From owner-ipng@sunroof.eng.sun.com Wed Aug 1 03:28:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71ARTi10486 for ipng-dist; Wed, 1 Aug 2001 03:27:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71ARPD10478; Wed, 1 Aug 2001 03:27:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17837; Wed, 1 Aug 2001 03:27:37 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02552; Wed, 1 Aug 2001 03:27:33 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f71AQeL02265; Wed, 1 Aug 2001 17:26:41 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <2914.996582086@brandenburg.cs.mu.OZ.AU> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Aug 2001 17:26:40 +0700 Message-ID: <2263.996661600@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 31 Jul 2001 16:17:17 -0700 From: "D. J. Bernstein" Message-ID: | In the aol.com example, the sysadmin sets up dns-01.ns.aol.com A6 ... | prefix.aol.net, and similarly dns-02.ns.aol.com A6 ... prefix.aol.net. | What's ``ludicrous'' about that? It's exactly what the A6 specifications | encourage him to do. The A6 specs don't encourage anything. They indicate some ways that A6 might perhaps be used. It also says that for NS records, A6 0 should be used... | But it destroys connectivity to AOL. Even though this fictional example doesn't follow the suggestions for NS records, it only "destroys connectivity" when accompanied with one perverse method of ignoring "glue". What's more, one method which isn't even consistent with its proponent's views of how the DNS ought to have been designed. With any reasonable implementation, the setup described would work. [Aside: it really would be better to use fictional domains - like example.com or .xx for illustrative purposes, as best I can tell, AOL have never deployed A6 records this way, however dumb some of their other DNS setups might have been] | All the efficiency issues are minor. The reliability issues are crucial. Reliability is important. Yes. But we cannot go to the extreme of preferring reliability over everything else - if we did, the DNS protocol would probably require a database retained at every node, containing a complete list of all the other nodes on the internet and their addresses (etc). That way, lookups would never fail, and they'd be as quick as we care to make them. We could even call that database HOSTS.TXT. | The A6 proponents keep claiming that a limited form of A6 is safe, but | they never answer when I ask them to identify the exact limitation that | has this magical effect. Because there is none. A6 is safe in any event. But just like NS, etc, some configurations make more sense than others (are more likely to work in more environments). | How is the DNS administrator supposed to tell | the difference between ``ludicrous'' A6 records and normal A6 records? Valid point - we certainly need more written on how to use A6 well. That's some of what I am hoping to achieve in the near future - after the experiments have actually been done that collect the data that will have been analysed so as to actually have some basis for giving this kind of advice. 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 Aug 1 03:38:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71AbZh10572 for ipng-dist; Wed, 1 Aug 2001 03:37:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71AbGD10550; Wed, 1 Aug 2001 03:37:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18405; Wed, 1 Aug 2001 03:37:27 -0700 (PDT) Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04906; Wed, 1 Aug 2001 04:38:59 -0600 (MDT) Received: by EMAIL5 with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 12:36:52 +0200 Message-ID: From: Philippe Cousin To: "'ngtrans@sunroof.eng.sun.com'" , "'ipng@sunroof.eng.sun.com'" Cc: "Francis Dupont (E-mail)" , "Laurent Toutain (E-mail)" , =?iso-8859-1?Q?C=E9sar_Viho_=28E-mail=29?= , "Latif LADID (E-mail)" , "Jim Bound (E-mail)" , Nathalie Guinet , Jean-Luc Freisse , "Sarolta Dibuz (E-mail)" , "Ward Catriona (E-mail)" , "Patrick Grossetete (E-mail)" Subject: IPv6 Interoperability event organised by ETSI on 19-23 November 2 001. Date: Wed, 1 Aug 2001 12:37:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear madams, dear sirs, I am pleased to inform you on the preparation of an IPv6 INTEROPERABILITY EVENT which will be organised by the ETSI Interoperability service (also recently named as the Plugtests service). The event is scheduled on the 19-23 November, at ETSI Headquarter Sophia-Antipolis, France or in the surrounding. The topics addressed during the interoperability event are: - IPv4-IPv6 transition mechanisms (6to4, Tunnel broker, DSTM, SIIT, NAT-PT, ..) - IPv6 with 3G mobile (transition from Ipv4, ROHC, ..) - IPv6 testing (Mobile IP, IPsec, RIPng, ...) This event organised by ETSI, a neutral and non-profit organisation, is open to everyone and is sponsored by the E.U. through the e-Europe programme for a broader companies participation . Note that key expertise will be allocated for the preparation of the event in order to provide testing facilities on the topics identified here above. Experts will also be present during the event for assisting the participants. Update information will be maintained on the www.etsi.org/plugtests web site. Detailed and final information as well as registration to the event will be available before end of august. Suggestions and/or support are welcomed. Looking forward to recording your participation to the event. Best regards Philippe COUSIN Interoperability Service Manager Tel: + 33 (0)4 92 94 4306 Fax: +33 (0)4 93 65 4716 http:\\www.etsi.org\plugtests\ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 1 03:58:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71AvRS10609 for ipng-dist; Wed, 1 Aug 2001 03:57:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71AvMD10602; Wed, 1 Aug 2001 03:57:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19636; Wed, 1 Aug 2001 03:57:35 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA12336; Wed, 1 Aug 2001 04:59:05 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 93B1A4B20; Wed, 1 Aug 2001 19:57:24 +0900 (JST) To: Philippe Cousin Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: Philippe.Cousin's message of Wed, 01 Aug 2001 12:37:14 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 Interoperability event organised by ETSI on 19-23 November 2 001. From: itojun@iijlab.net Date: Wed, 01 Aug 2001 19:57:24 +0900 Message-ID: <369.996663444@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am pleased to inform you on the preparation of an IPv6 INTEROPERABILITY >EVENT which will be organised by the ETSI Interoperability service (also >recently named as the Plugtests service). > >The event is scheduled on the 19-23 November, at ETSI Headquarter >Sophia-Antipolis, France or in the surrounding. Just wondering - are there any particular reasons for the dates? There's an IPv6-related conference from nov20 to nov23, in paris (is it an IPv6 forum event?). I guess some people needs to multiply themselves to ateend both. http://www.upperside.fr/ipv6/deployipv6intro.htm itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 1 04:17:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71BHLx10692 for ipng-dist; Wed, 1 Aug 2001 04:17:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71BGuD10672; Wed, 1 Aug 2001 04:16:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15943; Wed, 1 Aug 2001 04:17:09 -0700 (PDT) Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA21065; Wed, 1 Aug 2001 05:18:40 -0600 (MDT) Received: by EMAIL5 with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 13:16:34 +0200 Message-ID: From: Philippe Cousin To: "'itojun@iijlab.net'" Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: IPv6 Interoperability event organised by ETSI on 19-23 Novemb er 2 001. Date: Wed, 1 Aug 2001 13:16:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----Original Message----- From: itojun@iijlab.net [mailto:itojun@iijlab.net] Sent: 01 August 2001 12:57 To: Philippe Cousin Cc: ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: Re: IPv6 Interoperability event organised by ETSI on 19-23 November 2 001. >I am pleased to inform you on the preparation of an IPv6 INTEROPERABILITY >EVENT which will be organised by the ETSI Interoperability service (also >recently named as the Plugtests service). > >The event is scheduled on the 19-23 November, at ETSI Headquarter >Sophia-Antipolis, France or in the surrounding. Just wondering - are there any particular reasons for the dates? There's an IPv6-related conference from nov20 to nov23, in paris (is it an IPv6 forum event?). I guess some people needs to multiply themselves to ateend both. http://www.upperside.fr/ipv6/deployipv6intro.htm Thanks for the info , I was not aware of. As you no doubt know, it is difficult to find a date which will suit all. I believe that engineers who will attend the interop are not the same as those going to the conference. Some may also see combining Paris and Nice trips the same week. the date is not still writen in the stone and we may still have some room of maneuvre in case a lot of potential attendees have a clash in their agenda. regards Philippe itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 1 05:45:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71CiL910922 for ipng-dist; Wed, 1 Aug 2001 05:44:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71CiED10914 for ; Wed, 1 Aug 2001 05:44:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22664 for ; Wed, 1 Aug 2001 05:44:27 -0700 (PDT) Received: from muncher.math.uic.edu (koobera.math.uic.edu [131.193.178.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA23741 for ; Wed, 1 Aug 2001 06:44:26 -0600 (MDT) Received: (qmail 5454 invoked by uid 1001); 1 Aug 2001 12:44:45 -0000 Date: 1 Aug 2001 12:44:45 -0000 Message-ID: <20010801124445.30844.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > it only "destroys connectivity" when accompanied with one > perverse method of ignoring "glue". This ``perverse method'' has been used by all versions of BIND since 1997, and of course by every version of my cache. The need for it is explained in detail in http://cr.yp.to/djbdns/notes.html. > as best I can tell, AOL have never deployed A6 records this way Of course they haven't. We have a wonderful opportunity to abort the A6 and DNAME proposals before anyone starts relying on them. > for NS records, A6 0 should be used... How is that going to be enforced? How is the DNS administrator supposed to know which machines might later be used as name servers? Are caches going to abort NS lookups that involve A6 indirection? What about all the other ways that A6 can lead to loops? ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 1 06:54:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71Dqub11099 for ipng-dist; Wed, 1 Aug 2001 06:52:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71DqqD11092; Wed, 1 Aug 2001 06:52:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23559; Wed, 1 Aug 2001 06:53:06 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05511; Wed, 1 Aug 2001 07:53:00 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f71DqDL02864; Wed, 1 Aug 2001 20:52:13 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <20010801124445.30844.qmail@cr.yp.to> References: <20010801124445.30844.qmail@cr.yp.to> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Aug 2001 20:52:13 +0700 Message-ID: <2862.996673933@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 1 Aug 2001 12:44:45 -0000 From: "D. J. Bernstein" Message-ID: <20010801124445.30844.qmail@cr.yp.to> | This ``perverse method'' has been used by all versions of BIND since | 1997, and of course by every version of my cache. The need for it is | explained in detail in http://cr.yp.to/djbdns/notes.html. I haven't looked to see whether BIND really does that or not, but there is certainly no need for it (and I actually doubt it a bit). To be more clear, the web page (originally) referred to suggests that the DNS should have originally used foo.example.com. IN NS 192.168.1.17 instead of foo.example.com. IN NS ns.example.com. ns.example.com. IN A 192.168.1.17 That is, advocating server resolution of indirection. If one were to assume that that is how things should be done, then one must also assume that a DNS packet containing foo.example.com. IN NS 192.168.1.17 encoded in some DNS format binary form would be acceptable. But apparently it isn't, if the DNS binary form is ... foo.example.com. IN NS trash-name. trash-name. IN A 192.168.1.17 where the 2nd occurrence of "trash-name." is, of course, just a pointer back to the first one using internal DNS name compression techniques. Given the currently adopted format for DNS packets, which contains a (compressible) label as the value of a NS RR, encoding the server side resolution of the NS record indirection in this (2 RR) way is the obvious thing to do - it retains compatability with the rest of the deployed DNS. The pair of RRs given there allow the IP address of the nameserver for the foo.example.com. domain to be located, which is what is needed to actually use it to lookup names in the foo.example.com. domain of course. That's exactly the same as if the NS record had contained the address in the first place. The two encoding methods are isomorphic. For anyone to seriously claim that server side resolution of the indirection is the way things should be done, and that for some security or reliability related reason, this cannot be be made to work, begs credulity. Note: no-one said anything about caching the "trash-name. IN A .." record anywhere, or using it for any purpose at all, other than for finding the address of the nameserver for the domain. This works for NS records, it works for A6, it works for anything else, and is exactly as reliable and secure as would putting all of the data into one RR. The only difference is in the cases where the extra A record is not included with the original response, which is a deliberate choice to trade off some extra round trips (queries) (and hence lower reliability a little) for the extra flexibility it gives. | > for NS records, A6 0 should be used... | How is that going to be enforced? I didn't say it needed to be enforced - I was reacting to the suggestion that people were being encouraged to use A6 in the way your web page suggests. But if it were to be enforced, the place to do it would be when the delegation is done. eg: right now, if you attempt to delegate a domain in a zone I manage, your listed NS list will be checked, and if any of those is a CNAME, rather than having an A record (for IPv4 delegations) then I simply won't do the delegation. You either give the name an A record, or use a different NS name, or your domain isn't delegated. For IPv6 I can, if I desire, simply check that the A6 record of the NS is an A6 0 format - if that turns out to be the right thing to do (which the A6 RFC suggests it probably will be, but until we get it tested it is hard to know for sure). | Are caches going to abort NS lookups that involve A6 indirection? I expect not, as they don't necessarily abort NS lookups when a CNAME is found. That the resolver (a cache is just a storage mechanism for results that have been obtained previously, it is the resolver that is doing the lookup) is able to translate the name doesn't mean that it is the way that it should be deployed. | What about all the other ways that A6 can lead to loops? They will result in lookup failures - just as do CNAME loops, and NS loops, and all of the other ways that people can shoot themselves. If you want your names to be useful for people, you make sure they're entered in a way that works. If you don't care, then you don't, and people won't be able to use your name. That's the way it is now, it is the way it should remain. 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 Aug 1 07:03:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71E3Fa11186 for ipng-dist; Wed, 1 Aug 2001 07:03:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71E3AD11179; Wed, 1 Aug 2001 07:03:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22881; Wed, 1 Aug 2001 07:03:24 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04483; Wed, 1 Aug 2001 08:04:52 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A59364B20; Wed, 1 Aug 2001 23:03:11 +0900 (JST) To: Robert Elz Cc: Olafur Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, Alain Durand , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Tue, 31 Jul 2001 07:42:36 MST. 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: Joint DNSEXT & NGTRANS agenda From: itojun@iijlab.net Date: Wed, 01 Aug 2001 23:03:11 +0900 Message-ID: <2244.996674591@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | 4 Jun-ichiro itojun Hagino : > | >This one contains a bunch of info on the current state of the world, >followed by a large amount of FUD. There's essentially nothing in it >of value to the discussion. I could analyse this doc paragraph by >paragraph, and was once planning to do so - but I think that would be >a waste of everyone's time. plesae comment paragraphs one by one, or drop the assertion that it is a FUD. i wrote this because i believe there are serious problems with respect to the deployment as well as operation. if you don't get the problem, please say so (and I will need to describe it better). if you saw any mistakes in the draft. please say so (and i will need to correct those points, or describe them better). it's not productive to assert someone's draft as a FUD! itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 1 09:35:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71GYNO11715 for ipng-dist; Wed, 1 Aug 2001 09:34:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71GYJD11708 for ; Wed, 1 Aug 2001 09:34:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12129 for ; Wed, 1 Aug 2001 09:34:33 -0700 (PDT) Received: from blueyonder.co.uk (pcow028o.blueyonder.co.uk [195.188.53.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17225 for ; Wed, 1 Aug 2001 10:34:31 -0600 (MDT) Received: from mail pickup service by blueyonder.co.uk with Microsoft SMTPSVC; Wed, 1 Aug 2001 16:57:43 +0100 Received: from mercury.Sun.COM ([192.9.25.1]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 31 Jul 2001 20:41:00 +0100 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00201; Tue, 31 Jul 2001 12:40:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20180; Tue, 31 Jul 2001 12:39:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VJWHp07653 for ipng-dist; Tue, 31 Jul 2001 12:32:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VJWCY07646 for ; Tue, 31 Jul 2001 12:32:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00577; Tue, 31 Jul 2001 12:32:25 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27432; Tue, 31 Jul 2001 12:32:23 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 31 Jul 2001 12:32:19 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 4172351F99DC426598D88796474BC165 for plus 3 more; Tue, 31 Jul 2001 12:32:18 -0700 Reply-To: From: "Tony Hain" To: "Erik Nordmark" Cc: "Stig Venaas" , , Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt Date: Tue, 31 Jul 2001 12:32:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: F4D87574-26D94361-A461D21C-2AA56BC6 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6VJWDY07647 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > The text that Stig quoted from RFC 2461 says at the end > If the Default Router List is empty, > the sender assumes that the destination is on-link. > > In Unix implementations a possible implementation of this aspect > is by creating this route > route add default -interface > where is the hostname/IP address assigned to the node. I had always read that section as 'if you don't know a router simply try ND as a last resort'. I would still consider an implementation broken if it interpreted the lack of a router entry to mean that it should declare one of its interfaces to be the default route. I realize this is simply a semantic difference, but mixing the routing table with the neighbor cache seems like an operational disaster waiting to happen. > One possible way of making the draft clearer would be to, instead > of using the implementation concept of a routing table, express > the rule using the conceptual model in RFC 2461. I didn't read the rule as being restricted to a routing table because it included 'or the current next-hop neighbor'. I agree that could be interpreted as a router, but it could also be just the destination pointed to by the NC entry. How about 'or the current next-hop in the neighbor cache for DB is known to be unreachable'? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 1 10:30:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71HUK313000 for ipng-dist; Wed, 1 Aug 2001 10:30:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71HUGD12993 for ; Wed, 1 Aug 2001 10:30:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08087 for ; Wed, 1 Aug 2001 10:30:18 -0700 (PDT) Received: from blueyonder.co.uk (pcow028o.blueyonder.co.uk [195.188.53.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10706 for ; Wed, 1 Aug 2001 11:30:16 -0600 (MDT) Received: from mail pickup service by blueyonder.co.uk with Microsoft SMTPSVC; Wed, 1 Aug 2001 17:41:05 +0100 Received: from patan.sun.com ([192.18.98.43]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 31 Jul 2001 21:27:18 +0100 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04876; Tue, 31 Jul 2001 14:26:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17786; Tue, 31 Jul 2001 13:24:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VKENB07778 for ipng-dist; Tue, 31 Jul 2001 13:14:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VKEJY07771 for ; Tue, 31 Jul 2001 13:14:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28100 for ; Tue, 31 Jul 2001 13:14:33 -0700 (PDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02585 for ; Tue, 31 Jul 2001 14:16:05 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA11382 for ; Tue, 31 Jul 2001 15:12:29 -0500 Received: from d04mc300.raleigh.ibm.com (d04mc300.raleigh.ibm.com [9.67.228.190]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f6VKDF4108962 for ; Tue, 31 Jul 2001 16:13:15 -0400 Importance: Normal Subject: Which takes precedence - PKTINFO setsockopt or MULTICAST_IF setsockopt? To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Lori Napoli" Date: Tue, 31 Jul 2001 16:13:17 -0400 X-MIMETrack: Serialize by Router on D04MC300/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/31/2001 04:13:14 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to understand what interface would take precedence if an application is sending multicast traffic and had done both a PKTINFO setsockopt() that specified the outgoing interface and a MULTICAST_IF setsockopt to specify the outgoing interface. The follow text is from draft-ietf-ipngwg-rfc2292bis-02.txt which talks about PKTINFO ancillary data overriding the MULTICAST_IF socket option but does not give direction on the PKTINFO setsockopt. Thanks. 6.1. Specifying/Receiving the Interface Interfaces on an IPv6 node are identified by a small positive integer, as described in Section 4 of [RFC-2553]. That document also describes a function to map an interface name to its interface index, a function to map an interface index to its interface name, and a function to return all the interface names and indexes. Notice from this document that no interface is ever assigned an index of 0. When specifying the outgoing interface, if the ipi6_ifindex value is 0, the kernel will choose the outgoing interface. If the application specifies an outgoing interface for a multicast packet, the interface specified by the ancillary data overrides any interface specified by the IPV6_MULTICAST_IF socket option (described in [RFC-2553]), for that call to sendmsg() only. When the IPV6_RECVPKTINFO socket option is enabled, the received interface index is always returned as the ipi6_ifindex member of the in6_pktinfo structure. Lori z/OS Communications Server Development - TCP/IP Stack 919-254-6146 T/L 8-444-6146 E-mail: lanapoli@us.ibm.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 Aug 1 11:44:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f71Ii0X14034 for ipng-dist; Wed, 1 Aug 2001 11:44:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71IhtD14027 for ; Wed, 1 Aug 2001 11:43:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12962 for ; Wed, 1 Aug 2001 11:44:08 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA14812 for ; Wed, 1 Aug 2001 12:44:06 -0600 (MDT) Received: (qmail 3988 invoked by uid 1001); 1 Aug 2001 18:44:27 -0000 Date: 1 Aug 2001 18:44:27 -0000 Message-ID: <20010801184427.22210.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> <20010801124445.30844.qmail@cr.yp.to> <2862.996673933@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > For anyone to seriously claim that server side resolution of the > indirection is the way things should be done, and that for some > security or reliability related reason, this cannot be be made to > work, begs credulity. You are, as usual, massively confused. The reliability problems are not caused by the normal anti-poisoning rules. The problems are caused by servers that DO NOT HAVE ALL THE INFORMATION THE CLIENT NEEDS. For example, when a .com server says barclays.com NS ns1.barclays.co.uk, the client has to go look up the ns1.barclays.co.uk address. Is this because the client is protecting itself against poison? No. It's because the .com servers DO NOT HAVE THAT ADDRESS. Server-side indirection means that the server _does_ have the address. In this case, the server can easily use an in-bailiwick name for the address, so the normal anti-poisoning rules once again have no effect. The client avoids the extra lookups and the possibility of loops. The reason I recommend in-bailiwick names within the existing DNS architecture is that those names force the server to collect the address. Putting IP addresses into NS records directly would have the same beneficial effect. Summary: * Good situation: The server has the information. * Bad situation: The server doesn't have the information. The bad situation produces reliability problems. The point of A6 and DNAME is to move from the good situation to the bad situation; this is why I oppose A6 and DNAME. Of course, all of this is already explained on my web page. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 1 17:17:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f720H7c16170 for ipng-dist; Wed, 1 Aug 2001 17:17:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f720H3D16163 for ; Wed, 1 Aug 2001 17:17:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05447 for ; Wed, 1 Aug 2001 17:17:17 -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 SAA19642 for ; Wed, 1 Aug 2001 18:18:48 -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 RAA06210; Wed, 1 Aug 2001 17:17:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f720HF328469; Wed, 1 Aug 2001 17:17:15 -0700 X-mProtect: Wed, 1 Aug 2001 17:17:15 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdfYGt9r; Wed, 01 Aug 2001 17:17:13 PDT Message-Id: <4.3.2.7.2.20010801171510.0213ccd0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Aug 2001 17:16:47 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Agenda for London IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the agenda for IPng w.g. sessions at the London IETF. We have tried to allow enough time for each talk to permit a reasonable amount of discussion. As part of putting together the agenda, we gave priority to current working group activities and documents, new individual submissions, and last to status reports. Speakers should plan to keep their talk within the allotted time including discussion. The chairs will do our best to keep to this agenda. Please send us comments and change requests. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------------- WEDNESDAY, August 8, 2001 1300-1500 ------------------------------------ Introduction / Steve Deering (5 min) Review Agenda / Steve Deering (5 min) Document & Charter Status / Bob Hinden (10 min) 3GPP-IETF Design team status / Bob Hinden (10 min) DNS Discovery / Dave Thaler (20 min) Multilink Subnets / Dave Thaler (20 min) DHCPv6 Status and Last Call / Ralph Droms (10 min) Minimum IPv6 Functionality for a Cellular Host / John Loughney (25 min) AAAv6 Status / Charlie Perkins (5 min) Status of Linux and USAGI IPv6 / Yuji Sekiya (5 min) FRIDAY, August 10, 2001 0900-1130 ----------------------------------- IPv6 MIB Update Status / Bill Fenner (15 min) nnnn=2096,2011,2012,2013 IPv6 Site Renumbering / Christian Huitema (20 min) Source/Destination Address Selection / Brian Zill (15 min) Domain Name Auto-Registration for Plugged-in IPv6 Nodes / Hiroshi Kitamura (15 min) A proposal for the IPv6 Flow Label Specification / Alex Conta (30 min) Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino (15 min) Avoiding ping-pong packets on point-to-point links / Jun-ichiro itojun Hagino (10 min) An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min) Disconnecting TCP connection toward IPv6 anycast address / Jun-ichiro itojun Hagino (10 min) Socket API for IPv6 traffic class field / Jun-ichiro itojun Hagino (5min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 1 22:15:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f725Ejm16726 for ipng-dist; Wed, 1 Aug 2001 22:14:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f725EeD16719; Wed, 1 Aug 2001 22:14:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27442; Wed, 1 Aug 2001 22:14:54 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA02206; Wed, 1 Aug 2001 22:14:50 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f71IOlv00592; Thu, 2 Aug 2001 01:24:47 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <2244.996674591@itojun.org> References: <2244.996674591@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 02 Aug 2001 01:24:46 +0700 Message-ID: <590.996690286@brandenburg.cs.mu.OZ.AU> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f725EfE16720 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 01 Aug 2001 23:03:11 +0900 From: itojun@iijlab.net Message-ID: <2244.996674591@itojun.org> | plesae comment paragraphs one by one, OK, I'll do that. I'd actually suggest that most people not read much of this message - if my original assertion is correct, you'll just be wasting your time. If it isn't, then it will be the responses to this message that show that. | or drop the assertion that it is a FUD. I'm afraid you'll be seeing a bit more of that in this message. | i wrote this because i believe there are serious problems | with respect to the deployment as well as operation. I don't doubt that at all - no aspersions on your motives, or anyone else's. I just don't think that this doc adds much to the debate. That isn't to say that A6 should be adopted because of this, but nor is there anything here to suggest it shouldn't. | it's not productive to assert someone's draft as a FUD! Unfortunately, sometimes it is. I'll omit the boilerplate, abstract, and similar sections in this analysis of course... Section 1 is just a brief restatement of the basics of the RR types. No problems there. Though in 1.2, if you wanted to be truly fair, you'd add M O P Q R as more nodes in the zone file (same as N with different interface identifiers). After all, your typical zone file has more end nodes than subnets, and there are usually more of those that providers, etc... The example shown makes it look like A6 will have of the order of 13 RRs for a single node's addresses, whereas AAAA only requires 3. Make that be 6 nodes (a very small network) and you get 18 RR's for the A6 case, 18 RRs for the AAAA case. And that's with an overly elaborate A6 setup for most people (especially for a net that small). Section 2 is a statement about the state of the world as it is, no problems there either. Section 3 is where the comparisons are. 3.1 is how AAAA is familiar, we know it works, ... the beginnings of FUD. 3.2 If we are to use fragmented A6s (128bit splitted into multiple A6s), we have a lot of issues/worries." FUD. If we are to resolve IPv6 addresses using fragmented A6 records, we need to query DNS multiple times to resolve a single DNS name into an IPv6 address. should be "we might need to query". Since there has been no DNS record types that require multiple queries for resolution of the address itself, we have very little experience on such resource records. Not true, all non-trivial DNS lookups require multiple queries. In particular doing a lookup for any alias (owner of a CNAME) requires the CNAME be resolved, and then the A record be found (potentially via more CNAMEs). We have lots of experience with such things. The only part that differs is the "of the address itself". More FUD. There will be more delays in name resolution compared to queries to A/AAAA records. Not true. "There might be more delays" would be better. If we define a record with more number of fragments, there will be more query roundtrips. Same. There might be more round trips. How many more (what the average increase is, for a typical query) hasn't been measured. ie: FUD. There are only few possibilities to query fragments in parallel. True, but this is not new. In the above example, we can resolve A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others. Take a complex example and treat it as a common case ... create FUD. At this moment, there is very little documents available, regarding to the relationship between DNS record TTL and the query delays. This is true, but it is nothing new for A6. The same applies to very short TTLs in NS, CNAME, ... eg: if I do an A lookup of www.example.com and get back www.example.com. 1 IN CNAME www.example.net. and then it takes more than 1 second to figure out the A related to www.example.net, am I allowed to still return that CNAME? If not, then all the rest of the resolution is useless, it doesn't apply. A6 is just this same problem. It would be a good idea to codify Rob Austein's response to this issue and settle it. Raising it in the context of A6 in particular is just more FUD. The rest of page 5 is just exploring this issue in more detail, it isn't related to A6 specifically at all. If some of the fragments are DNSSEC-signed and some are not, how should we treat that address? RFC2874 section 6 briefly talks about it, not sure if complete answer is given. There's no difference here with A6 or any other DNS chain, which is only partially secure. Either you have en unbroken chain of sigs/keys back to something that you trust, or the data is unsecured. Nothing new for A6. FUD. It is much harder to implement A6 fragment reassemble code, than to implement AAAA record resolver. AAAA record resolver can be implemented as a straight extension of A record resolver. More FUD. More, this is irrelevant FUD. It is more difficult to implement a DNS resolver than a HOST.TXT lookup, but we still switched from HOSTS.TXT to the DNS. The resolver gets implemented just a small number of times, how difficult each of those happens to be is pretty much irrelevant in the grand scheme of things. o It is much harder to design timeout handling for the A6 reassembly. FUD. o In the case of library resolver implementation, it is harder to deal with exceptions (signals in UNIX case) for the large code fragment for resolvers. This basically says that writing resolvers isn't easy. Nothing at all related to A6 in this paragraph. Just FUD. There's nothing qualitatively new in A6, as far as DNS lookups go - just perhaps more of it. Nothing specially new (in this area) is required to implement A6. o When A6 prefix length field is not multiple of 8, address suffix portion needs to be shifted bitwise while A6 fragments are reassembled. [...] FUD. "I can create coding bugs" ... AAAA records are are 128 bits long, but aren't aligned, in DNS packets, implementations might not correctly align the data before using it, .... Gibberish. In RFC2874, a suggestion is made to use limited number of fragments per an IPv6 address. However, there is no protocol limitation defined. This is true. Perhaps we need to define a limit. Or perhaps we don't. We need some experience with what works and what doesn't. The lack makes it easier for malicious parties to impose DoS attacks using lots of A6 fragments (see the section on security consideration). More FUD. There are lots of ways to use the DNS to cause a remote node to do more work than it would prefer to do. Almost none of them have any practical effect, A6 less than some others. Nodes will only be doing A6 lookups when they have some reason to contact another node (like A). Sure you can arrange A6 to make it difficult or impossible for another node to contact you, and to make it do a whole lot of extra work. There are a zillion other ways to make a node do a whole bunch of extra work when it tries to contact you as well, both using the DNS, and via other means. With fragmented A6 records, in multi-prefix network configuration, it is not possible for us to limit the address on the DNS database to the specific set of records, like for load distribution purposes. Consider the following example. Even if we would like to advertise only 2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible to do so. It becomes mandatory for us to define the whole IPv6 address by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 (renumber friendliness) goes away. This is simply not true. All that is needed is more imaginative use of the A6 records. Eg; N.X.EXAMPLE. IN A6 40 ::11:1:1234:5678:9ABC:DEF0 A.NET.IP6.D.NET. or, if there were other nodes on the same subnet that we wanted to do the same thing to N.X.EXAMPLE. IN A6 64 ::1234:5678:9ABC:DEF0 A-D-ONLY A-D-ONLY IN A6 40 0:0:0011:: A.NET.IP6.D.NET. (and apologies if I got either of the details of those wrong, the details aren't important here, so I didn't think about them much). In either case, we still gain from not building in D.NET...'s prefix. So the benefit of A6 (renumber friendliness) does not "go away". Obviously though the more constraints we put on which addresses we are willing to allow to be advertised, that is, the more we build in addressing knowledge into our policy requirements, the more the DNS info will be tied to out specific address blocks - that's unavoidable for this kind of policy. It is also comparatively rare. The example at the top of page 7 is just more misguided configuration. 3.3 There are proposals to use non-fragmented A6 records in most of the places, like ``A6 0 <128bit>'', so that we would be able to switch to fragmented A6 records when we find a need for A6. This hs been suggested as a first step, yes. "In most of the places" isn't what has been suggested though that I have seen. Using A6 0 for NS records (which isn't most of anything) has been suggested. Using A6 0 as the first deployment step for A6 - before we have determined what costs those potential extra round trips might be (ie: to avoid the FUD relted to slower name resolution) has been suggested. From the packet format point of view, the approach has no benefit against AAAA. Rather, there is a one-byte overhead to every (unfragmented) A6 record compared to a AAAA record. It also has almost no cost. If the nameserver/resolver programs hardcode A6 processing to handle no fragments, there will be no future possibility for us to introduce fragmented A6 records. Yes, but that isn't what is being suggested. When there is no need for A6 reassembly, there will be no code deployment, and even if the reassembly code gets deployed they will not be tested enough. FUD. We can always do testing. Where lack of testing bites implementations is with the stuff that no-one thought to test, either because it was "obvious" that it would work, or because it was some wild case that no-one ever thought would happen (or thought of at all). A6 reassembly cerainly is neither of those. Testing it in the lab is trivial. Getting the bugs out is almost as trivial. How much it actually occurs in the wild doesn't matter. The author believes that the ``prepare for the future, use non-fragmented A6'' argument is not worthwhile. I won't dispute that - but just be sure that the case in favour of it is just to avoid the FUD that surrounds the extra queries that might be needed - have people set up their zones with A6 0, and then they'll know that they'll work just the same as AAAA would work, it is a safe option which will cause no problems. As the same time, braver souls can use more complex A6 setups. In the event of renumbering, non-fragmented A6 record has the same property as AAAA (the whole zone file has to be updated). This is certainly true (just a re-statement of part of the A6 design). 3.4 At this moment, end hosts support AAAA records only. Some people would like to see A6 deployment in DNS databases even with the lack of end hosts support. To workaround the deployment issues of A6, the following approach is proposed in IETF50 dnsext working group slot. It is called ``AAAA synthesis'' [Austein, 2001] : This is obviously a transiton method (or likely to be) - though having stub resolvers that only ever do AAAA, much as we have stub resolvers with no cache, and no way to do any kind of recursive lookups, with everything in a back end resolver, is a possibility. o Deploy A6 DNS records worldwide. The proposal was not specific about whether we would deploy fragmented A6 records, or non-fragmented A6 records (``A6 0''). It doesn't matter for this purpose. That's back to how important avoiding the FUD with the extra queries is seen to be. There's no need for everyone to adopt the same approach. o When a host queries AAAA record to a DNS server, the DNS server queries A6 fragments, reassemble it, and respond with a AAAA record. "DNS server" there should really be back end resolver. It is for the box near the stub resolver to do this, not the server for the zone. The approach needs to be diagnosed/specified in far more detail. Perhaps. It certainly wouldn't hurt, but I'm not sure it is needed either. That is, this is really something of a local issue between the stub resolver and its back end. That could be standardised, but doesn't have to be. Just to show it can be done, I'll give some answers. Not necessarily the right answers all the time, but plausible ones I think. That's to remove the FUD that comes from giving a list of unanswered questions, which implies that all this stuff must be difficult... o What is the DNS error code against AAAA querier, if the A6 reassembly fails? SERVFAIL, the same as when any DNS lookup fails. o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap uses TTL=0] It almost certainly doesn't matter, stub resolvers tend to have no caches anyway (whatever the TTL is, it is ignored). But anything between 0 and the minimum TTL from the A6 fragments combined would work. One of those two extremes would be most likely. o Which nameserver should synthesize the AAAA record, in the DNS recursize query chain? Is the synthesis mandatory for every DNS server implementation? The first one queried - the same one that does the recursive query work for the stub resolver. And no, of course not, it is only needed if you deply stub resolvers that need it (just the same as implementing resursive lookups in a server). o What should we do if the A6 reassembly takes too much time? Same as if chasing CNAME records takes too much time, or NS's don't respond soon enough, or ... Nothing even slightly new here. o What should we do about DNSSEC signatures? Most likely verify them in the back end resolver, and then (most likely using TSIG) indicate to the stub resolver that the data is OK. If we ever get stub resolvers that are doing their own signature validation, then I think they can be doing their own A6 resolution as well - dnssec is certainly lots more work than A6... o What if the resolver wants no synthesis? Do we want to have a flag bit in DNS packet, to enable/disable AAAA synthesis? It just queries for A6 records instead of AAAA. This whole scheme only makes sense if A6 records are to be the ones selected to be used. That is, there are no AAAA records in the wild any more. The only sense to ever query for AAAA is if you are requesting AAAA synthesis. (Of course, in the short term, you might actually get an original AAAA record, but that's just a transitional artifact). o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query timeouts, and other timeout parameters? This looks to be some (most) of the above points, simply restated more briefly. The approach seems to be vulnerable against DoS attacks, because the nameserver reassembles A6 fragments on behalf of the AAAA querier. FUD. There is nothing different here from any case where a back end resolver does all the work and then hands the final result of the query back to the stub resolver. 3.5. Issues in keeping both AAAA and A6 Did anyone actually suggest doing that? It makes no sense at all. If we adopt A6, then anyone who prefers the AAAA style, simply uses A6 0, that gives them all they would ever get from AAAA (at the cost of 1 byte per A6 0 record returned). If we are to keep both AAAA and A6 records onto the worldwide DNS database, it would impose more query delays to the client resolvers. It might indeed, if we were to do that nonsense thing, and do it in a nave way. If for some strange reason we did decide that keeping both A6 and AAAA made some kind of sense, then the obvious thing to do would be to invent a "meta-A" query (ANYA) which would return both AAAA and A6 records. It might be worth doing that anyway, and have it return A records as well - make it easier for dual stack implementations to discover all v4 and v6 addresses in a single query (could even have it return all the other address forms that we currently know of, for all those nodes in the internet with X.25 and NSAP and such records defined...) The rest of section 3.5 is just more FUD induced by not suggesting a more sensible method of dealing with an environment that will never exist (other than for a shortish transition period) anyway. 4 Some says that there will be more frequent renumbers in IPv6 network operation, and A6 is necessary to reduce the zone modification cost as well as zone signing costs on renumber operation. That is an argument, yes. It is not clear if we really want to renumber that frequently. How often we want to renumber is not really relevant. We don't want to renumber at all. What matters is how often we need to. We don't know. We might not know for another 20 years. With IPv6, it should be easier for ISPs to assign addresses statically to the downstream customers, rather than dynamically like we do in IPv4 dialup connectivity today. Probably true, as there are more IPv6 addresses (plenty) and so there should be much less need to share addresses. However, many ISPs seem to want to shuffle addresses not because of address shortage (ie: they switch addresses from A to B even while the client is connected, so the number of addresses assigned isn't altering), and is more to discourage the client from running servers than from any other cause (if the client can't advertise a stable address, then it is almost impossible for them to run any kind of server). But this kind of renumbering has never been what we're trying to deal with (or not very much) - nodes that only get dynamic addresses when they dial up are almost never in the DNS to start with - A6 affects only renumbering the DNS, so those nodes/sites aren't the ones of interest. So, this whole line of argument is achieving nothing at all. The rest of this paragraph adds nothing. It is questionable if it is possible to renumber IPv6 networks more frequently than with IPv4. FUD. In any case what counts here isn't what is possible right now, but what we should be aiming at producing. What would be the ideal outcome? Router renumbering protocol [Crawford, 2000] , IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998] can help us renumber the IPv6 network, however, network renumbering itself is not an easy task. FUD. But it even contradicts the previous paragraph, all of that stuff from the first 2 lines makes IPv6 renumbering easier than IPv4, and if it is easier it can (not necessarily will) be done more often. If you would like to maintain reachability from the outside world, a site administrator needs to carefully coordinate site renumber. True. So? The minimal interval between renumber is restricted by DNS record timeouts, as DNS records will be cached around the world True, which is why working on the DNS wrt renumbering is relevant in the first place. That is, to enable frequent renumbering we need to keep the DNS TTL low. But a low TTL has negative effects on caching. That's where A6 has benefits - the low TTL can be on just the few A6 records at the higher level (the upper bits of the addresses). Lower bits change rarely, and can have much longer TTLs. Whether this is 1 day and 1 month, or 1 hour and 1 day, or 1 minute and 1 hour (or 1 minute and 1 month) doesn't matter. What the costs and benefits of this will be we don't know yet - no-one that I know of has actually measured them. Most of the rest of section 4 is just more on how hard renumbering can be. That's not disputed. It is also no excuse for giving up, claiming it is too hard to ever be solved, and hence not worth doing anything that might help. A6 was designed to help administators update zone files during network renumbering events. Even with AAAA, zone file modification itself is easy; you can just query-replace the addresses in the zone files. The difficulty of network renumber comes from elsewhere. That's certainly true. But if you're thinking of A6 as some kind of weird macro processor for the zone file, then it is no wonder that you don't think of it as being useful. That is certainly not where its benefit lies. With AAAA, we need to sign the whole zone again with DNSSEC keys, after renumbering the network. With A6, we need to sign upper bits only with DNSSEC keys. Therefore, A6 will impose less zone signing cost on the event of network renumbering. Yes, this is one (comparatively minor really) A6 benefit. The DNSSEC issue of greater import is that only those parts of an organisation concerned with the renumbering need to go update their records, and re-sign them. Eg: if a university gets a new link, and adds a new prefix, then the university prefix A6 record would be updated, and all of the departments would get that new prefix applied to all of their addresses in the DNS, without any of them having to re-generate anything at all. That's where the benefits really start to acrue, not in the saving of a few hours of CPU time (though that's not completely irrelevant either - if it takes too long to sign a zone file, sites won't do it, or won't do it in a secure manner). As seen above, it is questionable if we renumber network that often, so it is questionable if A6 brings us an overall benefit. FUD. Note, however, even if we use A6 to facilitate more frequent renumbering and lower signing cost, all glue records has to be installed as non-fragmented A6 records (``A6 0''), and required to be signed again on renumbering events. This is very likely true, though I haven't actually done the analysis to prove it is actually necessary - but in any case, there are small handfuls of such things (the University of Melbourne probably has about 20 glue A records for the whole institution...) 5. Security consideration Sect 5 before 5.1 is a simple restatement of stuff already covered. I won't go through that again. Essentially all FUD. 5.1 explores one particular attack that could be mounted. It isn't a very effective attack, as all the attacker really achieves is preventing the client from accessing the attacker's own systems, and doing a bunch of extra packet sending/receiving while that is happening. The client would keep on doing other stuff while all this is happening, probably wihout even noticing (just as it does while any other problematic DNS lookup is being done - and if you don't know that those happen all the time, you should spend some time watching what any large mail server spends most of its time doing today - yet mail still gets through just fine to all the systems whose DNS isn't totally hosed). It is quite possible that a totally hopeless implementation could get itself stuck attempting to resolve a name forever, but when we start to base decisions on what trash implementations might do, we're really delving the depths of poor decision making. Note, however, this problem could be considered as a problem in recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA synthesis makes the problem more apparent, and more complex to diagnose. The first clause there is true, I'd like to see some evidence for the second one, without that it is just more FUD. To remedy this problem, we have a couple of solutions: (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the problem goes away. No it doesn't, only this particular way of causing it. (2) Even if we use A6, do not configure nameservers for AAAA synthesis. Deployment issues with existing IPv6 hosts get much harder. Something still has to build the 128 bit address out of the A6 fragments, if we're using A6. That can be called "AAAA synthesis" (the work is all identical) regardless of whether a RR with the AAAA type is ever actually produced. Thus this would make no difference at all - there's no benefit at all to be gained by prohibiting back end resolvers from doing AAAA generation for their stub resolvers from this line of argument. (3) Impose a protocol limitation to the number of A6 fragments. This might be a good thing to do. But even if we don't, any rational implementaton is going to do it anyway. (4) Do not query the expired records in A6 chain again. In other words, implement resolvers that ignore TTL on DNS records. Not sure if it is the right thing to do. This is not "ignore" but "treat differently than you were thinking". This is actually no different than what everyone does with the TTLs we have no anyway - they're only ever used for deciding whether a record that is in a cache is still valid. No-one does an A lookup, sees that the TTL returned is 1, thinks to himself "it was a second ago that I did that lookup, so this A record is invalid now, I'd better go do it again". Nothing like that at all - the old gethostbyname() inteface doesn't even return the TTL to the application, so it has no idea at all how long the data it just fetched is valid. What is done everywere now, and would be perfectly reasonable (or at the very least, not at all worse) is to ignore the TTLs from the records being used to build the answer (this includes NS records, CNAME records, and any others, including A6, that we need to fetch to eventually get the result we want) - excepting in the one case that we're fetching a result from a cache from some earlier result, in which case if the TTL has expired, then we have to go get it again. This has some perhaps unusual effects when we have TTL's that are very small, but that's OK. After all, if you're worried about records with TTL 1 expiring before the rest of the answer is obtained, how do you justify dealing with records with TTL 0 at all? Those would be nominally expired while the packet that contains them is en route to the resolver (no matter how close it is). Thus, by this theory, the trivial infinite loop DNS DoS attack would be www 0 IN A 1.2.3.4 as soon as the resolver gets that, it sees it has expired, and so has to go fetch it again... This one bothers no-one, nor will the A6 cases. 6 Conclusion Since there is nothing in the doc that actually provides any real information, other than FUD, drawing conclusions from it isn't going to be easy. A6/AAAA discussion has been an obstacle for IPv6 deployment, as the deployment of IPv6 NS recodrs have been deferred because of the discussion. This one I can't dispute - the discussion might very well be delaying deployment in some places. We still need to get it right, this really isn't a case where any answer will do, even the wrong one. Tossing a coin isn't a good solution here. We need more experience, and at least some data. The author do not see benefit in keeping both AAAA and A6 records No, nor do I (except perhaps for stub-resolvers - ie: keep the RR type, but deprecate its use in zone files). Given the unlikeliness of frequent network renumbering There's no evidence for that. Only for renumbering being difficult to achieve. That something is hard doesn't mean that we won't be forced to do it. the author believes that the A6's benefit in lower zone signing cost is not significant. I think it is significant, I'm not sure that it alone would be compelling. But the stright CPU costs to sign zones are only one of the issues. From the above discussions, the author suggests to keep AAAA and deprecate A6 (move A6 document to historic state). That's OK, that's just an opinion (as the note at the beginning of the section makes clear). The author believes that A6 can cause a lot of problem than the benefits it may have. That this is believed is quite likely correct. But before we take any notice, we really need some kind of evidence. A6 will make IPv6 DNS operation more complicated and vulnerable to attacks. This is FUD. AAAA is proven to work right in our IPv6 network operation since 1996. AAAA has been working just fine in existing IPv6 networks, and the author believes that it will in the coming days. And this is the warm fuzzy alternative. Note: I am not claiming that anything in this analysis is an argument for preferring A6 over AAAA, all this message sets out to achieve is to show that this particular draft contains no useful arguments the other way. We still need more data to provide some of the answers. However urgent it may seem to get this issue resolved, it is more important that we get it right. For something to do in the immediate future, invent the ANYA meta-query record, have it return A AAAA and A6 records, get back end resolvers doing that, and creating AAAA records for stub resolvers that do AAAA requests. That way, either AAAA or A6 records can be deployed, which allows sites to start sticking in A6, while not breaking those still doing AAAA lookups, and without requiring everyone to do lookups of both (and throwing in free IPv4 answers to the local cache as a side benefit). Apologies for the length of this message, I hope not too many people have reached this far in processing it (unless you skipped all the middle bit). It really would have been better to not have needed to send it at 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 Wed Aug 1 23:56:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f726tRO16946 for ipng-dist; Wed, 1 Aug 2001 23:55:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f726tND16939; Wed, 1 Aug 2001 23:55:23 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18688; Wed, 1 Aug 2001 23:55:36 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04433; Wed, 1 Aug 2001 23:55:32 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1AFA04B21; Thu, 2 Aug 2001 15:55:29 +0900 (JST) To: Robert Elz Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 02 Aug 2001 01:24:46 +0700. <590.996690286@brandenburg.cs.mu.OZ.AU> 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: Joint DNSEXT & NGTRANS agenda From: itojun@iijlab.net Date: Thu, 02 Aug 2001 15:55:29 +0900 Message-ID: <11603.996735329@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | plesae comment paragraphs one by one, >OK, I'll do that. I'd actually suggest that most people not read much >of this message - if my original assertion is correct, you'll just be >wasting your time. If it isn't, then it will be the responses to this >message that show that. Now I can respond to your comments, I'm very happy. First of all I would like to thank for all the comments for all the paragraphs (just for clarification - even if people don't agree with each other's opinion, it is Japanese custom to thank for the effort itself in the first place. "thank you" does not mean that I agree with you). Please note that, in i-d, there could be issues with my English skills (like I'm asserting something I did not mean to assert, or I write "must" where I should have used "may"). In short, I cannot believe how can you assert these problems as just "FUD". This way there will be no progress. In your comment it seems that you are using the word "FUD" for "unanswered questions". I don't understand your choice of word, and I really really object. Also, you are asking for evidence multiple times, for something noone can possibly prove. This way of discussion is unfair, and I'd like to ask you to try to prove them by yourself while I think about them too. You also wrote some text that can be considered a FUD under your rule, which leds me to believe that you don't understand the issue and your objective is jut to object. I have tweaked the quotation marks (">") so that it gets more clearer which part is from the draft and which part is your comment. itojun --- >Section 1 is just a brief restatement of the basics of the RR types. >No problems there. Though in 1.2, if you wanted to be truly fair, >you'd add M O P Q R as more nodes in the zone file (same as N with >different interface identifiers). After all, your typical zone file >has more end nodes than subnets, and there are usually more of those >that providers, etc... The example shown makes it look like A6 will >have of the order of 13 RRs for a single node's addresses, whereas AAAA >only requires 3. Make that be 6 nodes (a very small network) and >you get 18 RR's for the A6 case, 18 RRs for the AAAA case. And that's >with an overly elaborate A6 setup for most people (especially for a net >that small). I don't feel the need to put multiple addresses onto the example here, since in the following sections we don't use them much. >3.1 is how AAAA is familiar, we know it works, ... the beginnings of FUD.= >>3.2 >> If we are to use fragmented A6s (128bit splitted into multiple A6s), >> we have a lot of issues/worries." >FUD. You cannot assert like this. I have presented worries and issues in the following texts, and the line summarizes these. If you can provide a better wording, I'd love to see that. >> If we are to resolve IPv6 addresses using fragmented A6 records, we >> need to query DNS multiple times to resolve a single DNS name into >> an IPv6 address. >should be "we might need to query". do you include "A6 0" case into "fragmented A6 records"? if so, I can understand your wording change. Otherwise, I don't get it. >> Since there has been no DNS record types that require multiple >> queries for resolution of the address itself, we have very little >> experience on such resource records. >Not true, all non-trivial DNS lookups require multiple queries. In parti= >cular >doing a lookup for any alias (owner of a CNAME) requires the CNAME be >resolved, and then the A record be found (potentially via more CNAMEs). >We have lots of experience with such things. The only part that differs >is the "of the address itself". More FUD. How can you ignore part of my text ("of the address itself") and assert the lines as "not true"? This is totally unfair. A6 is the only resource record type that composes a single address itself from multiple query results. It is true. >> There will be more delays in name resolution compared to queries to >> A/AAAA records. >Not true. "There might be more delays" would be better. >> If we define a record with more number of fragments, >> there will be more query roundtrips. >Same. There might be more round trips. How many more (what the average >increase is, for a typical query) hasn't been measured. ie: FUD. Again, I did not include "A6 0" into "fragmented A6 records" case. >> There are only few possibilities to query fragments in parallel. >True, but this is not new. >> In the above example, we can resolve >> A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others. >Take a complex example and treat it as a common case ... create FUD. This problem is not new but I believe it worth mentioning it. If I do not mention it, readers would mistakenly think that it is possible to parallelize the queries for A6 fragments. Do you have problem with it? If I cannot things that are not new how can I write up an analysis document. >> At this moment, there is very little documents available, regarding to >> the relationship between DNS record TTL and the query delays. >This is true, but it is nothing new for A6. The same applies to very >short TTLs in NS, CNAME, ... >eg: if I do an A lookup of www.example.com and get back > www.example.com. 1 IN CNAME www.example.net. >and then it takes more than 1 second to figure out the A related to >www.example.net, am I allowed to still return that CNAME? If not, then >all the rest of the resolution is useless, it doesn't apply. A6 is just >this same problem. It would be a good idea to codify Rob Austein's >response to this issue and settle it. Raising it in the context of A6 >in particular is just more FUD. >The rest of page 5 is just exploring this issue in more detail, it isn't >related to A6 specifically at all. With A6 the problem is more apparent as it is the only resource record type which composes a single address out of multiple query results. For example, you can get a completely different IPv6 address out of multiple queries, if you get part of A6 chains swapped with other item. Assuming that this one is correct: A6 64 ::t:u:v:w A6 48 ::s:0:0:0:0 A6 0 p:q:r:: now if you get "A6 48 ::x:0:0:0:0", you will have a whole lot of fun. The problem had not been obvious with other resource record types. For other record types, we would get a completely correct answer, or completely hosed answer. With A6 we would get a partially correct answer (incorrect bits within a part of 128bit address). >> If some of the fragments are DNSSEC-signed and some are not, how should >> we treat that address? RFC2874 section 6 briefly talks about it, not >> sure if complete answer is given. >There's no difference here with A6 or any other DNS chain, which is only >partially secure. Either you have en unbroken chain of sigs/keys back to >something that you trust, or the data is unsecured. Nothing new for A6. > FUD. No, this is not a FUD. You are mixing up two different issues. Because A6 is the only resource record type which composes a single address out of multiple query results: - for other record types, the result is binary - completely believable or not. - for A6, the result is not binary - part of bits can be believable, part of bits can be not believable. >> It is much harder to implement A6 fragment reassemble code, than to >> implement AAAA record resolver. AAAA record resolver can be implemented >> as a straight extension of A record resolver. >More FUD. More, this is irrelevant FUD. It is more difficult to >implement a DNS resolver than a HOST.TXT lookup, but we still switched >from HOSTS.TXT to the DNS. The resolver gets implemented just a small >number of times, how difficult each of those happens to be is pretty much >irrelevant in the grand scheme of things. This is from our implementation experiences. There are very few people out there (I believe) who have actually implemented A6 reassembly/decoding code, so I believe it worth mentioning. Try it by yourself and see how many mistakes you will make due to the bitwise manipulations. >> o It is much harder to design timeout handling for the A6 reassembly. >FUD. No. See the above. >> o In the case of library resolver implementation, it is harder to deal >> with exceptions (signals in UNIX case) for the large code fragment for >> resolvers. >This basically says that writing resolvers isn't easy. Nothing at all >related to A6 in this paragraph. Just FUD. There's nothing qualitative= >ly >new in A6, as far as DNS lookups go - just perhaps more of it. Nothing >specially new (in this area) is required to implement A6. No. Try to implement it into libc resolver (like BIND8) and experience the pain we had. >> o When A6 prefix length field is not multiple of 8, address suffix >> portion needs to be shifted bitwise while A6 fragments are >> reassembled. [...] >FUD. "I can create coding bugs" ... AAAA records are are 128 bits >long, but aren't aligned, in DNS packets, implementations might not >correctly align the data before using it, .... Gibberish. Bitwise operations are so much more painful than 8-bit boundary operations. >> In RFC2874, a suggestion is made to use limited number of fragments per >> an IPv6 address. However, there is no protocol limitation defined. >This is true. Perhaps we need to define a limit. Or perhaps we don't. >We need some experience with what works and what doesn't. But how can you enforce that? Resolver side can protect themselves by using the upper-limit, however, it is not possible to avoid longer-than-limit A6 chains be placed onto the DNS zone files. A6 fragments are likely to be maintained by different administrative domains. It is not likely that a single admin to control over the whole A6 chain (otherwise, there's no benefit of A6 chain). If you have some proposal for the enforcement please let me know. >> The lack makes it easier for malicious parties to impose DoS attacks >> using lots of A6 fragments (see the section on security consideration). >More FUD. There are lots of ways to use the DNS to cause a remote node >to do more work than it would prefer to do. Almost none of them have any >practical effect, A6 less than some others. Nodes will only be doing A6 >lookups when they have some reason to contact another node (like A). Sure >you can arrange A6 to make it difficult or impossible for another node to >contact you, and to make it do a whole lot of extra work. There are a zillion >other ways to make a node do a whole bunch of extra work when it tries to >contact you as well, both using the DNS, and via other means. I agree this is not just a problem of A6, however, A6 makes the problem much more easier to exploit. >> With fragmented A6 records, in multi-prefix network configuration, it is >> not possible for us to limit the address on the DNS database to the >> specific set of records, like for load distribution purposes. Consider >> the following example. Even if we would like to advertise only >> 2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible >> to do so. It becomes mandatory for us to define the whole IPv6 address >> by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6 >> (renumber friendliness) goes away. >This is simply not true. All that is needed is more imaginative use of >the A6 records. Eg; > N.X.EXAMPLE. IN A6 40 ::11:1:1234:5678:9ABC:DEF0 A.NET.IP6.D.NET. >or, if there were other nodes on the same subnet that we wanted to do the= >same thing to > N.X.EXAMPLE. IN A6 64 ::1234:5678:9ABC:DEF0 A-D-ONLY > A-D-ONLY IN A6 40 0:0:0011:: A.NET.IP6.D.NET. >(and apologies if I got either of the details of those wrong, the details >aren't important here, so I didn't think about them much). If you define upper bits (than the part that have assigned to you, like less than /48) you become less ready to renumber events. Therefore, the former one in your example will jeopardize the renumbering benefits of A6. The latter one is better, however, I don't think it manageable (can you prove it is manageable for random dumb admins like me?). >>3.3 There are proposals to use non-fragmented A6 records in most of the >> places, like ``A6 0 <128bit>'', so that we would be able to switch to >> fragmented A6 records when we find a need for A6. >This hs been suggested as a first step, yes. "In most of the places" >isn't what has been suggested though that I have seen. Using A6 0 for >NS records (which isn't most of anything) has been suggested. Using A6 0 >as the first deployment step for A6 - before we have determined what >costs those potential extra round trips might be (ie: to avoid the FUD >relted to slower name resolution) has been suggested. My text describes what I got from the past IETF presentations and slides. Maybe you right, maybe I'm right. >> From the packet format point of view, the approach has no benefit >> against AAAA. Rather, there is a one-byte overhead to every >> (unfragmented) A6 record compared to a AAAA record. >It also has almost no cost. >> If the nameserver/resolver programs hardcode A6 processing to handle no >> fragments, there will be no future possibility for us to introduce >> fragmented A6 records. >Yes, but that isn't what is being suggested. >> When there is no need for A6 reassembly, there >> will be no code deployment, and even if the reassembly code gets >> deployed they will not be tested enough. >FUD. >We can always do testing. Where lack of testing bites implementations >is with the stuff that no-one thought to test, either because it was >"obvious" that it would work, or because it was some wild case that no-one >ever thought would happen (or thought of at all). A6 reassembly >cerainly is neither of those. Testing it in the lab is trivial. >Getting the bugs out is almost as trivial. How much it actually occurs >in the wild doesn't matter. If we take "A6 0" route, it is highly likely that vendors do not bother to implement A6 chain chasing, or with a buggy reassembly support. These systems will be deployed into the real world, and we will never be able to enable fragmented A6 usage. Therefore, I consider "A6 0" approach be a complete waste of 1 byte per an IPv6 record (you can never transition to fragmented A6 situation so there's no benefit against AAAA). This is not a FUD. If there's no operational needs, people won't bother to implement them. >>3.4 At this moment, end hosts support AAAA records only. Some people would >> like to see A6 deployment in DNS databases even with the lack of end >> hosts support. To workaround the deployment issues of A6, the following >> approach is proposed in IETF50 dnsext working group slot. It is called >> ``AAAA synthesis'' [Austein, 2001] : >This is obviously a transiton method (or likely to be) - though having >stub resolvers that only ever do AAAA, much as we have stub resolvers with >no cache, and no way to do any kind of recursive lookups, with everything >in a back end resolver, is a possibility. Now, can you predict how many people will have cache in stub resolvers in year 2005? In this year, as BIND4/8 resolvers and other non-caching resolver are around, cache deployment in the stub resolver (say, for UNIX and Windows systems) is almost equal to zero. There could be one-entry caching with very short lifetime implemented in some of them, or bad caching mechanisms in applications without TTL handling, that's all. With deployment of PDAs and smaller devices, it is unlikely to see the change of ratio between caching stub resolvers and non-chacing ones. How long did you wait for this? I'm equally worried about A6 fragment reassembly code deployment. >> o Deploy A6 DNS records worldwide. The proposal was not specific about >> whether we would deploy fragmented A6 records, or non-fragmented A6 >> records (``A6 0''). >It doesn't matter for this purpose. That's back to how important avoiding >the FUD with the extra queries is seen to be. There's no need for >everyone to adopt the same approach. I mentioned "A6 0" and "A6 non-zero" this just for clarity. How can you assert it as a FUD? It is not a FUD, you just did not understand (or I did not describe it well). >> o When a host queries AAAA record to a DNS server, the DNS server >> queries A6 fragments, reassemble it, and respond with a AAAA record. >"DNS server" there should really be back end resolver. It is for the >box near the stub resolver to do this, not the server for the zone. Maybe correct. However, when back end resolvers do not implement AAAA synthesis, the AAAA queries will get propagated into servers for the zones. >> The approach needs to be diagnosed/specified in far more detail. >Perhaps. It certainly wouldn't hurt, but I'm not sure it is needed either. >That is, this is really something of a local issue between the stub >resolver and its back end. That could be standardised, but doesn't have >to be. My worry is that, the approach will hurt us if we deploy it without analyzing it in detail before we do so. >Just to show it can be done, I'll give some answers. Not necessarily the >right answers all the time, but plausible ones I think. That's to remove >the FUD that comes from giving a list of unanswered questions, which implies >that all this stuff must be difficult... So in your world unanswered questions are called "FUD"? Did we have consensus for any of the following questions and answers? These questions are left open as (1) it is an analysis draft (2) we don't have consensus for ANY of them. And then you call them FUD? Nonsense. Do we all need to obey your answers as you are the prophet of DNS? >> o What is the DNS error code against AAAA querier, if the A6 reassembly >> fails? >SERVFAIL, the same as when any DNS lookup fails. Maybe, but I'm not sure. I need to hear voice from others. >> o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap >> uses TTL=0] >It almost certainly doesn't matter, stub resolvers tend to have no caches >anyway (whatever the TTL is, it is ignored). But anything between 0 and >the minimum TTL from the A6 fragments combined would work. One of those >two extremes would be most likely. Now you are contradicting with yourself. In the above you have mentioned that there would be stub resolvers with caching, and now you are saying that there will be no stub resolvers with caching. Which one do you mean? I agree that it has to be between 0 and min(TTL of A6 fragments), but for the choice of the value, there's no consensus. >> o Which nameserver should synthesize the AAAA record, in the DNS >> recursize query chain? Is the synthesis mandatory for every DNS >> server implementation? >The first one queried - the same one that does the recursive query work >for the stub resolver. And no, of course not, it is only needed if you >deply stub resolvers that need it (just the same as implementing resursive >lookups in a server). There's no mention in Rob's presentation nor Rob's draft. AAAA queries can get propagated into non-first nameservers at ease, when the first one does not have AAAA synthesis. Given that there are whole lot of DNS servers (1) with AAAA support (2) no A6 support and (3) no AAAA synthesis, it is highly likely that AAAA queries will be propagaged. You cannot blame people for propagating them (or you will blame everyone running BIND < 9.2). >> o What should we do if the A6 reassembly takes too much time? >Same as if chasing CNAME records takes too much time, or NS's don't >respond soon enough, or ... Nothing even slightly new here. Okay, that is one possiblity. >> o What should we do about DNSSEC signatures? >Most likely verify them in the back end resolver, and then (most likely >using TSIG) indicate to the stub resolver that the data is OK. If we >ever get stub resolvers that are doing their own signature validation, >then I think they can be doing their own A6 resolution as well - dnssec >is certainly lots more work than A6... The problem here is, again, with A6 there can be certified bits and uncertified bits within a single 128bit IPv6 address, and it is difficult for us to decide whether the synthesized AAAA record is really trustable or not. The above is just your proposal, not the consensus. >> o What if the resolver wants no synthesis? Do we want to have a flag >> bit in DNS packet, to enable/disable AAAA synthesis? >It just queries for A6 records instead of AAAA. This whole scheme only >makes sense if A6 records are to be the ones selected to be used. That is, >there are no AAAA records in the wild any more. The only sense to ever >query for AAAA is if you are requesting AAAA synthesis. (Of course, in >the short term, you might actually get an original AAAA record, but that's >just a transitional artifact). This part you don't have a concrete answer so I'll wait for others to add more opinions. >> o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query >> timeouts, and other timeout parameters? >This looks to be some (most) of the above points, simply restated more >briefly. Without an answer/consensus we cannot implement AAAA synthesis right. >> The approach seems to be vulnerable against DoS attacks, because the >> nameserver reassembles A6 fragments on behalf of the AAAA querier. >FUD. There is nothing different here from any case where a back end resolver >does all the work and then hands the final result of the query back to the >stub resolver. This is not a FUD. A6 makes the problem more apparent, and is slightly different from other resource record types. >>3.5. Issues in keeping both AAAA and A6 >Did anyone actually suggest doing that? It makes no sense at all. If we >adopt A6, then anyone who prefers the AAAA style, simply uses A6 0, that >gives them all they would ever get from AAAA (at the cost of 1 byte per >A6 0 record returned). (snip) >The rest of section 3.5 is just more FUD induced by not suggesting a >more sensible method of dealing with an environment that will never >exist (other than for a shortish transition period) anyway. Yes there is such an approach proposed. Rob Austin's transitional approach (endnode resolvers use AAAA and DNS servers use A6) is one of them. You just did not understand the problem and asserting it as a FUD. Not fair. >>4 Some says that there will be more frequent renumbers in IPv6 network >> operation, and A6 is necessary to reduce the zone modification cost as >> well as zone signing costs on renumber operation. >That is an argument, yes. >> It is not clear if we really want to renumber that frequently. >How often we want to renumber is not really relevant. We don't want to >renumber at all. What matters is how often we need to. We don't know. >We might not know for another 20 years. Thanks for wording pickiness, but I don't think the change is necessary. >> With >> IPv6, it should be easier for ISPs to assign addresses statically to the >> downstream customers, rather than dynamically like we do in IPv4 dialup >> connectivity today. >Probably true, as there are more IPv6 addresses (plenty) and so there sho= >uld >be much less need to share addresses. (snip) >But this kind of renumbering has never been what we're trying to deal with >(or not very much) - nodes that only get dynamic addresses when they dialup are almost never in the DNS to start with - A6 affects only renumbering >the DNS, so those nodes/sites aren't the ones of interest. >So, this whole line of argument is achieving nothing at all. The rest of >this paragraph adds nothing. So you are objecting to write down something obvious to you? Then what's the point in compiling list of "host requirement" which has batch of duplicated text from other RFCs? I don't see your point. Nonsense. >> It is questionable if it is possible to renumber IPv6 networks more >> frequently than with IPv4. >FUD. >In any case what counts here isn't what is possible right now, but what >we should be aiming at producing. What would be the ideal outcome? I don't agree that it is something we should be aiming. >> Router renumbering protocol [Crawford, 2000] >> , IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998] >> can help us renumber the IPv6 network, however, network renumbering >> itself is not an easy task. >FUD. But it even contradicts the previous paragraph, all of that stuff >from the first 2 lines makes IPv6 renumbering easier than IPv4, and if it >is easier it can (not necessarily will) be done more often. Not a FUD. The above statement is totally correct, and you are asserting it a FUD. >> If you would like to maintain reachability >> from the outside world, a site administrator needs to carefully >> coordinate site renumber. >True. So? So again you are objecting to document something obvious to you. Rediculous. >> The minimal interval between renumber is >> restricted by DNS record timeouts, as DNS records will be cached around >> the world >True, which is why working on the DNS wrt renumbering is relevant in the >first place. That is, to enable frequent renumbering we need to keep the >DNS TTL low. But a low TTL has negative effects on caching. That's where >A6 has benefits - the low TTL can be on just the few A6 records at the >higher level (the upper bits of the addresses). Lower bits change rarely, >and can have much longer TTLs. Whether this is 1 day and 1 month, or >1 hour and 1 day, or 1 minute and 1 hour (or 1 minute and 1 month) doesn't >matter. I'm questioning if it is necessary to renumber that frequently, and introduce very high complexity and overhead for normal case ("optimized for write"). Could you prove that we need higher frequency of renumber? >> A6 was designed to help administators update zone files during network >> renumbering events. Even with AAAA, zone file modification itself is >> easy; you can just query-replace the addresses in the zone files. The >> difficulty of network renumber comes from elsewhere. >That's certainly true. But if you're thinking of A6 as some kind of >weird macro processor for the zone file, then it is no wonder that you >don't think of it as being useful. That is certainly not where its >benefit lies. Then what is A6 really? Describe me in 10 words. For me, after doing the analysis, it is "overly complicated alternative of AAAA with less benefit". >> With AAAA, we need to sign the whole zone again with DNSSEC keys, after >> renumbering the network. With A6, we need to sign upper bits only with >> DNSSEC keys. Therefore, A6 will impose less zone signing cost on the >> event of network renumbering. >Yes, this is one (comparatively minor really) A6 benefit. >The DNSSEC issue of greater import is that only those parts of an organisation >concerned with the renumbering need to go update their records, and re-sign >them. Eg: if a university gets a new link, and adds a new prefix, then the >university prefix A6 record would be updated, and all of the departments would >get that new prefix applied to all of their addresses in the DNS, without >any of them having to re-generate anything at all. That's where the benefits >really start to acrue, not in the saving of a few hours of CPU time (though >that's not completely irrelevant either - if it takes too long to sign a >zone file, sites won't do it, or won't do it in a secure manner). Yes it is a benefit of A6, however, from the experiment result from Bill Sommerfeld and othres, I believe it is not big enough to amend the complexity of A6. >> As seen above, it is questionable if we >> renumber network that often, so it is questionable if A6 brings us an >> overall benefit. >FUD. No. Prove that we need to renumber so often that we can amend the complexity of A6. >> Note, however, even if we use A6 to facilitate more >> frequent renumbering and lower signing cost, all glue records has to be >> installed as non-fragmented A6 records (``A6 0''), and required to be >> signed again on renumbering events. >This is very likely true, though I haven't actually done the analysis to >prove it is actually necessary - but in any case, there are small handfuls >of such things (the University of Melbourne probably has about 20 glue A >records for the whole institution...) Prove it and drop me a note when you're done. >5. Security consideration >Sect 5 before 5.1 is a simple restatement of stuff already covered. >I won't go through that again. Essentially all FUD. Because previous sections are not FUD, 5.1 is not a FUD too. >> Note, however, this problem could be considered as a problem in >> recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA >> synthesis makes the problem more apparent, and more complex to diagnose. >The first clause there is true, I'd like to see some evidence for the >second one, without that it is just more FUD. I described them in the draft and you did not get it, and you assert it as a FUD. How nice. >> To remedy this problem, we have a couple of solutions: >> (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the >> problem goes away. >No it doesn't, only this particular way of causing it. A6 makes the problem more apparent, so if we don't have A6, we have the same amount of problems as today. What are you trying to mean? >> (2) Even if we use A6, do not configure nameservers for AAAA synthesis. >> Deployment issues with existing IPv6 hosts get much harder. >Something still has to build the 128 bit address out of the A6 fragments, >if we're using A6. That can be called "AAAA synthesis" (the work is all >identical) regardless of whether a RR with the AAAA type is ever actually >produced. Thus this would make no difference at all - there's no benefit >at all to be gained by prohibiting back end resolvers from doing AAAA >generation for their stub resolvers from this line of argument. You must give analysis to "A6 0 synthesis", otherwise your word is considered a FUD under your rule. >> (3) Impose a protocol limitation to the number of A6 fragments. >This might be a good thing to do. But even if we don't, any rational >implementaton is going to do it anyway. Okay. >> (4) Do not query the expired records in A6 chain again. In other words, >> implement resolvers that ignore TTL on DNS records. Not sure if it >> is the right thing to do. (snip) >This has some perhaps unusual effects when we have TTL's that are very >small, but that's OK. After all, if you're worried about records with >TTL 1 expiring before the rest of the answer is obtained, how do you >justify dealing with records with TTL 0 at all? Those would be nominally >expired while the packet that contains them is en route to the resolver >(no matter how close it is). Thus, by this theory, the trivial >infinite loop DNS DoS attack would be > www 0 IN A 1.2.3.4 >as soon as the resolver gets that, it sees it has expired, and so has to >go fetch it again... This one bothers no-one, nor will the A6 cases. (4) maybe a leftover from the previous revision of the draft. Sorry about it. >>6 Conclusion >Since there is nothing in the doc that actually provides any real information, >other than FUD, drawing conclusions from it isn't going to be easy. I presented real information and you just did not understand. Also, it is a FUD to say "there is nothing in the doc" while you are agreeing part of the document (see some of the comments *made by yourself*). >> A6/AAAA discussion has been an obstacle for IPv6 deployment, as the >> deployment of IPv6 NS recodrs have been deferred because of the >> discussion. = >This one I can't dispute - the discussion might very well be delaying >deployment in some places. We still need to get it right, this really >isn't a case where any answer will do, even the wrong one. Tossing a >coin isn't a good solution here. We need more experience, and at >least some data. Do you have an expected date to get more experiences and data? >> The author do not see benefit in keeping both AAAA and A6 records >No, nor do I (except perhaps for stub-resolvers - ie: keep the RR type, >but deprecate its use in zone files). So we should drop Rob's "AAAA synthesis" from the candidates. >> Given the unlikeliness of frequent network renumbering >There's no evidence for that. Only for renumbering being difficult >to achieve. That something is hard doesn't mean that we won't be >forced to do it. I have already discussed, in the earlier part of the draft, that the frequency of renumbering is not likely to be high. I felt that the discussion should have been enough to lead to the conclusion, so I did that. Now, if you are asked to prove it, how can you prove this? The way of discussion is not correct - you are asking for an evidence for something noone can really prove, and because of that you are asserting that the draft is a FUD. Total nonsense. >> the author believes that the A6's benefit in lower zone signing >> cost is not significant. >I think it is significant, I'm not sure that it alone would be compelling, >But the stright CPU costs to sign zones are only one of the issues. Now its my turn. Can you prove that the signing cost difference is significant? For what kind of zone file structure? For what kind of situation? Can you cover all the cases we would possibly encounter? >> From the above discussions, the author suggests to keep AAAA and >> deprecate A6 (move A6 document to historic state). >That's OK, that's just an opinion (as the note at the beginning of >the section makes clear). Yes. >> The author believes >> that A6 can cause a lot of problem than the benefits it may have. >That this is believed is quite likely correct. But before we take any >notice, we really need some kind of evidence. Agree in general, but I think I saw enough evidence from our experimental operations as well as analysis (like this draft). And you did not present any evidence either. >> A6 will make IPv6 DNS operation more complicated and vulnerable >> to attacks. >This is FUD. >> AAAA is proven to work right in our IPv6 network operation since 1996. >> AAAA has been working just fine in existing IPv6 networks, and the >> author believes that it will in the coming days. >And this is the warm fuzzy alternative. No it is not FUD. You cannot assert like this. If you say "I did not understnd this" or "I think this part is not correct", I can accept those. Asserting someone's draft a FUD is not fair and unproductive. >For something to do in the immediate future, invent the ANYA meta-query >record, have it return A AAAA and A6 records, get back end resolvers doing >that, and creating AAAA records for stub resolvers that do AAAA requests. >That way, either AAAA or A6 records can be deployed, which allows sites >to start sticking in A6, while not breaking those still doing AAAA lookups, >and without requiring everyone to do lookups of both (and throwing in >free IPv4 answers to the local cache as a side benefit). No new inventions, please please. It can only hurt the deployment more. >Apologies for the length of this message, I hope not too many people have >reached this far in processing it (unless you skipped all the middle bit), >It really would have been better to not have needed to send it at all. Well, now you need to go through my comments again. A bad day for you. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 2 03:30:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72AUBW17599 for ipng-dist; Thu, 2 Aug 2001 03:30:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72AU5D17590; Thu, 2 Aug 2001 03:30:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08550; Thu, 2 Aug 2001 03:29:59 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04205; Thu, 2 Aug 2001 04:31:03 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f72APer02021; Thu, 2 Aug 2001 17:25:43 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <11603.996735329@itojun.org> References: <11603.996735329@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Aug 2001 17:25:40 +0700 Message-ID: <2019.996747940@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 02 Aug 2001 15:55:29 +0900 From: itojun@iijlab.net Message-ID: <11603.996735329@itojun.org> | Now I can respond to your comments, I'm very happy. First of all | I would like to thank for all the comments for all the paragraphs | (just for clarification - even if people don't agree with each other's | opinion, it is Japanese custom to thank for the effort itself in | the first place. "thank you" does not mean that I agree with you). OK, and thank you for the response. | Please note that, in i-d, there could be issues with my English skills | (like I'm asserting something I did not mean to assert, or I write | "must" where I should have used "may"). I think I understood it all OK, and I am pretty sure that none of my comments related to the wording (alone). | In short, I cannot believe how can you assert these problems as | just "FUD". This way there will be no progress. Not from that doc (nor from my response), that's true. That's why I really didn't want to go through all of this line by line - there's almost nothing of value to be gained from it. | In your comment it seems that you are using the word "FUD" for | "unanswered questions". I don't understand your choice of word, and | I really really object. Oh. "FUD" is "Fear Uncertainty and Doubt". Unanswered questions are uncertainty - one of the principal attributes of FUD. That is, "here are all these things we don't know (uncertainty), all kinds of things might go wrong (fear), we aren't sure this is right (doubt)". That's exactly what FUD is. I should have made that clear before, sorry. That is, FUD is an argument which goes along the lines of "we don't really understand this, so let's not do it". | Also, you are asking for evidence multiple times, for something noone | can possibly prove. I don't think that's so. I think that evidence can be collected. | This way of discussion is unfair, and I'd like | to ask you to try to prove them by yourself while I think about | them too. Yes, that is what I want to do. As I said, my response doesn't add anything to the debate about which of A6 and AAAA is best to use - all it was intended to do was to point out that your draft doesn't either. That's why I really didn't want to waste everyone's time with a lengthy message. | You also wrote some text that can be considered a FUD under your rule, That might be true too. | I don't feel the need to put multiple addresses onto the example here, | since in the following sections we don't use them much. Yes, I understand ... but also since it isn't used much, you could also have given a much simpler example - more along the lines of what a net with just a few nodes would actually use. Not that this matters much. | >> If we are to resolve IPv6 addresses using fragmented A6 records, we | >> need to query DNS multiple times to resolve a single DNS name into | >> an IPv6 address. | >should be "we might need to query". | | do you include "A6 0" case into "fragmented A6 records"? if so, | I can understand your wording change. Otherwise, I don't get it. No, I mean a response like A.MY.EXAMPLE. IN A6 64 B.MY.EXAMPLE. B.MY.EXAMPLE. IN A6 48 C.MY.EXAMPLE. C.MY.EXAMPLE. IN A6 0 . That is, we still have fragmented A6 records, but they're all from the same zone, and hence all can be included in the same response packet. No extra queries, no extra delay, and a packet that might be bigger and might be smaller, depending upon just what data is being included (or if you like, how many RRs actually exist in the RRsets for each of the 3 names above). This is the kind of usage I'd actually expect A6 to see - rather than having the domain names sprayed around all over the place, which is theoretically possible, but not really very likely in practice. | How can you ignore part of my text ("of the address itself") and assert | the lines as "not true"? This is totally unfair. A6 is the only | resource record type that composes a single address itself from | multiple query results. It is true. Yes, but it is irrelevant - it is just provoking fear. The technique of chasing DNS chains to get answers is as old as the DNS itself. | Again, I did not include "A6 0" into "fragmented A6 records" case. Nor did I. | This problem is not new but I believe it worth mentioning it. | If I do not mention it, readers would mistakenly think that it is | possible to parallelize the queries for A6 fragments. It is OK to say that, but you should also make it clear that it isn't new. Otherwise readers might mistakenly believe that this is some new problem that has never existed before. | Do you have problem with it? If I cannot things that are not new | how can I write up an analysis document. You need to make sure that you're not raising evils, which when investigated turn out to be just the same as what we have already, and which when viewed in that light don't look nearly as problematic. That is, almost all that you're worried about being possible with A6 is just as possible with A6. Yet in practice none of it actually bothers anyone. There should be a lesson in that. | With A6 the problem is more apparent as it is the only resource record | type which composes a single address out of multiple query results. Apart from being new (fear, doubt...) what's supposed to be significant about that? | For example, you can get a completely different IPv6 address out of | multiple queries, if you get part of A6 chains swapped with other item. | Assuming that this one is correct: | A6 64 ::t:u:v:w | A6 48 ::s:0:0:0:0 | A6 0 p:q:r:: | now if you get "A6 48 ::x:0:0:0:0", you will have a whole lot of fun. This is djb's argument - it is possible to configure A6 and blow yourself away. This is also not new to A6. It applies to lots of the DNS. Step back and look at your arguments more carefully, and you'll see that almost all of them could be made against using the DNS at all - except that the DNS is now familiar, everyone is used to it, and that it generally works pretty well, so it is much harder to be worried by anyone showing that in theory all kinds of things could go wrong. | The problem had not been obvious with other resource record types. | For other record types, we would get a completely correct answer, | or completely hosed answer. With A6 we would get a partially | correct answer (incorrect bits within a part of 128bit address). That's a completely hosed answer. This is no different than a CNAME chain that is accidentally pointed at the wrong place somewhere in the middle. That in the A6 case the bits returned happen to be built out of pieces returned from different records is really irrelevant - other than that it is new (fear of the unknown). | No, this is not a FUD. You are mixing up two different issues. | Because A6 is the only resource record type which composes a single | address out of multiple query results: | - for other record types, the result is binary - completely believable | or not. | - for A6, the result is not binary - part of bits can be believable, | part of bits can be not believable. No, this is nonsense. Either you get the right answer, or you have the wrong one. However many bits of the wrong one would have been correct under other circumstances is irrelevant. | This is from our implementation experiences. There are very few | people out there (I believe) who have actually implemented A6 | reassembly/decoding code, so I believe it worth mentioning. Try it | by yourself and see how many mistakes you will make due to the | bitwise manipulations. I didn't ever say that the code was easy to get right. What I said was that this is irrelevant. This code will only be written a handful of times through eternity. And while it might take a while to get right those few times, in the overall scheme of things, it simply doesn't matter. I have faith in your ability to debug the code, and to get it right... | No. Try to implement it into libc resolver (like BIND8) and | experience the pain we had. It isn't clear to me that a dumb resolver (like the libc one) should ever be doing this, or doing DNSSEC validation, or anything else like that. The very existence of such a thing is really an accident of history. The bind9 lwresd approach (in one form or another) was what was envisaged when the DNS was designed (a resolver/cache that all applications would share, rather than one that exists just for the purpose of a single name lookup, or two, after which it vanishes leaving no history). | Bitwise operations are so much more painful than 8-bit boundary | operations. Sure, but you do them, get them right, and forget them. | But how can you enforce that? Resolver side can protect themselves | by using the upper-limit, however, it is not possible to avoid | longer-than-limit A6 chains be placed onto the DNS zone files. No, it isn't. Nor is it possible to prevent CNAME chains that loop forever in the DNS zone files, or NS record chains that go on forever (consider a set of NS records each of which is 63 levels down some completely unrelated tree...) The point is that none of this is new - it is not something that we need to worry about specifically - we can already see from operational experience that it is perfectly possible to define things in such a way that they do work. Now if you were able to point to something in the A6 spec which guaranteed that these kinds of problems must occur, then you'd have a valid point. But just saying that it is possible for people to create stupid configurations is just causing fear - what matters is that it is possible to create configurations that have no problems. Or, if the point was that it is possible to create configurations that others could never escape from (ie: that it really is possible to create new DoS attacks) that would also be a valid point - but as you concede above, resolvers can easily protect themselves from this. | A6 fragments are likely to be maintained by different administrative | domains. "Likely"? Says who? | It is not likely that a single admin to control over the | whole A6 chain (otherwise, there's no benefit of A6 chain). Actually, I think it is likely, and there's lots of benefit from that. There are other possible benefits from allowing others to control the upper parts, but there are also costs in doing that. Until we get some operational experience with this, we simply don't know what is going to be reasonable to do, and what isn't. | If you define upper bits (than the part that have assigned to you, | like less than /48) you become less ready to renumber events. Of course. But that's what the policy that you postulated mandated. There are plenty of other ways to set things up to avoid that, and still keep A6, and still avoid building in addresses, what is going to be good to use in any particular case will depend upon the particular circumstances. | Therefore, the former one in your example will jeopardize the | renumbering benefits of A6. The latter one is better, however, I don't | think it manageable (can you prove it is manageable for random dumb | admins like me?). No, and even ignoring the "random dumb admin" comment, which I don't think applies to you at all, if you're not happy with configuring A6 fragments in a way that will work for you, for any reason at all, then you can just use A6 0, and you have essentially the same as you would if AAAA was all that was used. What this argument essentially amounts to is "I don't see the need for A6 for myself, I don't think I could use it, therefore you aren't allowed to use it either". I don't think I'll have any trouble at all configuring A6 in a way that will work just fine for me, and unless you can show some problem that I will cause to you by so doing, I'd appreciate it if you'd just allow me to do that. | If we take "A6 0" route, it is highly likely that vendors do not | bother to implement A6 chain chasing, or with a buggy reassembly | support. We just do some interop testing. Just as we have done for lots of other stuff in IPv6 (and elsewhere) which isn't really all that likely to be deployed in the real world very much (or not immediately). There's nothing new about this - there was a bunch of interop testing done for DNS dynamic updates for example, which uncovered a whole host of bugs in various implementations, long before anyone in the outside world was going anywhere near dynamic DNS. | These systems will be deployed into the real world, | and we will never be able to enable fragmented A6 usage. Therefore, | I consider "A6 0" approach be a complete waste of 1 byte per an | IPv6 record (you can never transition to fragmented A6 situation | so there's no benefit against AAAA). This is not a FUD. If there's no | operational needs, people won't bother to implement them. I still think you're misinterpreting the "A6 0" approach. It isn't that we tell everyone that they must use only "A6 0", and hence implementors need implement only that - it is that we tell people that they can use "A6 0", it will work 100% identically to AAAA (once A6 resolvers exist at all), and hence is perfectly safe to do. No-one will be melting down the internet with all the extra queries, or setting up names that no-one else will be able to use, or ... But anyone who wants to try it will still be able to use A6 n. | Now, can you predict how many people will have cache in stub resolvers | in year 2005? No, but that's also so near term as to barely be worth it anyway. (But my definition of a stub resolver is one that doesn't have cache, or recursive abilities, etc, anyway, so perhaps I can predict 0 as the answer using that definition.) | In this year, as BIND4/8 resolvers and other non-caching | resolver are around, cache deployment in the stub resolver (say, | for UNIX and Windows systems) is almost equal to zero. Yes. This was exactly my point in my response to your fears about what happens to people who define their A6 records with minute TTLs. | How long did you wait for this? No idea. Perhaps forever - it could be that we always have dumb stub resolvers, and back end resolvers. That might mean AAAA synthesis at that level forever. But so what? Who cares where it is done, the 128 bits of address have to be collected together somewhere. | I'm equally worried about A6 fragment reassembly code deployment. ie: I don't know that it is going to happen, hence we can't rely upon it. That's FUD. If you could show some reason why it will not happen, that would be different, but you can't (or aren't) - only that you aren't sure that it will. | I mentioned "A6 0" and "A6 non-zero" this just for clarity. How can | you assert it as a FUD? It is not a FUD, you just did not understand | (or I did not describe it well). Whether with AAAA synthesis the A6 records collected are A6 0 or A6 n makes no difference at all. But raising points of uncertainty makes the proposal look flawed. It isn't when the answer simply doesn't matter. That is, the only point for mentioning this is to increase the fear. That may not have been what you intended, but it is the outcome. | Maybe correct. However, when back end resolvers do not implement AAAA | synthesis, the AAAA queries will get propagated into servers for the zones. Yes, that's true. Most likely, to handle this, in the near term, sites will include both AAAA and A6 records for any names that they expect to be looked up by random others, where it isn't clear whether an AAAA or A6 query will arrive. That is, I'd do that for my mail server, FTP server, web server, etc - but I wouldn't bother for all my workstations, etc, as the only people I care about being able to find their addresses are local, and locally I know (or will know) that A6 records will work. This is just the same as what happened when MX records were introduced. Initially, everyone had to have A records for their mail domain as well as an MX record that indicted the server (and which would have had an A record). That was because mail servers (SMTP clients) were used to simply looking up the A record, and the simple deployment of MX records wasn't going to change that overnight. Today however, MX records exist all the time with no A record for the same name - and even worse, which will not have an analogy with AAAA->A6, there can be an A record at the same node as an MX record, where the address given has no idea how to handle mail for the domain. That is, all the SMTP clients that only do A lookups rather than MX, have been delegated to the dust heap, if any still exist anywhere, they're so locked down as to be completely irrelevant to anyone. | My worry is that, the approach will hurt us if we deploy it without | analyzing it in detail before we do so. I have no problem with that - I believe more work needs to be done on analysing A6 setups, and how well they will work. However, there's no point at all doing that if before it is finished, someone (some group, even the wrong group, like ngtrans) decides not to bother waiting for the analysis, but to simply abandon A6 and keep AAAA, because it is the safe familiar way. What would be the point of even starting collecting any data if that is likely to be the result? | So in your world unanswered questions are called "FUD"? No, just unanswered questions whose point is to remain unanswered, and thus just raise the fear of the unknown. | Did we have consensus for any of the following questions and answers? No, of not that I know of - all I gave were some plausible answers, not necessarily the right ones. I thought I made that clear in my message. That is, my objective was to remove some of the fear (no more than that). | These questions are left open as (1) it is an analysis draft (2) we | don't have consensus for ANY of them. And then you call them FUD? Yes, when the result of them being left as open questions is "suggest that A6 be abandoned". If your point had simply been that we still have things to do before we can deploy A6, then I wouldn't be objecting, I'd be agreeing. But that wasn't your point - it was to have A6 made historic (it's there in the draft...) | Do we all need to obey your answers as you are the prophet of DNS? Of course not, we need to get answers. But for that to make sense, A6 needs to still remain as the DNS record intended to be used. That is, there has to be some point to bother finding the answers. | Now you are contradicting with yourself. In the above you have mentioned | that there would be stub resolvers with caching, and now you are saying | that there will be no stub resolvers with caching. Which one do you mean? stub resolvers are the dumb things with no caches. If I ever said anything different to that, it was an accident. | I agree that it has to be between 0 and min(TTL of A6 fragments), but | for the choice of the value, there's no consensus. My point was that it simply doesn't matter. DNS implementations have always been free to send any value as the TTL smaller than the max permitted. Older versions of BIND actually used to multiply the TTL left by some constant (I forget what, for this, assume 0.8 or something) whenever an RR was taken from the cache. That was perfectly legal. It resulted in decreased cache effectiveness of course, but also make it easy to get rid of bad data from someone's cache (just query it lots of times and the TTL would quickly reduce to 0). The same is true here, you can use any TTL you like, up to the max that makes sense, there doesn't need to be a consensus. And that's without relying on the stub resolvers ignoring the TTL you send anyway (which would not be good to rely on, even though it is most likely true). | There's no mention in Rob's presentation nor Rob's draft. Rob's draft (assuming you mean the one which is on the agenda for this discussion) is a bunch of open issues. I didn't hear the presentation. So, that's no surprise. | AAAA queries | can get propagated into non-first nameservers at ease, when the first | one does not have AAAA synthesis. Given that there are whole lot of DNS | servers (1) with AAAA support (2) no A6 support and (3) no AAAA synthesis, | it is highly likely that AAAA queries will be propagaged. You cannot blame | people for propagating them (or you will blame everyone running BIND < 9.2). I think this is the same thing I answered above. Of course I don't blame anyone - but please be clear to separate out the two issues here. The first is the way that IPv6 records ought to be looked up in the ideal IPv6 internet. And the second is how we get to there from where we are now. Only if the second one says "no way, impossible" should we take much notice of that when answering the first question. | The problem here is, again, with A6 there can be certified bits | and uncertified bits within a single 128bit IPv6 address, and it | is difficult for us to decide whether the synthesized AAAA record is | really trustable or not. No, if any of it isn't trustworthy (authenticated) then all of it is unauthenticated. That much is certain. | The above is just your proposal, not the consensus. As I said (in the first reply, and again this time), that is absolutely correct. "Just a few plausible answers". | Without an answer/consensus we cannot implement AAAA synthesis right. No, that isn't correct. That would be saying that we can't implement A6 correctly, and that simply isn't correct. The only extra parts with AAAA synthesis are the TTL (which as long as it is within bounds is correct, whatever value is picked) and DNSSEC. The latter is simply impossible, the resolver inventing the AAAA record out of pieces can't possibly also invent a SIG record for it (no matter whether or not it gets and verifies SIG records for all of the A6 fragments). If the stub resolver really wanted the SIGs so it could do its own validation of the answers, then it is really going to have to get the A6 fragments and validate those. But as A6 handling is certainly easier than DNSSEC, that shouldn't pose too much of a problem. Where the back end resolver is telling the stub resolver that the data is authenticated in some other way than sending a SIG record (eg: if it is using TSIG) then it say say "authenticated" the same way it would in any other answer (but only if *all* the A6 fragments were authenticated of course). | This is not a FUD. A6 makes the problem more apparent, and is slightly | different from other resource record types. No it isn't. It is all just the same. The only difference is that you're looking for evidence against A6, and we don't get have any operational experience that says that this matters no more to A6 than it does to anything else - so it is a good way to raise the fear levels. | Yes there is such an approach proposed. Rob Austin's transitional approach | (endnode resolvers use AAAA and DNS servers use A6) is one of them. No, that's a different thing entirely. We can keep AAAA queries, without keeping AAAA RRs in the zone files. What makes no sense is to keep AAAA in the zone files, and also allow A6 0. (Of course, as a transitional aid, servers could read "AAAA" in a zone file and build "A6 0" out of it, provided that the zone signer does the same thing, where dnssec is in use). | Thanks for wording pickiness, but I don't think the change is necessary. This one isn't just working pickiness - it is a fundamental point. How often we'd like to have to renumber, and how often we actually will have to renumber are not necessarily the same thing, or even related. What we're supposed to be doing (what we set out to do way back when ipng first started) is to remove as many impediments to easy renumbering as possible. That is, every time we find something that looks like it will cause problems, we look for a solution that will allow those problems to be avoided. We don't simply say "there's this other problem that isn't solved yet, so there's no point doing anything about this one" - that's defeatism. We can do better than that - but we have to keep working on each problem, each little obstacle to renumbering, as we find it. | So you are objecting to write down something obvious to you? No. I'm objecting to using something which is obvious, but irrelevant, as an argument. | >In any case what counts here isn't what is possible right now, but what | >we should be aiming at producing. What would be the ideal outcome? | | I don't agree that it is something we should be aiming. You mean that we should simply give up on making renumbering easier? | Not a FUD. The above statement is totally correct, and you are | asserting it a FUD. Yes. Most FUD is correct. That's how it works. What it is, when analysed, is irrelevant. That's what that was. | So again you are objecting to document something obvious to you. No, again, just to its use in an argument where it carries no force. This is more bad style - throw in all kinds of stuff that everyone agrees with, in the hope that they'll just go on agreeing when you get to the issues which aren't so clear. Its a standard trick. | I'm questioning if it is necessary to renumber that frequently, My point is that we don't know. And we won't know, for ages. 20 years ago we would have said it was never necessary (for external reasons) to renumber an IPv4 net. But things have changed since... What we need to be doing now is planning for the possibility that you might be wrong. If you're right, the cost will have been small (or that's the way it looks to me at the minute - we still need data to determine that one way or the other). On the other hand, if you're wrong, and we go your way and assume that you're right, the cost might be huge. | and introduce | very high complexity and overhead for normal case ("optimized for write"). I disagree with the complexity and overheads - but just like you, I have no data to back up my guesses. But I am planning to collect some data. | Could you prove that we need higher frequency of renumber? No, of course not. Nor can I (or you) prove that we won't need it. I prefer to plan now for the possibility, so it it happens we'll be able to cope without years more of deployment effort. Or at least, as much as can be done without huge costs. | Then what is A6 really? Describe me in 10 words. For me, after doing the | analysis, it is "overly complicated alternative of AAAA with less benefit". It is v6 addresses with increased notational and operational flexibility. | Yes it is a benefit of A6, however, from the experiment result from Bill | Sommerfeld and othres, That concentrated only on the CPU overheads, you ignored the operational overheads. | I believe it is not big enough to amend the complexity of A6. I don't believe that A6 needs to be complex. It is certainly simpler (though different) than the DNS SRV record (which has weights, and probabilities, and references to other names, ...) but which is being deployed now. You can certainly make it complex, and you can dream up all kinds of foul looking configurations that no-one will ever understand. I don't care. I can do a clean A6 config for my environment, that's all that matters to me. | Prove that we need to renumber so often that we can amend the complexity | of A6. As above, I can't prove we need to renumber, nor can you prove that we won't (ever). But I can, and intend to, measure the complexity and overheads of A6 (the necessary complexity in particular). | Prove it and drop me a note when you're done. You mean prove that the University of Melbourne only has a small handful of glue records? I could do that easily enough, but what would be the point? | >The first clause there is true, I'd like to see some evidence for the | >second one, without that it is just more FUD. | | I described them in the draft and you did not get it, and you assert it as | a FUD. How nice. There was no evidence in the draft that A6 and AAAA synthesis makes the problem more apparent, and more complex to diagnose. which was the 2nd clause referred to. Just the assertion of that. As you keep asking me -- prove it. Without the proof, or even any suggestion of some evidence to suggest it, all you're doing is raising the fear level. ie: FUD. | >> To remedy this problem, we have a couple of solutions: | >> (1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the | >> problem goes away. | >No it doesn't, only this particular way of causing it. | | A6 makes the problem more apparent, so if we don't have A6, we have the | same amount of problems as today. What are you trying to mean? You said "the problem goes away." What I meant was that no, it doesn't. Sure, if we had no A6 then there'd be one less way to cause it. If we had no CNAME, there'd be another way less. If we had no MX, there'd be another way less, if we had no NS, there'd be another way less. Let's just rid ourselves of the DNS completely, then this problem is really gone ... Is that seriously the argument? | >> (2) Even if we use A6, do not configure nameservers for AAAA synthesis. | >> Deployment issues with existing IPv6 hosts get much harder. | >Something still has to build the 128 bit address out of the A6 fragments, | >if we're using A6. That can be called "AAAA synthesis" (the work is all | >identical) regardless of whether a RR with the AAAA type is ever actually | >produced. Thus this would make no difference at all - there's no benefit | >at all to be gained by prohibiting back end resolvers from doing AAAA | >generation for their stub resolvers from this line of argument. | | You must give analysis to "A6 0 synthesis", otherwise your word is | considered a FUD under your rule. I'm not sure what you're getting at there, but perhaps I can try to be clearer. Note that what I am trying to do is to allay the fear, so I seriously hope that my statements aren't FUD... But also note, nothing in this message, or the previous one, in an argument in favour of keeping A6, or that's not how the messages are intended - which is why there's almost no point in anyone reading them, there is very little affirmative point here (which is why I didn't want to start this in the first place). My only point is to show that your draft is not a valid argument against A6. There might be others, and AAAA might still turn out to be the answer, but your draft does nothing to advance that case. But, your point above was that one way to avoid the DoS problem would be to not do AAAA synthesis (and then, from that, to show that no-one would be able to use A6 anytime soon without it, and so deploying A6 would be useless). The fallacy is in assuming that AAAA synthesis has anything to do with the DoS attack you're describing at all (that is AAAA synthesis in the way proposed, which is so dumb stub resolvers don't have to learn about A6 records). That's simply false - something has to compose the 128 bit address out of the A6 fragments, any DoS attack that was available against the back end resolver doing AAAA synthesis would be available in exactly the same way against any smart A6 capable resolver. Adding in the back end resolver doing AAAA synthesis doesn't change a thing. Hence eliminating that also doesn't fix anything, hence there's no reason to eliminate the back end resolver, and thus, that stub resolvers only know AAAA today, and need to get back AAAA, doesn't matter - AAAA synthesis can happen. I have no idea what "A6 0 synthesis" is supposed to refer to. | I presented real information and you just did not understand. I think I understand it all. | Also, it is a FUD to say "there is nothing in the doc" while you are | agreeing part of the document (see some of the comments *made by yourself*). There's lots of truth in the doc, there always is in an argument based upon FUD. What there isn't is any connection between the truth and the conclusion reached. That all relies on the fear of the unknown. | Do you have an expected date to get more experiences and data? No, but soon. I had hoped to have a draft written for London (the current IETF), but it just didn't happen. A few months would be about the limit though (I hope). I have some resources to devote to doing this, but not huge amounts. Of course, anyone else is welcome to go actually do some tests, and collect the data as well... | >> The author do not see benefit in keeping both AAAA and A6 records | >No, nor do I (except perhaps for stub-resolvers - ie: keep the RR type, | >but deprecate its use in zone files). | | So we should drop Rob's "AAAA synthesis" from the candidates. no, you didn't read what I said. What I said was "deprecate its use in zone files" (it being AAAA). That is, still allow AAAA queries, and AAAA responses, but all the data in AAAA responses (after a transition period, of course) will have come from AAAA synthesis. | >> Given the unlikeliness of frequent network renumbering | >There's no evidence for that. Only for renumbering being difficult | >to achieve. That something is hard doesn't mean that we won't be | >forced to do it. | | I have already discussed, in the earlier part of the draft, | that the frequency of renumbering is not likely to be high. You asserted that. You hope that it will be true. But we simply have no way to know what will happen in the future, do we? That's my point, that we don't know (and yes, there's some FUD in this). | Now, if you are asked to prove it, how can you prove this? | The way of discussion is not correct - you are asking for an evidence | for something noone can really prove, I am asking for evidence before you rely on it to prove a point, yes. If you can't collect the evidence, then neither can you rely upon the conclusion. | and because of that you are | asserting that the draft is a FUD. Total nonsense. Yes, you're speculating on how complex A6 must be (using the worst case scenarios) and speculating on how little benefit it will be (assuming the best possible scenarios), and from that concluding that A6 isn't needed. | Now its my turn. Can you prove that the signing cost difference is | significant? I thought that had been done already... But if you like, I can take one of the zones I serve (it has something like 200K names in it, I don't know how many RRs that translates into) and run the bind 9 signer on it on one of my DNS servers (that's a SS5 85MHz incidentally - NetBSD) and after however long it takes, post the numbers. Do I really have to do that? What would it achieve? Everyone already knows that it is going to be a big number... | For what kind of zone file structure? For what kind of | situation? Can you cover all the cases we would possibly encounter? These would be valid questions if you were treating my message as one in favour of keeping A6. Once again, that isn't what it was. All it was was showing that your draft isn't much of an excuse to deprecate A6. | Agree in general, but I think I saw enough evidence from our | experimental operations as well as analysis (like this draft). What experimental operations? The draft doesn't mention any. It clearly implies some investigation of the code, but doesn't give any hint that you have actually set up some zones containing A6 record and measured the extra delays, the extra round trips, ... If you've done that, you ought to be publishing that data, that would be valuable (that includes the zone file configurations, costs observed, ...) | And you did not present any evidence either. no, because all I'm doing is analysing your draft - and that only because you asked me to. Initially I rejected this approach, and instead just pointed out that in my opinion your draft had nothing to offer (which anyone could conclude after reading it). Eventually I hope to have some evidence to present, when that happens, the conclusion might be in favour of A6, or might be in favour of AAAA. The whole point of collecting data is to provide some basis for making a decision - making the decision before the data is collected seems backwards to me. | No it is not FUD. You cannot assert like this. If you say "I did not | understnd this" or "I think this part is not correct", I can accept | those. Asserting someone's draft a FUD is not fair and unproductive. It is fair, if that is what the draft is - its that alone, to justify my assertion in the first message, that caused me to send the second one (the previous long one) and then this one. To rebut my assertion all you need to do is produce the evidence that backs up your opinions - actually provide some facts rather than simple assertions. And facts which actually lead to some relevant conclusion, rather than irrelevant ones. That is, you could easily show that the ASCII code for 'A' is 65, and spend pages proving that, and from that show that there are indeed proven facts in the draft (or some later one) - but that doesn't add anything to the actual conclusion reached. | No new inventions, please please. It can only hurt the deployment more. Yes, I understand that a major concern is deployment as fast as possible. I have some sympathy for that. But I'm not willing to sacrifice IPv6's potential to achieve it a month, or a year, faster. It may be that events will overtake us all, and that the decision will be made in the field before the right amount of data has been collected to allow it to be made well - I hope not, but that's a possibility. But I really don't want the IETF to go rushing headlong into a decision only because there's some feeling that any decision is better than none, right now. This is going to be the last long message I send on this topic. I'd prefer to do something that's actually productive. 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 Aug 2 03:48:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72AmEF17677 for ipng-dist; Thu, 2 Aug 2001 03:48:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72Am9D17670; Thu, 2 Aug 2001 03:48:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA10163; Thu, 2 Aug 2001 03:48:10 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29731; Thu, 2 Aug 2001 03:48:06 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f72AlNr02053; Thu, 2 Aug 2001 17:47:24 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> <20010801124445.30844.qmail@cr.yp.to> <2862.996673933@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Aug 2001 17:47:23 +0700 Message-ID: <2051.996749243@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 01 Aug 2001 11:44:37 -0700 From: "D. J. Bernstein" Message-ID: | For example, when a .com server says barclays.com NS ns1.barclays.co.uk, | the client has to go look up the ns1.barclays.co.uk address. Is this | because the client is protecting itself against poison? No. It's because | the .com servers DO NOT HAVE THAT ADDRESS. What your web page said was ... Even if the address is provided, the cache won't accept it because .net addresses are not within the bailiwick of a .com server; this is the standard protection against poison. If the address is needed for correct operation, it is trivially easy for the COM server to be told it (or even go look it up, as a part of a server side indirection, other than the volume requirements in that particlar case). This is just standard glue processing (the way it is supposed to be done anyway). It is only this "standard protection against poison", which is totally bogus, as I showed in my last message, that would actually cause this to be a problem that can't easily be fixed. | Server-side indirection means that the server _does_ have the address. | In this case, the server can easily use an in-bailiwick name for the | address, so the normal anti-poisoning rules once again have no effect. But there's no poison involved, no-one ever said anything about putting anything in the cache. All that's relevant is that the address be associated with the NS record for the purposes of finding the nameserver, right now. What the name is should be 100% irrelevant. | The client avoids the extra lookups and the possibility of loops. And instead, the server does the extra lookups, and gets the possibility of loops? One of the design goals of many protocols (I wasn't around for the original DNS design, so I can't say for sure it was one here, but I wouldn't be surprised if it was) is to take the hard work away from the critical point, and distribute it. In this scenario, the DNS server is the critical point, the clients are distributed all over. DNS servers typically have lots of queries to answer - clients usually have nothing much else to do while doing the name lookup. Having the client do more work to make less work for the server is an attractive proposition - even if that means more overall work for the internet as a whole. | The reason I recommend in-bailiwick names within the existing DNS | architecture is that those names force the server to collect the | address. Putting IP addresses into NS records directly would have the | same beneficial effect. As my previous message showed, if implemented properly, any name can have the same benefit of the server knows the address, so can supply it. If the server doesn't know the address, then we're asking that the additional work be done at the point where it can be done with less impact. 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 Aug 2 03:51:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72Aofo17725 for ipng-dist; Thu, 2 Aug 2001 03:50:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72AocD17718; Thu, 2 Aug 2001 03:50:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12142; Thu, 2 Aug 2001 03:50:38 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14967; Thu, 2 Aug 2001 04:52:05 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f72Ancr02064; Thu, 2 Aug 2001 17:49:39 +0700 (ICT) From: Robert Elz To: gson@nominum.com (Andreas Gustafsson) cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <20010801124445.30844.qmail@cr.yp.to> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Aug 2001 17:49:38 +0700 Message-ID: <2062.996749378@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 01 Aug 2001 14:11:23 -0700 From: gson@nominum.com (Andreas Gustafsson) Message-ID: | When resolving, BIND 8 and 9 do reject | all records that are not within the domain whose authoritative | qservers are being queried. That's broken, and should be fixed. If it really is as you have explained it, it guarantees that some perfectly legal DNS configurations can never be properly resolved. | If they did not, we would | be seeing much more cases of cache poisoning that we do now. How? No-one is suggesting that these records be put in the cache. How can the cache be poisoned without that? 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 Aug 2 04:04:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72B3jq17825 for ipng-dist; Thu, 2 Aug 2001 04:03:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72B3eD17818; Thu, 2 Aug 2001 04:03:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15624; Thu, 2 Aug 2001 04:03:41 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA22317; Thu, 2 Aug 2001 05:05:13 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1B5CC4B21; Thu, 2 Aug 2001 20:03:36 +0900 (JST) To: Robert Elz Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 02 Aug 2001 17:25:40 +0700. <2019.996747940@brandenburg.cs.mu.OZ.AU> 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: Joint DNSEXT & NGTRANS agenda From: itojun@iijlab.net Date: Thu, 02 Aug 2001 20:03:36 +0900 Message-ID: <14511.996750216@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One last comment - you and I are not agreeing on the urgency of this. If we don't pick AAAA or A6 right now, we cannot deploy IPv6 NS records and/or IPv6 MX records, we cannot convince gTLDs/ccTLDs to accept IPv6 NS record registrations. The deadline for picking them up is at the London IETF. We wanted the choice like a couple of years ago. We operate commercial IPv6 backbone and selling services to customers since the summer of 1999. And we don't have an official choice of IPv6 DNS records? The situation is like a very very bad joke. We cannot wait forever. This way we can never deploy IPv6. (btw, I'm using no IPv4 from my laptop as I type this!) I appreciate your intent to do the analysis, but I cannot wait forever. We did the analysis and test operations, and the result is in my draft. I did my homework. > | So in your world unanswered questions are called "FUD"? >No, just unanswered questions whose point is to remain unanswered, and >thus just raise the fear of the unknown. The open questions in my drafts are intended to be answered, or get the consensus among people. This is not intended to be left ununsewered (What suggested you like that? Did I tell you so? how can can you assert like that without checking with me?). 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 Aug 2 04:35:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72BZAE18027 for ipng-dist; Thu, 2 Aug 2001 04:35:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72BZ6D18020; Thu, 2 Aug 2001 04:35:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03312; Thu, 2 Aug 2001 04:35:07 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21717; Thu, 2 Aug 2001 05:35:01 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f72BXUr02439; Thu, 2 Aug 2001 18:33:36 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <14511.996750216@itojun.org> References: <14511.996750216@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Aug 2001 18:33:30 +0700 Message-ID: <2437.996752010@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 02 Aug 2001 20:03:36 +0900 From: itojun@iijlab.net Message-ID: <14511.996750216@itojun.org> | One last comment - you and I are not agreeing on the urgency of this. Perhaps not, though I don't think we're that far apart on that. | If we don't pick AAAA or A6 right now, we cannot deploy IPv6 NS | records and/or IPv6 MX records, we cannot convince gTLDs/ccTLDs to | accept IPv6 NS record registrations. The deadline for picking them up | is at the London IETF. We wanted the choice like a couple of years ago. A couple of years ago we made the choice. That was A6. It has taken since then until about now (or even a bit beyond now) to get to the point where A6 can be deployed (when the implementations exist, etc). This isn't a case where we have 2 competing proposals on a more or less equal footing, and want to choose one, its a case where we have an IETF consensus doc, and are now considering deprecating it, before it has even had a reasonable chance to be tested, and without doing any actual testing (that has been reported anyway) to suggest that it won't work. | We operate commercial IPv6 backbone and selling services to customers | since the summer of 1999. And we don't have an official choice of | IPv6 DNS records? We do, that is A6. What we don't have is those actually deployed yet. | We did the analysis and test operations, and the result is in my draft. Maybe the draft is just lacking the necessary information, but I see nothing in it that is more than speculation, and fear of the unknown. | The open questions in my drafts are intended to be answered, or get | the consensus among people. This is not intended to be left | ununsewered (What suggested you like that? Did I tell you so? | how can can you assert like that without checking with me?). That's from the conclusion of the draft. It makes no sense to want answers to questions that are only relevant if A6 is to be used, if the answer is to deprecate A6. You say that A6 should be deprecated. In that case, it can't possibly be interesting to find the answers to questions that are only relevant if A6 is to be used... 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 Aug 2 05:08:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72C7xx18171 for ipng-dist; Thu, 2 Aug 2001 05:07:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72C7qD18156 for ; Thu, 2 Aug 2001 05:07:52 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05794 for ; Thu, 2 Aug 2001 05:07:54 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA07693 for ; Thu, 2 Aug 2001 05:07:53 -0700 (PDT) Received: (qmail 1902 invoked by uid 1001); 2 Aug 2001 12:02:46 -0000 Date: 2 Aug 2001 12:02:46 -0000 Message-ID: <20010802120246.31021.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <14511.996750216@itojun.org> <2437.996752010@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > before it has even had a reasonable chance to be tested We're saying ``deployment will be a disaster, and here's why.'' You're saying ``let's deploy it and see what happens.'' That's unacceptable. A6 and DNAME need to be killed _before_ people start relying on them. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 2 05:41:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72CeEA18315 for ipng-dist; Thu, 2 Aug 2001 05:40:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72Ce6D18299; Thu, 2 Aug 2001 05:40:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18517; Thu, 2 Aug 2001 05:40:08 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09441; Thu, 2 Aug 2001 05:40:06 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 02 Aug 2001 05:37:27 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 990E4BCEDBF24538BDBA3E7FFD6F8B1D for plus 4 more; Thu, 02 Aug 2001 05:37:26 -0700 Reply-To: From: "Tony Hain" To: "Robert Elz" , Cc: , , Subject: RE: Joint DNSEXT & NGTRANS agenda Date: Thu, 2 Aug 2001 13:37:24 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <2437.996752010@brandenburg.cs.mu.OZ.AU> X-SLUIDL: 1A4062C5-9BB44B2E-96C0527C-3B78EBC0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f72Ce7D18300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > A couple of years ago we made the choice. That was A6. > It has taken since then until about now (or even a bit > beyond now) to get to the point where A6 can be deployed >(when the implementations exist, etc). > This isn't a case where we have 2 competing proposals on > a more or less equal footing, and want to choose one, its > a case where we have an IETF consensus doc, and are now > considering deprecating it, before it has even had a > reasonable chance to be tested, and without doing any actual > testing (that has been reported anyway) to suggest that > it won't work. I have no doubt we could figure out how to make A6 work, and with a few guidelines written up even keep it from being noticeably different. My concern is that the basic premise for its need is explicitly contradictory to economic realities. As much as people claim they need to renumber their customers to compress the routing table, how many will really tell the people paying them that to continue being a customer they have to go through some level of routine pain? Even if it is only a few records a couple of times a year, the customers will quickly bail and find a provider that can deal with the entropy. This is just another case of the point of pain not matching with the gain, so it simply won't happen. 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 Aug 2 05:46:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f72CjsS18353 for ipng-dist; Thu, 2 Aug 2001 05:45:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72CjlD18337 for ; Thu, 2 Aug 2001 05:45:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24183 for ; Thu, 2 Aug 2001 05:45:48 -0700 (PDT) Received: from muncher.math.uic.edu (koobera.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA07485 for ; Thu, 2 Aug 2001 06:47:20 -0600 (MDT) Received: (qmail 30570 invoked by uid 1001); 2 Aug 2001 12:37:50 -0000 Date: 2 Aug 2001 12:37:50 -0000 Message-ID: <20010802123750.1416.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> <20010801124445.30844.qmail@cr.yp.to> <2862.996673933@brandenburg.cs.mu.OZ.AU> <2051.996749243@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > This is just standard glue processing (the way it is supposed to be > done anyway). That's not what the DNS standards say. RFC 1034 states quite clearly that glue is necessary only for in-bailiwick names. RFC 1537 says the same thing, and specifically recommends against glue for out-of-bailiwick names. So does RFC 1912. So does the c.p.t-i.d FAQ: ``Adding [out-of-bailiwick glue] is a very bad idea.'' Of course, BIND has thrown away out-of-bailiwick glue for years. You claim that discrimination against out-of-bailiwick glue poses ``a problem that can't easily be fixed.'' That's absurd. The fix is trivial: use in-bailiwick names. What's important---what avoids the reliability problems---is to have all the information available on the server. This is why I tell my users to select in-bailiwick names (the server _must_ collect the address in this case) and to avoid CNAME records. It's also why I oppose A6 and DNAME. > What your web page said was ... > Even if the address is provided, the cache won't accept it > because .net addresses are not within the bailiwick of a .com server; > this is the standard protection against poison. You are taking this out of context. The crucial point is that the address is _not_ provided. The next paragraph on my web page explains this in more detail. > | The client avoids the extra lookups and the possibility of loops. > And instead, the server does the extra lookups, and gets the possibility > of loops? Wrong. Server-side indirection never causes loops. You would understand this if you read my web page: http://cr.yp.to/djbdns/killa6.html ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 2 19:00:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f731xST22381 for ipng-dist; Thu, 2 Aug 2001 18:59:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f731wQD22359; Thu, 2 Aug 2001 18:58:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07583; Thu, 2 Aug 2001 18:58:27 -0700 (PDT) Received: from blackrock.internal.simegen.com (co3019724-a.thoms1.vic.optushome.com.au [203.164.36.115]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08287; Thu, 2 Aug 2001 19:58:23 -0600 (MDT) Received: from anaconda.internal.simegen.com ([10.0.2.1] helo=zeor.simegen.com) by blackrock.internal.simegen.com with esmtp (Exim 3.22 #1 (Debian)) id 15SUDo-0007cH-00; Fri, 03 Aug 2001 11:57:52 +1000 Message-ID: <3B6A051F.4010404@zeor.simegen.com> Date: Fri, 03 Aug 2001 11:57:51 +1000 From: Dancer Vesperman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+; Debian/GNU) Gecko/20010701 X-Accept-Language: en-us MIME-Version: 1.0 To: "D. J. Bernstein" CC: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Re: Joint DNSEXT & NGTRANS agenda References: <14511.996750216@itojun.org> <2437.996752010@brandenburg.cs.mu.OZ.AU> <20010802120246.31021.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk D. J. Bernstein wrote: > Robert Elz writes: > >>before it has even had a reasonable chance to be tested >> > > We're saying ``deployment will be a disaster, and here's why.'' You're > saying ``let's deploy it and see what happens.'' That's unacceptable. > A6 and DNAME need to be killed _before_ people start relying on them. You know, I seem to recall that I said the same about HTTP, way back when... I get the impression that it's too late to deploy something that isn't already ready. I agree with itojun (It's true that I spend a lot of time doing this): There is no time. A broken thing is probably better than no thing. IT people tend to laugh at IPv6 as vaporware these days. Personally, I don't much _CARE_ if it's possible for a DNS administrator to get things Horribly Wrong(tm) with A6 records. They _already_ get things Horribly Wrong(tm) with A records, NS records, MX records, SOA records and CNAME records....screwing up their domains with yet another record type would merely be continuing a grand tradition. Dan: You have a point. Maybe a good one. Personally, I don't think it's quite good enough given the apparent time-frames. Fait accompli and all that. D -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 2 19:12:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f732A5x22499 for ipng-dist; Thu, 2 Aug 2001 19:10:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7329eD22471 for ; Thu, 2 Aug 2001 19:09:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15416 for ; Thu, 2 Aug 2001 19:09:43 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08038 for ; Thu, 2 Aug 2001 19:09:42 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYZJ00.ID7 for ; Thu, 2 Aug 2001 22:02:07 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PIZ00.DCO; Fri, 27 Jul 2001 20:04:11 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA26330; Wed, 25 Jul 2001 08:15:08 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26409 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 07:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25420 for ; Wed, 25 Jul 2001 06:32:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07337; Wed, 25 Jul 2001 06:31:58 -0400 (EDT) Message-Id: <200107251031.GAA07337@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-icmp-name-lookups-08.txt Date: Wed, 25 Jul 2001 06:31:58 -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 IPNG Working Group of the IETF. Title : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-08.txt Pages : 15 Date : 24-Jul-01 This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-08.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-icmp-name-lookups-08.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: <20010724132106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132106.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 Aug 2 19:12:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f732A4322498 for ipng-dist; Thu, 2 Aug 2001 19:10:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7329dD22460 for ; Thu, 2 Aug 2001 19:09:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08609 for ; Thu, 2 Aug 2001 19:09:42 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08026 for ; Thu, 2 Aug 2001 19:09:42 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYXQ00.GD1; Thu, 2 Aug 2001 22:01:02 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PRT00.IDB; Fri, 27 Jul 2001 20:09:29 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA11922; Wed, 25 Jul 2001 15:04:15 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA02951 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 14:35:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA02472 for ; Wed, 25 Jul 2001 14:12:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18604; Wed, 25 Jul 2001 14:12:13 -0400 (EDT) Message-Id: <200107251812.OAA18604@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu From: The IESG SUBJECT: Last Call: Unicast-Prefix-based IPv6 Multicast Addresses to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 25 Jul 2001 14:12:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG and the MALLOC Working Groups to consider publication of the folloing two Interent-Drafts as Proposed Standards. o Unicast-Prefix-based IPv6 Multicast Addresses o Dynamic Allocation Guidelines for IPv6 Multicast Addresses as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 25, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-02.txt http://www.ietf.org/internet-drafts/; Thu, 2 Aug 2001 19:09:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15444 for ; Thu, 2 Aug 2001 19:09:43 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08051 for ; Thu, 2 Aug 2001 19:09:43 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGZ8B00.BDM for ; Thu, 2 Aug 2001 22:07:23 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5URB00.KIK; Fri, 27 Jul 2001 21:57:11 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA09207; Tue, 24 Jul 2001 08:14:23 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA14044 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:45:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12612 for ; Tue, 24 Jul 2001 06:29:19 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05854; Tue, 24 Jul 2001 06:29:18 -0400 (EDT) Message-Id: <200107241029.GAA05854@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-icmp-v3-01.txt Date: Tue, 24 Jul 2001 06:29:18 -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 IPNG Working Group of the IETF. Title : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v3-01.txt Pages : 20 Date : 23-Jul-01 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-v3-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010723140403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v3-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140403.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 Aug 2 19:12:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f732A5b22500 for ipng-dist; Thu, 2 Aug 2001 19:10:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7329bD22439 for ; Thu, 2 Aug 2001 19:09:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15402 for ; Thu, 2 Aug 2001 19:09:39 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA08001 for ; Thu, 2 Aug 2001 19:09:39 -0700 (PDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHGYHS00.EDB for ; Thu, 2 Aug 2001 21:51:28 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5CXJ00.B20; Fri, 27 Jul 2001 15:32:07 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id KAA02255; Fri, 27 Jul 2001 10:18:39 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA15141 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 09:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA12913 for ; Fri, 27 Jul 2001 07:08:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06745; Fri, 27 Jul 2001 07:08:05 -0400 (EDT) Message-Id: <200107271108.HAA06745@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-default-addr-select-05.txt Date: Fri, 27 Jul 2001 07:08:05 -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 IPNG Working Group of the IETF. Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-05.txt Pages : 21 Date : 26-Jul-01 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-default-addr-select-05.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-default-addr-select-05.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: <20010726170650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-default-addr-select-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170650.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 Aug 3 01:56:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f738t6F23844 for ipng-dist; Fri, 3 Aug 2001 01:55:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f738shD23824 for ; Fri, 3 Aug 2001 01:54:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13316 for ; Fri, 3 Aug 2001 01:54:46 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27218 for ; Fri, 3 Aug 2001 02:54:43 -0600 (MDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFHC00.2PR for ; Fri, 3 Aug 2001 03:58:24 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5URB00.KIK; Fri, 27 Jul 2001 21:57:11 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA09207; Tue, 24 Jul 2001 08:14:23 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA14044 for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 07:45:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12612 for ; Tue, 24 Jul 2001 06:29:19 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05854; Tue, 24 Jul 2001 06:29:18 -0400 (EDT) Message-Id: <200107241029.GAA05854@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-icmp-v3-01.txt Date: Tue, 24 Jul 2001 06:29:18 -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 IPNG Working Group of the IETF. Title : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v3-01.txt Pages : 20 Date : 23-Jul-01 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-v3-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010723140403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v3-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140403.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 Aug 3 01:56:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f738ssQ23839 for ipng-dist; Fri, 3 Aug 2001 01:54:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f738sbD23784 for ; Fri, 3 Aug 2001 01:54:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17016 for ; Fri, 3 Aug 2001 01:54:39 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27164 for ; Fri, 3 Aug 2001 02:54:36 -0600 (MDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHF4D00.PQI for ; Fri, 3 Aug 2001 03:50:37 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5CXJ00.B20; Fri, 27 Jul 2001 15:32:07 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id KAA02255; Fri, 27 Jul 2001 10:18:39 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA15141 for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 09:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA12913 for ; Fri, 27 Jul 2001 07:08:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06745; Fri, 27 Jul 2001 07:08:05 -0400 (EDT) Message-Id: <200107271108.HAA06745@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-default-addr-select-05.txt Date: Fri, 27 Jul 2001 07:08:05 -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 IPNG Working Group of the IETF. Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-05.txt Pages : 21 Date : 26-Jul-01 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-default-addr-select-05.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-default-addr-select-05.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: <20010726170650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-default-addr-select-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170650.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 Aug 3 01:56:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f738t4823843 for ipng-dist; Fri, 3 Aug 2001 01:55:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f738sgD23813 for ; Fri, 3 Aug 2001 01:54:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25854 for ; Fri, 3 Aug 2001 01:54:45 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27210 for ; Fri, 3 Aug 2001 02:54:42 -0600 (MDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFAW00.MQ1 for ; Fri, 3 Aug 2001 03:54:32 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PIZ00.DCO; Fri, 27 Jul 2001 20:04:11 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id IAA26330; Wed, 25 Jul 2001 08:15:08 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA26409 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 07:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25420 for ; Wed, 25 Jul 2001 06:32:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07337; Wed, 25 Jul 2001 06:31:58 -0400 (EDT) Message-Id: <200107251031.GAA07337@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-icmp-name-lookups-08.txt Date: Wed, 25 Jul 2001 06:31:58 -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 IPNG Working Group of the IETF. Title : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-08.txt Pages : 15 Date : 24-Jul-01 This document describes a protocol for asking an IPv6 node to supply certain network information, such as its hostname or fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a hostname are useful, and a direct query mechanism for other information has been found useful in serverless environments and for debugging. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-name-lookups-08.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-icmp-name-lookups-08.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: <20010724132106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010724132106.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 Aug 3 01:56:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f738t8U23845 for ipng-dist; Fri, 3 Aug 2001 01:55:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f738shD23816 for ; Fri, 3 Aug 2001 01:54:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00932 for ; Fri, 3 Aug 2001 01:54:45 -0700 (PDT) Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27215 for ; Fri, 3 Aug 2001 02:54:42 -0600 (MDT) Received: from postoffice.sarnoff.com ([127.0.0.1]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with SMTP id GHHFCZ00.7Q0; Fri, 3 Aug 2001 03:55:47 -0400 Received: from nova.sarnoff.com ([130.33.8.27]) by postoffice.sarnoff.com (Netscape Messaging Server 4.15) with ESMTP id GH5PRT00.IDB; Fri, 27 Jul 2001 20:09:29 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA11922; Wed, 25 Jul 2001 15:04:15 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA02951 for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 14:35:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA02472 for ; Wed, 25 Jul 2001 14:12:15 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18604; Wed, 25 Jul 2001 14:12:13 -0400 (EDT) Message-Id: <200107251812.OAA18604@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu From: The IESG SUBJECT: Last Call: Unicast-Prefix-based IPv6 Multicast Addresses to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 25 Jul 2001 14:12:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG and the MALLOC Working Groups to consider publication of the folloing two Interent-Drafts as Proposed Standards. o Unicast-Prefix-based IPv6 Multicast Addresses o Dynamic Allocation Guidelines for IPv6 Multicast Addresses as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by August 25, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-02.txt http://www.ietf.org/internet-drafts/; Fri, 3 Aug 2001 09:23:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14283 for ; Fri, 3 Aug 2001 09:22:28 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA24107 for ; Fri, 3 Aug 2001 10:22:27 -0600 (MDT) Received: (qmail 6263 invoked by uid 1001); 3 Aug 2001 16:01:23 -0000 Date: 3 Aug 2001 16:01:23 -0000 Message-ID: <20010803160123.32528.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg Hudson writes: > That sounds like a loop to me. It isn't. Here's what the isc.org server does: 1. Look up isrv4.pa.vix.com. 2. Set up ftp.isc.org with the same information. See? No loop. The procedure is guaranteed to end in two steps. The ftp.isc.org information at any moment is a correct copy of the recent isrv4.pa.vix.com information, exactly as specified. It doesn't matter where the isrv4.pa.vix.com information comes from. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 3 18:28:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f741Rib26713 for ipng-dist; Fri, 3 Aug 2001 18:27:45 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f741ReD26706 for ; Fri, 3 Aug 2001 18:27:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA22731 for ; Fri, 3 Aug 2001 18:27:42 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16828 for ; Fri, 3 Aug 2001 18:27:40 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA01547; Sat, 4 Aug 2001 10:28:53 +0900 (JST) Date: Sat, 04 Aug 2001 08:44:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sakreddy@india.hp.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Regarding IPV6_RECVPKTINFO. In-Reply-To: <3B5BD724.63910D7@india.hp.com> References: <3B54E927.C554BFCA@cisco.com> <3B5BD724.63910D7@india.hp.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 23 Jul 2001 13:19:57 +0530, >>>>> "Anil Kumar Reddy. S" said: > Can anybody please help me in finding out a solution to my problem > related to IPV6_RECVPKTINFO. > I am setting IPV6_RECVPKTINFO and when I do a recvmsg ( ), > it is returning MSG_CTRUNC in the 'flags' parameter. That means > I am not giving enough buffer to return the ancillary data. > My question is ... how much should I set the buffer space ?? I am doing > recvmsg ( ) in the following way : CMSG_SPACE(sizeof(struct in6_pktinfo)) should be enough. Are you sure that you did not specify any other options than IPV6_RECVPKTINFO? (BTW: I'm not sure what CMSG_SPACE(sizeof(struct in6_addr)) means. What is your intention to include this?) Another minor point: if (cmptr->cmsg_level == IPPROTO_IPV6 && cmptr->cmsg_type == IPV6_RECVPKTINFO) { ^^^^^^^^^^^^^^^^ IPV6_RECVPKTINFO should be IPV6_PKTINFO. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 3 18:29:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f741TFh26751 for ipng-dist; Fri, 3 Aug 2001 18:29:16 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f741T3D26736 for ; Fri, 3 Aug 2001 18:29:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01504 for ; Fri, 3 Aug 2001 18:29:04 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17234 for ; Fri, 3 Aug 2001 18:29:03 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA01560; Sat, 4 Aug 2001 10:29:03 +0900 (JST) Date: Sat, 04 Aug 2001 08:53:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: John Border Cc: deering@cisco.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: Followup question re ICMPv6 Time Exceeded Message Code 1 In-Reply-To: <3B5E07E8.E5082E81@hns.com> References: <3B5E07E8.E5082E81@hns.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 26 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 24 Jul 2001 19:42:32 -0400, >>>>> John Border said: > Is the sending of a Time Exceeded IPCMv6 message with a Code of 1 > ("fragment reassembly time exceeded") a MUST, a SHOULD or an OPTIONAL for a > host which discards an IPv6 packet for this reason? I guess it is a SHOULD. If insufficient fragments are received to complete reassembly of a packet within 60 seconds of the reception of the first-arriving fragment of that packet, reassembly of that packet must be abandoned and all the fragments that have been received for that packet must be discarded. If the first fragment (i.e., the one with a Fragment Offset of zero) has been received, an ICMP Time Exceeded -- Fragment Reassembly Time Exceeded message should be <--- sent to the source of that fragment. (RFC 2460, Section 4.5) (Note that RFC 2460 does not contain any capitalized terminologies like MUST/SHOULD/MAY/etc.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 3 18:29:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f741TOi26752 for ipng-dist; Fri, 3 Aug 2001 18:29:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f741T3D26738 for ; Fri, 3 Aug 2001 18:29:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01507 for ; Fri, 3 Aug 2001 18:29:05 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17235 for ; Fri, 3 Aug 2001 18:29:03 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA01553; Sat, 4 Aug 2001 10:28:58 +0900 (JST) Date: Sat, 04 Aug 2001 08:51:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: John Border Cc: deering@cisco.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: Re ICMPv6 Time Exceeded Message Code 1 In-Reply-To: <3B5DFBB4.70AA9DC3@hns.com> References: <3B5DFBB4.70AA9DC3@hns.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 24 Jul 2001 18:50:28 -0400, >>>>> John Border said: > The description in Section 3.3 of draft-ietf-ipngwg-icmp-v3-01.txt doesn't > mention the use of Code 1 - "fragment reassembly time exceeded". Presumably, > the destination node sends such a message when when it discards an IPv6 packet > because its reassembly timer for the packet expires. Are there restrictions > governing when such messages should be sent other than those described in > Section 2.4 of the document? I don't think so, but I'm not sure why the document does not explicitly mention the code-1 error (actually, older documents of the spec, RFC 1885 and RFC 2463, do not mention it, either.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 4 00:34:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f747WUj27251 for ipng-dist; Sat, 4 Aug 2001 00:32:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f747WQD27244; Sat, 4 Aug 2001 00:32:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12542; Sat, 4 Aug 2001 00:32:22 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10781; Sat, 4 Aug 2001 01:32:18 -0600 (MDT) From: Masataka Ohta Message-Id: <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA02195; Sat, 4 Aug 2001 16:15:16 +0900 Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <2062.996749378@brandenburg.cs.mu.OZ.AU> from Robert Elz at "Aug 2, 2001 05:49:38 pm" To: Robert Elz Date: Sat, 4 Aug 2001 16:15:15 +0859 () CC: Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre; > | When resolving, BIND 8 and 9 do reject > | all records that are not within the domain whose authoritative > | qservers are being queried. > > That's broken, and should be fixed. If it really is as you have > explained it, it guarantees that some perfectly legal DNS configurations > can never be properly resolved. > > | If they did not, we would > | be seeing much more cases of cache poisoning that we do now. > > How? No-one is suggesting that these records be put in the cache. I have been suggesting that these records be put in a referral-local cache content of which is not used for usual A query nor glue A of other referral points. Other approaches are broken w.r.t. performance. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 4 05:15:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f74CF9v27499 for ipng-dist; Sat, 4 Aug 2001 05:15:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f74CF5D27492; Sat, 4 Aug 2001 05:15:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23030; Sat, 4 Aug 2001 05:15:06 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23768; Sat, 4 Aug 2001 05:15:01 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f74CEiM18698; Sat, 4 Aug 2001 15:14:48 +0300 Date: Sat, 4 Aug 2001 15:14:43 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: , Subject: obstacles to renumbering [Re: Joint DNSEXT & NGTRANS agenda] In-Reply-To: <2019.996747940@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Let's continue the renumbering debate only in ipng@; please strip ngtrans from Cc: if replying. On Thu, 2 Aug 2001, Robert Elz wrote: [snip] > What we're supposed to be doing (what we set out to do way back when > ipng first started) is to remove as many impediments to easy renumbering > as possible. That is, every time we find something that looks like it > will cause problems, we look for a solution that will allow those > problems to be avoided. > > We don't simply say "there's this other problem that isn't solved yet, > so there's no point doing anything about this one" - that's defeatism. > > We can do better than that - but we have to keep working on each problem, > each little obstacle to renumbering, as we find it. I have a pragmatic (as probably most others) approach toward renumbering. Getting it working is completely is probably at least as difficult problem as working public key infrastructure problem (not that these have to be necessarily related, but the biggest problems aren't necessarily technical in nature). I'm not going into automatic router renumbering itself. But "site renumbering", a manual operation, can be made to "kinda work", I think. The most important issue is getting all hosts (or 99.5%) autoconfigured. If this can't be assumed, we've already lost the battle against scalability. 1, 10, even 30 routers or very important servers can be manually reconfigured in an acceptable amount of time, but if all servers, much less end-nodes, were to be reconfigured manually too.. not nice. Therefore, in practise, we should remove impediments to using autoconfiguration and having to manually specify network settings even if you do (e.g. DNS) if those come up. If this is agreed upon, the issues here are: 1) accept the fact that if there is no DNS service (e.g your network cable breaks and you reboot, the computer may get stuck at boot more or less indefinitely), you're on your own. (this could be worked around by vendors' some automated mechanism of copying the "last-known" addresses needed at boot to hosts.txt or something) 2) implement auto-discovery of dns servers e.g. with anycast (work already in full swing) 3) implement a mechanism to assign other than EUI64 suffixes automatically. IMO, this is required for servers -- having EUI64 identifier in DNS for a server is IMO unacceptable. I want my servers to be like PRFX::1, PRFX:1::10 etc. -- short, stable and easily remembered. (not that there is need for anything from IETF here -- this is just an approach vendors could use, as the autoconfigured prefix is already known). Any others? Practically, now renumbering sites would be _much easier_ already (ie. doable) if these were to be achieved. -- 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 Aug 4 15:12:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f74MC8f28620 for ipng-dist; Sat, 4 Aug 2001 15:12:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f74MC0D28613; Sat, 4 Aug 2001 15:12:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01325; Sat, 4 Aug 2001 15:12:01 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19241; Sat, 4 Aug 2001 16:11:58 -0600 (MDT) From: Masataka Ohta Message-Id: <200108042153.GAA05127@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id GAA05127; Sun, 5 Aug 2001 06:53:33 +0900 Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <200108041536.IAA01336@gulag.araneus.fi> from Andreas Gustafsson at "Aug 4, 2001 08:36:00 am" To: Andreas Gustafsson Date: Sun, 5 Aug 2001 06:53:33 +0859 () CC: Robert Elz , Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andreas; > > > How? No-one is suggesting that these records be put in the cache. > > > > I have been suggesting that these records be put in a referral-local > > cache content of which is not used for usual A query nor glue A of > > other referral points. > > I think that's an excellent approach, and one that should be seriously > considered when designing new resolver implementations. BIND 8 and 9 > have the concept of a single, global cache too deeply ingrained to be > changed at this point. As I have been suggesting it long before BIND 8 or9, I have no intention to check them specifically by myself. But, if they are implemented rationally, the modification would be: Add a field of referral point for a cache entry structure. Referral point would be null pointer unless it is cached from additional A for NS. Otherwise the referral point for the NS would be stored. Cache entries are matched considering the referral point, unless the answer is used for additional A for NS. Additonal A for NS may use cache entry with null referral point As all the referral points of a zone share the same glue information, zone may be used instead of referral point. I estimate the modification is a lot easier than several generations of misdirected attempts to obtain the true weak security. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 4 17:47:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f750lOI28861 for ipng-dist; Sat, 4 Aug 2001 17:47:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f750lID28853 for ; Sat, 4 Aug 2001 17:47:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01686 for ; Sat, 4 Aug 2001 17:47:19 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA10320 for ; Sat, 4 Aug 2001 18:47:18 -0600 (MDT) Received: (qmail 3879 invoked by uid 1001); 5 Aug 2001 00:47:37 -0000 Date: 5 Aug 2001 00:47:36 -0000 Message-ID: <20010805004736.9415.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta writes: > I have been suggesting that these records be put in a referral-local > cache content of which is not used for usual A query nor glue A of > other referral points. What records are you talking about? Typical A6 reliability problems involve servers that don't know the next step in the A6 chain. How is the server going to provide records that it doesn't have? Of course, we can eliminate the reliability problems by making sure that the servers have the entire A6 chain---in which case it's far simpler to use AAAA. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 5 06:32:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75DV4W29924 for ipng-dist; Sun, 5 Aug 2001 06:31:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75DV0D29917; Sun, 5 Aug 2001 06:31:00 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03810; Sun, 5 Aug 2001 06:31:01 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09450; Sun, 5 Aug 2001 06:30:58 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f75DU7i06949; Sun, 5 Aug 2001 20:30:08 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 05 Aug 2001 20:30:07 +0700 Message-ID: <6947.997018207@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 04 Aug 2001 23:05:03 -0700 From: "D. J. Bernstein" Message-ID: | What records are you talking about? Otha-san was talking about glue A records that accompany NS records, which is a side avenue that this discussion was taking. | Typical A6 reliability problems involve servers that don't know the next | step in the A6 chain. How is the server going to provide records that it | doesn't have? It isn't. Obviously. Whether or not there's a reliability problem in this case will depend upon how reliable the other servers, that have the rest of the data are of course. This is no different than an MX record that names a host served by a different server, or a similar NS record. And, yes, I know that you recommend to your users that they don't do that. And that's fine. And you can do the same with A6 as well... | Of course, we can eliminate the reliability problems by making sure that | the servers have the entire A6 chain---in which case it's far simpler to | use AAAA. But if A6 is used, each site has 3 choices. It can use A6 0, which is identical in effect to AAAA. Or it can use an A6 chain, where all the RR's are available at the same server. Or it can use an A6 chain, with one or more of the A6 records at some other server (hence requiring more lookups). Each site gets to make that choice, and make it indiviually for each v6 address to be placed in the DNS. That is, each site gets to choose between the degree of reliability, and the degree of flexibility that meets its needs best. You are, of course, free to keep recommending to your users that they only use A6 0 if you want to. You could even (assuming you ever implement any of this) refuse to allow your server to load any A6 record other than A6 0. But is there any good reason that you can give us why others shouldn't be free to make other choices? 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 Sun Aug 5 08:24:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75FNOk00369 for ipng-dist; Sun, 5 Aug 2001 08:23:24 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75FNGD00354 for ; Sun, 5 Aug 2001 08:23:16 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f75FN5217857; Sun, 5 Aug 2001 17:23:05 +0200 (MET DST) Date: Sun, 5 Aug 2001 14:53:07 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt To: alh-ietf@tndh.net Cc: Erik Nordmark , Stig Venaas , ipng@sunroof.eng.sun.com, richdr@microsoft.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I had always read that section as 'if you don't know a router simply try ND > as a last resort'. I would still consider an implementation broken if it > interpreted the lack of a router entry to mean that it should declare one of > its interfaces to be the default route. Are you talking about multi-interface hosts? There isn't a specification that talks about such hosts and it would be good to have such a spec because I think there are some complex issues hiding in this area. > I realize this is simply a semantic > difference, but mixing the routing table with the neighbor cache seems like > an operational disaster waiting to happen. What is the problem? > > One possible way of making the draft clearer would be to, instead > > of using the implementation concept of a routing table, express > > the rule using the conceptual model in RFC 2461. > > I didn't read the rule as being restricted to a routing table because it > included 'or the current next-hop neighbor'. I agree that could be > interpreted as a router, but it could also be just the destination pointed > to by the NC entry. How about 'or the current next-hop in the neighbor cache > for DB is known to be unreachable'? But in this case the next-hop wouldn't be known to be unreachable - its state would be unknown. Not until traffic is actually sent towards the next-hop can NUD detect that it is unreachable. Thus I think it makes sense to have an explicit mention of the "assume all destinations on-link" case in this rule. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 5 09:07:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75G6fU00839 for ipng-dist; Sun, 5 Aug 2001 09:06:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75G6TD00823 for ; Sun, 5 Aug 2001 09:06:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21089 for ; Sun, 5 Aug 2001 09:06:28 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA03594 for ; Sun, 5 Aug 2001 10:06:26 -0600 (MDT) Received: (qmail 32244 invoked by uid 1001); 5 Aug 2001 16:06:47 -0000 Date: 5 Aug 2001 16:06:47 -0000 Message-ID: <20010805160647.29275.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> <6947.997018207@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > That is, each site gets to choose between the degree of reliability, and > the degree of flexibility that meets its needs best. You're saying that the I.AM administrators _chose_ to make their domain only sporadically reachable by BIND 8 caches around the Internet? Sure, BIND 9 and dnscache have higher gluelessness limits, but those limits can be exceeded too. A cache can't let a single lookup consume arbitrary amounts of memory! See RFC 1034, section 5.3.3. If people start relying on A6 and DNAME, this type of failure---and the other two types described in http://cr.yp.to/djbdns/killa6.html---will become much more common. Are you going to claim that the victims _chose_ to screw up their own DNS service? ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 5 10:10:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75H9Ll00944 for ipng-dist; Sun, 5 Aug 2001 10:09:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75H9GD00937; Sun, 5 Aug 2001 10:09:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06024; Sun, 5 Aug 2001 10:09:17 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13514; Sun, 5 Aug 2001 11:09:14 -0600 (MDT) From: Masataka Ohta Message-Id: <200108051653.BAA06927@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA06927; Mon, 6 Aug 2001 01:53:31 +0900 Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: from "D. J. Bernstein" at "Aug 4, 2001 11:05:03 pm" To: "D. J. Bernstein" Date: Mon, 6 Aug 2001 01:53:30 +0859 () CC: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan; > > I have been suggesting that these records be put in a referral-local > > cache content of which is not used for usual A query nor glue A of > > other referral points. > > What records are you talking about? Just a history on glue A. You can apply it to glue AAAA (if any) and glue A6. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 5 11:43:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75IglW01093 for ipng-dist; Sun, 5 Aug 2001 11:42:47 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75IghD01086 for ; Sun, 5 Aug 2001 11:42:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27046 for ; Sun, 5 Aug 2001 11:42:43 -0700 (PDT) Received: from condor.isl.rdc.toshiba.co.jp (host217-33-136-94.ietf.ignite.net [217.33.136.94]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15282 for ; Sun, 5 Aug 2001 11:42:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by condor.isl.rdc.toshiba.co.jp (8.10.1/8.10.1) with ESMTP id f75IeLk01395; Mon, 6 Aug 2001 03:40:22 +0900 (JST) Date: Mon, 06 Aug 2001 03:40:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Brian Zill" Cc: , Subject: Re: Ad-hoc IPv6 inter-op session at London IETF In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 31 Jul 2001 18:48:03 -0700, >>>>> "Brian Zill" said: > At the recent ipng/ngtrans interim meeting in Redmond, we had an ad-hoc > IPv6 inter-op session which was surprisingly well-attended given that we > decided to do it at the last minute. Some real testing was actually > accomplished, and it was also a mildly fun social event. I was > wondering if anyone would be interested in doing this again? (snip) > I'm thinking Thursday night would be best since there is nothing on the > official agenda and we should all still be around since Friday morning > is the second ipngwg session. Other suggestions welcome. I'm interested in how implementations respond to Neighbor Solicitation messages on a p2p link, with or without source link-layer address options, in order to know the current situation about the interoperability issue described in Section 3 of draft-ietf-ipngwg-p2p-pingpong-00.txt. We can easily test this if the implementation supports configured tunnels (which is highly likely), and we'll need no additional subnets for the test. In terms of the motivation above, I wish to do the test for router implementations, and would like router vendors to join the event if they can set a tunnel to their labs. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 5 12:35:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75JXFd01154 for ipng-dist; Sun, 5 Aug 2001 12:33:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75JXBD01147 for ; Sun, 5 Aug 2001 12:33:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21149 for ; Sun, 5 Aug 2001 12:33:11 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13967 for ; Sun, 5 Aug 2001 13:33:12 -0600 (MDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA23580 for ; Sun, 5 Aug 2001 20:33:09 +0100 (BST) Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA27653 for ; Sun, 5 Aug 2001 20:33:09 +0100 (BST) Date: Sun, 5 Aug 2001 20:33:06 +0100 (BST) From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: [LUUG Publicity] 6-9 Aug, IETF and ISOC talks at UCL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I've not seen this on the ipng list, and it may be of general interest to many of you in London this week. Note Bob Fink is talking about IPv6 on the Thursday, which is otherwise an IPv6-less day. There's also a talk by Ted Ts'o at UCL at 6.30pm on Thursday on Linux, a talk organised jointly with ISOC. UCL is four tube stops east from the IETF hotel on the circle line. Tim ---------- Forwarded message ---------- Date: Sun, 5 Aug 2001 13:09:41 +0100 From: Charles.Curran@UKUUG.org To: luug-publicity@ourshack.org, members@list.ukuug.org Cc: chat@list.ukuug.org Subject: [LUUG Publicity] 6-9 Aug, IETF lunchtime talks at UCL. 18:20, 9 Aug: Ted Ts'o Taking advantage of the IETF meeting in London this week, UCL (Prof Jon Crowcroft, et al) are staging a series of lunchtime talks (12.00 to 13.30). See http://www.ukuug.org/events/IETF-UCL_Aug2001.shtml for a summary. Monday, 6 August Scott Bradner, Harvard Univ - Internet Standards RFC 2026 etc Geoff Huston, Telstra - Internet Routing and End to End Tuesday, 7 August Fred Baker, Cisco Systems - Quality of Service Wednesday, 8 August Barbara Fraser, Cisco - Security Mark Green, CacheFlow Inc. - Content Networking Thursday, 9 August Marco Carugi, Voila/France Telecom - Virtual Private Networks Bob Fink, NASA - IPv6 Up-to-the-minute information will be maintained at: http://www-mice.cs.ucl.ac.uk/ietf/talks.html. They ask that you REGISTER so that they have an idea of numbers. -- Details of UKUUG's Thursday evening event --Ted Ts'o on Linux (this replaces Tim O'Reilly) -- can be found at http://www.ukuug.org/events/TYT_20010809.shtml . Door open 18:00, starts 18:30. -- --Charles _______________________________________________ LUUG-publicity mailing list LUUG-publicity@ourshack.org http://www.ourshack.com/mailman/listinfo/luug-publicity -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 5 14:22:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75LMJk01339 for ipng-dist; Sun, 5 Aug 2001 14:22:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75LMFD01332 for ; Sun, 5 Aug 2001 14:22:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25622; Sun, 5 Aug 2001 14:22:12 -0700 (PDT) Received: from condor.isl.rdc.toshiba.co.jp (host217-33-136-94.ietf.ignite.net [217.33.136.94]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15418; Sun, 5 Aug 2001 14:22:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by condor.isl.rdc.toshiba.co.jp (8.10.1/8.10.1) with ESMTP id f75LJkk02081; Mon, 6 Aug 2001 06:19:46 +0900 (JST) Date: Mon, 06 Aug 2001 06:19:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: alh-ietf@tndh.net, Stig Venaas , ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: Re: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 5 Aug 2001 14:53:07 +0200 (CEST), >>>>> Erik Nordmark said: >> > One possible way of making the draft clearer would be to, instead >> > of using the implementation concept of a routing table, express >> > the rule using the conceptual model in RFC 2461. >> >> I didn't read the rule as being restricted to a routing table because it >> included 'or the current next-hop neighbor'. I agree that could be >> interpreted as a router, but it could also be just the destination pointed >> to by the NC entry. How about 'or the current next-hop in the neighbor cache >> for DB is known to be unreachable'? > But in this case the next-hop wouldn't be known to be unreachable - its state > would be unknown. > Not until traffic is actually sent towards the next-hop can NUD detect > that it is unreachable. Well, I was just about to send exactly the same comment on the current version of the draft, and > Thus I think it makes sense to have an explicit mention of the > "assume all destinations on-link" case in this rule. I agree with you. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. our (KAME's) implementation uses a "default" route to make neighbor caches when there is no default router, which was called "broken" in this thread. But I'd rather say that the essential problem here is that the meaning of "route" is vague, and that such implementations like ours should be allowed as a possible interpretation of RFC 2461. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 5 16:19:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f75NIuA01555 for ipng-dist; Sun, 5 Aug 2001 16:18:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f75NIqD01548 for ; Sun, 5 Aug 2001 16:18:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06540 for ; Sun, 5 Aug 2001 16:18:52 -0700 (PDT) Received: from condor.isl.rdc.toshiba.co.jp (host217-33-136-94.ietf.ignite.net [217.33.136.94]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12793 for ; Sun, 5 Aug 2001 17:18:49 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by condor.isl.rdc.toshiba.co.jp (8.10.1/8.10.1) with ESMTP id f75NGVk02273; Mon, 6 Aug 2001 08:16:31 +0900 (JST) Date: Mon, 06 Aug 2001 08:16:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Lori Napoli" Cc: ipng@sunroof.eng.sun.com Subject: Re: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 31 Jul 2001 12:15:33 -0400, >>>>> "Lori Napoli" said: > If you have a multi-homed machine, and you don't have a route to a > particular destination, over which interface do you suggest the packet be > sent out over ? This is in response to the following statement: > from RFC 2461: > If the Default Router List is empty, > the sender assumes that the destination is on-link. (At least for me) RFC 2461 is not very clear for multiple-interfaces cases, so the selection of the outgoing interface is implementation dependent. Our (KAME's) implementation introduces the notion of "default interface", which should manually be specified by the user. The kernel uses the default interface as the outgoing interface in this case. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 6 00:34:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f767WWs02098 for ipng-dist; Mon, 6 Aug 2001 00:32:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f767WSD02091; Mon, 6 Aug 2001 00:32:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02497; Mon, 6 Aug 2001 00:32:28 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29580; Mon, 6 Aug 2001 01:32:23 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f767VwT01656; Mon, 6 Aug 2001 14:31:59 +0700 (ICT) From: Robert Elz To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> <6947.997018207@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 06 Aug 2001 14:31:58 +0700 Message-ID: <1654.997083118@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 05 Aug 2001 09:18:47 -0700 From: "D. J. Bernstein" Message-ID: | You're saying that the I.AM administrators _chose_ to make their domain | only sporadically reachable by BIND 8 caches around the Internet? No, of course not. That seems to have been the result of a straight out implementation bug. When that kind of thing happens, the domain admins will generally find a way to avoid the bug (which seems to be what happened here), at the same time, the implementation should be fixing the bug so it doesn't bite others. | A cache can't let a single lookup consume | arbitrary amounts of memory! See RFC 1034, section 5.3.3. Of course it can't. So an administrator will make sure not to ask too much of caches, by creating rational configuration that remains well within reasonable limits. That's what people are doing now - the DNS actually works... (despite all these theoretical demonstrations that it can't possibly work... and the occasional reported case of things not working). | If people start relying on A6 and DNAME, this type of failure---and the | other two types described in http://cr.yp.to/djbdns/killa6.html---will | become much more common. Are you going to claim that the victims _chose_ | to screw up their own DNS service? No, and perhaps for a while, we will see some more failures, while people experiment, and before they learn what works. Everything has costs, A6 included, A6's added complexity, and hence more opportunities to accidentally configure things badly is one of those costs. Fortunately, A6 also has a trivial workaround for anyone who isn't sure what is a good config, and what isn't - they can always just use A6 0, and be just as safe as if they had used AAAA. No question about it. But with A6, I can use a more complex config if I feel confident of it. With AAAA I cannot. What's more, you can always use A6 as a chance to demonstrate your server indirection if you like - implement A6, and for any A6 n (n > 0) that gets loaded, have your server go and fetch all of the rest of the chain, and keep it up to date, so it is always there to be sent to clients in one packet, so the client can always get all of the data quickly. Sure the client will need to expend a little more CPU time combining the RR values (either the end resolver, or some back end resolver doing AAAA synthesis), but in the grand scheme of things, that's trivial. [Aside: just in case anyone thinks otherwise, this isn't just a challenge to do something I think is a dumb idea - on the contrary, I have for a long time believed that this is just what servers should be doing, for MX, and NS, and everything else where there could be a benefit - it is only the "too much work" arguments that have persuaded me not to try to make this at the very least a BCP as recommended practice for all servers]. 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 Mon Aug 6 01:17:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f768GV902191 for ipng-dist; Mon, 6 Aug 2001 01:16:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f768GRD02184 for ; Mon, 6 Aug 2001 01:16:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24140 for ; Mon, 6 Aug 2001 01:16:03 -0700 (PDT) Received: from email5.etsi.org (email5.etsi.fr [212.234.161.50]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00097 for ; Mon, 6 Aug 2001 01:16:02 -0700 (PDT) Received: by EMAIL5 with Internet Mail Service (5.5.2653.19) id ; Mon, 6 Aug 2001 10:15:22 +0200 Message-ID: From: Philippe Cousin To: "'JINMEI Tatuya / ????'" , Brian Zill Cc: ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU Subject: RE: Ad-hoc IPv6 inter-op session at London IETF Date: Mon, 6 Aug 2001 10:15:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk note that we are organising an IPv6 interop event on 19-23 November , Nice, France and this topic can be put in the list. (info on www.etsi.org/plugtests/) Philippe Cousin ETSI Interop service -----Original Message----- From: jinmei@kame.net [mailto:jinmei@kame.net] Sent: 05 August 2001 20:40 To: Brian Zill Cc: ipng@sunroof.eng.sun.com; ipv6imp@munnari.OZ.AU Subject: Re: Ad-hoc IPv6 inter-op session at London IETF >>>>> On Tue, 31 Jul 2001 18:48:03 -0700, >>>>> "Brian Zill" said: > At the recent ipng/ngtrans interim meeting in Redmond, we had an ad-hoc > IPv6 inter-op session which was surprisingly well-attended given that we > decided to do it at the last minute. Some real testing was actually > accomplished, and it was also a mildly fun social event. I was > wondering if anyone would be interested in doing this again? (snip) > I'm thinking Thursday night would be best since there is nothing on the > official agenda and we should all still be around since Friday morning > is the second ipngwg session. Other suggestions welcome. I'm interested in how implementations respond to Neighbor Solicitation messages on a p2p link, with or without source link-layer address options, in order to know the current situation about the interoperability issue described in Section 3 of draft-ietf-ipngwg-p2p-pingpong-00.txt. We can easily test this if the implementation supports configured tunnels (which is highly likely), and we'll need no additional subnets for the test. In terms of the motivation above, I wish to do the test for router implementations, and would like router vendors to join the event if they can set a tunnel to their labs. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 6 09:26:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76GQ1w03881 for ipng-dist; Mon, 6 Aug 2001 09:26:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76GPvD03874 for ; Mon, 6 Aug 2001 09:25:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11573 for ; Mon, 6 Aug 2001 09:26:03 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24894 for ; Mon, 6 Aug 2001 09:26:02 -0700 (PDT) Received: from localhost (host217-33-136-94.ietf.ignite.net [217.33.136.94]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA19810; Tue, 7 Aug 2001 01:28:46 +0900 (JST) Date: Tue, 07 Aug 2001 01:23:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU Subject: Re: Ad-hoc IPv6 inter-op session at London IETF In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 14 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 6 Aug 2001 10:15:48 +0200 , >>>>> Philippe Cousin said: > note that we are organising an IPv6 interop event on 19-23 November , Nice, > France > and this topic can be put in the list. (info on www.etsi.org/plugtests/) Hmm, it'll be nice if it can, though I myself not sure if I can attend the event... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 6 13:25:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76KOGT04952 for ipng-dist; Mon, 6 Aug 2001 13:24:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76KOBD04945 for ; Mon, 6 Aug 2001 13:24:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05202; Mon, 6 Aug 2001 13:24:14 -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 OAA16441; Mon, 6 Aug 2001 14:24:13 -0600 (MDT) Received: from localhost (host217-33-136-94.ietf.ignite.net [217.33.136.94]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id FAA21287; Tue, 7 Aug 2001 05:25:40 +0900 (JST) Date: Tue, 07 Aug 2001 05:20:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 58 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 26 Jul 2001 23:52:42 +0200 (CEST), >>>>> Erik Nordmark said: >> I've just read the previous discussion. It seems to me that we've >> basically reached a consensus for the receiving side; obsolete the >> IPV6_RECVRTHDRDSTOPTS option, and let the kernel send all headers (if >> requested) to applications in the receiving order. > As I recall this isn't sufficient. Some applications will need to be able > to tell e.g. whether a destination options header was before or after an ESP > header. For constency it would make sense to also be able to tell the > location of AH headers. > A possible solution would be to define IPV6_RECVESPHDR/IPV6_RECVAHHDR > and IPV6_ESPHDR/IPV6AHHDR. The latter two would be passed up as ancillary > data items of zero length (i.e. they would just be markers identifying > the location of the ESP/AH headers in the received packet). Ah, yes. We may need this stuff as well. I meant this additional stuff in my message above, but I was not enough clear, sorry. Anyway, it's not so complicated, and I think we do not see much trouble to reach consensus on this. >> For the sending side, which would be the difficult part, I think we >> have two possible approaches. >> >> 1. try to realize the full flexibility about the header chain; the API >> allows applications to specify any combination of headers (in any >> order). >> 2. only loosen the restriction about destination options headers; >> (e.g.) add another ancillary data type/socket option to specify the >> relationship between a destination options header and a fragment >> header. > I think #2 is sufficient as a goal. > But assuming we want to solve this both for sticky options and > ancillary data it might turn out that a resonable solution would > actually solve #1 as well. > (For instance, the sticky option case could be solved by making the option > buffer carry an addition"index" identifying which extension header the > setsockopt refers to in the sequence starting with the IPv6 header (1st, 2nd, > etc). Such a solution would allow specifying any order.) Through the succeeding discussion, I guess the reasonable way is - fix the current spec with as small changes as possible (i.e. basically #2 above), and - try to get further generalization (i.e. the #1 above) as a separate spec. Now we are about to compile the todo list and to write a new revision. So let's concentrate on the 1st step for now, and discuss it after the new revision is out. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 6 14:18:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76LHtD05406 for ipng-dist; Mon, 6 Aug 2001 14:17:55 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76LHoD05399 for ; Mon, 6 Aug 2001 14:17:50 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f76LHm212991; Mon, 6 Aug 2001 23:17:49 +0200 (MET DST) Date: Mon, 6 Aug 2001 23:15:20 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Lori Napoli , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > (At least for me) RFC 2461 is not very clear for multiple-interfaces > cases, so the selection of the outgoing interface is implementation > dependent. RFC 2461 explicitly states that multihoming (which should have said multi-interfaced hosts) is out of scope. > Our (KAME's) implementation introduces the notion of "default > interface", which should manually be specified by the user. The > kernel uses the default interface as the outgoing interface in this > case. Is the same default interface also the default for originating multicast packets? Or do you have a separate default when no IPv6_MULTICAST_IF is specified? 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 Aug 6 14:32:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76LVXV05463 for ipng-dist; Mon, 6 Aug 2001 14:31:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76LVTD05456 for ; Mon, 6 Aug 2001 14:31:29 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00869; Mon, 6 Aug 2001 14:31:35 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16547; Mon, 6 Aug 2001 14:31:35 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id QAA20064; Mon, 6 Aug 2001 16:29:24 -0500 Received: from d04nm300.raleigh.ibm.com (d04nm300.raleigh.ibm.com [9.67.226.185]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f76LVSe70954; Mon, 6 Aug 2001 17:31:28 -0400 Importance: Normal Sensitivity: Subject: Re: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt To: Erik Nordmark Cc: JINMEI Tatuya / =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Mon, 6 Aug 2001 17:30:51 -0400 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 08/06/2001 05:31:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Our implementation uses a concept of default interface by piggybacking that concept on the routing table. If a customer wants a default interface, they can code a default route using that interface. This then would be the same default interface that would be used for multicast traffic if no MULTICAST_IF setsockopt was issued. Lori z/OS Communications Server Development - TCP/IP Stack 919-254-6146 T/L 8-444-6146 E-mail: lanapoli@us.ibm.com Erik Nordmark on 08/06/2001 05:15:20 PM Please respond to Erik Nordmark To: JINMEI Tatuya / $B?@L@C#:H(B cc: Lori Napoli/Raleigh/IBM@IBMUS, ipng@sunroof.eng.sun.com Subject: Re: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt > (At least for me) RFC 2461 is not very clear for multiple-interfaces > cases, so the selection of the outgoing interface is implementation > dependent. RFC 2461 explicitly states that multihoming (which should have said multi-interfaced hosts) is out of scope. > Our (KAME's) implementation introduces the notion of "default > interface", which should manually be specified by the user. The > kernel uses the default interface as the outgoing interface in this > case. Is the same default interface also the default for originating multicast packets? Or do you have a separate default when no IPv6_MULTICAST_IF is specified? 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 Aug 6 15:02:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76M1Zf05545 for ipng-dist; Mon, 6 Aug 2001 15:01:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76M1UD05538; Mon, 6 Aug 2001 15:01:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07672; Mon, 6 Aug 2001 15:01:37 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23288; Mon, 6 Aug 2001 16:01:37 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GHO00EOU2DBZ2@smtp.fnal.gov>; Mon, 06 Aug 2001 16:58:23 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f76LvDm21797; Mon, 06 Aug 2001 16:57:17 -0500 (CDT) Date: Mon, 06 Aug 2001 16:57:13 -0500 From: Matt Crawford Subject: Re: Joint DNSEXT & NGTRANS agenda In-reply-to: "02 Aug 2001 13:37:24 BST." To: alh-ietf@tndh.net Cc: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Message-id: <200108062157.f76LvDm21797@gungnir.fnal.gov> MIME-version: 1.0 X-Mailer: exmh version 2.0.2 2/24/98 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Gee, I almost wish there had been time to catch up on mail before today...) > Even if it is only a few records a couple of times a year, the > customers will quickly bail and find a provider that can deal > with the entropy. This is just another case of the point of pain > not matching with the gain, so it simply won't happen. These customers that bolt to avoid renumbering -- they will take their portable IPv6 address blocks with them? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 6 15:55:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76MtD605843 for ipng-dist; Mon, 6 Aug 2001 15:55:13 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76MtBD05836 for ; Mon, 6 Aug 2001 15:55:11 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f76MrW201680 for ipng@sunroof.eng.sun.com; Mon, 6 Aug 2001 15:53:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71L1wD15350; Wed, 1 Aug 2001 14:01:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20928; Wed, 1 Aug 2001 14:02:12 -0700 (PDT) Received: from gulag.araneus.fi ([63.197.0.204]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA18602; Wed, 1 Aug 2001 15:03:41 -0600 (MDT) Received: (from gson@localhost) by gulag.araneus.fi (8.9.3/8.6.12) id NAA02147; Wed, 1 Aug 2001 13:55:58 -0700 (PDT) Date: Wed, 1 Aug 2001 13:55:58 -0700 (PDT) Message-Id: <200108012055.NAA02147@gulag.araneus.fi> To: Robert Elz Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: <20010801124445.30844.qmail@cr.yp.to> <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > From: "D. J. Bernstein" > | This ``perverse method'' has been used by all versions of BIND since > | 1997, and of course by every version of my cache. The need for it is > | explained in detail in http://cr.yp.to/djbdns/notes.html. > > I haven't looked to see whether BIND really does that or not, but there > is certainly no need for it (and I actually doubt it a bit). This time, DJB is correct. When resolving, BIND 8 and 9 do reject all records that are not within the domain whose authoritative qservers are being queried. If they did not, we would be seeing much more cases of cache poisoning that we do now. -- Andreas Gustafsson, gson@nominum.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 Aug 6 15:56:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76MtY905856 for ipng-dist; Mon, 6 Aug 2001 15:55:34 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76MtWD05849 for ; Mon, 6 Aug 2001 15:55:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f76Mrqh01710 for ipng@sunroof.eng.sun.com; Mon, 6 Aug 2001 15:53:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7268oD16880; Wed, 1 Aug 2001 23:08:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA17321; Wed, 1 Aug 2001 23:09:05 -0700 (PDT) Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA19100; Wed, 1 Aug 2001 23:09:04 -0700 (PDT) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id CAA08844; Thu, 2 Aug 2001 02:08:55 -0400 Message-Id: <200108020608.CAA08844@egyptian-gods.MIT.EDU> To: gson@nominum.com (Andreas Gustafsson) cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: Your message of "Wed, 01 Aug 2001 14:11:23 PDT." Date: Thu, 02 Aug 2001 02:08:55 -0400 From: Greg Hudson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This time, DJB is correct. When resolving, BIND 8 and 9 do reject > all records that are not within the domain whose authoritative > qservers are being queried. If they did not, we would be seeing > much more cases of cache poisoning that we do now. To be precise: to avoid cache poisoning, out of domain records must not be used for future queries. There is no problem with using them for the purpose of the current query, although that may be considered too complicated to implement. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 6 15:56:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76Mu2o05880 for ipng-dist; Mon, 6 Aug 2001 15:56:02 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76MtxD05871 for ; Mon, 6 Aug 2001 15:55:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f76MsKp01740 for ipng@sunroof.eng.sun.com; Mon, 6 Aug 2001 15:54:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72CP1D18274 for ; Thu, 2 Aug 2001 05:25:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22324 for ; Thu, 2 Aug 2001 05:24:57 -0700 (PDT) Received: from home.ds9a.nl (20dyn209.com21.casema.net [213.17.90.209]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA13325 for ; Thu, 2 Aug 2001 06:24:54 -0600 (MDT) Received: (qmail 19709 invoked by uid 500); 2 Aug 2001 12:20:40 -0000 Date: Thu, 2 Aug 2001 14:20:40 +0200 From: bert hubert To: Robert Elz Cc: Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda Message-ID: <20010802142039.S19075@home.ds9a.nl> Mail-Followup-To: bert hubert , Robert Elz , Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@brandenburg.cs.mu.OZ.AU> <20010729135707.10649.qmail@cr.yp.to> <2263.996661600@brandenburg.cs.mu.OZ.AU> <2062.996749378@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2062.996749378@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Thu, Aug 02, 2001 at 05:49:38PM +0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Aug 02, 2001 at 05:49:38PM +0700, Robert Elz wrote: > | When resolving, BIND 8 and 9 do reject > | all records that are not within the domain whose authoritative > | qservers are being queried. > > That's broken, and should be fixed. If it really is as you have > explained it, it guarantees that some perfectly legal DNS configurations > can never be properly resolved. We had that problem. This leads to frantic phonecalls from Verisign, who explained it all very clearly and kindly suggested we move to using glue records ASAP. Verisign sees a very large number of requests on the (gtld?) rootservers for your nameservers otherwise. The situation was like this: At Amnic: I.AM NS select.powerdns.com. I.AM NS mincore.powerdns.com. At the GTLD servers: powerdns.com NS dns-us1.powerdns.net. powerdns.com NS dns-eu1.powerdns.net. dns-us1.powerdns.net A 63.123.33.130 dns-eu1.powerdns.net A 213.244.168.217 on the dns-{us,eu}1.powerdns.net: select.powerdns.com A 212.72.48.170 mincore.powerdns.com A 204.198.135.70 This sequence does not allow WWW.I.AM to be resolved by Bind 8.2.3. If you start from an empty cache, bind will not believe the answers it gets, and get stuck. We've now moved the I.AM NS records to the glued ns1.i.am and ns2.i.am, which get sent in the additional section, thus helping bind. I'm by nature not a bind-basher since I think it is unwise for competitors to throw mud at eachother, but this *is* rather silly behaviour. Having said that, writing a recursing nameserver is very difficult - so far we stick to only being authoritative. Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 6 15:57:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76MuPn05900 for ipng-dist; Mon, 6 Aug 2001 15:56:25 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76MuND05893 for ; Mon, 6 Aug 2001 15:56:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f76Msh601770 for ipng@sunroof.eng.sun.com; Mon, 6 Aug 2001 15:54:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72FpTD19378; Thu, 2 Aug 2001 08:51:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12307; Thu, 2 Aug 2001 08:51:30 -0700 (PDT) Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09367; Thu, 2 Aug 2001 08:51:26 -0700 (PDT) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id LAA09723; Thu, 2 Aug 2001 11:51:15 -0400 Message-Id: <200108021551.LAA09723@egyptian-gods.MIT.EDU> To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: Your message of "Thu, 02 Aug 2001 07:50:57 PDT." Date: Thu, 02 Aug 2001 11:51:15 -0400 From: Greg Hudson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Wrong. Server-side indirection never causes loops. You would > understand this if you read my web page: > http://cr.yp.to/djbdns/killa6.html I read your web page (just now) and I don't understand that server-side indirection never causes loops. Before the isc.org server can serve the address of ftp.isc.org, it has to have looked up the address of isrv4.pa.vix.com. If the pa.vix.com server is misconfigured and has a "server-side cname" pointing back to ftp.isc.org, it could be unable to serve the isrv4.pa.vix.com address before looking up the address of ftp.isc.org. That sounds like a loop to me. The two servers might detect the loop and behave intelligently, but so can a client. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 6 15:57:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76MukA05918 for ipng-dist; Mon, 6 Aug 2001 15:56:46 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76MuiD05911 for ; Mon, 6 Aug 2001 15:56:44 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f76Mt4C01800 for ipng@sunroof.eng.sun.com; Mon, 6 Aug 2001 15:55:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f72GTjD19545; Thu, 2 Aug 2001 09:29:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19553; Thu, 2 Aug 2001 09:29:38 -0700 (PDT) Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [209.151.24.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10648; Thu, 2 Aug 2001 10:29:28 -0600 (MDT) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id MAA01440; Thu, 2 Aug 2001 12:27:07 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca ([2001:410:402:2:204:76ff:fe2d:8c]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f72GQMF10353 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 2 Aug 2001 12:27:13 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f72GGAw00135; Thu, 2 Aug 2001 12:16:10 -0400 (EDT) Message-Id: <200108021616.f72GGAw00135@marajade.sandelman.ottawa.on.ca> To: namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Re: Joint DNSEXT & NGTRANS agenda In-reply-to: Your message of "02 Aug 2001 12:02:46 -0000." <20010802120246.31021.qmail@cr.yp.to> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 02 Aug 2001 12:16:09 -0400 From: Michael Richardson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My main fear about A6 is documentation: it seems too complicated, and the failure cases for it seem very hard to explain to muggles. Muggles have enough time maintaining IPv4 DNS records without DNSSEC. I am not certain if DJB is correct about the technical argument about signatures. I do not have a problem resigning my zones every day. I think that I have enough CPU. Maybe this won't be true for ccTLDs, etc. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 6 15:58:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76MvXH05949 for ipng-dist; Mon, 6 Aug 2001 15:57:33 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76MvUD05942 for ; Mon, 6 Aug 2001 15:57:31 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f76MtpY01830 for ipng@sunroof.eng.sun.com; Mon, 6 Aug 2001 15:55:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f74Fd7D27765; Sat, 4 Aug 2001 08:39:08 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09476; Sat, 4 Aug 2001 08:39:07 -0700 (PDT) Received: from gulag.araneus.fi ([63.197.0.204]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21829; Sat, 4 Aug 2001 08:39:07 -0700 (PDT) Received: (from gson@localhost) by gulag.araneus.fi (8.9.3/8.6.12) id IAA01336; Sat, 4 Aug 2001 08:36:00 -0700 (PDT) Date: Sat, 4 Aug 2001 08:36:00 -0700 (PDT) Message-Id: <200108041536.IAA01336@gulag.araneus.fi> To: Masataka Ohta Cc: Robert Elz , Andreas Gustafsson , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> References: <2062.996749378@brandenburg.cs.mu.OZ.AU> <200108040715.QAA02195@necom830.hpcl.titech.ac.jp> From: gson@nominum.com (Andreas Gustafsson) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta writes: > > How? No-one is suggesting that these records be put in the cache. > > I have been suggesting that these records be put in a referral-local > cache content of which is not used for usual A query nor glue A of > other referral points. I think that's an excellent approach, and one that should be seriously considered when designing new resolver implementations. BIND 8 and 9 have the concept of a single, global cache too deeply ingrained to be changed at this point. -- Andreas Gustafsson, gson@nominum.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 Aug 6 16:50:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f76Nnmk06262 for ipng-dist; Mon, 6 Aug 2001 16:49:48 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76NnkD06255 for ; Mon, 6 Aug 2001 16:49:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f76Nm7r01962 for ipng@sunroof.eng.sun.com; Mon, 6 Aug 2001 16:48:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76NTcD06191 for ; Mon, 6 Aug 2001 16:29:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27277 for ; Mon, 6 Aug 2001 16:29:43 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10740 for ; Mon, 6 Aug 2001 16:29:43 -0700 (PDT) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id QAA18642; Mon, 6 Aug 2001 16:29:12 -0700 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Mon, 6 Aug 2001 16:29:11 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org Subject: Re: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 In-Reply-To: <200107272030.NAA06020@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [ NOTE: this is cross-posted to the MIBS list because the discussion concerns both IPv4 and IPv6. The "new MIBS" referred to are those in draft-ietf-ipngwg-rfc2011-update-00.txt, draft-ietf-ipngwg-rfc2012-update-00.txt, draft-ietf-ipngwg-rfc2013-update-00.txt, and draft-ietf-ipngwg-rfc2096-update-00.txt. ] On Fri, 27 Jul 2001, Bill Fenner wrote: > The plan is to deprecate the existing objects in these RFCs > in favor of the protocol-independent ones. The exact plan is not > yet known (e.g. publish a new revision with all objects listed > as deprecated vs. reclassify the old RFCs as historic, etc.). And as one can see explicitly from the drafts themselves, the intent is also to deprecate all of the IPv4-specific stuff in RFC 2011, RFC 2012, RFC 2013, and RFC 2096. Note that the MIB modules in the first three of these RFCs are simply translations into SMIv2 of the MIB-II IP group (less routing table), TCP group, and UDP group, respectively; the substance is unchanged from RFC 1213. > The intent is definitely not to suddenly cause existing implementations > to be non-standard, but to encourage evolution. But that's PRECISELY what adoption of these drafts in their present form would do. Where new compliance statements exist, they make the new version-independent objects unconditionally mandatory and don't mention the version-specific objects. That makes existing implementations non-compliant and (if the drafts were to be adopted as standards) non-standard. Notice that it is not just existing implementations of the existing IPv6 MIBs in RFC 2452, RFC 2454, RFC 2465, and RFC 2466 that would be destandardized, but also existing implementations of the MIB-II IP, TCP, and UDP groups. The older IPv4-specific objects have in all cases been deprecated in favor of the new protocol-independent objects, and so have the old IPv4-specific compliance statements. In the case of the draft IP MIB there would be some gain in functionality for an IPv4-only implementation in the form of per-interface statistics. Since providing this functionality would require new objects anyway, so it's reasonable to provide them in a version-independent manner. On the other hand, it's news to me that there has been a significant demand from actual users for this feature (correction from actual users is invited), particularly at the cost of backward compatibility. In the case of the TCP and UDP MIBs there is no gain in functionality for an IPv4-only implementation apart from high-capacity counters, and those are protocol-neutral anyway. Apart from those counters, the old MIB-II stuff for IPv4 supplemented by the IPv6 TCP connection table in RFC 2452 and the IPv6 UDP listener table in RFC 2454 seem to provide the same functionality. I don't see any problem that the draft solve by replacing the version-specific tables, but I see plenty of problems that they would create by having new implementations not being backward compatible with old ones, not to mention implementation churn. Is it really worth all that to fix what to fix what is essentially an aesthetic flaw? Better the approach of RFC 2452 and RFC 2454, which would leave IPv4-only implementations intact. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 01:41:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f778eRW07377 for ipng-dist; Tue, 7 Aug 2001 01:40:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f778eMD07370 for ; Tue, 7 Aug 2001 01:40:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08666; Tue, 7 Aug 2001 01:40:26 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25759; Tue, 7 Aug 2001 01:40:22 -0700 (PDT) Received: from localhost (host217-33-136-94.ietf.ignite.net [217.33.136.94]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA25872; Tue, 7 Aug 2001 17:43:01 +0900 (JST) Date: Tue, 07 Aug 2001 10:00:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 6 Aug 2001 23:15:20 +0200 (CEST), >>>>> Erik Nordmark said: >> (At least for me) RFC 2461 is not very clear for multiple-interfaces >> cases, so the selection of the outgoing interface is implementation >> dependent. > RFC 2461 explicitly states that multihoming (which should have said > multi-interfaced hosts) is out of scope. Ah, correct. I should've been clearer on this. >> Our (KAME's) implementation introduces the notion of "default >> interface", which should manually be specified by the user. The >> kernel uses the default interface as the outgoing interface in this >> case. > Is the same default interface also the default for originating multicast > packets? Yes, sometimes, and indirectly. Actually, when the kernel tries to send a multicast packet without any hints on the outgoing interface, it looks up the routing table to determine the outgoing interface. Since the multicast destination only matches the default route (unless there is a more specific multicast route in the kernel), the kernel sends the packet to the outgoing interface of the default route. As I said before (in another thread?), if there is no default router, and the default interface is specified, then the kernel installs a "default route" to the interface to make neighbor cache for every destination. Consequently, multicasted packets without any hints will be sent on the default interface. If we have a default router, though, the packet will be sent to the interface to the (currently preferred) default router, the interface which may be different from the "default interface." JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 03:12:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77ABiP07932 for ipng-dist; Tue, 7 Aug 2001 03:11:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77ABdD07925; Tue, 7 Aug 2001 03:11:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04132; Tue, 7 Aug 2001 03:11:44 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11197; Tue, 7 Aug 2001 04:11:47 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GHP00GHT0BHK9@smtp.fnal.gov>; Tue, 07 Aug 2001 05:11:41 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f77AAYm24838; Tue, 07 Aug 2001 05:10:34 -0500 (CDT) Date: Tue, 07 Aug 2001 05:10:34 -0500 From: Matt Crawford Subject: Joint DNSEXT & NGTRANS summary To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Message-id: <200108071010.f77AAYm24838@gungnir.fnal.gov> X-Mailer: exmh version 2.0.2 2/24/98 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have overheard nearly opposite outcomes quoted by random people in the halls, and some of the joint co-chairs (all the ones I've asked so far) seem reluctant to say anything substantive in public about the outcome of the joint dnsext/ngtrans meeting. I know there are some interested parties who were not present and I have no idea whether or how well they heard it on the mbone. So, here's my view from the floor ... other views would be welcome, the sooner the better. There was a lot of discussion, culminating with a "hum" on the following four choices: 1. Deploy A6 in full panoply, synthesize AAAA for transition period 2. Deploy A6 conservatively ("A6 0"), synthesize as above 3. Reclassify A6 as experimental, use AAAA for production 4. Reclasify A6 as historic, use AAAA for production. The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all accounts. There was quite obviously no consensus (i.e., unanimity) or rough consensus (in the usual IETF sense of near-unanimity). It could not even be concluded that the loudest hum represented a majority of those voicing an opinion. The difference in impressions taken away, therefore, I would account for by differences in opinion about whether the preference of a plurality, possibly a slim majority, represent a decision to alter the status quo. (That being A6 on the standards track.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 03:18:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77AIEN07989 for ipng-dist; Tue, 7 Aug 2001 03:18:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77AI9D07982; Tue, 7 Aug 2001 03:18:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29330; Tue, 7 Aug 2001 03:18:15 -0700 (PDT) Received: from starfruit.itojun.org (host217-33-137-35.ietf.ignite.net [217.33.137.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25928; Tue, 7 Aug 2001 04:18:12 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id AA1BA7BA; Tue, 7 Aug 2001 19:16:29 +0900 (JST) To: Matt Crawford Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: crawdad's message of Tue, 07 Aug 2001 05:10:34 EST. <200108071010.f77AAYm24838@gungnir.fnal.gov> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Tue, 07 Aug 2001 19:16:29 +0900 Message-Id: <20010807101629.AA1BA7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >1. Deploy A6 in full panoply, synthesize AAAA for transition period >2. Deploy A6 conservatively ("A6 0"), synthesize as above >3. Reclassify A6 as experimental, use AAAA for production >4. Reclasify A6 as historic, use AAAA for production. > >The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all >accounts. There was quite obviously no consensus (i.e., unanimity) I would say 3 >> 2 > 1 > 4, heard from my location (near the VGA projector). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 03:19:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77AJ7R08026 for ipng-dist; Tue, 7 Aug 2001 03:19:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77AIfD07991; Tue, 7 Aug 2001 03:18:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA10346; Tue, 7 Aug 2001 03:18:36 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29934; Tue, 7 Aug 2001 03:18:36 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f77AIYm21450; Tue, 7 Aug 2001 03:18:34 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f77AIY619105; Tue, 7 Aug 2001 03:18:34 -0700 Message-Id: <200108071018.f77AIY619105@zed.isi.edu> Subject: Re: Joint DNSEXT & NGTRANS summary To: crawdad@fnal.gov (Matt Crawford) Date: Tue, 7 Aug 2001 03:18:33 -0700 (PDT) Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108071010.f77AAYm24838@gungnir.fnal.gov> from "Matt Crawford" at Aug 07, 2001 05:10:34 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % There was a lot of discussion, culminating with a "hum" on the % following four choices: % % 1. Deploy A6 in full panoply, synthesize AAAA for transition period % 2. Deploy A6 conservatively ("A6 0"), synthesize as above % 3. Reclassify A6 as experimental, use AAAA for production % 4. Reclasify A6 as historic, use AAAA for production. I took a (perhaps) stricter view on these four choices: 1) A6 stays on Stds track, syth AAAA when needed, AAAA is depricated 2) A6 stays on Stds track, tempered by a recommendation to operationally use A6 0. 3) Leave AAAA on Stds track, move A6 to experimental. 4) Move A6 to historic, leave AAAA on Stds track. % The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all % accounts. There was quite obviously no consensus (i.e., unanimity) % or rough consensus (in the usual IETF sense of near-unanimity). It % could not even be concluded that the loudest hum represented a % majority of those voicing an opinion. That was my impression as well. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 03:29:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77ASdo08078 for ipng-dist; Tue, 7 Aug 2001 03:28:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77ASaD08071; Tue, 7 Aug 2001 03:28:36 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16308; Tue, 7 Aug 2001 03:28:41 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA04262; Tue, 7 Aug 2001 03:28:40 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA10639; Tue, 7 Aug 2001 06:28:30 -0400 Date: Tue, 7 Aug 2001 06:28:30 -0400 (EDT) From: Jim Bound To: Matt Crawford Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108071010.f77AAYm24838@gungnir.fnal.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I felt consensus for number 3 is my input. /jim On Tue, 7 Aug 2001, Matt Crawford wrote: > I have overheard nearly opposite outcomes quoted by random people > in the halls, and some of the joint co-chairs (all the ones I've > asked so far) seem reluctant to say anything substantive in public > about the outcome of the joint dnsext/ngtrans meeting. I know there > are some interested parties who were not present and I have no idea > whether or how well they heard it on the mbone. So, here's my > view from the floor ... other views would be welcome, the sooner > the better. > > There was a lot of discussion, culminating with a "hum" on the > following four choices: > > 1. Deploy A6 in full panoply, synthesize AAAA for transition period > 2. Deploy A6 conservatively ("A6 0"), synthesize as above > 3. Reclassify A6 as experimental, use AAAA for production > 4. Reclasify A6 as historic, use AAAA for production. > > The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all > accounts. There was quite obviously no consensus (i.e., unanimity) > or rough consensus (in the usual IETF sense of near-unanimity). It > could not even be concluded that the loudest hum represented a > majority of those voicing an opinion. > > The difference in impressions taken away, therefore, I would account > for by differences in opinion about whether the preference of a > plurality, possibly a slim majority, represent a decision to alter the > status quo. (That being A6 on the standards track.) > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 05:18:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77CIPE08357 for ipng-dist; Tue, 7 Aug 2001 05:18:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77CILD08350; Tue, 7 Aug 2001 05:18:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13366; Tue, 7 Aug 2001 05:18:27 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24848; Tue, 7 Aug 2001 06:18:24 -0600 (MDT) Received: from CLASSIC.viagenie.qc.ca (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f77CfmQ57470; Tue, 7 Aug 2001 08:41:48 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010807080026.034287b0@127.0.0.1> X-Sender: blanchet@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 Aug 2001 08:01:17 -0400 To: Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Marc Blanchet Subject: Re: Joint DNSEXT & NGTRANS summary In-Reply-To: <200108071010.f77AAYm24838@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While I vote for 3, I do agree with your reading that: - 3 > others - the hummm was not cristal clear. Marc. At/ 05:10 2001-08-07 -0500, Matt Crawford you wrote/vous criviez: >I have overheard nearly opposite outcomes quoted by random people >in the halls, and some of the joint co-chairs (all the ones I've >asked so far) seem reluctant to say anything substantive in public >about the outcome of the joint dnsext/ngtrans meeting. I know there >are some interested parties who were not present and I have no idea >whether or how well they heard it on the mbone. So, here's my >view from the floor ... other views would be welcome, the sooner >the better. > >There was a lot of discussion, culminating with a "hum" on the >following four choices: > >1. Deploy A6 in full panoply, synthesize AAAA for transition period >2. Deploy A6 conservatively ("A6 0"), synthesize as above >3. Reclassify A6 as experimental, use AAAA for production >4. Reclasify A6 as historic, use AAAA for production. > >The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all >accounts. There was quite obviously no consensus (i.e., unanimity) >or rough consensus (in the usual IETF sense of near-unanimity). It >could not even be concluded that the loudest hum represented a >majority of those voicing an opinion. > >The difference in impressions taken away, therefore, I would account >for by differences in opinion about whether the preference of a >plurality, possibly a slim majority, represent a decision to alter the >status quo. (That being A6 on the standards track.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 06:54:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77Drtk08855 for ipng-dist; Tue, 7 Aug 2001 06:53:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77DrqD08848 for ; Tue, 7 Aug 2001 06:53:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04279 for ; Tue, 7 Aug 2001 06:53: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 HAA25509 for ; Tue, 7 Aug 2001 07:53: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 GAA09412; Tue, 7 Aug 2001 06:53:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f77Drhp15996; Tue, 7 Aug 2001 06:53:43 -0700 X-mProtect: Tue, 7 Aug 2001 06:53:43 -0700 Nokia Silicon Valley Messaging Protection Received: from host217-33-140-17.ietf.ignite.net (217.33.140.17, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdBVAtxh; Tue, 07 Aug 2001 06:53:39 PDT Message-Id: <4.3.2.7.2.20010807064504.01de8a68@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 06:53:25 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Updated IPng Agenda for London IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Updated agenda attached. Due to requests from some of the speakers the DNS discovery and USAGI talks were moved to Friday and Dialup talks were moved to Wednesday. Please let us know if this creates any problems. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------------- WEDNESDAY, August 8, 2001 1300-1500 ------------------------------------ Introduction / Steve Deering (5 min) Review Agenda / Steve Deering (5 min) Document & Charter Status / Bob Hinden (10 min) 3GPP-IETF Design team status / Bob Hinden (10 min) DNS Discovery / Dave Thaler (20 min) Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino (15 min) Avoiding ping-pong packets on point-to-point links / Jun-ichiro itojun Hagino (10 min) Multilink Subnets / Dave Thaler (20 min) DHCPv6 Status and Last Call / Ralph Droms (10 min) Minimum IPv6 Functionality for a Cellular Host / John Loughney (25 min) AAAv6 Status / Charlie Perkins (5 min) FRIDAY, August 10, 2001 0900-1130 ----------------------------------- IPv6 MIB Update Status / Bill Fenner (15 min) nnnn=2096,2011,2012,2013 IPv6 Site Renumbering / Christian Huitema (20 min) Source/Destination Address Selection / Brian Zill (15 min) Domain Name Auto-Registration for Plugged-in IPv6 Nodes / Hiroshi Kitamura (15 min) A proposal for the IPv6 Flow Label Specification / Alex Conta (30 min) An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min) Disconnecting TCP connection toward IPv6 anycast address / Jun-ichiro itojun Hagino (10 min) Socket API for IPv6 traffic class field / Jun-ichiro itojun Hagino (5min) Status of Linux and USAGI IPv6 / Yuji Sekiya (5 min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 06:58:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77Dvqm08900 for ipng-dist; Tue, 7 Aug 2001 06:57:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77DvVD08874; Tue, 7 Aug 2001 06:57:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28438; Tue, 7 Aug 2001 06:57:37 -0700 (PDT) Received: from ogud.com (208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com [208.59.114.172]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26027; Tue, 7 Aug 2001 06:57:36 -0700 (PDT) Received: from localhost (ogud@localhost) by ogud.com (8.11.3/8.11.2) with ESMTP id f77Du6e18006; Tue, 7 Aug 2001 09:56:07 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Tue, 7 Aug 2001 09:56:05 -0400 (EDT) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com cc: dnsop@cafax.se Subject: DNSEXT NGTRANS Joint meeting DRAFT minutes In-Reply-To: <20010807124125.D8C884A5@z.hactrn.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk DNS-EXT/NGTRANS joint meeting on How to represent IPv6 addresses in DNS IETF-51, London - 6 August 2001 Olafur Gudmundsson, Alain Durand & Tony Hain chairing Minutes by: Bob Fink, David Lawrence, Jun-ichiro itojun Hagino (thanks for great minutes) Edited by Bob Fink and Olafur Gudmundsson This is draft minutes, please send edits/corrections for final minutes before 23:00 London time Thursday (2001/08/09) to ogud@ogud.com ----- Agenda Introduction (2 min) - Olafur Bit labels (5 min) - Alain DNAME use in reverse IPv6 tree (5 min) - Alain AAAA vs A6 (60 min) - Alain Consensus building (40 min) - Tony Summary (8 min) -Olafur ----- Short names: Full names Alain Alain Durand Bob Bob Hinden Christian Christian Huitema Erik Erik Nordmark Itojun Jun-ichiro itojun Hagino Matt Matt Crawford Olafur Olafur Gudmundsson Perry Perry Metzger Randy Randy Bush Rob Rob Austein Steve Steve Deering Thomas Thomas Narten Tony Tony Hain Introduction Olafur explained that the meeting goal is to find rough consensus on how to go forward with representation of IPv6 addresses in DNS. The meeting output will be an ID summarizing the meeting consensus, which will be taken to the appropriate mailing list(s). ---- Bit labels - Alain Are bit labels necessary in IPv6 DNS reverse tree, and is anybody planning to delegate on the last 4 bits? Matt Crawford stated that Bit Labels are not necessary if you are willing to do the delegation hack on non-nibble boundaries. Rob Austein explained that the last 4 bits meant a /125 or larger. There was no response from the floor to the questions posed by Alain. Andrea Gustafsson asked for someone to clarify why last 4 bits are special. Randy Bush explained that the issue is allocations in the last label when using a text-based name format in the reverse tree. In IN-ADDR.ARPA that means allocations in the last octet; in the text based version of IP6.ARPA (nibbles, not bitlabels), that means allocations in the last nibble. Being there was no discussion, Alain moved on. -- DNAME use in reverse IPv6 tree - Do we need DNAME in the IPv6 reverse tree? Alain noted that other DNAME uses were out of scope for the discussion. Christian noted that if you really want renumbering on fly, DNAME is needed, thus it follows the decision on need for A6. Matt Crawford noted that there is value in forward tree, even if not in reverse tree. Michael Patton said that we if we do A6, require DNAME in reverse tree, but if AAAA only, there is some value. Matt said that DNAME can be used to keep reverse map in the same zone as direct map. Alain asked if this was still true if there were only AAAA and no A6. Matt said yes. Olafur summarized that, given the limited defense of DNAME it was a DNS decision on whether other uses of DNAME justified it. --- AAAA vs A6 - Does anybody have any other application that requires A6, that can not be done by back-end processing and are not covered by draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt? Christian noted a point only partially covered by Rob's ID. Assumption is a db with all systems listed. There are schemes where hosts push addresses to db and when renumbering, there are individual decision that 1000's of hosts could to update the DNS with. Perry Metzger stated that if one does the db right, then tools can do it cleanly, no special protocol hacks are needed. We only think not due to lack of tools. It's only a SMOP :-), like MOIRA (sp) at MIT. Matt Crawford noted that this still relies on tools not yet written. A6 buys ability to register as single RR in db for all prefixes as it goes. Perry understands desire, but believes tools are needed, and for more than A6. Jim Bound asked if, assuming backend processing (with better tools than we now have), to evaluate if A6 make it more efficient, and thus worth implementing in this context. Olafur said, yes, a natural representation in db looking something like A6, would help. Jim Bound responded if we then agree, lets focus in the direction A6 points. Bill Sommerfield - I worked on MOIRA (sp) at MIT (that Perry mentioned as example) and I don't think that is for all sites. Wrong to force on all sites where model might not fit. Matt Crawford noted that missing from questions is, we focus on "today", not if it is needed in future. E.g., changes in routing system might need A6. - Is IPv6 going to do rapid renumbering or GSE-like routing? Bob Hinden asked if hourly or daily likely? Weekly/monthly most likely, i.e., not all that rapid. Rapid renumbering was not an original (or even current) goal for IPv6. Tony GSE is a "per packet" renumbering Matt Crawford noted that there was lots of discussion for minimal allocation size (i.e., the /48 issue). There are other ways for a body/system to move that might require rapid renumbering. One can't say for sure rapid renumbering won't be needed, and thus A6. Margaret Wasserman asked if we ware talking automated renumbering or not. Rob stated that if IPv6 going to do automated renumbering frequently, that quad A can't cope with it, even with better tools, due to issues like resigning time Christian noted there are scenarios with several prefixes: e.g., one might toggle between them on a daily basis or faster. Christian felt that for fire exit usage, if renumbering not used often (to check that it works) it would never be used. Steve Deering felt that many sites will have to renumber enough to know protocol (and implementations) work. Christian noted that the argument on renumbering seems to be gated on resigning. He is not convinced that we can't do security right. Steve stated that on issues other than security, an important goal with IPv6 is to make renumbering easier, but to make it occur very fast is unsolved, for more than just DNS records. Thus if we do rapid renumbering, it will be a very different architecture, e.g., GSE, and it is likely that it would keep site ignorant of changes and thus A6 wouldn't help. Ted Hardy asked if there are there applications for rapid renumbering, that happen faster than route propagation, that fall under multi-homing. Renumbering that happens faster than route propagation won't work. Alex K (?) asked if we know what the future is. IPv6 will be used in new applications beyond our current Internet, and who knows what these uses are. Choice is either put A6 flexibility there for the future, or stop developing A6 now and invent something new in future. Jim Bound agreed w/Steve that one can't guarantee rapid renumbering. A6 is a tool that underwent significant development and that it is an abstraction like scoping, multi-casting, that adds quality to the IPv6 architecture. Users will need renumbering to adopt IPv6. Perry asked at what costs. DNS queries are under fire for getting slower. Confident that he could renumber in hours or days, but probably not faster. It does work with AAAA, though he admitted his experience was for a small site. Randy noted that the problem with doing A6 for possibility of rapid renumbering is following dreams, not reality. To get v6 traction, A6 not helping. Jim Bound agreed with Randy, but would like to see if A6 0 would work and do testbeds to see what works. Concerned that the code base (we now have) might be useful might be thrown away before we learn from it. Simon Leinen noted that the performance issues are not straight forward. A6 request might be handled faster than AAAA, when host has many addresses. Matt Crawford asked do you think we can deploy A6 later on and really get it deployed? Randy noted that playing with A6, IPv6 folk are maintaining their code better than v4 folk may be. If we do renumbering it is analogous to, "do we do the routing thing". A6 is a solution to a problem we haven't yet defined, and constrains our solutions in future. Rather solve our problems and solve DNS stuff after. Matt Crawford asked again if we can make a change in the future like that? Thomas Narten asked, if we do rapid renumbering, are other changes needed? Then couldn't putting in changes for DNS be done too? Steve Deering noted that we have AAAA, and going to A6 0 is a "no brainer", but if it is lots of work to change to A6 for a limited value, is it worth it? Someone (name please ??) asked if we do A6 0, isn't it really just as hard to do a full-blown A6 later? Theo Pagtzis asked how would A6 handle really rapid renumbering? Steve Deering noted again, Mobile IP could do it, thus A6 not needed useful for rapid renumbering. Olafur felt that translation of A6 0 is easy, synthesis easy. The only question is then one of delay. Some company has done this already. Steve Deering asked, at what transition cost? Simon Linen (??) stated that AAAA and A6 are easy, and both can be deployed at the same time in the same zone, simple to have tools maintain one record type from the other. Itojun stated that maintaining A6 and AAAA is not easy. Rob Austein asked if mechanisms ease pain, as it is several years to do transition. This was discussed in Minneapolis. Another variation is to modify servers to generate A6 0 when quad AAAA is found. Though, when translating either way, signature is lost. However, it is important to not use A6 in complex ways. It is an attractive nuisance in that it does encourage people to try to exploit A6 beyond reasonable usage. Matt Crawford felt that transition best be kept short. Itojun is concerned that Rob says years to do transition tools and that his users can't wait. Alain stated that the plan from Minneapolis roughly described the transition. Rob said that Itojun correct; we can't take a long time for a transition. It is important to decide on A6 very soon. Mohsen Suissi from FRNIC noted that many users have been waiting for years to move to IPv6 production. AAAA works fine. If we say we have to move to A6 0 and wait for bind 9, and/or new O/S, we are waiting for more years. customers keep waiting. Itojun asked how many BIND 4 servers are still around versus BIND 9? Perry - how many folks using v6 all the time. A number of hands. Of these how many could run A6 soon, not so many of the hands. Folks around us using AAAA, can we go backwards and wait? Randy asked that for installed AAAA base would you use A6, and the he would, if it was a significant value, which it isn't. Jim Bound would change resolvers not O/S thus AAAA use would continue and this is only an operational issue. Margaret Wasserman asked why this is an issue of one against other. We have AAAA, so question is do we continue to work on A6, say as experimental. Plan for success, for renumbering, why not keep both? Steve Deering agree w/Margaret and Jim. Lack of decision here doesn't keep people from moving to IPv6. It should not be viewed as blocking IPv6. Alain said that the root operators are trying to get IPv6 accessible root servers, and that they are concerned about what to implement. --- Returning to GSE-like routing usage for A6 Randy stated that if a critical architectural change needed for A6, he would support it. However, we don't know what it will be yet. Thomas said that when Rob talked about transition time being a couple years this means at least 2, but he believes it would take 5 years given what is shipping and what current plans are. Tony Hain also noted that since decision is taking a while, we are talking about 6 months. before real development could even start. Maybe it's a 7 year transition. ==== consensus building (one minute break while chairs huddle) Tony Hain summarized what we are hearing from this meeting's discussions: --- Bitstring not necessary, so will take to list to confirm. --- DNAME - only one case where its necessary is if we choose A6. Matt believes you don't need but will really wish for it. Rob said without A6, DNAME use is a more general DNS question, i.e., equally relevant to v4. So again Tony noted that we will take to list to confirm. --- A6/AAAA - tools needed, and could make host push update vs relational db work. So again Tony noted that we will take to list to confirm. --- Renumbering - no consensus on time frames and out of scope here. If rapid implies less than hourly and requires significant architectural change than DNSSEC fails in verifying signature changes. Randy agreed but asked that GSE/8+8 also is in category of rapid renumbering (i.e., can't tell now if it will happen or when, and what it will look like). Also, noted that it is an operationally attractive nuisance. --- Consensus building - Straw polling the 4 address options for rough consensus: - full A6 development with AAAA synthesis - low hum, then a slightly louder hum when asked again - A6 0 w/ AAAA synthesis - medium hum, then a slightly louder hum when asked again - AAAA deployed, A6 to experimental - larger hum, then a slightly louder hum when asked again Randy elaborated that the value of going to Experimental means anyone using A6 has a consistently specified A6 spec to use. Thomas added, we want to signal developers about our A6 shipping intentions, and how defaults are set. Bill Manning believes AAAA should be left in standards track, and A6 to experimental. - AAAA deployed, A6 to historic - medium hum, then a slightly louder hum when asked again It was sense of the room that the hums indicated deploying AAAA and putting A6 to Experimental. Again, this will be take to list to confirm. - Bit labels - - make historic - medium hum - make experimental - loud hum - keep - no hum taken due to lack of comment earlier Therefore, DNAME for bit label use is limited to experimental use. When someone asked if the ip6.int vs ip6.arpa choice was going to be discussed, it was noted that it was out of scope for this group as it was an IAB decision. There was a brief discussion of what list the discussion should go to. Randy and Erik (our area directors in attendance) agreed it should fall under DNSEXT. and the results published to all the other lists. --- Meeting adjourned (ahead of schedule) Summary of of meeting consensus to be verified on mailing lists: - AAAA stays on standards track in DNSEXT, - A6 moved to experimental by DNSEXT - Bitlabels moved to experimental by DNSEXT - DNAME standardization is out scope. -end -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 07:09:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77E8SL08950 for ipng-dist; Tue, 7 Aug 2001 07:08:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77E8LD08934; Tue, 7 Aug 2001 07:08:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21505; Tue, 7 Aug 2001 07:08:26 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06118; Tue, 7 Aug 2001 08:08:17 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 07 Aug 2001 07:07:58 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 37C1A9A547424656A1C7D05C278D320E for plus 3 more; Tue, 07 Aug 2001 07:07:56 -0700 Reply-To: From: "Tony Hain" To: "Matt Crawford" Cc: , , Subject: RE: Joint DNSEXT & NGTRANS agenda Date: Tue, 7 Aug 2001 15:07:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200108062157.f76LvDm21797@gungnir.fnal.gov> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: D63E63D0-442D4E74-B5F9824C-472AAA1F Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f77E8LD08935 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford wrote: > These customers that bolt to avoid renumbering -- they will take > their portable IPv6 address blocks with them? The point was simply they would find a way to avoid recurring pain. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 07:22:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77ELnt09055 for ipng-dist; Tue, 7 Aug 2001 07:21:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77ELjD09048; Tue, 7 Aug 2001 07:21:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24219; Tue, 7 Aug 2001 07:21:40 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15669; Tue, 7 Aug 2001 08:21:42 -0600 (MDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 55A9C31919; Tue, 7 Aug 2001 07:21:32 -0700 (PDT) Message-Id: <5.0.2.1.2.20010807071618.020ca308@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 07 Aug 2001 07:21:31 -0700 To: , "Matt Crawford" From: "David R. Conrad" Subject: RE: Joint DNSEXT & NGTRANS agenda Cc: , , In-Reply-To: References: <200108062157.f76LvDm21797@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:07 PM 8/7/2001 +0100, Tony Hain wrote: > > These customers that bolt to avoid renumbering -- they will take > > their portable IPv6 address blocks with them? Portable IPv6 address blocks? Interesting concept. >The point was simply they would find a way to avoid recurring pain. Yeah. Like NAT. Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 09:05:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77G51H09711 for ipng-dist; Tue, 7 Aug 2001 09:05:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77G4vD09704; Tue, 7 Aug 2001 09:04:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24187; Tue, 7 Aug 2001 09:05:02 -0700 (PDT) Received: from as.vix.com (as.vix.com [204.152.187.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27885; Tue, 7 Aug 2001 10:04:19 -0600 (MDT) Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (8.11.3/8.11.3) with ESMTP id f77G0TH62930; Tue, 7 Aug 2001 09:00:29 -0700 (PDT) (envelope-from vixie@as.vix.com) Message-Id: <200108071600.f77G0TH62930@as.vix.com> To: Alexis Yushin cc: James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Alexis Yushin of "Tue, 07 Aug 2001 16:23:52 +0200." <200108071423.f77ENqd68433@open.nlnetlabs.nl> Date: Tue, 07 Aug 2001 09:00:29 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I see a big difference between deprecating/moving to historic and changing > status to experimental. Experemental implies further development. I don't see that difference here. Just as "let's let the market decide" really just means "let's do whatever Microsoft wants", so it is that "let's make it experimental" really just means "let's move on." (I find it amusing that SRV was experimental but that Microsoft's use of it pulled it forward.) I was not able to be in London, but had I been there my comments would've been: Let's not expect stub resolvers to do the caching necessary to understand either A6 or SIG/KEY -- those are things which servers ought to use to talk to other servers. Stub resolvers making recursive requests of their name servers should be using AAAA and TSIG. AAAA synthesis of underlying A6, and TSIG to protect verified KEY/SIG data for the last mile, is all a client needs. Every argument against SIG/KEY or against A6 comes down to either the caching problem or the complexity problem, and if we insulate the end-stations from those problems, the arguments are reduced to things which authority-side tools can be made to cope with. Hopefully this point was made by somebody. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 09:19:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77GIt609812 for ipng-dist; Tue, 7 Aug 2001 09:18:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77GIpD09801 for ; Tue, 7 Aug 2001 09:18:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26811 for ; Tue, 7 Aug 2001 09:18:22 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA09117 for ; Tue, 7 Aug 2001 10:18:23 -0600 (MDT) Received: from 157.54.7.67 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Aug 2001 09:16:34 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 7 Aug 2001 09:16:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Ad-hoc IPv6 inter-op session at London IETF -- Thursday 7:30 PM Date: Tue, 7 Aug 2001 09:16:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ad-hoc IPv6 inter-op session at London IETF -- Thursday 7:30 PM Thread-Index: AcEaLAST/gXE9GZlSVKHcD4JP1yeFgFLtdHQ From: "Brian Zill" To: Cc: X-OriginalArrivalTime: 07 Aug 2001 16:16:34.0127 (UTC) FILETIME=[537D7DF0:01C11F5C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f77GIpD09802 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We'll be having this fun little inter-op session Thursday evening. Meet at the entrance to the Terminal Room at 7:30 PM. Bring an implementation and any extra CAT-5 cables, hubs, routers, whatever you have handy. We may just end up using the terminal room network if we don't have any extra connectivity equipment. All are welcome. You don't need to be an implementer, just have an implementation you want to play with. So if you have any questions to ask the implementers of your favorite implementation, this is probably a good chance to do that. Looks like we'll have representatives from several different implementations present. --Brian -----Original Message----- From: Brian Zill [mailto:bzill@microsoft.com] Sent: Wednesday, August 01, 2001 02:48 To: ipng@sunroof.eng.sun.com Cc: ipv6imp@munnari.OZ.AU Subject: Ad-hoc IPv6 inter-op session at London IETF At the recent ipng/ngtrans interim meeting in Redmond, we had an ad-hoc IPv6 inter-op session which was surprisingly well-attended given that we decided to do it at the last minute. Some real testing was actually accomplished, and it was also a mildly fun social event. I was wondering if anyone would be interested in doing this again? Format would be similar to the last time - bring your favorite implementation and/or application/service you want to try out and we'll plug them all together and see what happens. This would be completely informal - we'd just find some quiet corner or noisy bar somewhere in the hotel to set up. If we wanted to test some routing stuff we'd need to set up our own little subnets like last time, otherwise we could just use the BT-supplied IPv6 connectivity. Unfortunately, since it's a little farther back to my lab than last time, I won't be able to bring such a large supply of hubs and cabling. So if we want our own private media, we'll have to all bring a few pieces along with us. I'm thinking Thursday night would be best since there is nothing on the official agenda and we should all still be around since Friday morning is the second ipngwg session. Other suggestions welcome. Drop me a line if you're interested and we can work out the details. --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 Aug 7 09:21:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77GKhi09852 for ipng-dist; Tue, 7 Aug 2001 09:20:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77GKdD09845; Tue, 7 Aug 2001 09:20:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23849; Tue, 7 Aug 2001 09:20:45 -0700 (PDT) Received: from starfruit.itojun.org (host217-33-137-35.ietf.ignite.net [217.33.137.35]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04044; Tue, 7 Aug 2001 09:20:44 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id AC56F7BA; Wed, 8 Aug 2001 01:20:00 +0900 (JST) To: Paul A Vixie Cc: Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: vixie's message of Tue, 07 Aug 2001 09:00:29 MST. <200108071600.f77G0TH62930@as.vix.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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 08 Aug 2001 01:20:00 +0900 Message-Id: <20010807162000.AC56F7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I see a big difference between deprecating/moving to historic and changing >> status to experimental. Experemental implies further development. > >I don't see that difference here. Just as "let's let the market decide" >really just means "let's do whatever Microsoft wants", so it is that "let's >make it experimental" really just means "let's move on." (I find it amusing >that SRV was experimental but that Microsoft's use of it pulled it forward.) > >I was not able to be in London, but had I been there my comments would've been: > > Let's not expect stub resolvers to do the caching necessary to > understand either A6 or SIG/KEY -- those are things which servers > ought to use to talk to other servers. Stub resolvers making > recursive requests of their name servers should be using AAAA and > TSIG. AAAA synthesis of underlying A6, and TSIG to protect > verified KEY/SIG data for the last mile, is all a client needs. > Every argument against SIG/KEY or against A6 comes down to either > the caching problem or the complexity problem, and if we insulate > the end-stations from those problems, the arguments are reduced to > things which authority-side tools can be made to cope with. i have a major concern with AAAA synthesis - which is, it is unclear as to who needs to AAAA synthesis. the concern is mentioned in my draft. - you can't guarantee every first-hop DNS server to do AAAA synthesis. - if anyone does not, AAAA queries go into non-first-hop DNS servers by recurse (imagine when pre-BIND9/non-BIND name server is used as the first-hop name server). therefore, AAAA synthesis basically asks everyone to run AAAA and A6 in parallel, which raises a lot of concerns (query delays if you query both, database maintenance cost if you maintain both in zone, no-sign if you synthesize, and a lot of others). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 09:30:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77GSh509996 for ipng-dist; Tue, 7 Aug 2001 09:28:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77GSdD09985; Tue, 7 Aug 2001 09:28:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24078; Tue, 7 Aug 2001 09:28:45 -0700 (PDT) Received: from cypress.tahi.org (host217-33-138-76.ietf.ignite.net [217.33.138.76]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10425; Tue, 7 Aug 2001 09:28:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by cypress.tahi.org (8.11.1/8.11.1) with ESMTP id f77Fk9G01178; Wed, 8 Aug 2001 00:46:09 +0900 (JST) (envelope-from nov@tahi.org) To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary From: OKABE Nobuo In-Reply-To: <200108071600.f77G0TH62930@as.vix.com> References: <200108071600.f77G0TH62930@as.vix.com> X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010808004609S.nov@tahi.org> Date: Wed, 08 Aug 2001 00:46:09 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Paul A Vixie Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Tue, 07 Aug 2001 09:00:29 -0700 > > I see a big difference between deprecating/moving to historic and changing > > status to experimental. Experemental implies further development. > > I don't see that difference here. Just as "let's let the market decide" > really just means "let's do whatever Microsoft wants", so it is that "let's > make it experimental" really just means "let's move on." (I find it amusing > that SRV was experimental but that Microsoft's use of it pulled it forward.) this is not true. i voted for 3, but it was not for microsort. and other people who voted were the same. ---- 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 Aug 7 09:50:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77GnXO10212 for ipng-dist; Tue, 7 Aug 2001 09:49:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77GnQD10205; Tue, 7 Aug 2001 09:49:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26710; Tue, 7 Aug 2001 09:49:32 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18885; Tue, 7 Aug 2001 10:49:29 -0600 (MDT) From: Masataka Ohta Message-Id: <200108071640.BAA29773@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id BAA29773; Wed, 8 Aug 2001 01:40:40 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010807101629.AA1BA7BA@starfruit.itojun.org> from Jun-ichiro itojun Hagino at "Aug 7, 2001 07:16:29 pm" To: Jun-ichiro itojun Hagino Date: Wed, 8 Aug 2001 01:40:38 +0859 () CC: Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun; > >1. Deploy A6 in full panoply, synthesize AAAA for transition period > >2. Deploy A6 conservatively ("A6 0"), synthesize as above > >3. Reclassify A6 as experimental, use AAAA for production > >4. Reclasify A6 as historic, use AAAA for production. > > > >The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all > >accounts. There was quite obviously no consensus (i.e., unanimity) > > I would say 3 >> 2 > 1 > 4, heard from my location (near the > VGA projector). So? Considering that mailing lists are the WGs... Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 10:35:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77HPRs10549 for ipng-dist; Tue, 7 Aug 2001 10:25:27 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77HPLD10542 for ; Tue, 7 Aug 2001 10:25:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f77HNfq02390 for ipng@sunroof.eng.sun.com; Tue, 7 Aug 2001 10:23:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77GhWD10154; Tue, 7 Aug 2001 09:43:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27685; Tue, 7 Aug 2001 09:43:38 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [213.53.69.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24148; Tue, 7 Aug 2001 10:40:18 -0600 (MDT) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.3/8.11.3) id f77Ge9K68980; Tue, 7 Aug 2001 18:40:09 +0200 (CEST) (envelope-from alexis) Message-Id: <200108071640.f77Ge9K68980@open.nlnetlabs.nl> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: "from James Aldridge at Aug 7, 2001 05:22:37 pm" To: James Aldridge Date: Tue, 7 Aug 2001 18:40:09 +0200 (CEST) CC: alexis@nlnetlabs.nl, Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Alexis Yushin Reply-To: alexis@nlnetlabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Once James Aldridge wrote: >Alexis Yushin wrote: >> I see a big difference between deprecating/moving to historic and changing >> status to experimental. Experemental implies further development. > >I think that "implies" might be a bit strong - "permits" might be more >appropriate (just check rfc-index.txt for all those ancient "experimental" >RFCs). But, yes, I do recognise the difference. Well, to be more specific we do plan on doing quite some more research and testing in the A6 area. (We as in NLnet Labs) Alexis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 10:35:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77HOpb10531 for ipng-dist; Tue, 7 Aug 2001 10:24:51 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77HOhD10524 for ; Tue, 7 Aug 2001 10:24:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f77HN3302330 for ipng@sunroof.eng.sun.com; Tue, 7 Aug 2001 10:23:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77FMdD09567; Tue, 7 Aug 2001 08:22:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10856; Tue, 7 Aug 2001 08:22:45 -0700 (PDT) Received: from aegir.EU.net (aegir.EU.net [193.242.90.19]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19103; Tue, 7 Aug 2001 08:22:44 -0700 (PDT) Received: from localhost.eu.net ([127.0.0.1] helo=aegir.EU.net) by aegir.EU.net with esmtp (Exim 3.30 #1) id 15U8go-0000uf-00; Tue, 07 Aug 2001 17:22:38 +0200 From: James Aldridge To: alexis@nlnetlabs.nl cc: Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Tue, 07 Aug 2001 16:23:52 +0200." <200108071423.f77ENqd68433@open.nlnetlabs.nl> Date: Tue, 07 Aug 2001 17:22:37 +0200 Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexis Yushin wrote: > I see a big difference between deprecating/moving to historic and changing > status to experimental. Experemental implies further development. I think that "implies" might be a bit strong - "permits" might be more appropriate (just check rfc-index.txt for all those ancient "experimental" RFCs). But, yes, I do recognise the difference. James -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 10:35:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77HOUE10522 for ipng-dist; Tue, 7 Aug 2001 10:24:30 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77HOND10515 for ; Tue, 7 Aug 2001 10:24:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f77HMht02300 for ipng@sunroof.eng.sun.com; Tue, 7 Aug 2001 10:22:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77ENuD09110; Tue, 7 Aug 2001 07:23:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08131; Tue, 7 Aug 2001 07:24:01 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [213.53.69.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09986; Tue, 7 Aug 2001 07:24:00 -0700 (PDT) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.3/8.11.3) id f77ENqd68433; Tue, 7 Aug 2001 16:23:52 +0200 (CEST) (envelope-from alexis) Message-Id: <200108071423.f77ENqd68433@open.nlnetlabs.nl> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: "from James Aldridge at Aug 7, 2001 12:34:52 pm" To: James Aldridge Date: Tue, 7 Aug 2001 16:23:52 +0200 (CEST) CC: Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Alexis Yushin Reply-To: alexis@nlnetlabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Once James Aldridge wrote: >Jim Bound wrote: >> I felt consensus for number 3 is my input. > >That was my view too. There certainly seemed to be consensus for using AAAA >records for production and deprecating A6 records (either as experimental or >historic) I see a big difference between deprecating/moving to historic and changing status to experimental. Experemental implies further development. Alexis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 10:35:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77HP6810540 for ipng-dist; Tue, 7 Aug 2001 10:25:06 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77HP2D10533 for ; Tue, 7 Aug 2001 10:25:02 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f77HNMk02360 for ipng@sunroof.eng.sun.com; Tue, 7 Aug 2001 10:23:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77GclD10074; Tue, 7 Aug 2001 09:38:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23799; Tue, 7 Aug 2001 09:38:54 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [213.53.69.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09031; Tue, 7 Aug 2001 10:38:50 -0600 (MDT) Received: (from alexis@localhost) by open.nlnetlabs.nl (8.11.3/8.11.3) id f77GclL68959; Tue, 7 Aug 2001 18:38:47 +0200 (CEST) (envelope-from alexis) Message-Id: <200108071638.f77GclL68959@open.nlnetlabs.nl> Subject: Re: DNSEXT NGTRANS Joint meeting DRAFT minutes In-Reply-To: "from Olafur Gudmundsson at Aug 7, 2001 09:56:05 am" To: Olafur Gudmundsson Date: Tue, 7 Aug 2001 18:38:47 +0200 (CEST) CC: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, dnsop@cafax.se From: Alexis Yushin Reply-To: alexis@nlnetlabs.nl X-Mailer: ELM [version 2.4ME+ PL87 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Once Olafur Gudmundsson wrote: >Alex K (?) asked if we know what the future is. IPv6 will be used in Alexis Yushin, thank you very much! Alexis >new applications beyond our current Internet, and who knows what these >uses are. Choice is either put A6 flexibility there for the future, or >stop developing A6 now and invent something new in future. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 10:35:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77HNLg10495 for ipng-dist; Tue, 7 Aug 2001 10:23:21 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77HNDD10488 for ; Tue, 7 Aug 2001 10:23:13 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f77HLWg02210 for ipng@sunroof.eng.sun.com; Tue, 7 Aug 2001 10:21:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77AYrD08137; Tue, 7 Aug 2001 03:34:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12083; Tue, 7 Aug 2001 03:34:58 -0700 (PDT) Received: from aegir.EU.net (aegir.EU.net [193.242.90.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05053; Tue, 7 Aug 2001 04:34:55 -0600 (MDT) Received: from localhost.eu.net ([127.0.0.1] helo=aegir.EU.net) by aegir.EU.net with esmtp (Exim 3.30 #1) id 15U4CK-0000he-00; Tue, 07 Aug 2001 12:34:52 +0200 From: James Aldridge To: Jim Bound cc: Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Tue, 07 Aug 2001 06:28:30 EDT." Date: Tue, 07 Aug 2001 12:34:52 +0200 Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > I felt consensus for number 3 is my input. That was my view too. There certainly seemed to be consensus for using AAAA records for production and deprecating A6 records (either as experimental or historic) --James > > /jim > > > On Tue, 7 Aug 2001, Matt Crawford wrote: > > > I have overheard nearly opposite outcomes quoted by random people > > in the halls, and some of the joint co-chairs (all the ones I've > > asked so far) seem reluctant to say anything substantive in public > > about the outcome of the joint dnsext/ngtrans meeting. I know there > > are some interested parties who were not present and I have no idea > > whether or how well they heard it on the mbone. So, here's my > > view from the floor ... other views would be welcome, the sooner > > the better. > > > > There was a lot of discussion, culminating with a "hum" on the > > following four choices: > > > > 1. Deploy A6 in full panoply, synthesize AAAA for transition period > > 2. Deploy A6 conservatively ("A6 0"), synthesize as above > > 3. Reclassify A6 as experimental, use AAAA for production > > 4. Reclasify A6 as historic, use AAAA for production. > > > > The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all > > accounts. There was quite obviously no consensus (i.e., unanimity) > > or rough consensus (in the usual IETF sense of near-unanimity). It > > could not even be concluded that the loudest hum represented a > > majority of those voicing an opinion. > > > > The difference in impressions taken away, therefore, I would account > > for by differences in opinion about whether the preference of a > > plurality, possibly a slim majority, represent a decision to alter the > > status quo. (That being A6 on the standards track.) > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 10:35:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77HO9510513 for ipng-dist; Tue, 7 Aug 2001 10:24:09 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77HNxD10506 for ; Tue, 7 Aug 2001 10:23:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f77HMKM02270 for ipng@sunroof.eng.sun.com; Tue, 7 Aug 2001 10:22:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77CfQD08405; Tue, 7 Aug 2001 05:41:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27087; Tue, 7 Aug 2001 05:41:32 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07373; Tue, 7 Aug 2001 06:41:33 -0600 (MDT) Received: from z.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 1F2471B50; Tue, 7 Aug 2001 08:41:29 -0400 (EDT) Received: by z.hactrn.net (Postfix, from userid 1001) id D8C884A5; Tue, 7 Aug 2001 12:41:25 +0000 (GMT) Received: from hactrn.net (localhost [127.0.0.1]) by z.hactrn.net (Postfix) with ESMTP id C5C9E4A3; Tue, 7 Aug 2001 13:41:25 +0100 (BST) To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Matt Crawford of "Tue, 07 Aug 2001 05:10:34 CDT." <200108071010.f77AAYm24838@gungnir.fnal.gov> MIME-Version: 1.0 (generated by WEMI 1.13.7 - "Shimada") Content-Type: text/plain; charset=US-ASCII Date: Tue, 07 Aug 2001 13:41:20 +0100 From: Rob Austein Message-Id: <20010807124125.D8C884A5@z.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Er, Matt, AAAA -and- A6 are both currently proposed standards. Other than that (and its implications on what the "status quo" is), I agree with your summary. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 10:36:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77HNjF10504 for ipng-dist; Tue, 7 Aug 2001 10:23:45 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77HNcD10497 for ; Tue, 7 Aug 2001 10:23:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f77HLwQ02240 for ipng@sunroof.eng.sun.com; Tue, 7 Aug 2001 10:21:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77B25D08195; Tue, 7 Aug 2001 04:02:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08221; Tue, 7 Aug 2001 04:02:11 -0700 (PDT) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15744; Tue, 7 Aug 2001 04:02:10 -0700 (PDT) Received: from pc (A010-0162.JCSN.splitrock.net [63.252.220.162]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with SMTP id f77B24r166182; Tue, 7 Aug 2001 07:02:05 -0400 Message-ID: <03a901c11f2f$989f8680$4ddcfc3f@pc> From: "JIM R FLEMING" To: "Bill Manning" , "Matt Crawford" Cc: , , , References: <200108071018.f77AIY619105@zed.isi.edu> Subject: Re: Joint DNSEXT & NGTRANS summary Date: Tue, 7 Aug 2001 05:56:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Bill Manning" To: "Matt Crawford" Cc: ; ; ; Sent: Tuesday, August 07, 2001 5:18 AM Subject: Re: Joint DNSEXT & NGTRANS summary > % There was a lot of discussion, culminating with a "hum" on the > % following four choices: > % > % 1. Deploy A6 in full panoply, synthesize AAAA for transition period > % 2. Deploy A6 conservatively ("A6 0"), synthesize as above > % 3. Reclassify A6 as experimental, use AAAA for production > % 4. Reclasify A6 as historic, use AAAA for production. > > I took a (perhaps) stricter view on these four choices: > > 1) A6 stays on Stds track, syth AAAA when needed, AAAA is > depricated > 2) A6 stays on Stds track, tempered by a recommendation to > operationally use A6 0. > 3) Leave AAAA on Stds track, move A6 to experimental. > 4) Move A6 to historic, leave AAAA on Stds track. > > > % The relative volumes of the hum seemed to be 3 > 2 > 1 > 4, by all > % accounts. There was quite obviously no consensus (i.e., unanimity) > % or rough consensus (in the usual IETF sense of near-unanimity). It > % could not even be concluded that the loudest hum represented a > % majority of those voicing an opinion. > > That was my impression as well. > > > --bill You might first want to first define "production". When one talks about "production services", I assume they are at a minimum talking about IPv16-Compliant equipment. (i.e. Carrier-Grade, NEBS, 24", -48vDC,Fault-Tolerant LANs,1000/100/10 Ethernets) http://www.dot-biz.com/IPv16/ Jim Fleming Why gamble with a .BIZ Lottery? Start a real .BIZ Today ! http://www.DOT-BIZ.com http://www.BIZ.Registry 0:212 - BIZ World -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 11:05:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77HnRw10855 for ipng-dist; Tue, 7 Aug 2001 10:49:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77HnHD10848; Tue, 7 Aug 2001 10:49:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15665; Tue, 7 Aug 2001 10:49:23 -0700 (PDT) Received: from as.vix.com (as.vix.com [204.152.187.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06973; Tue, 7 Aug 2001 11:49:19 -0600 (MDT) Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (8.11.3/8.11.3) with ESMTP id f77HmHH64664; Tue, 7 Aug 2001 10:48:17 -0700 (PDT) (envelope-from vixie@as.vix.com) Message-Id: <200108071748.f77HmHH64664@as.vix.com> To: Jun-ichiro itojun Hagino cc: Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Jun-ichiro itojun Hagino of "Wed, 08 Aug 2001 01:20:00 +0900." <20010807162000.AC56F7BA@starfruit.itojun.org> Date: Tue, 07 Aug 2001 10:48:17 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i have a major concern with AAAA synthesis - which is, it is unclear > as to who needs to AAAA synthesis. the concern is mentioned > in my draft. > > - you can't guarantee every first-hop DNS server to do AAAA synthesis. > - if anyone does not, AAAA queries go into non-first-hop DNS servers > by recurse (imagine when pre-BIND9/non-BIND name server is used > as the first-hop name server). > > therefore, AAAA synthesis basically asks everyone to run AAAA and A6 > in parallel, which raises a lot of concerns (query delays if you query > both, database maintenance cost if you maintain both in zone, no-sign > if you synthesize, and a lot of others). i would much rather deal with those problems, since they are solvable, then to deal with non-renumberable 128 bit addresses, since they simply lead to NAT. i cannot emphasize strongly enough that vast numbers of transit-consumers who lack the various powers needed to own portable address space will NOT deploy globally addressable IPv6 space if it simply means that they will become even more captive of their ipv6-transit providers than they are of their ipv4-transit providers today. the gprs and other mobile data providers are mostly going to be able to own portable address space so they don't care about this issue. but for "the enterprise" this is a real problem. if ipv6 is no easier to renumber than ipv4, then we're going to see large scale NAT. much larger scale NAT than we see today. being a captive customer of some transit provider when you only have an ipv4 /24 or even a /20 that you have to renumber if you change providers has difficulty N. being a captive customer of some transit provider when you have an ipv6 /64 to renumber if you change providers has difficulty N*(2^44). if NAT is used then the difficulty in either case is a constant, and for that matter, it's the same constant. so, "let's standardize both and let the market decide." but right now i'm hearing three camps trying to kill A6: implementors who consider bitstring, A6, and DNAME "too hard to do" transit providers who like the idea of captive ipv6 /64 customers transit customers who have enough power to own their own ipv6 blocks who in this mix is representing the interests of the average MIS manager? (and who do you think is going to drive the ipv6 economy, anyhow?) this debate borders on "simply unbelievable." -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 11:42:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77IQIc10958 for ipng-dist; Tue, 7 Aug 2001 11:26:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77IOtD10951; Tue, 7 Aug 2001 11:24:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26963; Tue, 7 Aug 2001 11:24:21 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01360; Tue, 7 Aug 2001 12:24:20 -0600 (MDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA07760; Tue, 7 Aug 2001 14:23:41 -0400 (EDT) Message-Id: <200108071823.OAA07760@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: James Aldridge cc: Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Tue, 07 Aug 2001 12:34:52 +0200." Date: Tue, 07 Aug 2001 14:23:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Seems like we really need a group to study how to do renumbering. Such a group needs to consider not just DNS but everything that renumbering affects - e.g. DNS, routers, hosts, firewalls, applications using address-based authentication, long-running applications, and large-scale distributed applications. We need to consider the whole process of renumbering rather than trying to solve the problem in a piecemeal fashion. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 14:48:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77Ll4n11870 for ipng-dist; Tue, 7 Aug 2001 14:47:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77Ll1D11863 for ; Tue, 7 Aug 2001 14:47:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07778 for ; Tue, 7 Aug 2001 14:47:08 -0700 (PDT) Received: from hotmail.com (law2-f60.hotmail.com [216.32.181.60]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12462 for ; Tue, 7 Aug 2001 15:47:05 -0600 (MDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 7 Aug 2001 14:47:07 -0700 Received: from 160.43.145.196 by lw2fd.hotmail.msn.com with HTTP; Tue, 07 Aug 2001 21:47:07 GMT X-Originating-IP: [160.43.145.196] From: "Aldrin Isaac" To: ipng@sunroof.eng.sun.com Date: Tue, 07 Aug 2001 17:47:07 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Aug 2001 21:47:07.0681 (UTC) FILETIME=[8135A910:01C11F8A] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Before I begin, I would like to apologize for any incorrectness in this message. I am very new to IPv6 so Im still trying to get all the facts straight. A few individuals in the IPv6 community, including Steve Deering, have told me that the IPv6 addressing schema has focused on Internet provider/vendor needs, as the groups that decide on IPv6 do not have adequate, if any, representation from the non Internet provider/vendor community. I know this may be bad timing but I feel it is necessary to write to those it may concern in order to re-iterate some issues. I work for a large private information provider. We connect privately to over 20000 customer networks which constitute over a million computer systems, of which over 150,000 subscribe to our data. Our private network has around 250 POPs connecting over 80 countries to our data centers. We have considered plans to peer several of these POPs to the Internet to provide short-cuts for our customer networks to access various resources on the Internet. Our network is, however, strictly private. The company has little or no interest in becoming a network service provider, and even less interest in becoming an Internet transit service provider. This, unfortunately for us, means that we would not be eligible to apply for a [Sub-]TLA, based on RFC 2450. In the current IPv6 addressing plan a [Sub-]TLA and all contained addressing is owned by an Internet transit service provider. This presents several problems. This provider may go out of business, adopt unacceptable business policies, get bought by a business rival (btw, this has happened to us), etc. If such things should happen to our [Sub-]TLA provider we stand a risk of having to change our addressing. This would put our business at considerable risk due to several factors. Although RFC 2347 describes a way to have addressing independence from long-haul transit providers by connecting to the Internet via an exchange, it says nothing about (1) how an exchange can provide dedicated addressing to a global company, (2) how and who will administer it (3) will multihoming via an exchange provide the routing insulation provided by peering independantly? If an exchange is administered by a public body, would we not be entitled to preferential considerations? Who has the answers to these questions? We use the same routers that large providers use. We also happen to have thousands of distributed servers on our network running several versions of several operating systems. I have not seen any effort on the part of these router and systems vendors to simplify the rapid change of addressing. For us this means not only changing addresses on over 40,000 thousand interfaces, but also changing over 100,000 lines of distributed policies. Not to mention all the data storage, thresholding and alarm systems and databases. Also, in my experience, massive changes have exposed bugs in vendor software that have caused loss of service to our customers. For example, when changing policy, if a line of policy does not implement properly due to some race condition, this can cause loss of service and/or exposure (btw, we have seen this happen). Almost all of our 20000 customer networks use firewalls. Our addresses are configured into these firewalls. It takes over a year of letters and meetings with 20000 customers to accomplish this. Not to mention tens of thousands of man-hours. We not only have canned connections to customers, but also over 1000 private connections to our own sources of data, each of which is unique to that data provider. We need to privately peer with these corporations, without the ISP in the middle. These peering points are full of policies in both directions and on both sides. I am not sure if there is an IPv6 study group on the impact of changing addresses, or if anyone has published anything regarding this topic. If anyone knows of where I can find information regarding this I would appreciate having it. The current addressing scheme does not solve the problem of multi-homing in any concrete way either. There is a conflict in the current scheme between aggregation, multi-homing and address transparency. If I want to make a [Sub-]TLA provider in the Far East happy, Id need to use an address assigned by him. However, this may not make any of the other 99 ISPs I decide to peer with very happy. I can make every [Sub-]TLA provider happy if I do IPv6 NAT using that providers assigned address. This, however, defeats the IPv6 claim to rid the world of NAT and create full address transparency. It seems to me that in the current addressing schema, things like route aggregation and host autoconfiguration has taken precedence over some other very serious issues. In what balance were these factors measured for route aggregation to win? Route aggregation solves a single technical problem. But it doesn't seem to solve any other significant business issue towards the implementation of IPv6. The industry has proven capable of building better routers that can handle more route entries. Im not against route aggregation. I use it aggressively in our network. But I dont think its a good idea for a company such as mines to be subjected to having our address space outside our control. I see a lot of intelligent dialogue in these working groups. But it seems to me no one wants to touch the issues that will actually move IPv6 into the real world. I hate to say this to everyone who's worked so hard on IPv6. The current IPv6 addressing schema is unusable by anyone except Internet providers trying to serve the household and small business market. It needs to be redone to gain the support of large corporations. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 16:05:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f77N4Uv12440 for ipng-dist; Tue, 7 Aug 2001 16:04:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77N4QD12433 for ; Tue, 7 Aug 2001 16:04:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28033 for ; Tue, 7 Aug 2001 16:04:33 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11014 for ; Tue, 7 Aug 2001 16:04:32 -0700 (PDT) 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 QAA28689; Tue, 7 Aug 2001 16:04:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f77N4Wi04977; Tue, 7 Aug 2001 16:04:32 -0700 X-mProtect: Tue, 7 Aug 2001 16:04:32 -0700 Nokia Silicon Valley Messaging Protection Received: from host217-33-140-17.ietf.ignite.net (217.33.140.17, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdztGSkx; Tue, 07 Aug 2001 16:04:29 PDT Message-Id: <4.3.2.7.2.20010807154244.0225ec78@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 16:04:15 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Updated IPng Agenda for London IETF (REVISED) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Updated agenda attached. Due to requests from some of the speakers the DNS discovery and USAGI talks were moved to Friday and Dialup talks were moved to Wednesday. Please let us know if this creates any problems. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------------- WEDNESDAY, August 8, 2001 1300-1500 ------------------------------------ Introduction / Steve Deering (5 min) Review Agenda / Steve Deering (5 min) Document & Charter Status / Bob Hinden (10 min) 3GPP-IETF Design team status / Bob Hinden (10 min) Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino (15 min) Avoiding ping-pong packets on point-to-point links / Jun-ichiro itojun Hagino (10 min) Multilink Subnets / Dave Thaler (20 min) DHCPv6 Status and Last Call / Ralph Droms (10 min) Minimum IPv6 Functionality for a Cellular Host / John Loughney (25 min) AAAv6 Status / Charlie Perkins (5 min) FRIDAY, August 10, 2001 0900-1130 ----------------------------------- IPv6 Site Renumbering / Christian Huitema (20 min) Source/Destination Address Selection / Brian Zill (15 min) Domain Name Auto-Registration for Plugged-in IPv6 Nodes / Hiroshi Kitamura (15 min) A proposal for the IPv6 Flow Label Specification / Alex Conta (30 min) DNS Discovery / Dave Thaler (20 min) An analysis of IPv6 anycast / Jun-ichiro itojun Hagino (10 min) Disconnecting TCP connection toward IPv6 anycast address / Jun-ichiro itojun Hagino (10 min) IPv6 MIB Update Status / Bill Fenner (15 min) nnnn=2096,2011,2012,2013 Socket API for IPv6 traffic class field / Jun-ichiro itojun Hagino (5min) Status of Linux and USAGI IPv6 / Yuji Sekiya (5 min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 7 17:15:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f780ETr12913 for ipng-dist; Tue, 7 Aug 2001 17:14:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f780EOD12906 for ; Tue, 7 Aug 2001 17:14:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07005 for ; Tue, 7 Aug 2001 17:14:31 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA23200 for ; Tue, 7 Aug 2001 18:14:19 -0600 (MDT) Received: (qmail 11566 invoked by uid 1001); 8 Aug 2001 00:14:33 -0000 Date: 8 Aug 2001 00:14:32 -0000 Message-ID: <20010808001432.8394.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <200108071748.f77HmHH64664@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul A Vixie writes: > so, "let's standardize both and let the market decide." So you don't mind us deploying clients that look for only AAAA and A? And you don't mind us deploying caches that don't convert A6 to AAAA? The BIND company will stop saying things like I will note that djbdns does not support A6, DNAME, bitstring labels, and other modern features of the DNS. We did not have the luxury of ignoring IETF standards; we prefer to work and play well with others. and start saying things like ``Apparently the market has decided to use AAAA'' and ``Beware that clients won't look for your A6/DNAME records''? > who in this mix is representing the interests of the average MIS manager? Such as a manager wondering why his users are having sporadic problems reaching www.i.am? Or a manager who wants his site renumbered _now_, and can't wait several years for universal client-side A6 support? Or a manager unable to find DNS software with the features he wants, because DNS implementors have to waste so much time on garbage like A6? > if ipv6 is no easier to renumber than ipv4, then we're going to see large > scale NAT. much larger scale NAT than we see today. Explain. If the renumbering costs are the same, why will NAT become more popular? Why will users become ``even more captive''? The NAT sites I've seen are using it for precisely one reason: to conserve precious IPv4 address space. They won't use NAT with IPv6. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 17:33:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f780VxW13053 for ipng-dist; Tue, 7 Aug 2001 17:31:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f780VsD13046; Tue, 7 Aug 2001 17:31:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09851; Tue, 7 Aug 2001 17:32:01 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23239; Tue, 7 Aug 2001 17:32:00 -0700 (PDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 1DAF53190C; Tue, 7 Aug 2001 17:32:00 -0700 (PDT) Message-Id: <5.0.2.1.2.20010807172339.0301adb0@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 07 Aug 2001 17:31:59 -0700 To: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: "David R. Conrad" Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010808001432.8394.qmail@cr.yp.to> References: <200108071748.f77HmHH64664@as.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, At 12:14 AM 8/8/2001 +0000, D. J. Bernstein wrote: >The NAT sites I've seen are using it for precisely one reason: to >conserve precious IPv4 address space. Large organizations also use NAT so they aren't held hostage by their service provider. Really. If you don't believe me, ask any large organization that does not have "portable" address space. >They won't use NAT with IPv6. Yes, they will. As soon as they are told by their new ISP that they must renumber, they'll question if they are any better off than they were with IPv4. Neat thing about IPv6 is that everyone will be in the same boat -- no historical "portable" prefixes, right? The argument can be made that you can renumber with AAAA, but pretending that renumbering is not an incentive to use NAT is just silly. Rgds, -drc P.S. Sorry if this is considered heretical. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 7 18:33:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f781V6U13225 for ipng-dist; Tue, 7 Aug 2001 18:31:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f781UtD13218; Tue, 7 Aug 2001 18:30:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19627; Tue, 7 Aug 2001 18:31:02 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15458; Tue, 7 Aug 2001 18:31:01 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA10224; Tue, 7 Aug 2001 21:30:57 -0400 (EDT) Message-Id: <200108080130.VAA10224@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "David R. Conrad" cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Tue, 07 Aug 2001 17:31:59 PDT." <5.0.2.1.2.20010807172339.0301adb0@localhost> Date: Tue, 07 Aug 2001 21:30:57 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > P.S. Sorry if this is considered heretical. I don't think it's heretical at all. I don't take it as an absolute that people would inherently rather renumber than use NAT, but I think it's reasonable to assume that large numbers of people will follow the path of least resistance, or perhaps, of least apparent risk. If at the time the decision is made, NAT looks easier than renumbering, that's what they'll do. So if we want to avoid NAT in IPv6, we need to make renumbering *much* easier than it is now. Problem is, A6 in its current form doesn't really do this. Even if it works as advertised, A6 only addresses one of many aspects of renumbering. And DNS is almost certainly not the mechanism that you want to use to advertise address changes in your local network. And people have a difficult enough time configuring SOA, NS, A, CNAME, PTR and MX records correctly, without having to also sort out A6 and DNAME. To me it appears that A6 could actually increase the difficulty of renumbering without disruption. OTOH, I can see how A6 (or some subset thereof) might end up being part of an overall renumbering strategy. For instance, I can see how a DNS-like identifier might be assigned to name the set of global address prefixes by which a given network might be reached, and how a DNS server for a domain might want to act as a cache for those name-to-prefix bindings, and how those bindings might be suitably represented by A6 records. I can even see how it might be desirable to expose those A6 records outside of your local net if you are signing your records with DNSSEC. I can also see how it would be desirable to just sign the AAAA records. The presumption behind A6 seems to be that the party who signs your prefix record is likely to be different than the party who signs the suffixes. I don't buy that at all, because I believe that renumberings, no matter how easy they become, are still going to need to be explicitly managed events. You don't want your ISP asserting that you have a new prefix before your firewalls, routers, hosts, and applications know how to deal with it. Re-signing the records in a zone is the least of the problems that must be solved in order to do the renumbering. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 01:40:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f788dcG13998 for ipng-dist; Wed, 8 Aug 2001 01:39:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f788dXD13991; Wed, 8 Aug 2001 01:39:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06914; Wed, 8 Aug 2001 01:39:39 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA23186; Wed, 8 Aug 2001 02:39:42 -0600 (MDT) From: Masataka Ohta Message-Id: <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA02821; Wed, 8 Aug 2001 17:30:21 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.0.2.1.2.20010807172339.0301adb0@localhost> from "David R. Conrad" at "Aug 7, 2001 05:31:59 pm" To: "David R. Conrad" Date: Wed, 8 Aug 2001 17:30:20 +0859 () CC: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk drc; > >The NAT sites I've seen are using it for precisely one reason: to > >conserve precious IPv4 address space. > > Large organizations also use NAT so they aren't held hostage by their > service provider. Really. If you don't believe me, ask any large > organization that does not have "portable" address space. So, you are saying that the large organiation is currently accepting to manually change IP addresses of DNS servers on renumbering, aren't you? They should have small (maybe two) number of nameservers for the entire organization visible from the outside in the public Internet and willing to renumber them or have none and ask someone operate ones. If so, A6 is perfectly fine for it for easy and quick renumbering. > The argument can be made that you can renumber with AAAA, but pretending > that renumbering is not an incentive to use NAT is just silly. The only thing to do is to have an RFC for the organization to tell renumbering with A6 is as easy as with NAT. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 02:07:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7896nN14080 for ipng-dist; Wed, 8 Aug 2001 02:06:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7896MD14051; Wed, 8 Aug 2001 02:06:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08666; Wed, 8 Aug 2001 02:06:29 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17174; Wed, 8 Aug 2001 02:06:28 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7896Nm10337; Wed, 8 Aug 2001 02:06:23 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7896Nf20107; Wed, 8 Aug 2001 02:06:23 -0700 Message-Id: <200108080906.f7896Nf20107@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: moore@cs.utk.edu (Keith Moore) Date: Wed, 8 Aug 2001 02:06:23 -0700 (PDT) Cc: jhma@KPNQwest.net (James Aldridge), seamus@bit-net.com (Jim Bound), crawdad@fnal.gov (Matt Crawford), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108071823.OAA07760@astro.cs.utk.edu> from "Keith Moore" at Aug 07, 2001 02:23:41 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % Seems like we really need a group to study how to do renumbering. % Such a group needs to consider not just DNS but everything that % renumbering affects - e.g. DNS, routers, hosts, firewalls, applications % using address-based authentication, long-running applications, and % large-scale distributed applications. We need to consider the % whole process of renumbering rather than trying to solve the problem % in a piecemeal fashion. % % Keith % PIER did look at renumbering from the IPv4 perspective. We explicitly did not consider IPv6 issues as IPv6 was still newly hatched. Perhaps it is time to revisit PIER in light of the current state of IPv6. If there is interest, pier-request@isi.edu -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 02:33:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f789Wos14165 for ipng-dist; Wed, 8 Aug 2001 02:32:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f789WlD14158 for ; Wed, 8 Aug 2001 02:32:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14296 for ; Wed, 8 Aug 2001 02:32:51 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23364 for ; Wed, 8 Aug 2001 03:32:47 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f789WIl03585; Wed, 8 Aug 2001 16:32:19 +0700 (ICT) From: Robert Elz To: "Aldrin Isaac" cc: ipng@sunroof.eng.sun.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 16:32:18 +0700 Message-ID: <3583.997263138@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 07 Aug 2001 17:47:07 -0400 From: "Aldrin Isaac" Message-ID: | In the current IPv6 addressing plan a [Sub-]TLA and all contained addressing | is owned by an Internet transit service provider. This presents several | problems. This provider may go out of business, adopt unacceptable business | policies, get bought by a business rival (btw, this has happened to us), | etc. If such things should happen to our [Sub-]TLA provider we stand a risk | of having to change our addressing. This was known when IPv6 was being developed. That is, that was the deliberate plan - it is (currently anyway) the only way that we know how to make the Internet routing system work. If you have an alternative, there are lots of us who would be only too pleased to learn of it. | I have not seen any effort on the part of these | router and systems vendors to simplify the rapid change of addressing. That's largely true (from what I have observed as well). It is a pity. However, it is also expected - that is, why are they going to do any work to change what they're currently selling, when everyone is simply content to keep buying it. And here, rather than pressure the vendors to change (and with a company of your apparent size, which would also mean its likely large budget for equipment) you're attempting to pressure the IETF to change the addressing plan to make up for that. That's backwards. You should instead be asking the vendors to support what you need. | For us this means not only changing addresses on over 40,000 thousand | interfaces, IPv6 should make this much easier than it was with IPv4. The combination of auto-config and router renumbering (and perhaps more to come) should make this task entirely manageable. That's the plan anyway - if there's anything missing to make it work, please let us know so that can be fixed. | but also changing over 100,000 lines of distributed policies. But this one is truly a pain to manage currently. But there's no real reason why you should have a single IP address (v4 or v6) in such a database. (That is, perhaps excepting a few well known addresses like 127.0.0.1). That is, I've never yet heard of a policy which says "addresses that start with a 10 are allowed in, because I like 10". Rather, the policy is "addresses from company X are allowed in" - and then when one looks, one sees that addresses from company X start with 10, and no-one else's do, so what goes in the policy is "addresses that start with 10" - then the router/filewall/whatever has to do less work, its vendor has to do less work, and you have to do lots more work. And you're asking for that state of affairs to continue? The policies should be expressed in a form that actually expresses what you want to say, and then should be being converted into something that the packet forwarding engines can handle (which means, bit values of addresses). As soon as that conversion gets to be automated, rather than done manually, it becomes trivial to repeat it as frequently as is necessary to keep up with any address changes - and what's more to automate that, so that it all happens automatically, whenever addresses alter. | Almost all of our 20000 customer networks use firewalls. Our addresses are | configured into these firewalls. Same there, they don't care about your address - they care about you. They shouldn't be configuring your address anywhere. It is only the primitive state of the existing tools that has led to this way of doing things. Let's fix that, rather than assuming there is no other way. | I am not sure if there is an IPv6 study group on the impact of changing | addresses, or if anyone has published anything regarding this topic. There was a working group that considered the issues. There needs to be more work on this - it is an important topic. | If anyone knows of where I can find information regarding this I would | appreciate having it. Look for the results that came from the pier working group (rfc1916 rfc2071 rfc2072), but don't expect too much. | I hate to say this to everyone who's worked so hard on IPv6. The current | IPv6 addressing schema is unusable by anyone except Internet providers | trying to serve the household and small business market. It needs to be0 | redone to gain the support of large corporations. It is well known that the current addressing plans are not what we would really like to have. But no-one yet has been able to suggest anything better that will actually work. There have been other suggestions, the "best of the rest" is probably Tony Hain's current suggestion for embedding locations in the address, so your address says where you are geographically, and hence is unrelated to any provider, etc. Similar things (with less analysis and detail) have been suggested before. The problem with any of these kinds of schemes is that to work properly, it requires particular connectivity - that is, it all still reverts to topological addressing, but with the topology constrained so addresses can be related to things other than which provider you happen to be connected to. There's never been any reason to presume that any kind of constrained net topology can ever be made to happen. Tony's draft allows for that by simply giving everyone the choice - use either ISP provided addresses, or connect to the constrained topology and get a fixed address based upon your physical location. It might work, my guess is that it won't. Having said all of that, let me also say that I'm not sure that your particular situation would be as bad as you make it seem to be. That is, if the sites you're connecting are on the IPv6 internet already then you should simply be able to use their IPv6 addresses from their regular internet connectivity. Those might change occasionally, but not all at once (ie: you're likely to have a continual stream of updates to make, but only comparatively small ones - and nothing more difficult than what happens due to new customers appearing, or old ones leaving). If the sites don't have IPv6 connectivity, and you're running a private net for your own internal purposes, then what do you care what the internet addressing plan is like? Just invent your own, assign your own addresses to the client sites, and you all use those. I kind of doubt that will be the case though, it would be rather like the private phone systems, who put in trunk lines to connect institutions to others assuming that the people wouldn't also be connected to the PSTN - they will be, and so their PSTN numbers can be (and are) used over the private lines - that makes things simpler for everyone (even though there things need to be updated occasionally when the PSTN numbers change). There may be other options as well - is the NUSLA proposal ever gets into implementations, then you could run things using site local addressing everywhere, so you'd be completely immune to any global address changes. That is, you'd essentially all just agree to keep your site local addresses (which have a "which site am I" identifier in them with NUSLA) distinct from each other, and then you could allow packets to pass between sites using those addresses. You get a flat unroutable address space, but your net is easily small enough that that isn't an issue. 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 Aug 8 02:42:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f789gHr14203 for ipng-dist; Wed, 8 Aug 2001 02:42:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f789g8D14179 for ; Wed, 8 Aug 2001 02:42:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11083 for ; Wed, 8 Aug 2001 02:42:15 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA28041 for ; Wed, 8 Aug 2001 03:42:17 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GHQ00IBATMCPP@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Wed, 08 Aug 2001 04:42:12 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f789f0m00339; Wed, 08 Aug 2001 04:41:03 -0500 (CDT) Date: Wed, 08 Aug 2001 04:40:59 -0500 From: Matt Crawford Subject: Re: (ngtrans) DNSEXT NGTRANS Joint meeting DRAFT minutes In-reply-to: "07 Aug 2001 09:56:05 EDT." To: Olafur Gudmundsson Cc: DNSEXT mailing list , ipng@sunroof.eng.sun.com Reply-to: DNSEXT mailing list Message-id: <200108080941.f789f0m00339@gungnir.fnal.gov> MIME-version: 1.0 X-Mailer: exmh version 2.0.2 2/24/98 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford noted that missing from questions is, we focus on "today", not if it is needed in future. E.g., changes in routing system might need A6. Not "changes in routing system" but "coupling of DNS prefix delegation to routing system's idea of prefix delegation." > Consensus building Here's the problem. There was no attempt at consenus *building* after the discussion, only a quick measurement of opinions at that point. Given that a state of consensus did not already exist at this point > Straw polling the 4 address options for rough consensus: > ...then a slightly louder hum when asked again... It is my possibly-mistaken recollection that only the first two question were asked twice, becaused of a long interval of discussion after the second. It seems to be everyone's recollection that the fourth alternative got distinctly less volume than any of the other three, yet these minutes state it otherwise. > Therefore, DNAME for bit label use is limited to experimental use. Er, I don't think there was any coupling of DNAME and bit-string labels in the question, so I think you mean to say "bit labels under the reverse tree" or something of that sort. > It was sense of the room that the hums indicated .. There was no meta-question asked about what the hums indicated. Maybe you mean to say "The sense of the room, as measured by hums, was...". But this raises the question of what does this phrase "sense of the room" mean? Further own your minutes you make the leap to > Summary of of meeting consensus to be verified on mailing lists: The sole contentious point seemed to be the four-pronged AAAA vs A6 question, and the aggregated (hum) mass of opinion did not show consensus by any accepted definition of the word, nor even rough consensus by most reckonings. > - AAAA stays on standards track in DNSEXT, > - A6 moved to experimental by DNSEXT I do not believe there was rough consensus on these points. There was a plurality in favor of this option. It's impossible to say whether it was a majority, but it was clearly not an overwhelming majority. > - Bitlabels moved to experimental by DNSEXT There was rough consensus on this. > - DNAME standardization is out scope. I do not recall this question having been asked of the room. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 04:53:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78BqTw14483 for ipng-dist; Wed, 8 Aug 2001 04:52:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78BqPD14476 for ; Wed, 8 Aug 2001 04:52:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19906 for ; Wed, 8 Aug 2001 04:52:30 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05835 for ; Wed, 8 Aug 2001 05:52:34 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GHQ00MC8ZMZ0X@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Wed, 08 Aug 2001 06:52:26 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f78BoXm00810; Wed, 08 Aug 2001 06:50:38 -0500 (CDT) Date: Wed, 08 Aug 2001 06:50:33 -0500 From: Matt Crawford In-reply-to: "08 Aug 2001 16:32:18 +0700." <3583.997263138@brandenburg.cs.mu.OZ.AU> To: Robert Elz Cc: Aldrin Isaac , ipng@sunroof.eng.sun.com Message-id: <200108081150.f78BoXm00810@gungnir.fnal.gov> MIME-version: 1.0 X-Mailer: exmh version 2.0.2 2/24/98 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ditto what kre said, plus there's also the possibility of doing away with address-based controls on access to your data altogether and substituting access by certificate or shared key at the application or transport level, or ipsec with something other than an address as the selector. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 04:57:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78Bv2c14534 for ipng-dist; Wed, 8 Aug 2001 04:57:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78BueD14506; Wed, 8 Aug 2001 04:56:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20632; Wed, 8 Aug 2001 04:56:45 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08378; Wed, 8 Aug 2001 05:56:41 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 08 Aug 2001 04:56:31 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 3D48CCECC2514CF0B497E402065A818F for plus 6 more; Wed, 08 Aug 2001 04:56:30 -0700 Reply-To: From: "Tony Hain" To: "Keith Moore" , "David R. Conrad" Cc: "D. J. Bernstein" , , , , Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Wed, 8 Aug 2001 12:56:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200108080130.VAA10224@astro.cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: F40C8580-63574749-B5727C79-E853A7A9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f78BueD14513 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > So if we want to avoid NAT in IPv6, we need to make renumbering > *much* easier than it is now. Or accept the reality that enforcing PA as the 'only' approach is in direct conflict with the ultimate goals of the consumer. > ... I think it's reasonable to assume that large numbers of > people will follow the path of least resistance, or perhaps, > of least apparent risk. This is the best description of the problem I have seen. A missing piece is that the local minimum is different depending on your perspective as provider or consumer. Our whole approach is biased toward the provider, partially because of scale, but mostly because they had a voice in the decision while the consumer did not. Yes scale is a real problem, but the fact that the consumer will find the path of least resistance is at least as big. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 05:34:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78CXMA14704 for ipng-dist; Wed, 8 Aug 2001 05:33:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78CXID14697 for ; Wed, 8 Aug 2001 05:33:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26977 for ; Wed, 8 Aug 2001 05:33:24 -0700 (PDT) Received: from charminar.wipsys.stph.net (charminar.wipsys.stph.net [196.12.38.162]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00698 for ; Wed, 8 Aug 2001 06:33:18 -0600 (MDT) Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by charminar.wipsys.stph.net (8.11.4/8.11.4) with SMTP id f78CWoS05393 for ; Wed, 8 Aug 2001 18:02:50 +0530 (IST) Received: from lbmail.mail.wipro.com ([196.12.37.250]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GHR1IC00.M9Y for ; Wed, 8 Aug 2001 18:02:36 +0530 Received: from 6c3 ([196.12.37.230]) by lbmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GHR1I700.FGS; Wed, 8 Aug 2001 18:02:32 +0530 Message-ID: <002801c12005$e0f59240$e6250cc4@wipsys.stph.net> Reply-To: "srinivas nalluri" From: "Srinivasa Rao Nalluri" To: "Matt Crawford" , "Robert Elz" Cc: "Aldrin Isaac" , References: <200108081150.f78BoXm00810@gungnir.fnal.gov> Subject: Re: Date: Wed, 8 Aug 2001 18:00:15 +0530 Organization: Wipro Technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit a test mail. please click reply bye Nalluri --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 06:09:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78D8iq14817 for ipng-dist; Wed, 8 Aug 2001 06:08:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78D8dD14810; Wed, 8 Aug 2001 06:08:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27366; Wed, 8 Aug 2001 06:08:45 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16657; Wed, 8 Aug 2001 06:08:44 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA12968; Wed, 8 Aug 2001 09:08:37 -0400 (EDT) Message-Id: <200108081308.JAA12968@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Masataka Ohta cc: "David R. Conrad" , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 17:30:20 +0859." <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> X-SUBJECT-MSG-FROM: Masataka Ohta Date: Wed, 08 Aug 2001 09:08:37 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The only thing to do is to have an RFC for the organization to tell > renumbering with A6 is as easy as with NAT. only thing is, it's not as easy with A6 as it is with NAT. if you use NATs to renumber, when you change prefixes the only thing you change is the NAT. the NAT does translation of addresses within external DNS queries and responses for you. all of your internal routers, firewalls, hosts, applications, etc. stay the same. if you renumber using IPv6, all of that state in routers, firewalls, hosts, applications, etc has to change somehow, and it has to change with minimal disruption of service. A6 only addresses one part of that. renumbering is a hard problem. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 06:17:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78DGQY14854 for ipng-dist; Wed, 8 Aug 2001 06:16:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78DG2D14847; Wed, 8 Aug 2001 06:16:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27322; Wed, 8 Aug 2001 06:15:28 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19733; Wed, 8 Aug 2001 06:15:26 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78DEol04262; Wed, 8 Aug 2001 20:14:59 +0700 (ICT) To: alh-ietf@tndh.net cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: "Tony Hain"'s message of "Wed, 08 Aug 2001 12:56:27 +0100." References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 20:14:50 +0700 Message-ID: <4260.997276490@brandenburg.cs.mu.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk alh-ietf@tndh.net said: | Or accept the reality that enforcing PA as the 'only' approach is in | direct conflict with the ultimate goals of the consumer. The ultimate goals of the consumer are surely to have a stable internet connection that works, and allows all available services. Or for many perhaps at an even higher level, to make lots of money however it can be made, and care about very little else. Very few ultimate consumers care at all about renumbering, except to the extent that it interferes with one of the above real goals. They care even less about the format of DNS resource records of course. If renumbering is forced, and that causes problems, and NAT seems to allow those problems to be avoided, then NAT is what people will do. Once NAT is seen as an inappropriate solution (which it will be once people start wanting most of their systems to be available as servers, not just clients, for at least some protocols) then they'll look to find something else that works. Geographic based addresses, with their likely increased costs might be the solution. Of course, if we can keep on working and get renumbering to work so easily and cleanly that it ceases to be any kind of real cost, then perhaps enforcing PA won't be seen as being in direct conflict with anything any more - as no-one (at the ultimate consumer level) will even notice it happening. That's what we should be working towards, what's more, it should be an attainable target - there's nothing so complex about configuring an IP address that it needs to be seen as some kind of black art, to be done once and never repeated. The only real problems are that with IPv4 we allowed the IP addresses to be configured everywhere, we assumed they were a fixture (more permanent that even a domain name, as they have essentially no vanity value) - and that has made the update process absurdly difficult. We just need to make sure that everyone is aware that the only places an IPv6 address should ever be written are in the DNS zone files and in router configs for networks (and there, in a form that router renumbering can update). Anywhere else you're ever tempted to enter an IPv6 address we need to find an alternative. 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 Aug 8 06:54:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78Ds5414925 for ipng-dist; Wed, 8 Aug 2001 06:54:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78DrbD14909; Wed, 8 Aug 2001 06:53:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01660; Wed, 8 Aug 2001 06:53:43 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24969; Wed, 8 Aug 2001 07:53:40 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 08 Aug 2001 06:53:29 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id A2C88D1230C34A3C8219918A5361221C for plus 4 more; Wed, 08 Aug 2001 06:53:28 -0700 Reply-To: From: "Tony Hain" To: "Robert Elz" Cc: , , , Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Wed, 8 Aug 2001 14:53:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4260.997276490@brandenburg.cs.mu.OZ.AU> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: E4850ADA-84DD4566-99E7CD15-05E1B8D3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f78DrbD14910 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: I have no arguments with your comments other than: > The only real problems are that with IPv4 we > allowed the IP addresses to be configured everywhere ... If *configuration* were the 'only' problem it might be possible to fix renumbering. The fact that applications expect they need to know about the addresses in use will compound the problem such that it will be very difficult if not impossible to make renumbering completely transparent. I have no doubt we can find a way to completely automate renumbering, but I seriously doubt that we can 'fix' all of the application developers, and their products. Given this state, the end user will be exposed to renumbering events. We either accept this and find a way to scale routing without renumbering, or accept that NAT will persist. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 07:38:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78EbrE15031 for ipng-dist; Wed, 8 Aug 2001 07:37:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78EbmD15024; Wed, 8 Aug 2001 07:37:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09142; Wed, 8 Aug 2001 07:37:49 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08388; Wed, 8 Aug 2001 08:37:45 -0600 (MDT) From: Masataka Ohta Message-Id: <200108081430.XAA04529@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA04529; Wed, 8 Aug 2001 23:30:44 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: from Tony Hain at "Aug 8, 2001 02:53:20 pm" To: Tony Hain Date: Wed, 8 Aug 2001 23:30:43 +0859 () CC: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony; > > The only real problems are that with IPv4 we > > allowed the IP addresses to be configured everywhere ... > > If *configuration* were the 'only' problem it might be possible > to fix renumbering. The fact that applications expect they need > to know about the addresses in use will compound the problem > such that it will be very difficult if not impossible to make > renumbering completely transparent. Are you talking about ancient whois implementation? > I have no doubt we can find > a way to completely automate renumbering, but I seriously doubt > that we can 'fix' all of the application developers, and their=20 > products. Given this state, the end user will be exposed to > renumbering events. We either accept this and find a way to > scale routing without renumbering, or accept that NAT will > persist. Or, are you saying an NAT server can be detached from old ISP and attached to new ISP keeping the existing connections? Masataka Ohta PS With end-to-end multihoming, it is possible that application/transport program periodically check DNS to be smoothly renumbered. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 07:45:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78EjbQ15078 for ipng-dist; Wed, 8 Aug 2001 07:45:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78EjXD15071; Wed, 8 Aug 2001 07:45:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10254; Wed, 8 Aug 2001 07:45:38 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23419; Wed, 8 Aug 2001 08:45:28 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78Eiml04668; Wed, 8 Aug 2001 21:44:50 +0700 (ICT) From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081308.JAA12968@astro.cs.utk.edu> References: <200108081308.JAA12968@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 21:44:48 +0700 Message-ID: <4666.997281888@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 08 Aug 2001 09:08:37 -0400 From: Keith Moore Message-ID: <200108081308.JAA12968@astro.cs.utk.edu> | if you use NATs to renumber, when you change prefixes the only thing | you change is the NAT. This is only true if you only consider your own work. When you change addresses though, lots of other people need to update their firewall configurations, etc. The recent message on the ipng list from Isaac Aldrin (and apologies if I inverted that name - the mail headers weren't clear...) shows that quite clearly - a major problem is notifying your peers of the new address and having them update their configurations. Of course, A6 doesn't solve that problem, though its use might make it a little simpler. That is, if have an A6 record that defines my network prefix, that I refer to from the A6 records for all my host names, etc, then I can tell my peer sites that they can use that same A6 record to configure their firewalls (and they can verify it using dnssec, etc). Then, when my addresses change, which I make known in the DNS by updating my prefix A6 record, your firewall should be able to automatically update itself. Assuming I'm sane (and the circumstances allow), I'll have two different prefixes for a while, both would be made known from the same prefix name in the DNS, your firewall would then allow both through during the transition - when the old address expires, your firewall will automatically stop allowing that old address in. I'd hate to think how many IPv4 firewalls exist that have IP addresses configured in them, where the owner (user) of the IPv4 address now is completely unrelated to the user at the time the firewall was configured. It's possible to achieve all this with AAAA as well, I could have an AAAA record that defines my prefix, but that would be used by nothing that I care about, so it would require real discipline to remember to keep that one updated. On the other hand, the A6 record would be referred to by most other A6 records in the zone file - that's one of the few that would need to be touched by a renumbering, so you can be fairly sure that updating it will never be forgotten. | if you renumber using IPv6, all of that state in routers, firewalls, | hosts, applications, etc has to change somehow, and it has to change | with minimal disruption of service. A6 only addresses one part of that. This is certainly true. I don't think anyone is claiming that A6 solves any problems of itself. What it does is remove a part of one impediment to getting a solution. That doesn't sound like much, and it probably isn't ... but I'd rather not have that impediment, than have to deal with it forever. | renumbering is a hard problem. That's certainly true too. 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 Aug 8 07:50:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78EndA15133 for ipng-dist; Wed, 8 Aug 2001 07:49:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78EnYD15126; Wed, 8 Aug 2001 07:49:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10031; Wed, 8 Aug 2001 07:49:38 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15509; Wed, 8 Aug 2001 07:49:38 -0700 (PDT) From: Masataka Ohta Message-Id: <200108081413.XAA04324@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA04324; Wed, 8 Aug 2001 23:13:27 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081308.JAA12968@astro.cs.utk.edu> from Keith Moore at "Aug 8, 2001 09:08:37 am" To: Keith Moore Date: Wed, 8 Aug 2001 23:13:27 +0859 () CC: "David R. Conrad" , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith; > > The only thing to do is to have an RFC for the organization to tell > > renumbering with A6 is as easy as with NAT. > > only thing is, it's not as easy with A6 as it is with NAT. It is. > if you use NATs to renumber, when you change prefixes the only thing > you change is the NAT. the NAT does translation of addresses within > external DNS queries and responses for you. all of your internal > routers, firewalls, hosts, applications, etc. stay the same. It is stupid if internal routers, firewalls, hosts, applications, etc. do not rely on DNS and use raw addresses. DNS does translation of addresses for all of your internal routers, firewalls, hosts, applications. However, the problem is that router autoconfiguration is a bad thing to do if we use DNS, regardless of whether we use renumbering on ISP change or not. > A6 only addresses one part of that. So, we should have router configuration mechanism where routers (and firewalls) automatically accept upper 48 bit of addresses but nothing more. > renumbering is a hard problem. Except for DNS glue, renumbering is trivially easy. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 07:59:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78Ex3F15190 for ipng-dist; Wed, 8 Aug 2001 07:59:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78EwxD15183; Wed, 8 Aug 2001 07:58:59 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11624; Wed, 8 Aug 2001 07:59:03 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22487; Wed, 8 Aug 2001 07:58:59 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id KAA13753; Wed, 8 Aug 2001 10:57:32 -0400 (EDT) Message-Id: <200108081457.KAA13753@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 21:44:48 +0700." <4666.997281888@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 10:57:32 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | if you renumber using IPv6, all of that state in routers, firewalls, > | hosts, applications, etc has to change somehow, and it has to change > | with minimal disruption of service. A6 only addresses one part of that. > > This is certainly true. I don't think anyone is claiming that A6 > solves any problems of itself. What it does is remove a part of one > impediment to getting a solution. That doesn't sound like much, and > it probably isn't ... but I'd rather not have that impediment, than > have to deal with it forever. agreed that we'd be better off without that impediment. but the A6 method of removing that impediment creates impediments of its own, and some folks believe it's not a good tradeoff. and it's hard to understand the value of A6 (to understand whether it is worth the cost) without having a good understanding of the total cost of renumbering. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 08:02:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78F1Kc15256 for ipng-dist; Wed, 8 Aug 2001 08:01:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78F1GD15248; Wed, 8 Aug 2001 08:01:16 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21056; Wed, 8 Aug 2001 08:01:16 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23985; Wed, 8 Aug 2001 08:01:15 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA13833; Wed, 8 Aug 2001 11:01:07 -0400 (EDT) Message-Id: <200108081501.LAA13833@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Masataka Ohta cc: Tony Hain , Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 23:30:43 +0859." <200108081430.XAA04529@necom830.hpcl.titech.ac.jp> X-SUBJECT-MSG-FROM: Masataka Ohta Date: Wed, 08 Aug 2001 11:01:07 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > With end-to-end multihoming, it is possible that application/transport > program periodically check DNS to be smoothly renumbered. that's insane. you've just decreased the reliability of applications by at least two nines. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 08:08:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78F81X15326 for ipng-dist; Wed, 8 Aug 2001 08:08:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78F7vD15319 for ; Wed, 8 Aug 2001 08:07:57 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13818 for ; Wed, 8 Aug 2001 08:08:03 -0700 (PDT) Received: from polaris.lgsi.co.in ([202.54.13.206]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28547 for ; Wed, 8 Aug 2001 08:07:56 -0700 (PDT) Received: from prashanth ([202.54.13.195]) by polaris.lgsi.co.in (Netscape Messaging Server 4.15) with ESMTP id GHR93200.4I6; Wed, 8 Aug 2001 20:46:14 +0530 From: "Basavaraj Unnibhavi" To: "Ipng" Cc: "Erik Nordmark" Subject: Prefix delete RA behaviour Date: Wed, 8 Aug 2001 20:38:10 +0530 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) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, If prefixes in the router are deleted by admin, what should be the behaviour of RA (Router advertisement). I think Neighbor discovery spec doesn't specify about this. Thanks in advance for clarification. Basavaraj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 08:21:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78FL4D15390 for ipng-dist; Wed, 8 Aug 2001 08:21:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78FL0D15383; Wed, 8 Aug 2001 08:21:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15546; Wed, 8 Aug 2001 08:21:06 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01377; Wed, 8 Aug 2001 08:20:59 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78FKZl04838; Wed, 8 Aug 2001 22:20:35 +0700 (ICT) From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081501.LAA13833@astro.cs.utk.edu> References: <200108081501.LAA13833@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 22:20:35 +0700 Message-ID: <4836.997284035@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 08 Aug 2001 11:01:07 -0400 From: Keith Moore Message-ID: <200108081501.LAA13833@astro.cs.utk.edu> | that's insane. you've just decreased the reliability of applications by | at least two nines. That makes no sense at all. If an application goes and checks the DNS, and gets no answer back, or anything else to indicate that communications should fail, it can simply ignore that, and just keep on using the address it has. That is, until/unless that address stops working. On the other hand, if the DNS tells you that the entity you're connecting to has been renumbered, then if you were willing to trust the address the DNS gave you initially, you'd be foolish to ignore it now... Using the updated address just has to be better than simply having things fail because the old address is no longer available. Of course, there are truly dumb ways to use addresses that can be imagined (and are probably even used) where you see changing addresses from what is really load balancing or similar. Implemented sanely those cause no problems (you see all the addresses, as long as the one you're using is still there, carry on, even if it isn't the one you'd pick if you were starting again now). And even there, using A6 as the DNS mechanism allows much better heuristics, if you have an A6 record that says "this is my address, and it relies on this other A6 for its prefix", and later you get the same result, but the value of the prefix has changed, then you can be fairly sure that a renumbering has happened - as distinct from simply getting back a different address, which gives you no clue as to why the address is no longer the same (and you can't really just compare bits, because from afar, you have no idea what is prefix and what isn't). 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 Aug 8 08:45:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78FjLv15533 for ipng-dist; Wed, 8 Aug 2001 08:45:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78FjHD15526; Wed, 8 Aug 2001 08:45:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23161; Wed, 8 Aug 2001 08:45:23 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23366; Wed, 8 Aug 2001 09:45:18 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78Fiil04981; Wed, 8 Aug 2001 22:44:46 +0700 (ICT) From: Robert Elz To: Daniel Senie cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> References: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 22:44:44 +0700 Message-ID: <4979.997285484@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 08 Aug 2001 11:13:52 -0400 From: Daniel Senie Message-ID: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> | Not to mention melting the 'net under ever increasing DNS load, since we'd | no longer be able to cache anything. Huh??? No-one ever said anything about changing the definition or use of the TTL field in DNS replies. If you get a TTL that says an address is valid for a day, then you can keep using it for a day without checking again. Or you can check again every 5 minutes if you want to, but the answers will just keep coming back from your local cache, each with a TTL 5 minutes shorter than the previous time... 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 Aug 8 09:26:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78GPX115754 for ipng-dist; Wed, 8 Aug 2001 09:25:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78GPKD15747 for ; Wed, 8 Aug 2001 09:25:25 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01974 for ; Wed, 8 Aug 2001 09:25:04 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19946 for ; Wed, 8 Aug 2001 09:25:03 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 08 Aug 2001 09:24:59 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id DC7F39B7A21A4592A8D63222FC63911C for plus 1 more; Wed, 08 Aug 2001 09:24:58 -0700 Reply-To: From: "Tony Hain" To: "Aldrin Isaac" , Subject: RE: None Date: Wed, 8 Aug 2001 17:24:56 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: D5F1AAA2-7F2D4DBB-861A4198-DDD7EE13 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f78GPUD15748 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Aldrin, I for one would like to thank you for the critique. One of the concerns I have had is that the current plans are biased to address the concerns of providers, simply because they had a voice in the process, while the end customers didn't. There are people trying to figure out how to deal with the multi-homing issues now, but again these are frequently focused on how to minimize the pain for provides, with hand-waving about how the result will be better for the end customer. Please feel free to inject some perspective into the debate, and encourage your peers to do the same. I would not want to mislead you that the result will necessarily be what you are looking for, but it stands little chance of being that without the input you could provide. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 09:35:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78GZHE15788 for ipng-dist; Wed, 8 Aug 2001 09:35:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78GZDD15781 for ; Wed, 8 Aug 2001 09:35:13 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02164; Wed, 8 Aug 2001 09:35:09 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11406; Wed, 8 Aug 2001 09:35:08 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f78GZ3820718; Wed, 8 Aug 2001 18:35:03 +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 SAA29394; Wed, 8 Aug 2001 18:35:02 +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.11.3/8.11.3) with ESMTP id f78GZ2u73336; Wed, 8 Aug 2001 18:35:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108081635.f78GZ2u73336@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Basavaraj Unnibhavi" cc: "Ipng" , "Erik Nordmark" Subject: Re: Prefix delete RA behaviour In-reply-to: Your message of Wed, 08 Aug 2001 20:38:10 +0530. Date: Wed, 08 Aug 2001 18:35:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If prefixes in the router are deleted by admin, what should be the behaviour of RA (Router advertisement). I think Neighbor discovery spec doesn't specify about this. => they are no more in RAs so hosts will deprecate and invalidate them at experations of lifetimes. Usually the router admin has an easy way to send some RAs with 0 lifetimes in case of an error (a router plugged on the wrong Ethernet for instance). You may have troubles with the two hour rule but in this case you can authenticate RAs too ... Regards Francis.Dupont@enst-bretagne.fr PS: my neighbor (the guy who plugged a router on the wrong socket) is smiling because no current implementation has the two hour rule enabled by default (read never :-), look at Arkko's drafts to know why. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 09:36:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78GZXM15797 for ipng-dist; Wed, 8 Aug 2001 09:35:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78GZTD15790; Wed, 8 Aug 2001 09:35:29 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15178; Wed, 8 Aug 2001 09:35:34 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26259; Wed, 8 Aug 2001 09:35:30 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78GZCl05164; Wed, 8 Aug 2001 23:35:12 +0700 (ICT) From: Robert Elz To: Daniel Senie cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> References: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 23:35:12 +0700 Message-ID: <5162.997288512@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 08 Aug 2001 12:12:15 -0400 From: Daniel Senie Message-ID: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> | Reread what Keith wrote. It was actually what Keith quoted that Otha-san wrote, not that that really matters. | If applications are going to use DNS to check for | changes in addressing, how is caching going to help? It isn't going to help, but it isn't going to be eliminated either. | You're suggesting the | local caches just answer the every-5-minute lookups, but that's useless if | the DNS lookups are used as a part of multihoming. I'm not sure of the relevance of multihoming - it was renumbering we were discussing, but never mind. | I interpreted the | periodic lookup as being a way for applications to find out that a remote | machine has migrated to a new address. Yes. | If local caches mask that migration, how's that help? It is giving the answer (as authorised by the owner of the data). Consider what happens now, and forget about long lived applications periodically polling - instead consider a series of short lived applications (like web page accesses, which do a DNS lookup for every URL usually). Given that caches answer now for those queries, for as long as the TTL allows, do you really see any difference at all? | Multihoming has to involve resiliancy. If the addresses are cached for a | day, saying "oh, your application will start working again tomorrow" is | unlikely to cut it. No. But that's never been the idea. | So, I guess the question back to the original point was, what information | is going to be IN those lookups that happen every 5 minutes? Nothing, which is why a sane app wouldn't do that, only when the TTL it originally received (assuming it is using an API that reveals the TTL of course) has expired. On the other hnd, other than increased traffic at the local DNS cache, checking the address more frequently doesn't hurt either. | If that | information needs to change on a minute by minute basis (or a 5 minute by 5 | minute basis) then caching is not going to help. No. Somehow I think you're missing the context of this whole discussion though. | So, the question is, to | use this effectively, do zones have to be set up with their TTL set to 60 | seconds? No, bit when you set a TTL on a record in the DNS, that's a promise that the data isn't going to change from the time someone fetches the record until the TTL has expired. No-one is planning on altering that. That is, that's true today, and will remain true tomorrow (you can cache this answer for at least 6 months...) The effect is that you need to handle TTLs and address changes together. The old address needs to remain valid while any RRs that were handed out are still alive. That's the DNS, and will remain. 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 Aug 8 09:37:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78GbDV15842 for ipng-dist; Wed, 8 Aug 2001 09:37:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78Gb7D15832; Wed, 8 Aug 2001 09:37:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01317; Wed, 8 Aug 2001 09:37:13 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13656; Wed, 8 Aug 2001 10:37:10 -0600 (MDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA14428; Wed, 8 Aug 2001 12:35:52 -0400 (EDT) Message-Id: <200108081635.MAA14428@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 22:20:35 +0700." <4836.997284035@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 12:35:52 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | that's insane. you've just decreased the reliability of applications by > | at least two nines. > > That makes no sense at all. > > If an application goes and checks the DNS, and gets no answer back, or > anything else to indicate that communications should fail, it can simply > ignore that, and just keep on using the address it has. That is, > until/unless that address stops working. but if the application starts using a new address, and that address doesn't reach the same peer (same socket on the same host) as before, then switching to the new address causes premature failure. the application is always better off continuing to use the old address, attempting to switch addresses only to recover from apparently broken connections. even then, the application has to guess as to whether it's more likely that the connection will begin working again or whether the old address is now permanently invalid. furthermore, it's always been the case that you could get multiple addresses in response to a name lookup, and there's no license to assume that those addresses are interchangable for open connections. in that case, which address does an application choose? > On the other hand, if the DNS tells you that the entity you're connecting > to has been renumbered, then if you were willing to trust the address the > DNS gave you initially, you'd be foolish to ignore it now... and you'd be foolish to switch while the old address is still working, for reasons cited above. > Of course, there are truly dumb ways to use addresses that can be > imagined (and are probably even used) where you see changing addresses > from what is really load balancing or similar. Implemented sanely those > cause no problems (you see all the addresses, as long as the one you're > using is still there, carry on, even if it isn't the one you'd pick > if you were starting again now). but this doesn't facilitate renumbering. > And even there, using A6 as the DNS mechanism allows much better > heuristics, if you have an A6 record that says "this is my address, and > it relies on this other A6 for its prefix", and later you get the same > result, but the value of the prefix has changed, then you can be fairly > sure that a renumbering has happened no you can't. just because DNS thinks that a new prefix exists for an address is no indication that the application on the other end can deal with your using the new prefix. it's hard enough to keep MX records in sync with SMTP servers, and that's something that should be explicitly managed. asking applications to keep track of changes in DNS doesn't strike me as an effective way to do renumbering. we need an interrupt mechanism, not a polling one, and we need something that works at the IP level, not using an application that is layered on top of IP. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 09:39:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78GdN515891 for ipng-dist; Wed, 8 Aug 2001 09:39:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78GdED15884 for ; Wed, 8 Aug 2001 09:39:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05860 for ; Wed, 8 Aug 2001 09:39:16 -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 KAA11534 for ; Wed, 8 Aug 2001 10:39:18 -0600 (MDT) Received: from localhost ([2001:618:7:2:ccf2:b8cf:75ef:dfef]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA09855 for ; Thu, 9 Aug 2001 01:42:00 +0900 (JST) Date: Thu, 09 Aug 2001 01:36:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Wrap up and last call: sin6_scope_id semantics User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Thu_Aug__9_01:36:50_2001-1" X-Dispatcher: imput version 980905(IM100) Lines: 310 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Thu_Aug__9_01:36:50_2001-1 Content-Type: text/plain; charset=US-ASCII (Most of you have probably lost the context..., but) We have discussed the semantics of the sin6_scope_id filed of the sockaddr_in6 structure (see attached). Here are the list of people who have explicitly stated opinions: A (the flat 32): Steve Deering, Erik Nordmark, YOSHIFUJI Hideaki, and I. B (the strict 4+28 split): Francis and Vladislav Yasevich C (the flexible 4+28 split): Dave Thaler and Markku Savela The majority is those who support A. However, I'm afraid we cannot call this "consensus" (only a few people have presented opinions anyways...) I think we've fully discussed this and we'll not be able to expect further information to tie-break the situation, so we should decide it now anyway. Possible approaches would be as follows: 1. pick the idea A as consensus 2. leave it as implementation dependent 3. just pick one randomly (by coin-toss, etc) I would, of course, like to propose #1. But, it would not be fair just to do so, so please speak up if anyone of you (still) oppose to the idea. Then we should choose 2 or 3 (it would actually be 2, #3 is ridiculous...). I'd really like to avoid #2 because it would annoy users so much, but it would even be better than not documenting it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_Aug__9_01:36:50_2001-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from localhost (localhost [127.0.0.1]) by condor.jinmei.org (8.11.2/8.11.2) with ESMTP id f5QIE9W26956 for ; Wed, 27 Jun 2001 03:14:09 +0900 (JST) Received: from shuttle.wide.toshiba.co.jp by localhost with POP3 (fetchmail-5.3.0) for jinmei@localhost (single-drop); Wed, 27 Jun 2001 03:14:09 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA29769 for ; Wed, 27 Jun 2001 03:13:13 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id DAA15077 for ; Wed, 27 Jun 2001 03:12:05 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id DAA12932 for ; Wed, 27 Jun 2001 03:12:05 +0900 (JST) Received: from maltese.wide.toshiba.co.jp ([202.249.10.99]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id DAA20936 for ; Wed, 27 Jun 2001 03:12:04 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id DAA12928 for ; Wed, 27 Jun 2001 03:12:04 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id DAA15073 for ; Wed, 27 Jun 2001 03:12:03 +0900 (JST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by orange.kame.net (8.9.3+3.2W/3.7W) with ESMTP id DAA26643 for ; Wed, 27 Jun 2001 03:12:03 +0900 (JST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07419; Tue, 26 Jun 2001 12:10:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26862; Tue, 26 Jun 2001 11:10:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QI7fdP010067 for ; Tue, 26 Jun 2001 11:07:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QI7ff0010066 for ipng-dist; Tue, 26 Jun 2001 11:07:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QI7bdP010059 for ; Tue, 26 Jun 2001 11:07:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15115 for ; Tue, 26 Jun 2001 11:07:45 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21346 for ; Tue, 26 Jun 2001 11:07:43 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA29717 for ; Wed, 27 Jun 2001 03:08:43 +0900 (JST) Date: Wed, 27 Jun 2001 03:07:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: summary of discussions about the semantics of sin6_scope_id User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 190 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk X-UIDL: iBZ"!%EH"!e@5!!\JK"! The following is a summary of discussions about the semantics of sin6_scope_id (aka flat 32 vs 4+28 split issue) we have had in the API list. Since some of key members of this issue are (accidentally) not on the list, I think this list is the best place to get a consensus. Please note that the text below is not the conclusion, but just a memo. I'd like to hear from others about the issues on this list based on the memo, discuss further if necessary, and try to get a consensus hopefully in a week or so. Then the result will (probably) be in the next revision of the scope architecture draft. In the following memo, I'll first show you definitions of the semantics, which will fall into 3 categories. I'll then describe (a summary of) opinions about each definition that I've heard in the discussions. I tried to be fair when describing them, but if I was wrong on some points or I missed something, please point it out. DEFINITIONS We have seen 3 definitions of semantics. I call them (A) the flat 32 (B) the strict 4+28 split (C) the flexible 4+28 split respectively. (A) The flat 32 uses the whole space (i.e. 32 bits) per scope. The uniqueness of IDs are only ensured in a single scope. Both (B) and (C) embed a scope type (4 bits) into the ID space. IDs in a particular scope is specified by the remaining 28 bits. And the 28-bit ID for a particular zone must also be unique in the scope. We can choose the 28-bit ID for a particular zone in any way, but Francis showed a concrete example: the interface index of a particular interface that belongs to the zone. I'll use this definition in the following examples, with the smallest interface index in the zone as the particular one. The only difference between (B) and (C) is about the usage. In "the strict strip", - if an ID is given with a (non-unspecified) address, the ID must be in the same scope type as the address in any context (including in a sockaddr_in6 structure). - even if the accompanying address is unspecified, we do not allow a non-zero ID for specifying a particular (or any) zone of a particular scope type. "The flexible split", on the other hand, does not have any such restriction; we allow any combination of a (scoped) address and a zone ID, provided that the scope type of the ID is equal to or smaller than the scope type of the address. Examples. The following topology is described in the scope architecture draft. --------------------------------------------------------------- | a node | | | | | | | | | | | | /--------------------site1--------------------\ /--site2--\ | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link A) Using the "flat 32", the zone indices are as follows: ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5 ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4 ID(site1) = 1, ID(site2) = 2 where ID(x) means the zone identifier for the zone "x". B&C) Using the strict/flexible 4+28 split, the zone indices are ID(intf1) = 0x10000001, ID(intf2) = 0x10000002, ..., ID(intf5) = 0x10000005 ID(link1) = 0x20000001, ID(link2) = 0x20000002, ID(link3) = 0x20000004, ID(link4) = 0x20000005 ID(site1) = 0x50000001, ID(site2) = 0x50000005 (assuming scope types like the "scop" field for multicast addresses.) And, if we take (B), the strict 4+28 split, then if we have a sockaddr_in6 structure, whose sin6_addr member is "fec0::1234", then its sin6_scope_id must be in the site scope, like 0x50000001. if we have a sockaddr_in6 structure, whose sin6_addr member is in6addr_any, then its sin6_scope_id must be 0. If we take (C), the flexible split, then if we have a sockaddr_in6 structure, whose sin6_addr member is "fec0::1234", then the scope type of its sin6_scope_id can be any scope which is equal to or smaller than the site scope. if we have a sockaddr_in6 structure, whose sin6_addr member is in6addr_any, the the sin6_scope_id is in any type of scope. Example usages of the flexibility are: 1) binding to "any interface in a given scope zone". This would mean, when sa.sin6_addr = unspecified, and sa.sin6_scope_id = 0x50000001, then bind(&sa) specifies the kernel to accept any packet arrived at the interface which belongs to the site zone 1. 2) when sa.sin6_addr = fec0::1234, and sa.sin6_scope_id = 0x20000002, then sendto(&sa) specifies the kernel to send the corresponding packet to one of the interfaces in the link zone 2. 3) allow IPV6_MULTICAST_IF (and IPV6_JOIN_GROUP) to use a scope id rather than just an ifindex, to let the stack choose the best interface in a given scope zone, similar to passing 0 today. OPINIONS Opinions from those who support A (including Steve and I): A-1 It provides backward compatibility to existing implementations that use interface indices as link indices, assuming one-to-one mapping between interfaces and links. A-2 There is no chance of misusages such as specifying a site zone ID for a link-local address. A-3 Since the IDs are typically specified with a (non-unspecified) address, like in the sockaddr_in6 structure, and the accompanying address itself provides the appropriate scope type, the strict split does not have much merit. We'd rather keep it "simple" to avoid misconfiguration described in A-2. A-4 The flexible split would make comparison of two scoped addresses (in a same scope type) more complicated; we may have a chance to compare {sin6_addr = fec0::1234, sin6_scope_id = 0x50000001} and {sin6_addr = fec0::1234, sin6_scope_id = 0x20000002} which may or may not specify a same single node, and we can't just compare the scope ID part by a "simple" operator '='. A-5 It would be the most readable, especially when we use digit integers for IDs, as specified in the current scope architecture draft. (e.g. recall the fact that 0x50000001 = 1342177281). Even if we allow hex integers or a dotted notation like 5.1, the flat ID would still be the most readable, and we'll see some situations that we want to type the ID itself, not an alias name of the ID, in some configuration files or something. A-6 We've never seen realistic examples of the flexibility that the flexible split would provide. On the other hand, we will see (or even have seen) some situations where we just want to disambigute scoped addresses (with the same scope type of the address). We should implement the "advanced" flexibility in a kind of advanced API, not using a part of the basic API; sin6_scope_id. (Note: I'm probably biased, and might not be fair, in this section. I have to say that some people pointed out that some of the points were just a matter of taste, and some points did not provide much difference. Also, please make additions in the items below, and corrections to the items above.) Opinions from those who support B (including Francis and Vlad - please add if I miss anyone): B-1 It provides global uniqueness. B-2 It provides zone IDs by themselves. B-3 It has no possible conflict with the interface index space. B-4 As for the readability, we should change the current definition, so that hex integers or the dotted notation would be allowed. B-5 It can provide the backward compatibility described in A-2 above and the readability in A-5, by specifying that the scope type 0 means the same scope type of the corresponding address (assuming a non unspecified address is given). B-6 the flexibility that the flexible split would provide is a "too much" or "too clever" stuff, and should not be in the basic API (basically the same argument as A-6 above) Opinions from those who support C (including Dave and Markku - please add if I miss anyone): C-1: the same benefits as B-1 to B-3 are applied to C. C-2: the same argument as B-4 as for the readability. C-3: the example usages described in "Example usages of the flexibility" above really benefits of this approach. C-4: we should not add API knobs to implement the flexibility, because it would confuse the users. 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 -------------------------------------------------------------------- --Multipart_Thu_Aug__9_01:36:50_2001-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 09:53:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78GqiH15936 for ipng-dist; Wed, 8 Aug 2001 09:52:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78GqeD15929; Wed, 8 Aug 2001 09:52:40 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19016; Wed, 8 Aug 2001 09:52:46 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05252; Wed, 8 Aug 2001 09:52:44 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA14676; Wed, 8 Aug 2001 12:51:23 -0400 (EDT) Message-Id: <200108081651.MAA14676@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Daniel Senie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 22:44:44 +0700." <4979.997285484@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 12:51:23 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No-one ever said anything about changing the definition or use of the > TTL field in DNS replies. this is a common source of confusion. the TTL field in DNS refers to the binding between the DNS name and the address. it has nothing whatsoever to do with the lifetime of the binding between the address and any hosts/sockets/processes that might be attached to 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 Aug 8 09:55:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78GsqQ15981 for ipng-dist; Wed, 8 Aug 2001 09:54:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78GsjD15974; Wed, 8 Aug 2001 09:54:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04840; Wed, 8 Aug 2001 09:54:51 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20372; Wed, 8 Aug 2001 10:54:50 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78GsUl05266; Wed, 8 Aug 2001 23:54:30 +0700 (ICT) From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081635.MAA14428@astro.cs.utk.edu> References: <200108081635.MAA14428@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 23:54:30 +0700 Message-ID: <5264.997289670@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 08 Aug 2001 12:35:52 -0400 From: Keith Moore Message-ID: <200108081635.MAA14428@astro.cs.utk.edu> | the application is always | better off continuing to use the old address, attempting to switch | addresses only to recover from apparently broken connections. Yes, probably, but you still need to discover the changed address. | furthermore, it's always been the case that you could get multiple addresses | in response to a name lookup, and there's no license to assume that those | addresses are interchangable for open connections. in that case, which | address does an application choose? Does it matter? If the connection is going to be broken anyway, because the old address is no longer valid, then you either pick a new one that works (and in many, probably even most, cases, any would do), or it fails and things are no more broken than they were before. The app could even try all the possible new addresses (assuming there are more than one) if it likes. | no you can't. just because DNS thinks that a new prefix exists for an | address is no indication that the application on the other end can | deal with your using the new prefix. No, it isn't. But if the DNS tells you that the old address is no longer valid, that is an indication that you're going to have to do something, sometime pretty soon. | to do renumbering. we need an interrupt mechanism, not a polling one, | and we need something that works at the IP level, not using an application | that is layered on top of IP. Unfortunately, not possible. IP is stateless, it has no idea who its peers are, to send some kind of "I just renumbered" indication (or I am about to renumber - same problem). TCP could handle that, but not everything uses TCP (UDP has the same problem as IP). Apps that need to deal with this (and that's really only those few that have long lived connections that need to be able to continue through events like renumbering ... that is, forget about HTTP, SMTP, probably FTP as well) are going to have to deal with this at the application level. That either means adding stuff to all the protocols ("I'm moving now...") or having the apps find some other way to discover that a peer has renumbered. Or outlaw renumbering, and somehow route flat /48's (or find some other addressing method that both aggregates nicely, and avoids needing renumbering). Or simply accept that some applications will necessarily fail when renumbering happens (and NAT can't fix it). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 09:58:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78GwHo16018 for ipng-dist; Wed, 8 Aug 2001 09:58:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78Gw2D16010; Wed, 8 Aug 2001 09:58:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10733; Wed, 8 Aug 2001 09:58:03 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22504; Wed, 8 Aug 2001 09:58:03 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA14715; Wed, 8 Aug 2001 12:56:41 -0400 (EDT) Message-Id: <200108081656.MAA14715@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Daniel Senie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 23:35:12 +0700." <5162.997288512@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 12:56:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | So, the question is, to > | use this effectively, do zones have to be set up with their TTL set to 60 > | seconds? > > No, bit when you set a TTL on a record in the DNS, that's a promise that > the data isn't going to change from the time someone fetches the record > until the TTL has expired. actually, it's not. if that were the case, we could never change a name-to-address binding without first setting TTL to zero (or providing a mechanism that allows them to diminish to zero) and waiting for older TTLs to expire. it's somewhat more realistic to say that a TTL indicates (for an address record) that any services referred to by the DNS name will continue to be available at that IP address until the TTL expires, if they're available at all. it's even more realistic to say that TTL indicates the amount of time for which the DNS administrator is willing to accept that the services associated with the DNS name will be effectively unavailable, should he/she need to change the addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 10:03:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78H2b416084 for ipng-dist; Wed, 8 Aug 2001 10:02:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78H2ID16062; Wed, 8 Aug 2001 10:02:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21534; Wed, 8 Aug 2001 10:02:24 -0700 (PDT) Received: from mochila.martin.fl.us (mochila.martin.fl.us [198.136.32.118]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24919; Wed, 8 Aug 2001 10:02:23 -0700 (PDT) Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id NAA17004; Wed, 8 Aug 2001 13:02:07 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id NAA29047; Wed, 8 Aug 2001 13:02:05 -0400 (EDT) Date: Wed, 8 Aug 2001 13:02:05 -0400 (EDT) From: Greg Maxwell To: Robert Elz cc: Keith Moore , , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5264.997289670@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 8 Aug 2001, Robert Elz wrote: [snip] > Unfortunately, not possible. IP is stateless, it has no idea who its > peers are, to send some kind of "I just renumbered" indication (or I am > about to renumber - same problem). TCP could handle that, but not everything > uses TCP (UDP has the same problem as IP). > > Apps that need to deal with this (and that's really only those few that > have long lived connections that need to be able to continue through events > like renumbering ... that is, forget about HTTP, SMTP, probably FTP as well) > are going to have to deal with this at the application level. That either > means adding stuff to all the protocols ("I'm moving now...") or having the > apps find some other way to discover that a peer has renumbered. > > Or outlaw renumbering, and somehow route flat /48's (or find some other > addressing method that both aggregates nicely, and avoids needing > renumbering). > > Or simply accept that some applications will necessarily fail when > renumbering happens (and NAT can't fix it). Or just accept that addresses identify paths to hosts, move your host definition to a higher level, and move to a transport level which can handle this such as SCTP. Such an approach would not be all or nothing, as legacy applications would still function, but not during renumbering. Such a solution would also save aggregation in the face of multihoming as is being discussed in the multi6 working group. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 10:04:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78H43k16116 for ipng-dist; Wed, 8 Aug 2001 10:04:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78H3xD16106 for ; Wed, 8 Aug 2001 10:03:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07177 for ; Wed, 8 Aug 2001 10:04:05 -0700 (PDT) Received: from INET-VRS-06.redmond.corp.microsoft.com ([131.107.3.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA07913 for ; Wed, 8 Aug 2001 11:04:03 -0600 (MDT) Received: from 157.54.9.108 by INET-VRS-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 10:03:29 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Aug 2001 10:03:06 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Aug 2001 10:03:04 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Aug 2001 10:02:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipngwg-icmp-v3-01.txt Date: Wed, 8 Aug 2001 10:02:08 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1610A11@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipngwg-icmp-v3-01.txt thread-index: AcEULIyR309qCYyNT5uJWFnsTrcilQL/OUeA From: "Mohit Talwar" To: Cc: , , "Brian Zill" X-OriginalArrivalTime: 08 Aug 2001 17:02:09.0593 (UTC) FILETIME=[DC5E3A90:01C1202B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f78H3xD16107 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, I believe there is something amiss from the current draft. To quote Brian... [Quote] Section 2.1 says "The type field indicates the type of the message. Its value determines the format of the remaining data". Section 2.4 point (a) says "If an ICMPv6 error message of unknown type is received, it MUST be passed to the upper layer". Section 2.4 point (d) says "In those cases where the internet-layer protocol is required to pass an ICMPv6 error message to the upper-layer process, the upper-layer protocol type is extracted from the original packet (contained in the body of the ICMPv6 error message) and used to select the appropriate upper-layer process to handle the error. The problem here is that since the format of the remaining data is type dependent, and we have an unknown error type, then we don't know how to find the original packet header in the remaining data section in order to extract the upper-layer protocol type. And we need to be able to do that if we're going to meet the requirements of section 2.4. It is the case that all defined error types have a 32 bit type-specific field, so treating all known errors the same way is possible today. It's the handling of unknown error types that causes the problem. [\Quote] Perhaps, if it is not considered too restrictive, we should enforce that all ICMPv6 error messages consist of the base ICMPv6 header followed by "32 bits of type-specific data", (followed by as much of the offending packet as will fit without making the error packet exceed 1280 bytes. Thanx, Mohit. PS Also, there is a typo in sections 2.4, e.4 and 2.4, e.5. These should refer to e.3, not e.2. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, July 24, 2001 3:29 AM Cc: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-ietf-ipngwg-icmp-v3-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v3-01.txt Pages : 20 Date : 23-Jul-01 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-v3-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 10:11:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78HAx616150 for ipng-dist; Wed, 8 Aug 2001 10:10:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78HAsD16143; Wed, 8 Aug 2001 10:10:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23286; Wed, 8 Aug 2001 10:11:01 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29136; Wed, 8 Aug 2001 10:11:00 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA14777; Wed, 8 Aug 2001 13:09:38 -0400 (EDT) Message-Id: <200108081709.NAA14777@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 23:54:30 +0700." <5264.997289670@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 13:09:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | no you can't. just because DNS thinks that a new prefix exists for an > | address is no indication that the application on the other end can > | deal with your using the new prefix. > > No, it isn't. But if the DNS tells you that the old address is no > longer valid, that is an indication that you're going to have to do > something, sometime pretty soon. DNS cannot tell you that old addresses are no longer valid, it can only tell you that some addresses should be valid. The absence of some address in a list of A (or AAAA or A6) records is not an indication that the address is not valid. > | to do renumbering. we need an interrupt mechanism, not a polling one, > | and we need something that works at the IP level, not using an application > | that is layered on top of IP. > > Unfortunately, not possible. IP is stateless, it has no idea who its > peers are, to send some kind of "I just renumbered" indication (or I am > about to renumber - same problem). TCP could handle that, but not > everything uses TCP (UDP has the same problem as IP). any system for renumbering (including the one you are proposing) will require changes to existing protocols. the question is, where is the best place to make these changes? my guess is, some combination of ND/RD and ICMP. but they're not going to be simple changes (well, not if we expect them to work well) because right now we don't even have the concept of a host or stack identifier in the architecture. (with the possible exception of the last 64 bits of a v6 address, and even then, not in all cases) > Apps that need to deal with this (and that's really only those few that > have long lived connections that need to be able to continue through events > like renumbering ... that is, forget about HTTP, SMTP, probably FTP as well) which apps are affected depends on the frequency of renumbering and the overlap during which multiple addresses are valid. and yes, if we can make these periods large enough (and the number of apps affected few enough) we can shift the burden of recovery to those apps. we really need for these to be explicitly chosen design parameters. my feeling is that the mean time between renumbering should be no worse than the mean time between shutdown of reasonable hosts for other reasons, which is to say, several months. that way, renumbering doesn't significantly affect application reliability. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 10:18:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78HHXv16217 for ipng-dist; Wed, 8 Aug 2001 10:17:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78HHOD16210; Wed, 8 Aug 2001 10:17:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10827; Wed, 8 Aug 2001 10:17:30 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02384; Wed, 8 Aug 2001 10:17:27 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78HH9l05405; Thu, 9 Aug 2001 00:17:09 +0700 (ICT) From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081656.MAA14715@astro.cs.utk.edu> References: <200108081656.MAA14715@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 00:17:09 +0700 Message-ID: <5403.997291029@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 08 Aug 2001 12:56:41 -0400 From: Keith Moore Message-ID: <200108081656.MAA14715@astro.cs.utk.edu> | actually, it's not. if that were the case, we could never change | a name-to-address binding without first setting TTL to zero (or | providing a mechanism that allows them to diminish to zero) | and waiting for older TTLs to expire. That's the way it should be done, yes. And it is the way that people who really care about keeping things working make changes where that is needed, but ... | it's somewhat more realistic to say that a TTL indicates (for an address | record) that any services referred to by the DNS name will continue to be | available at that IP address until the TTL expires, if they're available | at all. that's fine too. When I reread my words I see that I didn't really say the right thing, what I should have said, rather than "that the data isn't going to change" is "that the data is going to remain valid" and as long as you can keep reaching the address that you were given, that's OK, even if some other application, doing a new query (and not hitting the cache for whatever reason) would get a different answer. (and if I were a pedantic nerd, I'd make that "data are going to remain valid", or better, since a TTL applies to an RR "datum is going to remain valid", but I won't do either of those...) However... | it's even more realistic to say that TTL indicates the amount of time | for which the DNS administrator is willing to accept that the services | associated with the DNS name will be effectively unavailable, should | he/she need to change the addresses. That's not an unfair description of what often happens, mostly through ignorance of how things should be done though. Fortunately, with v6 (whatever DNS RR format is chosen) having multiple addresses assigned to an interface is designed as a normal case, rather than an unusual one. There should rarely be a need to make an old address go away before its old DNS data has had a chance to naturally expire, so the IPv4 style of "old address out, new address in" as a indivisible operation should gradually fade away, as the new methodology becomes familiar. 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 Aug 8 10:19:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78HId116257 for ipng-dist; Wed, 8 Aug 2001 10:18:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78HIVD16248; Wed, 8 Aug 2001 10:18:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11119; Wed, 8 Aug 2001 10:18:37 -0700 (PDT) Received: from as.vix.com (as.vix.com [204.152.187.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19860; Wed, 8 Aug 2001 11:18:35 -0600 (MDT) Received: from as.vix.com (localhost [127.0.0.1]) by as.vix.com (8.11.3/8.11.3) with ESMTP id f78HILH85940; Wed, 8 Aug 2001 10:18:22 -0700 (PDT) (envelope-from vixie@as.vix.com) Message-Id: <200108081718.f78HILH85940@as.vix.com> To: Daniel Senie cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from Daniel Senie of "Wed, 08 Aug 2001 11:13:52 EDT." <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Date: Wed, 08 Aug 2001 10:18:21 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Not to mention melting the 'net under ever increasing DNS load, since we'd > no longer be able to cache anything. that's a hyberbolic comment if ever i've heard one. there would still be caching. TTL's would be the same as they are now, which means they'd have to be reduced one TTL in advance of a renumbering event. btw, i'm seeing a moderate amount (hundreds of packets per second to a /23) of icmp from all of the companies (some white hat, some black hat) probing my network for security problems. traffic in and of itself is not a worry, is 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 Aug 8 10:27:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78HRJv16397 for ipng-dist; Wed, 8 Aug 2001 10:27:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78HRED16384; Wed, 8 Aug 2001 10:27:14 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27174; Wed, 8 Aug 2001 10:27:21 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07497; Wed, 8 Aug 2001 10:27:20 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA14897; Wed, 8 Aug 2001 13:25:59 -0400 (EDT) Message-Id: <200108081725.NAA14897@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Thu, 09 Aug 2001 00:17:09 +0700." <5403.997291029@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 13:25:59 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | it's even more realistic to say that TTL indicates the amount of time > | for which the DNS administrator is willing to accept that the services > | associated with the DNS name will be effectively unavailable, should > | he/she need to change the addresses. > > That's not an unfair description of what often happens, mostly through > ignorance of how things should be done though. sometimes ignorance, and sometimes a realistic assessment (based on knowledge of the users and applications affected) of the harm that will be done. > Fortunately, with v6 > (whatever DNS RR format is chosen) having multiple addresses assigned to > an interface is designed as a normal case, rather than an unusual one. the stacks are designed to deal with this, yes. whether ISPs and network administrators and firewalls and applications will also deal with this is a separate question. even so, renumbering for the purpose of new connections is a lot easier than renumbering established connections. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 10:32:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78HW3Y16440 for ipng-dist; Wed, 8 Aug 2001 10:32:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78HVwD16431; Wed, 8 Aug 2001 10:31:58 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17868; Wed, 8 Aug 2001 10:32:05 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25458; Wed, 8 Aug 2001 10:32:02 -0700 (PDT) From: Masataka Ohta Message-Id: <200108081718.CAA06297@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA06297; Thu, 9 Aug 2001 02:18:30 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> from Daniel Senie at "Aug 8, 2001 12:12:15 pm" To: Daniel Senie Date: Thu, 9 Aug 2001 02:18:28 +0859 () CC: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Daniel; > > | Not to mention melting the 'net under ever increasing DNS load, since > > we'd > > | no longer be able to cache anything. > > > >Huh??? > > > >No-one ever said anything about changing the definition or use of the > >TTL field in DNS replies. If you get a TTL that says an address is > >valid for a day, then you can keep using it for a day without checking > >again. Or you can check again every 5 minutes if you want to, but > >the answers will just keep coming back from your local cache, each with > >a TTL 5 minutes shorter than the previous time... > > Reread what Keith wrote. that he is crazy? > If applications are going to use DNS to check for > changes in addressing, how is caching going to help? Caching helps because applications won't check DNS again until TTL expires and even if it does cache will supress actual query. Caching helps other applications share the result of query. > You're suggesting the > local caches just answer the every-5-minute lookups, but that's useless if > the DNS lookups are used as a part of multihoming. I interpreted the > periodic lookup as being a way for applications to find out that a remote > machine has migrated to a new address. If local caches mask that migration, > how's that help? You are merely saying that DNS TTL should not be unnecessarily small. DNS semantics is that if TTL expires applications still relying on the answer should query again. BTW, it is also possible to modify applications to carry information that addresses change occurred and a list of new addresses. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 10:32:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78HW9J16447 for ipng-dist; Wed, 8 Aug 2001 10:32:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78HW3D16439; Wed, 8 Aug 2001 10:32:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14956; Wed, 8 Aug 2001 10:32:04 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13601; Wed, 8 Aug 2001 11:32:08 -0600 (MDT) From: Masataka Ohta Message-Id: <200108081722.CAA06350@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA06350; Thu, 9 Aug 2001 02:22:40 +0900 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081651.MAA14676@astro.cs.utk.edu> from Keith Moore at "Aug 8, 2001 12:51:23 pm" To: Keith Moore Date: Thu, 9 Aug 2001 02:22:39 +0859 () CC: Robert Elz , Daniel Senie , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith; > > No-one ever said anything about changing the definition or use of the > > TTL field in DNS replies. > > this is a common source of confusion. > > the TTL field in DNS refers to the binding between the DNS name and > the address. it has nothing whatsoever to do with the lifetime > of the binding between the address and any hosts/sockets/processes > that might be attached to it. What you don't understand is that, today, most users/applications use DNS name for identification. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 10:36:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78HaZE16520 for ipng-dist; Wed, 8 Aug 2001 10:36:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78HaWD16513 for ; Wed, 8 Aug 2001 10:36:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16156 for ; Wed, 8 Aug 2001 10:36:38 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05506 for ; Wed, 8 Aug 2001 11:36:33 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78HaGl05438; Thu, 9 Aug 2001 00:36:17 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 00:36:16 +0700 Message-ID: <5436.997292176@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 09 Aug 2001 01:36:50 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | The majority is those who support A. Actually, it wasn't, you had 4 supporting A, and 4 not supporting A. A might have more support than either of the others, but not majority support... I'm not sure I know or care enough about this to offer an opinion, but I would like to ask a question .... | A) Using the "flat 32", the zone indices are as follows: | | ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5 | ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4 | ID(site1) = 1, ID(site2) = 2 Would another variation of that approach result in ID(site2) == 5 and ID(link4) == 5 ? And I don't care if ID(link2) is 2 or 3, and whether ID(site1) is 1 2 3 or 4. That is, pick the scope identifier of a lower level object that is within the higher level object as the identifier for that object. That is to avoid the problem where "1" means one place in one context and somewhere totally different in another. Instead "2" in link context would mean a particular link, in site context it would mean a collection of links, but the link "2" would certainly be one of them. With things defined that way, I think A would suit me just fine (not that I'd count my opinion on this issue), without it, I think I'd prefer B or C, just so the ambiguity is avoided. 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 Aug 8 10:58:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78HvXJ16617 for ipng-dist; Wed, 8 Aug 2001 10:57:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78HvTD16610; Wed, 8 Aug 2001 10:57:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04795; Wed, 8 Aug 2001 10:57:35 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25274; Wed, 8 Aug 2001 11:57:30 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78Huol05602; Thu, 9 Aug 2001 00:56:50 +0700 (ICT) From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081709.NAA14777@astro.cs.utk.edu> References: <200108081709.NAA14777@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 00:56:50 +0700 Message-ID: <5600.997293410@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 08 Aug 2001 13:09:38 -0400 From: Keith Moore Message-ID: <200108081709.NAA14777@astro.cs.utk.edu> | DNS cannot tell you that old addresses are no longer valid, it can only | tell you that some addresses should be valid. The absence of some address | in a list of A (or AAAA or A6) records is not an indication that the | address is not valid. I'm not sure I agree with that. The RRset should be the complete list of addresses that belong to a name (which isn't necessarily the complete set that belong to the node that owns the name of course). If an address isn't in the RRset, then it doesn't belong to the name, by definition, and hence, is invalid as a translation of the name. Whether that address still happens to reach the entity that it reached yesterday, when it was a valid translation of the name is a different question. | any system for renumbering (including the one you are proposing) | will require changes to existing protocols. the question is, | where is the best place to make these changes? my guess is, | some combination of ND/RD and ICMP. I'm not sure it is possible. Sure, a node could respond with some kind of message to a peer that sends a packet to an address that the node is in the process of deprecating - but that doesn't help at all for all the other peers that don't happen to send any traffic during the deprecation period. | which apps are affected depends on the frequency of renumbering and the | overlap during which multiple addresses are valid. The overlap period, yes, the frequency, no, not really. I can renumber 7 times in a day, and as long as the first (and rest) of those addresses remain valid long enough, then all is OK. | we really need for these to be explicitly chosen design parameters. That means then the overlap period. Unfortunately, I suspect that's not possible. | my feeling is that the mean time between renumbering should be no worse | than the mean time between shutdown of reasonable hosts for other reasons, | which is to say, several months. that way, renumbering doesn't | significantly affect application reliability. And unfortunately you're trying to equate two measures that are likely moving in opposite directions. Hosts (and OS's) are becoming more stable, and remaining running between shutdowns far longer than used to be possible (I recall the days when computers were turned off each night when people went home...) And renumbering is likely to become more necessary, hence more frequent, as the net gets bigger, and the routing problems get worse (assuming no revolutionary solution of course). But in any case, it isn't host uptime that counts, but application connection time - what you would like is for addresses to remain valid (after ceasing to be preferred) for at least as long as the average app connection is likely to remain. It would be nice to aim for that where possible, but circumstances being what they are, mandating it would just make us look foolish. 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 Aug 8 11:11:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78IAqJ16665 for ipng-dist; Wed, 8 Aug 2001 11:10:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78IAkD16658; Wed, 8 Aug 2001 11:10:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26386; Wed, 8 Aug 2001 11:10:52 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09797; Wed, 8 Aug 2001 12:10:55 -0600 (MDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id C140B31914; Wed, 8 Aug 2001 11:10:50 -0700 (PDT) Message-Id: <5.0.2.1.2.20010808093637.02ff22f8@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 08 Aug 2001 11:10:50 -0700 To: Masataka Ohta From: "David R. Conrad" Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> References: <5.0.2.1.2.20010807172339.0301adb0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ohta-san, At 05:30 PM 8/8/2001 +0859, Masataka Ohta wrote: >So, you are saying that the large organiation is currently accepting >to manually change IP addresses of DNS servers on renumbering, aren't >you? Yes. >If so, A6 is perfectly fine for it for easy and quick renumbering. I don't think so. A6 is only a small part of the full problem. >The only thing to do is to have an RFC for the organization to tell >renumbering with A6 is as easy as with NAT. But it wouldn't be since addresses are embedded in (manually edited) configuration files, filter lists, etc. Sorta reminds me of the IDN situation. Instead of focusing on the real problem (getting higher layers to do the right thing), the focus is on fixing the DNS... Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 11:56:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78Itql16937 for ipng-dist; Wed, 8 Aug 2001 11:55:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78ItlD16930; Wed, 8 Aug 2001 11:55:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19004; Wed, 8 Aug 2001 11:55:53 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19698; Wed, 8 Aug 2001 12:55:50 -0600 (MDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA15722; Wed, 8 Aug 2001 14:54:33 -0400 (EDT) Message-Id: <200108081854.OAA15722@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Thu, 09 Aug 2001 00:56:50 +0700." <5600.997293410@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 14:54:32 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | DNS cannot tell you that old addresses are no longer valid, it can only > | tell you that some addresses should be valid. The absence of some address > | in a list of A (or AAAA or A6) records is not an indication that the > | address is not valid. > > I'm not sure I agree with that. The RRset should be the complete > list of addresses that belong to a name (which isn't necessarily the > complete set that belong to the node that owns the name of course). why? nothing in the standards requires that all IP addresses be listed, and most applications are quite capable of using IP addresses as names for services. there's also no reason that you couldn't use a completely different mechanism than DNS to determine the IP address associated with a service. (we will certainly need to do this someday, as DNS cannot last forever) > If an address isn't in the RRset, then it doesn't belong to the name, > by definition, and hence, is invalid as a translation of the name. perhaps, but it might still be a valid address for the service that the user wants. > | any system for renumbering (including the one you are proposing) > | will require changes to existing protocols. the question is, > | where is the best place to make these changes? my guess is, > | some combination of ND/RD and ICMP. > > I'm not sure it is possible. Sure, a node could respond with some > kind of message to a peer that sends a packet to an address that the > node is in the process of deprecating - but that doesn't help at all > for all the other peers that don't happen to send any traffic during > the deprecation period. if hosts are notified when their address prefixes change, that notification can be forwarded to any connections (TCP or otherwise) that the host knows about. similarly, if those hosts can notify resident applications that the addresses prefixes have changed, those applications can at least potentially notify their peers. this doesn't solve the problem entirely, since more than one host in a conversation could be concurrently changing addresses. but since only the hosts and applications know who their communications peers are, that's where you have to start. > | which apps are affected depends on the frequency of renumbering and the > | overlap during which multiple addresses are valid. > > The overlap period, yes, the frequency, no, not really. I can renumber > 7 times in a day, and as long as the first (and rest) of those addresses > remain valid long enough, then all is OK. probably so. but there is also probably a practical limit to the number of address prefixes that should be used at any one time. > | we really need for these to be explicitly chosen design parameters. > > That means then the overlap period. > > Unfortunately, I suspect that's not possible. well, we appear to have some people assuming that renumberings will be so infrequent that we can disregard them, and others assuming that renumberings will be so frequent that protocols have to deal with them explicitly. that's no way to do engineering. for applications to make use of IPv6 there needs to be some reasonable bounds on tbe behavior of the network. > | my feeling is that the mean time between renumbering should be no worse > | than the mean time between shutdown of reasonable hosts for other reasons, > | which is to say, several months. that way, renumbering doesn't > | significantly affect application reliability. > > And unfortunately you're trying to equate two measures that are likely > moving in opposite directions. Hosts (and OS's) are becoming more > stable, and remaining running between shutdowns far longer than used to > be possible (I recall the days when computers were turned off each night > when people went home...) > > And renumbering is likely to become more necessary, hence more frequent, > as the net gets bigger, and the routing problems get worse (assuming no > revolutionary solution of course). I concur. > But in any case, it isn't host uptime that counts, but application connection > time - what you would like is for addresses to remain valid (after ceasing to > be preferred) for at least as long as the average app connection is likely > to remain. I don't think that's the right criterion - first of all, that would have 50% of all connections being broken; second, it's based on assumptions about the nature of traffic, which will vary widely over time. I'd rather say that we have expectations about how the network behaves - just as (say) end-to-end packet loss should be no worse than 20%, address bindings should be good for at least several days. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 12:11:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78JB0U17044 for ipng-dist; Wed, 8 Aug 2001 12:11:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78JAtD17037; Wed, 8 Aug 2001 12:10:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10623; Wed, 8 Aug 2001 12:11:01 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22545; Wed, 8 Aug 2001 12:11:00 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA15947; Wed, 8 Aug 2001 15:10:55 -0400 (EDT) Message-Id: <200108081910.PAA15947@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "David R. Conrad" cc: Masataka Ohta , "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 11:10:50 PDT." <5.0.2.1.2.20010808093637.02ff22f8@localhost> Date: Wed, 08 Aug 2001 15:10:55 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Sorta reminds me of the IDN situation. Instead of focusing on the real > problem (getting higher layers to do the right thing), the focus is on > fixing the DNS... we might disagree that higher layers are the best place to fix the problem or that the fix exclusively belongs there. but it should be clear that we cannot do a good job of fixing this with DNS alone. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 12:30:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78JTSE17129 for ipng-dist; Wed, 8 Aug 2001 12:29:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78JT9D17122; Wed, 8 Aug 2001 12:29:09 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18919; Wed, 8 Aug 2001 12:29:15 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04099; Wed, 8 Aug 2001 12:29:12 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f78JSvl06019; Thu, 9 Aug 2001 02:28:57 +0700 (ICT) From: Robert Elz To: Keith Moore cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108081854.OAA15722@astro.cs.utk.edu> References: <200108081854.OAA15722@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 02:28:57 +0700 Message-ID: <6017.997298937@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 08 Aug 2001 14:54:32 -0400 From: Keith Moore Message-ID: <200108081854.OAA15722@astro.cs.utk.edu> | why? nothing in the standards requires that all IP addresses be listed, Again, it depends upon exactly what you're measuring here. The DNS defines the name, and if it has A (or AAAA or A6) RR's, then those define the addresses that belong to that name. That someone might know of some other address that happens to reach the same piece of hardware isn't really relevant - even if the other address happens to work just as well. | there's also no reason that you couldn't use a completely | different mechanism than DNS to determine the IP address associated with | a service. (we will certainly need to do this someday, as DNS cannot | last forever) Perhaps. When that happens then we'll have two ways to define the mapping between names and addresses, and when they're not the same, we'll have a mess (unless we also design a whole new naming scheme to go with it, which is a rat hole I think I'll avoid in this discussion). | if hosts are notified when their address prefixes change, that notification | can be forwarded to any connections (TCP or otherwise) that the host knows | about. Yes, at the TCP level, things are easy (well, could be, assuming adequate protocol support, and "easy" is probably the wrong term even then, "possible" would be better). It is everything else that causes the problems. Long lived UDP NFS mounts are one to really worry about. With v6 they're almost all going to be able to use site local addressing, and so be immune, but they still show the problem - the server explicitly has no knowledge of who is connected, and it can be weeks between packets from clients to servers if nothing is happening... If the client just validates the name it was given whenever its address has expired, then it can pick up on address changes, and use the new address (the server doesn't care what address requests come to). Client renumberings in this scenario don't matter, as the server doesn't send unsolicited packets - only replies (so as long as the address remains valid for a RTT, that's enough...) Each protocol really needs to be investigated separately, what might work, and what mightn't will vary enormously. Which is another reason why attempting to fix it at the IP layer probably isn't the solution. | similarly, if those hosts can notify resident applications that the | addresses prefixes have changed, those applications can at least potentially | notify their peers. Only if the end that is renumbering has any idea who its peers are. That isn't always the case. | this doesn't solve the problem entirely, since more than one host | in a conversation could be concurrently changing addresses. yes, that part is the real hard one to handle - but if we can't get it right without that case, worrying about that one is a waste of energy. | but there is also probably a practical limit to the number | of address prefixes that should be used at any one time. Yes, but thanks to virtual web hosting (the old way) it isn't a limit we're going to reach with almost any renumbering frequency that is practical by any means... | well, we appear to have some people assuming that renumberings will be | so infrequent that we can disregard them, and others assuming that | renumberings will be so frequent that protocols have to deal with them | explicitly. that's no way to do engineering. for applications to | make use of IPv6 there needs to be some reasonable bounds on tbe | behavior of the network. Yes. Unfortunately, the very disagreement that you mention means that deciding what those bounds should be isn't going to be easy. Personally, I'm also not sure I need to know - I want to make it possible to renumber easily, which should make it possible to do frequently if needed, and then hope I almost never have to actually do it... That is, I want to be able to deal with the worst case, but will hope that the best case is what occurs. If the hopes fade, I will at least know that I'm not sunk - if they're realised, then everyone is happy. | I don't think that's the right criterion - first of all, that would have | 50% of all connections being broken; A factor of 2 or whatever isn't going to make any marked difference. | second, it's based on assumptions | about the nature of traffic, which will vary widely over time. Sure. Though we only care about the traffic that is likely to get caught in this net - anything too short lived, or whose characteristics make broken connections essentially irrelevant (ie: will retry anyway) can be ignored. We only need to include the stuff that wants to live a long life. | I'd rather say that we have expectations about how the network behaves - | just as (say) end-to-end packet loss should be no worse than 20%, Hmm... if it gets to double figures I give up for the day... But I don't think we've ever had such a definition, what packet loss is tolerable also depends heavily upon the applications. | address bindings should be good for at least several days. Would be a nice target. Just as long as we don't actually assume that we will be able to meet it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 12:50:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78Jmg017173 for ipng-dist; Wed, 8 Aug 2001 12:48:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78JmbD17166; Wed, 8 Aug 2001 12:48:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29849; Wed, 8 Aug 2001 12:48:43 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16254; Wed, 8 Aug 2001 12:48:42 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA16310; Wed, 8 Aug 2001 15:47:22 -0400 (EDT) Message-Id: <200108081947.PAA16310@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: Keith Moore , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Thu, 09 Aug 2001 02:28:57 +0700." <6017.997298937@brandenburg.cs.mu.OZ.AU> Date: Wed, 08 Aug 2001 15:47:22 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Date: Wed, 08 Aug 2001 14:54:32 -0400 > From: Keith Moore > Message-ID: <200108081854.OAA15722@astro.cs.utk.edu> > > | why? nothing in the standards requires that all IP addresses be listed, > > Again, it depends upon exactly what you're measuring here. The DNS > defines the name, and if it has A (or AAAA or A6) RR's, then those define > the addresses that belong to that name. > > That someone might know of some other address that happens to reach > the same piece of hardware isn't really relevant - even if the other > address happens to work just as well. it's relevant to renumbering, because renumbering affects whether those addresses continue to work well - independently of what the DNS says. > | there's also no reason that you couldn't use a completely > | different mechanism than DNS to determine the IP address associated with > | a service. (we will certainly need to do this someday, as DNS cannot > | last forever) > > Perhaps. When that happens then we'll have two ways to define the > mapping between names and addresses not necessarily. the input to such a service doesn't have to be service names (they could for instance be queries for resources matching several criteria). even if the input were service names, those names don't have to be from the same space as DNS names. there are already several applications that work this way, because DNS doesn't suit their needs. > | if hosts are notified when their address prefixes change, that > | notification can be forwarded to any connections (TCP or otherwise) > | that the host knows about. > > Yes, at the TCP level, things are easy (well, could be, assuming > adequate protocol support, and "easy" is probably the wrong term > even then, "possible" would be better). Right, I'm just generalizing this to "any thing for which the host's OS maintains per-connection state". So (for example) it would also be true of UDP sockets for which a remote address were bound to the socket. > If the client just validates the name it was given whenever its address > has expired, then it can pick up on address changes, and use the new > address (the server doesn't care what address requests come to). as explained earlier, this doesn't work in general. you're overloading the DNS name to do something it wasn't designed to do. > Each protocol really needs to be investigated separately, what might > work, and what mightn't will vary enormously. Which is another reason > why attempting to fix it at the IP layer probably isn't the solution. no, you can't fix everything at the IP layer. but the notifications that address prefixes are being changed (or that old ones are invalid) should originate with the network, not with DNS. > | similarly, if those hosts can notify resident applications that the > | addresses prefixes have changed, those applications can at least > | potentially notify their peers. > > Only if the end that is renumbering has any idea who its peers are. > That isn't always the case. no, but at least this will provide a mechanisms by which applications can be aware of their peers. existing non-connection-based applications won't be able to survive renumbering, no matter what fix we come up with. > | this doesn't solve the problem entirely, since more than one host > | in a conversation could be concurrently changing addresses. > > yes, that part is the real hard one to handle - but if we can't get it > right without that case, worrying about that one is a waste of energy. true enough. the question is whether a solution that fails to address that case is adequate. (or, are we also wasting our energy if we fail to address that case?) > | well, we appear to have some people assuming that renumberings will be > | so infrequent that we can disregard them, and others assuming that > | renumberings will be so frequent that protocols have to deal with them > | explicitly. that's no way to do engineering. for applications to > | make use of IPv6 there needs to be some reasonable bounds on tbe > | behavior of the network. > > Yes. Unfortunately, the very disagreement that you mention means that > deciding what those bounds should be isn't going to be easy. Still, I think we'd be better off if we started trying to get consensus on a figure, than by trying to make progress without a shared understanding of the problem. We've made recommendations on other design parameters, like prefix length. > Personally, I'm also not sure I need to know - I want to make it possible > to renumber easily, which should make it possible to do frequently if needed, > and then hope I almost never have to actually do it... > > That is, I want to be able to deal with the worst case, but will hope that > the best case is what occurs. Right. But I want to know what the worst reasonable case is so that I can design my applications to deal with it. > | I'd rather say that we have expectations about how the network behaves - > | just as (say) end-to-end packet loss should be no worse than 20%, > > Hmm... if it gets to double figures I give up for the day... I wish the network to my home worked that well. > But I don't think we've ever had such a definition, what packet loss > is tolerable also depends heavily upon the applications. Right. But at some point you stop expecting anything to work. > | address bindings should be good for at least several days. > > Would be a nice target. Just as long as we don't actually assume that > we will be able to meet it. Again, I think we need to be able to make *some* assumptions. Just as TCP doesn't survive arbitrary amounts of packet lossage, neither do applications survive arbitrary amounts of renumbering. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 15:20:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MK2F17573 for ipng-dist; Wed, 8 Aug 2001 15:20:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MJwD17566 for ; Wed, 8 Aug 2001 15:19:58 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27479 for ; Wed, 8 Aug 2001 15:20:05 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06634 for ; Wed, 8 Aug 2001 15:20:03 -0700 (PDT) Received: from localhost (host217-33-136-94.ietf.ignite.net [217.33.136.94]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id HAA12372; Thu, 9 Aug 2001 07:20:18 +0900 (JST) Date: Thu, 09 Aug 2001 07:15:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <5436.997292176@brandenburg.cs.mu.OZ.AU> References: <5436.997292176@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 50 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 09 Aug 2001 00:36:16 +0700, >>>>> Robert Elz said: > | The majority is those who support A. > Actually, it wasn't, you had 4 supporting A, and 4 not supporting A. > A might have more support than either of the others, but not majority > support... You could say that, but I believe B and C should be separate. Actually, - Francis (who supports B) said he said he'd rather prefer A to C, because C would introduce too much complexity. - Markku (or Dave? anyway who supports C) said he'd rather prefer A to B, because we'd not see much benefit to separate the field (i.e. 4+28) if we get rid of the flexibility that C provided. > I'm not sure I know or care enough about this to offer an opinion, but > I would like to ask a question .... > | A) Using the "flat 32", the zone indices are as follows: > | > | ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5 > | ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4 > | ID(site1) = 1, ID(site2) = 2 > Would another variation of that approach result in ID(site2) == 5 > and ID(link4) == 5 ? Yes, it would. > That is to avoid the problem where "1" means one place in one context > and somewhere totally different in another. Instead "2" in link context > would mean a particular link, in site context it would mean a collection > of links, but the link "2" would certainly be one of them. > With things defined that way, I think A would suit me just fine > (not that I'd count my opinion on this issue), without it, I think > I'd prefer B or C, just so the ambiguity is avoided. Hmm, I guess it would be okay to leave it as implementation dependent, that is, "we adopt the flat 32 model, but the actual mapping from a particular zone to a zone ID (sin6_scope_id) is implementation dependent." Does this make sense to you? 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 Aug 8 15:27:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MQmm17718 for ipng-dist; Wed, 8 Aug 2001 15:26:48 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MQkD17711 for ; Wed, 8 Aug 2001 15:26:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MP4h01624 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:25:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77IhVD11013; Tue, 7 Aug 2001 11:43:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01792; Tue, 7 Aug 2001 11:43:37 -0700 (PDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16374; Tue, 7 Aug 2001 12:43:37 -0600 (MDT) Received: from yarrow-wls.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f77IhIC17301 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 7 Aug 2001 14:43:18 -0400 Message-Id: <5.1.0.14.2.20010807143808.00a8ed00@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 Aug 2001 14:43:18 -0400 To: Keith Moore , James Aldridge From: Daniel Senie Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108071823.OAA07760@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:23 PM 8/7/01, Keith Moore wrote: >Seems like we really need a group to study how to do renumbering. >Such a group needs to consider not just DNS but everything that >renumbering affects - e.g. DNS, routers, hosts, firewalls, applications >using address-based authentication, long-running applications, and >large-scale distributed applications. We need to consider the >whole process of renumbering rather than trying to solve the problem >in a piecemeal fashion. > >Keith This could be a worthwhile undertaking. There are two possible aspects of such a group: developing protocols and standards to lessen the effort in renumbering, and providing information on how to survive renumbering in the present world. An example of providing information would be a handbook for the administrator facing a move to a new colo. Getting the timing of Registry changes (for TLD zone NS glue), DNS changes, and server changes done in proper order requires significant planning. I suspect many folks just get it wrong, and suffer with outages for longer than they need to. Having a document to enumerate the steps to follow could be a good deliverable of such a group. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.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 Aug 8 15:27:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MRJY17740 for ipng-dist; Wed, 8 Aug 2001 15:27:19 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MRHD17733 for ; Wed, 8 Aug 2001 15:27:17 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MPYe01654 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:25:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7814lD13192 for ; Tue, 7 Aug 2001 18:04:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11824 for ; Tue, 7 Aug 2001 18:04:54 -0700 (PDT) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17425 for ; Tue, 7 Aug 2001 19:04:51 -0600 (MDT) Received: from Volpar.com ([204.30.36.55]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id VAA06593; Tue, 7 Aug 2001 21:04:35 -0400 (EDT) Message-ID: <3B708B38.B3D36992@Volpar.com> Date: Tue, 07 Aug 2001 17:43:36 -0700 From: Dianna Adair Reply-To: Volpar@Volpar.com Organization: Volpar Inc X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Aldrin Isaac CC: ipng@sunroof.eng.sun.com Subject: Re: NO subject, no company, lots of complaints References: Content-Type: multipart/mixed; boundary="------------FBF36BD76C9EDA8A7BF58F0C" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------FBF36BD76C9EDA8A7BF58F0C Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 7 August 2001 "over 20000 customer networks which constitute over a million computer systems, of which over 150,000 subscribe to our data. " and you do not have the sophistication to include a subject title or identify what company you propose to represent, send with a hotmail address, and issue criticism against undefined vendor software? My humble opinion: Please spare the technical gurus the need to process these types of e-mails Dianna Adair Volpar Inc Aldrin Isaac wrote: > Before I begin, I would like to apologize for any incorrectness in this > message. I am very new to IPv6 so Im still trying to get all the facts > straight. > > A few individuals in the IPv6 community, including Steve Deering, have told > me that the IPv6 addressing schema has focused on Internet provider/vendor > needs, as the groups that decide on IPv6 do not have adequate, if any, > representation from the non Internet provider/vendor community. I know this > may be bad timing but I feel it is necessary to write to those it may > concern in order to re-iterate some issues. > > I work for a large private information provider. We connect privately to > over 20000 customer networks which constitute over a million computer > systems, of which over 150,000 subscribe to our data. Our private network > has around 250 POPs connecting over 80 countries to our data centers. We > have considered plans to peer several of these POPs to the Internet to > provide short-cuts for our customer networks to access various resources > on the Internet. Our network is, however, strictly private. The company > has little or no interest in becoming a network service provider, and even > less interest in becoming an Internet transit service provider. This, > unfortunately for us, means that we would not be eligible to apply for a > [Sub-]TLA, based on RFC 2450. > > In the current IPv6 addressing plan a [Sub-]TLA and all contained addressing > is owned by an Internet transit service provider. This presents several > problems. This provider may go out of business, adopt unacceptable business > policies, get bought by a business rival (btw, this has happened to us), > etc. If such things should happen to our [Sub-]TLA provider we stand a risk > of having to change our addressing. This would put our business at > considerable risk due to several factors. > > Although RFC 2347 describes a way to have addressing independence from > long-haul transit providers by connecting to the Internet via an > exchange, it says nothing about (1) how an exchange can provide dedicated > addressing to a global company, (2) how and who will administer it (3) will > multihoming via an exchange provide the routing insulation provided by > peering independantly? If an exchange is administered by a public body, > would we not be entitled to preferential considerations? Who has the > answers to these questions? > > We use the same routers that large providers use. We also happen to have > thousands of distributed servers on our network running several versions of > several operating systems. I have not seen any effort on the part of these > router and systems vendors to simplify the rapid change of addressing. For > us this means not only changing addresses on over 40,000 thousand > interfaces, but also changing over 100,000 lines of distributed policies. > Not to mention all the data storage, thresholding and alarm systems and > databases. Also, in my experience, massive changes have exposed bugs in > vendor software that have caused loss of service to our customers. For > example, when changing policy, if a line of policy does not implement > properly due to some race condition, this can cause loss of service and/or > exposure (btw, we have seen this happen). > > Almost all of our 20000 customer networks use firewalls. Our addresses are > configured into these firewalls. It takes over a year of letters and > meetings with 20000 customers to accomplish this. Not to mention tens of > thousands of man-hours. > > We not only have canned connections to customers, but also over 1000 > private connections to our own sources of data, each of which is unique to > that data provider. We need to privately peer with these corporations, > without the ISP in the middle. These peering points are full of policies in > both directions and on both sides. > > I am not sure if there is an IPv6 study group on the impact of changing > addresses, or if anyone has published anything regarding this topic. If > anyone knows of where I can find information regarding this I would > appreciate having it. > > The current addressing scheme does not solve the problem of multi-homing in > any concrete way either. There is a conflict in the current scheme between > aggregation, multi-homing and address transparency. If I want to make a > [Sub-]TLA provider in the Far East happy, Id need to use an address > assigned by him. However, this may not make any of the other 99 ISPs I > decide to peer with very happy. I can make every [Sub-]TLA provider happy > if I do IPv6 NAT using that providers assigned address. This, however, > defeats the IPv6 claim to rid the world of NAT and create full address > transparency. > > It seems to me that in the current addressing schema, things like route > aggregation and host autoconfiguration has taken precedence over some other > very serious issues. In what balance were these factors measured for route > aggregation to win? Route aggregation solves a single technical problem. > But it doesn't seem to solve any other significant business issue towards > the implementation of IPv6. The industry has proven capable of building > better routers that can handle more route entries. Im not against route > aggregation. I use it aggressively in our network. But I dont think its > a good idea for a company such as mines to be subjected to having our > address space outside our control. > > I see a lot of intelligent dialogue in these working groups. But it seems > to me no one wants to touch the issues that will actually move IPv6 into the > real world. > > I hate to say this to everyone who's worked so hard on IPv6. The current > IPv6 addressing schema is unusable by anyone except Internet providers > trying to serve the household and small business market. It needs to be > redone to gain the support of large corporations. > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------FBF36BD76C9EDA8A7BF58F0C Content-Type: text/x-vcard; charset=us-ascii; name="Volpar.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Dianna Adair Content-Disposition: attachment; filename="Volpar.vcf" begin:vcard n:Adair;Dianna tel;fax:408-986-8482 tel;work:408-986-8689 / 800-845-2323 x-mozilla-html:FALSE org:Volpar Inc adr:;;941 Laurelwood Rd ;Santa Clara ;CA;95054; version:2.1 email;internet:Volpar@Volpar.com x-mozilla-cpt:;-1 end:vcard --------------FBF36BD76C9EDA8A7BF58F0C-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 15:28:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MRqH17766 for ipng-dist; Wed, 8 Aug 2001 15:27:52 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MRnD17752 for ; Wed, 8 Aug 2001 15:27:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MQ6F01684 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:26:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f782cKD13369; Tue, 7 Aug 2001 19:38:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02986; Tue, 7 Aug 2001 19:38:26 -0700 (PDT) Received: from lox.sandelman.ottawa.on.ca (lox.sandelman.ottawa.on.ca [192.139.46.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07693; Tue, 7 Aug 2001 19:38:25 -0700 (PDT) Received: from nox.sandelman.ottawa.on.ca (nox.sandelman.ottawa.on.ca [209.151.24.6]) by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id WAA17223; Tue, 7 Aug 2001 22:38:23 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (port-40.ottawa2.achilles.net [209.151.2.47]) by nox.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f782chX17187 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 7 Aug 2001 22:39:25 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (localhost [[UNIX: localhost]]) by marajade.sandelman.ottawa.on.ca (8.11.0/8.11.0) with ESMTP id f781IT001109; Tue, 7 Aug 2001 21:18:30 -0400 (EDT) Message-Id: <200108080118.f781IT001109@marajade.sandelman.ottawa.on.ca> To: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com cc: dnsop@cafax.se Subject: Re: (ngtrans) DNSEXT NGTRANS Joint meeting DRAFT minutes In-reply-to: Your message of "Tue, 07 Aug 2001 09:56:05 EDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 07 Aug 2001 21:18:29 -0400 From: Michael Richardson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Olafur" == Olafur Gudmundsson writes: Olafur> Steve Deering noted that we have AAAA, and going to A6 0 is a "no Olafur> brainer", but if it is lots of work to change to A6 for a limited Olafur> value, is it worth it? While going to A6 0 is simple, if the stub resolver implementers simply ask for "A6 0", i.e. ask for A6 instead of AAAA as if it was AAAA, then if we come up with a new situation that *requires* A6 X (X!=0), then we are in trouble. Secondly, those code paths where X!=0 will not get tested even if they are written, and security may be involved, and wouldn't a buffer overflow bug in a stub resolver be pretty! ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.6, an Emacs/PGP interface iQCVAwUBO3CTZIqHRg3pndX9AQHSVgQAhHufxyqSAzXfL4ht5w9rxiJAdtfdJkSw dY3O3lG6Z0VAGiX58gZE2sUSBHMXKEZh60Y9/3rNkOddFtt9e1etM6XpAiebqqa/ SHThUXqjCkwDDgskuohEkh7WXEel9YHFjMzqQtw2PgGv0mErrj5Rz5b8ykxs/xJ1 KpSmo/bMAcw= =hGYV -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 15:29:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MSCv17775 for ipng-dist; Wed, 8 Aug 2001 15:28:12 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MS9D17768 for ; Wed, 8 Aug 2001 15:28:09 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MQRI01714 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:26:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f789vSD14225; Wed, 8 Aug 2001 02:57:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11884; Wed, 8 Aug 2001 02:56:40 -0700 (PDT) Received: from snout.autonomica.se (host217-33-136-183.ietf.ignite.net [217.33.136.183]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA04829; Wed, 8 Aug 2001 03:56:38 -0600 (MDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id D7ED21ED08; Wed, 8 Aug 2001 11:54:00 +0200 (CEST) To: Michael Richardson Cc: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) DNSEXT NGTRANS Joint meeting DRAFT minutes References: <200108080118.f781IT001109@marajade.sandelman.ottawa.on.ca> From: Johan Ihren Date: 08 Aug 2001 11:54:00 +0200 In-Reply-To: Michael Richardson's message of "Tue, 07 Aug 2001 21:18:29 -0400" Message-ID: <2cd766c1xj.fsf@snout.autonomica.se> Lines: 47 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Richardson writes: > >>>>> "Olafur" == Olafur Gudmundsson writes: > Olafur> Steve Deering noted that we have AAAA, and going to A6 0 is a "no > Olafur> brainer", but if it is lots of work to change to A6 for a limited > Olafur> value, is it worth it? > > While going to A6 0 is simple, if the stub resolver implementers > simply ask for "A6 0", i.e. ask for A6 instead of AAAA as if it was > AAAA, then if we come up with a new situation that *requires* A6 X > (X!=0), then we are in trouble. Which is exactly why I think that the claim that A6 0 is equivalent to AAAA is wrong. We should keep the AAAA as "what stub resolvers use" and synthesize it from a DNS infrastructure built from A6. Non-stub resolvers have a choice of whether to deal with possible chains by querying for an A6, or stay with the easier-to-digest form by querying for a AAAA. I really think that the humming in the room was based very much upon fears of delaying deployment further, regardless of technical solution. And a feeling that A6, even in the form of A6 0, would do that (which is correct). Since AAAA synthesis was presented as a transition mechanism, not the "final solution" those concerns won out. > Secondly, those code paths where X!=0 will not get tested even if > they are written, and security may be involved, and wouldn't a > buffer overflow bug in a stub resolver be pretty! By staying with the AAAA for stub resolvers this will simply not happen. Regards, Johan Ihren Autonomica PS. A popular description of the differences between AAAA and A6 is to claim that AAAA is optimized for read, while A6 is optimized for write. Possibly a better way out putting it would have been to say that AAAA is optimised for the (stub) resolver and end applications, while A6 is optimized for the nameserver and DNS infrastructure. By keeping AAAA synthetization as a permenent mechanism rather than as a transition issue it would be possible to optimize for both... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 15:29:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MSWO17786 for ipng-dist; Wed, 8 Aug 2001 15:28:32 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MSSD17779 for ; Wed, 8 Aug 2001 15:28:28 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MQk901744 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:26:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78A3AD14277; Wed, 8 Aug 2001 03:03:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12537; Wed, 8 Aug 2001 03:03:15 -0700 (PDT) Received: from snout.autonomica.se (host217-33-136-183.ietf.ignite.net [217.33.136.183]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08431; Wed, 8 Aug 2001 04:03:05 -0600 (MDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 8AB221ED08; Wed, 8 Aug 2001 12:02:58 +0200 (CEST) To: Paul A Vixie Cc: Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <200108071600.f77G0TH62930@as.vix.com> From: Johan Ihren Date: 08 Aug 2001 12:02:58 +0200 In-Reply-To: Paul A Vixie's message of "Tue, 07 Aug 2001 09:00:29 -0700" Message-ID: <2c8zguc1il.fsf@snout.autonomica.se> Lines: 36 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul A Vixie writes: > > I see a big difference between deprecating/moving to historic and changing > > status to experimental. Experemental implies further development. > > I don't see that difference here. Just as "let's let the market decide" > really just means "let's do whatever Microsoft wants", so it is that "let's > make it experimental" really just means "let's move on." (I find it amusing > that SRV was experimental but that Microsoft's use of it pulled it forward.) > > I was not able to be in London, but had I been there my comments would've been: > > Let's not expect stub resolvers to do the caching necessary to > understand either A6 or SIG/KEY -- those are things which servers > ought to use to talk to other servers. Stub resolvers making > recursive requests of their name servers should be using AAAA and > TSIG. AAAA synthesis of underlying A6, and TSIG to protect > verified KEY/SIG data for the last mile, is all a client needs. > Every argument against SIG/KEY or against A6 comes down to either > the caching problem or the complexity problem, and if we insulate > the end-stations from those problems, the arguments are reduced to > things which authority-side tools can be made to cope with. > > Hopefully this point was made by somebody. It was made, but not as succinctly. However, AAAA synthesis was mostly presented as a transition mechanism leading towards an A6-only future. I think that is a mistake and what worries people who are satisfied with their working AAAA-based stub resolver. Your point (in another mail) about renumbering as a defence againg being locked in by your provider was definitely not made. Johan Ihren Autonomica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 15:29:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MSo017802 for ipng-dist; Wed, 8 Aug 2001 15:28:50 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MSjD17795 for ; Wed, 8 Aug 2001 15:28:45 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MR3v01774 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:27:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78CCaD14580; Wed, 8 Aug 2001 05:12:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22074; Wed, 8 Aug 2001 05:12:31 -0700 (PDT) Received: from horst.ait.utk.edu (HORST.AIT.UTK.EDU [128.169.234.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17470; Wed, 8 Aug 2001 06:12:21 -0600 (MDT) Received: from horst.ait.utk.edu (uther@localhost) by horst.ait.utk.edu (8.11.0/8.11.0) with ESMTP id f78CC7V08616; Wed, 8 Aug 2001 08:12:07 -0400 Message-Id: <200108081212.f78CC7V08616@horst.ait.utk.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se, uther@horst.ait.utk.edu Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: Message from "D. J. Bernstein" of "08 Aug 2001 00:14:32 -0000." <20010808001432.8394.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Aug 2001 08:12:07 -0400 From: Ron Tipton Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The NAT sites I've seen are using it for precisely one reason: to > conserve precious IPv4 address space. They won't use NAT with IPv6. > > ---Dan Dan, I can only speak for myself, but we (the University of Tennessee) seriously considered using NAT for our dorm network, not because of lack of IPv4 address space, but because of lack of PORTABLE IPv4 address space. Most of our free IPv4 address space belonged to one of our ISPs and we DO NOT want to stay captive to them. In the end we decided to renumber our entire network to avoid NAT, but for us, NAT was a better solution than using IPv4 address space belonging to an ISP. After the pain of that renumbering, I assure you that if IPv6 address space only belongs to ISPs and not to the University of Tennessee, we will NAT to avoid captivity! r Ron Tipton Advanced Internet Technologies University of Tennessee -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 15:30:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MT8317813 for ipng-dist; Wed, 8 Aug 2001 15:29:08 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MT5D17806 for ; Wed, 8 Aug 2001 15:29:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MRN401804 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:27:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78FDwD15350; Wed, 8 Aug 2001 08:13:58 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16948; Wed, 8 Aug 2001 08:14:03 -0700 (PDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03148; Wed, 8 Aug 2001 08:14:01 -0700 (PDT) Received: from yarrow-wls.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f78FDqC10602 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 8 Aug 2001 11:13:53 -0400 Message-Id: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 08 Aug 2001 11:13:52 -0400 To: Keith Moore From: Daniel Senie Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <200108081501.LAA13833@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:01 AM 8/8/01, Keith Moore wrote: > > With end-to-end multihoming, it is possible that application/transport > > program periodically check DNS to be smoothly renumbered. > >that's insane. you've just decreased the reliability of applications by >at least two nines. Not to mention melting the 'net under ever increasing DNS load, since we'd no longer be able to cache anything. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.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 Aug 8 15:30:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MTVB17832 for ipng-dist; Wed, 8 Aug 2001 15:29:31 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MTND17822 for ; Wed, 8 Aug 2001 15:29:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MRfu01834 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:27:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78G0XD15605; Wed, 8 Aug 2001 09:00:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05607; Wed, 8 Aug 2001 08:59:22 -0700 (PDT) Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08488; Wed, 8 Aug 2001 09:59:19 -0600 (MDT) Received: from pc (nas-147-245.chicago-n.navipath.net [64.20.147.245]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with SMTP id f78FuAX117992; Wed, 8 Aug 2001 11:56:11 -0400 Message-ID: <004701c12023$3ed86dc0$67986f40@pc> From: "JIM R FLEMING" To: , , , , "D. J. Bernstein" Cc: "pdeblanc@usvi. net" , "@Quasar" , "orobles@nic. mx" , "Elisabeth. Porteneuve@cetp. ipsl. fr" , "edyson@edventure. com" , "Eric. Menge@sba. gov" , "JandL" , "Jay@Fenello. com" , , "joppenheimer@icbtollfree. com" , "krose@ntia. doc. gov" , "mcade@att. com" , "mueller@syr. edu" , "vint cerf" , "pindar@HK. Super. NET" , "linda@icann. org" , "karl@cavebear. com" , "quaynor@ghana. com" , "junsec@wide. ad. jp" , "andy@ccc. de" , "shkyong@kgsm. kaist. ac. kr" , "hans@icann. org" , "mkatoh@mkatoh. net" , "ken. fockler@sympatico. ca" , "f. fitzsimmons@att. net" , "Amadeu@nominalia. com" , , , , , "mouhamet@sonatel. sn" , "jplano@quorum. com. ar" , , "hph@online. no" , "gvaldez@nic. mx" , "cjw@remarque. org" , , , "ant@hivemind. net" , , "ietf@ietf. org" References: <200108071748.f77HmHH64664@as.vix.com> <5.0.2.1.2.20010807172339.0301adb0@localhost> Subject: held hostage by.... Date: Wed, 8 Aug 2001 10:20:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "David R. Conrad" To: "D. J. Bernstein" ; ; ; ; Sent: Tuesday, August 07, 2001 7:31 PM Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary > Dan, > > At 12:14 AM 8/8/2001 +0000, D. J. Bernstein wrote: > >The NAT sites I've seen are using it for precisely one reason: to > >conserve precious IPv4 address space. > > Large organizations also use NAT so they aren't held hostage by their > service provider. Really. If you don't believe me, ask any large > organization that does not have "portable" address space. > Large organizations also use NAT so that they are not held hostage by the ICANN/IANA multi-level-marketing (MLM) structure of the large IPv4 Address Block owners and the Regional Registries.[1] By using NAT, companies do not have to pay "Internet taxes" to inefficient organizations who continue to grow in size to support their traveling road shows of gad-flys, groupies, industry pundits and politicians. What should be a completely automated system of obtaining (and returning) blocks of IP addresses to pools maintained on reliable database servers, continues to be a *subjective*, manual system, which requires that people "grease" the right parts of the system in order to obtain a useable IPv4 address block. The large companies (some listed below) who already have plenty of IPv4 allocations, are immune from dealing with the MLM monster. They regularly claim they just do not see what the problem is, yet, they are able to grow in size and win contracts because they have the IPv4 allocations and others pay dearly in fees and administrative overhead to obtain meager resources. [1] http://www.iana.org/assignments/ipv4-address-space 000/8 IANA - Reserved Sep 81 001/8 IANA - Reserved Sep 81 002/8 IANA - Reserved Sep 81 003/8 General Electric Company May 94 004/8 Bolt Beranek and Newman Inc. Dec 92 005/8 IANA - Reserved Jul 95 006/8 Army Information Systems Center Feb 94 007/8 IANA - Reserved Apr 95 008/8 Bolt Beranek and Newman Inc. Dec 92 009/8 IBM Aug 92 010/8 IANA - Private Use Jun 95 011/8 DoD Intel Information Systems May 93 012/8 AT&T Bell Laboratories Jun 95 013/8 Xerox Corporation Sep 91 014/8 IANA - Public Data Network Jun 91 015/8 Hewlett-Packard Company Jul 94 016/8 Digital Equipment Corporation Nov 94 017/8 Apple Computer Inc. Jul 92 018/8 MIT Jan 94 019/8 Ford Motor Company May 95 020/8 Computer Sciences Corporation Oct 94 021/8 DDN-RVN Jul 91 022/8 Defense Information Systems Agency May 93 023/8 IANA - Reserved Jul 95 024/8 ARIN - Cable Block May 01 (Formerly IANA - Jul 95) 025/8 Royal Signals and Radar Establishment Jan 95 026/8 Defense Information Systems Agency May 95 027/8 IANA - Reserved Apr 95 028/8 DSI-North Jul 92 029/8 Defense Information Systems Agency Jul 91 030/8 Defense Information Systems Agency Jul 91 031/8 IANA - Reserved Apr 99 032/8 Norsk Informasjonsteknologi Jun 94 033/8 DLA Systems Automation Center Jan 91 034/8 Halliburton Company Mar 93 035/8 MERIT Computer Network Apr 94 036/8 IANA - Reserved Jul 00 (Formerly Stanford University - Apr 93) 037/8 IANA - Reserved Apr 95 038/8 Performance Systems International Sep 94 039/8 IANA - Reserved Apr 95 040/8 Eli Lily and Company Jun 94 041/8 IANA - Reserved May 95 042/8 IANA - Reserved Jul 95 043/8 Japan Inet Jan 91 044/8 Amateur Radio Digital Communications Jul 92 045/8 Interop Show Network Jan 95 046/8 Bolt Beranek and Newman Inc. Dec 92 047/8 Bell-Northern Research Jan 91 048/8 Prudential Securities Inc. May 95 049/8 Joint Technical Command May 94 Returned to IANA Mar 98 050/8 Joint Technical Command May 94 Returned to IANA Mar 98 051/8 Deparment of Social Security of UK Aug 94 052/8 E.I. duPont de Nemours and Co., Inc. Dec 91 053/8 Cap Debis CCS Oct 93 054/8 Merck and Co., Inc. Mar 92 055/8 Boeing Computer Services Apr 95 056/8 U.S. Postal Service Jun 94 057/8 SITA May 95 058/8 IANA - Reserved Sep 81 059/8 IANA - Reserved Sep 81 060/8 IANA - Reserved Sep 81 061/8 APNIC - Pacific Rim Apr 97 062/8 RIPE NCC - Europe Apr 97 063/8 ARIN Apr 97 064/8 ARIN Jul 99 065/8 ARIN Jul 00 066/8 ARIN Jul 00 067/8 ARIN May 01 068/8 ARIN Jun 01 069-079/8 IANA - Reserved Sep 81 080/8 RIPE NCC Apr 01 081/8 RIPE NCC Apr 01 082-095/8 IANA - Reserved Sep 81 096-126/8 IANA - Reserved Sep 81 127/8 IANA - Reserved Sep 81 128-191/8 Various Registries May 93 192/8 Various Registries - MultiRegional May 93 193/8 RIPE NCC - Europe May 93 194/8 RIPE NCC - Europe May 93 195/8 RIPE NCC - Europe May 93 196/8 Various Registries May 93 197/8 IANA - Reserved May 93 198/8 Various Registries May 93 199/8 ARIN - North America May 93 200/8 ARIN - Central and South America May 93 201/8 Reserved - Central and South America May 93 202/8 APNIC - Pacific Rim May 93 203/8 APNIC - Pacific Rim May 93 204/8 ARIN - North America Mar 94 205/8 ARIN - North America Mar 94 206/8 ARIN - North America Apr 95 207/8 ARIN - North America Nov 95 208/8 ARIN - North America Apr 96 209/8 ARIN - North America Jun 96 210/8 APNIC - Pacific Rim Jun 96 211/8 APNIC - Pacific Rim Jun 96 212/8 RIPE NCC - Europe Oct 97 213/8 RIPE NCC - Europe Mar 99 214/8 US-DOD Mar 98 215/8 US-DOD Mar 98 216/8 ARIN - North America Apr 98 217/8 RIPE NCC - Europe Jun 00 218/8 APNIC - Pacific Rim Dec 00 219-223/8 IANA - Reserved Sep 81 224-239/8 IANA - Multicast Sep 81 240-255/8 IANA - Reserved Sep 81 --------------------------------- Fortunately, that all now changes, since Microsoft has added the ability to use 2002 "IPv8 Addressing" in Windows 2000. Rather than allocating the IPv8 Address space to the same insiders above, the address space has been dispersed to thousands of regional and non-regional registries, in order to make it fair and open and to encourage automation and low-cost or no-cost allocations. People that get angry about this are generally expressing their concerns that THEY are no longer going to be able to hold people hostage over some simple IP address allocations. http://www.dot-arizona.com/IPv8/IPv4/ The "toy" IPv4 Internet is a sewer. IPv8 is designed to be a swamp to cover the sewer. IPv16 is the "high-ground".... ...here are some links... Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 15:30:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MTjt17846 for ipng-dist; Wed, 8 Aug 2001 15:29:45 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MTeD17837 for ; Wed, 8 Aug 2001 15:29:40 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MRws01864 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:27:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78G97D15633; Wed, 8 Aug 2001 09:09:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28572; Wed, 8 Aug 2001 09:09:13 -0700 (PDT) Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18672; Wed, 8 Aug 2001 10:09:09 -0600 (MDT) Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id JAA10815; Wed, 8 Aug 2001 09:10:50 -0700 (PDT) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2654.89) id ; Wed, 8 Aug 2001 09:07:42 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F40154CA5F@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Randy Bush'" , alh-ietf@tndh.net Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Wed, 8 Aug 2001 09:07:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12024.4066E080" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C12024.4066E080 Content-Type: text/plain; charset="iso-8859-1" NAT is here and will stay irregardless of what the IETF might want. The principal benefit of NAT to many businesses is that it is a very effective means of cutting off approximately 80% of network security problems at a stroke. Less functionality is precisely what these users want. On the home user front the popularity of NAT is increasing as people discover that a $100 box from Frys allows them to plug four computers into the home network instead of one. Rather than demanding that the network change to match the protocols it is time to accept the fact that for the next twenty years at least NAT is going to be a part of the infrastructure and look for ways in which that mode of use can be supported without denying the end user a substantial degree of functionality. Since the only part of a TCP/IP session that needs the external address is the initial setup, why not design protocols that allow that part to be delegated to a third party 'connection server'? After all any personal presence type protocol will need some form of static server since the user will hop between devices even if the devices themselves had static addresses. The trick would be to find some way to get the NAT boxes to cooperate. Phill Phillip Hallam-Baker FBCS C.Eng. Principal Scientist VeriSign Inc. pbaker@verisign.com 781 245 6996 x227 > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, August 08, 2001 9:15 AM > To: alh-ietf@tndh.net > Cc: ngtrans@sunroof.eng.sun.com; namedroppers@ops.ietf.org; > ipng@sunroof.eng.sun.com; dnsop@cafax.se > Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary > > > alh-ietf@tndh.net said: > | Or accept the reality that enforcing PA as the 'only' > approach is in > | direct conflict with the ultimate goals of the consumer. > > The ultimate goals of the consumer are surely to have a > stable internet > connection that works, and allows all available services. > > Or for many perhaps at an even higher level, to make lots of > money however > it can be made, and care about very little else. > > Very few ultimate consumers care at all about renumbering, > except to the > extent that it interferes with one of the above real goals. > They care > even less about the format of DNS resource records of course. > > If renumbering is forced, and that causes problems, and NAT > seems to allow > those problems to be avoided, then NAT is what people will > do. Once NAT > is seen as an inappropriate solution (which it will be once > people start > wanting most of their systems to be available as servers, not > just clients, > for at least some protocols) then they'll look to find > something else that > works. Geographic based addresses, with their likely > increased costs might > be the solution. > > Of course, if we can keep on working and get renumbering to > work so easily > and cleanly that it ceases to be any kind of real cost, then perhaps > enforcing PA won't be seen as being in direct conflict with > anything any > more - as no-one (at the ultimate consumer level) will even notice it > happening. > > That's what we should be working towards, what's more, it should be an > attainable target - there's nothing so complex about configuring an IP > address that it needs to be seen as some kind of black art, to be done > once and never repeated. The only real problems are that with IPv4 we > allowed the IP addresses to be configured everywhere, we assumed they > were a fixture (more permanent that even a domain name, as they have > essentially no vanity value) - and that has made the update process > absurdly difficult. We just need to make sure that everyone is aware > that the only places an IPv6 address should ever be written are in the > DNS zone files and in router configs for networks (and there, > in a form > that router renumbering can update). Anywhere else you're > ever tempted > to enter an IPv6 address we need to find an alternative. > > kre > > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > ------_=_NextPart_000_01C12024.4066E080 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C12024.4066E080-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 15:31:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f78MU3u17869 for ipng-dist; Wed, 8 Aug 2001 15:30:03 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78MU0D17862 for ; Wed, 8 Aug 2001 15:30:00 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f78MSHX01894 for ipng@sunroof.eng.sun.com; Wed, 8 Aug 2001 15:28:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f78GDLD15675; Wed, 8 Aug 2001 09:13:21 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09624; Wed, 8 Aug 2001 09:13:26 -0700 (PDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29750; Wed, 8 Aug 2001 09:13:26 -0700 (PDT) Received: from yarrow-wls.senie.com (h0040100ebb17.ne.mediaone.net [24.218.3.56]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.3/8.11.3) with ESMTP id f78GCFC15385 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 8 Aug 2001 12:12:16 -0400 Message-Id: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 08 Aug 2001 12:12:15 -0400 To: Robert Elz From: Daniel Senie Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <4979.997285484@brandenburg.cs.mu.OZ.AU> References: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:44 AM 8/8/01, Robert Elz wrote: > Date: Wed, 08 Aug 2001 11:13:52 -0400 > From: Daniel Senie > Message-ID: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> > > | Not to mention melting the 'net under ever increasing DNS load, since > we'd > | no longer be able to cache anything. > >Huh??? > >No-one ever said anything about changing the definition or use of the >TTL field in DNS replies. If you get a TTL that says an address is >valid for a day, then you can keep using it for a day without checking >again. Or you can check again every 5 minutes if you want to, but >the answers will just keep coming back from your local cache, each with >a TTL 5 minutes shorter than the previous time... Reread what Keith wrote. If applications are going to use DNS to check for changes in addressing, how is caching going to help? You're suggesting the local caches just answer the every-5-minute lookups, but that's useless if the DNS lookups are used as a part of multihoming. I interpreted the periodic lookup as being a way for applications to find out that a remote machine has migrated to a new address. If local caches mask that migration, how's that help? Multihoming has to involve resiliancy. If the addresses are cached for a day, saying "oh, your application will start working again tomorrow" is unlikely to cut it. So, I guess the question back to the original point was, what information is going to be IN those lookups that happen every 5 minutes? If that information needs to change on a minute by minute basis (or a 5 minute by 5 minute basis) then caching is not going to help. So, the question is, to use this effectively, do zones have to be set up with their TTL set to 60 seconds? ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.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 Aug 8 18:06:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7915lt18380 for ipng-dist; Wed, 8 Aug 2001 18:05:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7915gD18373; Wed, 8 Aug 2001 18:05:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA29002; Wed, 8 Aug 2001 18:05:45 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25745; Wed, 8 Aug 2001 18:05:44 -0700 (PDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA18362; Wed, 8 Aug 2001 21:05:30 -0400 (EDT) Message-Id: <200108090105.VAA18362@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hallam-Baker, Phillip" cc: "'Randy Bush'" , alh-ietf@tndh.net, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Wed, 08 Aug 2001 09:07:41 PDT." <2F3EC696EAEED311BB2D009027C3F4F40154CA5F@vhqpostal.verisign.com> Date: Wed, 08 Aug 2001 21:05:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The principal benefit of NAT to many businesses is that it is a very > effective means of cutting off approximately 80% of network security > problems at a stroke. Less functionality is precisely what these users want. Understood. But very little of that security benefit is really due to NAT; most of it is due to the fact that connections have to be initiated from within. That's certainly an artifact of NAT (actually NAPT) but it can be done just as easily without translating addresses. > Rather than demanding that the network change to match the protocols it is > time to accept the fact that for the next twenty years at least NAT is going > to be a part of the infrastructure and look for ways in which that mode of > use can be supported without denying the end user a substantial degree of > functionality. You may be right about NAT being here to stay. Problem is, once you have a NAT in the signal path there's no way to repair the damage that has been done. That substantial degree of functionality (not to mention reliability) is inherently lost. > Since the only part of a TCP/IP session that needs the external address is > the initial setup, why not design protocols that allow that part to be > delegated to a third party 'connection server'? Your premise is false. TCP/IP doesn't need the external address at all; it's happy as long as each end sees consistent source and destination addresses throughout the entire connection. It's the applications that need globally usable and stable endpoint identifiers. > After all any personal > presence type protocol will need some form of static server since the user > will hop between devices even if the devices themselves had static > addresses. The trick would be to find some way to get the NAT boxes to > cooperate. With this approach you need the NAT boxes to explicitly support every protocol, and that makes new protocols difficult to deploy. The alternative is to teach the NAT boxes to support 6to4, which any v6 protocol can use. But you make a good point about security. If people get the idea (correctly or not) that they're sacrificing security by supporting v6, they won't bother deploying it. We need to have v6 border routers that deliver the same degree of security as NATs do, without actually translating addresses. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 18:31:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f791Trb18507 for ipng-dist; Wed, 8 Aug 2001 18:29:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f791TnD18500; Wed, 8 Aug 2001 18:29:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07738; Wed, 8 Aug 2001 18:29:56 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11041; Wed, 8 Aug 2001 19:29:53 -0600 (MDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 0F35017DF; Wed, 8 Aug 2001 18:29:54 -0700 (PDT) Date: Wed, 8 Aug 2001 18:29:54 -0700 From: David Terrell To: Daniel Senie Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010808182954.B31440@pianosa.catch22.org> Reply-To: David Terrell References: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <4979.997285484@brandenburg.cs.mu.OZ.AU> <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net>; from dts@senie.com on Wed, Aug 08, 2001 at 12:12:15PM -0400 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 6:27PM up 18 days, 21:06, 35 users, load averages: 0.31, 0.23, 0.22 X-Baby: Theodore Marvin Wolpinsky Terrell born 162 days, 3 hours, 41 minutes, 56 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Aug 08, 2001 at 12:12:15PM -0400, Daniel Senie wrote: > At 11:44 AM 8/8/01, Robert Elz wrote: > > Date: Wed, 08 Aug 2001 11:13:52 -0400 > > From: Daniel Senie > > Message-ID: <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> > > > > | Not to mention melting the 'net under ever increasing DNS load, since > > we'd > > | no longer be able to cache anything. > > > >Huh??? > > > >No-one ever said anything about changing the definition or use of the > >TTL field in DNS replies. If you get a TTL that says an address is > >valid for a day, then you can keep using it for a day without checking > >again. Or you can check again every 5 minutes if you want to, but > >the answers will just keep coming back from your local cache, each with > >a TTL 5 minutes shorter than the previous time... > > Reread what Keith wrote. If applications are going to use DNS to check for > changes in addressing, how is caching going to help? You're suggesting the > local caches just answer the every-5-minute lookups, but that's useless if > the DNS lookups are used as a part of multihoming. I interpreted the > periodic lookup as being a way for applications to find out that a remote > machine has migrated to a new address. If local caches mask that migration, > how's that help? > > Multihoming has to involve resiliancy. If the addresses are cached for a > day, saying "oh, your application will start working again tomorrow" is > unlikely to cut it. I think they're talking about reestablishing existing connections if the address published in the DNS changes. I think that's pretty silly. Application protocols should (where appropriate) be able to reconnect, or users can -- and DNS records near a renumbering event should have low TTLs, or multiple A* records for a multihomed situation, and applications should not be caching records excessively (or at all, really), and making multiple attempts at multiple A* records. -- David Terrell | "We must go forward, not backwards; upwards, Nebcorp Prime Minister | not forwards; and always twirling, twirling, dbt@meat.net | twirling towards freedom!" http://wwn.nebcorp.com/ | - The Simpsons -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 18:32:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f791VUx18531 for ipng-dist; Wed, 8 Aug 2001 18:31:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f791VQD18524; Wed, 8 Aug 2001 18:31:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08000; Wed, 8 Aug 2001 18:31:32 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12560; Wed, 8 Aug 2001 18:31:32 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id D668D17F5; Wed, 8 Aug 2001 18:31:31 -0700 (PDT) Date: Wed, 8 Aug 2001 18:31:31 -0700 From: David Terrell To: Masataka Ohta Cc: Tony Hain , Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010808183131.C31440@pianosa.catch22.org> Reply-To: David Terrell References: <200108081430.XAA04529@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200108081430.XAA04529@necom830.hpcl.titech.ac.jp>; from mohta@necom830.hpcl.titech.ac.jp on Wed, Aug 08, 2001 at 11:30:43PM +0859 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 6:30PM up 18 days, 21:09, 35 users, load averages: 0.28, 0.31, 0.25 X-Baby: Theodore Marvin Wolpinsky Terrell born 162 days, 3 hours, 44 minutes, 45 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Aug 08, 2001 at 11:30:43PM +0859, Masataka Ohta wrote: > With end-to-end multihoming, it is possible that application/transport > program periodically check DNS to be smoothly renumbered. If you need this sort of feature set, you should probably be using something like SCTP which has explicit layer 4 support for multiple valid layer 3 addresses. -- David Terrell | "My question is, if a mime types, isn't dbt@meat.net | that kinda cheating?" http://wwn.nebcorp.com/ | - Jason Zych -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 20:01:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79315p18676 for ipng-dist; Wed, 8 Aug 2001 20:01:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79311D18669 for ; Wed, 8 Aug 2001 20:01:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04041 for ; Wed, 8 Aug 2001 20:01:07 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12986 for ; Wed, 8 Aug 2001 21:01:05 -0600 (MDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 58FE81762; Wed, 8 Aug 2001 20:01:06 -0700 (PDT) Date: Wed, 8 Aug 2001 20:01:06 -0700 From: David Terrell To: Robert Elz Cc: Aldrin Isaac , ipng@sunroof.eng.sun.com Subject: Re: your mail Message-ID: <20010808200105.D31440@pianosa.catch22.org> Reply-To: David Terrell References: <3583.997263138@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <3583.997263138@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Wed, Aug 08, 2001 at 04:32:18PM +0700 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 7:56PM up 18 days, 22:34, 34 users, load averages: 0.09, 0.20, 0.27 X-Baby: Theodore Marvin Wolpinsky Terrell born 162 days, 5 hours, 10 minutes, 1 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Aug 08, 2001 at 04:32:18PM +0700, Robert Elz wrote: > | but also changing over 100,000 lines of distributed policies. > > But this one is truly a pain to manage currently. But there's no real > reason why you should have a single IP address (v4 or v6) in such a database. > (That is, perhaps excepting a few well known addresses like 127.0.0.1). > > That is, I've never yet heard of a policy which says "addresses that start > with a 10 are allowed in, because I like 10". Rather, the policy is > "addresses from company X are allowed in" - and then when one looks, one > sees that addresses from company X start with 10, and no-one else's do, > so what goes in the policy is "addresses that start with 10" - then the > router/filewall/whatever has to do less work, its vendor has to do less > work, and you have to do lots more work. And you're asking for that state > of affairs to continue? > > The policies should be expressed in a form that actually expresses what > you want to say, and then should be being converted into something that the > packet forwarding engines can handle (which means, bit values of addresses). > As soon as that conversion gets to be automated, rather than done manually, > it becomes trivial to repeat it as frequently as is necessary to keep up > with any address changes - and what's more to automate that, so that it > all happens automatically, whenever addresses alter. interestingly enough, (and I'm not particularly pro A6), A6 chains make this easier. "Allow in all nets referenced by prefix.customer.example.net". -- David Terrell | "War is peace, Prime Minister, Nebcorp | freedom is slavery, dbt@meat.net | ignorance is strength http://wwn.nebcorp.com/ | Dishes are clean." - Chris Fester -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 8 20:23:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f793MUY18727 for ipng-dist; Wed, 8 Aug 2001 20:22:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f793MQD18720; Wed, 8 Aug 2001 20:22:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05864; Wed, 8 Aug 2001 20:22:28 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19763; Wed, 8 Aug 2001 20:22:16 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f793LZh00946; Thu, 9 Aug 2001 10:21:37 +0700 (ICT) From: Robert Elz To: David Terrell cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010808182954.B31440@pianosa.catch22.org> References: <20010808182954.B31440@pianosa.catch22.org> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <5.1.0.14.2.20010808111308.03f697d0@mail.amaranth.net> <4979.997285484@brandenburg.cs.mu.OZ.AU> <5.1.0.14.2.20010808120719.03df9bd0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 10:21:35 +0700 Message-ID: <944.997327295@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 8 Aug 2001 18:29:54 -0700 From: David Terrell Message-ID: <20010808182954.B31440@pianosa.catch22.org> For the purposes of this discussion, the difference between: | I think they're talking about reestablishing existing connections | if the address published in the DNS changes. and | Application protocols should (where appropriate) be able to reconnect, is immaterial. The question is whether the user sees an interruption, not how the interruption is handled. Keith was asking for it to be fixed below the level of the applications, presumably because updating lots of applications (different kinds, and just different implementations) is going to be a very long process, whereas if things could be fixed below that everything would see instant benefits. That's also why SCTP isn't the immediate answer, as aside from actually getting that implemented and deployed itself, the applications would still need to be converted to use it. | or users can But that is exactly what people are claiming is unacceptable. I suspect that what it really depends upon is the particular application's nature. Which also suggests that handling this in the applications, rather than below, is the appropriate place. | -- and DNS records | near a renumbering event should have low TTLs, or multiple A* records | for a multihomed situation, and applications should not be caching | records excessively (or at all, really), and making multiple attempts | at multiple A* records. Yes - but the question is how the app determines that it needs to do this. If a peer renumbers, and you don't get told that happened, then all you can expect to see is either packets vanishing into the void, or perhaps an ICMP host unreachable. Both of those are also consistent with a net link going down. If you wait long enough to be fairly confident that it isn't just a transient net blip, then you've already caused enough of an interruption to the service that there's a noticeable problem. So, the question then is just how you decide that you should be establishing a new connection (or somehow making an old one shift addresses). That's where the possibility of looking in the DNS and seeing that the address you were told to use before is no longer there arose in the first place. If there's some way that you can do that before there's any packet interruption, then the renumbering can be made truly invisible to the users. If we decide that we have to wait until we get some kind of failure indication (even just a single RTT (or RTO) without a response - even though that usually just indicates mild congestion) then you have already altered the operation of the app - though perhaps imperceptably. If it was possible to create a signalling protocol so peers could be informed of address changes, that would solve the problems (any address validity overlap time would allow for a seamless address switch). But I can't see how to make that work for stateless protocols (DNS, NFS, ...) where the server is renumbered - basically the server simply has no idea who should be informed. Perhaps we can live with these failing, given that it is likely to be rare that such things cross site boundaries (the general DNS case is already doing DNS watching for address changes of course, using the TTL - it is a proof by example that it can be made to work - the cases that fail are the two where addresses are configured, that is root servers (where the problems are so great that the answer seems to be to simply give those immutable addresses forever) and locating a back end resolver for a stub - which is unlikely to cross a site boundary). As for apps caching DNS replies - I disgaree there. The TTL is there to allow caching, anyone who agrees to respect the TTL should be able to cache a DNS reply and re-use it until the TTL expires. Attempt to outlaw that and you just end up with semantic quibbles "That's not my application caching that address, it is my application's local resolver that is doing the caching..." 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 Aug 8 20:28:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f793SQf18772 for ipng-dist; Wed, 8 Aug 2001 20:28:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f793SND18765 for ; Wed, 8 Aug 2001 20:28:23 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06114 for ; Wed, 8 Aug 2001 20:28:29 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12545 for ; Wed, 8 Aug 2001 20:28:23 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f793S3h00965; Thu, 9 Aug 2001 10:28:04 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: <5436.997292176@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 10:28:03 +0700 Message-ID: <963.997327683@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 09 Aug 2001 07:15:07 +0900 From: JINMEI Tatuya Message-ID: | You could say that, but I believe B and C should be separate. This is an irrelevant point (the whole question of majorities), but it doesn't matter whether they're separate or not, a majority is still more than 50% of the total, not just the greatest number of any of the possibilities. | Hmm, I guess it would be okay to leave it as implementation dependent, | that is, "we adopt the flat 32 model, but the actual mapping from a | particular zone to a zone ID (sin6_scope_id) is implementation | dependent." Does this make sense to you? Yes, I have no problem with that. But again, I don't know enough about the implications for my opinion on this to count for anything... 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 Aug 8 21:17:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f794Gb018837 for ipng-dist; Wed, 8 Aug 2001 21:16:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f794GXD18830; Wed, 8 Aug 2001 21:16:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14269; Wed, 8 Aug 2001 21:16:39 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA28448; Wed, 8 Aug 2001 22:16:41 -0600 (MDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA19383; Thu, 9 Aug 2001 00:13:47 -0400 (EDT) Message-Id: <200108090413.AAA19383@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Robert Elz cc: David Terrell , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of "Thu, 09 Aug 2001 10:21:35 +0700." <944.997327295@brandenburg.cs.mu.OZ.AU> Date: Thu, 09 Aug 2001 00:13:47 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith was asking for it to be fixed below the level of the applications, > presumably because updating lots of applications (different kinds, and > just different implementations) is going to be a very long process, > whereas if things could be fixed below that everything would see instant > benefits. or more generally, I'm asking for some agreement on the degree of address stability an application should be able to expect - hopefully one that is large enough that most applications can work without having to explicitly deal with the potential for renumbering. even for those applications that do have to deal with renumbering, DNS names do not always suffice as peer names, due to the common need to map a single DNS name onto multiple addresses, the delay inherent in DNS queries, and the degraded reliability. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 21:19:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f794IiQ18870 for ipng-dist; Wed, 8 Aug 2001 21:18:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f794IeD18863 for ; Wed, 8 Aug 2001 21:18:40 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10453 for ; Wed, 8 Aug 2001 21:18:46 -0700 (PDT) Received: from mailrelay.spctra.com ([198.235.204.29]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05556 for ; Wed, 8 Aug 2001 21:18:45 -0700 (PDT) Received: from exchange1.spctra.com (exchange1.spctra.com [10.1.0.20]) by mailrelay.spctra.com (8.11.3/8.11.3) with ESMTP id f794Duf00996; Thu, 9 Aug 2001 00:13:56 -0400 Received: by exchange1.spctra.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 00:21:19 -0400 Message-ID: <540707AF4B85D51180EB00902785AE980B6105@exchange1.spctra.com> From: Stephen Trigg To: Aldrin Isaac , "'Volpar@Volpar.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: NO subject, no company, lots of complaints Date: Thu, 9 Aug 2001 00:21:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Diana, Not withstanding the dubious origin of the mail (and perhaps the identity of the corporation was withheld for legitimate reasons) the criticisms stand in their own right. Moreover the technical gurus are precisely the people who need to address these issues. It is not only large companies (like the one described), but also small to medium sized enterprises with 'semi-autonomous', global networks who may potentially be trapped between the tyranny of service providers and the cost (many hidden) of complex implementations. Any approach to renumbering that is too costly, complex or labour intensive to be effectively implemented in the, often under-resourced and under-trained, SMEs - who are becoming one of the largest groups of users of the internet - is hardly to be considered a successful solution. A nice theoretical system which cannot be implemented in practice will not be a success - especially if the goal is to eliminate NAT. NAT is a tough competitor. I won't pretend to be up-to-speed on the technical issues here - I've only been following this discussion in detail for a couple of weeks - but it strikes me that a little more consideration of other types of end-user and their peculiar problems, at this stage, may make the stated goals more achievable. Steve > ---------- > From: Dianna Adair[SMTP:Volpar@Volpar.com] > Reply To: Volpar@Volpar.com > Sent: 08 August 2001 01:43 > To: Aldrin Isaac > Cc: ipng@sunroof.eng.sun.com > Subject: Re: NO subject, no company, lots of complaints > > <> > 7 August 2001 > > "over 20000 customer networks which constitute over a million computer > systems, of which over 150,000 subscribe to our data. " and you do not > have the > sophistication to include a subject title or identify what company you > propose > to represent, send with a hotmail address, and issue criticism against > undefined > vendor software? > > My humble opinion: Please spare the technical gurus the need to process > these > types of e-mails > > Dianna Adair > Volpar Inc > > > Aldrin Isaac wrote: > > > Before I begin, I would like to apologize for any incorrectness in this > > message. I am very new to IPv6 so I'm still trying to get all the facts > > straight. > > > > A few individuals in the IPv6 community, including Steve Deering, have > told > > me that the IPv6 addressing schema has focused on Internet > provider/vendor > > needs, as the groups that decide on IPv6 do not have adequate, if any, > > representation from the non Internet provider/vendor community. I know > this > > may be bad timing but I feel it is necessary to write to those it may > > concern in order to re-iterate some issues. > > > > I work for a large private information provider. We connect privately > to > > over 20000 customer networks which constitute over a million computer > > systems, of which over 150,000 subscribe to our data. Our private > network > > has around 250 POPs connecting over 80 countries to our data centers. > We > > have considered plans to peer several of these POPs to the Internet to > > provide "short-cuts" for our customer networks to access various > resources > > on the Internet. Our network is, however, strictly private. The > company > > has little or no interest in becoming a network service provider, and > even > > less interest in becoming an Internet transit service provider. This, > > unfortunately for us, means that we would not be eligible to apply for a > > [Sub-]TLA, based on RFC 2450. > > > > In the current IPv6 addressing plan a [Sub-]TLA and all contained > addressing > > is "owned" by an Internet transit service provider. This presents > several > > problems. This provider may go out of business, adopt unacceptable > business > > policies, get bought by a business rival (btw, this has happened to us), > > etc. If such things should happen to our [Sub-]TLA provider we stand a > risk > > of having to change our addressing. This would put our business at > > considerable risk due to several factors. > > > > Although RFC 2347 describes a way to have "addressing independence from > > long-haul transit providers" by connecting to the Internet via an > > "exchange", it says nothing about (1) how an exchange can provide > dedicated > > addressing to a global company, (2) how and who will administer it (3) > will > > multihoming via an exchange provide the routing "insulation" provided by > > peering independantly? If an exchange is administered by a public body, > > would we not be entitled to preferential considerations? Who has the > > answers to these questions? > > > > We use the same routers that large providers use. We also happen to > have > > thousands of distributed servers on our network running several versions > of > > several operating systems. I have not seen any effort on the part of > these > > router and systems vendors to simplify the rapid change of addressing. > For > > us this means not only changing addresses on over 40,000 thousand > > interfaces, but also changing over 100,000 lines of distributed > policies. > > Not to mention all the data storage, thresholding and alarm systems and > > databases. Also, in my experience, massive changes have exposed bugs in > > vendor software that have caused loss of service to our customers. For > > example, when changing policy, if a line of policy does not implement > > properly due to some race condition, this can cause loss of service > and/or > > exposure (btw, we have seen this happen). > > > > Almost all of our 20000 customer networks use firewalls. Our addresses > are > > configured into these firewalls. It takes over a year of letters and > > meetings with 20000 customers to accomplish this. Not to mention tens > of > > thousands of man-hours. > > > > We not only have "canned" connections to customers, but also over 1000 > > private connections to our own sources of data, each of which is unique > to > > that data provider. We need to privately peer with these corporations, > > without the ISP in the middle. These peering points are full of > policies in > > both directions and on both sides. > > > > I am not sure if there is an IPv6 study group on the impact of changing > > addresses, or if anyone has published anything regarding this topic. If > > anyone knows of where I can find information regarding this I would > > appreciate having it. > > > > The current addressing scheme does not solve the problem of multi-homing > in > > any concrete way either. There is a conflict in the current scheme > between > > aggregation, multi-homing and address transparency. If I want to make a > > [Sub-]TLA provider in the Far East happy, I'd need to use an address > > assigned by him. However, this may not make any of the other 99 ISPs I > > decide to peer with very happy. I can make every [Sub-]TLA provider > happy > > if I do IPv6 NAT using that providers assigned address. This, however, > > defeats the IPv6 claim to rid the world of NAT and create full address > > transparency. > > > > It seems to me that in the current addressing schema, things like route > > aggregation and host autoconfiguration has taken precedence over some > other > > very serious issues. In what balance were these factors measured for > route > > aggregation to win? Route aggregation solves a single technical > problem. > > But it doesn't seem to solve any other significant business issue > towards > > the implementation of IPv6. The industry has proven capable of building > > better routers that can handle more route entries. I'm not against > route > > aggregation. I use it aggressively in our network. But I don't think > it's > > a good idea for a company such as mines to be subjected to having our > > address space outside our control. > > > > I see a lot of intelligent dialogue in these working groups. But it > seems > > to me no one wants to touch the issues that will actually move IPv6 into > the > > real world. > > > > I hate to say this to everyone who's worked so hard on IPv6. The > current > > IPv6 addressing schema is unusable by anyone except Internet providers > > trying to serve the household and small business market. It needs to be > > redone to gain the support of large corporations. > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > http://explorer.msn.com/intl.asp > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Aug 8 22:28:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f795SE818959 for ipng-dist; Wed, 8 Aug 2001 22:28:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f795SAD18952 for ; Wed, 8 Aug 2001 22:28:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA20763 for ; Wed, 8 Aug 2001 22:28:17 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA27619 for ; Wed, 8 Aug 2001 23:28:14 -0600 (MDT) Received: from 157.54.9.100 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 22:26:53 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Aug 2001 22:26:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-default-addr-select-04.txt (fwd) Date: Wed, 8 Aug 2001 22:26:52 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FC5D@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-default-addr-select-04.txt (fwd) Thread-Index: AcEYX/Lc/9d6e9dKS963QlCy9qMIfwIMXmnw From: "Richard Draves" To: "Mauro Tortonesi" Cc: , "Brian Zill" X-OriginalArrivalTime: 09 Aug 2001 05:26:52.0962 (UTC) FILETIME=[E5BB4020:01C12093] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f795SAD18953 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [As some of you know, I've been away from email for the past two months. I am still not on any email lists, ipng included.] See comments below... > -----Original Message----- > From: Mauro Tortonesi [mailto:mauro@ferrara.linux.it] > Sent: Sunday, July 29, 2001 11:54 AM > To: Richard Draves > Subject: draft-ietf-default-addr-select-04.txt (fwd) > > > > you've probably missed this mail i've posted to the ipng ml ;-) > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > > ---------- Forwarded message ---------- > Date: Fri, 20 Jul 2001 19:07:29 +0200 (CEST) > From: Mauro Tortonesi > To: ipng@sunroof.eng.sun.com > Subject: draft-ietf-default-addr-select-04.txt > > > last monday i have revised > draft-ietf-default-addr-select-04.txt, and i have some > questions and minor editorial comments: > > > Page 1: > > Abstract > > [...] > > All IPv6 nodes, including both hosts and routers, must implement > default address selection as defined in this specification. > > why "must" and not "MUST"? I have the vague impression that it's best to avoid overuse of capitalized MUST/SHOULD/etc, but I am happy to defer here to those with more RFC experience. > Page 5: > > > 2.3. IPv6 Addresses with Embedded IPv4 Addresses > > IPv4-compatible addresses [2] and 6to4 addresses [12] contain an > embedded IPv4 address. For the purposes of this document, these > addresses should be treated as having global scope. > > IPv4-compatible addresses should be treated as having "preferred" > configuration status. > > what about 6to4 addresses? shouldn't they be treated as > having "preferred" configuration status too? what about other > embedded address types? 6to4 addresses will typically be acquired via usual address configuration means (like receiving a prefix in a Router Advertisement) so their configuration status will depend on their lifetime, just like other global addresses. > 2.4. Loopback Address and Other Format Prefixes > > The loopback address should be treated as having link-local > scope [9, section 4] and "preferred" configuration status. > > this has already been (partly) stated in section 2.1. I don't see how section 2.1 says anything about the loopback address. > 2.5. Policy Table > > [...] > > The precedence value Precedence(A) is used for sorting destination > addresses. If Precedence(A) > Precedence(B), we say that address A > has higher precedence than address B, meaning that our algorithm > will prefer to sort destination address A before > destination address > B. > > i would change this into: > > The precedence value Precedence(A) is used for sorting destination > addresses. If Precedence(A) > Precedence(B), we say that address A > has higher precedence than address B, meaning that our algorithm > will prefer to sort destination (or source) address A before > destination (or source) address B. I disagree. Because the Precedence value is used only when sorting addresses for use as a destination (section 5) it would be highly misleading to insert a reference to source addresses. > Page 10: > > 6. Interactions with Routing > > [...] One router is advertising a global prefix A and > the other route is advertising global prefix B. > ^^^^^ > > i think you wanted to say router here. Yes, thanks. > IMHO, draft-ietf-default-addr-select-04.txt is a very well > done work. i wonder how many implementations already support > source and destination address selection. does any of you > have some information about this? The MS implementation supports the draft. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 8 23:23:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f796MUS19032 for ipng-dist; Wed, 8 Aug 2001 23:22:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f796MPD19025 for ; Wed, 8 Aug 2001 23:22:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27823 for ; Wed, 8 Aug 2001 23:22:33 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA15052 for ; Thu, 9 Aug 2001 00:22:28 -0600 (MDT) Received: from 157.54.9.108 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 23:20:59 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Aug 2001 23:20:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt Date: Wed, 8 Aug 2001 23:20:56 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FC60@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt Thread-Index: AcEY9iGy9U7qHsImSbyKigL4eanzeQHoKaDQ From: "Richard Draves" To: "Stig Venaas" Cc: X-OriginalArrivalTime: 09 Aug 2001 06:20:57.0425 (UTC) FILETIME=[73950410:01C1209B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f796MQD19026 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've been discussing destination address selection with some > people, in particular how getaddrinfo() ideally should sort > IPv4 addresses in the case that a host is placed in an > IPv4-only network, and how this works with the algorithm in the draft. > > The first destination rule is: > > Rule 1: Avoid unusable destinations. > If there is no route to DB or the current next-hop neighbor for DB > is known to be unreachable or if Source(DB) is undefined, then sort > DA before DB. Similarly, if there is no route to DA or the current > next-hop neighbor for DA is known to be unreachable or if > Source(DA) > is undefined, then sort DB before DA. > For IPv6 destination addresses, the > > First of all, the paragraph actually ends like this in the > draft. Is something missing, or should the last words be removed? Yup, some unfinished editing there in the -05 version. Ignore the last words. > My first thought was that this rule for an IPv6 host in an > IPv4-only network with no known IPv6 routers would be enough > to have IPv4 addresses sorted before IPv6 addresses. There > was however some confusion in our discussion because some > implementations have in this case an on-link default route, > which means you actually have a route for all IPv6 addresses. > I think this route should be ignored, and maybe it should be > made clear in the draft. This on-link default route is just a > way of implementing the following part of the conceptual > sending algorithm in RFC 2460: > > Next-hop determination for a given unicast destination operates as > follows. The sender performs a longest prefix match against the > Prefix List to determine whether the packet's destination is on- or > off-link. If the destination is on-link, the next-hop > address is the > same as the packet's destination address. Otherwise, the sender > selects a router from the Default Router List (following the rules > described in Section 6.3.6). If the Default Router List is empty, > the sender assumes that the destination is on-link. > > That's how I see it anyway, I would like comments on this. Actually the first couple examples in section 9.2 were supposed to illustrate this scenario. The IPv6-capable host will presumably have some IPv6 addresses, even though it is in an IPv4-only network (meaning no IPv6 router available). For example, it will have a link-local IPv6 address on its lan interface and an IPv6 loopback address. So when a DNS name resolves to two addresses, global IPv4 and global IPv6, the "prefer matching scope" rule causes the IPv4 address to be sorted first. It seems there are two problems with the phrase "no route" in Rule 1: - RFC 2461 conceptual model doesn't have routes - The RFC 2461 "assume destination is on-link" fallback - is this a route or not? When I wrote "no route", I was really thinking "if for whatever internal error reason, the implementation can not convert the destination address to a next-hop neighbor". Perhaps it would be best to just remove the "no route" clause from Rule 1, and say that a destination D is considered unusable if Source(D) is undefined or if the next-hop neighbor for D is known to be unreachable. > Another issue that came up: > > It seems reasonable that IPv6 applications use this algorithm > while IPv4 applications that don't care about IPv6 do not. Or > does anyone think that we actually should use this algorithm > then as well; preferring RFC 1918 destination for 1918 source > etc? One way of doing this might be to use the algorithm in > getaddrinfo() if AI_V4MAPPED is set, but leave the addresses > unsorted otherwise (also for AI_ALL). Hmm. I guess I was thinking all uses of getaddrinfo() would want the sorting, even IPv4 applications. In any case, I don't like the AI_V4MAPPED suggestion - plenty of IPv6 applications will not use that flag. It could be something like - if the caller specifies that only IPv4 addresses are desired, then the sorting is not done. But if the caller specifies IPv6 addresses or leaves the family unspecified, then the sorting is done. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 9 01:33:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f798X9v19380 for ipng-dist; Thu, 9 Aug 2001 01:33:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f798WfD19358; Thu, 9 Aug 2001 01:32:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09155; Thu, 9 Aug 2001 01:32:47 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA17602; Thu, 9 Aug 2001 02:32:45 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Aug 2001 01:31:25 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 01:31:30 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 01:31:30 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 01:31:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Thu, 9 Aug 2001 01:31:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (ngtrans) Joint DNSEXT & NGTRANS summary Thread-Index: AcEfWwy/zFjVYjC5SA+Uh2Qc7kfPqwBUib7B From: "Christian Huitema" To: "Paul A Vixie" , "Alexis Yushin" Cc: "James Aldridge" , "Jim Bound" , "Matt Crawford" , , , , X-OriginalArrivalTime: 09 Aug 2001 08:31:28.0802 (UTC) FILETIME=[AF725020:01C120AD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f798WfD19359 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, Just for the record -- Microsoft as a corporation did not try to sway this issue one way or the other; individual IETF contributors who happen to work for Microsoft have various opinions in this debate. OTOH, we are shipping software, and we would really want the debate to be resolved very soon. -- Christian Huitema -----Original Message----- From: Paul A Vixie [mailto:vixie@vix.com] Sent: Tue 8/7/2001 9:00 AM To: Alexis Yushin Cc: James Aldridge; Jim Bound; Matt Crawford; ngtrans@sunroof.eng.sun.com; namedroppers@ops.ietf.org; ipng@sunroof.eng.sun.com; dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary > I see a big difference between deprecating/moving to historic and changing > status to experimental. Experemental implies further development. I don't see that difference here. Just as "let's let the market decide" really just means "let's do whatever Microsoft wants", so it is that "let's make it experimental" really just means "let's move on." (I find it amusing that SRV was experimental but that Microsoft's use of it pulled it forward.) I was not able to be in London, but had I been there my comments would've been: Let's not expect stub resolvers to do the caching necessary to understand either A6 or SIG/KEY -- those are things which servers ought to use to talk to other servers. Stub resolvers making recursive requests of their name servers should be using AAAA and TSIG. AAAA synthesis of underlying A6, and TSIG to protect verified KEY/SIG data for the last mile, is all a client needs. Every argument against SIG/KEY or against A6 comes down to either the caching problem or the complexity problem, and if we insulate the end-stations from those problems, the arguments are reduced to things which authority-side tools can be made to cope with. Hopefully this point was made by somebody. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 9 01:46:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f798jWE19539 for ipng-dist; Thu, 9 Aug 2001 01:45:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f798jSD19532 for ; Thu, 9 Aug 2001 01:45:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10102 for ; Thu, 9 Aug 2001 01:45:35 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04265 for ; Thu, 9 Aug 2001 01:45:34 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f798jW818083; Thu, 9 Aug 2001 10:45:32 +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 KAA05356; Thu, 9 Aug 2001 10:45:32 +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.11.3/8.11.3) with ESMTP id f798jVu76307; Thu, 9 Aug 2001 10:45:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108090845.f798jVu76307@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Thu, 09 Aug 2001 01:36:50 +0900. Date: Thu, 09 Aug 2001 10:45:31 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The majority is those who support A. However, I'm afraid we cannot call this "consensus" (only a few people have presented opinions anyways...) => we obviously need more opinions... I don 't know how to collect them, IPv6 WG agenda for Friday is already more than full! 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 Aug 9 02:04:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7993JF19591 for ipng-dist; Thu, 9 Aug 2001 02:03:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7993ED19584 for ; Thu, 9 Aug 2001 02:03:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03273 for ; Thu, 9 Aug 2001 02:03:21 -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 DAA05068 for ; Thu, 9 Aug 2001 03:03:16 -0600 (MDT) Received: from localhost ([2001:618:7:2:98f7:3fbd:ffbf:5ffb]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA16044; Thu, 9 Aug 2001 18:03:16 +0900 (JST) Date: Thu, 09 Aug 2001 17:58:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <963.997327683@brandenburg.cs.mu.OZ.AU> References: <5436.997292176@brandenburg.cs.mu.OZ.AU> <963.997327683@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 09 Aug 2001 10:28:03 +0700, >>>>> Robert Elz said: > | You could say that, but I believe B and C should be separate. > This is an irrelevant point (the whole question of majorities), > but it doesn't matter whether they're separate or not, a majority > is still more than 50% of the total, not just the greatest number > of any of the possibilities. Okay, please just read the text "relatively large number of people (or whatever you want). > | Hmm, I guess it would be okay to leave it as implementation dependent, > | that is, "we adopt the flat 32 model, but the actual mapping from a > | particular zone to a zone ID (sin6_scope_id) is implementation > | dependent." Does this make sense to you? > Yes, I have no problem with that. But again, I don't know enough about > the implications for my opinion on this to count for anything... I see, I won't count you as a support of A. 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 Aug 9 02:14:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f799E7619650 for ipng-dist; Thu, 9 Aug 2001 02:14:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f799E3D19643 for ; Thu, 9 Aug 2001 02:14:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12208 for ; Thu, 9 Aug 2001 02:14:00 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11913 for ; Thu, 9 Aug 2001 03:13:57 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f799BC817323; Thu, 9 Aug 2001 11:11:12 +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 LAA05743; Thu, 9 Aug 2001 11:11:11 +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.11.3/8.11.3) with ESMTP id f799BBu76403; Thu, 9 Aug 2001 11:11:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108090911.f799BBu76403@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Thu, 09 Aug 2001 00:36:16 +0700. <5436.997292176@brandenburg.cs.mu.OZ.AU> Date: Thu, 09 Aug 2001 11:11:11 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: That is, pick the scope identifier of a lower level object that is within the higher level object as the identifier for that object. => I share your concern which is the main reason I dislike option A (i.e. use 1,2,3,... is simple but misleading). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 9 02:17:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f799H7x19668 for ipng-dist; Thu, 9 Aug 2001 02:17:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f799H3D19661; Thu, 9 Aug 2001 02:17:03 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10122; Thu, 9 Aug 2001 02:17:10 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10462; Thu, 9 Aug 2001 02:17:06 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f799GCh04218; Thu, 9 Aug 2001 16:16:12 +0700 (ICT) From: Robert Elz To: "Christian Huitema" cc: "Paul A Vixie" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 16:16:12 +0700 Message-ID: <4216.997348572@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 9 Aug 2001 01:31:28 -0700 From: "Christian Huitema" Message-ID: | Just for the record -- Microsoft as a corporation did not try to sway | this issue one way or the other; That wasn't the way I read Paul's comment - I read it more as suggesting that if the IETF doesn't pick one way or the other, and completely stamp out the other (ie: if one gets marked as experimental, or if both get left as PS), then you (Microsoft) will just pick whichever one that appeals to you most, and that will effectively set the standard, regardless of what any of the rest of us think later. I suspect that's half right - what microsoft put in their clients would only matter if they start doing A6 lookups - if they just do AAAA, then AAAA synthesis can allow A6 deployment to work just fine. I'm less convinced about the power of microsoft to sway the world via the server behaviour. The one thing that is pretty clear, is that if microsoft clients start doing A6 queries to find IPv6 addresses, then it is A6 that the world will deploy (we won't be synthesising A6 records out of AAAA, while possible, that makes no sense at 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 Aug 9 02:23:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f799Na219751 for ipng-dist; Thu, 9 Aug 2001 02:23:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f799NVD19744; Thu, 9 Aug 2001 02:23:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05077; Thu, 9 Aug 2001 02:23:38 -0700 (PDT) Received: from starfruit.itojun.org (host217-33-137-35.ietf.ignite.net [217.33.137.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23140; Thu, 9 Aug 2001 03:23:43 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 3EBEA7BA; Thu, 9 Aug 2001 18:22:52 +0900 (JST) To: Robert Elz Cc: "Christian Huitema" , "Paul A Vixie" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: kre's message of Thu, 09 Aug 2001 16:16:12 +0700. <4216.997348572@brandenburg.cs.mu.OZ.AU> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Thu, 09 Aug 2001 18:22:52 +0900 Message-Id: <20010809092252.3EBEA7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I suspect that's half right - what microsoft put in their clients would >only matter if they start doing A6 lookups - if they just do AAAA, then >AAAA synthesis can allow A6 deployment to work just fine. as I repeatedly commented, AAAA synthesis does not really work in the wild due to the deployment hurdles and ambiguity as to who is going to synthesize. 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 Aug 9 02:43:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f799gt619856 for ipng-dist; Thu, 9 Aug 2001 02:42:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f799gaD19849; Thu, 9 Aug 2001 02:42:36 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18109; Thu, 9 Aug 2001 02:42:37 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24457; Thu, 9 Aug 2001 02:42:32 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f799ffh04350; Thu, 9 Aug 2001 16:41:47 +0700 (ICT) From: Robert Elz To: Jun-ichiro itojun Hagino cc: "Christian Huitema" , "Paul A Vixie" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010809092252.3EBEA7BA@starfruit.itojun.org> References: <20010809092252.3EBEA7BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Aug 2001 16:41:41 +0700 Message-ID: <4348.997350101@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 09 Aug 2001 18:22:52 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010809092252.3EBEA7BA@starfruit.itojun.org> | as I repeatedly commented, AAAA synthesis does not really work in the | wild due to the deployment hurdles and ambiguity as to who is going | to synthesize. There's no ambiguity. It gets done at your local resolver/cache. For deployment, yes, to make use of A6 lookups code is going to need to be deployed - if that means just that it is required that you deploy a back end resolver that understands A6 and AAAA synthesis, then that seems like a fairly easy upgrade path (much easier than if all the clients had to be upgraded). And yes, as you have pointed out, if the local back end resolver doesn't understand A6, and AAAA synthesis, then AAAA queries will still get transmitted to the rest of the net. In the short term, the existing AAAA records can just be returned, that's the first step of transition. But it also does no great harm if some other server does AAAA synthesis on your behalf (you'll have no good way to verify the data, but the chances are that you wouldn't be bothering even if you had). 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 Aug 9 02:55:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f799sXo19952 for ipng-dist; Thu, 9 Aug 2001 02:54:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f799sRD19945 for ; Thu, 9 Aug 2001 02:54:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07284 for ; Thu, 9 Aug 2001 02:54:35 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05676 for ; Thu, 9 Aug 2001 03:54:32 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GHS00DMPOUY3G@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Thu, 09 Aug 2001 04:54:34 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f799rNm08348; Thu, 09 Aug 2001 04:53:23 -0500 (CDT) Date: Thu, 09 Aug 2001 04:53:23 -0500 From: Matt Crawford In-reply-to: "07 Aug 2001 17:47:07 EDT." To: Aldrin Isaac Cc: ipng@sunroof.eng.sun.com Message-id: <200108090953.f799rNm08348@gungnir.fnal.gov> MIME-version: 1.0 X-Mailer: exmh version 2.0.2 2/24/98 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I imagine that your routers have no difficulty in carrying a separate route for each of your customers, so there's no need for you to get involved in assigning them address prefixes. As for tracking the possible changes in their prefixes, you (and your customers) will have to make that effort part of the cost of your service. Whether it's easy or hard is still an open question, partly hining (IMHO) on DNS choices to be made in the near future. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 9 04:52:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79Bpp620347 for ipng-dist; Thu, 9 Aug 2001 04:51:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79BplD20340 for ; Thu, 9 Aug 2001 04:51:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15183 for ; Thu, 9 Aug 2001 04:51:52 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08623 for ; Thu, 9 Aug 2001 05:51:49 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f79Bn8820552; Thu, 9 Aug 2001 13:49:09 +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 NAA07322; Thu, 9 Aug 2001 13:49:08 +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.11.3/8.11.3) with ESMTP id f79Bn7u76894; Thu, 9 Aug 2001 13:49:07 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108091149.f79Bn7u76894@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Thu, 09 Aug 2001 07:15:07 +0900. Date: Thu, 09 Aug 2001 13:49:07 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > With things defined that way, I think A would suit me just fine > (not that I'd count my opinion on this issue), without it, I think > I'd prefer B or C, just so the ambiguity is avoided. Hmm, I guess it would be okay to leave it as implementation dependent, that is, "we adopt the flat 32 model, but the actual mapping from a particular zone to a zone ID (sin6_scope_id) is implementation dependent." Does this make sense to you? => don't forget we need some functions to deal with zone IDs (inheritance + a interface index -> interface zone ID macro) and IDs <-> names tools (file name, syntax, some functions again)... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 9 05:04:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79C4Lu20420 for ipng-dist; Thu, 9 Aug 2001 05:04:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79C3oD20398; Thu, 9 Aug 2001 05:03:50 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22119; Thu, 9 Aug 2001 05:03:55 -0700 (PDT) Received: from mochila.martin.fl.us (mochila.martin.fl.us [198.136.32.118]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28606; Thu, 9 Aug 2001 05:03:51 -0700 (PDT) Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id IAA26967; Thu, 9 Aug 2001 08:03:23 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id IAA07252; Thu, 9 Aug 2001 08:03:20 -0400 (EDT) Date: Thu, 9 Aug 2001 08:03:20 -0400 (EDT) From: Greg Maxwell To: Robert Elz cc: David Terrell , , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <944.997327295@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 9 Aug 2001, Robert Elz wrote: [snip] > Keith was asking for it to be fixed below the level of the applications, > presumably because updating lots of applications (different kinds, and > just different implementations) is going to be a very long process, > whereas if things could be fixed below that everything would see instant > benefits. That's also why SCTP isn't the immediate answer, as aside > from actually getting that implemented and deployed itself, the applications > would still need to be converted to use it. [snip] Why would this be unacceptable? Having connections survive renumbering is an enhanced feature, and yet another reason applications should move to an improved transport. For the general case of site renumbering, such a change could typically occur in off-hours (where they exist), and go service by service so I don't think it's critical that every application should be able to survive it seemlessly. Mobile IP is a more intresting situation, It would be useful if a mobile host could carry two prefixes, it's tunneled prefix, and a local prefix and could utilize transport layer renumbering support to seemlessly move between networks without the constant overhead of tunneling or dropping connections. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 9 05:12:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79CBuW20478 for ipng-dist; Thu, 9 Aug 2001 05:11:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79CBqD20471; Thu, 9 Aug 2001 05:11:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24821; Thu, 9 Aug 2001 05:11:57 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21513; Thu, 9 Aug 2001 06:11:54 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f79CAY813627; Thu, 9 Aug 2001 14:10:35 +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 OAA07626; Thu, 9 Aug 2001 14:10:34 +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.11.3/8.11.3) with ESMTP id f79CAWu76993; Thu, 9 Aug 2001 14:10:32 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108091210.f79CAWu76993@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Keith Moore cc: "Hallam-Baker, Phillip" , "'Randy Bush'" , alh-ietf@tndh.net, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-reply-to: Your message of Wed, 08 Aug 2001 21:05:30 EDT. <200108090105.VAA18362@astro.cs.utk.edu> Date: Thu, 09 Aug 2001 14:10:32 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: But you make a good point about security. If people get the idea (correctly or not) that they're sacrificing security by supporting v6, they won't bother deploying it. We need to have v6 border routers that deliver the same degree of security as NATs do, without actually translating addresses. => this is easy for TCP (or any connected transport, cf the tcp established of Cisco routers) but I can't see a way to do this for UDP without keeping state... Of course this argument doesn't apply if a real firewall is used (stateless firewalls are out of the market or should be ASAP). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 9 06:25:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79DP0s20619 for ipng-dist; Thu, 9 Aug 2001 06:25:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79DOuD20612 for ; Thu, 9 Aug 2001 06:24:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01065 for ; Thu, 9 Aug 2001 06:25:02 -0700 (PDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA29412 for ; Thu, 9 Aug 2001 06:25:02 -0700 (PDT) Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Aug 2001 06:24:59 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 06:24:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 06:24:56 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 9 Aug 2001 06:24:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Subject: RE: Wrap up and last call: sin6_scope_id semantics Date: Thu, 9 Aug 2001 06:24:54 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B58134@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wrap up and last call: sin6_scope_id semantics thread-index: AcEgWOP1XxOlcLyFRQi6A4Je5g1/ogAfPBFW From: "Dave Thaler" To: =?utf-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= Cc: X-OriginalArrivalTime: 09 Aug 2001 13:24:55.0359 (UTC) FILETIME=[ADC5B4F0:01C120D6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f79DOuD20613 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I disagree as well that there's a "majority" (or any sort of consensus) for A, and it would in fact be my last choice of the four possibilities (counting implementation dependent). I would prefer (in order): C (flexible) implementation dependent (what you suggest below) B (strict) A (flat) -Dave -----Original Message----- From: JINMEI Tatuya / 神明達哉 [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Wed 08/08/2001 15:15 To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics >>>>> On Thu, 09 Aug 2001 00:36:16 +0700, >>>>> Robert Elz said: > | The majority is those who support A. > Actually, it wasn't, you had 4 supporting A, and 4 not supporting A. > A might have more support than either of the others, but not majority > support... You could say that, but I believe B and C should be separate. Actually, - Francis (who supports B) said he said he'd rather prefer A to C, because C would introduce too much complexity. - Markku (or Dave? anyway who supports C) said he'd rather prefer A to B, because we'd not see much benefit to separate the field (i.e. 4+28) if we get rid of the flexibility that C provided. > I'm not sure I know or care enough about this to offer an opinion, but > I would like to ask a question .... > | A) Using the "flat 32", the zone indices are as follows: > | > | ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5 > | ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4 > | ID(site1) = 1, ID(site2) = 2 > Would another variation of that approach result in ID(site2) == 5 > and ID(link4) == 5 ? Yes, it would. > That is to avoid the problem where "1" means one place in one context > and somewhere totally different in another. Instead "2" in link context > would mean a particular link, in site context it would mean a collection > of links, but the link "2" would certainly be one of them. > With things defined that way, I think A would suit me just fine > (not that I'd count my opinion on this issue), without it, I think > I'd prefer B or C, just so the ambiguity is avoided. Hmm, I guess it would be okay to leave it as implementation dependent, that is, "we adopt the flat 32 model, but the actual mapping from a particular zone to a zone ID (sin6_scope_id) is implementation dependent." Does this make sense to you? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 9 11:17:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79IGPG21480 for ipng-dist; Thu, 9 Aug 2001 11:16:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79IFsD21458; Thu, 9 Aug 2001 11:15:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19814; Thu, 9 Aug 2001 11:15:46 -0700 (PDT) Received: from blackrock.internal.simegen.com (co3019724-a.thoms1.vic.optushome.com.au [203.164.36.115]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22880; Thu, 9 Aug 2001 12:15:49 -0600 (MDT) Received: from anaconda.internal.simegen.com ([10.0.2.1] helo=zeor.simegen.com) by blackrock.internal.simegen.com with esmtp (Exim 3.31 #1 (Debian)) id 15UuBJ-0001b7-00; Fri, 10 Aug 2001 04:05:17 +1000 Message-ID: <3B72D0DD.4000806@zeor.simegen.com> Date: Fri, 10 Aug 2001 04:05:17 +1000 From: Dancer Vesperman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.1+; Debian/GNU) Gecko/20010701 X-Accept-Language: en-us MIME-Version: 1.0 To: Christian Huitema CC: Paul A Vixie , Alexis Yushin , James Aldridge , Jim Bound , Matt Crawford , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema wrote: > Paul, > > Just for the record -- Microsoft as a corporation did not try to sway this issue one way or the other; individual IETF contributors who happen to work for Microsoft have various opinions in this debate. OTOH, we are shipping software, and we would really want the debate to be resolved very soon. > > -- Christian Huitema > > -----Original Message----- > From: Paul A Vixie [mailto:vixie@vix.com] > > > > I see a big difference between deprecating/moving to historic and changing > > status to experimental. Experemental implies further development. > > I don't see that difference here. Just as "let's let the market decide" > really just means "let's do whatever Microsoft wants", so it is that "let's I think what Paul meant was an invocation of the Golden Rule of Arts and Sciences ("He who has the gold, makes the rules" for those not versed in the classics). There's probably no need to wave loaded disclaimers around where they might go off, and injure a bystander :) Microsoft's name (rightly or wrongly) is commonly substituted by those in the halls of Information Technology for any amoral, monopolising concern or manufacturer of low-quality merchandise. It is not at all unusual (in my personal experience) to hear a shoddy telecommunications provider, or a Harmful Products Manufacturer(tm) referred to as 'A Microsoft' or 'A Microsoft Subsidiary'. Oh, well. I guess any publicity is good publicity...Or at least that's what I've heard Marketing say. :) D -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 9 13:43:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79Kh9721855 for ipng-dist; Thu, 9 Aug 2001 13:43:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79Kh5D21848 for ; Thu, 9 Aug 2001 13:43:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28377 for ; Thu, 9 Aug 2001 13:43:11 -0700 (PDT) Received: from mh1dmz1.bloomberg.com (mh1dmz1.bloomberg.com [199.172.169.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15271 for ; Thu, 9 Aug 2001 13:43:11 -0700 (PDT) Received: from ns2.bloomberg.com by mh1dmz1.bloomberg.com with ESMTP; Thu, 9 Aug 2001 16:17:29 -0400 Received: from ny11012205a (aisaac [160.43.145.196]) by ns2.bloomberg.com (8.9.3/8.9.3) with SMTP id QAA12918; Thu, 9 Aug 2001 16:17:28 -0400 (EDT) From: "Aldrin Isaac" To: "Matt Crawford" Cc: Subject: RE: renumbering Date: Thu, 9 Aug 2001 16:10:35 -0400 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200108090953.f799rNm08348@gungnir.fnal.gov> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, | I imagine that your routers have no difficulty in carrying a separate route | for each of your customers, so there's no need for you to get involved in | assigning them address prefixes. As for tracking the possible changes in | their prefixes, you (and your customers) will have to make that effort part of | the cost of your service. Whether it's easy or hard is still an open | question, partly hining (IMHO) on DNS choices to be made in the near future. In the near future will routers, which currently carry almost all of the route policying and most of the traffic filtering in large distributed networks, use v6 "DNSSEC" to get the IPv6 address information they need to apply against arriving packets (rather than manually coding IPv6 addresses into the routers configuration)? If so, would there be any examples of vendors that are participating in this effort? One cannot look to vaporware to build a network. It seems that the new Internet is more DNS and less everything else (except if you are an ISP). Maybe it would be better to use DNS name to route packets instead of fixed-length 64-bit addresses (just kidding of course). AI P.S. I wonder if there is an illustration of the IPng "vision". A picture is better than a thousand words. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 9 13:57:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79KuCn21918 for ipng-dist; Thu, 9 Aug 2001 13:56:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79Ku7D21911 for ; Thu, 9 Aug 2001 13:56:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01562 for ; Thu, 9 Aug 2001 13:56:08 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA22048 for ; Thu, 9 Aug 2001 14:56:14 -0600 (MDT) Received: (qmail 21248 invoked by uid 1001); 9 Aug 2001 19:50:55 -0000 Date: 9 Aug 2001 19:50:55 -0000 Message-ID: <20010809195055.20375.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <4216.997348572@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > if microsoft clients start doing A6 queries to find IPv6 addresses, > then it is A6 that the world will deploy Do you mean that they'll look for A6 and _not_ AAAA? If so, they'll cut themselves off from practically the entire IPv6 network: administrators provide addresses as AAAA, not A6. Or do you mean that they'll look for A6 _and_ AAAA? If so, how does that motivate administrators to switch to A6? Administrators who switch will cut themselves off from all the other clients that look only for AAAA. Or are you talking about an imaginary world in which AAAA and A6 are both starting from scratch? ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 9 14:07:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79L74F21983 for ipng-dist; Thu, 9 Aug 2001 14:07:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79L6xD21976 for ; Thu, 9 Aug 2001 14:06:59 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12652 for ; Thu, 9 Aug 2001 14:07:05 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA07877 for ; Thu, 9 Aug 2001 14:07:03 -0700 (PDT) Received: (qmail 26230 invoked by uid 1001); 9 Aug 2001 20:05:02 -0000 Date: 9 Aug 2001 20:05:02 -0000 Message-ID: <20010809200502.2501.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <5.0.2.1.2.20010807172339.0301adb0@localhost> <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> <5.0.2.1.2.20010808093637.02ff22f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David R. Conrad writes: > But it wouldn't be since addresses are embedded in (manually edited) > configuration files, filter lists, etc. What relevance does this have to the topic at hand? If you want to change the software to look up addresses in DNS, go ahead. A6 doesn't make this any easier. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 9 14:46:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f79LkE322084 for ipng-dist; Thu, 9 Aug 2001 14:46:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79LkAD22077; Thu, 9 Aug 2001 14:46:10 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21154; Thu, 9 Aug 2001 14:46:16 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18575; Thu, 9 Aug 2001 14:46:16 -0700 (PDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 484F53190D; Thu, 9 Aug 2001 14:46:16 -0700 (PDT) Message-Id: <5.0.2.1.2.20010809141410.0303ce78@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 09 Aug 2001 14:46:15 -0700 To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: "David R. Conrad" Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010809200502.2501.qmail@cr.yp.to> References: <5.0.2.1.2.20010807172339.0301adb0@localhost> <200108080830.RAA02821@necom830.hpcl.titech.ac.jp> <5.0.2.1.2.20010808093637.02ff22f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, I know it is hard when you're so busy lying about "The BIND Company", but do try to keep up. I was responding to a message that said A6 makes renumbering trivial. I was suggesting that the real renumbering problem can't be solved just in the DNS. It would, at best, solve only a portion of the problem. However, please continue to remove context and misrepresent -- you do it so well. Rgds, -drc At 08:05 PM 8/9/2001 +0000, D. J. Bernstein wrote: >David R. Conrad writes: > > But it wouldn't be since addresses are embedded in (manually edited) > > configuration files, filter lists, etc. > >What relevance does this have to the topic at hand? > >If you want to change the software to look up addresses in DNS, go >ahead. A6 doesn't make this any easier. > >---Dan >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Aug 9 23:24:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A6OJ722648 for ipng-dist; Thu, 9 Aug 2001 23:24:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A6OFD22641; Thu, 9 Aug 2001 23:24:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18189; Thu, 9 Aug 2001 23:24:22 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14336; Thu, 9 Aug 2001 23:24:19 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7A6NUY01959; Fri, 10 Aug 2001 13:23:31 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010809195055.20375.qmail@cr.yp.to> References: <20010809195055.20375.qmail@cr.yp.to> <4216.997348572@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 Aug 2001 13:23:30 +0700 Message-ID: <1957.997424610@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 9 Aug 2001 19:50:55 -0000 From: "D. J. Bernstein" Message-ID: <20010809195055.20375.qmail@cr.yp.to> This is a pointless exercise, but anyway... | Do you mean that they'll look for A6 and _not_ AAAA? I meant if they did that - I'm not expecting it to be very likely. | If so, they'll cut themselves off from practically the entire IPv6 | network: administrators provide addresses as AAAA, not A6. Some now do both.. but they wouldn't, the point of the original comment was that whatever the dominant market share does, everyone else is forced to follow. If 90% of the clients happened to be doing A6 lookups, then administrators would be providing A6 records. 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 Aug 9 23:30:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A6TaE22704 for ipng-dist; Thu, 9 Aug 2001 23:29:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A6TVD22697; Thu, 9 Aug 2001 23:29:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12351; Thu, 9 Aug 2001 23:29:39 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA16292; Thu, 9 Aug 2001 23:29:38 -0700 (PDT) From: Masataka Ohta Message-Id: <200108100621.PAA14172@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA14172; Fri, 10 Aug 2001 15:20:59 +0859 Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.0.2.1.2.20010808093637.02ff22f8@localhost> from "David R. Conrad" at "Aug 8, 2001 11:10:50 am" To: "David R. Conrad" Date: Fri, 10 Aug 2001 15:20:58 +0859 () CC: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk drc; > >So, you are saying that the large organiation is currently accepting > >to manually change IP addresses of DNS servers on renumbering, aren't > >you? > > Yes. > > >If so, A6 is perfectly fine for it for easy and quick renumbering. > > I don't think so. A6 is only a small part of the full problem. The beggest part of the full problem is updating DNS glue. > >The only thing to do is to have an RFC for the organization to tell > >renumbering with A6 is as easy as with NAT. > > But it wouldn't be since addresses are embedded in (manually edited) > configuration files, filter lists, etc. It is really painful to do so with 128 bit addresses. With A6, DNS provides not only addresses but also bitmasks that writing cofiguration becomes easy. > Sorta reminds me of the IDN situation. Instead of focusing on the real > problem (getting higher layers to do the right thing), the focus is on > fixing the DNS... The right thing to do for IDN and NAT, is not to use them. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 9 23:47:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A6lCK22756 for ipng-dist; Thu, 9 Aug 2001 23:47:12 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A6l7D22749 for ; Thu, 9 Aug 2001 23:47:07 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7A6l8219037; Fri, 10 Aug 2001 08:47:09 +0200 (MET DST) Date: Fri, 10 Aug 2001 01:37:55 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Prefix delete RA behaviour To: Basavaraj Unnibhavi Cc: Ipng , Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hello, > If prefixes in the router are deleted by admin, what should be the behaviour > of RA (Router advertisement). I think Neighbor discovery spec doesn't > specify about this. It depends on what the semantics are of the administrative "delete" operation. There are 2.5 possible interpretations: - Immediately remove the prefix. To do this robustly for nodes that are not connected to the link the hole time the router(s) need to advertise the prefix with zero lifetimes until the end of the original lifetime has expired. - Remove the prefix by stopping to extending the lifetime. This can be done by either - stop advertising the prefix. This causes existing nodes to decrement the lifetime in real time. - advertiseing the prefix with a lifetime decrementing in real time. This is the same as the "stop" except that newly arriving nodes will configure the addresses with a short lifetime. So you are correct that RFC 2461 doesn't specify the semantics of such *management operations* and how they map to the routers configuration information. But the spec does specify how this configuration information is advertised in the protocol and how the information received in the protocol affects the configuration on the hosts. Erik > Thanks in advance for clarification. > > Basavaraj > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 02:03:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A93GN23099 for ipng-dist; Fri, 10 Aug 2001 02:03:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A93AD23089 for ; Fri, 10 Aug 2001 02:03:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05558 for ; Fri, 10 Aug 2001 02:03:17 -0700 (PDT) Received: from starfruit.itojun.org (host217-33-137-35.ietf.ignite.net [217.33.137.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29005 for ; Fri, 10 Aug 2001 03:03:23 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 188357BA; Fri, 10 Aug 2001 18:00:21 +0900 (JST) To: kitamura@da.jp.nec.com Cc: ipng@sunroof.eng.sun.com Subject: draft-kitamura-ipv6-name-auto-reg-00.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: Fri, 10 Aug 2001 18:00:21 +0900 Message-Id: <20010810090021.188357BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk - to query the hostname (or maybe FQDN domain name), from registrar, you may be able to use ICMPv6 node information query. - at detector, you can't differentiate between temporary address and non-temporary address. there's no indication available on the 128bit address bits. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 02:10:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A99es23167 for ipng-dist; Fri, 10 Aug 2001 02:09:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A99aD23160 for ; Fri, 10 Aug 2001 02:09:36 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08587 for ; Fri, 10 Aug 2001 02:09:43 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20329 for ; Fri, 10 Aug 2001 02:09:41 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7A99Yf04087; Fri, 10 Aug 2001 12:09:34 +0300 Date: Fri, 10 Aug 2001 12:09:34 +0300 (EEST) From: Pekka Savola To: cc: Subject: Re: draft-kitamura-ipv6-name-auto-reg-00.txt In-Reply-To: <20010810090021.188357BA@starfruit.itojun.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, 10 Aug 2001, Jun-ichiro itojun Hagino wrote: Also see my worries wrt. severe DoS attacks with DAD's and the like on the list on 16 Jul (haven't been commented on). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 02:30:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A9UIO23277 for ipng-dist; Fri, 10 Aug 2001 02:30:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A9UED23270 for ; Fri, 10 Aug 2001 02:30:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07593 for ; Fri, 10 Aug 2001 02:30:21 -0700 (PDT) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11953 for ; Fri, 10 Aug 2001 03:30:27 -0600 (MDT) Received: from duplo.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.5/8.11.3) with ESMTP id f7A9UFq17408; Fri, 10 Aug 2001 18:30:16 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.5/8.10.2) id f7A9TrE00914; Fri, 10 Aug 2001 10:29:53 +0100 (BST) Date: Fri, 10 Aug 2001 10:29:53 +0100 (BST) From: Atsushi Onoe Message-Id: <200108100929.f7A9TrE00914@duplo.sm.sony.co.jp> To: itojun@iijlab.net Cc: kitamura@da.jp.nec.com, ipng@sunroof.eng.sun.com Subject: Re: draft-kitamura-ipv6-name-auto-reg-00.txt In-Reply-To: Your message of "Fri, 10 Aug 2001 18:00:21 +0900" <20010810090021.188357BA@starfruit.itojun.org> References: <20010810090021.188357BA@starfruit.itojun.org> X-Mailer: Cue version 0.6 (010809-1110/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - to query the hostname (or maybe FQDN domain name), from registrar, > you may be able to use ICMPv6 node information query. > - at detector, you can't differentiate between temporary address and > non-temporary address. there's no indication available on the 128bit > address bits. ICMPv6 node information query should not open node information if the query is destined to a temporary address, IMO. And the registration should be done only when detector or registrar successfully get an answer for the node information query. Thus the registration of a temporary address can be avoided. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 02:35:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A9YhK23356 for ipng-dist; Fri, 10 Aug 2001 02:34:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A9YcD23345 for ; Fri, 10 Aug 2001 02:34:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02858 for ; Fri, 10 Aug 2001 02:34:45 -0700 (PDT) Received: from starfruit.itojun.org (host217-33-137-35.ietf.ignite.net [217.33.137.35]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13857 for ; Fri, 10 Aug 2001 03:34:52 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D9EB77BA; Fri, 10 Aug 2001 18:31:40 +0900 (JST) To: ipng@sunroof.eng.sun.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: draft-conta-ipv6-flow-label-02.txt From: Jun-ichiro itojun Hagino Date: Fri, 10 Aug 2001 18:31:40 +0900 Message-Id: <20010810093140.D9EB77BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk with many of the diffserv-oriented encoding, there are possibilities for routers to get tricked by originating nodes, leading to theft of traffic and/or simple kernel panic (if we put header length into flow label field, and if your router is careless - if you are careful you are not speeding things up and there's no meaning in embedding header length into flow label field). I'm not very happy with the proposal. I vote for end-to-end pseudorandom value as specified in RFC1883 (2460 weakened end-to-end part of the text, IIRC). it helps you to hash traffic at routers, that's all. you cannot trust the value in the field anyways, therefore pseudorandom is the only thing you can handle. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 02:37:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7A9b1b23412 for ipng-dist; Fri, 10 Aug 2001 02:37:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A9avD23405 for ; Fri, 10 Aug 2001 02:36:57 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08186 for ; Fri, 10 Aug 2001 02:37:04 -0700 (PDT) Received: from starfruit.itojun.org (host217-33-137-35.ietf.ignite.net [217.33.137.35]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29103 for ; Fri, 10 Aug 2001 02:36:59 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 519417BA for ; Fri, 10 Aug 2001 18:33:54 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Fri, 10 Aug 2001 18:31:40 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-conta-ipv6-flow-label-02.txt From: Jun-ichiro itojun Hagino Date: Fri, 10 Aug 2001 18:33:54 +0900 Message-Id: <20010810093354.519417BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > with many of the diffserv-oriented encoding, there are possibilities > for routers to get tricked by originating nodes, leading to theft of > traffic and/or simple kernel panic (if we put header length into flow > label field, and if your router is careless - if you are careful you > are not speeding things up and there's no meaning in embedding > header length into flow label field). also, if you are going to rewrite the field for the sake of diffserv, why don't you use traffic class field (6bit)? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 03:04:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AA3Xc23555 for ipng-dist; Fri, 10 Aug 2001 03:03:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AA38D23533; Fri, 10 Aug 2001 03:03:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28748; Fri, 10 Aug 2001 03:03:13 -0700 (PDT) Received: from ogud.com (208-59-114-172.c3-0.129-ubr1.lnh-129.md.cable.rcn.com [208.59.114.172]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09768; Fri, 10 Aug 2001 04:03:10 -0600 (MDT) Received: from localhost (ogud@localhost) by ogud.com (8.11.3/8.11.2) with ESMTP id f7AA1JT30200; Fri, 10 Aug 2001 06:01:20 -0400 (EDT) (envelope-from ogud@ogud.com) Date: Fri, 10 Aug 2001 06:01:19 -0400 (EDT) From: Olafur Gudmundsson X-Sender: ogud@hlid.dc.ogud.com To: DNSEXT mailing list , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com cc: dnsop@cafax.se Subject: Final DNSEXT NGTRANS Joint meeting minutes 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 Final Minutes of the DNS-EXT/NGTRANS joint meeting on How to represent IPv6 addresses in DNS IETF-51, London - 6 August 2001 Olafur Gudmundsson, Alain Durand & Tony Hain chairing Minutes by: Bob Fink, David Lawrence, Jun-ichiro itojun Hagino (thanks for great minutes) Edited by Bob Fink and Olafur Gudmundsson ----- Agenda Introduction (2 min) - Olafur Bit labels (5 min) - Alain DNAME use in reverse IPv6 tree (5 min) - Alain AAAA vs A6 (60 min) - Alain Consensus building (40 min) - Tony Summary (8 min) -Olafur ----- Short names: Full names Alain Alain Durand Bob Bob Hinden Christian Christian Huitema Erik Erik Nordmark Itojun Jun-ichiro itojun Hagino Matt Matt Crawford Olafur Olafur Gudmundsson Perry Perry Metzger Randy Randy Bush Rob Rob Austein Steve Steve Deering Thomas Thomas Narten Tony Tony Hain Introduction Olafur explained that the meeting goal is to find rough consensus on how to go forward with representation of IPv6 addresses in DNS. The meeting output will be an ID summarizing the meeting consensus, which will be taken to the appropriate mailing list(s). ---- Bit labels - Alain Are bit labels necessary in IPv6 DNS reverse tree, and is anybody planning to delegate on the last 4 bits? Matt Crawford stated that Bit Labels are not necessary if you are willing to do the delegation hack on non-nibble boundaries. Rob Austein explained that the last 4 bits meant a /125 or larger. There was no response from the floor to the questions posed by Alain. Andrea Gustafsson asked for someone to clarify why last 4 bits are special. Randy Bush explained that the issue is allocations in the last label when using a text-based name format in the reverse tree. In IN-ADDR.ARPA that means allocations in the last octet; in the text based version of IP6.ARPA (nibbles, not bitlabels), that means allocations in the last nibble. Being there was no discussion, Alain moved on. -- DNAME use in reverse IPv6 tree - Do we need DNAME in the IPv6 reverse tree? Alain noted that other DNAME uses were out of scope for the discussion. Christian noted that if you really want renumbering on fly, DNAME is needed, thus it follows the decision on need for A6. Matt Crawford noted that there is value in forward tree, even if not in reverse tree. Michael Patton said that we if we do A6, require DNAME in reverse tree, but if AAAA only, there is some value. Matt said that DNAME can be used to keep reverse map in the same zone as direct map. Alain asked if this was still true if there were only AAAA and no A6. Matt said yes. Olafur summarized that, given the limited defense of DNAME it was a DNS decision on whether other uses of DNAME justified it. --- AAAA vs A6 - Does anybody have any other application that requires A6, that can not be done by back-end processing and are not covered by draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt? Christian noted a point only partially covered by Rob's ID. Assumption is a db with all systems listed. There are schemes where hosts push addresses to db and when renumbering, there are individual decision that 1000's of hosts could to update the DNS with. Perry Metzger stated that if one does the db right, then tools can do it cleanly, no special protocol hacks are needed. We only think not due to lack of tools. It's only a SMOP :-), like MOIRA (sp) at MIT. Matt Crawford noted that this still relies on tools not yet written. A6 buys ability to register as single RR in db for all prefixes as it goes. Perry understands desire, but believes tools are needed, and for more than A6. Jim Bound asked if, assuming backend processing (with better tools than we now have), to evaluate if A6 make it more efficient, and thus worth implementing in this context. Olafur said, yes, a natural representation in db looking something like A6, would help. Jim Bound responded if we then agree, lets focus in the direction A6 points. Bill Sommerfield - I worked on MOIRA (sp) at MIT (that Perry mentioned as example) and I don't think that is for all sites. Wrong to force on all sites where model might not fit. Matt Crawford noted that missing from questions is, we focus on "today", not if it is needed in future. E.g., coupling of DNS prefix delegation to routing system's idea of prefix delegation. - Is IPv6 going to do rapid renumbering or GSE-like routing? Bob Hinden asked if hourly or daily likely? Weekly/monthly most likely, i.e., not all that rapid. Rapid renumbering was not an original (or even current) goal for IPv6. Tony GSE is a "per packet" renumbering Matt Crawford noted that there was lots of discussion for minimal allocation size (i.e., the /48 issue). There are other ways for a body/system to move that might require rapid renumbering. One can't say for sure rapid renumbering won't be needed, and thus A6. Margaret Wasserman asked if we ware talking automated renumbering or not. Rob stated that if IPv6 going to do automated renumbering frequently, that quad A can't cope with it, even with better tools, due to issues like resigning time Christian noted there are scenarios with several prefixes: e.g., one might toggle between them on a daily basis or faster. Christian felt that for fire exit usage, if renumbering not used often (to check that it works) it would never be used. Steve Deering felt that many sites will have to renumber enough to know protocol (and implementations) work. Christian noted that the argument on renumbering seems to be gated on resigning. He is not convinced that we can't do security right. Steve stated that on issues other than security, an important goal with IPv6 is to make renumbering easier, but to make it occur very fast is unsolved, for more than just DNS records. Thus if we do rapid renumbering, it will be a very different architecture, e.g., GSE, and it is likely that it would keep site ignorant of changes and thus A6 wouldn't help. Ted Hardy asked if there are there applications for rapid renumbering, that happen faster than route propagation, that fall under multi-homing. Renumbering that happens faster than route propagation won't work. Alexis Yushin asked if we know what the future is. IPv6 will be used in new applications beyond our current Internet, and who knows what these uses are. Choice is either put A6 flexibility there for the future, or stop developing A6 now and invent something new in future. Jim Bound agreed w/Steve that one can't guarantee rapid renumbering. A6 is a tool that underwent significant development and that it is an abstraction like scoping, multi-casting, that adds quality to the IPv6 architecture. Users will need renumbering to adopt IPv6. Perry asked at what costs. DNS queries are under fire for getting slower. Confident that he could renumber in hours or days, but probably not faster. It does work with AAAA, though he admitted his experience was for a small site. Randy noted that the problem with doing A6 for possibility of rapid renumbering is following dreams, not reality. To get v6 traction, A6 not helping. Jim Bound agreed with Randy, but would like to see if A6 0 would work and do testbeds to see what works. Concerned that the code base (we now have) might be useful might be thrown away before we learn from it. Simon Leinen noted that the performance issues are not straight forward. A6 request might be handled faster than AAAA, when host has many addresses. Matt Crawford asked do you think we can deploy A6 later on and really get it deployed? Randy noted that playing with A6, IPv6 folk are maintaining their code better than v4 folk may be. If we do renumbering it is analogous to, "do we do the routing thing". A6 is a solution to a problem we haven't yet defined, and constrains our solutions in future. Rather solve our problems and solve DNS stuff after. Matt Crawford asked again if we can make a change in the future like that? Thomas Narten asked, if we do rapid renumbering, are other changes needed? Then couldn't putting in changes for DNS be done too? Steve Deering noted that we have AAAA, and going to A6 0 is a "no brainer", but if it is lots of work to change to A6 for a limited value, is it worth it? Someone (name please ??) asked if we do A6 0, isn't it really just as hard to do a full-blown A6 later? Theo Pagtzis asked how would A6 handle really rapid renumbering? Steve Deering noted again, Mobile IP could do it, thus A6 not needed useful for rapid renumbering. Olafur felt that translation of A6 0 is easy, synthesis easy. The only question is then one of delay. Some company has done this already. Steve Deering asked, at what transition cost? Simon Linen (??) stated that AAAA and A6 are easy, and both can be deployed at the same time in the same zone, simple to have tools maintain one record type from the other. Itojun stated that maintaining A6 and AAAA is not easy. Rob Austein asked if mechanisms ease pain, as it is several years to do transition. This was discussed in Minneapolis. Another variation is to modify servers to generate A6 0 when quad AAAA is found. Though, when translating either way, signature is lost. However, it is important to not use A6 in complex ways. It is an attractive nuisance in that it does encourage people to try to exploit A6 beyond reasonable usage. Matt Crawford felt that transition best be kept short. Itojun is concerned that Rob says years to do transition tools and that his users can't wait. Alain stated that the plan from Minneapolis roughly described the transition. Rob said that Itojun correct; we can't take a long time for a transition. It is important to decide on A6 very soon. Mohsen Suissi from FRNIC noted that many users have been waiting for years to move to IPv6 production. AAAA works fine. If we say we have to move to A6 0 and wait for bind 9, and/or new O/S, we are waiting for more years. customers keep waiting. Itojun asked how many BIND 4 servers are still around versus BIND 9? Perry - how many folks using v6 all the time. A number of hands. Of these how many could run A6 soon, not so many of the hands. Folks around us using AAAA, can we go backwards and wait? Randy asked that for installed AAAA base would you use A6, and the he would, if it was a significant value, which it isn't. Jim Bound would change resolvers not O/S thus AAAA use would continue and this is only an operational issue. Margaret Wasserman asked why this is an issue of one against other. We have AAAA, so question is do we continue to work on A6, say as experimental. Plan for success, for renumbering, why not keep both? Steve Deering agree w/Margaret and Jim. Lack of decision here doesn't keep people from moving to IPv6. It should not be viewed as blocking IPv6. Alain said that the root operators are trying to get IPv6 accessible root servers, and that they are concerned about what to implement. --- Returning to GSE-like routing usage for A6 Randy stated that if a critical architectural change needed for A6, he would support it. However, we don't know what it will be yet. Thomas said that when Rob talked about transition time being a couple years this means at least 2, but he believes it would take 5 years given what is shipping and what current plans are. Tony Hain also noted that since decision is taking a while, we are talking about 6 months. before real development could even start. Maybe it's a 7 year transition. ==== consensus building (one minute break while chairs huddle) Tony Hain summarized what we are hearing from this meeting's discussions: --- Bitstring not necessary, so will take to list to confirm. --- DNAME - only one case where its necessary is if we choose A6. Matt believes you don't need but will really wish for it. Rob said without A6, DNAME use is a more general DNS question, i.e., equally relevant to v4. So again Tony noted that we will take to list to confirm. --- A6/AAAA - tools needed, and could make host push update vs relational db work. So again Tony noted that we will take to list to confirm. --- Renumbering - no consensus on time frames and out of scope here. If rapid implies less than hourly and requires significant architectural change than DNSSEC fails in verifying signature changes. Randy agreed but asked that GSE/8+8 also is in category of rapid renumbering (i.e., can't tell now if it will happen or when, and what it will look like). Also, noted that it is an operationally attractive nuisance. --- Next the chairs attempted to get the sense of the room to the reading material and discussions. Consensus is to be judged on the mailing list. - Straw polling the 4 address options for rough consensus: The first 3 questions where asked then there was restart after clarification on what experimental status was. - full A6 development with AAAA synthesis - low hum, then a slightly louder hum when asked again - A6 0 w/ AAAA synthesis - medium hum, then a slightly louder hum when asked again - AAAA deployed, A6 to experimental - larger hum, then a slightly louder hum when asked again Randy elaborated that the value of going to Experimental means anyone using A6 has a consistently specified A6 spec to use. Thomas added, we want to signal developers about our A6 shipping intentions, and how defaults are set. Bill Manning believes AAAA should be left in standards track, and A6 to experimental. - AAAA deployed, A6 to historic - medium hum The chairs judged the sense of the room that the hums indicated deploying AAAA and moving A6 to Experimental. Again, this will be taken to list to confirm. - Bit labels - - make historic - medium hum - make experimental - loud hum - keep - no hum taken due to lack of comment earlier Therefore, DNAME for bit label use is limited to experimental use of bitlabels in the reverse tree. When someone asked if the ip6.int vs ip6.arpa choice was going to be discussed, it was noted that it was out of scope for this group as it was an IAB decision. There was a brief discussion of what list the discussion should go to. Randy and Erik (our area directors in attendance) agreed it should fall under DNSEXT. and the results published to all the other lists. --- Meeting adjourned (ahead of schedule) Summary of the sense of the meeting, to be verified on mailing lists: - AAAA stays on standards track in DNSEXT, - A6 moved to experimental by DNSEXT - Bitlabels moved to experimental by DNSEXT - DNAME standardization is out scope. -end -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 03:12:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AACff23646 for ipng-dist; Fri, 10 Aug 2001 03:12:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AACaD23639 for ; Fri, 10 Aug 2001 03:12:36 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-14.EBay.Sun.COM [129.150.4.14]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AACdB848556 for ; Fri, 10 Aug 2001 03:12:39 -0700 (PDT) Message-Id: <5.1.0.14.0.20010810030132.01c69f30@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 Aug 2001 03:19:15 -0700 To: ipng@sunroof.eng.sun.com From: Alain Durand Subject: Source address selection draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I missed this part of the IPng discussion on source address selection/ destination address ordering. There were two points I would have like to make: 1- Some of this text is clearly in the scope of standard track. e.g. deprecated vs non deprecated Some other parts are more questionable, are would better fit in a Best Current Practise (BCP) document. e.g privacy extension, 6to4, other non-native addresses.... We have recently discovered some issues with ISATAP that ended up in modified text in the draft. I'm sure such other similar problems will be discovered in the future. It will be much easier to reissue the BCP part than to modify the complete RFC if it ever reach DS status. So I would have like to re-iterate my suggestion to split the document in two: framework, obvious rules... goes standard track other rules, values in various tables goes BCP 2. The current draft does longest prefix match on 128 bits. In the case of a dual-rail network where each hosts has 2 interfaces prefix P1/64 ------------------------------------------------------ | h1 | h2 |h3 ------------------------------------------------------ prefix P2/64 In this case, the choice of network 1 or network 2 depend on the actual MAC address of the hosts. This is a situation that is very difficult to understand/debug by network administrator. I would like to suggest to do longest prefix match only on the 64 most significant bits. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 03:21:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AALIg23714 for ipng-dist; Fri, 10 Aug 2001 03:21:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AALED23704 for ; Fri, 10 Aug 2001 03:21:14 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA11259 for ; Fri, 10 Aug 2001 03:21:20 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13176 for ; Fri, 10 Aug 2001 03:21:18 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f7AAL3820218; Fri, 10 Aug 2001 12:21:04 +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 MAA18885; Fri, 10 Aug 2001 12:21:03 +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.11.3/8.11.3) with ESMTP id f7AAL2u80638; Fri, 10 Aug 2001 12:21:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108101021.f7AAL2u80638@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: kitamura@da.jp.nec.com, ipng@sunroof.eng.sun.com Subject: Re: draft-kitamura-ipv6-name-auto-reg-00.txt In-reply-to: Your message of Fri, 10 Aug 2001 18:00:21 +0900. <20010810090021.188357BA@starfruit.itojun.org> Date: Fri, 10 Aug 2001 12:21:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: - at detector, you can't differentiate between temporary address and non-temporary address. there's no indication available on the 128bit address bits. => I disagree: a very simple idea is to test the (in)famous universal/local bit of the interface ID... Francis.Dupont@enst-bretagne.fr PS: I complain against the unfair suggestion to send this draft to the DNSext WG! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 03:27:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAR2q23785 for ipng-dist; Fri, 10 Aug 2001 03:27:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAQvD23778 for ; Fri, 10 Aug 2001 03:26:57 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA11512 for ; Fri, 10 Aug 2001 03:27:03 -0700 (PDT) Received: from starfruit.itojun.org (host217-33-137-35.ietf.ignite.net [217.33.137.35]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14759 for ; Fri, 10 Aug 2001 03:27:00 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 4D2427BA; Fri, 10 Aug 2001 19:23:32 +0900 (JST) To: Francis Dupont Cc: kitamura@da.jp.nec.com, ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Fri, 10 Aug 2001 12:21:02 +0200. <200108101021.f7AAL2u80638@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-kitamura-ipv6-name-auto-reg-00.txt From: Jun-ichiro itojun Hagino Date: Fri, 10 Aug 2001 19:23:32 +0900 Message-Id: <20010810102332.4D2427BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - at detector, you can't differentiate between temporary address and > non-temporary address. there's no indication available on the 128bit > address bits. >=> I disagree: a very simple idea is to test the (in)famous universal/local >bit of the interface ID... there are non-temporary address with u/l bit set to "local". itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 03:33:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAWuP23822 for ipng-dist; Fri, 10 Aug 2001 03:32:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAWpD23815 for ; Fri, 10 Aug 2001 03:32:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00570 for ; Fri, 10 Aug 2001 03:32:57 -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 EAA09982 for ; Fri, 10 Aug 2001 04:33:02 -0600 (MDT) Received: from localhost ([2001:618:7:2:791f:5cbf:fefd:7f77]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id TAA26165; Fri, 10 Aug 2001 19:35:25 +0900 (JST) Date: Fri, 10 Aug 2001 19:30:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Jun-ichiro itojun Hagino , kitamura@da.jp.nec.com, ipng@sunroof.eng.sun.com Subject: Re: draft-kitamura-ipv6-name-auto-reg-00.txt In-Reply-To: <200108101021.f7AAL2u80638@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200108101021.f7AAL2u80638@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 10 Aug 2001 12:21:02 +0200, >>>>> Francis Dupont said: > - at detector, you can't differentiate between temporary address and > non-temporary address. there's no indication available on the 128bit > address bits. > => I disagree: a very simple idea is to test the (in)famous universal/local > bit of the interface ID... I don't think so. Even for stateless-autoconfigured hosts, it should be allowed to use non-EUD, non-random interface IDs. That is, a public autoconfigured address can have an interface address with the universal/local bit being turned off (unlike EUI-64 IDs). We cannot syntactically tell such public addresses from temporary addresses. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 03:37:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAbDj23848 for ipng-dist; Fri, 10 Aug 2001 03:37:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAb9D23841 for ; Fri, 10 Aug 2001 03:37:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00807 for ; Fri, 10 Aug 2001 03:37:15 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23789 for ; Fri, 10 Aug 2001 04:37:12 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f7AAbD824676 for ; Fri, 10 Aug 2001 12:37:13 +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 MAA19058 for ; Fri, 10 Aug 2001 12:37: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.11.3/8.11.3) with ESMTP id f7AAbCu80731 for ; Fri, 10 Aug 2001 12:37:12 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108101037.f7AAbCu80731@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: USAGI & talk Date: Fri, 10 Aug 2001 12:37:12 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk talk is the best example of a broken application protocol I know: - first version sent Vax structures as it - second version sent sockaddr structure with network endianess So I support Itojun, please use a text representation of addresses, not a binary internal stuff! Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 10 03:42:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAgcr23919 for ipng-dist; Fri, 10 Aug 2001 03:42:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAgYD23912 for ; Fri, 10 Aug 2001 03:42:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00983 for ; Fri, 10 Aug 2001 03:42:40 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13702 for ; Fri, 10 Aug 2001 04:42:45 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA20028; Fri, 10 Aug 2001 12:42:09 +0200 (MET DST) Date: Fri, 10 Aug 2001 12:42:09 +0200 From: Ignatios Souvatzis To: Francis Dupont Cc: Jun-ichiro itojun Hagino , kitamura@da.jp.nec.com, ipng@sunroof.eng.sun.com Subject: Re: draft-kitamura-ipv6-name-auto-reg-00.txt Message-ID: <20010810124209.D19324@theory.cs.uni-bonn.de> References: <20010810090021.188357BA@starfruit.itojun.org> <200108101021.f7AAL2u80638@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="juZjCTNxrMaZdGZC" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108101021.f7AAL2u80638@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Fri, Aug 10, 2001 at 12:21:02PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --juZjCTNxrMaZdGZC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 10, 2001 at 12:21:02PM +0200, Francis Dupont wrote: > In your previous mail you wrote: >=20 > - at detector, you can't differentiate between temporary address and > non-temporary address. there's no indication available on the 128b= it > address bits. > =20 > =3D> I disagree: a very simple idea is to test the (in)famous universal/l= ocal > bit of the interface ID... Doesn't work in a lot of cases. - machines without Ethernet, only a PPP (or ARCnet) connection, won't have any global EUI64 to use - machines configured by DHCP won't use the EUI64-mapped EUI48 Regards, -is --juZjCTNxrMaZdGZC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO3O6fTCn4om+4LhpAQGqjggAxlANtGayWSJohJv9Z+67ZrjJSI7VBBJz nBXPej7EdhwC4obAIZKc2R37aib86Zf8uIwJJ8UXhA+/Xd5UX3EmDgz8G6/GSJyL ygaqi1j9LzWwULS/CRMT46S83BLs+IY5/f0f0g/m5UXwUEPTCW1nYEkflVvKoDV0 9Jh44doFbEMugjkD48H5XuuGEht05Ku832nc/7zhLXB4wfGsVxKc2bw5mdJ5dPeX sykAHqtZJhT7/pbr6Z8WbdLXiByVLL1lG8ZlH1SGeics2+L6V2jWKB9V+N9id8a3 a7+6FxWaI2nsIqe//PygMPA8ZWyvRcpdyq3a7X+u3LfDDs4kX53Zgw== =uF5d -----END PGP SIGNATURE----- --juZjCTNxrMaZdGZC-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 03:44:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAiJF23965 for ipng-dist; Fri, 10 Aug 2001 03:44:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAiFD23958 for ; Fri, 10 Aug 2001 03:44:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07668 for ; Fri, 10 Aug 2001 03:44:21 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA14556 for ; Fri, 10 Aug 2001 04:44:27 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA20054 for ipng@sunroof.eng.sun.com; Fri, 10 Aug 2001 12:44:19 +0200 (MET DST) Date: Fri, 10 Aug 2001 12:44:19 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: USAGI & talk Message-ID: <20010810124419.E19324@theory.cs.uni-bonn.de> References: <200108101037.f7AAbCu80731@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="DWg365Y4B18r8evw" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108101037.f7AAbCu80731@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Fri, Aug 10, 2001 at 12:37:12PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --DWg365Y4B18r8evw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Aug 10, 2001 at 12:37:12PM +0200, Francis Dupont wrote: > talk is the best example of a broken application protocol I know: > - first version sent Vax structures as it > - second version sent sockaddr structure with network endianess > So I support Itojun, please use a text representation of addresses, > not a binary internal stuff! Reminds me I've wanted to write up a next generation talk protocol document with less explicit addresses, and that actually uses the lenght provided, for a long long time. Regards, -is --DWg365Y4B18r8evw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO3O6/zCn4om+4LhpAQGbnQgAhGN4Dt+sFusuurJWRE5/lJ0Ok1KPYWeO uswdzMd8R6YxriOvSXwUdQpWHOuC/EKy4Jeq04XGl26nBsYgZETQHJFTXX6o4FO7 kseS4CqL6ijOsB4ouq+JXUC3RxeBfd0DS9sK5cQw3HPKCw09LSnX/3TskURqJkEW WYmrzod7td5GEre42eKROyoy5f5DSxonJB5TOWEXD44tJpQj7FV+K3nSyoN63+1y uxOS79LV/y3XjHuaAFKud9NrmJMkKvoT+XVmB+wF0g49phd5UkINytg/nzvflv8Q HzKXK9t9T4kd7cPyJ1sDtWSKLWtjY3qFjQuJEhPVciPvPvlaRvYjNw== =x08i -----END PGP SIGNATURE----- --DWg365Y4B18r8evw-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 03:55:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAspl24010 for ipng-dist; Fri, 10 Aug 2001 03:54:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAsmD24003 for ; Fri, 10 Aug 2001 03:54:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08531 for ; Fri, 10 Aug 2001 03:54:54 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01777 for ; Fri, 10 Aug 2001 03:54:54 -0700 (PDT) Received: from CLASSIC.viagenie.qc.ca (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f7ABIlQ27198; Fri, 10 Aug 2001 07:18:47 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010810063123.0209c310@127.0.0.1> X-Sender: blanchet@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 10 Aug 2001 06:57:34 -0400 To: ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: draft-blanchet-ngtrans-exampleaddr-01 Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, in the ngtrans meeting, it was requested that this topic will be discussed by the ipv6 wg. I'm waiting for further instructions for moving forward. Marc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 03:59:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7AAxTn24036 for ipng-dist; Fri, 10 Aug 2001 03:59:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7AAxND24029 for ; Fri, 10 Aug 2001 03:59:23 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13412 for ; Fri, 10 Aug 2001 03:59:29 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03509 for ; Fri, 10 Aug 2001 03:59:29 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id FAA30904; Fri, 10 Aug 2001 05:57:18 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7AAxNr98528; Fri, 10 Aug 2001 06:59:23 -0400 Subject: Re: draft-kitamura-ipv6-name-auto-reg-00.txt To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, Jun-ichiro itojun Hagino , kitamura@da.jp.nec.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Fri, 10 Aug 2001 11:55:50 +0100 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 08/10/2001 06:59:23 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Friday, 08/10/2001 at 12:21 ZE2, Francis Dupont wrote: > In your previous mail you wrote: > > - at detector, you can't differentiate between temporary address and > non-temporary address. there's no indication available on the 128bit > address bits. > > => I disagree: a very simple idea is to test the (in)famous universal/local > bit of the interface ID... But only if the interface ID is generated as an EUI-64. DHCP, manual configuration, and even stateless address autoconfig without privacy extensions may (and likely will) use interface IDs which are only locally unique. Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 14:28:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ALRrt25945 for ipng-dist; Fri, 10 Aug 2001 14:27:53 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ALRpD25938 for ; Fri, 10 Aug 2001 14:27:51 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ALQAe08628 for ipng@sunroof.eng.sun.com; Fri, 10 Aug 2001 14:26:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79FFVD20947; Thu, 9 Aug 2001 08:15:31 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08014; Thu, 9 Aug 2001 08:15:36 -0700 (PDT) Received: from eagle.verisign.com (eagle.verisign.com [208.206.241.105]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02883; Thu, 9 Aug 2001 08:15:33 -0700 (PDT) Received: from postal-gw1.verisign.com (verisign.com [63.104.27.101]) by eagle.verisign.com (8.9.3/BCH1.7.1) with ESMTP id IAA02061; Thu, 9 Aug 2001 08:18:30 -0700 (PDT) Received: by postal-gw.verisign.com with Internet Mail Service (5.5.2654.89) id ; Thu, 9 Aug 2001 08:15:21 -0700 Message-ID: <2F3EC696EAEED311BB2D009027C3F4F4058696C6@vhqpostal.verisign.com> From: "Hallam-Baker, Phillip" To: "'Keith Moore'" , "Hallam-Baker, Phillip" Cc: "'Randy Bush'" , alh-ietf@tndh.net, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Thu, 9 Aug 2001 08:15:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C120E6.1A521B40" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C120E6.1A521B40 Content-Type: text/plain; charset="iso-8859-1" > Understood. But very little of that security benefit is > really due to NAT; most of it is due to the fact that > connections have to be initiated from within. That's > certainly an artifact of NAT (actually NAPT) but it can > be done just as easily without translating addresses. Unfortunately the problem with anything labelled 'security' is that once it is installed it is practically impossible to shift. We still have people who refuse to countenance moving from DES which has been broken in practice to AES because they don't know how secure AES will prove... well duuhh, it ain't gonna be worse than DES. So we give them 3DES rather than argue. Co-opting the NAT box as you suggest to become a 6 to 4 type box is the real answer. Wishing they will go away is simply futile. Phill ------_=_NextPart_000_01C120E6.1A521B40 Content-Type: application/octet-stream; name="Phillip Hallam-Baker (E-mail).vcf" Content-Disposition: attachment; filename="Phillip Hallam-Baker (E-mail).vcf" BEGIN:VCARD VERSION:2.1 N:Hallam-Baker;Phillip FN:Phillip Hallam-Baker (E-mail) ORG:VeriSign TITLE:Principal Consultant TEL;WORK;VOICE:(781) 245-6996 x227 EMAIL;PREF;INTERNET:hallam@verisign.com REV:20010214T163732Z END:VCARD ------_=_NextPart_000_01C120E6.1A521B40-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 14:28:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ALSE425958 for ipng-dist; Fri, 10 Aug 2001 14:28:14 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ALSCD25951 for ; Fri, 10 Aug 2001 14:28:12 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ALQUC08658 for ipng@sunroof.eng.sun.com; Fri, 10 Aug 2001 14:26:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f79HspD21408 for ; Thu, 9 Aug 2001 10:54:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01078 for ; Thu, 9 Aug 2001 10:54:58 -0700 (PDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24928 for ; Thu, 9 Aug 2001 10:54:58 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.41 2001/07/09 21:06:22 root Exp $) with SMTP id RAA26840 for ; Thu, 9 Aug 2001 17:54:58 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 09 Aug 2001 17:54:57 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 Aug 2001 10:54:56 -0700 Message-ID: <9678C2B4D848D41187450090276D1FAE09C85ABA@FMSMSX32> From: Ranjeeta To: "'ipng@sunroof.eng.sun.com'" Subject: Question on ICMPv6 Date: Thu, 9 Aug 2001 10:54:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Does anybody know what RFC I should refer to for ICMPv6 Checksum calculation? Thanks, Ranjeeta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 14:29:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ALSd025969 for ipng-dist; Fri, 10 Aug 2001 14:28:39 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ALSZD25962 for ; Fri, 10 Aug 2001 14:28:35 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ALQs808688 for ipng@sunroof.eng.sun.com; Fri, 10 Aug 2001 14:26:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7A3QeD22433; Thu, 9 Aug 2001 20:26:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04480; Thu, 9 Aug 2001 20:26:45 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12892; Thu, 9 Aug 2001 20:26:45 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id UAA07385; Thu, 9 Aug 2001 20:14:18 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 9 Aug 2001 20:14:18 -0700 (PDT) From: Bernard Aboba To: Robert Elz cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <4216.997348572@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That wasn't the way I read Paul's comment - I read it more as suggesting > that if the IETF doesn't pick one way or the other, and completely > stamp out the other (ie: if one gets marked as experimental, or if both > get left as PS), then you (Microsoft) will just pick whichever one that > appeals to you most, and that will effectively set the standard, > regardless of what any of the rest of us think later. > I believe that it was Pogo that said: "We have met the enemy... and it is us." Rather than worrying so much about what this or that company might do, the IETF might better spend its time and energy making clear decisions within a reasonable timeframe. Most IPv6 implementors will need to make a decision on how to handle AAAA/A6 in the next 6 months. Without guidance from the IETF, history suggests that they will each make the decision based on their own analysis, and then once having shipped, less flexibility will be available in order to accomodate the installed base. We've already gone down this road with IKE -- where the most basic VPN scenarios do not interoperate. In many cases "no decision" is actually the worst possible decision. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 10 14:41:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ALeXE26120 for ipng-dist; Fri, 10 Aug 2001 14:40:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ALeTD26113 for ; Fri, 10 Aug 2001 14:40:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08810 for ; Fri, 10 Aug 2001 14:40:37 -0700 (PDT) Received: from sea-av1.zama.net (smtp1.zama.net [203.142.132.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02309 for ; Fri, 10 Aug 2001 15:40:42 -0600 (MDT) Received: from sea-av1.zama.net (localhost [127.0.0.1]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id OAA01797 for ; Fri, 10 Aug 2001 14:40:35 -0700 (PDT) Received: from postoff1.zama.net (sea-postoff1.zama.net [172.16.100.20]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id OAA01789 for ; Fri, 10 Aug 2001 14:40:34 -0700 (PDT) Received: from bmcgehee ([203.142.132.5]) by postoff1.zama.net (Netscape Messaging Server 4.15) with ESMTP id GHVG7M00.30G; Fri, 10 Aug 2001 14:40:34 -0700 From: "Brian McGehee" To: "Ranjeeta" , Subject: RE: Question on ICMPv6 Date: Fri, 10 Aug 2001 14:40:34 -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.2911.0) Importance: Normal In-Reply-To: <9678C2B4D848D41187450090276D1FAE09C85ABA@FMSMSX32> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following may lead you to the right information. Section 2.3 of rfc 2463 2.3 Message Checksum Calculation The checksum is the 16-bit one's complement of the one's complement sum of the entire ICMPv6 message starting with the ICMPv6 message type field, prepended with a "pseudo-header" of IPv6 header fields, as specified in [IPv6, section 8.1]. The Next Header value used in the pseudo-header is 58. (NOTE: the inclusion of a pseudo-header in the ICMPv6 checksum is a change from IPv4; see [IPv6] for the rationale for this change.) For computing the checksum, the checksum field is set to zero. ...happy hunting Brian McGehee Zama Networks mailto:doc@zama.net http://www.zama.net/Static.po?name=zacademy /o)\ \(o/ -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Ranjeeta Sent: Thursday, August 09, 2001 10:55 AM To: 'ipng@sunroof.eng.sun.com' Subject: Question on ICMPv6 Hi, Does anybody know what RFC I should refer to for ICMPv6 Checksum calculation? Thanks, Ranjeeta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Aug 10 17:40:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7B0e9g26460 for ipng-dist; Fri, 10 Aug 2001 17:40:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7B0e4D26442 for ; Fri, 10 Aug 2001 17:40:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24097 for ; Fri, 10 Aug 2001 17:40:11 -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 SAA08257 for ; Fri, 10 Aug 2001 18:40: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 RAA16625; Fri, 10 Aug 2001 17:40:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7B0e8V32612; Fri, 10 Aug 2001 17:40:08 -0700 X-mProtect: Fri, 10 Aug 2001 17:40:08 -0700 Nokia Silicon Valley Messaging Protection Received: from maxdialin30.iprg.nokia.com (205.226.20.224, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdVNu6Jg; Fri, 10 Aug 2001 17:40:06 PDT Message-ID: <3B747EFF.CA54BCB6@iprg.nokia.com> Date: Fri, 10 Aug 2001 17:40:31 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Working Group CC: AAA Working Group Mailing List Subject: AAA for IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, At the IPv6 meeting in IETF 51, there was a discussion about whether the AAA working group should consider the possibility of accepting a work item to standardize a protocol to enable the use of AAA to authorize network access for IPv6 nodes. The general sense of the working group seemed quite positive on suggesting that such a thing would be appropriate. I am specifically _not_ asking whether our AAAv6 document should be considered as a working group document within the AAA working group. That would be a matter for the AAA working group to consider. I am only attempting to find out whether the general sense of the working group is the same as the general sense that was expressed at IETF 51. If approval is voiced, or at least objections are not raised, then I will relay the information to the AAA working group. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 11 02:15:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7B9Ei327443 for ipng-dist; Sat, 11 Aug 2001 02:14:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7B9EeD27436 for ; Sat, 11 Aug 2001 02:14:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17179 for ; Sat, 11 Aug 2001 02:14:48 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01466 for ; Sat, 11 Aug 2001 03:14:55 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7B9Eao12101; Sat, 11 Aug 2001 12:14:36 +0300 Date: Sat, 11 Aug 2001 12:14:36 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: , Subject: Re: Fwd: Re: note from the iesg plenary In-Reply-To: <4.2.2.20010810223354.00a87100@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've added ipng to Cc: list as this has never been discussed there, and is IMO mostly ipng-stuff. On Fri, 10 Aug 2001, Margaret Wasserman wrote: > >>Basically, I have four issues: > >> > >> (1) Boundaries for regular route lookups. > >> (2) Site-local routing. > >> (3) Anycast routing. > >> (4) Routing table MIBs. > >> > >>(1) The current addressing architecture defines all routable > >>unicast addresses to include a 64-bit identifier. Does that mean > >>that it is reasonable for a router to only look at the first 64 > >>bits when making a routing decision? Or should routers still treat > >>these addresses as CIDR-like? I think this was discussed very recently in 'prefix length used by backbone routers' thread in multi6. I'm not sure if all issues raised here were brought up there. > >>(2) Site-local routing is particularly confusing on a site-border router. > >>I don't know if anyone has really implemented one, but it seems likely > >>that it will need to have multiple routing tables (one global table > >>and one per attached site). Even an intra-site router may need two > >>conceptual routing tables (one global, one site). [snip] Why would there be a need for two routing tables? It might help, but I don't see it as strictly necessary. Wouldn't "practically" some equivalent of an IPv6 access list, blocking site-local addresses from spreading outside of the site and in the site be sufficient? Also, all routing EGP protocols should have route-map's or equivalent to eliminate the possible spread of site-local, and link-local, address announcements. It's legal to use different AS numbers inside the site (e.g. one or two primary ones and some from private space), the default behaviour perhaps should be: 1) in eBGP (or anything between two AS numbers), filter site-local announcements by default 2) if extra keyword "same-site" is used even with different AS's, this would not be done. > >>(3) IPv6 anycast is substantially different from the anycast hacks > >>currently used in IPv4. One big difference: a global IPv6 anycast > >>address would (probably?) not appear to be inside of anyone's AS. > >>I don't know if this causes problems, as I haven't had time to look > >>at how OSPF would handle a host route injection for a router outside > >>the AS. Another huge difference (from usage point of view): IPv6 anycast address MUST not be used as a source address. I doubt host route injection will work due to "martian" filtering of /128's, or other such routes. What will work, is the similar thing as it is done with IPv4 anycast: Consider: 6to4 IPv4 anycast prefix is 192.88.99.0/24. 6to4 IPv4 anycast address is 192.88.99.1. If someone injected 192.88.99.1, that would surely be filtered. But as IPv6 anycast is defined the same as IPv4 anycast, you can just inject routes to to some /48, /64, etc. networks -- no different than current route injections. (btw, nobody is advertising 6to4 anycast prefix in DFZ yet. Shows the current ipv4 anycast deployment rate mentioned in ngtrans at IETF51 wrt. isatap discovery IMO.. :-) > >>However, the IPv4 stuff has only been tried with BGP. Do we know for > >>sure that the OSPF tree will converge if it thinks that one host is > >>actually located at two different places in the topology? Maybe this > >>would just work -- I don't know OSPF well enough to know for sure > >>without closely reviewing the spec (or maybe trying it). We cannot be sure. That is, if OSPF costs (or other protocols' metrics) to different anycast advertisements are equal, there will be load-balancing. But then again, this might be designed behaviour (for unicast, probably not for anycast) too. By designing the site topology properly, and adjusting the last-hop (ie. router to host providing anycast service; this might not always be doable if routers themselves act as anycast servers) OSPF costs by adding big values there, e.g. "500" or "1000" so there would be no overlap no matter what, this should converge quite nicely. This is a policy issue. One might want to (in intra-site policy) either (or some others): - select the closest anycast server (ospf cost should not be adjusted, loadbalancing would be considered a feature) - select always the default anycast server if it's responding, if not, select a different one (preferring the service with ospf cost) > >>(4) The current IPv6 routing table MIBs are based on the IPv4 > >>routing MIBs. It isn't clear if they will be able to properly > >>handle IPv6 routing tables, as they may be different. Once we > >>figure out the architecture and conceptual datastructures, I will > >>closely review the MIBs to see if they match. As you know, Bill Fenner is revising these. Now's the time... -- 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 Aug 11 07:50:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7BEniA27698 for ipng-dist; Sat, 11 Aug 2001 07:49:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7BEndD27691 for ; Sat, 11 Aug 2001 07:49:40 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01038 for ; Sat, 11 Aug 2001 07:49:49 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA18910 for ; Sat, 11 Aug 2001 07:49:48 -0700 (PDT) Received: (qmail 4625 invoked by uid 500); 11 Aug 2001 14:38:20 -0000 Date: Sat, 11 Aug 2001 07:38:20 -0700 From: Pat Calhoun To: Charlie Perkins Cc: IPng Working Group , AAA Working Group Mailing List Subject: Re: [AAA-WG]: AAA for IPv6 Message-ID: <20010811073820.J3420@charizard.diameter.org> Mail-Followup-To: Charlie Perkins , IPng Working Group , AAA Working Group Mailing List References: <3B747EFF.CA54BCB6@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B747EFF.CA54BCB6@iprg.nokia.com>; from charliep@IPRG.nokia.com on Fri, Aug 10, 2001 at 05:40:31PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that the AAA WG should expand its charter to allow for folks in other WGs looking at using AAA in their application to come forth. Perhaps the AAA WG would be a place for the Diameter application to be created. I am, however, afraid of boiling the ocean, so we need to be very careful in what work items we accept. We do, however, want to make sure that we don't end up with n number of accounting protocols in the IETF (something that is actually happening as I type). So, keeping some order is a good thing. If the WG goes away, it becomes the IESG's responsibility. My 2 cents, PatC On Fri, Aug 10, 2001 at 05:40:31PM -0700, Charlie Perkins wrote: > > Hello folks, > > At the IPv6 meeting in IETF 51, there was a discussion about whether > the AAA working group should consider the possibility of accepting a > work item to standardize a protocol to enable the use of AAA to > authorize network access for IPv6 nodes. The general sense of the > working group seemed quite positive on suggesting that such a thing > would be appropriate. > > I am specifically _not_ asking whether our AAAv6 document should > be considered as a working group document within the AAA working > group. That would be a matter for the AAA working group to consider. > I am only attempting to find out whether the general sense of the > working group is the same as the general sense that was expressed > at IETF 51. If approval is voiced, or at least objections are not > raised, then I will relay the information to the AAA working group. > > Regards, > Charlie P. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 11 08:48:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7BFlXF27763 for ipng-dist; Sat, 11 Aug 2001 08:47:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7BFlTD27756 for ; Sat, 11 Aug 2001 08:47:29 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00014 for ; Sat, 11 Aug 2001 08:47:39 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29445 for ; Sat, 11 Aug 2001 08:47:38 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Sat, 11 Aug 2001 17:47:35 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECA94F@mail.kebne.se> From: Thomas Eklund To: "'Pat Calhoun '" , "'Charlie Perkins '" Cc: "'IPng Working Group '" , "'AAA Working Group Mailing List '" Subject: RE: [AAA-WG]: AAA for IPv6 Date: Sat, 11 Aug 2001 17:47:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Pat and AAA WG, I belive that it should be a working group item. The draft shows how access control could be done for IPv6. It does not propose any new accounting protocol it proposes how authentication and authorazation could be done with both a stateful approach (i.e. DHCPv6) and a stateless approach (ND). -- Best Regards Thomas -----Original Message----- From: Pat Calhoun To: Charlie Perkins Cc: IPng Working Group; AAA Working Group Mailing List Sent: 2001-08-11 16:38 Subject: Re: [AAA-WG]: AAA for IPv6 I think that the AAA WG should expand its charter to allow for folks in other WGs looking at using AAA in their application to come forth. Perhaps the AAA WG would be a place for the Diameter application to be created. I am, however, afraid of boiling the ocean, so we need to be very careful in what work items we accept. We do, however, want to make sure that we don't end up with n number of accounting protocols in the IETF (something that is actually happening as I type). So, keeping some order is a good thing. If the WG goes away, it becomes the IESG's responsibility. My 2 cents, PatC On Fri, Aug 10, 2001 at 05:40:31PM -0700, Charlie Perkins wrote: > > Hello folks, > > At the IPv6 meeting in IETF 51, there was a discussion about whether > the AAA working group should consider the possibility of accepting a > work item to standardize a protocol to enable the use of AAA to > authorize network access for IPv6 nodes. The general sense of the > working group seemed quite positive on suggesting that such a thing > would be appropriate. > > I am specifically _not_ asking whether our AAAv6 document should > be considered as a working group document within the AAA working > group. That would be a matter for the AAA working group to consider. > I am only attempting to find out whether the general sense of the > working group is the same as the general sense that was expressed > at IETF 51. If approval is voiced, or at least objections are not > raised, then I will relay the information to the AAA working group. > > Regards, > Charlie P. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 12 04:51:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7CBoee28950 for ipng-dist; Sun, 12 Aug 2001 04:50:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CBobD28943 for ; Sun, 12 Aug 2001 04:50:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10709 for ; Sun, 12 Aug 2001 04:50:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13466 for ; Sun, 12 Aug 2001 04:50:45 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7CBoh524260 for ; Sun, 12 Aug 2001 14:50:44 +0300 Date: Sun, 12 Aug 2001 14:50:43 +0300 (EEST) From: Pekka Savola To: Subject: Mapped IPv6 Flow label In-Reply-To: <20010810093140.D9EB77BA@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, [ http://www.ietf.org/internet-drafts/draft-conta-ipv6-flow-label-02.txt ] The ipv6 flow label draft presented at IETF51 generated a lot of discussion; basically UDP/TCP port numbers and some other data is mapped into the proposed Flow label field. The concern on the security, and reliability, of this were raised, and rightly so (I agree), but IMO the main point is this: Currently, Edge routers or hosts themselves, set DSCP/Traffic Class bits in the datagrams after looking at UDP/TCP ports, or some other, functionally equivalent data. Traffic class is of limited size and has no global meaning. With separate, sufficiently long Flow Label field, DiffServ model _could_ be extended so that the core routers themselves (or Edge/Border routers mode scalably) could perform classification and differentiation. The data -> Flow Label mapping only has to be done once, and it's in a fixed position in the header. The policy within different AS's, how to deal with specific packets, could be (mostly) covered. The packet wouldn't have to reclassified at the border. Were it not for reliability, layer violation, the function of core routers, etc. considerations, this _could_ be viewed as a Good Thing for enabling easier _Internet-wide_ QoS. This is perhaps one "justification" for the author for introducing this behaviour. Just bringing up one point about DiffServ which was not all that possible with IPv4.. -- 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 Aug 12 08:49:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7CFnNO29225 for ipng-dist; Sun, 12 Aug 2001 08:49:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CFnJD29218 for ; Sun, 12 Aug 2001 08:49:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03845 for ; Sun, 12 Aug 2001 08:49:29 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17141 for ; Sun, 12 Aug 2001 08:49:29 -0700 (PDT) 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 IAA11292; Sun, 12 Aug 2001 08:49:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7CFnSo31403; Sun, 12 Aug 2001 08:49:28 -0700 X-mProtect: Sun, 12 Aug 2001 08:49:28 -0700 Nokia Silicon Valley Messaging Protection Received: from slip139-92-151-55.fra.de.prserv.net (139.92.151.55, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdENwQF3; Sun, 12 Aug 2001 08:49:25 PDT Message-Id: <4.3.2.7.2.20010812084819.01e7e3d8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 12 Aug 2001 08:49:11 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft Minutes from London IPng Meeting Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft minutes and most of the presentations for the IPng working group meeting held at the London IETF can be found at: http://playground.sun.com/pub/ipng/html/meetings.html Corrections and updates to me. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 12 21:03:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7D42Tb00073 for ipng-dist; Sun, 12 Aug 2001 21:02:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7D42PD00066; Sun, 12 Aug 2001 21:02:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06593; Sun, 12 Aug 2001 21:02:34 -0700 (PDT) Received: from nara.off.connect.com.au (nara.off.connect.com.au [192.94.41.40]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA09681; Sun, 12 Aug 2001 22:02:43 -0600 (MDT) Received: (from njones@localhost) by nara.off.connect.com.au id OAA07780 (8.8.8/IDA-1.7); Mon, 13 Aug 2001 14:02:29 +1000 (EST) Message-ID: <20010813140229.C4458@connect.com.au> Date: Mon, 13 Aug 2001 14:02:29 +1000 From: Nathan Jones To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <4216.997348572@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Bernard Aboba on Thu, Aug 09, 2001 at 08:14:18PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A6 supporters have spent a lot of time promoting flexibility, arguing that we shouldn't limit our options because of fear of what might happen. AAAA supporters have spent a lot of time telling us that such flexibility is not required and that possible A6 implementation problems can't be fixed just by making recommendations for DNS administrators. The debate has gone on and on, but no consensus has been reached. (I don't consider hums at London's meeting to be consensus.) Is there merit in asking the Area Directors (or possibly the IESG) for arbitration? -- nathanj Matt Crawford wrote: >Here's the problem. There was no attempt at consenus *building* after >the discussion, only a quick measurement of opinions at that point. Bernard Aboba wrote: >Rather than worrying so much about what this or that company might do, the >IETF might better spend its time and energy making clear decisions within >a reasonable timeframe. > >In many cases "no decision" is actually the worst possible decision. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 12 22:12:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7D5Buj00160 for ipng-dist; Sun, 12 Aug 2001 22:11:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7D5BpD00151 for ; Sun, 12 Aug 2001 22:11:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15898 for ; Sun, 12 Aug 2001 22:12:02 -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 XAA01530 for ; Sun, 12 Aug 2001 23:12:09 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA13655; Mon, 13 Aug 2001 14:13:40 +0900 (JST) Date: Mon, 13 Aug 2001 05:02:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Mohit Talwar" Cc: , , , "Brian Zill" Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-v3-01.txt In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1610A11@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1610A11@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 8 Aug 2001 10:02:08 -0700, >>>>> "Mohit Talwar" said: > Perhaps, if it is not considered too restrictive, we should enforce that > all ICMPv6 error messages consist of the base ICMPv6 header followed by > "32 bits of type-specific data", (followed by as much of the offending > packet as will fit without making the error packet exceed 1280 bytes. I agree. At least the spec should be more clear about the format of the unknown error messages. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 12 22:15:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7D5Ek600181 for ipng-dist; Sun, 12 Aug 2001 22:14:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7D5EgD00173 for ; Sun, 12 Aug 2001 22:14:42 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA16054 for ; Sun, 12 Aug 2001 22:14:52 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26732 for ; Sun, 12 Aug 2001 22:14:51 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA13692; Mon, 13 Aug 2001 14:15:09 +0900 (JST) Date: Mon, 13 Aug 2001 05:27:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: "Mauro Tortonesi" , Subject: Re: draft-ietf-default-addr-select-04.txt (fwd) In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FC5D@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA80355FC5D@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 8 Aug 2001 22:26:52 -0700, >>>>> "Richard Draves" said: >> IMHO, draft-ietf-default-addr-select-04.txt is a very well >> done work. i wonder how many implementations already support >> source and destination address selection. does any of you >> have some information about this? > The MS implementation supports the draft. The recent versions of KAME snapshot releases for *BSD have a partial support of the destination ordering. "Partial" means that the implementation skips some of the rules specified in the draft. For example, it does not support the flexible policy table. You can freely refer to the implementation at KAME's libinet6/getaddrinfo.c. We're also planning to implement the source address selection part in the KAME stack, probably in the very near future. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 13 03:24:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DANcO00827 for ipng-dist; Mon, 13 Aug 2001 03:23:38 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DANWD00809 for ; Mon, 13 Aug 2001 03:23:32 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7DANW203446; Mon, 13 Aug 2001 12:23:33 +0200 (MET DST) Date: Mon, 13 Aug 2001 12:20:53 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Wrap up and last call: sin6_scope_id semantics To: Robert Elz Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5436.997292176@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That is, pick the scope identifier of a lower level object that is within > the higher level object as the identifier for that object. > > That is to avoid the problem where "1" means one place in one context > and somewhere totally different in another. Instead "2" in link context > would mean a particular link, in site context it would mean a collection > of links, but the link "2" would certainly be one of them. I don't know if there is a requirement for the stability of ids that has bearing on this suggestion. For instance, when intf #2 is removed from the node while running, then applications explicitly using intf #2 would clearly need to handle the change to the configuration. But your constraint seem to imply that the ID(link2) would now need to change from 2 to be the same as the ID for some other interface in that link. That would force applications using link ids to handle the reconfiguration even though the node is still attached to the same set of sites - it is merely using different interfaces to attach to the links. I guess one could handle this type of reconfiguration by - never reusing the IDs at any scope for new stuff, and - somehow keeping the historic bindings around. That way ID(link2) = 2 even though interface #2 is gone. 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 Aug 13 04:07:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DB6ut00963 for ipng-dist; Mon, 13 Aug 2001 04:06:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DB6RD00948; Mon, 13 Aug 2001 04:06:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA26452; Mon, 13 Aug 2001 04:06:36 -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 FAA10979; Mon, 13 Aug 2001 05:06:42 -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 HAA13578; Mon, 13 Aug 2001 07:05:19 -0400 (EDT) Message-Id: <200108131105.HAA13578@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt Date: Mon, 13 Aug 2001 07:05:18 -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 : Transitional Integration of Mobile IPv4 and Mobile IPv6 Author(s) : P. Engelstad Filename : draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt Pages : 21 Date : 09-Aug-01 This draft outlines how a dual stack mobile node can be reached and communicate by means of both IPv4 and IPv6, even in situations where the mobile node is in reach of only either IPv4 or IPv6 networks. A Dual Stack Mobility Agent accommodates mobility and translates between IPv4 and IPv6 traffic. It may operate as a mobility agent in its own right or as a module that relays traffic between existing single stack Mobile IPv4 and Mobile IPv6 home agents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010809115441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-engelstad-ngtrans-mipv4-over-mipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010809115441.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 Aug 13 04:59:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DBx9P01197 for ipng-dist; Mon, 13 Aug 2001 04:59:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DBx6D01190 for ; Mon, 13 Aug 2001 04:59:06 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29268; Mon, 13 Aug 2001 04:59:14 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21680; Mon, 13 Aug 2001 04:59:09 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f7DBx6819912; Mon, 13 Aug 2001 13:59:06 +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 NAA03085; Mon, 13 Aug 2001 13:59:05 +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.11.3/8.11.3) with ESMTP id f7DBx4u04427; Mon, 13 Aug 2001 13:59:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108131159.f7DBx4u04427@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Robert Elz , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Mon, 13 Aug 2001 12:20:53 +0200. Date: Mon, 13 Aug 2001 13:59:04 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I don't know if there is a requirement for the stability of ids that has bearing on this suggestion. => I believe there should be none because the stability requirement should be for id names, not id values. Of course, we should recommend to use always names too. That way ID(link2) = 2 even though interface #2 is gone. => the real issue is to get ID(link2) = 2 even though interface #2 is now affected to link333... Names are the solution there too! Regards Francis.Dupont@enst-bretagne.fr PS: I believe our colleague Jinmei is waiting for a decision between options A, B and C before producing a document... Please help him! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 13 05:24:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DCNRh01241 for ipng-dist; Mon, 13 Aug 2001 05:23:27 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DCNHD01234 for ; Mon, 13 Aug 2001 05:23:17 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7DCNH214888; Mon, 13 Aug 2001 14:23:17 +0200 (MET DST) Date: Mon, 13 Aug 2001 14:20:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Wrap up and last call: sin6_scope_id semantics To: Francis Dupont Cc: Erik Nordmark , Robert Elz , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200108131159.f7DBx4u04427@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > > I don't know if there is a requirement for the stability of ids > that has bearing on this suggestion. > > => I believe there should be none because the stability requirement > should be for id names, not id values. Of course, we should recommend > to use always names too. Notice that I did *not* talk about stability across reboots. My issue is whether it is ok or not to have the ids change on a whim while the machine is *running* (e.g. due to using hotplugging to add or remove NICs). If we allow this rate of change it seems like an application needs to do the name to id translation each time it is using an id for instance each time it is sending a packet. Is that really what we want? Erik > That way ID(link2) = 2 even though interface #2 is gone. > > => the real issue is to get ID(link2) = 2 even though interface #2 > is now affected to link333... Names are the solution there too! > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I believe our colleague Jinmei is waiting for a decision between > options A, B and C before producing a document... Please help him! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 13 07:13:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DECSg01495 for ipng-dist; Mon, 13 Aug 2001 07:12:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DECOD01488 for ; Mon, 13 Aug 2001 07:12:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28374; Mon, 13 Aug 2001 07:12:32 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08648; Mon, 13 Aug 2001 08:12:29 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f7DECT824423; Mon, 13 Aug 2001 16:12:29 +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 QAA04385; Mon, 13 Aug 2001 16:12:28 +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.11.3/8.11.3) with ESMTP id f7DECRu04797; Mon, 13 Aug 2001 16:12:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108131412.f7DECRu04797@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Robert Elz , JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Mon, 13 Aug 2001 14:20:38 +0200. Date: Mon, 13 Aug 2001 16:12:27 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > In your previous mail you wrote: > > I don't know if there is a requirement for the stability of ids > that has bearing on this suggestion. > > => I believe there should be none because the stability requirement > should be for id names, not id values. Of course, we should recommend > to use always names too. Notice that I did *not* talk about stability across reboots. My issue is whether it is ok or not to have the ids change on a whim while the machine is *running* (e.g. due to using hotplugging to add or remove NICs). => it seems we agree to say it is *not* ok. If we allow this rate of change it seems like an application needs to do the name to id translation each time it is using an id for instance each time it is sending a packet. Is that really what we want? => no, we don't want that. Only the inheritance stuff should be called each time. Note we don't want to change the name-id file very often too. Regards Francis.Dupont@enst-bretagne.fr PS: I believe you'd like to get some freedom in the way zone ID values are chosen. If we use a per interface list of zones which the interface belongs to, then we can implement what we'd like... Simple schemes are easier because they don't need the reverse map (zones to interface lists). PPS: simple schemes can be described and simulated when the name-id file is configured, do more complex schemes need a standard way to express zone/interface mapping? I believe the only hairy case is the mobile node one, so do you know what we need for such cases? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 13 08:43:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7DFgUq02053 for ipng-dist; Mon, 13 Aug 2001 08:42:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7DFgQD02046 for ; Mon, 13 Aug 2001 08:42:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20798 for ; Mon, 13 Aug 2001 08:42:36 -0700 (PDT) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00639 for ; Mon, 13 Aug 2001 08:42:34 -0700 (PDT) Received: from avispa (avispa.it.uc3m.es [163.117.139.178]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id RAA10871; Mon, 13 Aug 2001 17:42:29 +0200 From: "marcelo" To: "Richard Draves" Cc: Subject: draft-ietf-ipngwg-default-addr-select-05.txt Date: Mon, 13 Aug 2001 17:41:53 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FC60@red-msg-06.redmond.corp.microsoft.com> Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Questions and comments about the default address selection mechanisms: 1- About scope and deprecated addresses in source address selection: Considering the way Rule 2 and rule 3 are specified, is it possible that a deprecated address is selected rather than a non-deprecated with bigger scope? For example suppose that the destination address D has site local scope and the outgoing interface has 2 addresses assigned: a site local address SA which is deprecated and a global address SB which is not deprecated. Applying rule 2 scope(SA); Mon, 13 Aug 2001 10:21:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00513; Mon, 13 Aug 2001 10:21:57 -0700 (PDT) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24365; Mon, 13 Aug 2001 11:22:00 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id f7DHLi013952; Tue, 14 Aug 2001 00:21:44 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7DHLAP02872; Tue, 14 Aug 2001 00:21:13 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 00:21:10 +0700 Message-ID: <2870.997723270@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 13 Aug 2001 12:20:53 +0200 (CEST) From: Erik Nordmark Message-ID: | But your constraint seem to imply that the ID(link2) would now need to | change from 2 to be the same as the ID for some other interface in that link. No, that's reading more into what I said than I intended. The important part, from my perspective, was ... avoid the problem where "1" means one place in one context and somewhere totally different in another. The rest of it was just one possibility, allowing all of interfaces, links and sites, to be numbered with small integers starting from 1. (That is, avoid numbers that have bits set up in the high bits, which Jinmei's B and C seemed to be requiring). How the numbering is done is pretty much irrelevant to me, provided that we don't have identifier ambiguity, and ideally, without using identifiers with magic in the upper bits. For all I care, you can number the interfaces 1, 2, 3, ... N, then the links N+1, N+2, ... M, then the sites M+1, ... P, then if a new interface or link (or site) appears, call it P+1. It doesn't matter that the numbers for any one type aren't contiguous. If an implementation wanted, it could even number its interfaces 1 4 7 10 ... its links 2 5 8 11 ..., and its sites 3 6 9 12 ... (also no requirement for all numbers to actually be in use). The 'Instead "2" in link context would mean a particular link, in site context it would mean a collection of links, but the link "2" would certainly be one of them' comment was just meant as one possible way that small numbers could be assigned in a way that wouldn't be too horrible (at least the identifier would always mean one general direction). You might remember that it was also a question - whether that's something that scheme A would allow (not having followed this debate, I had no idea whether it was assumed for A that the id's would be 1 2 3 for interfaces, 1 2 3 for links, and 1 2 3 for sites... - that's how it was represented in the example, and that I don't much like at all). Certainly I wouldn't want applications to have to go polling (or handling events) to discover that the id's have all changed because of some interface reconfiguration - the IDs should certainly be stable from one boot to another (or at least reasonably stable, if an interface is removed, then replaced, I don't care if it has the same ID it used to have or not). I'm not sure how applications should handle the case where an interface moves from one link to another, or a link moves from one site to another (which would be done by administrator configuration or some automated equivalent thereof I assume). For more applications it probably doesn't matter, for the others (eg: I want to (many times over an interval) send to all interfaces in site X) some kind of polling or event mechanism will probably be needed. | I guess one could handle this type of reconfiguration by | - never reusing the IDs at any scope for new stuff, and | - somehow keeping the historic bindings around. The latter isn't needed, assuming the current bindings are kept around. But yes, never re-using an ID is one fairly easy way to handle things, and one which is likely to be safe. Maybe what I'd like to say would be that no identifier should be used for any interface, link, or site, that is also used for another of those, unless the smaller of those (as defined, ie: interface < link < site) is a subset of the bigger (as configured). No requirement that there ever be any duplication, just a restriction on when duplicate ids in different scopes are permitted. 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 Mon Aug 13 18:48:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E1lPx05027 for ipng-dist; Mon, 13 Aug 2001 18:47:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E1ktD05008; Mon, 13 Aug 2001 18:46:55 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08758; Mon, 13 Aug 2001 18:46:48 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15398; Mon, 13 Aug 2001 18:45:38 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 13 Aug 2001 18:45:27 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 015BB357CA164CDAB048E269628A0C36 for plus 4 more; Mon, 13 Aug 2001 18:45:26 -0700 Reply-To: From: "Tony Hain" To: "Nathan Jones" , , , , Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Mon, 13 Aug 2001 18:45:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010813140229.C4458@connect.com.au> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: C814BCB6-A0EA4844-AC25B899-14F100AB Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7E1kxD05009 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well I told the other chairs to let the discussion on this thread continue through today as a mechanism to allow consensus to emerge, and then I would step up and try to summarize. As Matt noted in originating the thread there was no absolutely overwhelming position by those in the room in London, but to a degree that really doesn't matter. What matters is the position of those participating in the mail lists. What the question in London did was allow the chairs and IESG observers to gauge the distinction between a few very loud voices vs. a broad based level of support, and gauge how many had a willingness to express an opinion on the subject (which from what I could tell was everyone). Nathan and Bernard have a good start to the summary, in terms of boiling down the essential viewpoints. The things I would add from the discussion include: - It is clear that we know how to make A6 resolvers deal with AAAA clients. - It appears that with current tools A6 reduces the burden of renumbering on the zone administrator. - It is not clear that renumbering will occur faster than a AAAA zone file could be resigned. - It is clear that we could evolve from AAAA to A6 later if it became necessary. Additionally: - It is clear that on either path we need better tools for DNS management. - It is also clear that address renumbering can't be solved simply through DNS magic. Shortly, an Internet-Draft will be sent to the lists that describes the rough consensus (possibly very rough) of the joint group and recommends a course of action to the IESG. For this reason it would be inappropriate for the IESG to be asked to arbitrate the creation of a recommendation to themselves. While the WG chairs are listed as authors, it is still an I-D subject to comment and editing like any other. If you feel the positions presented in the draft do not represent the collective working group opinion, speak up. Tony -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Nathan Jones Sent: Sunday, August 12, 2001 9:02 PM To: ngtrans@sunroof.eng.sun.com; namedroppers@ops.ietf.org; ipng@sunroof.eng.sun.com; dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary A6 supporters have spent a lot of time promoting flexibility, arguing that we shouldn't limit our options because of fear of what might happen. AAAA supporters have spent a lot of time telling us that such flexibility is not required and that possible A6 implementation problems can't be fixed just by making recommendations for DNS administrators. The debate has gone on and on, but no consensus has been reached. (I don't consider hums at London's meeting to be consensus.) Is there merit in asking the Area Directors (or possibly the IESG) for arbitration? -- nathanj Matt Crawford wrote: >Here's the problem. There was no attempt at consenus *building* after >the discussion, only a quick measurement of opinions at that point. Bernard Aboba wrote: >Rather than worrying so much about what this or that company might do, the >IETF might better spend its time and energy making clear decisions within >a reasonable timeframe. > >In many cases "no decision" is actually the worst possible decision. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Aug 13 19:38:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E2bjS05148 for ipng-dist; Mon, 13 Aug 2001 19:37:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E2bcD05131 for ; Mon, 13 Aug 2001 19:37:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03108 for ; Mon, 13 Aug 2001 19:37:47 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA24057 for ; Mon, 13 Aug 2001 20:37:57 -0600 (MDT) Received: (qmail 10019 invoked by uid 1001); 14 Aug 2001 02:38:06 -0000 Date: 14 Aug 2001 02:38:06 -0000 Message-ID: <20010814023806.10986.qmail@cr.yp.to> Automatic-Legal-Notices: Copyright 2001, D. J. Bernstein. My transmission of this message to you does not constitute a copyright waiver or any other limitation of my rights, even if you have told me otherwise. From: "D. J. Bernstein" To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010813140229.C4458@connect.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a DNS server, a DNS cache, and a DNS client library. Current situation: (1) The server talks to caches only through IPv4. It can provide AAAA and ip6.int records, as per RFC 1123 section 6.1.3.5, but the input format is not as streamlined as the input format for A and in-addr.arpa. (2) The cache talks to servers and clients only through IPv4. It can forward AAAA records, as per RFC 1123 section 6.1.3.5, but it does not use them to locate servers. (3) The client library talks to caches only through IPv4. It doesn't include any functions related to IPv6 addresses. Plans: (1) Server: Talk to caches through IPv6. Include streamlined syntax to generate AAAA/ip6.int. (2) Cache: Talk to servers and clients through IPv6. Use AAAA records to locate servers. (3) Client library: Talk to caches through IPv6. Incorporate AAAA lookups, falling back to A. Incorporate ip6.int lookups. Things that I do _not_ plan to do: (1) A6, DNAME, bit labels, and ip6.arpa in the server. (2) A6, DNAME, bit labels, and ip6.arpa in the cache. (3) A6, DNAME, bit labels, and ip6.arpa in the client library. I want it to be crystal clear to the users that they have to set up AAAA records and ip6.int. They can't expect to be reachable if they use A6 or DNAME or ip6.arpa. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 02:41:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7E9ep805959 for ipng-dist; Tue, 14 Aug 2001 02:40:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E9ekD05952; Tue, 14 Aug 2001 02:40:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18063; Tue, 14 Aug 2001 02:40:56 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06234; Tue, 14 Aug 2001 02:40:55 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 4A2D47BA; Tue, 14 Aug 2001 18:37:06 +0900 (JST) To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 14 Aug 2001 11:34:12 +0200. <2cr8ufkmsr.fsf@snout.autonomica.se> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Tue, 14 Aug 2001 18:37:05 +0900 Message-Id: <20010814093706.4A2D47BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I think that such evolution will quickly move from the realm of clear >possibilities to "things that simply will not happen" as the base of >resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. > >Today it would be easy, since the resolver base is small and mostly >based upon various versions of bind9 that will (all?) be upgraded to a >version with AAAA synthesis built in. the observation seems misleading to me. BIND4/8 happily serves AAAA client (over IPv4 UDP/TCP), therefore, the resolver base is already quite big for AAAA. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 03:25:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EAP8X06145 for ipng-dist; Tue, 14 Aug 2001 03:25:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EAObD06123; Tue, 14 Aug 2001 03:24:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08814; Tue, 14 Aug 2001 03:24:35 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20834; Tue, 14 Aug 2001 04:24:45 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7EAOUm07458; Tue, 14 Aug 2001 03:24:30 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7EAOUj03215; Tue, 14 Aug 2001 03:24:30 -0700 Message-Id: <200108141024.f7EAOUj03215@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: johani@autonomica.se Date: Tue, 14 Aug 2001 03:24:30 -0700 (PDT) Cc: alh-ietf@tndh.net (Tony Hain), nathanj@optimo.com.au (Nathan Jones), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <2cr8ufkmsr.fsf@snout.autonomica.se> from "Johan Ihren" at Aug 14, 2001 11:34:12 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % > - It is clear that we could evolve from AAAA to A6 later if % > it became necessary. % % I think that such evolution will quickly move from the realm of clear % possibilities to "things that simply will not happen" as the base of % resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. Lets see, pretty much every resolver "shipped" since 1996 has AAAA support but does not do A4synth. One could infer that this is a fairly large base. % Today it would be easy, since the resolver base is small and mostly % based upon various versions of bind9 that will (all?) be upgraded to a % version with AAAA synthesis built in. This is a much smaller base but might be growing... at least on the server side. Of course, with the "genetic diversity" that is now present, we have a number of suppliers to consider. DJB has stated that he has no intention of supporting either A4synth or A6. % Tomorrow, with a large base of resolvers without that functionality, % anyone who attempts to move from AAAA to A6 will literaly saw off the % branch of the tree he is sitting on (from the perspective of AAAA % on-lookers on the ground). True of the adoption of any new feature. % All I am saying is that I think any attempt att consensus through the % "we can always upgrade later" argument is bound to misfire. Hum... while using this arguement to try and reach consensus may be fraught with danger, the basic premise, that the Internet is evolutionary, e.g. "we can always upgrade later" is a core concept in many peoples minds. Revolutionary techniques, e.g. flag days, non-backward compatability, etc. are much harder to float past the "powers that be". These days, such techniques tend to come from outside, and blindside the PTB, then we all have to scramble to adapt/adopt. e.g. Netscape, RealNetworks, etc. come to mind. % % Johan % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 05:21:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ECKhB06587 for ipng-dist; Tue, 14 Aug 2001 05:20:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ECKcD06580; Tue, 14 Aug 2001 05:20:38 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28885; Tue, 14 Aug 2001 05:20:38 -0700 (PDT) Received: from nara.off.connect.com.au (nara.off.connect.com.au [192.94.41.40]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06060; Tue, 14 Aug 2001 05:20:37 -0700 (PDT) Received: (from njones@localhost) by nara.off.connect.com.au id WAA18612 (8.8.8/IDA-1.7); Tue, 14 Aug 2001 22:19:25 +1000 (EST) Message-ID: <20010814221925.U4458@connect.com.au> Date: Tue, 14 Aug 2001 22:19:25 +1000 From: Nathan Jones To: Bill Manning , johani@autonomica.se Cc: Tony Hain , Nathan Jones , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2cr8ufkmsr.fsf@snout.autonomica.se> <200108141024.f7EAOUj03215@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <200108141024.f7EAOUj03215@zed.isi.edu>; from Bill Manning on Tue, Aug 14, 2001 at 03:24:30AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Aug 14, 2001 at 03:24:30AM -0700, Bill Manning wrote: >% I think that such evolution will quickly move from the realm of clear >% possibilities to "things that simply will not happen" as the base of >% resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. > > Lets see, pretty much every resolver "shipped" since 1996 > has AAAA support but does not do A4synth. One could infer > that this is a fairly large base. A large base of software that handles AAAA, but not necessarily a large base of DNS administrators using AAAA records. Probably the majority of sysadmins have not yet dealt with IPv6. When they start, they will look to standards for guidance. If we leave A6 on the standards track now, it will become natural to use A6. This can drive deployment of resolvers which do AAAA synthesis. By contrast, if we remove A6 from the standards track now, then there is no incentive to implement support for AAAA synthesis. If we then turn around and say "we do need A6 after all", there is little momentum to implement and deploy A6. > Hum... while using this arguement to try and reach consensus > may be fraught with danger, the basic premise, that the Internet > is evolutionary, e.g. "we can always upgrade later" is a > core concept in many peoples minds. While "we can always upgrade later", it seems to me to be odd that we would plan it that way. If 128 bit IP addresses had been specified a year or so after IPv4 came out, would a working group then have said "we probably don't -really- need it - let's deprecate it and encourage 32 bit addresses instead"? Standards are sometimes created but not used. But at least the standard is available if a need arises. A6 is already on the standards track and people want to deprecate it before it has been given a chance. If the specification is not worthy, perhaps the "market" will decide to ignore it, but at least it is available. -- nathanj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 06:11:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EDB2O07241 for ipng-dist; Tue, 14 Aug 2001 06:11:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EDAZD07219; Tue, 14 Aug 2001 06:10:35 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20985; Tue, 14 Aug 2001 06:10:36 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08835; Tue, 14 Aug 2001 06:10:36 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7EDAXm10349; Tue, 14 Aug 2001 06:10:33 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7EDAXH03576; Tue, 14 Aug 2001 06:10:33 -0700 Message-Id: <200108141310.f7EDAXH03576@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: nathanj@optimo.com.au (Nathan Jones) Date: Tue, 14 Aug 2001 06:10:33 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), johani@autonomica.se, alh-ietf@tndh.net (Tony Hain), nathanj@optimo.com.au (Nathan Jones), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <20010814221925.U4458@connect.com.au> from "Nathan Jones" at Aug 14, 2001 10:19:25 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % On Tue, Aug 14, 2001 at 03:24:30AM -0700, Bill Manning wrote: % >% I think that such evolution will quickly move from the realm of clear % >% possibilities to "things that simply will not happen" as the base of % >% resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. % > % > Lets see, pretty much every resolver "shipped" since 1996 % > has AAAA support but does not do A4synth. One could infer % > that this is a fairly large base. % % A large base of software that handles AAAA, but not necessarily a % large base of DNS administrators using AAAA records. Note that Joahn mentioned resolvers and I followed up on that idea. You introduce Humans in the form of sysadmins. % Probably the majority of sysadmins have not yet dealt with IPv6. When % they start, they will look to standards for guidance. If we leave A6 % on the standards track now, it will become natural to use A6. This can % drive deployment of resolvers which do AAAA synthesis. Or they can use AAAA, also on the standards track. (this is the nub of the issue at hand, at least from here) Itojan (sp?) has an excellent draft on the experience of sysadmins who have used both AAAA and A6. The results are instructive. % By contrast, if we remove A6 from the standards track now, then there % is no incentive to implement support for AAAA synthesis. If we then % turn around and say "we do need A6 after all", there is little % momentum to implement and deploy A6. Until it gets put back on the Standards track, like SRV. % A6 is already on the standards track and people want to deprecate it before % it has been given a chance. If the specification is not worthy, perhaps % the "market" will decide to ignore it, but at least it is available. Not depricate, move to a responsible track, for now. % % -- % nathanj % -------------------------------------------------------------------- % IETF IPng Working Group Mailing List % IPng Home Page: http://playground.sun.com/ipng % FTP archive: ftp://playground.sun.com/pub/ipng % Direct all administrative requests to majordomo@sunroof.eng.sun.com % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 06:43:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EDgtA07512 for ipng-dist; Tue, 14 Aug 2001 06:42:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EDgpD07505; Tue, 14 Aug 2001 06:42:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07296; Tue, 14 Aug 2001 06:42:52 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20920; Tue, 14 Aug 2001 06:42:50 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B56A77BA; Tue, 14 Aug 2001 22:37:49 +0900 (JST) To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 14 Aug 2001 15:27:04 +0200. <2cae12lql3.fsf@snout.autonomica.se> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Tue, 14 Aug 2001 22:37:49 +0900 Message-Id: <20010814133749.B56A77BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If we look at DNS configuration for the v6 part of the world it is at >present based upon various kinds of ugliness to get around the fact >that there is almost no hierarchy deployed over v6 transport (starting >with the lack of roots accessible over v6 transport). > >The most common is to use a forwarding configuration to escape over to >the v4 transport universe with full DNS connectivity. > >*All* this will have to change over the coming years if or when or >wherever we decide to start deploying roots accessible over v6 >transport. I don't get your argument at all. Because first part of the IPv6 transition will be toward IPv4/v6 dual stack, AAAA over IPv4 transport works just fine for us. The history proves that it works fine for us - due to the lack of IPv6 accessible root, IPv6 accessible ccTLD/gTLD, and lack of IPv6 NS record registration support by many of the registries, we IPv6 users are forced to rely upon IPv4 DNS infrastructure. Luckily, it works quite well. total transition to AAAA (or A6) over IPv6 transport is of course better, however, it needs a major upgrades, including: - IPv6-ready root - IPv6-ready ccTLD and gTLD - IPv6-ready random .com servers all of them needs to be done before the total transition, so it is unrealistic to talk about total transition this time. So, what I'm saying is, AAAA deployment is already so wide enough (all BIND4/8/9 do support them okay), and for me it is way too late already to transition to anything else (including A6). If we are to transition to something other than AAAA, the transition needs to be coordinated very delicately, like transition from IPv4 to IPv6 and it will take multiple years to do so. We cannot wait any more. Think DNS transport issue (DNS over IPv6, or IPv4) and DNS payload issue (AAAA, A or A6) separately. What we are talking about is mainly the payload issue, though, it affects the deployment of the IPv6 DNS transport (as NS records need to point to AAAA, or A6). I guess you are mixing up these two. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 06:48:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EDm7o07553 for ipng-dist; Tue, 14 Aug 2001 06:48:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EDm3D07546; Tue, 14 Aug 2001 06:48:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20994; Tue, 14 Aug 2001 06:48:05 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (kre.coe.psu.ac.th [202.28.96.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15481; Tue, 14 Aug 2001 07:47:55 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7EDlJb15208; Tue, 14 Aug 2001 20:47:20 +0700 (ICT) From: Robert Elz To: Bill Manning cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108141024.f7EAOUj03215@zed.isi.edu> References: <200108141024.f7EAOUj03215@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 20:47:19 +0700 Message-ID: <15206.997796839@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 14 Aug 2001 03:24:30 -0700 (PDT) From: Bill Manning Message-ID: <200108141024.f7EAOUj03215@zed.isi.edu> | Hum... while using this arguement to try and reach consensus | may be fraught with danger, the basic premise, that the Internet | is evolutionary, e.g. "we can always upgrade later" is a | core concept in many peoples minds. It may be, but they're deluding themselves. The only plausible argument now for ignoring A6, and persisting with AAAA, is the current deployed base, and the difficulty of getting all of it upgraded, and the desire to make IPv6 "real" as soon as possible. If that's an argument to be listened to now, it can only possibly have greater and greater force as time passes and AAAA is deployed more, and used more, than the comparatively trivial amount it is now. The comment in Tony Hain's message: - It is clear that we could evolve from AAAA to A6 later if it became necessary. is not only not clear, it is simply wrong. There's no way to change such a basic part of the infrastructure once it is widely deployed. No way at all. (That is, unless "later" means next month, of course, if it is soon enough, it would still be possible - that is, it needs to happen while the 6bone is still the major long haul IPv6 net, once we have enough real v6 users that we start getting v6 real v6 infrastructure, then the time will have passed). 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 Aug 14 07:18:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEH9307975 for ipng-dist; Tue, 14 Aug 2001 07:17:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEGfD07947; Tue, 14 Aug 2001 07:16:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22863; Tue, 14 Aug 2001 07:16:41 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07502; Tue, 14 Aug 2001 08:16:37 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7EEGbm23851; Tue, 14 Aug 2001 07:16:37 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7EEGbY03659; Tue, 14 Aug 2001 07:16:37 -0700 Message-Id: <200108141416.f7EEGbY03659@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 14 Aug 2001 07:16:37 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <15206.997796839@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at Aug 14, 2001 08:47:19 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % | Hum... while using this arguement to try and reach consensus % | may be fraught with danger, the basic premise, that the Internet % | is evolutionary, e.g. "we can always upgrade later" is a % | core concept in many peoples minds. % % It may be, but they're deluding themselves. % % kre Hogwash. EGP -> BGP RIP -> ISIS/OSPF MB/MG -> MX All upgrades. Works a treat. From this little corner of the world, things look like this: AAAA = stds track A6 = stds track we can do the following: a) move one proposal somewhere else on the standards track b) Leave them where they are. For a), that would mean giving a nodding preference to one, based on some criteria. Certain people seem to be leaning toward one selection based on operational experience, deployed code, and legitimate paranoia that the alternative is operationally problematic. For b) that leave the "market" to decide, leading to operationally problematic state on questionable interoperability. Because I beleive that A6 has enough potential, I'm willing to have it move to experimental, giving developers and operators more time to understand its impact. I think that long term, its benefits will overshadow AAAA and that a migration plan can be deployed. But for now, it needs more work and AAAA meets todays limited requirements. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 07:50:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEnNQ08358 for ipng-dist; Tue, 14 Aug 2001 07:49:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEnJD08351; Tue, 14 Aug 2001 07:49:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19190; Tue, 14 Aug 2001 07:49:19 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18387; Tue, 14 Aug 2001 08:49:26 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7EEmtb15665; Tue, 14 Aug 2001 21:48:55 +0700 (ICT) From: Robert Elz To: Bill Manning cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108141416.f7EEGbY03659@zed.isi.edu> References: <200108141416.f7EEGbY03659@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 21:48:55 +0700 Message-ID: <15663.997800535@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 14 Aug 2001 07:16:37 -0700 (PDT) From: Bill Manning Message-ID: <200108141416.f7EEGbY03659@zed.isi.edu> | Hogwash. EGP -> BGP | RIP -> ISIS/OSPF | MB/MG -> MX | | All upgrades. Works a treat. Hogwash. I'm not exterior routing expert, but aren't EGP/BGP etc, essentially bilateral relationships? That is, as long as two peers agree on what they use, no-one else really cares. I'm sure the conversion (so long ago I bet many people here don't recall EGP) wasn't quite this easy, but it still doesn't involve unrelated paries all deciding that it is time to start doing something different. Interior routing protocols are something within the confines of one organisation, and aren't even vaguelly similar. The last one is the closest, except that MB/MG were never deployed, and even now, mailers still fall back to using A records when there is no MX record (that is, we have no way of indicating "no mail for that domain" which is what we would have had had MX been deployed from the start). This is the closest example, and it is one that illustrates that upgrades don't really work (even after the 12 years since MX was defined, or whatever it is (longer I think)). The only contemporary upgrade that is anything like what changing AAAA to A6 would be, after serious AAAA deployment and use is the conversion to IPv6 from IPv4. Even with all the support it has, that one is not yet certain to actually complete (things are looking good, but it isn't certain by any means). And that's with the motivation behind it that IPv4 simply cannot cope with the net of the future, no matter what frills are added around the edges (2^32 isn't enough to give one address to everyone who needs one). | we can do the following: | | a) move one proposal somewhere else on the standards track You actually mean off the standards track. | Because I beleive that A6 has enough potential, I'm willing | to have it move to experimental, giving developers and | operators more time to understand its impact. I think that | long term, its benefits will overshadow AAAA and that a | migration plan can be deployed. No, assuming you're right, long term what will happen is that people will lament that the wrong decision was made in 2001, but regret that there's no way to transition any more, the combination of resolvers doing only AAAA lookups, and servers providing only AAAA records, means there's no clean way to get out from under (sure, servers could provide A6 records as well, but they'll have to keep providing AAAA records forever to keep the old resolvers happy, and resolvers could do A6 lookups but they'd have to fall back on doing AAAA so they can find names that are only available that way - given that AAAA would have to remain, and resolvers would have to do lookups of it, just for practical reasons, there's no way to actually transition to A6). 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 Aug 14 07:57:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EEvPW08518 for ipng-dist; Tue, 14 Aug 2001 07:57:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEv5D08496; Tue, 14 Aug 2001 07:57:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02459; Tue, 14 Aug 2001 07:57:05 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09687; Tue, 14 Aug 2001 08:57:01 -0600 (MDT) Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15Wfcq-000IEc-00; Tue, 14 Aug 2001 07:57:00 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Nathan Jones Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2cr8ufkmsr.fsf@snout.autonomica.se> <200108141024.f7EAOUj03215@zed.isi.edu> <20010814221925.U4458@connect.com.au> Message-Id: Date: Tue, 14 Aug 2001 07:57:00 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Standards are sometimes created but not used. But at least the > standard is available if a need arises. that is one of the major uses of the experimental class of rfcs, this is not the way we do it today, but if you want to do it, do it this way. then, when we need it, we pull it off experimental to standard track. for example, we are doing this with 2770 now. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 09:14:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EGEAV09219 for ipng-dist; Tue, 14 Aug 2001 09:14:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EGE6D09212 for ; Tue, 14 Aug 2001 09:14:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12515 for ; Tue, 14 Aug 2001 09:14:08 -0700 (PDT) From: stefano.faccin@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18527 for ; Tue, 14 Aug 2001 10:14:04 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7EGE9i07958 for ; Tue, 14 Aug 2001 11:14:09 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 14 Aug 2001 11:14:05 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 14 Aug 2001 11:14:05 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 14 Aug 2001 11:14:01 -0500 Message-ID: <82ECD4351A4A9547957C606034A3CB8D0B01A6@daebe005.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: AAA for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEidVcPaJxdVo5QEdWJUgAIx6TWpQCYvw/w To: , Cc: , , X-OriginalArrivalTime: 14 Aug 2001 16:14:05.0360 (UTC) FILETIME=[23B5B300:01C124DC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7EGE7D09213 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pat, Charlie, I believe that the work on standardizing a protocol that enables the use of AAA to authorize network access for IPv6 nodes is very important and should be started as soon as possible. In fact, I believe that such work item is great enabler for the successful deployment of AAA and IPv6 in commercial networks. However, I'm not so sure whether it should be the AAA WG to take care of such work item or if URP (when/if it becomes a WG) should work on it. According to the discussion on the URP mailing list and the feedback at the URP BOF at IETF 51, it seems to me that this work item would find a better home in URP than in AAA WG. Perhaps we should also hear from URP people to see what they think. Also, I'd like to hear comments from IPNG people to see why the AAA WG is the appropriate home for this work item and what they think about having URP as group handling the work item. Regarding the future work of AAA WG, I hope the WG will not be dismissed since, as Pat suggests, it would be the perfect place for other WG to provide their input for new applications. This would ensure that new applications can be created in a single place even if relevant to issues discussed in other WGs. This would allow some level of coordination, instead of having work done in several separate places with the risk of overlapping efforts and incompatible results. As for the AAA WG charter, if I'm not wrong in the current charter it is written that "The protocol must include attributes in support for IPv6 network access". What this actually mean is not so clear to me, since it can be read in several ways. Can somebody clarify it? Form my point of view, if the AAA WG is still alive after the current specifications are completed, the charter already supports new applications related to IPv6. As an example, applications such as the one proposed at IETF 51 (draft-le-aaa-diameter-mobileipv6-00.txt) should be supported thanks to the above statement. Thanks, Stefano F. -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Saturday, August 11, 2001 9:38 AM To: Perkins Charles (IPRG) Cc: IPng Working Group; AAA Working Group Mailing List Subject: Re: [AAA-WG]: AAA for IPv6 I think that the AAA WG should expand its charter to allow for folks in other WGs looking at using AAA in their application to come forth. Perhaps the AAA WG would be a place for the Diameter application to be created. I am, however, afraid of boiling the ocean, so we need to be very careful in what work items we accept. We do, however, want to make sure that we don't end up with n number of accounting protocols in the IETF (something that is actually happening as I type). So, keeping some order is a good thing. If the WG goes away, it becomes the IESG's responsibility. My 2 cents, PatC On Fri, Aug 10, 2001 at 05:40:31PM -0700, Charlie Perkins wrote: > > Hello folks, > > At the IPv6 meeting in IETF 51, there was a discussion about whether > the AAA working group should consider the possibility of accepting a > work item to standardize a protocol to enable the use of AAA to > authorize network access for IPv6 nodes. The general sense of the > working group seemed quite positive on suggesting that such a thing > would be appropriate. > > I am specifically _not_ asking whether our AAAv6 document should > be considered as a working group document within the AAA working > group. That would be a matter for the AAA working group to consider. > I am only attempting to find out whether the general sense of the > working group is the same as the general sense that was expressed > at IETF 51. If approval is voiced, or at least objections are not > raised, then I will relay the information to the AAA working group. > > Regards, > Charlie P. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 13:43:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EKh0P10117 for ipng-dist; Tue, 14 Aug 2001 13:43:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EKgWD10095; Tue, 14 Aug 2001 13:42:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13013; Tue, 14 Aug 2001 13:42:33 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23458; Tue, 14 Aug 2001 14:42:29 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7EKgUm21518; Tue, 14 Aug 2001 13:42:30 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7EKgUN04104; Tue, 14 Aug 2001 13:42:30 -0700 Message-Id: <200108142042.f7EKgUN04104@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 14 Aug 2001 13:42:30 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <15663.997800535@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at Aug 14, 2001 09:48:55 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % Hogwash. Actually, the correct response here is "Sheep Dip" :) % | we can do the following: % | % | a) move one proposal somewhere else on the standards track % % You actually mean off the standards track. Well, we could do that too. ISIS/OSPF ended up spending -lots- of time at different places on the stds track. For the AAAA/A6 debate that is tabled, I'd rather see one moved off the stds track to experimental. % | Because I beleive that A6 has enough potential, I'm willing % | to have it move to experimental, giving developers and % | operators more time to understand its impact. I think that % | long term, its benefits will overshadow AAAA and that a % | migration plan can be deployed. % % No, assuming you're right, long term what will happen is that people % will lament that the wrong decision was made in 2001, but regret that % there's no way to transition any more, the combination of resolvers % doing only AAAA lookups, and servers providing only AAAA records, means % there's no clean way to get out from under (sure, servers could provide % A6 records as well, but they'll have to keep providing AAAA records % forever to keep the old resolvers happy, and resolvers could do A6 lookups % but they'd have to fall back on doing AAAA so they can find names that % are only available that way - given that AAAA would have to remain, and % resolvers would have to do lookups of it, just for practical reasons, % there's no way to actually transition to A6). Cynic. (nee realist?) % % kre % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 14:59:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ELwUg10369 for ipng-dist; Tue, 14 Aug 2001 14:58:30 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ELwSD10362 for ; Tue, 14 Aug 2001 14:58:29 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ELudM21600 for ipng@sunroof.eng.sun.com; Tue, 14 Aug 2001 14:56:39 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7BEHsD27673 for ; Sat, 11 Aug 2001 07:17:55 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24678 for ; Sat, 11 Aug 2001 07:18:04 -0700 (PDT) From: francis.arts@alcatel.be Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13373 for ; Sat, 11 Aug 2001 07:18:01 -0700 (PDT) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f7BEHu803968 for ; Sat, 11 Aug 2001 16:17:56 +0200 (MET DST) Received: by Bemail06.net.alcatel.be(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C1256AA5.004E8A69 ; Sat, 11 Aug 2001 16:17:52 +0200 X-Lotus-FromDomain: ALCATEL To: ipng@sunroof.eng.sun.com Message-ID: Date: Sat, 11 Aug 2001 16:17:47 +0200 Subject: IPv6 over PPP / ethernet Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a question on the transport of IPv6 over PPP and ethernet interfaces: * IPv6 over PPP: Looking into RFC 2472 I understand that IPv6 and IPv4 packets have a different PPP protocol number. However, are there any implementations that use the same PPP protocol number for IPv4 and IPv6 packets but with a different version number in the IP header? * IPv6 over ethernet: Are there any implementations that use the same ether type number for IPv4 and IPv6 packets but with a different version number in the IP header? Thanks. Francis. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 14:59:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ELwnM10378 for ipng-dist; Tue, 14 Aug 2001 14:58:49 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ELwlD10371 for ; Tue, 14 Aug 2001 14:58:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ELuvp21630 for ipng@sunroof.eng.sun.com; Tue, 14 Aug 2001 14:56:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7BHJoD27924 for ; Sat, 11 Aug 2001 10:19:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11361 for ; Sat, 11 Aug 2001 10:20:01 -0700 (PDT) Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22813 for ; Sat, 11 Aug 2001 11:19:58 -0600 (MDT) Received: from viruswall1.entp.attws.com (viruswall1.entp.attws.com [135.214.40.161]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id KAA08480; Sat, 11 Aug 2001 10:19:23 -0700 (PDT) Received: from neastmail.entp.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc.) id KAA29166; Sat, 11 Aug 2001 10:19:22 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id KAA04666; Sat, 11 Aug 2001 10:19:20 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Sat, 11 Aug 2001 13:19:19 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E5890508697A@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Pat Calhoun'" , Charlie Perkins Cc: IPng Working Group , AAA Working Group Mailing List , "Engelhart, Bob" , "Molchan, John" , "'ileana.leuca@attws.com'" Subject: RE: [AAA-WG]: AAA for IPv6 Date: Sat, 11 Aug 2001 13:19:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pat, I agree with your suggestion that the "AAA WG would be a place for the Diameter application to be created". Consideration is being given in 3GPP SA5 to utilize in several application scenarios that have requirements variations. It would be very helpful to have the AAA WG as a resource to examine the scenario requirements and provide their advice. At least two perspectives of advice are needed: (1) whether it is feasible to use Diameter in a scenario and (2)whether its specific scenario configuration is correct. Other observations and suggestions would, of course, be welcomed by 3GPP SA5. The dissolution of the AAA WG, at this time, would hamper utilization of the Diameter knowledge resource. Hopefully, a dissolution decision will not occur. Thad -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Saturday, August 11, 2001 10:38 AM To: Charlie Perkins Cc: IPng Working Group; AAA Working Group Mailing List Subject: Re: [AAA-WG]: AAA for IPv6 I think that the AAA WG should expand its charter to allow for folks in other WGs looking at using AAA in their application to come forth. Perhaps the AAA WG would be a place for the Diameter application to be created. I am, however, afraid of boiling the ocean, so we need to be very careful in what work items we accept. We do, however, want to make sure that we don't end up with n number of accounting protocols in the IETF (something that is actually happening as I type). So, keeping some order is a good thing. If the WG goes away, it becomes the IESG's responsibility. My 2 cents, PatC On Fri, Aug 10, 2001 at 05:40:31PM -0700, Charlie Perkins wrote: > > Hello folks, > > At the IPv6 meeting in IETF 51, there was a discussion about whether > the AAA working group should consider the possibility of accepting a > work item to standardize a protocol to enable the use of AAA to > authorize network access for IPv6 nodes. The general sense of the > working group seemed quite positive on suggesting that such a thing > would be appropriate. > > I am specifically _not_ asking whether our AAAv6 document should > be considered as a working group document within the AAA working > group. That would be a matter for the AAA working group to consider. > I am only attempting to find out whether the general sense of the > working group is the same as the general sense that was expressed > at IETF 51. If approval is voiced, or at least objections are not > raised, then I will relay the information to the AAA working group. > > Regards, > Charlie P. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 15:00:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ELxN610405 for ipng-dist; Tue, 14 Aug 2001 14:59:23 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ELxLD10392 for ; Tue, 14 Aug 2001 14:59:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ELvVP21660 for ipng@sunroof.eng.sun.com; Tue, 14 Aug 2001 14:57:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E9XwD05922; Tue, 14 Aug 2001 02:33:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28541; Tue, 14 Aug 2001 02:34:09 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11064; Tue, 14 Aug 2001 03:34:04 -0600 (MDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 1A7C91ED08; Tue, 14 Aug 2001 11:34:13 +0200 (CEST) To: "Tony Hain" Cc: "Nathan Jones" , , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: From: Johan Ihren Date: 14 Aug 2001 11:34:12 +0200 In-Reply-To: "Tony Hain"'s message of "Mon, 13 Aug 2001 18:45:26 -0700" Message-ID: <2cr8ufkmsr.fsf@snout.autonomica.se> Lines: 37 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Tony Hain" writes: > Nathan and Bernard have a good start to the summary, in > terms of boiling down the essential viewpoints. The things > I would add from the discussion include: > > - It is clear that we know how to make A6 resolvers deal with > AAAA clients. > - It appears that with current tools A6 reduces the burden of > renumbering on the zone administrator. > - It is not clear that renumbering will occur faster than a > AAAA zone file could be resigned. > - It is clear that we could evolve from AAAA to A6 later if > it became necessary. I think that such evolution will quickly move from the realm of clear possibilities to "things that simply will not happen" as the base of resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. Today it would be easy, since the resolver base is small and mostly based upon various versions of bind9 that will (all?) be upgraded to a version with AAAA synthesis built in. Tomorrow, with a large base of resolvers without that functionality, anyone who attempts to move from AAAA to A6 will literaly saw off the branch of the tree he is sitting on (from the perspective of AAAA on-lookers on the ground). On the other hand, I fully realize the issues with keeping a (mostly unused) code-path of AAAA synthesis around in the resolvers with A6 not on the standards track. All I am saying is that I think any attempt att consensus through the "we can always upgrade later" argument is bound to misfire. Johan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 15:00:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ELxkh10418 for ipng-dist; Tue, 14 Aug 2001 14:59:46 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ELxhD10411 for ; Tue, 14 Aug 2001 14:59:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ELvrl21690 for ipng@sunroof.eng.sun.com; Tue, 14 Aug 2001 14:57:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EDRID07385; Tue, 14 Aug 2001 06:27:18 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16938; Tue, 14 Aug 2001 06:27:17 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06862; Tue, 14 Aug 2001 06:27:15 -0700 (PDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 938611ED08; Tue, 14 Aug 2001 15:27:04 +0200 (CEST) To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010814093706.4A2D47BA@starfruit.itojun.org> From: Johan Ihren Date: 14 Aug 2001 15:27:04 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Tue, 14 Aug 2001 18:37:05 +0900" Message-ID: <2cae12lql3.fsf@snout.autonomica.se> Lines: 51 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino writes: > >I think that such evolution will quickly move from the realm of clear > >possibilities to "things that simply will not happen" as the base of > >resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. > > > >Today it would be easy, since the resolver base is small and mostly > >based upon various versions of bind9 that will (all?) be upgraded to a > >version with AAAA synthesis built in. > > the observation seems misleading to me. BIND4/8 happily serves AAAA > client (over IPv4 UDP/TCP), therefore, the resolver base is already > quite big for AAAA. Ahem. Let me put it this way: If we look at DNS configuration for the v6 part of the world it is at present based upon various kinds of ugliness to get around the fact that there is almost no hierarchy deployed over v6 transport (starting with the lack of roots accessible over v6 transport). The most common is to use a forwarding configuration to escape over to the v4 transport universe with full DNS connectivity. *All* this will have to change over the coming years if or when or wherever we decide to start deploying roots accessible over v6 transport. So, regardless of whether the present numbers of deployed resolvers is large or small (I think it is small compared to what we hope to have in three years, you think it is large compared to what we had three years ago, both positions are fine) it is still not a problem since their configurations will all change when v6 roots appear. However, the point of v6 root deployment is the *only* time in IPv6 history that we will be able to make such a change (push a configuration change like AAAA synthesis into all corners) which is one of several reasons why we should be (and are) so very careful before introducing v6 glue for the roots. When I talked about experimental deployment of v6 roots during dnsop in Minneapolis I was clearly overly optimistic about the timeframe. And while the A6 vs AAAA issue has been one reason for delay it is not the only concern. Johan PS. On the other hand, I do understand your argument about old bind4/8 serving AAAA over v4 transport. And, yes, the consequence is that clients on the IPv4 Internet will not find the AAAAddresses of whatever they are trying to lookup. No one said this was easy. DS. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 15:00:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EM05t10427 for ipng-dist; Tue, 14 Aug 2001 15:00:05 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EM01D10420 for ; Tue, 14 Aug 2001 15:00:02 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ELwBJ21720 for ipng@sunroof.eng.sun.com; Tue, 14 Aug 2001 14:58:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EEHvD07991; Tue, 14 Aug 2001 07:17:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24443; Tue, 14 Aug 2001 07:17:57 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05992; Tue, 14 Aug 2001 07:17:55 -0700 (PDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 2FC211ED08; Tue, 14 Aug 2001 16:17:41 +0200 (CEST) To: Bill Manning Cc: nathanj@optimo.com.au (Nathan Jones), alh-ietf@tndh.net (Tony Hain), ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <200108141310.f7EDAXH03576@zed.isi.edu> From: Johan Ihren Date: 14 Aug 2001 16:17:41 +0200 In-Reply-To: Bill Manning's message of "Tue, 14 Aug 2001 06:10:33 -0700 (PDT)" Message-ID: <2c66bqlo8q.fsf@snout.autonomica.se> Lines: 72 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Manning writes: > % > % On Tue, Aug 14, 2001 at 03:24:30AM -0700, Bill Manning wrote: > % >% I think that such evolution will quickly move from the realm of clear > % >% possibilities to "things that simply will not happen" as the base of > % >% resolvers that serve AAAA clients but doesn't do AAAA synthesis grows. > % > > % > Lets see, pretty much every resolver "shipped" since 1996 > % > has AAAA support but does not do A4synth. One could infer > % > that this is a fairly large base. > % > % A large base of software that handles AAAA, but not necessarily a > % large base of DNS administrators using AAAA records. > > Note that Joahn mentioned resolvers and I followed up > on that idea. You introduce Humans in the form of sysadmins. Oops. Let's be careful with our terminology. "Resolver", to me, denotes a full-service DNS client, like the part of a recursive server that does lookups, and possibly follows A6 chains and such strange things. "Stub resolver" denotes a bare-bones subset of the resolver that is present as part of an application. I've been exclusively discussing full-service resolvers, since I believe that AAAA synthesis (in the local caching resolver aka name server) is the right solution to (among other things) the problem of *not* having to upgrade all the deployed and implemented *stub resolvers*. > % Probably the majority of sysadmins have not yet dealt with IPv6. When > % they start, they will look to standards for guidance. If we leave A6 > % on the standards track now, it will become natural to use A6. This can > % drive deployment of resolvers which do AAAA synthesis. > > Or they can use AAAA, also on the standards track. > (this is the nub of the issue at hand, at least from here) > Itojan (sp?) has an excellent draft on the experience > of sysadmins who have used both AAAA and A6. The results > are instructive. ...but it should be mentioned that many of the issues Itojun discusses are relative to implementing A6 in *stub resolvers*, which is not what I am arguing for. Another part of the document decribes various (fully valid) worries about timeouts and delays etc due to following long A6 chains that extend beyond the organizational border into the unknown territory of the ISP and beyond (above?). I think that this is perhaps not the only perspective since a clueful leaf node is not the main problem here. A possibly more interesting perspective would be that of a clueful central organisation with lots of delegated prefixes in various directions. I also think that perspective is posibly more valid, since statistically the amount of clue goes down as you move down the delegation chain. The problem then becomes one of "how do I propagate this need to change the prefix" recursively down all these delegations and into whatever tools and scripts they have decided to use for zone management and no longer even know how they work. With A6 this particular sub-part of the renumbering problem becomes a non-issue. Not so with AAAA. Not even close. Johan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 15:01:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EM0P110446 for ipng-dist; Tue, 14 Aug 2001 15:00:25 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EM0KD10433 for ; Tue, 14 Aug 2001 15:00:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7ELwUV21750 for ipng@sunroof.eng.sun.com; Tue, 14 Aug 2001 14:58:30 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EIUED09970 for ; Tue, 14 Aug 2001 11:30:14 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21836 for ; Tue, 14 Aug 2001 11:30:14 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12447 for ; Tue, 14 Aug 2001 11:30:13 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA04884; Tue, 14 Aug 2001 11:23:09 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 14 Aug 2001 11:23:09 -0700 (PDT) From: Bernard Aboba To: stefano.faccin@nokia.com cc: pcalhoun@diameter.org, charliep@iprg.nokia.com, aaa-wg@merit.edu, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <82ECD4351A4A9547957C606034A3CB8D0B01A6@daebe005.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As for the AAA WG charter, if I'm not wrong in the current charter it is > written that "The protocol must include attributes in support for IPv6 > network access". What this actually mean is not so clear to me, since it > can be read in several ways. Can somebody clarify it? The current charter refers to enabling IPv6 network access in conventional NAS applications (e.g. PPPv6). Since Mobile IPv6 work was not complete at the time the original requirements work was done, AAA for MIPv6 was not included in the charter. In general, addition of a AAA WG charter item for MIPv6 is only appropriate when the appropriate subject area WGs have completed their work. So work on the authentication architecture for MIPv6 needs to occur outside AAA WG where the appropriate subject matter experts reside. Once those experts have reached consensus and produced a document, the AAA WG can consider that document as input. This process ensures proper coordination between the AAA WG and subject area WGs. So a AAA WG work item for MIPv6 is dependent on progress within the BURP and MIPv6 communities. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 15:51:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7EMonA10598 for ipng-dist; Tue, 14 Aug 2001 15:50:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7EMojD10591 for ; Tue, 14 Aug 2001 15:50:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11679 for ; Tue, 14 Aug 2001 15:50:46 -0700 (PDT) From: stefano.faccin@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09178 for ; Tue, 14 Aug 2001 16:50:57 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7EMpkI20442 for ; Tue, 14 Aug 2001 17:51:46 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 14 Aug 2001 17:50:43 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 14 Aug 2001 17:50:47 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 14 Aug 2001 17:50:39 -0500 Message-ID: <82ECD4351A4A9547957C606034A3CB8D0B01A8@daebe005.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: AAA for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEk7yL2T2g6+JDhEdWpVgBQi2kYTQADSopA To: Cc: , , X-OriginalArrivalTime: 14 Aug 2001 22:50:47.0073 (UTC) FILETIME=[8EA2E110:01C12513] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7EMokD10592 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bernard, thanks for your answer and the clarification. I agree that the application for the Mobile IPv6 specific case is dependent on the work in URP, since a protocol between the MN and the network needs to be defined to support the authorization and authentication (and optionally other features) of the IPv6 node. It is exactly for this reason that I suggested that the correct home for the work item proposed by Charlie (related to AAAv6) would be URP and not AAA WG. I would also add that if positive progress happens in URP, URP may indicate AAA WG the need for such an application. I also understand your concern about the relation between new applications and protocols defined in other WGs that have not been closed completely yet. However, the issues under discussion in MIPv6 do not impact the MIPv6 application proposed in the draft draft-le-aaa-diameter-mobileipv6-00.txt. In fact, unless the protocol is heavily modified besides the aspects for security of BUs (quite improbable), the draft for the MIPv6 application still applies. For this reason, I believe the group can still start working on such application. Moreover, I believe the title of the draft may be misleading and for this reason is going to be changed and the draft re-submitted. In fact, the draft applies in general to the support through the AAA Diameter infrastructure of authorization of network access for IPv6 nodes, authentication of the IPv6 node and key distribution for the IPv6 node. In addition, if the node happens to be a Mobile IPv6 node, support of mobility can be provided. For these reasons, the draft is not directly dependent on the fate of Mobile IPv6, and from your description of the charter I believe it applies to the AAA WG. Stefano F. -----Original Message----- From: ext Bernard Aboba [mailto:aboba@internaut.com] Sent: Tuesday, August 14, 2001 1:23 PM To: Faccin Stefano (NRC/Dallas) Cc: pcalhoun@diameter.org; Perkins Charles (IPRG); aaa-wg@merit.edu; ipng@sunroof.eng.sun.com; urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 > As for the AAA WG charter, if I'm not wrong in the current charter it is > written that "The protocol must include attributes in support for IPv6 > network access". What this actually mean is not so clear to me, since it > can be read in several ways. Can somebody clarify it? The current charter refers to enabling IPv6 network access in conventional NAS applications (e.g. PPPv6). Since Mobile IPv6 work was not complete at the time the original requirements work was done, AAA for MIPv6 was not included in the charter. In general, addition of a AAA WG charter item for MIPv6 is only appropriate when the appropriate subject area WGs have completed their work. So work on the authentication architecture for MIPv6 needs to occur outside AAA WG where the appropriate subject matter experts reside. Once those experts have reached consensus and produced a document, the AAA WG can consider that document as input. This process ensures proper coordination between the AAA WG and subject area WGs. So a AAA WG work item for MIPv6 is dependent on progress within the BURP and MIPv6 communities. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 16:42:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7ENfTJ10685 for ipng-dist; Tue, 14 Aug 2001 16:41:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7ENfPD10678 for ; Tue, 14 Aug 2001 16:41:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12304 for ; Tue, 14 Aug 2001 16:41:26 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA06182 for ; Tue, 14 Aug 2001 17:41:36 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id AAA11008; Wed, 15 Aug 2001 00:41:22 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id AAA41156; Wed, 15 Aug 2001 00:41:21 +0100 Message-ID: <3B79B74B.8A153CDF@hursley.ibm.com> Date: Tue, 14 Aug 2001 18:42:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta CC: ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <3B794BF4.7319CCDE@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Subject: Re: draft-conta-ipv6-flow-label-02.txt > Date: Fri, 10 Aug 2001 18:33:54 +0900 > From: Jun-ichiro itojun Hagino > To: ipng@sunroof.eng.sun.com > > > with many of the diffserv-oriented encoding, there are possibilities > > for routers to get tricked by originating nodes, leading to theft of > > traffic and/or simple kernel panic (if we put header length into flow > > label field, and if your router is careless - if you are careful you > > are not speeding things up and there's no meaning in embedding > > header length into flow label field). > > also, if you are going to rewrite the field for the sake of diffserv, > why don't you use traffic class field (6bit)? I didn't see this until today because some daemon threw me off the mailing list... The traffic class field is not enough. If you have to re-classify traffic at an administrative boundary, then by definition at that point the traffic class field is inadequate; you need more information. The advantage that IPv6 has is that even when the header is partly hidden by IPSEC, the flow label is available to carry additional semantics. The actual proposal is to use the PHB identifier which has end to end semantics. 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 Aug 14 17:07:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7F06uo10710 for ipng-dist; Tue, 14 Aug 2001 17:06:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F06qD10703 for ; Tue, 14 Aug 2001 17:06:52 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25642 for ; Tue, 14 Aug 2001 17:06:53 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21843 for ; Tue, 14 Aug 2001 17:06:52 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7F06Nl85704; Tue, 14 Aug 2001 20:06:23 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7F06MX66955; Tue, 14 Aug 2001 20:06:22 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id UAA07602; Tue, 14 Aug 2001 20:06:22 -0400 (EDT) Message-Id: <200108150006.UAA07602@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian E Carpenter cc: Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] In-reply-to: Your message of "Tue, 14 Aug 2001 18:42:03 CDT." <3B79B74B.8A153CDF@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 14 Aug 2001 20:06:22 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter wrote: > The traffic class field is not enough. If you have to re-classify traffic at > an administrative boundary, then by definition at that point the traffic class > field is inadequate; you need more information. The advantage that IPv6 has > is that even when the header is partly hidden by IPSEC, the flow label is > available to carry additional semantics. The actual proposal is to use the > PHB identifier which has end to end semantics. Brian, The counter argument against putting port information in the flow label is that it gives the application the incentive to lie (by putting bogus information in the flow label), without the impact of breaking the receiver's port demultiplexing. The counter argument against putting the PHB id in the flow label is that it is irrelevant: the way PHBs have been defined has virtually no relationship to any application QoS performance parameters, and furthermore, the downstream network usually couldn't care less what the application desires. If I am reclassifying traffic at an administrative boundary then by definition I don't care about or trust the "QoS information" in the packet as anything more than a hint which I am free to ignore (depending on the TCS I have with the upstream network). When crossing security boundaries the only field which I am reasonably safe to trust is the destination address. Protocol/port filtering only makes sense within an enterprise network or at the access provider's edge. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 14 22:49:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7F5n8m11566 for ipng-dist; Tue, 14 Aug 2001 22:49:08 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F5n3D11559; Tue, 14 Aug 2001 22:49:03 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-12.EBay.Sun.COM [129.150.4.12]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F5n5g118805; Tue, 14 Aug 2001 22:49:05 -0700 (PDT) Message-Id: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 Aug 2001 22:55:37 -0700 To: Robert Elz From: Alain Durand Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org In-Reply-To: <15663.997800535@brandenburg.cs.mu.OZ.AU> References: <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:48 PM 8/14/2001 +0700, Robert Elz wrote: > >No, assuming you're right, long term what will happen is that people >will lament that the wrong decision was made in 2001, but regret that >there's no way to transition any more, the combination of resolvers >doing only AAAA lookups, and servers providing only AAAA records, means >there's no clean way to get out from under (sure, servers could provide >A6 records as well, but they'll have to keep providing AAAA records >forever to keep the old resolvers happy, and resolvers could do A6 lookups >but they'd have to fall back on doing AAAA so they can find names that >are only available that way - given that AAAA would have to remain, and >resolvers would have to do lookups of it, just for practical reasons, >there's no way to actually transition to A6). Doing AAAA synthesis at the resolver side helps a stub resolver that knows only about AAAA to get data from servers that knows only about A6. This transition scenario will work if we can upgrade the resolvers at the same time we introduce A6 in the servers. (note that upgrading the resolvers is a much simpler task than upgrading all the stub resolvers) Still, it may not be possible to upgrade them all before we introduce A6 in some servers. So what you are highlighting is the need for servers that are populated with A6 to answer resolvers (not stub-resolver) that know only about AAAA. Of course, as you mentioned, servers could be manually populated with AAAA at well as A6, but there are other possibilities. In other words, we have to explore AAAA synthesis done at the server side: - the server could automatically generate all the corresponding AAAA records when loading its A6 database. Of course, the missing pieces will have to be provided. - the server could generate AAAA on request. Of course, there are drawbacks and issues with such mechanisms and more study will have to be made to understand them, but they are transition mechanism and as such, do not need to be perfect. The point i'm trying to make is that by combining AAAA synthesis at the server side with AAAA synthesis at the resolver side, we may have a way to transition from an all AAAA world to a world with a mix of AAAA and A6 if/when we need it. Note also that such techniques would have to be used now if we decided to move to A6 today. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 22:59:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7F5wrp11602 for ipng-dist; Tue, 14 Aug 2001 22:58:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F5wmD11595 for ; Tue, 14 Aug 2001 22:58:48 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25339 for ; Tue, 14 Aug 2001 22:58:51 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07128 for ; Tue, 14 Aug 2001 22:58:48 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D792D7BB; Wed, 15 Aug 2001 14:52:07 +0900 (JST) To: francis.arts@alcatel.be Cc: ipng@sunroof.eng.sun.com In-reply-to: francis.arts's message of Sat, 11 Aug 2001 16:17:47 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 over PPP / ethernet From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 14:52:07 +0900 Message-Id: <20010815055207.D792D7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I have a question on the transport of IPv6 over PPP and ethernet interfaces: > >* IPv6 over PPP: Looking into RFC 2472 I understand that IPv6 and >IPv4 packets have a different PPP protocol number. However, are >there any implementations that use the same PPP protocol number >for IPv4 and IPv6 packets but with a different version number >in the IP header? > >* IPv6 over ethernet: Are there any implementations that use the >same ether type number for IPv4 and IPv6 packets but with a different >version number in the IP header? I guess noone is doing that, for both questions. if someone did that, they won't interoperate with others. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 23:08:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7F67T511654 for ipng-dist; Tue, 14 Aug 2001 23:07:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F67PD11647 for ; Tue, 14 Aug 2001 23:07:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12292 for ; Tue, 14 Aug 2001 23:07:28 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA27276 for ; Wed, 15 Aug 2001 00:07:40 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7F6B3G00639 for ; Wed, 15 Aug 2001 09:11:03 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 15 Aug 2001 09:07:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVTJVC>; Wed, 15 Aug 2001 09:07:22 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094175@esebe004.NOE.Nokia.com> To: aboba@internaut.com, stefano.faccin@nokia.com Cc: aaa-wg@merit.edu, deering@cisco.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Wed, 15 Aug 2001 09:07:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bernard, RE: AAAv6 draft > Has this draft been presented within the IPNG WG? Since IPv6 > architecture occurs within IPNG WG, the proposed IPv6/AAA > authentication architecture would need to be presented and > gain consensus within the IPNG WG before a AAA WG work item > could be considered. Charlie Perkins presented the AAAv6 draft he has been writing to the IPNG WG. There seemed to be general consensus that this was good work (in general) and be persued. It seemed to the group that IPNG WG was not the best place for this, but the AAA could be one possibility. Erik Nordmark also suggested that URP could be another home. Of course, if I have mis-interpreted the consensus, I' sure someone (Steve?) could correct me. I'm in favor of this going forward. I think that no official decision has been made on URP (whether or not it is to be a WG) - perhaps the Area Directors & Work Group chairs could discuss where the best place for this work is. best regards, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 14 23:28:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7F6RYl11728 for ipng-dist; Tue, 14 Aug 2001 23:27:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F6RTD11721 for ; Tue, 14 Aug 2001 23:27:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16658 for ; Tue, 14 Aug 2001 23:27:32 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA06444 for ; Wed, 15 Aug 2001 00:27:41 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C7AAF7BA; Wed, 15 Aug 2001 15:20:38 +0900 (JST) To: Brian E Carpenter Cc: Alex Conta , ipng@sunroof.eng.sun.com In-reply-to: brian's message of Tue, 14 Aug 2001 18:42:03 EST. <3B79B74B.8A153CDF@hursley.ibm.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: [Fwd: draft-conta-ipv6-flow-label-02.txt] From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 15:20:38 +0900 Message-Id: <20010815062038.C7AAF7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The traffic class field is not enough. If you have to re-classify traffic at >an administrative boundary, then by definition at that point the traffic class >field is inadequate; you need more information. The advantage that IPv6 has >is that even when the header is partly hidden by IPSEC, the flow label is >available to carry additional semantics. The actual proposal is to use the >PHB identifier which has end to end semantics. I heard the presentation differently. in IETF51 presentation Alex Conta made the following proposals, at least: - putting PHB value not trustworthy. - putting total extension header length if the originator lies about the value, intermediate routers can go panic. - putting port/addr/whatever encoded if the originator lies about the value, theft-of-service happens. none of these values are trustworthy, since originator can lie about those. because these values are not trustworthy, intermediate routers need to get those values by normal ways (by chasing extension header chain, or whatevr), and therefore, flow label value is just wasted. I particularly don't like the idea of putting total extension header length. as soon as it gets deployed bad guys can mount various attacks. So, back to my original posting, I vote for end-to-end pseudorandom 20bit value. intermediate router MAY use it to hash the traffic, that's all. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 00:41:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7F7ed111800 for ipng-dist; Wed, 15 Aug 2001 00:40:39 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F7eZD11793 for ; Wed, 15 Aug 2001 00:40:35 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12430; Wed, 15 Aug 2001 03:40:36 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f7F7dx023964; Wed, 15 Aug 2001 03:39:59 -0400 (EDT) Message-Id: <200108150739.f7F7dx023964@thunk.east.sun.com> From: Bill Sommerfeld To: Steve Blake cc: Brian E Carpenter , Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] In-reply-to: Your message of "Tue, 14 Aug 2001 20:06:22 EDT." <200108150006.UAA07602@castillo.torrentnet.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 15 Aug 2001 03:39:59 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If I am reclassifying traffic at an administrative boundary then by > definition I don't care about or trust the "QoS information" in the > packet as anything more than a hint which I am free to ignore (depending > on the TCS I have with the upstream network). When crossing security > boundaries the only field which I am reasonably safe to trust is the > destination address. yes, exactly. there's no point in putting cleartext port numbers in headers; moreover, even if they were somehow required to transit the network, there would be a strong incentive for cooperating IPsec implementations to include deliberately incorrect port numbers to reduce the amount of information available for traffic analysis. So, I'm afraid that in the long run any "cleartext port numbers" field would have to be treated at administrative boundaries with the same level of suspicion as the diffserv code point.. > Protocol/port filtering only makes sense within an enterprise > network or at the access provider's edge. And it only makes sense at the access provider's edge if the customer is silly enough to send traffic in the clear.. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 02:06:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7F95XF11933 for ipng-dist; Wed, 15 Aug 2001 02:05:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F95TD11926; Wed, 15 Aug 2001 02:05:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29700; Wed, 15 Aug 2001 02:05:31 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29768; Wed, 15 Aug 2001 03:05:26 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 742B37BA; Wed, 15 Aug 2001 17:57:32 +0900 (JST) To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 15 Aug 2001 09:34:23 +0200. <2czo91kc8w.fsf@snout.autonomica.se> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 17:57:32 +0900 Message-Id: <20010815085732.742B37BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'm pointing out that due to the configuration change that will follow >from deployment of v6 roots it will be comparatively easy to reach all >the caching resolvers (i.e. name servers) on v6 transport to ensure >that they all do AAAA synthesis. isn't it just a root.hint change, not a server replacement? as I have pointed out repeatedly, AAAA synthesis has its own problems and I don't feel like deploying it. (1) A6 chasing is traffic multiplication = DoS possibility (recursive servers), (2) it is unclear as to how will be doing AAAA synthesis, and we cannot ensure that it will happen at the leaf (3) by deploying AAAA synthesis you end up maintaining both A6 and AAAA: (3a) impose lookup delays to IPv6 clients. (3b) server admins need to maintain both A6 and AAAA in zoen file, which is unhappy. >However, while agreeing that the deployed base of AAAA-aware caching >resolvers on the IPv4-only Internet is large it is less clear to me >how many of those actually care about v6 address records at all. Nor >is it clear how many of those that will start to care before having >upgraded their name server software (which contrary to popular belief >actually happens, although certainly not to all of them). a lot of them do care about AAAA records, since IPv6 people are forced to use IPv4 infrastructure. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 02:16:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7F9GM311973 for ipng-dist; Wed, 15 Aug 2001 02:16:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F9GJD11966 for ; Wed, 15 Aug 2001 02:16:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19119 for ; Wed, 15 Aug 2001 02:16:01 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14080 for ; Wed, 15 Aug 2001 02:15:57 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 451A417A2; Wed, 15 Aug 2001 02:15:57 -0700 (PDT) Date: Wed, 15 Aug 2001 02:15:57 -0700 From: David Terrell To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010815021556.A20597@pianosa.catch22.org> Reply-To: David Terrell References: <200108090105.VAA18362@astro.cs.utk.edu> <200108091210.f79CAWu76993@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200108091210.f79CAWu76993@givry.rennes.enst-bretagne.fr>; from Francis.Dupont@enst-bretagne.fr on Thu, Aug 09, 2001 at 02:10:32PM +0200 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 2:13AM up 25 days, 4:52, 30 users, load averages: 0.11, 0.13, 0.15 X-Baby: Theodore Marvin Wolpinsky Terrell born 168 days, 11 hours, 27 minutes, 26 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Aug 09, 2001 at 02:10:32PM +0200, Francis Dupont wrote: > In your previous mail you wrote: > > But you make a good point about security. If people get the idea > (correctly or not) that they're sacrificing security by supporting v6, > they won't bother deploying it. We need to have v6 border routers > that deliver the same degree of security as NATs do, without actually > translating addresses. > > => this is easy for TCP (or any connected transport, cf the tcp > established of Cisco routers) but I can't see a way to do this for > UDP without keeping state... Of course this argument doesn't apply > if a real firewall is used (stateless firewalls are out of the market > or should be ASAP). Site local scope and multi-addressing of nodes makes this fairly trivial. If services that should only be available at a site local level are only bound to site-local scope and border routers properly enforce that, then there's no problem. You don't need to filter incoming UDP if nobody's running a UDP listener on a global address. This makes IPv6 every bit as 'secure' as NAPT, and without the kind of ugly application proxies needed for protocols like FTP, H.323, IRC DCC, and others. -- David Terrell | "When we said that you needed to cut the dbt@meat.net | wires for ultimate security, we didn't Nebcorp Prime Minister | mean that you should go wireless instead." http://wwn.nebcorp.com/ | - Casper Dik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 03:02:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FA1WV12078 for ipng-dist; Wed, 15 Aug 2001 03:01:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FA1DD12059; Wed, 15 Aug 2001 03:01:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02143; Wed, 15 Aug 2001 03:01:13 -0700 (PDT) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA28842; Wed, 15 Aug 2001 04:01:21 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id f7FA0rh00531; Wed, 15 Aug 2001 17:00:53 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7FA0iG02363; Wed, 15 Aug 2001 17:00:46 +0700 (ICT) From: Robert Elz To: Alain Durand cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2001 17:00:43 +0700 Message-ID: <2361.997869643@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 14 Aug 2001 22:55:37 -0700 From: Alain Durand Message-ID: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> | Doing AAAA synthesis at the resolver side helps a stub resolver that | knows only about AAAA to get data from servers that knows only about A6. yes, sure. | This transition scenario will work if we can upgrade the resolvers | at the same time we introduce A6 in the servers. (note that upgrading | the resolvers is a much simpler task than upgrading all the stub resolvers) It would work if we did it now. There's no way we can ever upgrade all the resolvers (the real resolvers, the back ends) once IPv6 becomes mainstream. Just imagine now that you wanted to upgrade all the IPv4 resolvers (back end resolvers) - there's simply no way. When IPv6 starts being deployed the net will be able to grow faster than it has, it is going to be lots bigger 5 years from now than it is now. Upgrading anything that requires everyone to upgrade anything at all will simply be impossible. | Still, it may not be possible to upgrade them all before we introduce A6 | in some servers. Actually, it would probably be easier the other way. Adding anything in zone files requires deliberate administrator effort. People will only do that if there's a benefit. On the other hand, AAAA synthesis can be slipped in along with other changes in back end resolvers, so that people (some people) would have it without really even realising it. Some people have it now without realising it... But there's no way to get everyone to have it - which means that administrators will always have to add AAAA records so those people can find their web server, mail server, .... And if AAAA records have to exist, and resolvers will be looking for them (because no way are all servers going to start supplying A6 all at once, even with a fairly broad concept of the time quantum) then there's no point adding A6 records at all - they'd be just one more thing that has to be maintained (excess duplicate data). Further, they wouldn't help do anything, as the AAAA records are still all going to be there. If there's a problem that A6 would be useful to solve, then what will happen is that people will find some hack that allows it to be solved using AAAA instead, as AAAA will be what exists. If you want examples of this, look at Mobile IP - which has a whole mechanism all created, with packet forwarding via home agents, and stuff, all because there's simply no way to upgrade TCP stacks to allow the identifier of a connection to be changed (not even with enough security added to make the change secure). Not even given that only major servers really would need that upgrade (and mobile nodes of course, which need upgraded code anyway). Rather than upgrading TCP, we invent a hack to work around the fact that TCP simply cannot be upgraded. Or, look at IDN, which is doing obscene things to the DNS, to work around the fact that it is impossible to upgrade all the old mailers (etc) to handle arbitrary (non-ascii) domain names. Rather than fix the problem where it ought to be fixed, hacks are done in other places - because there is simply no practical way to get the upgrade done that people are willing to live with (me: I'd just break all the old mailers, etc, and tell people to upgrade if they'll ever receive/send mail to a domain with a non-ascii name, but most people aren't willing to do that). | So what you are highlighting is the need for servers | that are populated with A6 to answer resolvers (not stub-resolver) | that know only about AAAA. No. What I was highlighting is that if AAAA is nominated now as the way that we go, then AAAA is it for eternity. Pretending that we might sometime later upgrade to A6 if it seemed to be a better idea is no more than an attempt to handle people who think "A6 probably is better, but it isn't deployed yet - let's go with what we have now so we can make it happen, then we'll upgrade later". Pretend that the upgrade can happen, and selecting AAAA now doesn't seem so bad. It cannot happen - net wide infrastructure upgrades are close to impossible (for them to be even worth considering, the rationale has to be more than compelling, there must be no other choice - for A6, or mobile IP, or IDN, or anything else like that, there's always going to be some other way than the right way). | Of course, as you mentioned, servers could be manually populated with AAAA | at well as A6, but there are other possibilities. In other words, we have | to explore AAAA synthesis done at the server side: If we were to make the change now, then yes, that's exactly what we should be doing. Now there isn't enough deployment to make it all that hard. For the next 6 months or so (maybe even longer if IPv6 takeup remains slow) we'll still have that option. But not much further away. | - the server could automatically generate all the corresponding AAAA records | when loading its A6 database. Yes. I'd actually thought of making a hack to bind9 that would convert all AAAA records into A6 0, and supplying only A6 whatever the admin configured into the zone file... | The point i'm trying to make is that by combining AAAA synthesis | at the server side with AAAA synthesis at the resolver side, we | may have a way to transition from an all AAAA world to a world | with a mix of AAAA and A6 if/when we need it. We have a way to do it now, or soon. There's no way that it can ever be made to happen once we get wide deployment. Expecting it is just fantasy. eg: now the DNS has SRV records, they do so everything that MX can do, and more. In a way they're the analog of A6 and AAAA (MX is a subset of SRV). There would be benefits to converting SMTP to use SRV instead of MX. Can you imagine anyone seriously suggesting that that happen however? Can you really imagine that there'd ever be a day when we could deprecate the MX record? | Note also that such techniques would have to be used now if we decided | to move to A6 today. Yes, sure. Though it is also possible that AAAA synthesis would never be a transition technique, but rather a permanent part of the way things work (even if we decided that we wanted to move away from it, and there probably wouldn't be much reason, there'd be no way to ever upgrade all the clients, so back end resolvers would always need to provide it, so new clients may as well just use the service that they know will be there...) 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 Aug 15 03:18:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FAHN212124 for ipng-dist; Wed, 15 Aug 2001 03:17:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FAHID12117; Wed, 15 Aug 2001 03:17:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04502; Wed, 15 Aug 2001 03:17:17 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28779; Wed, 15 Aug 2001 04:17:13 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 480907BA; Wed, 15 Aug 2001 19:08:52 +0900 (JST) To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 15 Aug 2001 11:57:01 +0200. <2cpu9xk5n6.fsf@snout.autonomica.se> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 19:08:52 +0900 Message-Id: <20010815100852.480907BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >I'm pointing out that due to the configuration change that will follow >> >from deployment of v6 roots it will be comparatively easy to reach all >> >the caching resolvers (i.e. name servers) on v6 transport to ensure >> >that they all do AAAA synthesis. >> isn't it just a root.hint change, not a server replacement? >Well, if you are running in a forwarding configuration *with your >present server* and replace the root.hint file with one that includes >v6 glue for one or several roots not much will happen. So there is no >point to it. > >Because you are using a forwarding configuration. I don't understand what you are saying, AT ALL. I'm not using forwarding configuration. you must have some assumption in your head which is not presented here. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 03:22:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FALfZ12161 for ipng-dist; Wed, 15 Aug 2001 03:21:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FALbD12154; Wed, 15 Aug 2001 03:21:37 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA03887; Wed, 15 Aug 2001 03:21:36 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28388; Wed, 15 Aug 2001 03:21:35 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 3582B17F5; Wed, 15 Aug 2001 03:21:35 -0700 (PDT) Date: Wed, 15 Aug 2001 03:21:35 -0700 From: David Terrell To: Robert Elz Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010815032134.A1896@pianosa.catch22.org> Reply-To: David Terrell References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <2361.997869643@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <2361.997869643@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Wed, Aug 15, 2001 at 05:00:43PM +0700 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 3:08AM up 25 days, 5:46, 31 users, load averages: 0.15, 0.18, 0.11 X-Baby: Theodore Marvin Wolpinsky Terrell born 168 days, 12 hours, 22 minutes, 4 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Aug 15, 2001 at 05:00:43PM +0700, Robert Elz wrote: > | Still, it may not be possible to upgrade them all before we introduce A6 > | in some servers. > > Actually, it would probably be easier the other way. Adding > anything in zone files requires deliberate administrator effort. > People will only do that if there's a benefit. On the other hand, > AAAA synthesis can be slipped in along with other changes in back > end resolvers, so that people (some people) would have it without > really even realising it. Some people have it now without realising > it... > But there's no way to get everyone to have it - which means that > administrators will always have to add AAAA records so those people > can find their web server, mail server, .... And if AAAA records > have to exist, and resolvers will be looking for them (because no > way are all servers going to start supplying A6 all at once, even > with a fairly broad concept of the time quantum) then there's no > point adding A6 records at all - they'd be just one more thing that > has to be maintained (excess duplicate data). There's no reason why it can't be a gradual upgrade. Authoritative servers for zones with A6 can do AAAA synthesis at query time just as easily as the local non-stub resolver can. It becomes a server-side indirection mechanism, which is available to A6-grokking caches. Considering that like it or not A) BIND is still a majority of nameservers, B) bind9 is the first version to support v6 transport and C) I don't imagine Nominum/ISC/"The BIND Company" removing A6 support just because it's not "the thing", this feature is basically already present today. ISPs can provide A6 prefix records for their customers, those customers can use A6 chains to point to their ISPs and do authoritative server-side AAAA synthesis (well, ok, bind needs to add this I guess), and most people can go on using AAAA and be happy. I'm squarely in the "Let's take AAAA because it works and let's get IPv6 off the ground" camp. -- David Terrell | p = "you are nasty" q = "my first name is Janet" Nebcorp PM | r = "my first name is baby" s = "My name is Miss Jackson" dbt@meat.net | (!r -> q) & (p -> s) - Braverman's Third Lemma wwn.nebcorp.com | !r & (!p -> q) & (p -> s) - Libor's Corollary -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 04:17:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FBH6V12340 for ipng-dist; Wed, 15 Aug 2001 04:17:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FBGcD12320; Wed, 15 Aug 2001 04:16:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08140; Wed, 15 Aug 2001 04:16:37 -0700 (PDT) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20011; Wed, 15 Aug 2001 05:16:31 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id f7FBGSh00622; Wed, 15 Aug 2001 18:16:28 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7FBGMG02676; Wed, 15 Aug 2001 18:16:23 +0700 (ICT) From: Robert Elz To: Jun-ichiro itojun Hagino cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010815085732.742B37BA@starfruit.itojun.org> References: <20010815085732.742B37BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2001 18:16:22 +0700 Message-ID: <2674.997874182@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 15 Aug 2001 17:57:32 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010815085732.742B37BA@starfruit.itojun.org> | (1) A6 chasing is traffic multiplication = DoS possibility (recursive | servers), That has nothing at all to do with AAAA synthesis - it is an argument against A6 in general, but a very weak one. A site that wants to avoid this with A6 can easily avoid it. A site that wants to create lots of traffic with lookups can easily create it with AAAA (just add a few CNAMEs going into other domains...) A6 adds one more opportunity for people to configure things badly, but nothing at all new. | (2) it is unclear as to how will be doing AAAA synthesis, and we cannot | ensure that it will happen at the leaf Who cares? If someone asks for an AAAA, and gets back an AAAA, then they're happy right? If the server provided an A6, was asked for an A6, and answered with an A6, it is happy, right? Something between original (probably stub) resolver and server converted. Who cares what it was? The operators of the resolver might care - for lots of reasons, in which case they provide the back end resolver that does the synthesis. | (3) by deploying AAAA synthesis you end up maintaining both A6 and AAAA: No, exactly the opposite, you end up maintaining A6 only. The AAAA RR type remains in use, but that's no work for anyone. Actual AAAA records remain in zone files only long enough for the current (small) infrastructure to be mostly upgraded (so that it has back end resolvers in enough places). Once a fair proportion has that installed, the AAAA records simply get yanked from everywhere. That provides the incentive for everyone else to install a capable back end. | (3a) impose lookup delays to IPv6 clients. No, no delays at all (other than what is involved in the A6 lookup). | (3b) server admins need to maintain both A6 and AAAA in zoen file, | which is unhappy. No, only A6 records, that's what AAAA synthesis is all about, remember... 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 Aug 15 04:45:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FBjFt12434 for ipng-dist; Wed, 15 Aug 2001 04:45:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FBjBD12427; Wed, 15 Aug 2001 04:45:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11013; Wed, 15 Aug 2001 04:45:11 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA00662; Wed, 15 Aug 2001 05:45:06 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 84BB87BA; Wed, 15 Aug 2001 20:36:09 +0900 (JST) To: Johan Ihren Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: johani's message of 15 Aug 2001 13:27:07 +0200. <2chev9k1h0.fsf@snout.autonomica.se> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 20:36:09 +0900 Message-Id: <20010815113609.84BB87BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I don't understand what you are saying, AT ALL. I'm not using >> forwarding configuration. you must have some assumption in >> your head which is not presented here. > >Ok. Before I repeat the mistake of guessing at your configuration I >suggest you tell me about it. > >Personally I use a forwarding config for v6-only nameservers and I >believe that this is by far the most common case. I have been talking about a nameserver, with root.hint, on IPv4/v6 dual stack machine. to be more precise, see below. I never have talked about nameservers on IPv6-only machine, they will never work without some help from IPv4/v6 dual stack nameserver. (and it is rather unrealistic to talk about nameeservers in IPv6-only network today...) itojun --- # $NetBSD: named.conf,v 1.5 2000/03/01 11:06:29 itojun Exp $ # boot file for secondary name server # Note that there should be one primary entry for each SOA record. options { directory "/etc/namedb"; listen-on-v6 { any; }; }; zone "." { type hint; file "root.cache"; }; zone "localhost" { type master; file "localhost"; }; zone "127.IN-ADDR.ARPA" { type master; file "127"; }; -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 04:49:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FBnJs12471 for ipng-dist; Wed, 15 Aug 2001 04:49:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FBnED12464; Wed, 15 Aug 2001 04:49:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20086; Wed, 15 Aug 2001 04:49:15 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08140; Wed, 15 Aug 2001 05:49:25 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id CA9C17BA; Wed, 15 Aug 2001 20:40:10 +0900 (JST) To: Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: kre's message of Wed, 15 Aug 2001 18:16:22 +0700. <2674.997874182@brandenburg.cs.mu.OZ.AU> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 20:40:10 +0900 Message-Id: <20010815114010.CA9C17BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | (2) it is unclear as to how will be doing AAAA synthesis, and we cannot > | ensure that it will happen at the leaf >Who cares? If someone asks for an AAAA, and gets back an AAAA, then >they're happy right? If the server provided an A6, was asked for an >A6, and answered with an A6, it is happy, right? Something between >original (probably stub) resolver and server converted. Who cares >what it was? >The operators of the resolver might care - for lots of reasons, in which >case they provide the back end resolver that does the synthesis. you should care about this. there's no guarantee that AAAA synthesis happen between end client and master/slave nameservers. AAAA will leak from leaf to the core. > | (3a) impose lookup delays to IPv6 clients. >No, no delays at all (other than what is involved in the A6 lookup). if people query both AAAA and A6, there will be more delays. > | (3b) server admins need to maintain both A6 and AAAA in zoen file, > | which is unhappy. >No, only A6 records, that's what AAAA synthesis is all about, remember... you seem to be assuming that there's some AAAA synthesis server between IPv6 end node and nameservers. your assumption does not hold, especially during the transition period. because the assumption does not hold, zone admins need to maintain AAAA records too. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 05:31:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FCV9J12569 for ipng-dist; Wed, 15 Aug 2001 05:31:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FCUfD12548; Wed, 15 Aug 2001 05:30:41 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22860; Wed, 15 Aug 2001 05:30:42 -0700 (PDT) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08938; Wed, 15 Aug 2001 05:30:39 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id f7FCUWh00679; Wed, 15 Aug 2001 19:30:32 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7FCUSG02964; Wed, 15 Aug 2001 19:30:29 +0700 (ICT) From: Robert Elz To: Jun-ichiro itojun Hagino cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010815114010.CA9C17BA@starfruit.itojun.org> References: <20010815114010.CA9C17BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2001 19:30:28 +0700 Message-ID: <2962.997878628@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 15 Aug 2001 20:40:10 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010815114010.CA9C17BA@starfruit.itojun.org> | you should care about this. Why? | there's no guarantee that AAAA synthesis | happen between end client and master/slave nameservers. AAAA will | leak from leaf to the core. Yes. That doesn't tell me why I need to care. People send queries for all kinds of RR types that I don't have in my zone files, my servers return NO DATA responses (no error, no answer). Perfectly normal. That's what is likely to happen if they request an AAAA and all I have is A6. (Just maybe I'll do AAAA synthesis for random people in the very early days). Exactly why is this a problem to care about? | if people query both AAAA and A6, there will be more delays. Yes, so they shouldn't. End nodes can do AAAA to their back end. The back end should do A6 only, and synthesise the AAAA. No extra delays. | you seem to be assuming that there's some AAAA synthesis server | between IPv6 end node and nameservers. your assumption does not hold, | especially during the transition period. Right now it doesn't, no, it will take a little while to get them installed everywhere if we decide on A6 now. | because the assumption | does not hold, zone admins need to maintain AAAA records too. No, I can use A records as backup. They backup both the peers that only know about AAAA, and the ones that don't know IPv6 at all. We all agree that IPv4 is still going to be needed for a while yet, so it is just fine with me if peers who cannot handle A6 at all simply use IPv4. That will work. If the remote end wants to use IPv6, then it can install a synthesis server for its AAAA only nodes, and the A6 records will work fine. We can do this, because right now IPv4 works, and is a backup that we need to have anyway - so it is just fine to simply toss out all the AAAA records and replace them with A6. Nothing is going to break because of that. We won't be able to do that when we start getting native IPv6 nets though, which is why if this change is ever to be made, it needs to be made very soon - otherwise never. 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 Aug 15 05:44:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FChdJ12740 for ipng-dist; Wed, 15 Aug 2001 05:43:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FChZD12733; Wed, 15 Aug 2001 05:43:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17186; Wed, 15 Aug 2001 05:43:36 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26446; Wed, 15 Aug 2001 06:43:32 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E40457BA; Wed, 15 Aug 2001 21:34:11 +0900 (JST) To: Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: kre's message of Wed, 15 Aug 2001 19:30:28 +0700. <2962.997878628@brandenburg.cs.mu.OZ.AU> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 21:34:11 +0900 Message-Id: <20010815123411.E40457BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | you should care about this. >Why? > | there's no guarantee that AAAA synthesis > | happen between end client and master/slave nameservers. AAAA will > | leak from leaf to the core. >Yes. That doesn't tell me why I need to care. People send queries >for all kinds of RR types that I don't have in my zone files, my >servers return NO DATA responses (no error, no answer). Perfectly >normal. That's what is likely to happen if they request an AAAA and >all I have is A6. (Just maybe I'll do AAAA synthesis for random people >in the very early days). > >Exactly why is this a problem to care about? we (pick any community i'm involved with) are already operating AAAA in a lot of places. we need to keep those configuration to work fine while we migrate to A6 + AAAA synthesis. we have serious users of IPv6 using AAAA, and we cannot break their configuration, nor transition them into some other record type in one night. you have been proposing a migration path with a hard "flag day", with: - all existing zone files must be rewritten to from AAAA to A6 in one night (of which timezone?) - all AAAA queriers can stay as is, but there has to be AAAA synthesis server at every leaf - no AAAA traffic in core DNS cloud, only A6 traffic. this is totally unacceptable to us. the story applies only if we are going to move to A6 + AAAA synthesis. if we don't migrate, we have no worry and everyone is happy. itojun@tired. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 06:00:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FCxZA12809 for ipng-dist; Wed, 15 Aug 2001 05:59:35 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FCxUD12802; Wed, 15 Aug 2001 05:59:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04721; Wed, 15 Aug 2001 05:59:32 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06374; Wed, 15 Aug 2001 06:59:43 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E27BE7BA; Wed, 15 Aug 2001 21:49:58 +0900 (JST) To: Nathan Jones Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: njones's message of Wed, 15 Aug 2001 22:54:28 +1000. <20010815225428.A11162@connect.com.au> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 21:49:58 +0900 Message-Id: <20010815124958.E27BE7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> you seem to be assuming that there's some AAAA synthesis server >> between IPv6 end node and nameservers. your assumption does not hold, >> especially during the transition period. because the assumption >> does not hold, zone admins need to maintain AAAA records too. >It is only during the transition period that this assumption does not >hold true. The result of the transition is that there is an AAAA synth >server between the IPv6 end node and the nameserver. It is only during >the transition that AAAA records will be maintained alongside A6 records. how long do you think it will take, and how many people do you think get bitten by this? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 06:01:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FD0xv12854 for ipng-dist; Wed, 15 Aug 2001 06:00:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FD0dD12828; Wed, 15 Aug 2001 06:00:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15994; Wed, 15 Aug 2001 06:00:40 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07164; Wed, 15 Aug 2001 07:00:52 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7FD0Zm07613; Wed, 15 Aug 2001 06:00:35 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7FD0YH05643; Wed, 15 Aug 2001 06:00:34 -0700 Message-Id: <200108151300.f7FD0YH05643@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: kre@munnari.OZ.AU Date: Wed, 15 Aug 2001 06:00:34 -0700 (PDT) Cc: Alain.Durand@sun.com (Alain Durand), ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <2361.997869643@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at Aug 15, 2001 05:00:43 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % It cannot happen - net wide infrastructure upgrades are close to impossible % (for them to be even worth considering, the rationale has to be more % than compelling, there must be no other choice - for A6, or mobile IP, % or IDN, or anything else like that, there's always going to be some other % way than the right way). Then the Internet is doomed. Either evolution or revolution. Either the right way or an incremental hack, a goiter, that we can never get rid of. If there can never be any significant upgrade, then something else will come along and replace it. Some interesting work is starting to appear in the HIP/MANET space that could give some level of transport independence (rehoming TCP sessions on the fly) which could make existing mobilip OBE. The right path for IDN was to change the on-wire/stored encoding, forcing application evolution. Some fools^H^H^Hlks are looking at how to make those changes to the DNS. % We have a way to do it now, or soon. There's no way that it can ever % be made to happen once we get wide deployment. Expecting it is just fantasy. % % eg: now the DNS has SRV records, they do so everything that MX can do, % and more. In a way they're the analog of A6 and AAAA (MX is a subset of % SRV). There would be benefits to converting SMTP to use SRV instead of % MX. Can you imagine anyone seriously suggesting that that happen however? % Can you really imagine that there'd ever be a day when we could deprecate % the MX record? Yes I can see it. We've done it before. VJC is yet another example. Heck, we might even replace SMTP. % Yes, sure. Though it is also possible that AAAA synthesis would never % be a transition technique, but rather a permanent part of the way things % work (even if we decided that we wanted to move away from it, and there % probably wouldn't be much reason, there'd be no way to ever upgrade all % the clients, so back end resolvers would always need to provide it, so % new clients may as well just use the service that they know will be there...) Yet another hack, like mobilip & IDN. % kre As stated elsewhere, you seem to be taking the cynical path while I retain some semblence of pollyanna. You seem unwilling to do the right thing in favor of what looks like the expediant thing. Or am I reading too much into your statements? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 06:36:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FDWfS12983 for ipng-dist; Wed, 15 Aug 2001 06:32:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FDWaD12976; Wed, 15 Aug 2001 06:32:36 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08491; Wed, 15 Aug 2001 06:32:37 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02841; Wed, 15 Aug 2001 06:32:35 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 72CFE7BA; Wed, 15 Aug 2001 22:22:51 +0900 (JST) To: Nathan Jones Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: njones's message of Wed, 15 Aug 2001 23:13:37 +1000. <20010815231337.B11162@connect.com.au> 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: (ngtrans) Joint DNSEXT & NGTRANS summary From: Jun-ichiro itojun Hagino Date: Wed, 15 Aug 2001 22:22:51 +0900 Message-Id: <20010815132251.72CFE7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> transition them into some other record type in one night. you have >> been proposing a migration path with a hard "flag day", with: >I don't recall anyone saying that this needs to be an instant change. > >I do recall people saying that A6 has merit and that it is worth the >effort to migrate. > >The whole idea of transition mechanisms like AAAA synth is to allow >gradual adoption of A6 as people start adopting A6. well, this is because you guys have been ignorant about transition issue from the current situation to "AAAA synthesis" situation. >Obviously there will be a transition period during which members of >the existing (comparatively small) IPv6 community will either provide >both AAAA and A6, or run DNS software that can synthesise AAAA RRs to >serve requests from other existing IPv6 users. what I have been arguing about is that, AAAA synthesis advocators never mention about transition period like the above four lines. it was very first time it was admitted by AAAA synthesis advocators. AAAA synthesis advocators never talk about this "issues during transition period to AAAA synthesis" wait, AAAA synthesis is a transition tool to A6, and we need a transition period to move to AAAA synthesis? what is the merit of doing such a complex thing? will the effort really buy us anything? there has to be more detailed analysis made, before AAAA synthesis be even taken into consideration. I'm serious. someone has to write up a whole analysis document. I tried it in my draft, but you may say I'm biased :-P >> - all existing zone files must be rewritten to from AAAA to A6 in one >> night (of which timezone?) >> - all AAAA queriers can stay as is, but there has to be AAAA synthesis >> server at every leaf >> - no AAAA traffic in core DNS cloud, only A6 traffic. >These claims seem to stem from either disbelieve that the transition >can be made, or from desire to stop A6 regardless of its merits. you can't control what I believe, or disbelieve. what I'm keep saying is AAAA synthesis advocators are too optimistic about the mess that happens during the transition period. and if we don't transition, there's no mess! itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 06:36:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FDZXY12992 for ipng-dist; Wed, 15 Aug 2001 06:35:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FDZSD12985 for ; Wed, 15 Aug 2001 06:35:29 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19488 for ; Wed, 15 Aug 2001 06:35:19 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04070 for ; Wed, 15 Aug 2001 06:35:14 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA22980; Wed, 15 Aug 2001 14:35:11 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA50678; Wed, 15 Aug 2001 14:35:10 +0100 Message-ID: <3B7A7A90.DAC4510@hursley.ibm.com> Date: Wed, 15 Aug 2001 08:35:12 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <20010815062038.C7AAF7BA@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I didn't hear the presentation since I was sick. But yes, the draft analyses all those ideas and rejects them - the surviving proposal is to use the PHB ID. I will comment on that in response to Steve's message. The pseudorandom case works for intserv and is irrelevant to diffserv. Brian Jun-ichiro itojun Hagino wrote: > > >The traffic class field is not enough. If you have to re-classify traffic at > >an administrative boundary, then by definition at that point the traffic class > >field is inadequate; you need more information. The advantage that IPv6 has > >is that even when the header is partly hidden by IPSEC, the flow label is > >available to carry additional semantics. The actual proposal is to use the > >PHB identifier which has end to end semantics. > > I heard the presentation differently. in IETF51 presentation Alex > Conta made the following proposals, at least: > - putting PHB value > not trustworthy. > - putting total extension header length > if the originator lies about the value, intermediate routers > can go panic. > - putting port/addr/whatever encoded > if the originator lies about the value, theft-of-service > happens. > none of these values are trustworthy, since originator can lie about > those. because these values are not trustworthy, intermediate routers > need to get those values by normal ways (by chasing extension header > chain, or whatevr), and therefore, flow label value is just wasted. > > I particularly don't like the idea of putting total extension header > length. as soon as it gets deployed bad guys can mount various attacks. > > So, back to my original posting, I vote for end-to-end pseudorandom > 20bit value. intermediate router MAY use it to hash the traffic, > that's all. > > itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 06:43:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FDhFc13066 for ipng-dist; Wed, 15 Aug 2001 06:43:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FDhCD13059 for ; Wed, 15 Aug 2001 06:43:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24025 for ; Wed, 15 Aug 2001 06:43:13 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29829 for ; Wed, 15 Aug 2001 07:43:09 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA13012; Wed, 15 Aug 2001 14:43:10 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA36538; Wed, 15 Aug 2001 14:43:10 +0100 Message-ID: <3B7A7C67.B7D0AD46@hursley.ibm.com> Date: Wed, 15 Aug 2001 08:43:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Steve Blake CC: Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <200108150006.UAA07602@castillo.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Blake wrote: > > Brian Carpenter wrote: > > > The traffic class field is not enough. If you have to re-classify traffic at > > an administrative boundary, then by definition at that point the traffic class > > field is inadequate; you need more information. The advantage that IPv6 has > > is that even when the header is partly hidden by IPSEC, the flow label is > > available to carry additional semantics. The actual proposal is to use the > > PHB identifier which has end to end semantics. > > Brian, > > The counter argument against putting port information in the flow label > is that it gives the application the incentive to lie (by putting bogus > information in the flow label), without the impact of breaking the receiver's > port demultiplexing. Quite agree. This option doesn't work. Sorry if the draft doesn't make it clear that we reject it. > > The counter argument against putting the PHB id in the flow label is that > it is irrelevant: the way PHBs have been defined has virtually no > relationship to any application QoS performance parameters, and furthermore, > the downstream network usually couldn't care less what the application > desires. This is debatable. Since there is a potentially large number of IANA-registered PHB IDs, they can actually be given more semantics than a true PHB. It's certainly stretching the concept. It's also the only way I can see to make the flow label relevant to diffserv; but we are at liberty to conclude that it can't be done and we leave the flow label exactly as it is, relevant only to intserv. > If I am reclassifying traffic at an administrative boundary then by > definition I don't care about or trust the "QoS information" in the > packet as anything more than a hint which I am free to ignore (depending > on the TCS I have with the upstream network). When crossing security > boundaries the only field which I am reasonably safe to trust is the > destination address. Protocol/port filtering only makes sense within > an enterprise network or at the access provider's edge. Well yes, but when the packet has an ESP header you are in trouble. The idea of adding some semantics in the flow label is to deal with the ESP case. If you aren't prepared to believe that field then of course all is lost and you can only do address based classification. Regards Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 06:51:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FDoYk13110 for ipng-dist; Wed, 15 Aug 2001 06:50:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FDoUD13103 for ; Wed, 15 Aug 2001 06:50:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01098 for ; Wed, 15 Aug 2001 06:50:32 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04789 for ; Wed, 15 Aug 2001 07:50:27 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA23112; Wed, 15 Aug 2001 14:50:28 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA36604; Wed, 15 Aug 2001 14:50:17 +0100 Message-ID: <3B7A7E0F.B2379C84@hursley.ibm.com> Date: Wed, 15 Aug 2001 08:50:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta , Pekka Savola , ipng Subject: Re: [Fwd: Mapped IPv6 Flow label] References: <3B794C04.DBFC002B@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > From: Pekka Savola > To: > > Hello all, > > [ http://www.ietf.org/internet-drafts/draft-conta-ipv6-flow-label-02.txt ] > > The ipv6 flow label draft presented at IETF51 generated a lot of > discussion; basically UDP/TCP port numbers and some other data is mapped > into the proposed Flow label field. No, the actual proposal is to use the PHB ID, since there is no reversible mapping of port numbers. > > The concern on the security, and reliability, of this were raised, and > rightly so (I agree), but IMO the main point is this: > > Currently, Edge routers or hosts themselves, set DSCP/Traffic Class bits > in the datagrams after looking at UDP/TCP ports, or some other, > functionally equivalent data. Traffic class is of limited size and has no > global meaning. > > With separate, sufficiently long Flow Label field, DiffServ model _could_ > be extended so that the core routers themselves (or Edge/Border routers > mode scalably) could perform classification and differentiation. The data > -> Flow Label mapping only has to be done once, and it's in a fixed > position in the header. The policy within different AS's, how to deal > with specific packets, could be (mostly) covered. The packet wouldn't > have to reclassified at the border. But the flow label field *is not* sufficiently long for this. That's why we propose the PHB ID. See my response to Steve Blake for the discussion of that. > Were it not for reliability, layer violation, the function of core > routers, etc. considerations, this _could_ be viewed as a Good Thing for > enabling easier _Internet-wide_ QoS. This is perhaps one "justification" > for the author for introducing this behaviour. Layer violation is an intrinsic part of QoS classification so that isn't an issue. The real decision depends on the trust and security issues raised by Steve Blake and Bill Somerfeld. > Just bringing up one point about DiffServ which was not all that possible > with IPv4.. Indeed, that was the motivation for the draft. If we can devise a way to use the flow label, it is a plus point. But if we accept Steve and Bill's arguments, it is impossible. 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 Aug 15 07:30:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FEThg13290 for ipng-dist; Wed, 15 Aug 2001 07:29:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FETdD13283 for ; Wed, 15 Aug 2001 07:29:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00791 for ; Wed, 15 Aug 2001 07:29:35 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01470 for ; Wed, 15 Aug 2001 07:29:34 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id KAA06897; Wed, 15 Aug 2001 10:30:25 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id KAA22618; Wed, 15 Aug 2001 10:30:23 -0400 Message-ID: <3B7A877A.140D8E4C@txc.com> Date: Wed, 15 Aug 2001 10:30:18 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Blake CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <200108150006.UAA07602@castillo.torrentnet.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF39BF95424F6BD25E7D61632" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF39BF95424F6BD25E7D61632 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve, Steve Blake wrote: > > Brian Carpenter wrote: > > > The traffic class field is not enough. If you have to re-classify traffic at > > an administrative boundary, then by definition at that point the traffic class > > field is inadequate; you need more information. The advantage that IPv6 has > > is that even when the header is partly hidden by IPSEC, the flow label is > > available to carry additional semantics. The actual proposal is to use the > > PHB identifier which has end to end semantics. > > Brian, > > The counter argument against putting port information in the flow label > is that it gives the application the incentive to lie (by putting bogus > information in the flow label), without the impact of breaking the receiver's > port demultiplexing. > Independent of what Brian may have to say.... What you say gives the impression that the draft introduces a higher security risk, but that is absolutely not true. The QoS processing is affected the same way, whether there is a port number or something else in the flow label. That is to say that the security impact of using a port number, or any other label format, is not different than with the RFC 2460 definition of the flow label format, if a user can change as pleases packet headers before packets are sent. > The counter argument against putting the PHB id in the flow label is that > it is irrelevant: the way PHBs have been defined has virtually no > relationship to any application QoS performance parameters, The relationship or non-relationship with an application prior to using the PHB value in the flow label is irrelevant. One could use anything as a value, including a predefined IANA value. Using the PHB ID is clever, because it avoids the hassles of another set of IANA numbers. > and furthermore, > the downstream network usually couldn't care less what the application > desires. > It is correct to say "usually", because it is not "always". There are plenty of situations, where there is a merit for the downstream providers. Nevertheless, it was stated quite clearly in the draft, the best and direct application is in access networks. > If I am reclassifying traffic at an administrative boundary then by > definition I don't care about or trust the "QoS information" in the > packet as anything more than a hint which I am free to ignore (depending > on the TCS I have with the upstream network). You are free to ignore, but you should also be free to consider, depending on SLS/TCS. The point is in giving the users/providers the choice. > [...] > Steven L. Blake > Ericsson IP Infrastructure (919)472-9913 Alex --------------msF39BF95424F6BD25E7D61632 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MTUxNDMwMjJaMCMGCSqGSIb3DQEJBDEWBBQpNl0QrB6N0sIGv/Js zGwEY7+3EDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gBzfn7NAM/mpN9N7ea7UplCyd8VJjWsJjtRdR9OzitCg9bkYWUgeE/zNKL/aXQ0YEvwfCKO5 o81uwH9w+MtgqR4LNUFZwr6AH59AoqTIrbkhVVQ5QObmuPUY/DtVQbDqINU2E+LRnIAN1/6W UMZBnN4oDRSqMEpCsuqqtdOh3buS --------------msF39BF95424F6BD25E7D61632-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 07:32:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FEWDI13330 for ipng-dist; Wed, 15 Aug 2001 07:32:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FEVpD13309; Wed, 15 Aug 2001 07:31:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05537; Wed, 15 Aug 2001 07:31:52 -0700 (PDT) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02719; Wed, 15 Aug 2001 07:31:49 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id f7FEVgh00751; Wed, 15 Aug 2001 21:31:42 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7FEVZG03205; Wed, 15 Aug 2001 21:31:37 +0700 (ICT) From: Robert Elz To: Jun-ichiro itojun Hagino cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010815123411.E40457BA@starfruit.itojun.org> References: <20010815123411.E40457BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2001 21:31:35 +0700 Message-ID: <3203.997885895@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 15 Aug 2001 21:34:11 +0900 From: Jun-ichiro itojun Hagino Message-ID: <20010815123411.E40457BA@starfruit.itojun.org> | we (pick any community i'm involved with) are already operating AAAA | in a lot of places. Fine. | we need to keep those configuration to work fine | while we migrate to A6 + AAAA synthesis. Of course. | you have | been proposing a migration path with a hard "flag day", No I haven't. What I said was that I can change my AAAA records to A6 records any time I like. I can simply delete my AAAA records and not replace them at all any time I like. You will never notice, I'm quite sure that you don't care in the least about my few AAAA records. For any new systems I can install only A6 records - while you're only doing AAAA lookups you won't find them. You won't find them now while they have no v6 records at all either... Either way, you cope. | - all existing zone files must be rewritten to from AAAA to A6 in one | night (of which timezone?) No, I didn't say anything like that. I said that a server could convert (or a human operating a server could), I didn't ever claim that it all has to happen at once, there's no reason for that. | - all AAAA queriers can stay as is, but there has to be AAAA synthesis | server at every leaf Eventually, yes. In the short term, one used as a forwarder anywhere (one per ISP would do just fine). | - no AAAA traffic in core DNS cloud, only A6 traffic. That's not a requirement, just a target. It will probably never be reached. But who cares? There are probably MB queries out there in the net now, somewhere, no-one cares about those either. In another message you asked (Nathan Jones I think, but I will answer anyway) | how long do you think it will take, and how many people do you think | get bitten by this? Time, depending upon how committed various people are, a month or two, perhaps three. It depends how urgent it is seen to be. People, maybe 10K or so, perhaps realistically just a thousand. Compared to the millions of internet users, almost no-one. Of course, if you're one of the 10K (or 1K or whatever it is) then you're going to suffer a bit - you'll have some extra work to do, and you might want to maintain both AAAA and A6 for a while (you probably would, I wouldn't). That's extra work. It is also a part of the price of being an early adopter, which tends to hit everything new as it is being introduced. You get the benefits of being among the first, you have to pay the costs as well. And in another message ... | what I have been arguing about is that, AAAA synthesis advocators | never mention about transition period like the above four lines. That's because it is kind of obvious. Clearly the net that we have now is going to have to transition (assuming A6 is selected). You can read my messages about how impossible that will be if left a few years as implying that I don't think this is a trivial exercise, even now. It isn't. But it is manageable now. It can be done. We could even do it in stages, ask everyone to put A6 records in their servers wherever AAAA records exist. Then when we see (by querying the servers that we care about) that has been done, we can install A6->AAAA synthesis resolvers. Then when we see that the number of AAAA queries hitting our servers has dropped to an acceptably low level (which each of us can define individually), remove the AAAA records from our servers. Allow 3 weeks for the first step, and then everything is self timimg (we each proceed at our own pace). | wait, AAAA synthesis is a transition tool to A6, You can view it that way - but it is also possible to view it as simply a part of the infrastructure, the same way that TSIG/AD is a part of the DNSSEC infrastructure. Allow end nodes to do just simple things (if they want, they can always do A6, or full dnssec, if they prefer - most won't) forever. Nothing transition about it. | and we need a transition period to move to AAAA synthesis? Yes, but this isn't hard. | what is the merit of doing such a complex thing? It isn't complex. It is simple. It gets us to a much more flexible DNS RR - one which incidentally (aside from all the other benefits) means we need just N+M RR's in the DNS (and answers) rather than N*M for every node (where N is the number of interfaces a node has, and M is the number of prefixes). That may very well allow UDP queries to continue to work in situations (especially major serves - which are what most people want to reach) that AAAA would require TCP be used instead (ie: the 1280 (or 512 for basic v4 transport) bytes of DNS packet will hold much bigger A6 RRsets - sanely designed - then it will AAAA RRsets). eg: for AAAA, in a 512 byte packet, you can fit (maybe, if you're lucky and the name isn't too long) 27 RRs. If you have 4 providers, then the max addresses for a node before you get TC problems is 6. That's pretty limiting... With A6, you could probably fit 20 addresses for the node (and the 4 providers). This is one of the things the tests I am about to start doing will measure... If you're using many addresses to get load balancing, this matters. 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 Aug 15 07:37:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FEaSx13361 for ipng-dist; Wed, 15 Aug 2001 07:36:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FEaOD13354 for ; Wed, 15 Aug 2001 07:36:24 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01887 for ; Wed, 15 Aug 2001 07:36:25 -0700 (PDT) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00698 for ; Wed, 15 Aug 2001 07:36:23 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id f7FEaKh00755; Wed, 15 Aug 2001 21:36:20 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7FEaFG03225; Wed, 15 Aug 2001 21:36:16 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: Steve Blake , Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] In-Reply-To: <3B7A7C67.B7D0AD46@hursley.ibm.com> References: <3B7A7C67.B7D0AD46@hursley.ibm.com> <200108150006.UAA07602@castillo.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2001 21:36:14 +0700 Message-ID: <3223.997886174@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 15 Aug 2001 08:43:04 -0500 From: Brian E Carpenter Message-ID: <3B7A7C67.B7D0AD46@hursley.ibm.com> This is way outside my area, but ... | Well yes, but when the packet has an ESP header you are in trouble. The idea | of adding some semantics in the flow label is to deal with the ESP case. | If you aren't prepared to believe that field then of course all is lost | and you can only do address based classification. I think the point was that if you believe the data, then you can be guaranteed that people will cheat. Therefore you cannot believe the field. Therefore all you are left with is the address. (which is pretty much as you just said, but you left off the final step) Therefore it is pointless adding any semantics to the field, because even if there, they can't (won't) be used. 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 Aug 15 07:57:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FEvIS13520 for ipng-dist; Wed, 15 Aug 2001 07:57:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FEupD13500; Wed, 15 Aug 2001 07:56:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08439; Wed, 15 Aug 2001 07:56:51 -0700 (PDT) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06606; Wed, 15 Aug 2001 08:57:00 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id f7FEudh00774; Wed, 15 Aug 2001 21:56:39 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7FEubG03257; Wed, 15 Aug 2001 21:56:37 +0700 (ICT) From: Robert Elz To: Bill Manning cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <200108151300.f7FD0YH05643@zed.isi.edu> References: <200108151300.f7FD0YH05643@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2001 21:56:37 +0700 Message-ID: <3255.997887397@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 15 Aug 2001 06:00:34 -0700 (PDT) From: Bill Manning Message-ID: <200108151300.f7FD0YH05643@zed.isi.edu> | Then the Internet is doomed. Either evolution or revolution. In some places, revolution is all that is possible. The evolutionary step is just too big to every take. | If there can never be any significant upgrade, then something | else will come along and replace it. There can be upgrades, we see upgrades all the time. What will never happen is an upgrade that is a basic change on the way things function, that requires lots of what is out there to change to keep up. All the upgrades that succeed are either done as local transitions (I upgrade, you upgrade, eventually perhaps everyone might have), or are backwards compatible (I have upgraded, I keep talking to you, even if you haven't). | Some interesting work | is starting to appear in the HIP/MANET space that could | give some level of transport independence (rehoming TCP | sessions on the fly) which could make existing mobilip | OBE. Not anytime soon. There might always be something new that works better, but to use all the existing stuff, TCP is still going to be around, for a very very long time. | The right path for IDN was to change the on-wire/stored encoding, Actually, for the DNS, the right thing was almost nothing - it all works already (maybe some servers might need bugs fixed, to allow names containing nuls or something be stored in files, but that's not too hard). | forcing application evolution. Yes, that would be the right way. But we know it isn't the way that is being adopted, don't we. Ever wonder why... | Some fools^H^H^Hlks | are looking at how to make those changes to the DNS. No DNS changes are needed. Just a definition of what a non-ascii label means (like "it is UTF-8" or something), and perhaps something to deal with ascii case equivalence (yet another feature it would be nice to excise, but which is too deeply rooted now to ever go away). | Heck, we might even replace SMTP. We just finished redefining SMTP - with the major objective of documenting what is actually used (eliminating the dead wood). Not much was deleted, really... | As stated elsewhere, you seem to be taking the cynical | path while I retain some semblence of pollyanna. Perhaps. The latter is an interesting nightmare... | You seem unwilling to do the right thing in favor of what looks | like the expediant thing. No, I'd very much like to do the right thing. That includes fixing TCP so it can handle connection renaming (which would be trivial to do in a backwards compatible way - but impossible to get deployed at a big enough fraction of sites to make it actually useful), sticking idn labels directly in the DNS (and having the app protocols deal with that), and using A6 rather than AAAA. The last we can choose to do now, it is still possible. The others we could choose to do, but I doubt they'd ever actually work (idn just maybe, with enough pressure - as comparatively little actually cares, whatever the standards say). | Or am I reading too much into your statements? Perhaps. 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 Aug 15 08:54:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FFrPK13721 for ipng-dist; Wed, 15 Aug 2001 08:53:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FFrLD13711 for ; Wed, 15 Aug 2001 08:53:21 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13868 for ; Wed, 15 Aug 2001 08:53:22 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19123 for ; Wed, 15 Aug 2001 08:53:19 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA15574; Wed, 15 Aug 2001 16:53:16 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA14812; Wed, 15 Aug 2001 16:53:16 +0100 Message-ID: <3B7A9A09.D41F41CA@hursley.ibm.com> Date: Wed, 15 Aug 2001 10:49:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Elz CC: Steve Blake , Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <3B7A7C67.B7D0AD46@hursley.ibm.com> <200108150006.UAA07602@castillo.torrentnet.com> <3223.997886174@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > > Date: Wed, 15 Aug 2001 08:43:04 -0500 > From: Brian E Carpenter > Message-ID: <3B7A7C67.B7D0AD46@hursley.ibm.com> > > This is way outside my area, but ... > > | Well yes, but when the packet has an ESP header you are in trouble. The idea > | of adding some semantics in the flow label is to deal with the ESP case. > | If you aren't prepared to believe that field then of course all is lost > | and you can only do address based classification. > > I think the point was that if you believe the data, then you can be guaranteed > that people will cheat. > > Therefore you cannot believe the field. > > Therefore all you are left with is the address. > > (which is pretty much as you just said, but you left off the final step) > > Therefore it is pointless adding any semantics to the field, because > even if there, they can't (won't) be used. But there's a recursion here. If you choose to believe port and protocol numbers, then all cheaters have to do is encapsulate their low priority packets in what look like VoIP packets and they will get real time performance. So whatever you choose to believe (except the destination address) could be bogus. It turns out this doesn't matter. If somebody cheats in this way, they will pay the tariff for better QoS anyway - so why would the ISP care? I think that is the rebuttal to Steve Blake's argument - customers pay for the service they actually get, even if they are disguising their traffic. So sure they can cheat, but they are the losers. 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 Aug 15 09:13:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FGCau13792 for ipng-dist; Wed, 15 Aug 2001 09:12:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FGCWD13785; Wed, 15 Aug 2001 09:12:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20650; Wed, 15 Aug 2001 09:12:33 -0700 (PDT) Received: from nara.off.connect.com.au (nara.off.connect.com.au [192.94.41.40]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00040; Wed, 15 Aug 2001 09:12:28 -0700 (PDT) Received: (from njones@localhost) by nara.off.connect.com.au id CAA26063 (8.8.8/IDA-1.7); Thu, 16 Aug 2001 02:04:35 +1000 (EST) Message-ID: <20010816020435.A25502@connect.com.au> Date: Thu, 16 Aug 2001 02:04:35 +1000 From: Nathan Jones To: Johan Ihren , David Terrell Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <2361.997869643@brandenburg.cs.mu.OZ.AU> <20010815032134.A1896@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Johan Ihren on Wed, Aug 15, 2001 at 12:30:37PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Johan Ihren wrote: >An authoritative, non-recursive server with only A6 fragments around >can not synthesise the AAAA since that would require it to query for >missing fragments. True, but it could still be an option for DNS administrators happy to run a recursive nameserver. Also, I haven't thought this through fully, but is there any reason a nameserver couldn't have an option to use recursion for AAAA synthesis, but still deny to recurse when answering client queries? -- nathanj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 09:21:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FGL8Q13835 for ipng-dist; Wed, 15 Aug 2001 09:21:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FGL5D13828 for ; Wed, 15 Aug 2001 09:21:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11873 for ; Wed, 15 Aug 2001 09:21:06 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04716 for ; Wed, 15 Aug 2001 09:21:05 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id MAA09289; Wed, 15 Aug 2001 12:21:56 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA27691; Wed, 15 Aug 2001 12:21:40 -0400 Message-ID: <3B7AA18F.AD8803E8@txc.com> Date: Wed, 15 Aug 2001 12:21:35 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <20010815062038.C7AAF7BA@starfruit.itojun.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0E696D9D46511CDCAE5A9770" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms0E696D9D46511CDCAE5A9770 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Itojun, You seem to ignore that both RFC 1883, and RFC 2460 themselves state that the flow label definition has limitations. Since 1994-95, and 97-98 when those documents were written/reviewed, a lot more progress has been made relative to QOS and labeling traffic, in terms of architecture, specifications, and applicability. You state that the current definition is perfect, or it suits you perfect. But you do not want to accept a win-win situation, which is a mechanism that - does not eliminate what suits you, but also - would suit others. I am going to try to keep religion out, and respond to the technical content of what you're saying whatever that may be - please see bellow. Alex >Jun-ichiro itojun Hagino wrote: > > >The traffic class field is not enough. If you have to re-classify traffic at > >an administrative boundary, then by definition at that point the traffic class > >field is inadequate; you need more information. The advantage that IPv6 has > >is that even when the header is partly hidden by IPSEC, the flow label is > >available to carry additional semantics. The actual proposal is to use the > >PHB identifier which has end to end semantics. > > I heard the presentation differently. in IETF51 presentation Alex > Conta made the following proposals, at least: > - putting PHB value > not trustworthy. The PHB is as trustworthy as anything else, including the pseudo-random value. If a user can set values as pleases, it can do that with the pseudo-random number as well. > - putting total extension header length > if the originator lies about the value, intermediate routers > can go panic. I disagree. "less than the size of the packet" is a simple, cheap, straight forward validation test of the headers length, that would ensure that nothing wrong can happen, regardless of memory being partioned and protected. Even without the validation, the reduced number of bits available for the length is forcing a reasonable limit on the length. The TCP/UDP ports are accessed for "read", and the values are not used as pointers or offsets. Assuming an implementation that enforces memory partitioning, the "kernel" has most likely "read" access anywhere in memory, so "memory access violation" is unlikely. Also please note that the use of a total header length would not be conceptually, and practically different than IPv4. The IHL field in the IPv4 header includes the length of the main header fields, and the IPv4 options. Some of the IPv4 options are of a variable length. A variable size IPv4 option carries a field indicating the length. We knew how to implement this back many years ago, right?, so we should be able to implement this carefully for IPv6, if need be. > - putting port/addr/whatever encoded > if the originator lies about the value, theft-of-service > happens. As said above, the security risk is not higher than with the pseudo-random number. > none of these values are trustworthy, since originator can lie about > those. because these values are not trustworthy, intermediate routers > need to get those values by normal ways (by chasing extension header > chain, or whatevr), and therefore, flow label value is just wasted. > > I particularly don't like the idea of putting total extension header > length. as soon as it gets deployed bad guys can mount various attacks. > > So, back to my original posting, I vote for end-to-end pseudorandom > 20bit value. intermediate router MAY use it to hash the traffic, > that's all. > > itojun --------------ms0E696D9D46511CDCAE5A9770 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MTUxNjIxMzdaMCMGCSqGSIb3DQEJBDEWBBTtX4RV5lcqFbH0pRRh b0uikC6KkjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gA/GwfAvrMIeOH/9a5DQNSmq6KyglPBo1pvz3JlsDuydA7H1vTgKkuNJGrfHsSza+0FZPfsi lHKXidI29230Wjt0HmeeOfyl68sKTwzbM7PO+gucOCsSikjAlEU+bQ5QfyhCqlqgO47KCYc6 ZNcbdyEFx8pj9bkLuErJ3fgih0Ml --------------ms0E696D9D46511CDCAE5A9770-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 09:38:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FGbtl13890 for ipng-dist; Wed, 15 Aug 2001 09:37:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FGboD13883 for ; Wed, 15 Aug 2001 09:37:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15465 for ; Wed, 15 Aug 2001 09:37:51 -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 KAA12679 for ; Wed, 15 Aug 2001 10:38:01 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA04603; Thu, 16 Aug 2001 01:40:46 +0900 (JST) Date: Thu, 16 Aug 2001 01:37:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <200108131412.f7DECRu04797@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200108131412.f7DECRu04797@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 53 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 13 Aug 2001 16:12:27 +0200, >>>>> Francis Dupont said: >> => I believe there should be none because the stability requirement >> should be for id names, not id values. Of course, we should recommend >> to use always names too. > Notice that I did *not* talk about stability across reboots. > My issue is whether it is ok or not to have the ids change > on a whim while the machine is *running* (e.g. due to using hotplugging to > add or remove NICs). > => it seems we agree to say it is *not* ok. Of course not. Aside from this particular issue, it seems that MIB guys also want zone IDs that can identify particular scope types. If such usage has reality, it would mean 4+28 (or something similar) IDs are more suitable. I talked with Steve (and some other guys who supported the idea A) on this issue assuming such usage in MIBs, and we thought we could compromise on this point, as long as we could avoid "flexibility" that the idea C would provide. So, the basic idea is as follows: - take 4+28 split. - actual mapping from zone to the 28 bit part does not matter, but it should not change while the node is running (as discussed in this thread) - introduce "aliases" for numeric zone IDs to improve readability in the textual representation. e.g. "link2" is an alias of a link ID whose intra-link id is 2 (i.e. 0x20000002). "site4" is an alias of a site ID whose intra-site id is 4 (i.e. 0x50000004). We now allow fec0::1234%site4 as well as fec0::1234%1342177284 (1342177284=0x50000004) - when a zone ID is used with an address (typically in the sockaddr_in6 structure), the scope type of the ID must be equal to the scope type of the address. This should basically be the same idea as B. So I guess supporters of B do not oppose to this (I hope not, actually). As I said above, most of supporters of A could live with this. Can we (especially those who support C) make a compromise on this with this plan? Then I'll revise the textual representation in the scope architecture draft, according to the idea. 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 Aug 15 09:47:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FGkmX13927 for ipng-dist; Wed, 15 Aug 2001 09:46:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FGkiD13920 for ; Wed, 15 Aug 2001 09:46:44 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24722 for ; Wed, 15 Aug 2001 09:46:45 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17104 for ; Wed, 15 Aug 2001 09:46:45 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7FGkWM94212; Wed, 15 Aug 2001 12:46:32 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7FGkWf76010; Wed, 15 Aug 2001 12:46:32 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id MAA16236; Wed, 15 Aug 2001 12:46:31 -0400 (EDT) Message-Id: <200108151646.MAA16236@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] In-reply-to: Your message of "Wed, 15 Aug 2001 10:49:29 CDT." <3B7A9A09.D41F41CA@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 Aug 2001 12:46:28 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter wrote: > > Therefore it is pointless adding any semantics to the field, because > > even if there, they can't (won't) be used. > > But there's a recursion here. If you choose to believe port and protocol > numbers, then all cheaters have to do is encapsulate their low priority > packets in what look like VoIP packets and they will get real time > performance. So whatever you choose to believe (except the destination > address) could be bogus. > > It turns out this doesn't matter. If somebody cheats in this way, they will > pay the tariff for better QoS anyway - so why would the ISP care? I think > that is the rebuttal to Steve Blake's argument - customers pay for the service they > actually get, even if they are disguising their traffic. So sure they can cheat, > but they are the losers. To summarize: the customer will pay for higher CoS, and can either explicitly "signal" the provider of the desired per-packet CoS (via the traffic class or flow label fields), or let the provider infer the required per-packet CoS, according to agreement, by looking at the protocol/ports and addresses. Pushing protocol/port filtering to the provider is easier to deploy if I trust the hosts in my network: I don't have to change the hosts or deploy any Diffserv filtering/marking in my firewall. If I trust the hosts to put legitimate values in the flow label field, then I can just as easilly trust them to put legitimate values in the traffic class field. If I don't trust my hosts, then I need to enforce my Diffserv policy at the firewall anyway. So I think the argument boils down to whether 6 bits or 20 bits is enough to convey application CoS preferences to the network. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 10:03:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FH38Z14002 for ipng-dist; Wed, 15 Aug 2001 10:03:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FH34D13995 for ; Wed, 15 Aug 2001 10:03:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00918 for ; Wed, 15 Aug 2001 10:03:06 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27477 for ; Wed, 15 Aug 2001 11:03:12 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA17380; Wed, 15 Aug 2001 18:02:56 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA42866; Wed, 15 Aug 2001 18:02:56 +0100 Message-ID: <3B7AAA08.C2211D49@hursley.ibm.com> Date: Wed, 15 Aug 2001 11:57:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Steve Blake CC: ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <200108151646.MAA16236@castillo.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk See comment at the end. Steve Blake wrote: > > Brian Carpenter wrote: > > > > Therefore it is pointless adding any semantics to the field, because > > > even if there, they can't (won't) be used. > > > > But there's a recursion here. If you choose to believe port and protocol > > numbers, then all cheaters have to do is encapsulate their low priority > > packets in what look like VoIP packets and they will get real time > > performance. So whatever you choose to believe (except the destination > > address) could be bogus. > > > > It turns out this doesn't matter. If somebody cheats in this way, they will > > pay the tariff for better QoS anyway - so why would the ISP care? I think > > that is the rebuttal to Steve Blake's argument - customers pay for the service they > > actually get, even if they are disguising their traffic. So sure they can cheat, > > but they are the losers. > > To summarize: the customer will pay for higher CoS, and can either explicitly > "signal" the provider of the desired per-packet CoS (via the traffic class > or flow label fields), or let the provider infer the required per-packet CoS, > according to agreement, by looking at the protocol/ports and addresses. > > Pushing protocol/port filtering to the provider is easier to deploy if I > trust the hosts in my network: I don't have to change the hosts or deploy > any Diffserv filtering/marking in my firewall. If I trust the hosts to > put legitimate values in the flow label field, then I can just as easilly > trust them to put legitimate values in the traffic class field. If I > don't trust my hosts, then I need to enforce my Diffserv policy at the > firewall anyway. > > So I think the argument boils down to whether 6 bits or 20 bits is enough > to convey application CoS preferences to the network. Excellent summary. We originally chose a 6 bit diffserv field partly because it was available in both IPv4 and IPv6, and partly because it allows for very efficient classification in *core* routers, with the more demanding multi-field classification being left to border routers. The question before the house (in the end that means both ipng and diffserv) is whether the added complexity of adding the flow label to the diffserv model is justified by the gain in expressiveness. It doesn't do anything for the trust model. 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 Aug 15 10:04:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FH3SF14011 for ipng-dist; Wed, 15 Aug 2001 10:03:28 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FH3ND14004; Wed, 15 Aug 2001 10:03:24 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-109.EBay.Sun.COM [129.150.4.109]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FH3Og256075; Wed, 15 Aug 2001 10:03:24 -0700 (PDT) Message-Id: <5.1.0.14.0.20010815100613.033a7378@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 Aug 2001 10:10:28 -0700 To: Johan Ihren From: Alain Durand Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org In-Reply-To: <2clmklk436.fsf@snout.autonomica.se> References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <2361.997869643@brandenburg.cs.mu.OZ.AU> <20010815032134.A1896@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:30 PM 8/15/2001 +0200, Johan Ihren wrote: > > There's no reason why it can't be a gradual upgrade. Authoritative > > servers for zones with A6 can do AAAA synthesis at query time just > > as easily as the local non-stub resolver can. It becomes a server-side > > indirection mechanism, which is available to A6-grokking caches. > >This is *wrong*. > >An authoritative, non-recursive server with only A6 fragments around >can not synthesise the AAAA since that would require it to query for >missing fragments. Those fragments could be provided (or queried) when the server is started. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 10:12:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FHBuX14076 for ipng-dist; Wed, 15 Aug 2001 10:11:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FHBqD14069 for ; Wed, 15 Aug 2001 10:11:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22119 for ; Wed, 15 Aug 2001 10:11:53 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03726 for ; Wed, 15 Aug 2001 11:12:06 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7FHBqT02823; Wed, 15 Aug 2001 10:11:52 -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 ACR18276; Wed, 15 Aug 2001 10:11:35 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA17854; Wed, 15 Aug 2001 10:11:35 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15226.44359.301654.186683@thomasm-u1.cisco.com> Date: Wed, 15 Aug 2001 10:11:35 -0700 (PDT) To: Brian E Carpenter Cc: Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] In-Reply-To: <3B7AAA08.C2211D49@hursley.ibm.com> References: <200108151646.MAA16236@castillo.torrentnet.com> <3B7AAA08.C2211D49@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Excellent summary. We originally chose a 6 bit diffserv field partly because > it was available in both IPv4 and IPv6, and partly because it allows for > very efficient classification in *core* routers, with the more demanding > multi-field classification being left to border routers. > > The question before the house (in the end that means both ipng and diffserv) > is whether the added complexity of adding the flow label to the diffserv > model is justified by the gain in expressiveness. It doesn't do anything > for the trust model. I haven't heard about any imminent shortage of DSCP's. Indeed, it seems that there's only a small handful (2-6) that I've ever heard people contemplating. Maybe I just don't travel in the right circles... Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 10:40:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FHdfK14156 for ipng-dist; Wed, 15 Aug 2001 10:39:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FHdbD14149 for ; Wed, 15 Aug 2001 10:39:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29361 for ; Wed, 15 Aug 2001 10:39:39 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24513 for ; Wed, 15 Aug 2001 11:39:35 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f7FHdV821178; Wed, 15 Aug 2001 19:39:32 +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 TAA20180; Wed, 15 Aug 2001 19:39:31 +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.11.3/8.11.3) with ESMTP id f7FHdUl05178; Wed, 15 Aug 2001 19:39:31 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108151739.f7FHdUl05178@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Thu, 16 Aug 2001 01:37:28 +0900. Date: Wed, 15 Aug 2001 19:39:30 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Aside from this particular issue, it seems that MIB guys also want zone IDs that can identify particular scope types. => ah! They want zone IDs which stand by themselves. This should basically be the same idea as B. So I guess supporters of B do not oppose to this (I hope not, actually). => no opposition! Where I can sign? (:-) Can we (especially those who support C) make a compromise on this with this plan? => I believe C is not for the basic API but we can open a new activity about C in the advanced API (C people will propose things, A people will reject proposals which are not useful, B people will take holidays :-)? Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 10:41:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FHf1V14187 for ipng-dist; Wed, 15 Aug 2001 10:41:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FHeYD14167; Wed, 15 Aug 2001 10:40:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06790; Wed, 15 Aug 2001 10:40:35 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15935; Wed, 15 Aug 2001 10:40:35 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7FHeXm10084; Wed, 15 Aug 2001 10:40:33 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7FHeXK06094; Wed, 15 Aug 2001 10:40:33 -0700 Message-Id: <200108151740.f7FHeXK06094@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 15 Aug 2001 10:40:32 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <3255.997887397@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at Aug 15, 2001 09:56:37 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % a big enough fraction of sites to make it actually useful), sticking % idn labels directly in the DNS (and having the app protocols deal with % that), and using A6 rather than AAAA. % % The last we can choose to do now, it is still possible. The others we % could choose to do, but I doubt they'd ever actually work (idn just % maybe, with enough pressure - as comparatively little actually cares, % whatever the standards say). % % | Or am I reading too much into your statements? % % Perhaps. % % kre Ah... the light (well a light) is illuminated. We are in agreement save on two points: - the viablity of transition - the timeframe of transition Transition viability is debatable, the key point seems to be the window in which the transition occurs. You are arguing for a fairly short schedule and I think this can be streched out some -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 10:42:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FHg4h14222 for ipng-dist; Wed, 15 Aug 2001 10:42:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FHfeD14200; Wed, 15 Aug 2001 10:41:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29799; Wed, 15 Aug 2001 10:41:42 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26167; Wed, 15 Aug 2001 11:41:38 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7FHfXm10382; Wed, 15 Aug 2001 10:41:33 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7FHfXE06102; Wed, 15 Aug 2001 10:41:33 -0700 Message-Id: <200108151741.f7FHfXE06102@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: ahu@ds9a.nl (bert hubert) Date: Wed, 15 Aug 2001 10:41:28 -0700 (PDT) Cc: kre@munnari.OZ.AU (Robert Elz), bmanning@ISI.EDU (Bill Manning), ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <20010815172026.K28995@fork.powerdns.com> from "bert hubert" at Aug 15, 2001 05:20:26 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % On Wed, Aug 15, 2001 at 09:56:37PM +0700, Robert Elz wrote: % > Date: Wed, 15 Aug 2001 06:00:34 -0700 (PDT) % > From: Bill Manning % > Message-ID: <200108151300.f7FD0YH05643@zed.isi.edu> % > % > | Then the Internet is doomed. Either evolution or revolution. % > % > In some places, revolution is all that is possible. The evolutionary % > step is just too big to every take. % % I'm butting in here, but it may be interesting to know that quite a number % of the top-100 resolving nameserver installations out there are still % running Bind4! I'm doing some research on the big resolvers out there, % especially the (non-)randomness of the id field. % % Some of these people have gone through great lengths to remain at Bind4, % even though they run late breaking operating system releases. % % Regards, % % bert hubert I'd like to compare numbers. -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 12:12:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FJBnR14619 for ipng-dist; Wed, 15 Aug 2001 12:11:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FJBjD14612 for ; Wed, 15 Aug 2001 12:11:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02345 for ; Wed, 15 Aug 2001 12:11:46 -0700 (PDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA09863 for ; Wed, 15 Aug 2001 13:11:42 -0600 (MDT) Received: from 157.54.9.108 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 15 Aug 2001 12:11:30 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 Aug 2001 12:11:20 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 Aug 2001 12:11:19 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 Aug 2001 12:11:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Wrap up and last call: sin6_scope_id semantics Date: Wed, 15 Aug 2001 12:11:12 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B58142@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wrap up and last call: sin6_scope_id semantics thread-index: AcElseE9gFYsUlghR7uRwG5WYmrpYwAC5Daw From: "Dave Thaler" To: "Francis Dupont" , "JINMEI Tatuya / ????" Cc: X-OriginalArrivalTime: 15 Aug 2001 19:11:12.0477 (UTC) FILETIME=[0C60D0D0:01C125BE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7FJBkD14613 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, August 15, 2001 10:40 AM > To: JINMEI Tatuya / ???? > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Wrap up and last call: sin6_scope_id semantics > > In your previous mail you wrote: > > Aside from this particular issue, it seems that MIB guys also want > zone IDs that can identify particular scope types. > > => ah! They want zone IDs which stand by themselves. Yes, where you have a zone ID without an address. > This should basically be the same idea as B. So I guess supporters of > B do not oppose to this (I hope not, actually). > > => no opposition! Where I can sign? (:-) Same for supporters of C. (But yes, this is one of the reasons A is at the very bottom of my list). > Can we (especially those who support C) make a compromise on this with > this plan? Sorry, what was "this"? > => I believe C is not for the basic API but we can open a new activity > about C in the advanced API (C people will propose things, A people will > reject proposals which are not useful, B people will take holidays :-)? If B were the standard interoperable thing, but C would also be legal behavior (since it's a superset of B behavior) for an implementation, that would be fine by me. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 13:30:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FKUAH14789 for ipng-dist; Wed, 15 Aug 2001 13:30:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FKU7D14782 for ; Wed, 15 Aug 2001 13:30:07 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18978 for ; Wed, 15 Aug 2001 13:30:07 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17676 for ; Wed, 15 Aug 2001 13:30:07 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7FKU5m25027; Wed, 15 Aug 2001 13:30:05 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7FKU5L06387; Wed, 15 Aug 2001 13:30:05 -0700 Message-Id: <200108152030.f7FKU5L06387@zed.isi.edu> Subject: why A6 might be harder to deploy To: kre@munnari.OZ.AU Date: Wed, 15 Aug 2001 13:30:04 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com, dnsop@cafax.se X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk cc list trimed: A couple of other considerations: After IETF49, we held a ws that ran DNS on v6 transport. We tried A6 & AAAA records in the context of the DNS root. Dales notes reflect that FreeBSD's resolver was unable to recognise an A6 record when it was "glue" for a root server. It was able to recognise a AAAA record. This has not been rechecked to my knowledge. This is also applicable between the servers for a zone. In a mixed environment, it is possible to have servers running a variety of code, from Bind4, Bind8, Bind9 and even some of the other genetic varients (Microsoft, Lucent, PowerDNS, Akami, et.al.) Indeed, this is one of the strengths of the DNS. And in such clusters, RR 28 is well known and is passed around. If an NS records "glue" is type 28, zone transfers will occur. However nearly none of these versions/varients knows or supports type 38. And given the strict checking, for coherancy, in most of the recent code, if the glue for an NS is type 38, the zone transfer will -fail- That seems to indicate that if type 38 is to be used, all the servers for the zone in which they reside must be running code from a single branch. (the unknown RR type problem) And there are indications that that particular branch is not all that speedy. Some numbers I have seen indicate the QPS rate is about 50% less than the previous branch. Are we really ready to take that performance hit to gain A6 support? Random idea... Presume 10,000 v6 users today. If we give them AAAA now, and agressively explore/test A6, on the experimental track for 12-18 months, we might presume there would be 1,000,000 v6 users by then. That is still statistically "small" as an installed base and we would have a much stronger case that A6 performance issues are addressed, A4synth could be better understood, and operational tools are available. If we put forth the effort, it should be a no brainer to push it back on stds track and consider moving AAAA to historic (sort of like RIPv1 is historic... people still build it and use it. :) The installed base is still small enough that we can make the change... I think. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 14:27:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLQVx14949 for ipng-dist; Wed, 15 Aug 2001 14:26:31 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLQTD14942 for ; Wed, 15 Aug 2001 14:26:29 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLObi25901 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:24:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F3tAD10901 for ; Tue, 14 Aug 2001 20:55:10 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14149 for ; Tue, 14 Aug 2001 20:55:12 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12177 for ; Tue, 14 Aug 2001 20:55:11 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id UAA05470; Tue, 14 Aug 2001 20:48:22 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 14 Aug 2001 20:48:21 -0700 (PDT) From: Bernard Aboba To: stefano.faccin@nokia.com cc: aaa-wg@merit.edu, deering@cisco.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <82ECD4351A4A9547957C606034A3CB8D0B01A8@daebe005.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I also understand your concern about the relation between new > applications and protocols defined in other WGs that have not been > closed completely yet. > > I believe the title of the draft may be misleading and for > this reason is going to be changed and the draft re-submitted. In fact, > the draft applies in general to the support through the AAA Diameter > infrastructure of authorization of network access for IPv6 nodes, > authentication of the IPv6 node and key distribution for the IPv6 node. Has this draft been presented within the IPNG WG? Since IPv6 architecture occurs within IPNG WG, the proposed IPv6/AAA authentication architecture would need to be presented and gain consensus within the IPNG WG before a AAA WG work item could be considered. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:27:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLQq614958 for ipng-dist; Wed, 15 Aug 2001 14:26:52 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLQnD14951 for ; Wed, 15 Aug 2001 14:26:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLOvU25931 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:24:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F8uUD11898; Wed, 15 Aug 2001 01:56:30 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26854; Wed, 15 Aug 2001 01:56:31 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01340; Wed, 15 Aug 2001 01:56:29 -0700 (PDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id E64481ED08; Wed, 15 Aug 2001 09:34:23 +0200 (CEST) To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010814133749.B56A77BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 09:34:23 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Tue, 14 Aug 2001 22:37:49 +0900" Message-ID: <2czo91kc8w.fsf@snout.autonomica.se> Lines: 73 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino writes: > >If we look at DNS configuration for the v6 part of the world it is at > >present based upon various kinds of ugliness to get around the fact > >that there is almost no hierarchy deployed over v6 transport (starting > >with the lack of roots accessible over v6 transport). > > > >The most common is to use a forwarding configuration to escape over to > >the v4 transport universe with full DNS connectivity. > > > >*All* this will have to change over the coming years if or when or > >wherever we decide to start deploying roots accessible over v6 > >transport. > > I don't get your argument at all. > > Because first part of the IPv6 transition will be toward IPv4/v6 > dual stack, AAAA over IPv4 transport works just fine for us. > The history proves that it works fine for us - due to the lack of > IPv6 accessible root, IPv6 accessible ccTLD/gTLD, and lack of IPv6 > NS record registration support by many of the registries, we IPv6 > users are forced to rely upon IPv4 DNS infrastructure. Luckily, > it works quite well. > > total transition to AAAA (or A6) over IPv6 transport is of course > better, however, it needs a major upgrades, including: > - IPv6-ready root > - IPv6-ready ccTLD and gTLD > - IPv6-ready random .com servers > all of them needs to be done before the total transition, so it is > unrealistic to talk about total transition this time. > > So, what I'm saying is, AAAA deployment is already so wide enough > (all BIND4/8/9 do support them okay), and for me it is way too late > already to transition to anything else (including A6). If we are > to transition to something other than AAAA, the transition needs to > be coordinated very delicately, like transition from IPv4 to IPv6 > and it will take multiple years to do so. We cannot wait any more. > > Think DNS transport issue (DNS over IPv6, or IPv4) and DNS payload > issue (AAAA, A or A6) separately. What we are talking about is > mainly the payload issue, though, it affects the deployment of > the IPv6 DNS transport (as NS records need to point to AAAA, or A6). > I guess you are mixing up these two. No, I am not mixing them up. I'm pointing out that due to the configuration change that will follow from deployment of v6 roots it will be comparatively easy to reach all the caching resolvers (i.e. name servers) on v6 transport to ensure that they all do AAAA synthesis. I agree that this will not by itself help the deployed base of AAAA-aware, A6-ignorant caching resolvers that are v4 single stack. Furthermore there are obvious problems with doing AAAA synthesis in response to non-recursive AAAA queries, so we cannot shield those servers easily by doing the synthesis in the authoritative end. However, while agreeing that the deployed base of AAAA-aware caching resolvers on the IPv4-only Internet is large it is less clear to me how many of those actually care about v6 address records at all. Nor is it clear how many of those that will start to care before having upgraded their name server software (which contrary to popular belief actually happens, although certainly not to all of them). It is certainly a non-trivial number, but as Bill touched upon, somewhere there is a price to evolution, and I much rather have it there (among v4-only servers not caring about v6) than tying the hands of people that care very much about IPv6. Johan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:27:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLRGe14973 for ipng-dist; Wed, 15 Aug 2001 14:27:16 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLRDD14966 for ; Wed, 15 Aug 2001 14:27:13 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLPLB25961 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:25:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F9uwD12026; Wed, 15 Aug 2001 02:56:58 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01753; Wed, 15 Aug 2001 02:57:00 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21323; Wed, 15 Aug 2001 02:56:58 -0700 (PDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 27C441ED08; Wed, 15 Aug 2001 11:57:01 +0200 (CEST) To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010815085732.742B37BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 11:57:01 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 17:57:32 +0900" Message-ID: <2cpu9xk5n6.fsf@snout.autonomica.se> Lines: 45 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino writes: Hi Itojun, > >I'm pointing out that due to the configuration change that will follow > >from deployment of v6 roots it will be comparatively easy to reach all > >the caching resolvers (i.e. name servers) on v6 transport to ensure > >that they all do AAAA synthesis. > > isn't it just a root.hint change, not a server replacement? Well, if you are running in a forwarding configuration *with your present server* and replace the root.hint file with one that includes v6 glue for one or several roots not much will happen. So there is no point to it. Because you are using a forwarding configuration. However, what you want is a root accessible over v6 transport (and of course all the TLDs, etc, etc) so that you can move away from your forwarding configuration. However, to avoid walking around in a barren wasteland of almost no DNS hierarchy initially I strongly suspect that you would like some sort of fallback mechanism so that you can still get to the data that is presently only available over v4 transport. But to do that you *will* need a server replacement, since no server deployed does that today. There are various icky schemes for doing such transport bridging (Alain Durand and I have spent some time in that mess and there is a draft outlining some of the problems). All of these schemes are ugly, but without something like that I see little point to the v6 roots that you want. So, I still claim that the time of deployment of v6 glue for the first root is a "magic date" since that will initiate a configuration change and in all likelihood a server replacement for all the v6 caching resolvers that want to utilize this v6 root for anything useful. Look at it as a synchronization barrier for IPv6 DNS functionality. Johan Ihren -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:28:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLRYU14998 for ipng-dist; Wed, 15 Aug 2001 14:27:34 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLRVD14991 for ; Wed, 15 Aug 2001 14:27:31 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLPdH25991 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:25:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FAUcD12205; Wed, 15 Aug 2001 03:30:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04796; Wed, 15 Aug 2001 03:30:34 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14236; Wed, 15 Aug 2001 03:30:33 -0700 (PDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 766421ED08; Wed, 15 Aug 2001 12:30:37 +0200 (CEST) To: David Terrell Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <200108141416.f7EEGbY03659@zed.isi.edu> <200108141416.f7EEGbY03659@zed.isi.edu> <5.1.0.14.0.20010814140706.01aa6d98@jurassic> <2361.997869643@brandenburg.cs.mu.OZ.AU> <20010815032134.A1896@pianosa.catch22.org> From: Johan Ihren Date: 15 Aug 2001 12:30:37 +0200 In-Reply-To: David Terrell's message of "Wed, 15 Aug 2001 03:21:35 -0700" Message-ID: <2clmklk436.fsf@snout.autonomica.se> Lines: 23 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Terrell writes: > > But there's no way to get everyone to have it - which means that > > administrators will always have to add AAAA records so those people > > can find their web server, mail server, .... And if AAAA records > > have to exist, and resolvers will be looking for them (because no > > way are all servers going to start supplying A6 all at once, even > > with a fairly broad concept of the time quantum) then there's no > > point adding A6 records at all - they'd be just one more thing that > > has to be maintained (excess duplicate data). > > There's no reason why it can't be a gradual upgrade. Authoritative > servers for zones with A6 can do AAAA synthesis at query time just > as easily as the local non-stub resolver can. It becomes a server-side > indirection mechanism, which is available to A6-grokking caches. This is *wrong*. An authoritative, non-recursive server with only A6 fragments around can not synthesise the AAAA since that would require it to query for missing fragments. Johan Ihren -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:28:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLRrO15009 for ipng-dist; Wed, 15 Aug 2001 14:27:53 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLRnD15002 for ; Wed, 15 Aug 2001 14:27:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLPvs26021 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:25:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FBRAD12386; Wed, 15 Aug 2001 04:27:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09184; Wed, 15 Aug 2001 04:27:10 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA29720; Wed, 15 Aug 2001 05:27:21 -0600 (MDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 070A61ED08; Wed, 15 Aug 2001 13:27:07 +0200 (CEST) To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010815100852.480907BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 13:27:07 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 19:08:52 +0900" Message-ID: <2chev9k1h0.fsf@snout.autonomica.se> Lines: 25 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino writes: > >> >I'm pointing out that due to the configuration change that will follow > >> >from deployment of v6 roots it will be comparatively easy to reach all > >> >the caching resolvers (i.e. name servers) on v6 transport to ensure > >> >that they all do AAAA synthesis. > >> isn't it just a root.hint change, not a server replacement? > >Well, if you are running in a forwarding configuration *with your > >present server* and replace the root.hint file with one that includes > >v6 glue for one or several roots not much will happen. So there is no > >point to it. > > > >Because you are using a forwarding configuration. > > I don't understand what you are saying, AT ALL. I'm not using > forwarding configuration. you must have some assumption in > your head which is not presented here. Ok. Before I repeat the mistake of guessing at your configuration I suggest you tell me about it. Personally I use a forwarding config for v6-only nameservers and I believe that this is by far the most common case. Johan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:29:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLSDB15027 for ipng-dist; Wed, 15 Aug 2001 14:28:13 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLS8D15018 for ; Wed, 15 Aug 2001 14:28:08 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLQGA26051 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:26:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FD2XD12868; Wed, 15 Aug 2001 06:02:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16217; Wed, 15 Aug 2001 06:02:34 -0700 (PDT) Received: from nara.off.connect.com.au (nara.off.connect.com.au [192.94.41.40]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06281; Wed, 15 Aug 2001 07:02:25 -0600 (MDT) Received: (from njones@localhost) by nara.off.connect.com.au id WAA23689 (8.8.8/IDA-1.7); Wed, 15 Aug 2001 22:54:28 +1000 (EST) Message-ID: <20010815225428.A11162@connect.com.au> Date: Wed, 15 Aug 2001 22:54:28 +1000 From: Nathan Jones To: Jun-ichiro itojun Hagino , Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2674.997874182@brandenburg.cs.mu.OZ.AU> <20010815114010.CA9C17BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20010815114010.CA9C17BA@starfruit.itojun.org>; from Jun-ichiro itojun Hagino on Wed, Aug 15, 2001 at 08:40:10PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun wrote: > you should care about this. there's no guarantee that AAAA synthesis > happen between end client and master/slave nameservers. AAAA will > leak from leaf to the core. David Terrell's suggestion that AAAA synth be performed by nameservers which are authoritative for zones with A6 data seems worth considering here. DNS admins can then use A6 without fear that their hosts will not be found. Over time, the authoritative nameserver will not have to synthesise AAAA records as frequently, as it will receive more requests for A6 RRs. This increase in A6 requests will come from the normal uptake of resolvers that support A6 and perform AAAA synth for the remaining base of non-A6 stub resolvers. > if people query both AAAA and A6, there will be more delays. People won't always query both RR types. The idea of transition is to move to A6; once there is wide spread use of A6 records and resolvers that query for A6 records, there won't be frequent querying for both. >> | (3b) server admins need to maintain both A6 and AAAA in zoen file, >> | which is unhappy. >>No, only A6 records, that's what AAAA synthesis is all about, remember... > > you seem to be assuming that there's some AAAA synthesis server > between IPv6 end node and nameservers. your assumption does not hold, > especially during the transition period. because the assumption > does not hold, zone admins need to maintain AAAA records too. It is only during the transition period that this assumption does not hold true. The result of the transition is that there is an AAAA synth server between the IPv6 end node and the nameserver. It is only during the transition that AAAA records will be maintained alongside A6 records. (And once again, if you run a nameserver that can do AAAA synth, then you don't even need to maintain AAAA records too.) Lastly, there seems to be a number of people here supporting A6 in principle, but saying that we should shelve the idea now and consider it later. Surely it is preferable to follow those principles now, rather than putting the idea in the "too hard basket"... -- njones -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:29:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLSUJ15043 for ipng-dist; Wed, 15 Aug 2001 14:28:30 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLSQD15036 for ; Wed, 15 Aug 2001 14:28:26 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLQYg26081 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:26:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FDGQD12909; Wed, 15 Aug 2001 06:16:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17529; Wed, 15 Aug 2001 06:16:23 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15660; Wed, 15 Aug 2001 07:16:34 -0600 (MDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 841331ED08; Wed, 15 Aug 2001 15:16:12 +0200 (CEST) To: Jun-ichiro itojun Hagino Cc: "Tony Hain" , "Nathan Jones" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010815113609.84BB87BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 15:16:12 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 20:36:09 +0900" Message-ID: <2c66bpjwf7.fsf@snout.autonomica.se> Lines: 70 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino writes: > >Ok. Before I repeat the mistake of guessing at your configuration I > >suggest you tell me about it. > > > >Personally I use a forwarding config for v6-only nameservers and I > >believe that this is by far the most common case. > > I have been talking about a nameserver, with root.hint, on > IPv4/v6 dual stack machine. to be more precise, see below. > > I never have talked about nameservers on IPv6-only machine, > they will never work without some help from IPv4/v6 dual stack > nameserver. (and it is rather unrealistic to talk about > nameeservers in IPv6-only network today...) Ok, we were clearly talking about different things. And this further clarifies the initial difference in opinion on the size of the deployed base of full-service resolvers that are IPv6-aware and -caring. The issue with roots available over v6 transport was mostly a side track that was relevant only for the subset of full-service resolvers that are v6-only. As to whether it is unrealistic to talk about name servers on IPv6-only networks or not, I still argue that although they are a small base today (which we now agree upon) they will be the dominant species at some point in the future. And now is the time we have to decide how the world they will populate should work. But the core issue is still whether it is too late to upgrade the deployed full-service resolvers to do AAAA synthesis or not. And if not too late then how long it will take. I think that given a clear decision (which seems impossible) this could be fairly rapid for the full-service resolvers that actually see real traffic since they are almost certainly to a large degree waiting for the outcome of this A6/AAAA commotion. And given A6, that would not delay deployment [of IPv6], since new deployment would have the benefit of doing it right [i.e. A6] from the outset thereby rapidly creating even more incentive for the installed base (i.e. the dual-stack or forwarding servers, all of them bind9) to upgrade. It is important to weigh in the difficulties of pushing a deployed base to upgrade. But in this particular case I worry that that problem unnecessarily may be overshadowing the design issues. Anyone that presently operate a dual-stack server or a forwarding server with only v6 transport and isn't aware that there are unsolved problems with DNS for IPv6 and that it will in all likelihood be necessary to change configs/upgrade software/modify tools/etc is not really on top of his or her responsibilities. Fortunately, since we are still in the early days, I really think they constitute a small minority. The rest, regardless of their position on the A6/AAAA issue, are at least fully aware that such issues *exist* and hence aware that they will possibly have to change stuff somewhat as those issues get resolved. The v4-only-dont-care-about-v6-although- their-resolver-groks-aaaa is a different story, but I care less about breaking lookups of v6 records for them. So, to my mind, A6 would not necessarily delay deployment of IPv6 significantly. What is clearly delaying deployment is lack of consensus. But I don't know. It has to be a judgement call. Johan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:29:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLSnl15054 for ipng-dist; Wed, 15 Aug 2001 14:28:49 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLSkD15047 for ; Wed, 15 Aug 2001 14:28:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLQsr26111 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:26:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FDLKD12952; Wed, 15 Aug 2001 06:21:20 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27931; Wed, 15 Aug 2001 06:21:22 -0700 (PDT) Received: from nara.off.connect.com.au (nara.off.connect.com.au [192.94.41.40]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28063; Wed, 15 Aug 2001 06:21:20 -0700 (PDT) Received: (from njones@localhost) by nara.off.connect.com.au id XAA23898 (8.8.8/IDA-1.7); Wed, 15 Aug 2001 23:13:38 +1000 (EST) Message-ID: <20010815231337.B11162@connect.com.au> Date: Wed, 15 Aug 2001 23:13:37 +1000 From: Nathan Jones To: Jun-ichiro itojun Hagino , Robert Elz Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2962.997878628@brandenburg.cs.mu.OZ.AU> <20010815123411.E40457BA@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20010815123411.E40457BA@starfruit.itojun.org>; from Jun-ichiro itojun Hagino on Wed, Aug 15, 2001 at 09:34:11PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Aug 15, 2001 at 09:34:11PM +0900, Jun-ichiro itojun Hagino wrote: > transition them into some other record type in one night. you have > been proposing a migration path with a hard "flag day", with: I don't recall anyone saying that this needs to be an instant change. I do recall people saying that A6 has merit and that it is worth the effort to migrate. The whole idea of transition mechanisms like AAAA synth is to allow gradual adoption of A6 as people start adopting A6. Obviously there will be a transition period during which members of the existing (comparatively small) IPv6 community will either provide both AAAA and A6, or run DNS software that can synthesise AAAA RRs to serve requests from other existing IPv6 users. > - all existing zone files must be rewritten to from AAAA to A6 in one > night (of which timezone?) > - all AAAA queriers can stay as is, but there has to be AAAA synthesis > server at every leaf > - no AAAA traffic in core DNS cloud, only A6 traffic. These claims seem to stem from either disbelieve that the transition can be made, or from desire to stop A6 regardless of its merits. >itojun@tired. :-) -- nathanj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:29:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLT8v15072 for ipng-dist; Wed, 15 Aug 2001 14:29:08 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLT4D15063 for ; Wed, 15 Aug 2001 14:29:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLRCC26141 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:27:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FDfhD13038; Wed, 15 Aug 2001 06:41:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10498; Wed, 15 Aug 2001 06:41:44 -0700 (PDT) Received: from nara.off.connect.com.au (nara.off.connect.com.au [192.94.41.40]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26948; Wed, 15 Aug 2001 07:41:49 -0600 (MDT) Received: (from njones@localhost) by nara.off.connect.com.au id XAA24251 (8.8.8/IDA-1.7); Wed, 15 Aug 2001 23:33:56 +1000 (EST) Message-ID: <20010815233355.C11162@connect.com.au> Date: Wed, 15 Aug 2001 23:33:55 +1000 From: Nathan Jones To: Bill Manning , kre@munnari.OZ.AU Cc: Alain Durand , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2361.997869643@brandenburg.cs.mu.OZ.AU> <200108151300.f7FD0YH05643@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <200108151300.f7FD0YH05643@zed.isi.edu>; from Bill Manning on Wed, Aug 15, 2001 at 06:00:34AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Aug 15, 2001 at 06:00:34AM -0700, Bill Manning wrote: > Then the Internet is doomed. Either evolution or revolution. > Either the right way or an incremental hack, a goiter, that > we can never get rid of. I don't think kre is opposing evolution here; simply saying that we should assist evolution by doing it now while it's easier. >% eg: now the DNS has SRV records, they do so everything that MX can do, >% and more. In a way they're the analog of A6 and AAAA (MX is a subset of >% SRV). There would be benefits to converting SMTP to use SRV instead of >% MX. Can you imagine anyone seriously suggesting that that happen however? >% Can you really imagine that there'd ever be a day when we could deprecate >% the MX record? > > Yes I can see it. We've done it before. VJC is yet another > example. I can see that it is possible to convert SMTP to use SRV records, but the required transition time would be tremendous. The same applies to a transition from AAAA to A6 years down the track. > Heck, we might even replace SMTP. Isn't that revolutionary rather than evolutionary? :-) > Yet another hack, like mobilip & IDN. Why have a hack, when we can do it right the first time? You seem to be implying... > You seem unwilling to do the right thing in favor of what > looks like the expediant thing. Or am I reading too much > into your statements? ...that implementing A6 is the wrong thing to do. Wrong for what solid reasons? (Leaving transition "woes" out of the debate for a moment.) Wrong because AAAA has an advantage over A6? If so, what advantage? If it is not wrong, then why move it off the standards track? -- nathanj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:30:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLU8315119 for ipng-dist; Wed, 15 Aug 2001 14:30:08 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLU5D15112 for ; Wed, 15 Aug 2001 14:30:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLSDk26171 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:28:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FDnYD13085; Wed, 15 Aug 2001 06:49:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00999; Wed, 15 Aug 2001 06:49:36 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00492; Wed, 15 Aug 2001 07:49:45 -0600 (MDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 48E051ED08; Wed, 15 Aug 2001 15:49:26 +0200 (CEST) To: Jun-ichiro itojun Hagino Cc: Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <20010815123411.E40457BA@starfruit.itojun.org> From: Johan Ihren Date: 15 Aug 2001 15:49:26 +0200 In-Reply-To: Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 21:34:11 +0900" Message-ID: <2c1ymdjuvt.fsf@snout.autonomica.se> Lines: 13 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino writes: > the story applies only if we are going to move to A6 + AAAA synthesis. > if we don't migrate, we have no worry and everyone is happy. I'm not! Johan PS. Sorry about that, but I simply could not resist that response in the grand tradition of the british Monty Python-comedians... now back to our regular programme of intense disagreements ;-) From owner-ipng@sunroof.eng.sun.com Wed Aug 15 08:20:40 2001 Return-Path: Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FFKdg223358 for ; Wed, 15 Aug 2001 08:20:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FFKc213615; Wed, 15 Aug 2001 08:20:38 -0700 (PDT) Date: Wed, 15 Aug 2001 08:20:38 -0700 (PDT) From: owner-ipng@sunroof.eng.sun.com Message-Id: <200108151520.f7FFKc213615@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from [bert hubert ] Content-Length: 2406 Status: RO X-Status: $$$$ X-UID: 0000000047 From owner-ipng Wed Aug 15 08:20:34 2001 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FFKXD13608 for ; Wed, 15 Aug 2001 08:20:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12112 for ; Wed, 15 Aug 2001 08:20:33 -0700 (PDT) Received: from fork.powerdns.com (fork.powerdns.com [213.244.168.244]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA00835 for ; Wed, 15 Aug 2001 08:20:32 -0700 (PDT) Received: (qmail 3129 invoked by uid 1011); 15 Aug 2001 15:20:26 -0000 Date: Wed, 15 Aug 2001 17:20:26 +0200 From: bert hubert To: Robert Elz Cc: Bill Manning , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010815172026.K28995@fork.powerdns.com> Mail-Followup-To: bert hubert , Robert Elz , Bill Manning , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se References: <200108151300.f7FD0YH05643@zed.isi.edu> <3255.997887397@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3255.997887397@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Wed, Aug 15, 2001 at 09:56:37PM +0700 On Wed, Aug 15, 2001 at 09:56:37PM +0700, Robert Elz wrote: > Date: Wed, 15 Aug 2001 06:00:34 -0700 (PDT) > From: Bill Manning > Message-ID: <200108151300.f7FD0YH05643@zed.isi.edu> > > | Then the Internet is doomed. Either evolution or revolution. > > In some places, revolution is all that is possible. The evolutionary > step is just too big to every take. I'm butting in here, but it may be interesting to know that quite a number of the top-100 resolving nameserver installations out there are still running Bind4! I'm doing some research on the big resolvers out there, especially the (non-)randomness of the id field. Some of these people have gone through great lengths to remain at Bind4, even though they run late breaking operating system releases. Regards, bert hubert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 14:31:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7FLUE715128 for ipng-dist; Wed, 15 Aug 2001 14:30:14 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FLUAD15121 for ; Wed, 15 Aug 2001 14:30:11 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7FLSI626201 for ipng@sunroof.eng.sun.com; Wed, 15 Aug 2001 14:28:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FFKXD13608 for ; Wed, 15 Aug 2001 08:20:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12112 for ; Wed, 15 Aug 2001 08:20:33 -0700 (PDT) Received: from fork.powerdns.com (fork.powerdns.com [213.244.168.244]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA00835 for ; Wed, 15 Aug 2001 08:20:32 -0700 (PDT) Received: (qmail 3129 invoked by uid 1011); 15 Aug 2001 15:20:26 -0000 Date: Wed, 15 Aug 2001 17:20:26 +0200 From: bert hubert To: Robert Elz Cc: Bill Manning , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010815172026.K28995@fork.powerdns.com> Mail-Followup-To: bert hubert , Robert Elz , Bill Manning , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se References: <200108151300.f7FD0YH05643@zed.isi.edu> <3255.997887397@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3255.997887397@brandenburg.cs.mu.OZ.AU>; from kre@munnari.OZ.AU on Wed, Aug 15, 2001 at 09:56:37PM +0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Aug 15, 2001 at 09:56:37PM +0700, Robert Elz wrote: > Date: Wed, 15 Aug 2001 06:00:34 -0700 (PDT) > From: Bill Manning > Message-ID: <200108151300.f7FD0YH05643@zed.isi.edu> > > | Then the Internet is doomed. Either evolution or revolution. > > In some places, revolution is all that is possible. The evolutionary > step is just too big to every take. I'm butting in here, but it may be interesting to know that quite a number of the top-100 resolving nameserver installations out there are still running Bind4! I'm doing some research on the big resolvers out there, especially the (non-)randomness of the id field. Some of these people have gone through great lengths to remain at Bind4, even though they run late breaking operating system releases. Regards, bert hubert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 15 22:25:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7G5P6n15867 for ipng-dist; Wed, 15 Aug 2001 22:25:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7G5P2D15860 for ; Wed, 15 Aug 2001 22:25:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09102 for ; Wed, 15 Aug 2001 22:25:04 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA26111 for ; Wed, 15 Aug 2001 23:24:59 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id DC24A7BA; Thu, 16 Aug 2001 14:18:11 +0900 (JST) To: Alex Conta Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-reply-to: aconta's message of Wed, 15 Aug 2001 12:21:35 -0400. <3B7AA18F.AD8803E8@txc.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: [Fwd: draft-conta-ipv6-flow-label-02.txt] From: Jun-ichiro itojun Hagino Date: Thu, 16 Aug 2001 14:18:11 +0900 Message-Id: <20010816051812.DC24A7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I heard the presentation differently. in IETF51 presentation Alex >> Conta made the following proposals, at least: >> - putting PHB value >> not trustworthy. >The PHB is as trustworthy as anything else, including the pseudo-random >value. If a user can set values as pleases, it can do that with the >pseudo-random number as well. but if you look at the number as PHB, you are trusting that the originating system have put a meaningful, and correct, PHB. how can you be sure that the originating system is not cheating? >> - putting total extension header length >> if the originator lies about the value, intermediate routers >> can go panic. > >I disagree. > >"less than the size of the packet" is a simple, cheap, straight forward >validation test of the headers length, that would ensure that nothing >wrong can happen, regardless of memory being partioned and protected. I guess you are too optimistic. if you are using align-picky architecture CPU for your router, I can panic your router by putting some value that is not align-friendly into flow label field as the extension header length. >Even without the validation, the reduced number of bits available for >the length is forcing a reasonable limit on the length. The TCP/UDP >ports are accessed for "read", and the values are not used as pointers >or offsets. Assuming an implementation that enforces memory >partitioning, the "kernel" has most likely "read" access anywhere in >memory, so "memory access violation" is unlikely. I don't understand what you are trying to mean. regardless from read access or write access, your kernel can be tricked into: - accessing bits on a wrong boundary - accessing bits that are not a real port number I can trick the intermediate routers to believe that I'm using TCP port 80, while I'm actually using TCP port 22. >Also please note that the use of a total header length would not be >conceptually, and practically >different than IPv4. The IHL field in the IPv4 header includes the >length of the main header fields, and the IPv4 options. Some of the IPv4 >options are of a variable length. A variable size IPv4 option >carries a field indicating the length. We knew how to implement this >back many years ago, right?, so we should be able to implement this >carefully for IPv6, if need be. it is very different from IPv4 case. in IPv4 case, IHL field is the one and only field trustable, and there was no ambiguity. for IPv6 extension header length, the actual value is detected only by chasing header chain. your addition (of extension header length into flow label field) is a non-trustworthy copy of the real value. if your router believes that the value in flow label field, your router will get tricked. >> - putting port/addr/whatever encoded >> if the originator lies about the value, theft-of-service >> happens. >As said above, the security risk is not higher than with the >pseudo-random number. I don't believe so. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 15 23:16:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7G6Fxj15926 for ipng-dist; Wed, 15 Aug 2001 23:15:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7G6FtD15919 for ; Wed, 15 Aug 2001 23:15:55 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13441 for ; Wed, 15 Aug 2001 23:15:42 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17424 for ; Wed, 15 Aug 2001 23:15:41 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7G6F5c21725; Thu, 16 Aug 2001 09:15:05 +0300 Date: Thu, 16 Aug 2001 09:15:05 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: Jun-ichiro itojun Hagino , Brian E Carpenter , Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] In-Reply-To: <3B7AA18F.AD8803E8@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 15 Aug 2001, Alex Conta wrote: > >Jun-ichiro itojun Hagino wrote: > > > > >The traffic class field is not enough. If you have to re-classify traffic at > > >an administrative boundary, then by definition at that point the traffic class > > >field is inadequate; you need more information. The advantage that IPv6 has > > >is that even when the header is partly hidden by IPSEC, the flow label is > > >available to carry additional semantics. The actual proposal is to use the > > >PHB identifier which has end to end semantics. > > > > I heard the presentation differently. in IETF51 presentation Alex > > Conta made the following proposals, at least: > > - putting PHB value > > not trustworthy. > > The PHB is as trustworthy as anything else, including the pseudo-random > value. If a user can set values as pleases, it can do that with the > pseudo-random number as well. The user does not know which pseudo-random value to choose (2^19 or the like is lots..) to select to "steal specific kind of traffic", at least before you have indeed sent legally that kind of traffic and observed higher priority given to the that flow. If this were based on port numbers etc., the user could more easily guess/experiment with the behaviour, and set it as you please. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 16 06:39:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GDchO17616 for ipng-dist; Thu, 16 Aug 2001 06:38:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GDccD17609 for ; Thu, 16 Aug 2001 06:38:39 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17113 for ; Thu, 16 Aug 2001 06:38:43 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25898 for ; Thu, 16 Aug 2001 06:38:40 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA30070; Thu, 16 Aug 2001 14:38:37 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA41212; Thu, 16 Aug 2001 14:38:33 +0100 Message-ID: <3B7BCC98.D41BACA4@hursley.ibm.com> Date: Thu, 16 Aug 2001 08:37:28 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <200108151646.MAA16236@castillo.torrentnet.com> <3B7AAA08.C2211D49@hursley.ibm.com> <15226.44359.301654.186683@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: > > Brian E Carpenter writes: > > Excellent summary. We originally chose a 6 bit diffserv field partly because > > it was available in both IPv4 and IPv6, and partly because it allows for > > very efficient classification in *core* routers, with the more demanding > > multi-field classification being left to border routers. > > > > The question before the house (in the end that means both ipng and diffserv) > > is whether the added complexity of adding the flow label to the diffserv > > model is justified by the gain in expressiveness. It doesn't do anything > > for the trust model. > > I haven't heard about any imminent shortage of DSCP's. > Indeed, it seems that there's only a small handful > (2-6) that I've ever heard people contemplating. Maybe > I just don't travel in the right circles... We have deliberately been *very* conservative about defining standard PHBs, since we want to be very sure about what we standardise. But there are a potentially infinite number of local-use PHBs. That is why the DSCP value is mappable, and why the PHB ID was defined, so that local-use PHBs can be registered with IANA and signalled. The idea here is to stretch the semantics of the PHB ID just a little. Normal semantics of a PHB ID: "This is local-use PHB number 379" Stretched semantics: "This is local-use PHB number 379 and according to our SLA, that gets classified as real-time traffic needing at least a 10 Mbit/s rate" 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 Aug 16 06:42:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GDg4N17637 for ipng-dist; Thu, 16 Aug 2001 06:42:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GDg0D17630 for ; Thu, 16 Aug 2001 06:42:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13139 for ; Thu, 16 Aug 2001 06:42:04 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18842 for ; Thu, 16 Aug 2001 07:41:59 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA13302; Thu, 16 Aug 2001 14:42:01 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA15090; Thu, 16 Aug 2001 14:42:01 +0100 Message-ID: <3B7BCD64.1CA18DFD@hursley.ibm.com> Date: Thu, 16 Aug 2001 08:40:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <20010816051812.DC24A7BA@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino wrote: > > >> I heard the presentation differently. in IETF51 presentation Alex > >> Conta made the following proposals, at least: > >> - putting PHB value > >> not trustworthy. > >The PHB is as trustworthy as anything else, including the pseudo-random > >value. If a user can set values as pleases, it can do that with the > >pseudo-random number as well. > > but if you look at the number as PHB, you are trusting that the > originating system have put a meaningful, and correct, PHB. > how can you be sure that the originating system is not cheating? As I said, you don't care: they will pay the appropriate tariff for the PHB they request. It isn't the ISP's problem. For the other points, I agree with Itjun and perhaps disagree with Alex - there are some scary issues in playing with header length etc. Brian > > >> - putting total extension header length > >> if the originator lies about the value, intermediate routers > >> can go panic. > > > >I disagree. > > > >"less than the size of the packet" is a simple, cheap, straight forward > >validation test of the headers length, that would ensure that nothing > >wrong can happen, regardless of memory being partioned and protected. > > I guess you are too optimistic. if you are using align-picky > architecture CPU for your router, I can panic your router by putting > some value that is not align-friendly into flow label field as the > extension header length. > > >Even without the validation, the reduced number of bits available for > >the length is forcing a reasonable limit on the length. The TCP/UDP > >ports are accessed for "read", and the values are not used as pointers > >or offsets. Assuming an implementation that enforces memory > >partitioning, the "kernel" has most likely "read" access anywhere in > >memory, so "memory access violation" is unlikely. > > I don't understand what you are trying to mean. regardless from > read access or write access, your kernel can be tricked into: > - accessing bits on a wrong boundary > - accessing bits that are not a real port number > I can trick the intermediate routers to believe that I'm using > TCP port 80, while I'm actually using TCP port 22. > > >Also please note that the use of a total header length would not be > >conceptually, and practically > >different than IPv4. The IHL field in the IPv4 header includes the > >length of the main header fields, and the IPv4 options. Some of the IPv4 > >options are of a variable length. A variable size IPv4 option > >carries a field indicating the length. We knew how to implement this > >back many years ago, right?, so we should be able to implement this > >carefully for IPv6, if need be. > > it is very different from IPv4 case. in IPv4 case, IHL field is the > one and only field trustable, and there was no ambiguity. for IPv6 > extension header length, the actual value is detected only by chasing > header chain. your addition (of extension header length into flow > label field) is a non-trustworthy copy of the real value. if your > router believes that the value in flow label field, your router will > get tricked. > > >> - putting port/addr/whatever encoded > >> if the originator lies about the value, theft-of-service > >> happens. > >As said above, the security risk is not higher than with the > >pseudo-random number. > > I don't believe so. > > itojun -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 16 06:43:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GDhNL17655 for ipng-dist; Thu, 16 Aug 2001 06:43:23 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GDhID17648 for ; Thu, 16 Aug 2001 06:43:18 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7GDhC227110; Thu, 16 Aug 2001 15:43:12 +0200 (MET DST) Date: Thu, 16 Aug 2001 15:40:25 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Wrap up and last call: sin6_scope_id semantics To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Francis Dupont , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So, the basic idea is as follows: > > - take 4+28 split. > - actual mapping from zone to the 28 bit part does not matter, but it > should not change while the node is running (as discussed in this > thread) > - introduce "aliases" for numeric zone IDs to improve readability in > the textual representation. e.g. "link2" is an alias of a link ID > whose intra-link id is 2 (i.e. 0x20000002). "site4" is an alias of > a site ID whose intra-site id is 4 (i.e. 0x50000004). We now allow > fec0::1234%site4 as well as fec0::1234%1342177284 (1342177284=0x50000004) > - when a zone ID is used with an address (typically in the sockaddr_in6 > structure), the scope type of the ID must be equal to the scope type > of the address. Seems like, to the extent that there are existing applications which use if_nametoindex() -> sin6_scope_id for link-local addresses, we need to also support the top 4 being zero as an alias for the interface or link scope. Does anybody know of such applications? Does anybody know of applications doing the reverse (taking sin6_scope_id and passing it to if_indextoname())? If nobody on the list knows of such applications we could take the optimistic path and ignore the existence any such applications... Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 16 06:47:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GDkax17681 for ipng-dist; Thu, 16 Aug 2001 06:46:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GDkXD17674 for ; Thu, 16 Aug 2001 06:46:33 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08100 for ; Thu, 16 Aug 2001 06:46:37 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00279 for ; Thu, 16 Aug 2001 06:46:35 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA25576 for ; Thu, 16 Aug 2001 14:46:33 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA14852 for ; Thu, 16 Aug 2001 14:46:32 +0100 Message-ID: <3B7BCE71.BE8DB82E@hursley.ibm.com> Date: Thu, 16 Aug 2001 08:45:21 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng Subject: Higher level question about flow label Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the WG needs to decide once and for all whether the flow label is a) a CATNIP or MPLS-like routing handle or b) a QOS hint for intserv only or c) a QOS hint for intserv and diffserv or d) a waste of bits We can get back to the details once we have a consensus on this. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 16 07:28:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GESCL18237 for ipng-dist; Thu, 16 Aug 2001 07:28:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GES9D18230 for ; Thu, 16 Aug 2001 07:28:09 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14549 for ; Thu, 16 Aug 2001 07:28:11 -0700 (PDT) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18854 for ; Thu, 16 Aug 2001 07:28:10 -0700 (PDT) Received: from duplo.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.5/8.11.3) with ESMTP id f7GERxc16217; Thu, 16 Aug 2001 23:27:59 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.5/8.10.2) id f7GES3l01602; Thu, 16 Aug 2001 23:28:03 +0900 (JST) Date: Thu, 16 Aug 2001 23:28:03 +0900 (JST) From: Atsushi Onoe Message-Id: <200108161428.f7GES3l01602@duplo.sm.sony.co.jp> To: jinmei@isl.rdc.toshiba.co.jp Cc: Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: Your message of "Thu, 16 Aug 2001 01:37:28 +0900" References: X-Mailer: Cue version 0.6 (010815-1037/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - take 4+28 split. > - actual mapping from zone to the 28 bit part does not matter, but it > should not change while the node is running (as discussed in this > thread) > - introduce "aliases" for numeric zone IDs to improve readability in > the textual representation. e.g. "link2" is an alias of a link ID > whose intra-link id is 2 (i.e. 0x20000002). "site4" is an alias of > a site ID whose intra-site id is 4 (i.e. 0x50000004). We now allow > fec0::1234%site4 as well as fec0::1234%1342177284 (1342177284=0x50000004) > - when a zone ID is used with an address (typically in the sockaddr_in6 > structure), the scope type of the ID must be equal to the scope type > of the address. As I said at the meeting, I agree with the idea. Some isssues: - need to define the mapping between scope and top 4 bit? my guess is yes. MIB peaple may want to map a value into alias (e.g. "link") from a remote system. - should care existing implementations? yes. But I guess most of such applications use a interface index for scope_id, so it can be saved either: - assign scope value (4bit) 0 to link-local. or - implementation MAY accept the value 0 in implementation- specific manner, but SHOULD NOT return 0 for scope (4bit). - need to introduce new functions to map scope-name and the value? I hope not to define new functions, so want to _define_ the textual representation (e.g. "link", "site", ...) instead. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 16 07:31:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GEUrO18325 for ipng-dist; Thu, 16 Aug 2001 07:30:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GEUmD18318 for ; Thu, 16 Aug 2001 07:30:48 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25336; Thu, 16 Aug 2001 07:30:46 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24938; Thu, 16 Aug 2001 07:30:45 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:e99f:dffe:dce6:eef1]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA14112; Thu, 16 Aug 2001 23:33:57 +0900 (JST) Date: Thu, 16 Aug 2001 23:30:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Aug 2001 15:40:25 +0200 (CEST), >>>>> Erik Nordmark said: > Seems like, to the extent that there are existing applications > which use if_nametoindex() -> sin6_scope_id for link-local addresses, > we need to also support the top 4 being zero as an alias for the > interface or link scope. > Does anybody know of such applications? > Does anybody know of applications doing the reverse (taking sin6_scope_id > and passing it to if_indextoname())? Actually, since our (i.e. KAME/BSD's) getaddrinfo() and getnameinfo() use this mapping, all applications that use those two functions are affected, including ping, traceroute, ifconfig, netstat, route, telnet, ssh, ftp,... So we should probably provide some trick to ensure backward compatibility for such applications. 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 Aug 16 07:39:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GEcxd18430 for ipng-dist; Thu, 16 Aug 2001 07:38:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GEcsD18423 for ; Thu, 16 Aug 2001 07:38:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26223 for ; Thu, 16 Aug 2001 07:38:57 -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 IAA02275 for ; Thu, 16 Aug 2001 08:38:52 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:e99f:dffe:dce6:eef1]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA14232; Thu, 16 Aug 2001 23:42:00 +0900 (JST) Date: Thu, 16 Aug 2001 23:38:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Dave Thaler" Cc: "Francis Dupont" , Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1B58142@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1B58142@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 46 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 15 Aug 2001 12:11:12 -0700, >>>>> "Dave Thaler" said: >> This should basically be the same idea as B. So I guess supporters > of >> B do not oppose to this (I hope not, actually). >> >> => no opposition! Where I can sign? (:-) > Same for supporters of C. (But yes, this is one of the reasons A is > at the very bottom of my list). >> Can we (especially those who support C) make a compromise on this > with >> this plan? > Sorry, what was "this"? Sorry for the ambiguous wording. I just meant taking the idea from - take 4+28 split. ... - when a zone ID is used with an address (typically in the sockaddr_in6 structure), the scope type of the ID must be equal to the scope type of the address. in my original message, and revising the scoping architecture draft accordingly. >> => I believe C is not for the basic API but we can open a new activity >> about C in the advanced API (C people will propose things, A people > will >> reject proposals which are not useful, B people will take holidays > :-)? > If B were the standard interoperable thing, but C would also be legal > behavior (since it's a superset of B behavior) for an implementation, > that > would be fine by me. I think I'm okay with this, as long as we clearly note that C does not necessarily provide portability and that portable applications should stick to B. 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 Aug 16 07:44:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GEiBQ18463 for ipng-dist; Thu, 16 Aug 2001 07:44:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GEi7D18456 for ; Thu, 16 Aug 2001 07:44:07 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26954 for ; Thu, 16 Aug 2001 07:44:10 -0700 (PDT) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03120 for ; Thu, 16 Aug 2001 07:44:08 -0700 (PDT) Received: from duplo.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.5/8.11.3) with ESMTP id f7GEhqX16479; Thu, 16 Aug 2001 23:43:52 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.5/8.10.2) id f7GEhtf01773; Thu, 16 Aug 2001 23:43:56 +0900 (JST) Date: Thu, 16 Aug 2001 23:43:56 +0900 (JST) From: Atsushi Onoe Message-Id: <200108161443.f7GEhtf01773@duplo.sm.sony.co.jp> To: dthaler@windows.microsoft.com Cc: Francis.Dupont@enst-bretagne.fr, jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: RE: Wrap up and last call: sin6_scope_id semantics In-Reply-To: Your message of "Wed, 15 Aug 2001 12:11:12 -0700" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk <2E33960095B58E40A4D3345AB9F65EC1B58142@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1B58142@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-Mailer: Cue version 0.6 (010815-1037/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii > If B were the standard interoperable thing, but C would also be legal > behavior (since it's a superset of B behavior) for an implementation, > that > would be fine by me. So perhaps you will be against this 'must'? | - when a zone ID is used with an address (typically in the sockaddr_in6 | structure), the scope type of the ID must be equal to the scope type | of the address. I won't oppose that an implementation accepts the values which don't match the scope type, but at least it MUST NOT returns such values to applications, IMHO. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 16 08:06:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GF64O18503 for ipng-dist; Thu, 16 Aug 2001 08:06:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GF60D18496 for ; Thu, 16 Aug 2001 08:06:00 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28357; Thu, 16 Aug 2001 08:06:03 -0700 (PDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16839; Thu, 16 Aug 2001 08:06:01 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA24206; Thu, 16 Aug 2001 10:00:31 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7GF2Yh222076; Thu, 16 Aug 2001 11:02:34 -0400 Subject: Re: Wrap up and last call: sin6_scope_id semantics To: Erik Nordmark Cc: Francis Dupont , ipng@sunroof.eng.sun.com, JINMEI Tatuya / =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Thu, 16 Aug 2001 11:01:30 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/16/2001 11:02:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, 08/16/2001 at 03:40 ZE2, Erik Nordmark wrote: > > So, the basic idea is as follows: > > > > - take 4+28 split. > > - actual mapping from zone to the 28 bit part does not matter, but it > > should not change while the node is running (as discussed in this > > thread) > > - introduce "aliases" for numeric zone IDs to improve readability in > > the textual representation. e.g. "link2" is an alias of a link ID > > whose intra-link id is 2 (i.e. 0x20000002). "site4" is an alias of > > a site ID whose intra-site id is 4 (i.e. 0x50000004). We now allow > > fec0::1234%site4 as well as fec0::1234%1342177284 (1342177284=0x50000004) > > - when a zone ID is used with an address (typically in the sockaddr_in6 > > structure), the scope type of the ID must be equal to the scope type > > of the address. > > Seems like, to the extent that there are existing applications > which use if_nametoindex() -> sin6_scope_id for link-local addresses, > we need to also support the top 4 being zero as an alias for the > interface or link scope. > > Does anybody know of such applications? > Does anybody know of applications doing the reverse (taking sin6_scope_id > and passing it to if_indextoname())? This may work when the default link-local zones are used, but how will it work in the presence of manually-configured link-local zones? The current IPv6 Scoped Address Architecture draft allows implementations to configure multiple links to be in the same link-local zone. If this is done then there is no longer a one-to-one correlation between the link-local zone and the interface ID. It is probably useful to have a standard (or at least agreed upon) way to map between the sin6_scope_id and the zone name, something akin to the if_nametoindex() and if_indextoname() calls for converting an interface name to an index and vice-versa. While using the if_nametoindex() and if_indextoname() calls may work in some cases for link-local addresses (and maybe not even for link-local if manually configured link-local zones are used), it won't work for other scopes. Such an interface would be of use to a DNS resolver, and I can see other applications perhaps wanting to perform these types of mappings directly as well. Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 16 08:35:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GFYVb18737 for ipng-dist; Thu, 16 Aug 2001 08:34:31 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GFYND18723 for ; Thu, 16 Aug 2001 08:34:24 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7GFYE207731; Thu, 16 Aug 2001 17:34:14 +0200 (MET DST) Date: Thu, 16 Aug 2001 17:31:26 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Wrap up and last call: sin6_scope_id semantics To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , Francis Dupont , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Actually, since our (i.e. KAME/BSD's) getaddrinfo() and getnameinfo() > use this mapping, all applications that use those two functions are > affected, including ping, traceroute, ifconfig, netstat, route, > telnet, ssh, ftp,... I'm confused. When you ship a new release that supports a link ids, site ids, etc won't you also ship a getaddrinfo and getnameinfo which can handle those? Thus I think the only concern should be for applications which directly use if_nametoindex or if_indextoname for sin6_scope_id. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 16 08:48:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GFmFY18858 for ipng-dist; Thu, 16 Aug 2001 08:48:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GFmBD18851 for ; Thu, 16 Aug 2001 08:48:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07539 for ; Thu, 16 Aug 2001 08:48:14 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26310 for ; Thu, 16 Aug 2001 09:48:28 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7GFmBQ29785; Thu, 16 Aug 2001 08:48:11 -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 ACS00105; Thu, 16 Aug 2001 08:48:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA18175; Thu, 16 Aug 2001 08:48:06 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15227.60213.891671.893319@thomasm-u1.cisco.com> Date: Thu, 16 Aug 2001 08:48:05 -0700 (PDT) To: Brian E Carpenter Cc: Michael Thomas , Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] In-Reply-To: <3B7BCC98.D41BACA4@hursley.ibm.com> References: <200108151646.MAA16236@castillo.torrentnet.com> <3B7AAA08.C2211D49@hursley.ibm.com> <15226.44359.301654.186683@thomasm-u1.cisco.com> <3B7BCC98.D41BACA4@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Michael Thomas wrote: > > > > Brian E Carpenter writes: > > > Excellent summary. We originally chose a 6 bit diffserv field partly because > > > it was available in both IPv4 and IPv6, and partly because it allows for > > > very efficient classification in *core* routers, with the more demanding > > > multi-field classification being left to border routers. > > > > > > The question before the house (in the end that means both ipng and diffserv) > > > is whether the added complexity of adding the flow label to the diffserv > > > model is justified by the gain in expressiveness. It doesn't do anything > > > for the trust model. > > > > I haven't heard about any imminent shortage of DSCP's. > > Indeed, it seems that there's only a small handful > > (2-6) that I've ever heard people contemplating. Maybe > > I just don't travel in the right circles... > > We have deliberately been *very* conservative about defining standard PHBs, since > we want to be very sure about what we standardise. But there are a potentially > infinite number of local-use PHBs. That is why the DSCP value is mappable, and why > the PHB ID was defined, so that local-use PHBs can be registered with IANA and > signalled. The idea here is to stretch the semantics of the PHB ID just a little. Right. Even if the number of PHB's grows beyond 6-8 bits (which seems pretty unlikely to me), in order to be a real problem you would have to posit a network/domain which actually wanted to use more than could be currently mapped into the DSCP. I've been working on a lot of voip stuff in the last few years and the number of DSCP's I've heard has been in the range of about 2 to 5 or 6 that I recall, with higher end of the range seeming pretty extravagant. > Normal semantics of a PHB ID: > > "This is local-use PHB number 379" > > Stretched semantics: > > "This is local-use PHB number 379 and according to our SLA, that gets classified > as real-time traffic needing at least a 10 Mbit/s rate" Ah. This strikes me as trying to overload the semantics of DiffServ. Another way to go about this is to use signaled diffserv (either the COPS-PR or RSVP varieties) with policers at the proper edges of the network. That way, the traffic classes (ie the actual PHB) stays small. 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 Aug 16 10:19:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GHITu19338 for ipng-dist; Thu, 16 Aug 2001 10:18:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GHIPD19331 for ; Thu, 16 Aug 2001 10:18:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22610; Thu, 16 Aug 2001 10:18:28 -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 LAA23552; Thu, 16 Aug 2001 11:18:40 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA15701; Fri, 17 Aug 2001 02:21:35 +0900 (JST) Date: Fri, 17 Aug 2001 02:18:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Aug 2001 17:31:26 +0200 (CEST), >>>>> Erik Nordmark said: >> Actually, since our (i.e. KAME/BSD's) getaddrinfo() and getnameinfo() >> use this mapping, all applications that use those two functions are >> affected, including ping, traceroute, ifconfig, netstat, route, >> telnet, ssh, ftp,... > I'm confused. > When you ship a new release that supports a link ids, site ids, etc > won't you also ship a getaddrinfo and getnameinfo which can handle those? Of course I will. However, we should also provide backward compatibility to applications that are statically linked with older libraries. (probably my text in the previous message was unclear, sorry). > Thus I think the only concern should be for applications which > directly use if_nametoindex or if_indextoname for sin6_scope_id. So, unfortunately, this is not true, at least for some vendors including us. 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 Aug 16 12:54:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GJrUk20312 for ipng-dist; Thu, 16 Aug 2001 12:53:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GJrQD20305 for ; Thu, 16 Aug 2001 12:53:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28499 for ; Thu, 16 Aug 2001 12:53:04 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06401 for ; Thu, 16 Aug 2001 12:53:02 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA19518; Thu, 16 Aug 2001 20:52:59 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA46604; Thu, 16 Aug 2001 20:52:59 +0100 Message-ID: <3B7C2164.2CC24E01@hursley.ibm.com> Date: Thu, 16 Aug 2001 14:39:16 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <200108151646.MAA16236@castillo.torrentnet.com> <3B7AAA08.C2211D49@hursley.ibm.com> <15226.44359.301654.186683@thomasm-u1.cisco.com> <3B7BCC98.D41BACA4@hursley.ibm.com> <15227.60213.891671.893319@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: > > Brian E Carpenter writes: > > Michael Thomas wrote: > > > > > > Brian E Carpenter writes: > > > > Excellent summary. We originally chose a 6 bit diffserv field partly because > > > > it was available in both IPv4 and IPv6, and partly because it allows for > > > > very efficient classification in *core* routers, with the more demanding > > > > multi-field classification being left to border routers. > > > > > > > > The question before the house (in the end that means both ipng and diffserv) > > > > is whether the added complexity of adding the flow label to the diffserv > > > > model is justified by the gain in expressiveness. It doesn't do anything > > > > for the trust model. > > > > > > I haven't heard about any imminent shortage of DSCP's. > > > Indeed, it seems that there's only a small handful > > > (2-6) that I've ever heard people contemplating. Maybe > > > I just don't travel in the right circles... > > > > We have deliberately been *very* conservative about defining standard PHBs, since > > we want to be very sure about what we standardise. But there are a potentially > > infinite number of local-use PHBs. That is why the DSCP value is mappable, and why > > the PHB ID was defined, so that local-use PHBs can be registered with IANA and > > signalled. The idea here is to stretch the semantics of the PHB ID just a little. > > Right. Even if the number of PHB's grows beyond > 6-8 bits (which seems pretty unlikely to me), in > order to be a real problem you would have to posit > a network/domain which actually wanted to use more > than could be currently mapped into the DSCP. I've > been working on a lot of voip stuff in the last > few years and the number of DSCP's I've heard has > been in the range of about 2 to 5 or 6 that I > recall, with higher end of the range seeming > pretty extravagant. > > > Normal semantics of a PHB ID: > > > > "This is local-use PHB number 379" > > > > Stretched semantics: > > > > "This is local-use PHB number 379 and according to our SLA, that gets classified > > as real-time traffic needing at least a 10 Mbit/s rate" > > Ah. This strikes me as trying to overload the > semantics of DiffServ. Yes. Pretty shameless of me as diffserv co-chair :-) > Another way to go about > this is to use signaled diffserv (either the > COPS-PR or RSVP varieties) with policers at the > proper edges of the network. That way, the traffic > classes (ie the actual PHB) stays small. True. But signalling in the flow label is a low overhead approach (although of course there needs to be an out of band way of creating the SLA). 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 Aug 16 15:35:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7GMZME21046 for ipng-dist; Thu, 16 Aug 2001 15:35:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GMZIL21039 for ; Thu, 16 Aug 2001 15:35:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03656 for ; Thu, 16 Aug 2001 15:35:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13744 for ; Thu, 16 Aug 2001 15:35:20 -0700 (PDT) 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 PAA14699; Thu, 16 Aug 2001 15:35:20 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7GMZJo06148; Thu, 16 Aug 2001 15:35:19 -0700 X-mProtect: Thu, 16 Aug 2001 15:35:19 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdPp87k7; Thu, 16 Aug 2001 15:35:17 PDT Message-Id: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 16 Aug 2001 15:33:17 -0700 To: Brian E Carpenter From: Bob Hinden Subject: Re: Higher level question about flow label Cc: ipng In-Reply-To: <3B7BCE71.BE8DB82E@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote: >I think the WG needs to decide once and for all whether the flow label is > a) a CATNIP or MPLS-like routing handle >or b) a QOS hint for intserv only >or c) a QOS hint for intserv and diffserv >or d) a waste of bits I would like to suggest another choice: e) a set of bits we hold in reserve for the future I don't think that we have enough experience to pick between a), b), or c) now, and think that something might come up in the future where 28 bits in the IPv6 header might be very useful. This might not have anything to do with QOS. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 16 16:07:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7GN6Nr21206 for ipng-dist; Thu, 16 Aug 2001 16:06:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GN6KL21199 for ; Thu, 16 Aug 2001 16:06:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09211 for ; Thu, 16 Aug 2001 16:06:23 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25286 for ; Thu, 16 Aug 2001 16:06:22 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id TAA06563; Thu, 16 Aug 2001 19:07:13 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id TAA29641; Thu, 16 Aug 2001 19:07:12 -0400 Message-ID: <3B7C521D.6A168FDC@txc.com> Date: Thu, 16 Aug 2001 19:07:09 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <20010816051812.DC24A7BA@starfruit.itojun.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms314D7A4CE3CB6692FC63B4F5" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms314D7A4CE3CB6692FC63B4F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit itojun, As Brian already rightfully said, perhaps not with the same words, the draft promotes the flow label format in the main text, which is the IANA based value format. As Brian, I believe more in the IANA format. The flow label formats in the Appendix are presented as possible choices, each with its advantages and disadvantages, and as a record of such choices. The draft states that in the Appendix. The reason I am still arguing the Appendix formats, is for the sake of fairness and accuracy. Jun-ichiro itojun Hagino wrote: > .... > > >> - putting total extension header length > >> if the originator lies about the value, intermediate routers > >> can go panic. > > > >I disagree. > > > >"less than the size of the packet" is a simple, cheap, straight forward > >validation test of the headers length, that would ensure that nothing > >wrong can happen, regardless of memory being partioned and protected. > > I guess you are too optimistic. if you are using align-picky > architecture CPU for your router, I can panic your router by putting > some value that is not align-friendly into flow label field as the > extension header length. > Memory alignment became an access speed issue with certain 64bit processor/memory architectures, because of the access in 32 or 64bit "blocks", aligned at 32, or 64bit boundaries, thus possibly requiring for a byte access, depending the position of the byte in the "block", a shift of 8, 16, 24, or more bits. But this is far from anything you describe. I am afraid "memory alignment violation" is more a result of one's imagination than reality. > >Even without the validation, the reduced number of bits available for > >the length is forcing a reasonable limit on the length. The TCP/UDP > >ports are accessed for "read", and the values are not used as pointers > >or offsets. Assuming an implementation that enforces memory > >partitioning, the "kernel" has most likely "read" access anywhere in > >memory, so "memory access violation" is unlikely. > > I don't understand what you are trying to mean. regardless from > read access or write access, your kernel can be tricked into: > - accessing bits on a wrong boundary > - accessing bits that are not a real port number > I can trick the intermediate routers to believe that I'm using > TCP port 80, while I'm actually using TCP port 22. > > >Also please note that the use of a total header length would not be > >conceptually, and practically > >different than IPv4. The IHL field in the IPv4 header includes the > >length of the main header fields, and the IPv4 options. Some of the IPv4 > >options are of a variable length. A variable size IPv4 option > >carries a field indicating the length. We knew how to implement this > >back many years ago, right?, so we should be able to implement this > >carefully for IPv6, if need be. > > it is very different from IPv4 case. in IPv4 case, IHL field is the > one and only field trustable, and there was no ambiguity. for IPv6 > extension header length, the actual value is detected only by chasing > header chain. your addition (of extension header length into flow > label field) is a non-trustworthy copy of the real value. if your > router believes that the value in flow label field, your router will > get tricked. > Ultimately, as Brian pointed out, the Network Provider will charge the customer. The customer, if he/she is the culprit will pay, otherwise, will pay, and chase the culprit. For the sake of accuracy, for a flow label format that contains the length and the host-to-host protocol id, the flow label value should be set by the IPv6 stack, that is, the KERNEL. The user should only trigger the use of the label, but the two values - length, protocol id - would be set by the KERNEL, on "IPv6 output" code path. Both values are known on packet transmission. The length can be calculated and cached or stored in a field in the Protocol Control Block, or whatever structure is representing the communication. > >> - putting port/addr/whatever encoded > >> if the originator lies about the value, theft-of-service > >> happens. > >As said above, the security risk is not higher than with the > >pseudo-random number. > > I don't believe so. > > itojun you are making it sound like there is NO RISK with the pseudo-random number, and that is NOT TRUE. Once a pseudo-random flow label has been generated and cached, the risk of high-jacking it, is NOT DIFFERENT than with the non-pseudo-random flow label value. Alex --------------ms314D7A4CE3CB6692FC63B4F5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MTYyMzA3MTBaMCMGCSqGSIb3DQEJBDEWBBT75FX5KdHamY38uros R9cNyFKf3jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gDbS9GZAjY6ELBaGjCGCgdvlUo521aK2OplgtYfzjWiw5hgPdGg6v59iJdz3HosFdaiO4jmH iIRJ2e+aHii8Pb4EXjMU56EY8MALpU2U1hnOc/L+wp66fMa3UUlool/yELmFAMFPXZ2wKQ2f 9JWvlsqQgQkHCjrTpDaUuLeBWn++ --------------ms314D7A4CE3CB6692FC63B4F5-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 16 16:15:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7GNEkS21241 for ipng-dist; Thu, 16 Aug 2001 16:14:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GNEgL21234 for ; Thu, 16 Aug 2001 16:14:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11252 for ; Thu, 16 Aug 2001 16:14:45 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA28940 for ; Thu, 16 Aug 2001 17:14:58 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id TAA06695; Thu, 16 Aug 2001 19:15:36 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id TAA29887; Thu, 16 Aug 2001 19:15:35 -0400 Message-ID: <3B7C5414.7F95A87E@txc.com> Date: Thu, 16 Aug 2001 19:15:32 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: Jun-ichiro itojun Hagino , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4A0E63D754C5CD57751D83FD" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms4A0E63D754C5CD57751D83FD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Indeed, there is a need for at least one packet of a high QoS level before one could steal the value of the flow label and use it for a non-authorized flow (it is mostly, if not always, known which ports are high QoS level and which not). However, once the pseudo-random number is cached, or stored, the RISK is not different. A long flow state time to live obviously helps the wrongdoer. Pekka Savola wrote: > > On Wed, 15 Aug 2001, Alex Conta wrote: > > >Jun-ichiro itojun Hagino wrote: > > > > > > >The traffic class field is not enough. If you have to re-classify traffic at > > > >an administrative boundary, then by definition at that point the traffic class > > > >field is inadequate; you need more information. The advantage that IPv6 has > > > >is that even when the header is partly hidden by IPSEC, the flow label is > > > >available to carry additional semantics. The actual proposal is to use the > > > >PHB identifier which has end to end semantics. > > > > > > I heard the presentation differently. in IETF51 presentation Alex > > > Conta made the following proposals, at least: > > > - putting PHB value > > > not trustworthy. > > > > The PHB is as trustworthy as anything else, including the pseudo-random > > value. If a user can set values as pleases, it can do that with the > > pseudo-random number as well. > > The user does not know which pseudo-random value to choose (2^19 or the > like is lots..) to select to "steal specific kind of traffic", at least > before you have indeed sent legally that kind of traffic and observed > higher priority given to the that flow. If this were based on port numbers > etc., the user could more easily guess/experiment with the behaviour, and > set it as you please. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords --------------ms4A0E63D754C5CD57751D83FD Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MTYyMzE1MzRaMCMGCSqGSIb3DQEJBDEWBBRRuF1xUdxbkAAUlk0r 7HCdN1rrXTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gDOTBaa96lK9BEeMKb18VhsJe57De0Yqqm35FNQ/ls4L1K7Di9dJ1K/f33rQzSkA6r9E5eoG 9I36eNdiW3p7YCQpGf+cqOZLvNXYq8ODu7VyqhHpH+JO4SsGrlBhaz5Velk8vp6q/od5fRQW lBsL356kVgCoks2mhK7pl3clBx/X --------------ms4A0E63D754C5CD57751D83FD-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 16 18:38:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H1bid21903 for ipng-dist; Thu, 16 Aug 2001 18:37:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H1bfL21896 for ; Thu, 16 Aug 2001 18:37:41 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA04436 for ; Thu, 16 Aug 2001 18:37:45 -0700 (PDT) Received: from moon.bjnet.edu.cn (moon.bjnet.edu.cn [202.112.4.65]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14359 for ; Thu, 16 Aug 2001 18:37:43 -0700 (PDT) Received: from xmw ([202.112.37.166]) by moon.bjnet.edu.cn (8.9.1a/8.9.1) with SMTP id JAA12722 for ; Fri, 17 Aug 2001 09:37:46 +0900 (CDT) Message-ID: <008801c126bd$399931a0$a62570ca@xmw.cainonet.net.cn> From: "Mingwei Xu" To: Subject: quit Date: Fri, 17 Aug 2001 09:37:46 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01C12700.45BD4640" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0085_01C12700.45BD4640 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_0085_01C12700.45BD4640 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
------=_NextPart_000_0085_01C12700.45BD4640-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 16 22:14:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H5E6F22194 for ipng-dist; Thu, 16 Aug 2001 22:14:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H5E2L22187 for ; Thu, 16 Aug 2001 22:14:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23785 for ; Thu, 16 Aug 2001 22:14:07 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05658 for ; Thu, 16 Aug 2001 22:14:06 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7H5HkG08790 for ; Fri, 17 Aug 2001 08:17:46 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 17 Aug 2001 08:14:04 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVVGNM>; Fri, 17 Aug 2001 08:14:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF242933@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Fri, 17 Aug 2001 08:14:01 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > I think the WG needs to decide once and for all whether the > flow label is > a) a CATNIP or MPLS-like routing handle > or b) a QOS hint for intserv only > or c) a QOS hint for intserv and diffserv > or d) a waste of bits > > We can get back to the details once we have a consensus on this. I prefer c, but wouldn't mind it being simplified down to "A QoS hint." 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 Thu Aug 16 22:23:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H5NNv22275 for ipng-dist; Thu, 16 Aug 2001 22:23:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H5NIL22268 for ; Thu, 16 Aug 2001 22:23:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA24689 for ; Thu, 16 Aug 2001 22:23:22 -0700 (PDT) Received: from starfruit.itojun.org (starfruit.bakeoff.ipsec.com [130.233.9.166]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA09915 for ; Thu, 16 Aug 2001 23:23:33 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 270517BA; Fri, 17 Aug 2001 14:12:05 +0900 (JST) To: Alex Conta Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-reply-to: aconta's message of Thu, 16 Aug 2001 19:07:09 -0400. <3B7C521D.6A168FDC@txc.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: [Fwd: draft-conta-ipv6-flow-label-02.txt] From: Jun-ichiro itojun Hagino Date: Fri, 17 Aug 2001 14:12:05 +0900 Message-Id: <20010817051205.270517BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >As Brian already rightfully said, perhaps not with the same words, the >draft promotes the flow label format in the main text, which is the IANA >based value format. As Brian, I believe more in the IANA format. The >flow label formats in the Appendix are presented as possible choices, >each with its advantages and disadvantages, and as a record of such >choices. The draft states that in the Appendix. then why you pushed those non-IANA values in the presentation? this is the source of confusion. >> I guess you are too optimistic. if you are using align-picky >> architecture CPU for your router, I can panic your router by putting >> some value that is not align-friendly into flow label field as the >> extension header length. >Memory alignment became an access speed issue with certain 64bit >processor/memory architectures, because of the access in 32 or 64bit >"blocks", aligned at 32, or 64bit boundaries, thus possibly requiring >for a byte access, depending the position of the byte in the "block", a >shift of 8, 16, 24, or more bits. But this is far from anything you >describe. > >I am afraid "memory alignment violation" is more a result of one's >imagination than reality. you are horribly wrong. have you ever used alignment-picky CPUs like alpha? >> it is very different from IPv4 case. in IPv4 case, IHL field is the >> one and only field trustable, and there was no ambiguity. for IPv6 >> extension header length, the actual value is detected only by chasing >> header chain. your addition (of extension header length into flow >> label field) is a non-trustworthy copy of the real value. if your >> router believes that the value in flow label field, your router will >> get tricked. >Ultimately, as Brian pointed out, the Network Provider will charge the >customer. The customer, if he/she is the culprit will pay, otherwise, >will pay, and chase the culprit. > >For the sake of accuracy, for a flow label format that contains the >length and the host-to-host protocol id, the flow label value should be >set by the IPv6 stack, that is, the KERNEL. The user should only trigger >the use of the label, but the two values - length, protocol id - would >be set by the KERNEL, on "IPv6 output" code path. Both values are known >on packet transmission. The length can be calculated and cached or >stored in a field in the Protocol Control Block, or whatever structure >is representing the communication. how can you trust IPv6 stack that is in the possession of end user? they can be hacked up. the only devices you can trust is those you administer in your diffserv cloud. you can never trust customers devices. >> >As said above, the security risk is not higher than with the >> >pseudo-random number. >> I don't believe so. >you are making it sound like there is NO RISK with the pseudo-random >number, and that is NOT TRUE. >Once a pseudo-random flow label has been generated and cached, the risk >of high-jacking it, is NOT DIFFERENT than with the non-pseudo-random >flow label value. I believe there's substantial difference, but okay, I got your point. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 17 00:14:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H7Dce22366 for ipng-dist; Fri, 17 Aug 2001 00:13:38 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H7DYL22359 for ; Fri, 17 Aug 2001 00:13:34 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06297; Fri, 17 Aug 2001 03:13:37 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f7H7D0015748; Fri, 17 Aug 2001 03:13:00 -0400 (EDT) Message-Id: <200108170713.f7H7D0015748@thunk.east.sun.com> From: Bill Sommerfeld To: Bob Hinden cc: Brian E Carpenter , ipng Subject: Re: Higher level question about flow label In-reply-to: Your message of "Thu, 16 Aug 2001 15:33:17 PDT." <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 17 Aug 2001 03:13:00 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would like to suggest another choice: > > e) a set of bits we hold in reserve for the future > > I don't think that we have enough experience to pick between a), b), or c) > now, and think that something might come up in the future where 28 bits in > the IPv6 header might be very useful. This might not have anything to do > with QOS. Currently the field is defined as "must be random"; if we want to preserve the ability to recycle it for something else in the future, we need to redefine it *NOW* as a "must be zero". - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 17 01:13:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7H8Cdx22645 for ipng-dist; Fri, 17 Aug 2001 01:12:39 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.179.15]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H8CYL22638 for ; Fri, 17 Aug 2001 01:12:35 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7H8CN226751; Fri, 17 Aug 2001 10:12:23 +0200 (MET DST) Date: Fri, 17 Aug 2001 10:09:32 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Wrap up and last call: sin6_scope_id semantics To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , Francis Dupont , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Of course I will. However, we should also provide backward > compatibility to applications that are statically linked with older > libraries. (probably my text in the previous message was unclear, > sorry). Ah - static linking is such a mess :-( If you need to solve the static linking issue then there is a hard problem for passing sin6_scope_id from the kernel to the application. Somehow the kernel needs to know whether the application wants the backwards compatible (top 4 bits being zero so the statically linked getnameinfo/if_indextoname will work) scope_id or the new one. Thus the kernel needs to be able to tell whether the application was statically linked against getnameinfo. This is hard as far as I know. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 17 07:14:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HEEBZ23746 for ipng-dist; Fri, 17 Aug 2001 07:14:11 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HEE7L23739 for ; Fri, 17 Aug 2001 07:14:08 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05935 for ; Fri, 17 Aug 2001 07:14:07 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02213 for ; Fri, 17 Aug 2001 07:14:06 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA29126; Fri, 17 Aug 2001 15:14:04 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA46648; Fri, 17 Aug 2001 15:14:03 +0100 Message-ID: <3B7D26F7.234F52D0@hursley.ibm.com> Date: Fri, 17 Aug 2001 09:15:19 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bob Hinden CC: ipng Subject: Re: Higher level question about flow label References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > > Brian, > > At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote: > >I think the WG needs to decide once and for all whether the flow label is > > a) a CATNIP or MPLS-like routing handle > >or b) a QOS hint for intserv only > >or c) a QOS hint for intserv and diffserv > >or d) a waste of bits > > I would like to suggest another choice: > > e) a set of bits we hold in reserve for the future A couple of people have said this in private mail too. I agree; making it a "reserved MBZ" field is the practical alternative to "a waste of bits". > > I don't think that we have enough experience to pick between a), b), or c) > now, and think that something might come up in the future where 28 bits in > the IPv6 header might be very useful. This might not have anything to do > with QOS. I think you mean 20 bits. The traffic class octet is fully standardised by diffserv and ECN. The problem with this is that the text we have today effectively selects option b), since it endorses the pseudo-random value. If we do nothing, we have effectively chosen the intserv-only usage. That's why I started this thread. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 17 07:22:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HELYD23804 for ipng-dist; Fri, 17 Aug 2001 07:21:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HELUL23797 for ; Fri, 17 Aug 2001 07:21:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00703 for ; Fri, 17 Aug 2001 07:21:28 -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 IAA14434 for ; Fri, 17 Aug 2001 08:21:23 -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.5/8.11.5) with ESMTP id f7HELGx29027; Fri, 17 Aug 2001 16:21:16 +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 QAA07824; Fri, 17 Aug 2001 16:21:16 +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.11.3/8.11.3) with ESMTP id f7HELGl12433; Fri, 17 Aug 2001 16:21:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108171421.f7HELGl12433@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: ipng Subject: Re: Higher level question about flow label In-reply-to: Your message of Thu, 16 Aug 2001 08:45:21 CDT. <3B7BCE71.BE8DB82E@hursley.ibm.com> Date: Fri, 17 Aug 2001 16:21:16 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think the WG needs to decide once and for all whether the flow label is a) a CATNIP or MPLS-like routing handle or b) a QOS hint for intserv only or c) a QOS hint for intserv and diffserv or d) a waste of bits => I vote for b) Regards Francis.Dupont@enst-bretagne.fr PS: Intserv is not 100% dead because there is an environment (wireless) where to get more bandwidth is really expensive (in Europe at least :-). PPS: there is another usage: flow-based switching for fast routing but I don't believe this really helps (petabit router vendors?) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 17 07:31:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HEUTv23898 for ipng-dist; Fri, 17 Aug 2001 07:30:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HEUQL23891 for ; Fri, 17 Aug 2001 07:30:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11867 for ; Fri, 17 Aug 2001 07:30:21 -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 IAA29453 for ; Fri, 17 Aug 2001 08:30:33 -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.5/8.11.5) with ESMTP id f7HETix29556; Fri, 17 Aug 2001 16:29:47 +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 QAA07911; Fri, 17 Aug 2001 16:29:45 +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.11.3/8.11.3) with ESMTP id f7HETel12516; Fri, 17 Aug 2001 16:29:44 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108171429.f7HETel12516@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Atsushi Onoe cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Thu, 16 Aug 2001 23:28:03 +0900. <200108161428.f7GES3l01602@duplo.sm.sony.co.jp> Date: Fri, 17 Aug 2001 16:29:40 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As I said at the meeting, I agree with the idea. Some isssues: - need to define the mapping between scope and top 4 bit? my guess is yes. MIB peaple may want to map a value into alias (e.g. "link") from a remote system. => multicast scope values? - should care existing implementations? yes. But I guess most of such applications use a interface index for scope_id, so it can be saved either: - assign scope value (4bit) 0 to link-local. or - implementation MAY accept the value 0 in implementation- specific manner, but SHOULD NOT return 0 for scope (4bit). => the MAY is fine. - need to introduce new functions to map scope-name and the value? I hope not to define new functions, so want to _define_ the textual representation (e.g. "link", "site", ...) instead. => I prefer real names than xxxNNN. Can we get both (i.e. a config file plus a default translation rule)? Regards Francis.Dupont@enst-bretagne.fr PS: scopes are according to draft-ietf-ipngwg-addr-arch-v3-06.txt: 0 reserved 1 interface-local scope 2 link-local scope 3 subnet-local scope 4 admin-local scope 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 9 (unassigned) A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope F reserved 2 and 5 have a meaning for unicast. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 17 07:35:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HEYk223920 for ipng-dist; Fri, 17 Aug 2001 07:34:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HEYgL23913 for ; Fri, 17 Aug 2001 07:34:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02549; Fri, 17 Aug 2001 07:34:37 -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 IAA22472; Fri, 17 Aug 2001 08:34:32 -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.5/8.11.5) with ESMTP id f7HEXmx29771; Fri, 17 Aug 2001 16:33: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 QAA07963; Fri, 17 Aug 2001 16:33: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.11.3/8.11.3) with ESMTP id f7HEXml12537; Fri, 17 Aug 2001 16:33:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108171433.f7HEXml12537@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Thu, 16 Aug 2001 23:30:35 +0900. Date: Fri, 17 Aug 2001 16:33:48 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> On Thu, 16 Aug 2001 15:40:25 +0200 (CEST), >>>>> Erik Nordmark said: > Seems like, to the extent that there are existing applications > which use if_nametoindex() -> sin6_scope_id for link-local addresses, > we need to also support the top 4 being zero as an alias for the > interface or link scope. > Does anybody know of such applications? > Does anybody know of applications doing the reverse (taking sin6_scope_id > and passing it to if_indextoname())? Actually, since our (i.e. KAME/BSD's) getaddrinfo() and getnameinfo() use this mapping, all applications that use those two functions are affected, including ping, traceroute, ifconfig, netstat, route, telnet, ssh, ftp,... => change the dynamic library and recompile all statically linked applications? So we should probably provide some trick to ensure backward compatibility for such applications. => a MAY was proposed... But I am in favor of a *short* period with the trick enabled by default. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 17 09:21:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HGKk024564 for ipng-dist; Fri, 17 Aug 2001 09:20:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HGKbL24557 for ; Fri, 17 Aug 2001 09:20:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27436; Fri, 17 Aug 2001 09:20:33 -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 KAA19071; Fri, 17 Aug 2001 10:20:28 -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.5/8.11.5) with ESMTP id f7HGKUx07313; Fri, 17 Aug 2001 18:20:30 +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 SAA08778; Fri, 17 Aug 2001 18:20:31 +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.11.3/8.11.3) with ESMTP id f7HGKUl13306; Fri, 17 Aug 2001 18:20:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108171620.f7HGKUl13306@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Fri, 17 Aug 2001 10:09:32 +0200. Date: Fri, 17 Aug 2001 18:20:30 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Thus the kernel needs to be able to tell whether the application was statically linked against getnameinfo. This is hard as far as I know. => the only easy way is to change something in system calls (AF_INET6 value, system call numbers, ...). But how many real applications need scoped addresses? All examples I know are for system tools (ifconfig, ...) which are *not* real applications with only one (bad) exception: net$cape. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 17 09:22:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HGMT924589 for ipng-dist; Fri, 17 Aug 2001 09:22:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HGMQL24582 for ; Fri, 17 Aug 2001 09:22:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01421 for ; Fri, 17 Aug 2001 09:22:26 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13563 for ; Fri, 17 Aug 2001 09:22:25 -0700 (PDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA29659; Fri, 17 Aug 2001 17:22:23 +0100 (BST) Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id RAA14297; Fri, 17 Aug 2001 17:22:23 +0100 (BST) Date: Fri, 17 Aug 2001 17:22:23 +0100 (BST) From: Tim Chown To: Francis Dupont cc: ipng Subject: Re: Higher level question about flow label In-Reply-To: <200108171421.f7HELGl12433@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 17 Aug 2001, Francis Dupont wrote: > In your previous mail you wrote: > > I think the WG needs to decide once and for all whether the flow label is > a) a CATNIP or MPLS-like routing handle > or b) a QOS hint for intserv only > or c) a QOS hint for intserv and diffserv > or d) a waste of bits > > => I vote for b) So would you vote to mandate that the field is non-mutable in transit too? tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 17 09:49:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HGmRH24778 for ipng-dist; Fri, 17 Aug 2001 09:48:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HGmOL24771 for ; Fri, 17 Aug 2001 09:48:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10275 for ; Fri, 17 Aug 2001 09:48:25 -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 KAA08731 for ; Fri, 17 Aug 2001 10:48:38 -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 JAA06093; Fri, 17 Aug 2001 09:48:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7HGmM419539; Fri, 17 Aug 2001 09:48:22 -0700 X-mProtect: Fri, 17 Aug 2001 09:48:22 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdFnxugB; Fri, 17 Aug 2001 09:48:20 PDT Message-Id: <4.3.2.7.2.20010817093007.0251f0b8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 17 Aug 2001 09:47:34 -0700 To: Brian E Carpenter From: Bob Hinden Subject: Re: Higher level question about flow label Cc: ipng In-Reply-To: <3B7D26F7.234F52D0@hursley.ibm.com> References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > > I don't think that we have enough experience to pick between a), b), or c) > > now, and think that something might come up in the future where 28 bits in > > the IPv6 header might be very useful. This might not have anything to do > > with QOS. > >I think you mean 20 bits. The traffic class octet is fully standardised by >diffserv and ECN. Yes, my error. I was not suggesting we change the traffic class field. >The problem with this is that the text we have today effectively selects >option b), since it endorses the pseudo-random value. If we do nothing, >we have effectively chosen the intserv-only usage. That's why I started >this thread. I agree. It was good to ask the question. The point I was trying to make is that while we have now many QOS standards, we don't have very much deployment experience. As such it is hard to tell if it is worthwhile to use these 20 bits to optimize QOS performance. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 17 10:57:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HHu8l25159 for ipng-dist; Fri, 17 Aug 2001 10:56:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HHu4L25152 for ; Fri, 17 Aug 2001 10:56:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18686 for ; Fri, 17 Aug 2001 10:56:06 -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 LAA29165 for ; Fri, 17 Aug 2001 11:56:20 -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.5/8.11.5) with ESMTP id f7HHtWx11368; Fri, 17 Aug 2001 19:55:32 +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 TAA09405; Fri, 17 Aug 2001 19:55:32 +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.11.3/8.11.3) with ESMTP id f7HHtWl13963; Fri, 17 Aug 2001 19:55:32 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108171755.f7HHtWl13963@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Chown cc: ipng Subject: Re: Higher level question about flow label In-reply-to: Your message of Fri, 17 Aug 2001 17:22:23 BST. Date: Fri, 17 Aug 2001 19:55:32 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I vote for b) So would you vote to mandate that the field is non-mutable in transit too? => yes but only if its value is not zero (i.e. restrict to write once). Regards Francis.Dupont@enst-bretagne.fr PS: the idea is to put zero in the field by default and to put a (non-zero) random value by source or one of the first equipments on the path for Intserv. We have a bridge (laptop running FreeBSD 4.3 + ALTQ) on a subnetwork which just does that here. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 17 14:37:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7HLbEj26066 for ipng-dist; Fri, 17 Aug 2001 14:37:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HLbAL26059 for ; Fri, 17 Aug 2001 14:37:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11239 for ; Fri, 17 Aug 2001 14:37:12 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13684 for ; Fri, 17 Aug 2001 15:37:07 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id RAA25857; Fri, 17 Aug 2001 17:38:03 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id RAA11220; Fri, 17 Aug 2001 17:38:02 -0400 Message-ID: <3B7D8EA4.E735FD96@txc.com> Date: Fri, 17 Aug 2001 17:37:40 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <20010817051205.270517BA@starfruit.itojun.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3F98AA9CCBFEA623DAE7A8F2" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3F98AA9CCBFEA623DAE7A8F2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jun-ichiro itojun Hagino wrote: > > then why you pushed those non-IANA values in the presentation? > this is the source of confusion. You refer to the last 2 slides of the 14 slide presentation, each WITH BIG TITLES: OTHER POSSIBLE IPv6 FLOW LABEL FORMATS, presenting Appendix A of the draft. Your message title confused me: I thought you've read the draft, and based your comments on the draft. I agree. Certainly less confusion, less nit picking, non-bias, always helps. <...> > ... have you ever used alignment-picky CPUs like alpha? > at the top of page 27 in the draft, in Appendix A: "...IPv6 headers are 8byte aligned, therefore the length could be represented as the number of 8byte chunks occupied by the headers, in which case the maximum length would be 32Kbytes." With this representation, the receiver would simply shift the value of the field with 3 bits, thus ensuring a 8 byte alignment on accessing the TCP/UDP headers. >... > how can you trust IPv6 stack that is in the possession of end user? > they can be hacked up. the only devices you can trust is those you > administer in your diffserv cloud. you can never trust customers > devices. > It seems to me that you are still missing the points made earlier. The Diffserv QoS engines in the access routers do a policing (classification&metering&dropping) that trims the high level QoS traffic -- hacked by a user, or not -- to the level specified in SLAs, TCAs. So, a user, at the most, uses up all that was contracted with the ISP, and paid for, anyway. This is in fact THE BEAUTY of THE MODEL. > itojun --------------ms3F98AA9CCBFEA623DAE7A8F2 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MTcyMTM3NTRaMCMGCSqGSIb3DQEJBDEWBBRBLT9K4hSOv9kNyPL/ Azy2WcXjjTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gKwIf7ROktaE/ZnZmnI6sohz10IzH8NHCGWpIa3VhsbQ00xOqgMR2aUUQzwmPxYxzJ65Rt58 f5M3hjLT5eacJ/1rRp9qD0HLDyb843fmzO0W7HZl7cVgXUTpnz4tdwQnxf+Wp/erCdAaioNk DiXOemBFhuKnZf9OES3svWNDdJ/X --------------ms3F98AA9CCBFEA623DAE7A8F2-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 18 16:08:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7IN7gg27912 for ipng-dist; Sat, 18 Aug 2001 16:07:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7IN7YL27869 for ; Sat, 18 Aug 2001 16:07:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAB28761 for ; Sat, 18 Aug 2001 02:11:19 -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 DAA04886 for ; Sat, 18 Aug 2001 03:11:14 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:b59a:f1da:5780:d1be]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA03183; Sat, 18 Aug 2001 18:14:22 +0900 (JST) Date: Sat, 18 Aug 2001 18:10:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <200108171620.f7HGKUl13306@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200108171620.f7HGKUl13306@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 17 Aug 2001 18:20:30 +0200, >>>>> Francis Dupont said: > In your previous mail you wrote: > Thus the kernel needs to be able to tell whether the application > was statically linked against getnameinfo. This is hard as far as I > know. > => the only easy way is to change something in system calls (AF_INET6 > value, system call numbers, ...). But how many real applications > need scoped addresses? All examples I know are for system tools > (ifconfig, ...) which are *not* real applications with only one > (bad) exception: net$cape. I'm not sure about the issue of "net$cape", but we (some KAME users and I) sometimes use link-local addresses for ssh and telnet, in order to log into an adjacent node (typically a router); % ssh fe80::1234%2 However, we should only care about the sending side in such usages, which would be (much) easier than the receiving side. So, considering the sending part only might be a reasonable way to go... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 18 16:13:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7INCYP28036 for ipng-dist; Sat, 18 Aug 2001 16:12:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7INCSL28015 for ; Sat, 18 Aug 2001 16:12:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08502 for ; Sat, 18 Aug 2001 01:32:15 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04031 for ; Sat, 18 Aug 2001 01:32:13 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:b59a:f1da:5780:d1be]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA03000; Sat, 18 Aug 2001 17:35:07 +0900 (JST) Date: Sat, 18 Aug 2001 17:31:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: Atsushi Onoe , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <200108171429.f7HETel12516@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200108171429.f7HETel12516@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 17 Aug 2001 16:29:40 +0200, >>>>> Francis Dupont said: > - need to introduce new functions to map scope-name and the value? > I hope not to define new functions, so want to _define_ > the textual representation (e.g. "link", "site", ...) > instead. > => I prefer real names than xxxNNN. Can we get both (i.e. a config file > plus a default translation rule)? I do not object to introducing real names, but I'd like to leave that part as implementation dependent, and just define the formal aliases (like "link2") in the scope architecture draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 18 16:13:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7INCgR28037 for ipng-dist; Sat, 18 Aug 2001 16:12:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7INCSL28017 for ; Sat, 18 Aug 2001 16:12:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA07995 for ; Sat, 18 Aug 2001 01:28:20 -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 CAA27600 for ; Sat, 18 Aug 2001 02:28:14 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:fdda:fffe:f7c3:d9bf]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA02966; Sat, 18 Aug 2001 17:31:34 +0900 (JST) Date: Sat, 18 Aug 2001 17:28:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Atsushi Onoe Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <200108161428.f7GES3l01602@duplo.sm.sony.co.jp> References: <200108161428.f7GES3l01602@duplo.sm.sony.co.jp> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Aug 2001 23:28:03 +0900 (JST), >>>>> Atsushi Onoe said: > Some isssues: > - need to define the mapping between scope and top 4 bit? > my guess is yes. MIB peaple may want to map a value > into alias (e.g. "link") from a remote system. Yes. As for the mapping, using the 4-bit "scop" value in multicast addresses is the easiest (and most intuitive) way, although we should consider the backward compatibility issue below. > - should care existing implementations? > yes. But I guess most of such applications use a interface > index for scope_id, so it can be saved either: > - assign scope value (4bit) 0 to link-local. > or > - implementation MAY accept the value 0 in implementation- > specific manner, but SHOULD NOT return 0 for scope (4bit). If we take the latter way, even older applications will see non-zero zone IDs for the link-local scope. Doesn't this annoy the applications? > - need to introduce new functions to map scope-name and the value? > I hope not to define new functions, so want to _define_ > the textual representation (e.g. "link", "site", ...) > instead. I agree. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 18 17:01:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J00B328534 for ipng-dist; Sat, 18 Aug 2001 17:00:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J005L28504 for ; Sat, 18 Aug 2001 17:00:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06439 for ; Sat, 18 Aug 2001 11:30:27 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00892 for ; Sat, 18 Aug 2001 12:30:22 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Sat, 18 Aug 2001 20:30:24 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECA9B2@mail.kebne.se> From: Thomas Eklund To: "'Francis Dupont '" , "'Brian E Carpenter '" Cc: "'ipng '" Subject: RE: Higher level question about flow label Date: Sat, 18 Aug 2001 20:30:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I vote for a semantics where you have MPLS or intserv style semantics and I would also like a bit telling if the packet is encrypted or not. -Francis.Dupont@enst-bretagne.fr -PS: Intserv is not 100% dead because there is an environment (wireless) -where to get more bandwidth is really expensive (in Europe at least :-). -PPS: there is another usage: flow-based switching for fast routing -but I don't believe this really helps (petabit router vendors?) --> No there is no need in term of a flow based switching fast routing since the memory where you store the routing tables are so huge today. 512 K IPv4 prefixes could be stored in one CAM memory and usually you can use several to obtain larger tables - all the CAM vendors support between 1 - 4 M IPv4 prefixes to be stored in their CAM and do one look up in a clock cycle. But many people are using flow to do traffic engneering and that's where I belive the "mpls" op by hop semantic is needed. for the flow label. It would also be easier to signal up to the routing protocls like IS-IS, OSPF. BGP etc when a change occured. -- 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 Sat Aug 18 17:01:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J00d628554 for ipng-dist; Sat, 18 Aug 2001 17:00:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J00YL28536 for ; Sat, 18 Aug 2001 17:00:34 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25883 for ; Fri, 17 Aug 2001 23:03:58 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20045 for ; Fri, 17 Aug 2001 23:03:57 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f7I63KK18561; Sat, 18 Aug 2001 09:03:20 +0300 Date: Sat, 18 Aug 2001 09:03:19 +0300 (EEST) From: Pekka Savola To: Alex Conta cc: Jun-ichiro itojun Hagino , Brian E Carpenter , Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] In-Reply-To: <3B7D8EA4.E735FD96@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 17 Aug 2001, Alex Conta wrote: > The Diffserv QoS engines in the access routers do a policing > (classification&metering&dropping) that trims the high level QoS traffic > -- hacked by a user, or not -- to the level specified in SLAs, TCAs. So, > a user, at the most, uses up all that was contracted with the ISP, and > paid for, anyway. This is in fact THE BEAUTY of THE MODEL. You seem to assume that you would always spoof to get _better_ service. This may not be the case, especially if you have to pay for the premium (and ISP would want you to pay more, of course :). If e.g. some 3G mobiles were using this mechanism, Bastard Operators might set it so that some messages (think SMS) are dirty expensive compared to "normal traffic". Then, if the user would be able to change the label to get those for a cheaper price (and perhaps insignificant loss of QoS) and get billed way less, he might do it. Also, the idea that an operator might do QoS classification etc. on the traffic _for free_ (e.g. add "low delay" to dport 22, 23; low cost to nntp etc.) just to benefit the user(s) is unfamiliar to you? This is where "spoofing" becomes annoying, because people don't pay for the extra QoS. I think this was a basis in "spoofing better QoS capabilities" discussion. -- 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 Aug 18 17:23:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J0MuW28717 for ipng-dist; Sat, 18 Aug 2001 17:22:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J0MaL28709 for ; Sat, 18 Aug 2001 17:22:36 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28594; Sat, 18 Aug 2001 02:05:38 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08556; Sat, 18 Aug 2001 02:05:37 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:b59a:f1da:5780:d1be]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA03147; Sat, 18 Aug 2001 18:08:53 +0900 (JST) Date: Sat, 18 Aug 2001 18:05:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 17 Aug 2001 10:09:32 +0200 (CEST), >>>>> Erik Nordmark said: >> Of course I will. However, we should also provide backward >> compatibility to applications that are statically linked with older >> libraries. (probably my text in the previous message was unclear, >> sorry). > Ah - static linking is such a mess :-( > If you need to solve the static linking issue then there is a hard > problem for passing sin6_scope_id from the kernel to the application. That's right. This is the difficult part of the problem. > Somehow the kernel needs to know whether the application wants the backwards > compatible (top 4 bits being zero so the statically linked > getnameinfo/if_indextoname will work) scope_id or the new one. > Thus the kernel needs to be able to tell whether the application was statically > linked against getnameinfo. This is hard as far as I know. Yes, so, I guess we have (at least) three options. 1. just forget statically linked applications 2. care about statically linked applications for sending side only 3. care about statically linked applications for both sending and receiving side #2 might be a reasonable point of compromise. If we can agree with this, things will be quite easy. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 18 19:47:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J2kfU28865 for ipng-dist; Sat, 18 Aug 2001 19:46:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J2kbL28858 for ; Sat, 18 Aug 2001 19:46:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13906 for ; Sat, 18 Aug 2001 19:46:31 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26628 for ; Sat, 18 Aug 2001 20:46:46 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 139684B21; Sun, 19 Aug 2001 11:46:27 +0900 (JST) To: Francis Dupont Cc: Brian E Carpenter , ipng In-reply-to: Francis.Dupont's message of Fri, 17 Aug 2001 16:21:16 +0200. <200108171421.f7HELGl12433@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Higher level question about flow label From: itojun@iijlab.net Date: Sun, 19 Aug 2001 11:46:27 +0900 Message-ID: <24326.998189187@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the WG needs to decide once and for all whether the flow label is > a) a CATNIP or MPLS-like routing handle > or b) a QOS hint for intserv only > or c) a QOS hint for intserv and diffserv > or d) a waste of bits (b). 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 Sat Aug 18 20:03:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J329p29064 for ipng-dist; Sat, 18 Aug 2001 20:02:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J324L29053 for ; Sat, 18 Aug 2001 20:02:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23742 for ; Sat, 18 Aug 2001 05:18:50 -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 GAA03544 for ; Sat, 18 Aug 2001 06:18:44 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:5dbe:760c:fede:f597]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id VAA04083; Sat, 18 Aug 2001 21:22:01 +0900 (JST) Date: Sat, 18 Aug 2001 21:18:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy Brabson" Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Aug 2001 11:01:30 -0400, >>>>> "Roy Brabson" said: >> Seems like, to the extent that there are existing applications >> which use if_nametoindex() -> sin6_scope_id for link-local addresses, >> we need to also support the top 4 being zero as an alias for the >> interface or link scope. >> >> Does anybody know of such applications? >> Does anybody know of applications doing the reverse (taking sin6_scope_id >> and passing it to if_indextoname())? > This may work when the default link-local zones are used, but how will it > work in the presence of manually-configured link-local zones? It simply won't. We're talking about some existing implementations that assume a one-to-one mapping between links and interfaces. > It is probably useful to have a standard (or at least agreed upon) way to > map between the sin6_scope_id and the zone name, something akin to the > if_nametoindex() and if_indextoname() calls for converting an interface > name to an index and vice-versa. Probably. But once we define clear semantics, it would not be so hard. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 18 20:21:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J3KkR29260 for ipng-dist; Sat, 18 Aug 2001 20:20:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J3KgL29248 for ; Sat, 18 Aug 2001 20:20:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10270 for ; Sat, 18 Aug 2001 02:20:18 -0700 (PDT) Received: from starfruit.itojun.org (dial-143-D06.LON1.equant.net [57.66.6.143]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07373 for ; Sat, 18 Aug 2001 03:20:30 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id EFEA67C1; Sat, 18 Aug 2001 18:19:50 +0900 (JST) To: Alex Conta Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com In-reply-to: aconta's message of Fri, 17 Aug 2001 17:37:40 -0400. <3B7D8EA4.E735FD96@txc.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: [Fwd: draft-conta-ipv6-flow-label-02.txt] From: Jun-ichiro itojun Hagino Date: Sat, 18 Aug 2001 18:19:50 +0900 Message-Id: <20010818091950.EFEA67C1@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> then why you pushed those non-IANA values in the presentation? >> this is the source of confusion. >You refer to the last 2 slides of the 14 slide presentation, each WITH >BIG TITLES: >OTHER POSSIBLE IPv6 FLOW LABEL FORMATS, presenting Appendix A of the >draft. >Your message title confused me: I thought you've read the draft, and >based your comments on the draft. even if they are in the appendix section, it is still true that your idea does not work. I would like to suggest you to drop the appendix A from the next revision of the draft. >at the top of page 27 in the draft, in Appendix A: > >"...IPv6 headers are 8byte aligned, therefore the length could be >represented as the number of 8byte > chunks occupied by the headers, in which case the maximum length would >be 32Kbytes." > >With this representation, the receiver would simply shift the value of >the field with 3 bits, thus ensuring a 8 byte alignment on accessing the >TCP/UDP headers. fair enough, but I really suggest you to drop the section as well, as it won't work. >> how can you trust IPv6 stack that is in the possession of end user? >> they can be hacked up. the only devices you can trust is those you >> administer in your diffserv cloud. you can never trust customers >> devices. >> > >It seems to me that you are still missing the points made earlier. > >The Diffserv QoS engines in the access routers do a policing >(classification&metering&dropping) that trims the high level QoS traffic >-- hacked by a user, or not -- to the level specified in SLAs, TCAs. So, >a user, at the most, uses up all that was contracted with the ISP, and >paid for, anyway. This is in fact THE BEAUTY of THE MODEL. you have been saying, in the thread, that the PHB value gets filled by the originating end. so which is the truth? if the most significant bit of the flow label field is the indication of "end-to-end/hop-by-hop", say so in the draft. there's no indication. 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 Sat Aug 18 21:46:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7J4jTu29698 for ipng-dist; Sat, 18 Aug 2001 21:45:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J4jPL29691 for ; Sat, 18 Aug 2001 21:45:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04010; Sat, 18 Aug 2001 21:45:22 -0700 (PDT) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA23094; Sat, 18 Aug 2001 22:45:34 -0600 (MDT) Received: from duplo.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.5/8.11.3) with ESMTP id f7J4jI712147; Sun, 19 Aug 2001 13:45:18 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.5/8.10.2) id f7J4j0N03923; Sun, 19 Aug 2001 13:45:00 +0900 (JST) Date: Sun, 19 Aug 2001 13:45:00 +0900 (JST) From: Atsushi Onoe Message-Id: <200108190445.f7J4j0N03923@duplo.sm.sony.co.jp> To: jinmei@isl.rdc.toshiba.co.jp Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: Your message of "Sat, 18 Aug 2001 18:05:29 +0900" References: X-Mailer: Cue version 0.6 (010815-1037/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. just forget statically linked applications > 2. care about statically linked applications for sending side only > 3. care about statically linked applications for both sending and > receiving side > > #2 might be a reasonable point of compromise. If we can agree with > this, things will be quite easy. Agreed. And also note that even for such applications, they should accept the textual addresses with non-zero scope. So cut & paste still works well. ex. new kernel old applications -------------------------------------------------------------- fe80::1%link1 - old getnameinfo -> fe80::1%536870913 (fe80::1%0x20000001) fe80::1%link1 <- old getaddrinfo - Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 19 12:33:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7JJUn200984 for ipng-dist; Sun, 19 Aug 2001 12:30:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7JJUjL00977 for ; Sun, 19 Aug 2001 12:30:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08737 for ; Sun, 19 Aug 2001 12:30:40 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10744 for ; Sun, 19 Aug 2001 13:30:56 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA24262; Sun, 19 Aug 2001 20:30:37 +0100 Received: from hursley.ibm.com ([9.29.3.171]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA42870; Sun, 19 Aug 2001 20:30:37 +0100 Message-ID: <3B8013BB.7AD50AA0@hursley.ibm.com> Date: Sun, 19 Aug 2001 14:30:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Eklund CC: "'Francis Dupont '" , "'ipng '" Subject: Re: Higher level question about flow label References: <31A473DBB655D21180850008C71E251A04ECA9B2@mail.kebne.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, How can you combine a routing handle usage with intserv usage? These usages are totally disjoint. It's one or the other. The historical fact (thanks to Frank Solensky for pointing this out in private mail) is that we rejected the routing handle usage right at the beginning of IPv6, even though some people disagreed and still regret it. But we also moved the language about the flow label to an appendix in RFC 2460, which means that many implementors seem to have ignored it. I believe it is time to clean up that ambiguity. BTW it's the presence of an ESP header that tells you if the packet is encrypted. I don't see any need for a bit. Brian Thomas Eklund wrote: > > I vote for a semantics where you have MPLS or intserv style semantics and I > would also like a bit telling if the packet is encrypted or not. > > -Francis.Dupont@enst-bretagne.fr > -PS: Intserv is not 100% dead because there is an environment (wireless) > -where to get more bandwidth is really expensive (in Europe at least :-). > -PPS: there is another usage: flow-based switching for fast routing > -but I don't believe this really helps (petabit router vendors?) > > --> No there is no need in term of a flow based switching fast routing since > the memory where you store the routing tables are so huge today. 512 K IPv4 > prefixes could be stored in one CAM memory and usually you can use several > to obtain larger tables - all the CAM vendors support between 1 - 4 M IPv4 > prefixes to be stored in their CAM and do one look up in a clock cycle. > > But many people are using flow to do traffic engneering and that's where I > belive the "mpls" op by hop semantic is needed. for the flow label. It would > also be easier to signal up to the routing protocls like IS-IS, OSPF. BGP > etc when a change occured. > > -- 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 Sun Aug 19 12:39:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7JJZNu01002 for ipng-dist; Sun, 19 Aug 2001 12:35:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7JJZFL00995 for ; Sun, 19 Aug 2001 12:35:17 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09023 for ; Sun, 19 Aug 2001 12:35:16 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20022 for ; Sun, 19 Aug 2001 12:35:15 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA31868; Sun, 19 Aug 2001 20:35:11 +0100 Received: from hursley.ibm.com ([9.29.3.171]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA42882; Sun, 19 Aug 2001 20:35:09 +0100 Message-ID: <3B8014C0.D3D7F39@hursley.ibm.com> Date: Sun, 19 Aug 2001 14:34:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Pekka Savola CC: Alex Conta , Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Fri, 17 Aug 2001, Alex Conta wrote: > > The Diffserv QoS engines in the access routers do a policing > > (classification&metering&dropping) that trims the high level QoS traffic > > -- hacked by a user, or not -- to the level specified in SLAs, TCAs. So, > > a user, at the most, uses up all that was contracted with the ISP, and > > paid for, anyway. This is in fact THE BEAUTY of THE MODEL. > > You seem to assume that you would always spoof to get _better_ service. > This may not be the case, especially if you have to pay for the premium > (and ISP would want you to pay more, of course :). If e.g. some 3G > mobiles were using this mechanism, Bastard Operators might set it so that > some messages (think SMS) are dirty expensive compared to "normal > traffic". Then, if the user would be able to change the label to get > those for a cheaper price (and perhaps insignificant loss of QoS) and get > billed way less, he might do it. But at busy hour they may get no service at all so I think they will still get what they pay for. > > Also, the idea that an operator might do QoS classification etc. on the > traffic _for free_ (e.g. add "low delay" to dport 22, 23; low cost to nntp > etc.) just to benefit the user(s) is unfamiliar to you? This is where > "spoofing" becomes annoying, because people don't pay for the extra QoS. > I think this was a basis in "spoofing better QoS capabilities" > discussion. Hate to say it, but soft-hearted ISPs who do this will indeed be ripped off by some of their users. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 19 12:48:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7JJlFP01051 for ipng-dist; Sun, 19 Aug 2001 12:47:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7JJlBL01044 for ; Sun, 19 Aug 2001 12:47:12 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00836 for ; Sun, 19 Aug 2001 12:47:13 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23264 for ; Sun, 19 Aug 2001 12:47:11 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA24310; Sun, 19 Aug 2001 20:47:04 +0100 Received: from hursley.ibm.com ([9.29.3.171]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA56216; Sun, 19 Aug 2001 20:47:04 +0100 Message-ID: <3B801774.EE3ABB92@hursley.ibm.com> Date: Sun, 19 Aug 2001 14:45:56 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <20010818091950.EFEA67C1@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun, Jun-ichiro itojun Hagino wrote: > > >> then why you pushed those non-IANA values in the presentation? > >> this is the source of confusion. > >You refer to the last 2 slides of the 14 slide presentation, each WITH > >BIG TITLES: > >OTHER POSSIBLE IPv6 FLOW LABEL FORMATS, presenting Appendix A of the > >draft. > >Your message title confused me: I thought you've read the draft, and > >based your comments on the draft. > > even if they are in the appendix section, it is still true that > your idea does not work. I would like to suggest you to > drop the appendix A from the next revision of the draft. When the WG decides what it wants, we could certainly drop the discussion of the rejected ideas (but sometimes it is useful to at least list the rejected ideas, so that we don't have the same discussion again in 2003). > > >at the top of page 27 in the draft, in Appendix A: > > > >"...IPv6 headers are 8byte aligned, therefore the length could be > >represented as the number of 8byte > > chunks occupied by the headers, in which case the maximum length would > >be 32Kbytes." > > > >With this representation, the receiver would simply shift the value of > >the field with 3 bits, thus ensuring a 8 byte alignment on accessing the > >TCP/UDP headers. > > fair enough, but I really suggest you to drop the section as well, > as it won't work. > > >> how can you trust IPv6 stack that is in the possession of end user? > >> they can be hacked up. the only devices you can trust is those you > >> administer in your diffserv cloud. you can never trust customers > >> devices. > >> > > > >It seems to me that you are still missing the points made earlier. > > > >The Diffserv QoS engines in the access routers do a policing > >(classification&metering&dropping) that trims the high level QoS traffic > >-- hacked by a user, or not -- to the level specified in SLAs, TCAs. So, > >a user, at the most, uses up all that was contracted with the ISP, and > >paid for, anyway. This is in fact THE BEAUTY of THE MODEL. > > you have been saying, in the thread, that the PHB value gets filled > by the originating end. so which is the truth? if the most > significant bit of the flow label field is the indication of > "end-to-end/hop-by-hop", say so in the draft. there's no indication. The DSCP MAY be rewritten *anywhere* along the path, typically at an administrative domain boundary. Even if it is initially set by the source host, it MAY be rewritten each time the packet goes through a multi-field classifier. Thus, the value is not altered at every hop, but it may not be e2e either. The distinction made in the proposal by the MSB is between a pseudo-random value as defined in RFC 2460 Appendix A (for intserv) and a non-random value (for diffserv). But they are both e2e values, unlike the DSCP. This should be documented. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 19 15:02:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7JM0xc01378 for ipng-dist; Sun, 19 Aug 2001 15:00:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7JM0tL01371 for ; Sun, 19 Aug 2001 15:00:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15222 for ; Sun, 19 Aug 2001 15:00:57 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21749 for ; Sun, 19 Aug 2001 15:00:56 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 00:00:54 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> From: Thomas Eklund To: "'Brian E Carpenter '" , Thomas Eklund Cc: "''Francis Dupont ' '" , "''ipng ' '" Subject: RE: Higher level question about flow label Date: Mon, 20 Aug 2001 00:00:53 +0200 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 f7JM0uL01372 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Brian, The intention is not to combine those at the same time the idea I support is to let people have both and let the user decide. Baically I see two different scenarios: 1) service provider, hop-by-hop semantic and wants the flowlabel to resemble mpls flow label 2) enterprise, end-to-end (within the admin doman i.e. the enerprise) where you probably would like a intserv model. I dont see the need for defining a diffserv model since you have a diffserv label today, but if there is many ISP that want more DSCP then I would support it (eventhough the ISP talk is not looking for that in a near future). regards Thomas -----Original Message----- From: Brian E Carpenter To: Thomas Eklund Cc: 'Francis Dupont '; 'ipng ' Sent: 2001-08-19 21:30 Subject: Re: Higher level question about flow label Thomas, How can you combine a routing handle usage with intserv usage? These usages are totally disjoint. It's one or the other. The historical fact (thanks to Frank Solensky for pointing this out in private mail) is that we rejected the routing handle usage right at the beginning of IPv6, even though some people disagreed and still regret it. But we also moved the language about the flow label to an appendix in RFC 2460, which means that many implementors seem to have ignored it. I believe it is time to clean up that ambiguity. BTW it's the presence of an ESP header that tells you if the packet is encrypted. I don't see any need for a bit. Brian Thomas Eklund wrote: > > I vote for a semantics where you have MPLS or intserv style semantics and I > would also like a bit telling if the packet is encrypted or not. > > -Francis.Dupont@enst-bretagne.fr > -PS: Intserv is not 100% dead because there is an environment (wireless) > -where to get more bandwidth is really expensive (in Europe at least :-). > -PPS: there is another usage: flow-based switching for fast routing > -but I don't believe this really helps (petabit router vendors?) > > --> No there is no need in term of a flow based switching fast routing since > the memory where you store the routing tables are so huge today. 512 K IPv4 > prefixes could be stored in one CAM memory and usually you can use several > to obtain larger tables - all the CAM vendors support between 1 - 4 M IPv4 > prefixes to be stored in their CAM and do one look up in a clock cycle. > > But many people are using flow to do traffic engneering and that's where I > belive the "mpls" op by hop semantic is needed. for the flow label. It would > also be easier to signal up to the routing protocls like IS-IS, OSPF. BGP > etc when a change occured. > > -- 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 Sun Aug 19 19:58:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K2voq01764 for ipng-dist; Sun, 19 Aug 2001 19:57:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K2vkL01757 for ; Sun, 19 Aug 2001 19:57:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14678 for ; Sun, 19 Aug 2001 19:57:47 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA06765 for ; Sun, 19 Aug 2001 20:57:42 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24320; Sun, 19 Aug 2001 22:57:42 -0400 Date: Sun, 19 Aug 2001 22:57:42 -0400 (EDT) From: Jim Bound To: Brian E Carpenter Cc: ipng Subject: Re: Higher level question about flow label In-Reply-To: <3B7BCE71.BE8DB82E@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 Hi Brian, Good idea. I vote for b. As first input. /jim On Thu, 16 Aug 2001, Brian E Carpenter wrote: > I think the WG needs to decide once and for all whether the flow label is > a) a CATNIP or MPLS-like routing handle > or b) a QOS hint for intserv only > or c) a QOS hint for intserv and diffserv > or d) a waste of bits > > We can get back to the details once we have a consensus on this. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 19 20:03:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K32ro01806 for ipng-dist; Sun, 19 Aug 2001 20:02:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K32nL01799 for ; Sun, 19 Aug 2001 20:02:49 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14987 for ; Sun, 19 Aug 2001 20:02:44 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA07460 for ; Sun, 19 Aug 2001 20:02:43 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24581; Sun, 19 Aug 2001 23:02:28 -0400 Date: Sun, 19 Aug 2001 23:02:28 -0400 (EDT) From: Jim Bound To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics 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 Folks, In the next few weeks I will be updating the base api to be in accordance with the IEEE wording. I assume you all have reviewed that over the last month. I see no consensus on sin6_scope_id. Hence, I will do nothing to alter its semantics or syntax. /jim On Thu, 16 Aug 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Thu, 16 Aug 2001 15:40:25 +0200 (CEST), > >>>>> Erik Nordmark said: > > > Seems like, to the extent that there are existing applications > > which use if_nametoindex() -> sin6_scope_id for link-local addresses, > > we need to also support the top 4 being zero as an alias for the > > interface or link scope. > > > Does anybody know of such applications? > > Does anybody know of applications doing the reverse (taking sin6_scope_id > > and passing it to if_indextoname())? > > Actually, since our (i.e. KAME/BSD's) getaddrinfo() and getnameinfo() > use this mapping, all applications that use those two functions are > affected, including ping, traceroute, ifconfig, netstat, route, > telnet, ssh, ftp,... > > So we should probably provide some trick to ensure backward > compatibility for such applications. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 19 20:12:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K3BR201855 for ipng-dist; Sun, 19 Aug 2001 20:11:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K3BNL01848 for ; Sun, 19 Aug 2001 20:11:23 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23179 for ; Sun, 19 Aug 2001 20:11:24 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA09434 for ; Sun, 19 Aug 2001 20:11:24 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27495; Sun, 19 Aug 2001 23:11:12 -0400 Date: Sun, 19 Aug 2001 23:11:11 -0400 (EDT) From: Jim Bound To: Bill Sommerfeld Cc: Bob Hinden , Brian E Carpenter , ipng Subject: Re: Higher level question about flow label In-Reply-To: <200108170713.f7H7D0015748@thunk.east.sun.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We cannot define it now for MUST be zero. RSVPv6 uses its. But because it is random I don't agree means that specific bits can't be identified later if we need to. When the flow is encoded at such a point in time specific values will cause an error to the init app creating it (as I am a supporter of "b"). /jim On Fri, 17 Aug 2001, Bill Sommerfeld wrote: > > I would like to suggest another choice: > > > > e) a set of bits we hold in reserve for the future > > > > I don't think that we have enough experience to pick between a), b), or c) > > now, and think that something might come up in the future where 28 bits in > > the IPv6 header might be very useful. This might not have anything to do > > with QOS. > > Currently the field is defined as "must be random"; if we want to > preserve the ability to recycle it for something else in the future, > we need to redefine it *NOW* as a "must be zero". > > - Bill > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 19 20:18:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K3HoN01889 for ipng-dist; Sun, 19 Aug 2001 20:17:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K3HlL01882 for ; Sun, 19 Aug 2001 20:17:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA15765 for ; Sun, 19 Aug 2001 20:17:48 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA12659 for ; Sun, 19 Aug 2001 21:17:43 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26716; Sun, 19 Aug 2001 23:17:41 -0400 Date: Sun, 19 Aug 2001 23:17:41 -0400 (EDT) From: Jim Bound To: Tim Chown Cc: Francis Dupont , ipng Subject: Re: Higher level question about flow label 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 Yes I would as a note. I want what we orginally called for and to make sure nothing breaks RSVPv6 which uses the flowlabel too. /jim On Fri, 17 Aug 2001, Tim Chown wrote: > On Fri, 17 Aug 2001, Francis Dupont wrote: > > > In your previous mail you wrote: > > > > I think the WG needs to decide once and for all whether the flow label is > > a) a CATNIP or MPLS-like routing handle > > or b) a QOS hint for intserv only > > or c) a QOS hint for intserv and diffserv > > or d) a waste of bits > > > > => I vote for b) > > So would you vote to mandate that the field is non-mutable in transit too? > > tim > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 19 20:26:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K3Q4A01930 for ipng-dist; Sun, 19 Aug 2001 20:26:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K3Q0L01923 for ; Sun, 19 Aug 2001 20:26:00 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05673 for ; Sun, 19 Aug 2001 20:26:01 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA12125 for ; Sun, 19 Aug 2001 20:26:00 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA20269; Sun, 19 Aug 2001 23:25:57 -0400 Date: Sun, 19 Aug 2001 23:25:57 -0400 (EDT) From: Jim Bound To: Bob Hinden Cc: Brian E Carpenter , ipng Subject: Re: Higher level question about flow label In-Reply-To: <4.3.2.7.2.20010817093007.0251f0b8@mailhost.iprg.nokia.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think we should do b via an experimental draft. Go write some code and see if it works in the test beds (e.g. 6bone, 6init, Eurosix, DoD). Then report back. This will give us some experience. I think doing anything to promote routing based on transport+port is a bad technical idea and strategy for IPv6. IPv6 should put an end to that type of route lookup and forwarding now. Also regarding the argument of not knowing the length of headers, Itojun is correct we cannot put that in the flow label it will create bugs and is not prudent. We have long known that the forwarding path will have to live with extensibile headers. It is a done deal and we should move forward. Let the best engineers win who are are the smartest to create algorithms that can adapt to IPv6 extensibility. /jim On Fri, 17 Aug 2001, Bob Hinden wrote: > Brian, > > > > I don't think that we have enough experience to pick between a), b), or c) > > > now, and think that something might come up in the future where 28 bits in > > > the IPv6 header might be very useful. This might not have anything to do > > > with QOS. > > > >I think you mean 20 bits. The traffic class octet is fully standardised by > >diffserv and ECN. > > Yes, my error. I was not suggesting we change the traffic class field. > > >The problem with this is that the text we have today effectively selects > >option b), since it endorses the pseudo-random value. If we do nothing, > >we have effectively chosen the intserv-only usage. That's why I started > >this thread. > > I agree. It was good to ask the question. > > The point I was trying to make is that while we have now many QOS > standards, we don't have very much deployment experience. As such it is > hard to tell if it is worthwhile to use these 20 bits to optimize QOS > performance. > > Bob > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 19 20:33:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K3XCu01972 for ipng-dist; Sun, 19 Aug 2001 20:33:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K3X8L01965 for ; Sun, 19 Aug 2001 20:33:09 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06211 for ; Sun, 19 Aug 2001 20:33:09 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA14696 for ; Sun, 19 Aug 2001 20:33:08 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA10426; Sun, 19 Aug 2001 23:32:51 -0400 Date: Sun, 19 Aug 2001 23:32:51 -0400 (EDT) From: Jim Bound To: Brian E Carpenter Cc: Thomas Eklund , "'Francis Dupont '" , "'ipng '" Subject: Re: Higher level question about flow label In-Reply-To: <3B8013BB.7AD50AA0@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 Brian, Just to note. You have 3 hard votes for b. How long do we hold the voting booth open? I suggest one month. /jim On Sun, 19 Aug 2001, Brian E Carpenter wrote: > Thomas, > > How can you combine a routing handle usage with intserv usage? > These usages are totally disjoint. It's one or the other. > > The historical fact (thanks to Frank Solensky for pointing this out in > private mail) is that we rejected the routing handle usage right at > the beginning of IPv6, even though some people disagreed and still regret > it. But we also moved the language about the flow label to an appendix > in RFC 2460, which means that many implementors seem to have ignored it. > I believe it is time to clean up that ambiguity. > > BTW it's the presence of an ESP header that tells you if the packet is > encrypted. I don't see any need for a bit. > > Brian > > Thomas Eklund wrote: > > > > I vote for a semantics where you have MPLS or intserv style semantics and I > > would also like a bit telling if the packet is encrypted or not. > > > > -Francis.Dupont@enst-bretagne.fr > > -PS: Intserv is not 100% dead because there is an environment (wireless) > > -where to get more bandwidth is really expensive (in Europe at least :-). > > -PPS: there is another usage: flow-based switching for fast routing > > -but I don't believe this really helps (petabit router vendors?) > > > > --> No there is no need in term of a flow based switching fast routing since > > the memory where you store the routing tables are so huge today. 512 K IPv4 > > prefixes could be stored in one CAM memory and usually you can use several > > to obtain larger tables - all the CAM vendors support between 1 - 4 M IPv4 > > prefixes to be stored in their CAM and do one look up in a clock cycle. > > > > But many people are using flow to do traffic engneering and that's where I > > belive the "mpls" op by hop semantic is needed. for the flow label. It would > > also be easier to signal up to the routing protocls like IS-IS, OSPF. BGP > > etc when a change occured. > > > > -- thomas > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 19 20:38:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K3beJ02013 for ipng-dist; Sun, 19 Aug 2001 20:37:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K3baL02006 for ; Sun, 19 Aug 2001 20:37:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17508 for ; Sun, 19 Aug 2001 20:37:27 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA18955 for ; Sun, 19 Aug 2001 21:37:23 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24383; Sun, 19 Aug 2001 23:37:18 -0400 Date: Sun, 19 Aug 2001 23:37:18 -0400 (EDT) From: Jim Bound To: Thomas Eklund Cc: "'Brian E Carpenter '" , "''Francis Dupont ' '" , "''ipng ' '" Subject: RE: Higher level question about flow label In-Reply-To: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> 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 f7K3bbL02007 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thomas, the flowlabel with src global addr can be used by the CAM or SRAM for CATNIP or MPLS lookup. Why differentiate types of use? With b the Intserv model one gets a is my belief? thanks /jim On Mon, 20 Aug 2001, Thomas Eklund wrote: > Dear Brian, > The intention is not to combine those at the same time the idea I support is > to let people have both and let the user decide. > > Baically I see two different scenarios: > 1) service provider, hop-by-hop semantic and wants the flowlabel to resemble > mpls flow label > 2) enterprise, end-to-end (within the admin doman i.e. the enerprise) where > you probably would like a intserv model. > > I dont see the need for defining a diffserv model since you have a diffserv > label today, but if there is many ISP that want more DSCP then I would > support it (eventhough the ISP talk is not looking for that in a near > future). > regards > Thomas > > > > -----Original Message----- > From: Brian E Carpenter > To: Thomas Eklund > Cc: 'Francis Dupont '; 'ipng ' > Sent: 2001-08-19 21:30 > Subject: Re: Higher level question about flow label > > Thomas, > > How can you combine a routing handle usage with intserv usage? > These usages are totally disjoint. It's one or the other. > > The historical fact (thanks to Frank Solensky for pointing this out in > private mail) is that we rejected the routing handle usage right at > the beginning of IPv6, even though some people disagreed and still > regret > it. But we also moved the language about the flow label to an appendix > in RFC 2460, which means that many implementors seem to have ignored it. > I believe it is time to clean up that ambiguity. > > BTW it's the presence of an ESP header that tells you if the packet is > encrypted. I don't see any need for a bit. > > > Brian > > Thomas Eklund wrote: > > > > I vote for a semantics where you have MPLS or intserv style semantics > and I > > would also like a bit telling if the packet is encrypted or not. > > > > -Francis.Dupont@enst-bretagne.fr > > -PS: Intserv is not 100% dead because there is an environment > (wireless) > > -where to get more bandwidth is really expensive (in Europe at least > :-). > > -PPS: there is another usage: flow-based switching for fast routing > > -but I don't believe this really helps (petabit router vendors?) > > > > --> No there is no need in term of a flow based switching fast routing > since > > the memory where you store the routing tables are so huge today. 512 K > IPv4 > > prefixes could be stored in one CAM memory and usually you can use > several > > to obtain larger tables - all the CAM vendors support between 1 - 4 M > IPv4 > > prefixes to be stored in their CAM and do one look up in a clock > cycle. > > > > But many people are using flow to do traffic engneering and that's > where I > > belive the "mpls" op by hop semantic is needed. for the flow label. It > would > > also be easier to signal up to the routing protocls like IS-IS, OSPF. > BGP > > etc when a change occured. > > > > -- thomas > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 20 01:39:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K8cfr02485 for ipng-dist; Mon, 20 Aug 2001 01:38:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K8cbL02478 for ; Mon, 20 Aug 2001 01:38:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22891 for ; Mon, 20 Aug 2001 01:38:39 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12570 for ; Mon, 20 Aug 2001 02:38:29 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7K8gEG20799 for ; Mon, 20 Aug 2001 11:42:14 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 20 Aug 2001 11:38:28 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVW49C>; Mon, 20 Aug 2001 11:38:27 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FD5@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Mon, 20 Aug 2001 11:38:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Out of your choices I vote for (b). I also vote for John's notion of "just a QoS hint". Also, relax the pseudo-random number requirement of the flow label. Routers can't really know how good the PRF used by the host is, so no router should assume the flow label to be a pseudo random number! Also, if the flow label does not need to be a result of a PRF, usage of "well-known values" becomes possible, if anyone ever would find a need for that (currently I really don't see the need for this as the Traffic Class should provide more than enough tags for aggregates needing specific per-hop-behavior). Additionally, the flow label should not be mutable in transit, except within specific "QoS domains", where the flow-label value could temporarily be changed. I mean that the value seen at the flow label field on "QoS domain" entry will be restored at the "QoS domain" exit. Whatever signaling etc. might be needed to effect this is the problem of the "QoS domain". End-to-end the value should not be changed, except, perhaps as Francis suggested to allow it to be changed once from all-zero to a non-zero value. As for routing, the addresses themselves should be sufficient. And isn't MPLS supposed to live beneath the IP-layer? Jarno > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 16. elokuuta 2001 16:45 > To: ipng > Subject: Higher level question about flow label > > > I think the WG needs to decide once and for all whether the > flow label is > a) a CATNIP or MPLS-like routing handle > or b) a QOS hint for intserv only > or c) a QOS hint for intserv and diffserv > or d) a waste of bits > > We can get back to the details once we have a consensus on this. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 01:47:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K8lM902661 for ipng-dist; Mon, 20 Aug 2001 01:47:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K8lHL02649 for ; Mon, 20 Aug 2001 01:47:17 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23580 for ; Mon, 20 Aug 2001 01:47:18 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07337 for ; Mon, 20 Aug 2001 01:47:13 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7K8ovG25837 for ; Mon, 20 Aug 2001 11:50:57 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 20 Aug 2001 11:47:11 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVWV34>; Mon, 20 Aug 2001 11:47:11 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FD6@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, itojun@iijlab.net Cc: aconta@txc.com, ipng@sunroof.eng.sun.com Subject: RE: [Fwd: draft-conta-ipv6-flow-label-02.txt] Date: Mon, 20 Aug 2001 11:46:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian wrote: > The distinction made in the proposal by the MSB is between a > pseudo-random > value as defined in RFC 2460 Appendix A (for intserv) and a > non-random value > (for diffserv). But they are both e2e values, unlike the > DSCP. This should > be documented. > But who need any of the values to be pseudo-random? Intserv would work just fine if the flow label values would be taken out of the sequence 1,2,3,4,... Intserv signaling should provide for no problem of re-use after reboot either, since after a reboot the signaling would be done again before any use of the flow label. 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 Mon Aug 20 02:16:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K9FRb02787 for ipng-dist; Mon, 20 Aug 2001 02:15:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K9FNL02780 for ; Mon, 20 Aug 2001 02:15:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16926 for ; Mon, 20 Aug 2001 02:15:26 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07049 for ; Mon, 20 Aug 2001 02:15:25 -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.5/8.11.5) with ESMTP id f7K9F8x09998; Mon, 20 Aug 2001 11:15:09 +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 LAA02672; Mon, 20 Aug 2001 11:15:08 +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.11.3/8.11.3) with ESMTP id f7K9F4l31391; Mon, 20 Aug 2001 11:15:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108200915.f7K9F4l31391@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Atsushi Onoe , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Sat, 18 Aug 2001 17:31:44 +0900. Date: Mon, 20 Aug 2001 11:15:04 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I prefer real names than xxxNNN. Can we get both (i.e. a config file > plus a default translation rule)? I do not object to introducing real names, but I'd like to leave that part as implementation dependent, and just define the formal aliases (like "link2") in the scope architecture draft. => I don't understand your problem there: I prefer fe80::xxxx%eth0 to fe80::xxxx%link12, I believe you too... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 20 02:20:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K9KM002825 for ipng-dist; Mon, 20 Aug 2001 02:20:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K9KIL02818 for ; Mon, 20 Aug 2001 02:20:18 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12417 for ; Mon, 20 Aug 2001 02:20:20 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08585 for ; Mon, 20 Aug 2001 02:20:20 -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.5/8.11.5) with ESMTP id f7K9KBx10330; Mon, 20 Aug 2001 11:20: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 LAA02748; Mon, 20 Aug 2001 11:20:11 +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.11.3/8.11.3) with ESMTP id f7K9KBl31434; Mon, 20 Aug 2001 11:20:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108200920.f7K9KBl31434@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Sat, 18 Aug 2001 18:10:58 +0900. Date: Mon, 20 Aug 2001 11:20:11 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at laposte.enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm not sure about the issue of "net$cape", but we (some KAME users and I) sometimes use link-local addresses for ssh and telnet, in order => ssh and telnet are standard applications on *BSD (and there are dynamicallly linked). So they will inherit the getnameinfo update to log into an adjacent node (typically a router); % ssh fe80::1234%2 => % ssh fe80::1234%link2 will be better, and % ssh fe80::1234%eth0 even better! Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 20 02:32:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7K9Vps02886 for ipng-dist; Mon, 20 Aug 2001 02:31:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7K9VlL02879 for ; Mon, 20 Aug 2001 02:31:47 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27069 for ; Mon, 20 Aug 2001 02:31:49 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11854 for ; Mon, 20 Aug 2001 02:31:48 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Mon, 20 Aug 2001 11:31:51 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECA9B9@mail.kebne.se> From: Thomas Eklund To: "'Jim Bound'" , Thomas Eklund Cc: "'Brian E Carpenter '" , "''Francis Dupont ' '" , "''ipng ' '" Subject: RE: Higher level question about flow label Date: Mon, 20 Aug 2001 11:31:50 +0200 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 f7K9VlL02880 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, Of course it can, a CAM is programmable and that's not he problem, in fact the current with the current CAM you could do a 576 bit wide lookup if you are smart (and those bits does not need to be consecutive in the packet) in OC-192 which is sufficient for IPv6 multicast. It can but I dont belive in a model where the intserv bits will be carried end-to-end (over some transit provider) and can be trusted on the other end. I would put my two cents on the model where the intserv flow label only is going to be used within the enterprise or within an administrative domain (like an Radio Access Network in 3G) What I also think that b will be a good model where for instance you could signal the flow end to end over a VPN. The a model could really benfit when it comes to native TE for IPv6. You also really simplify the mpls model and get a the same approach for IPv6 where you could do TE over your IPv6 flows. That mean that you would make IPv6 "link-layer ware". I see many benefits of such an approach besides the obvius one the intserv which I also support. -- thomas >-----Original Message----- >From: Jim Bound [mailto:seamus@bit-net.com] >Sent: den 20 augusti 2001 05:37 >To: Thomas Eklund >Cc: 'Brian E Carpenter '; ''Francis Dupont ' '; ''ipng ' ' >Subject: RE: Higher level question about flow label > > >thomas, > >the flowlabel with src global addr can be used by the CAM or SRAM for >CATNIP or MPLS lookup. > >Why differentiate types of use? > >With b the Intserv model one gets a is my belief? > >thanks > > >/jim > > >On Mon, 20 Aug 2001, Thomas Eklund wrote: > >> Dear Brian, >> The intention is not to combine those at the same time the >idea I support is >> to let people have both and let the user decide. >> >> Baically I see two different scenarios: >> 1) service provider, hop-by-hop semantic and wants the >flowlabel to resemble >> mpls flow label >> 2) enterprise, end-to-end (within the admin doman i.e. the >enerprise) where >> you probably would like a intserv model. >> >> I dont see the need for defining a diffserv model since you >have a diffserv >> label today, but if there is many ISP that want more DSCP >then I would >> support it (eventhough the ISP talk is not looking for >that in a near >> future). >> regards >> Thomas >> >> >> >> -----Original Message----- >> From: Brian E Carpenter >> To: Thomas Eklund >> Cc: 'Francis Dupont '; 'ipng ' >> Sent: 2001-08-19 21:30 >> Subject: Re: Higher level question about flow label >> >> Thomas, >> >> How can you combine a routing handle usage with intserv usage? >> These usages are totally disjoint. It's one or the other. >> >> The historical fact (thanks to Frank Solensky for pointing >this out in >> private mail) is that we rejected the routing handle usage right at >> the beginning of IPv6, even though some people disagreed and still >> regret >> it. But we also moved the language about the flow label to >an appendix >> in RFC 2460, which means that many implementors seem to have >ignored it. >> I believe it is time to clean up that ambiguity. >> >> BTW it's the presence of an ESP header that tells you if the >packet is >> encrypted. I don't see any need for a bit. >> >> >> Brian >> >> Thomas Eklund wrote: >> > >> > I vote for a semantics where you have MPLS or intserv >style semantics >> and I >> > would also like a bit telling if the packet is encrypted or not. >> > >> > -Francis.Dupont@enst-bretagne.fr >> > -PS: Intserv is not 100% dead because there is an environment >> (wireless) >> > -where to get more bandwidth is really expensive (in >Europe at least >> :-). >> > -PPS: there is another usage: flow-based switching for fast routing >> > -but I don't believe this really helps (petabit router vendors?) >> > >> > --> No there is no need in term of a flow based switching >fast routing >> since >> > the memory where you store the routing tables are so huge >today. 512 K >> IPv4 >> > prefixes could be stored in one CAM memory and usually you can use >> several >> > to obtain larger tables - all the CAM vendors support >between 1 - 4 M >> IPv4 >> > prefixes to be stored in their CAM and do one look up in a clock >> cycle. >> > >> > But many people are using flow to do traffic engneering and that's >> where I >> > belive the "mpls" op by hop semantic is needed. for the >flow label. It >> would >> > also be easier to signal up to the routing protocls like >IS-IS, OSPF. >> BGP >> > etc when a change occured. >> > >> > -- thomas >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 20 04:35:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KBYDM03334 for ipng-dist; Mon, 20 Aug 2001 04:34:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KBYAL03327 for ; Mon, 20 Aug 2001 04:34:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20727 for ; Mon, 20 Aug 2001 04:34:11 -0700 (PDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01626 for ; Mon, 20 Aug 2001 05:34:05 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f7KBVxD19600; Mon, 20 Aug 2001 07:32:00 -0400 Message-Id: <200108201132.f7KBVxD19600@hygro.adsl.duke.edu> To: Brian E Carpenter cc: Bob Hinden , ipng Subject: Re: Higher level question about flow label In-Reply-To: Message from Brian E Carpenter of "Fri, 17 Aug 2001 09:15:19 CDT." <3B7D26F7.234F52D0@hursley.ibm.com> Date: Mon, 20 Aug 2001 07:31:59 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The problem with this is that the text we have today effectively selects > option b), since it endorses the pseudo-random value. If we do nothing, > we have effectively chosen the intserv-only usage. That's why I started > this thread. Is this really the case? RFC 2460 actually says: > 6. Flow Labels > > The 20-bit Flow Label field in the IPv6 header may be used by a > source to label sequences of packets for which it requests special > handling by the IPv6 routers, such as non-default quality of service > or "real-time" service. This aspect of IPv6 is, at the time of > writing, still experimental and subject to change as the requirements > for flow support in the Internet become clearer. Hosts or routers > that do not support the functions of the Flow Label field are > required to set the field to zero when originating a packet, pass the > field on unchanged when forwarding a packet, and ignore the field > when receiving a packet. > > Appendix A describes the current intended semantics and usage of the > Flow Label field. The only place that I know of where the Flow Label bits appear to be used is in RFC 2205 (Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification). It says: > 2. IPv6 inserts a variable number of variable-length Internet- > layer headers before the transport header, increasing the > difficulty and cost of packet classification for QoS. > > Efficient classification of IPv6 data packets could be > obtained using the Flow Label field of the IPv6 header. The > details will be provided in the future. RFC 2205 does include an "IPv6 Flow-label FILTER_SPEC", but by my very quick skimming this appears to be a separate filter spec in addition to the normal IPv6 one that just uses ports, address, etc. I.e., its not required to make use of RSVP in IPv6. Personally, I do not see the need to further define the Flow Label field just for the sake of defining it. These are effectively unused bits that may become useful at some time in the future that we can't well anticipate. When someone can make a compelling argument for why the bits need to be defined in a certain way (i.e., there is a real application for which using the bits provides significant benefits, and those benefits do not appear achievable through other means) that is the time to define the bits. What I do sense with many of the recent discussions surrounding the Flow Label is that there are many folks (i.e., folks putting IPv6 into hardware) that want to know what they should implement w.r.t. the Flow Label. While it would be nice to be able tell them what to do, we shouldn't standardize something just for the sake of having a definition. 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 Aug 20 05:02:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KC20A03438 for ipng-dist; Mon, 20 Aug 2001 05:02:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KC1uL03431 for ; Mon, 20 Aug 2001 05:01:56 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07080 for ; Mon, 20 Aug 2001 05:01:54 -0700 (PDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09716 for ; Mon, 20 Aug 2001 05:01:53 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id GAA69882; Mon, 20 Aug 2001 06:59:21 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7KC1Su25400; Mon, 20 Aug 2001 08:01:28 -0400 Subject: Re: Wrap up and last call: sin6_scope_id semantics To: Francis Dupont Cc: ipng@sunroof.eng.sun.com, JINMEI Tatuya / =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Atsushi Onoe X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Mon, 20 Aug 2001 08:01:20 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 08/20/2001 08:01:28 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, 08/20/2001 at 11:15 ZE2, Francis Dupont wrote: > In your previous mail you wrote: > > > => I prefer real names than xxxNNN. Can we get both (i.e. a config file > > plus a default translation rule)? > > I do not object to introducing real names, but I'd like to leave that > part as implementation dependent, and just define the formal aliases > (like "link2") in the scope architecture draft. > > => I don't understand your problem there: I prefer fe80::xxxx%eth0 to > fe80::xxxx%link12, I believe you too... I also prefer eth0 over link12. Using the names used to define the zones (either the default interface names or actual zone definitions) seems to be more useful than generating a somewhat arbitrary name and displaying that. How is the user supposed to correlate link12 back to the actual eth0 interface, anyway? I imagine another external or display could be used, but this would seem to introduce yet another step for a user to identify the particular interface/zone in question. Roy Brabson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 05:06:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KC5io03488 for ipng-dist; Mon, 20 Aug 2001 05:05:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KC5eL03481 for ; Mon, 20 Aug 2001 05:05:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23524 for ; Mon, 20 Aug 2001 05:05:41 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11773 for ; Mon, 20 Aug 2001 06:05:55 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 38ECC7BA for ; Mon, 20 Aug 2001 21:05:18 +0900 (JST) To: ipng In-reply-to: narten's message of Mon, 20 Aug 2001 07:31:59 -0400. <200108201132.f7KBVxD19600@hygro.adsl.duke.edu> 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: Higher level question about flow label From: Jun-ichiro itojun Hagino Date: Mon, 20 Aug 2001 21:05:18 +0900 Message-Id: <20010820120518.38ECC7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I voted for (b), with our past experience.reason. It may be useful to comment from out experiences, so I'll try to explain. We had some offsite meeting network setup in Japan, just like IETF terminal cluster, but with more aggressive experimental one. We used diffserv with prioritized queueing of some sort (kjc@csl.sony.co.jp should be able to refresh my memory about more detail), as well as integrated MPLS + diffserv network (diffserv classification, you can purchase bandwidth guarantee by virtual currency, traffic goes through dedicated MPLS path). Both of the time, major portion of the traffic was HTTP (TCP port 80), or SSH (TCP port 22). the fact made the classification guys (including kjc) irritated, as almost all the traffic look the same and there's no fun in doing port-based classification. Also, once someone uses ESP, it becomes impossible to classify based on port number. So, kjc wanted to at least identify each of the flow, at least for statistics purposes, as well as traffic classification/policying if possible. Even if end nodes use ESP, he would liked to identify a flow from other flows. So, he wanted us to attach unique pseudorandom flow label per flow. This leads us to (b), and that's one of the reason why draft-itojun-ipv6-flowlabel-api-02.txt is based on (b). It is true that the originating node can put random value into flow label and confuse classifier, but there's no point in doing that. Also, it is true that it may help if the originating node can fill in port number information into the flow label, however, the originating nodes are not that cooperative. End-to-end pseudorandom value looks like the most useful, and most easier-to-manage for originating nodes (without requiring too much information leak). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 20 05:54:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KCraV03629 for ipng-dist; Mon, 20 Aug 2001 05:53:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KCrXL03622 for ; Mon, 20 Aug 2001 05:53:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12178 for ; Mon, 20 Aug 2001 05:53:34 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12231 for ; Mon, 20 Aug 2001 06:53:30 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7KCrAp09522 for ; Mon, 20 Aug 2001 08:53:10 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Mon, 20 Aug 2001 08:53:23 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RDHH3JVV; Mon, 20 Aug 2001 08:53:23 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5NCX3; Mon, 20 Aug 2001 08:53:22 -0400 Message-ID: <3B81083C.1E404938@americasm06.nt.com> Date: Mon, 20 Aug 2001 08:53:17 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Bob Hinden , ipng Subject: Re: Higher level question about flow label References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I would vote for (e) as well. I would rather wait until someone can demonstrate that an application/use will benefit greatly from the use of the flow label bits. Brian Bob Hinden wrote: > > Brian, > > At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote: > >I think the WG needs to decide once and for all whether the flow label is > > a) a CATNIP or MPLS-like routing handle > >or b) a QOS hint for intserv only > >or c) a QOS hint for intserv and diffserv > >or d) a waste of bits > > I would like to suggest another choice: > > e) a set of bits we hold in reserve for the future > > I don't think that we have enough experience to pick between a), b), or c) > now, and think that something might come up in the future where 28 bits in > the IPv6 header might be very useful. This might not have anything to do > with QOS. > > Bob > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 07:32:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KEVBB04334 for ipng-dist; Mon, 20 Aug 2001 07:31:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KEV5L04327 for ; Mon, 20 Aug 2001 07:31:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28633 for ; Mon, 20 Aug 2001 07:31:06 -0700 (PDT) Received: from starfruit.itojun.org (dhcp0.itojun.org [210.160.95.106]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16808 for ; Mon, 20 Aug 2001 08:31:00 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 3D44A7BA; Mon, 20 Aug 2001 21:06:26 +0900 (JST) To: "Roy Brabson" Cc: Francis Dupont , ipng@sunroof.eng.sun.com, JINMEI Tatuya / =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= , Atsushi Onoe In-reply-to: rbrabson's message of Mon, 20 Aug 2001 08:01:20 -0400. 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: Wrap up and last call: sin6_scope_id semantics From: Jun-ichiro itojun Hagino Date: Mon, 20 Aug 2001 21:06:26 +0900 Message-Id: <20010820120626.3D44A7BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I also prefer eth0 over link12. Using the names used to define the zones >(either the default interface names or actual zone definitions) seems to be >more useful than generating a somewhat arbitrary name and displaying that. >How is the user supposed to correlate link12 back to the actual eth0 >interface, anyway? I imagine another external or display could be used, >but this would seem to introduce yet another step for a user to identify >the particular interface/zone in question. I guess textual representation is outside of the scope of the discussion. it is the matter of getaddrinfo/getnameinfo behavior, and it is outside of the scope of sin6_scope_id semantics discussion. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 20 07:54:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KErXk04552 for ipng-dist; Mon, 20 Aug 2001 07:53:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KErUL04545 for ; Mon, 20 Aug 2001 07:53:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15203 for ; Mon, 20 Aug 2001 07:53:30 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11294 for ; Mon, 20 Aug 2001 08:53:45 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id KAA28136; Mon, 20 Aug 2001 10:54:24 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id KAA21587; Mon, 20 Aug 2001 10:54:23 -0400 Message-ID: <3B812498.939168C4@txc.com> Date: Mon, 20 Aug 2001 10:54:16 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: Jun-ichiro itojun Hagino , Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0350F1CD95AA33A18CEF9C90" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms0350F1CD95AA33A18CEF9C90 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pekka Savola wrote: > > On Fri, 17 Aug 2001, Alex Conta wrote: > > The Diffserv QoS engines in the access routers do a policing > > (classification&metering&dropping) that trims the high level QoS traffic > > -- hacked by a user, or not -- to the level specified in SLAs, TCAs. So, > > a user, at the most, uses up all that was contracted with the ISP, and > > paid for, anyway. This is in fact THE BEAUTY of THE MODEL. > > You seem to assume that you would always spoof to get _better_ service [....] No, I do not assume at all that one would "always" spoof. > Also, the idea that an operator might do QoS classification etc. on the >traffic _for free_ (e.g. add "low delay" to dport 22, 23; low cost to nntp >etc.) just to benefit the user(s) is unfamiliar to you? [...] > I do not assume at all that the provider chooses to do a QoS classification/policing to only help the customer, or that it does it for free. The classification/policing and the rest of QoS, helps also the provider, it helps maximizing the usage of the provider network, while optimizing the service that the customers perceive/receive. The customer is paying usually one bill, that includes everything, the costs for higher QoS, lower QoS, or non-QoS at all(best effort). Regards, Alex --------------ms0350F1CD95AA33A18CEF9C90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjAxNDU0MTdaMCMGCSqGSIb3DQEJBDEWBBQXD4Wy2SXdikuGrwu7 gbohlJq0PjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gE358vrBI7lrg1cTeNwstODYH99OHr4jkfww+OXFqgHzVZTgtqcs/dEyl0CfwusEt3kXIW3P nUgpUobfEpGlWArG7ExZgYxhuWIe3BGyeHZZxraeFWnXaAi4X1o2UGtQSVSVq3SljTglNY+X 5OOhYD0gY2VFu4vAXpPn53NfWF2E --------------ms0350F1CD95AA33A18CEF9C90-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 10:25:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KHOWm05394 for ipng-dist; Mon, 20 Aug 2001 10:24:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KHOTL05387 for ; Mon, 20 Aug 2001 10:24:29 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15394 for ; Mon, 20 Aug 2001 10:24:26 -0700 (PDT) Received: from picollo.csl.sony.co.jp (h023.p106.iij4u.or.jp [210.130.106.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12101 for ; Mon, 20 Aug 2001 10:24:22 -0700 (PDT) Received: from localhost (kjc@localhost [127.0.0.1]) by picollo.csl.sony.co.jp (8.11.3/8.11.3) with ESMTP id f7KHOC420725; Tue, 21 Aug 2001 02:24:13 +0900 (JST) Date: Tue, 21 Aug 2001 02:24:11 +0900 (JST) Message-Id: <20010821.022411.115916392.kjc@csl.sony.co.jp> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label From: Kenjiro Cho In-Reply-To: <20010820120518.38ECC7BA@starfruit.itojun.org> References: <200108201132.f7KBVxD19600@hygro.adsl.duke.edu> <20010820120518.38ECC7BA@starfruit.itojun.org> X-Mailer: Mew version 2.0 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 Jun-ichiro itojun Hagino wrote: > So, kjc wanted to at least identify each of the flow, at least for > statistics purposes, as well as traffic classification/policying > if possible. Even if end nodes use ESP, he would liked to identify a > flow from other flows. So, he wanted us to attach unique pseudorandom > flow label per flow. This leads us to (b), and that's one of the > reason why draft-itojun-ipv6-flowlabel-api-02.txt is based on (b). minor correction: My point was that leaving the flowlabel field unused doesn't do any good for QoS/IPv6 deployment. So, I proposed to itojun to set flowlabel by default because I think the availability of flowlabel values will promote practical use of this field. The original definition may not be perfect but at least there are useful applications. It isn't only for intserv; e.g., it can be used for best-effort traffic to provide better fairness by WFQ-style schedulers. I think what the QoS community should have learned from the last several years is that sometimes getting practical and moving forward at the right time is more important than arguing :) -Kenjiro -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 10:38:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KHaxt05478 for ipng-dist; Mon, 20 Aug 2001 10:36:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KHatL05471 for ; Mon, 20 Aug 2001 10:36:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18338 for ; Mon, 20 Aug 2001 10:36:58 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21909 for ; Mon, 20 Aug 2001 11:36:50 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id NAA31898; Mon, 20 Aug 2001 13:37:48 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id NAA28998; Mon, 20 Aug 2001 13:37:48 -0400 Message-ID: <3B814A8B.AA0C0886@txc.com> Date: Mon, 20 Aug 2001 13:36:11 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Brian E Carpenter , Bob Hinden , ipng Subject: Re: Higher level question about flow label References: <200108201132.f7KBVxD19600@hygro.adsl.duke.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF2544DBC6E405F0810DF6D6C" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF2544DBC6E405F0810DF6D6C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Narten wrote: > > > [...] If we do nothing, > > we have effectively chosen the intserv-only usage.[...] > > > Is this really the case? > > RFC 2460 actually says: > > > 6. Flow Labels > > > > The 20-bit Flow Label field [...] > > > > Appendix A describes the current intended semantics and usage of the > > Flow Label field. > > The only place that I know of where the Flow Label bits appear to be > used is in RFC 2205 (Resource ReSerVation Protocol (RSVP) -- Version 1 > Functional Specification). [...] Are you saying that the "intended semantics and usage of the Flow Label field" documented in the Appendix A of RFC 2460 are optional? Alex --------------msF2544DBC6E405F0810DF6D6C Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjAxNzM3NDZaMCMGCSqGSIb3DQEJBDEWBBQ2Jj5TIpWUHbT+A0WV a8xR3nDaMzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gDd/azIiWEqN8eX+FxR+E/8ghNi2w3tzAoqkVnpErVC+V9TYY9NK04ggL+fV0E+SihezSU4a VJrCfp4u/Gq81GGqfAMVcGcIAUSTgbH2XKHEVklQZnsqXSVA8X8l5LGPg2U/gKDnB0QamUuS oMyCqAL2EiRA8dzTa0Li0UODrmK/ --------------msF2544DBC6E405F0810DF6D6C-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 11:11:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KI9vv05755 for ipng-dist; Mon, 20 Aug 2001 11:09:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KI9sL05748 for ; Mon, 20 Aug 2001 11:09:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26106 for ; Mon, 20 Aug 2001 11:09:56 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19742 for ; Mon, 20 Aug 2001 12:09:51 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id OAA32753; Mon, 20 Aug 2001 14:10:50 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA00715; Mon, 20 Aug 2001 14:10:48 -0400 Message-ID: <3B8152A4.49F5F7AE@txc.com> Date: Mon, 20 Aug 2001 14:10:44 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kenjiro Cho CC: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <200108201132.f7KBVxD19600@hygro.adsl.duke.edu> <20010820120518.38ECC7BA@starfruit.itojun.org> <20010821.022411.115916392.kjc@csl.sony.co.jp> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms14E5AD3B12FEFC28E956B2FA" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms14E5AD3B12FEFC28E956B2FA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kenjiro Cho wrote: > > Jun-ichiro itojun Hagino wrote: > > So, kjc wanted to at least identify each of the flow, at least for > > statistics purposes, <...> > > on (b). > > minor correction: > > My point was that leaving the flowlabel field unused doesn't do any > good for QoS/IPv6 deployment. I agree. > So, I proposed to itojun to set flowlabel by default because I think > the availability of flowlabel values will promote practical use of > this field. > If Intserv-only is "good" for QoS/IPv6, the use with both Intserv, and Diffserv, is "more than good", is an enhancement, a plus. > The original definition may not be perfect but at least there are > useful applications. It isn't only for intserv; e.g., it can be used > for best-effort traffic to provide better fairness by WFQ-style > schedulers. Adding the ability to do Diffserv QoS would improve the applicability, the useful applications, while allowing all of the original applications. It is a win-win situation. > -Kenjiro Alex --------------ms14E5AD3B12FEFC28E956B2FA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjAxODEwNDZaMCMGCSqGSIb3DQEJBDEWBBTPbmA8qlDY2bRX8Awy UHnoHpQqYTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gFP9fPdbfFiRud7mhWLm048dri/GhGW9o0zaMfnPI3nBqX5qb82YxGR5T39xKR0xRNLMrc01 h1nT5rVjMse0OV3yZJFvHpqA5w6R69FV2/jKOaeeAGXQSnONtc0a63J78q/RbFHIughwn1l3 YWdw8WZhwYoVbQU4jTDfJhxMf1TT --------------ms14E5AD3B12FEFC28E956B2FA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 11:22:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KILZ405907 for ipng-dist; Mon, 20 Aug 2001 11:21:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KILVL05900 for ; Mon, 20 Aug 2001 11:21:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10452 for ; Mon, 20 Aug 2001 11:21:32 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12384 for ; Mon, 20 Aug 2001 11:21:31 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA18946; Mon, 20 Aug 2001 14:19:33 -0400 Received: from rotala.raleigh.ibm.com (root@[9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA32688; Mon, 20 Aug 2001 14:19:11 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id NAA21705; Mon, 20 Aug 2001 13:53:46 -0400 Message-Id: <200108201753.NAA21705@rotala.raleigh.ibm.com> To: Alex Conta cc: Brian E Carpenter , Bob Hinden , ipng Subject: Re: Higher level question about flow label In-Reply-To: Message from Alex Conta of "Mon, 20 Aug 2001 13:36:11 EDT." <3B814A8B.AA0C0886@txc.com> Date: Mon, 20 Aug 2001 13:53:46 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Are you saying that the "intended semantics and usage of the Flow > Label field" documented in the Appendix A of RFC 2460 are optional? Optional at best, so yes. Note that when 2460 was advanced to Draft Standard, there was IESG pushback on including the Appendix A definition of the Flow Label as part of the standard (that is why it got moved to an appendix, with Section 6 using the wording "still experimental and subject to change"). The definition is largely unproven (in the sense that folks agree this is the best way to provide the function) and unused at this point, hardly what one would expect as part of a Draft Standard. That is not to say that it is the wrong way to do the Flow Label. But there is no consensus that it is the right way either. In my view, deciding on the right useage of the bits requires first understanding the problem that needs to be solved. 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 Aug 20 13:17:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KKECu06486 for ipng-dist; Mon, 20 Aug 2001 13:14:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KKE7L06474 for ; Mon, 20 Aug 2001 13:14:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02150 for ; Mon, 20 Aug 2001 13:14:03 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25875 for ; Mon, 20 Aug 2001 14:13:54 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA03065; Mon, 20 Aug 2001 16:14:52 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA06056; Mon, 20 Aug 2001 16:14:52 -0400 Message-ID: <3B816FB7.77F49A83@txc.com> Date: Mon, 20 Aug 2001 16:14:47 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Brian E Carpenter , Bob Hinden , ipng Subject: Re: Higher level question about flow label References: <200108201132.f7KBVxD19600@hygro.adsl.duke.edu> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms82FCF7C64260DA4BCF1E8390" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms82FCF7C64260DA4BCF1E8390 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Narten wrote: > > [...] When someone can make a compelling argument for why > the bits need to be defined in a certain way (i.e., there is a real > application for which using the bits provides significant benefits, > and those benefits do not appear achievable through other means) that > is the time to define the bits. What I do sense with many of the > recent discussions surrounding the Flow Label is that there are many > folks (i.e., folks putting IPv6 into hardware) that want to know what > they should implement w.r.t. the Flow Label. While it would be nice to > be able tell them what to do, we shouldn't standardize something just > for the sake of having a definition. > > Thomas 10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2 instructions of a hypothetical 1Ghz processor which can execute one instruction per cycle. That's a hell of a requirement. As consumers, we all enjoy the very cost-effective availability of 100Mb/sec line speed packet processing in almost every Notebook, or PC. IP and QoS Engines implemented in silicon, on a chip or a few chips, by IBM, INTEL, and many, many others, is one of the reasons of the low costs, along with the ability to optimizing the hardware in so many more and different ways than the software (for instance parallel header, or parallel header field processing). 1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just around the corner, with 40Gb/sec following not long after. With such drastic "timing" requirements, implementing engines in silicon, and inventing *clever* mechanisms to handle the sequential processing of headers alone, will not be sufficient to implement very cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a disadvantage relative to IPv4. We need all the help we can get from the protocol, that is headers, and their fields, for forwarding and QoS processing, and by that I mean both Intserv, and Diffserv. Regards, Alex > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms82FCF7C64260DA4BCF1E8390 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjAyMDE0NDlaMCMGCSqGSIb3DQEJBDEWBBQ99MtWbYKZsqm7zY/y BZ6SZuLEpDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gJZe9X7ZDqIB8OKS/v94NHZHZgZk9oODowbXmB6nNoPbEF/cAEpErKPXuS4oK/qF/5PpFALq x8wHMeFUKE6FB77ONynoqBSQOVdoXVbfLHOxp4e91CMRzVOeHYElv0uXfOaLLbgcnAQW9evO JwYuZ3K/usvAZKxWb3bQE0JXrhHI --------------ms82FCF7C64260DA4BCF1E8390-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 13:21:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KKKkJ06608 for ipng-dist; Mon, 20 Aug 2001 13:20:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KKKgL06601 for ; Mon, 20 Aug 2001 13:20:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03551 for ; Mon, 20 Aug 2001 13:20:44 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01166 for ; Mon, 20 Aug 2001 14:20:39 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA03206; Mon, 20 Aug 2001 16:21:38 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA06233; Mon, 20 Aug 2001 16:21:38 -0400 Message-ID: <3B81714E.DCDABD5D@txc.com> Date: Mon, 20 Aug 2001 16:21:34 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Brian E Carpenter , Bob Hinden , ipng Subject: Re: Higher level question about flow label References: <200108201753.NAA21705@rotala.raleigh.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms858FE1D37E668F938943D235" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms858FE1D37E668F938943D235 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the clarification, Alex Thomas Narten wrote: > > > Are you saying that the "intended semantics and usage of the Flow > > Label field" documented in the Appendix A of RFC 2460 are optional? > > Optional at best, so yes. > > Note that when 2460 was advanced to Draft Standard, there was IESG > pushback on including the Appendix A definition of the Flow Label as > part of the standard (that is why it got moved to an appendix, with > Section 6 using the wording "still experimental and subject to > change"). The definition is largely unproven (in the sense that folks > agree this is the best way to provide the function) and unused at this > point, hardly what one would expect as part of a Draft Standard. > > That is not to say that it is the wrong way to do the Flow Label. But > there is no consensus that it is the right way either. > > In my view, deciding on the right useage of the bits requires first > understanding the problem that needs to be solved. > > Thomas --------------ms858FE1D37E668F938943D235 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjAyMDIxMzZaMCMGCSqGSIb3DQEJBDEWBBQMEk9G5yR+sfDcH/X2 ChzoPLwbWzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gIXFm0RjEaxpB/x9QAvyA/MQLj5EgDjxihS91w9gri/FNGVn0fq0KmDf9tbf1UR0bcCDA18x 2HcKV91zGfXjQPX6EAFhNRfpRYuzAM+18vcoF3cHbeQpVbaHTmL63pt3gYRZr1bO9dcBKOwI vmP2Lc7r3bZMwS3/d464zgLAFEuu --------------ms858FE1D37E668F938943D235-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 14:48:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KLkmb07680 for ipng-dist; Mon, 20 Aug 2001 14:46:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KLkeL07673 for ; Mon, 20 Aug 2001 14:46:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12251 for ; Mon, 20 Aug 2001 14:46:41 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05983 for ; Mon, 20 Aug 2001 15:46:57 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id RAA04690 for ; Mon, 20 Aug 2001 17:47:35 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id RAA10025; Mon, 20 Aug 2001 17:47:35 -0400 Message-ID: <3B818571.14EE8E7D@txc.com> Date: Mon, 20 Aug 2001 17:47:29 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng Subject: Re: Higher level question about flow label References: <200108201132.f7KBVxD19600@hygro.adsl.duke.edu> <3B816FB7.77F49A83@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3134AAA85DBA9B7450DBFE3E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3134AAA85DBA9B7450DBFE3E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alex Conta wrote: > > Thomas Narten wrote: > > > > [...] When someone can make a compelling argument for why > > the bits need to be defined in a certain way (i.e., there is a real > > application for which using the bits provides significant benefits, > > and those benefits do not appear achievable through other means) that > > is the time to define the bits. What I do sense with many of the > > recent discussions surrounding the Flow Label is that there are many > > folks (i.e., folks putting IPv6 into hardware) that want to know what > > they should implement w.r.t. the Flow Label. While it would be nice to > > be able tell them what to do, we shouldn't standardize something just > > for the sake of having a definition. > > > > Thomas > > 10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, > or 3.2 > instructions of a hypothetical > 1Ghz processor which can execute one instruction per cycle. ""or 3.2 instructions"" meant to be: ""or 3.2 instructions per 4 byte longword"" Sorry. > That's a > hell of a requirement. > > As consumers, we all enjoy the very cost-effective availability of > 100Mb/sec line speed packet processing in almost every Notebook, or PC. > > IP and QoS Engines implemented in silicon, on a chip or a few chips, by > IBM, INTEL, and many, many others, is one of the reasons of the low > costs, along with the ability to optimizing the hardware > in so many more and different ways than the software (for instance > parallel header, or parallel header field processing). > > 1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just around the > corner, with 40Gb/sec following not long after. > > With such drastic "timing" requirements, implementing engines in > silicon, and inventing *clever* mechanisms to handle the sequential > processing of headers alone, will not be sufficient to implement very > cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a > disadvantage relative to IPv4. > > We need all the help we can get from the protocol, that is headers, and > their fields, for forwarding and QoS processing, and by that I mean both > Intserv, and Diffserv. > > Regards, > Alex > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- --------------ms3134AAA85DBA9B7450DBFE3E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjAyMTQ3MzJaMCMGCSqGSIb3DQEJBDEWBBRQlwXcW+heExiWKugr OqdZtgxHUjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gGvf2lhIVE8K1q+gsKEU9ko40b4pQK4xkkqCJ3U3HmrlrpECFqNC4xWpfK1Xk9zkrSab3LhR qT1MEtUX7O3HM1wXw/BypmUMXiYDqOCm6SNJd9YaOPK1odj+vRM9z8xalCfqKjDLfU8FLl7/ 4APxFCIF5ljK3pOK4reYyskSp34X --------------ms3134AAA85DBA9B7450DBFE3E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 15:24:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KMMvC07800 for ipng-dist; Mon, 20 Aug 2001 15:22:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KMMrL07793 for ; Mon, 20 Aug 2001 15:22:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14202 for ; Mon, 20 Aug 2001 15:22:56 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA25759 for ; Mon, 20 Aug 2001 16:23:14 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id SAA05284; Mon, 20 Aug 2001 18:23:49 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA11352; Mon, 20 Aug 2001 18:23:48 -0400 Message-ID: <3B818DEF.C55A979D@txc.com> Date: Mon, 20 Aug 2001 18:23:43 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound CC: Tim Chown , ipng Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms777BA03635BC10E7F4FC4DBB" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms777BA03635BC10E7F4FC4DBB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim, Please reexamine. As a hint, note that MPLS, which is using *mutable* labels, is using RSVP-TE (extension of RSVP for Traffic Engineering) as one of the label distribution mechanisms. Alex Jim Bound wrote: > > Yes I would as a note. I want what we orginally called for and to make > sure nothing breaks RSVPv6 which uses the flowlabel too. > > /jim > > On Fri, 17 Aug 2001, Tim Chown wrote: > > > On Fri, 17 Aug 2001, Francis Dupont wrote: > > > > > In your previous mail you wrote: > > > > > > I think the WG needs to decide once and for all whether the flow label is > > > a) a CATNIP or MPLS-like routing handle > > > or b) a QOS hint for intserv only > > > or c) a QOS hint for intserv and diffserv > > > or d) a waste of bits > > > > > > => I vote for b) > > > > So would you vote to mandate that the field is non-mutable in transit too? > > > > tim > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms777BA03635BC10E7F4FC4DBB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjAyMjIzNDVaMCMGCSqGSIb3DQEJBDEWBBS7K5hhKRnmgXVLQiey p06COR0msjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gKavP3pIJ4AAUbHfiQZt4AMqmIAsF4CJQE3RrQF7Z7iHGq8aOwhrab52X2WAlFSi3nyCBM1T +0hV+G2xNyifjIQWeV/95PAb/XIW8XFvA/IvoILvf3U7EGdlKgbrNtRrWPM/dqygWHPo4VQu 4syBG7CJWQZf/5VC1GtKlh5EuBRu --------------ms777BA03635BC10E7F4FC4DBB-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 15:34:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) id f7KMXAd07854 for ipng-dist; Mon, 20 Aug 2001 15:33:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KMX6L07847 for ; Mon, 20 Aug 2001 15:33:06 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23487 for ; Mon, 20 Aug 2001 15:33:08 -0700 (PDT) Received: from web14904.mail.yahoo.com (web14904.mail.yahoo.com [216.136.225.56]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA04229 for ; Mon, 20 Aug 2001 15:33:07 -0700 (PDT) Message-ID: <20010820223307.94794.qmail@web14904.mail.yahoo.com> Received: from [207.17.136.129] by web14904.mail.yahoo.com; Mon, 20 Aug 2001 15:33:07 PDT Date: Mon, 20 Aug 2001 15:33:07 -0700 (PDT) From: Daniel Chuang Subject: ipv6IfStateChange traps in RFC2465 To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, ipv6IfStateChange is defined as follows: ipv6IfStateChange NOTIFICATION-TYPE OBJECTS { ipv6IfDescr, ipv6IfOperStatus } STATUS current DESCRIPTION "An ipv6IfStateChange notification signifies that there has been a change in the state of an ipv6 interface. This notification should be generated when the interface's operational status transitions to or from the up(1) state." ::= { ipv6NotificationPrefix 1 } This can be translated into SNMPv1 trap from the above definition. BUT what kind of information will be put into the "agent-addr" in the v1 Trap PDU in the ipv6-only node? A couple of options: 1. SNMPv1 traps are not allowed for ipv6-only node. 2. modify RFC1157. 3. any other creative methods !! Thanks, Daniel __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 20 16:15:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7KNDvi08003 for ipng-dist; Mon, 20 Aug 2001 16:13:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7KNDrm07996 for ; Mon, 20 Aug 2001 16:13:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09009 for ; Mon, 20 Aug 2001 16:13:54 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA20523 for ; Mon, 20 Aug 2001 17:14:10 -0600 (MDT) Received: from 157.54.9.100 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Aug 2001 16:13:00 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 16:12:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 16:12:54 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 20 Aug 2001 16:12:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: ipv6IfStateChange traps in RFC2465 Date: Mon, 20 Aug 2001 16:12:41 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B5814F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipv6IfStateChange traps in RFC2465 thread-index: AcEpyKzJ0Mq4+Uq5Soi72b7BVyjhYgABEx0A From: "Dave Thaler" To: "Daniel Chuang" , Cc: X-OriginalArrivalTime: 20 Aug 2001 23:12:42.0201 (UTC) FILETIME=[9CFDFC90:01C129CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7KNDsm07997 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Daniel Chuang [mailto:ipv6_dchuang@yahoo.com] > > [...] what kind of information > will be put into the "agent-addr" in the v1 Trap > PDU in the ipv6-only node? > > A couple of options: > > 1. SNMPv1 traps are not allowed for ipv6-only node. > > 2. modify RFC1157. > > 3. any other creative methods !! It looks to me like the answer is (1). Cc'ing SNMPv3 list, where other experts reside. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 17:07:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L06Lx08146 for ipng-dist; Mon, 20 Aug 2001 17:06:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L06Hm08139 for ; Mon, 20 Aug 2001 17:06:17 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10326 for ; Mon, 20 Aug 2001 17:06:19 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13960 for ; Mon, 20 Aug 2001 17:06:18 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id UAA06449; Mon, 20 Aug 2001 20:07:14 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id UAA14067; Mon, 20 Aug 2001 20:07:13 -0400 Message-ID: <3B81A62A.669B5911@txc.com> Date: Mon, 20 Aug 2001 20:07:06 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound CC: Bob Hinden , Brian E Carpenter , ipng Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms15302C37AE71E255E3C79601" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms15302C37AE71E255E3C79601 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim, Jim Bound wrote: > > I think we should do b via an experimental draft. Go write some code and > see if it works in the test beds (e.g. 6bone, 6init, Eurosix, DoD). Then > report back. This will give us some experience. > > I think doing anything to promote routing based on transport+port is a bad > technical idea and strategy for IPv6. I am afraid, there is a misunderstanding. Nobody advocated transport+port to promote routing or as a strategy. > IPv6 should put an end to that type > of route lookup and forwarding now. > > Also regarding the argument of not knowing the length of headers, Itojun > is correct we cannot put that in the flow label it will create bugs and is > not prudent. I am afraid again of a misunderstanding. As I do not expect everyone to understand or care about bit shifting, I should mention just for the sake of the record, that it was shown, that the details can be crafted to eliminate the risk mentioned by Itojun, regarding length. > We have long known that the forwarding path will have to > live with extensibile headers. It is a done deal and we should move > forward. We have also known from day one, that the flow label is an aid to forwarding, and to QoS, and that we still have to work on it. > Let the best engineers win who are are the smartest to create > algorithms that can adapt to IPv6 extensibility. No question, IPv6 extensibility which is the ability to define and stack options in the 'hop by hop' headers, or 'destination' headers, is a plus. But we should minimize the price paid for it, that is the price for variable IPv6 headers of variable size. Cause variable size, during packet forwarding, is as bad, if not worse than variable size addresses, and we know where we (Steve, Bob, Jim, I, and many others) were on that many years ago. Minimizing the price paid is even more necessary, when we examine the gain on extensibility, by counting the IPv6 options which were standardized. and compare, them to the IPv4 standard options. Alex > > /jim > > On Fri, 17 Aug 2001, Bob Hinden wrote: > > > Brian, > > > > > > I don't think that we have enough experience to pick between a), b), or c) > > > > now, and think that something might come up in the future where 28 bits in > > > > the IPv6 header might be very useful. This might not have anything to do > > > > with QOS. > > > > > >I think you mean 20 bits. The traffic class octet is fully standardised by > > >diffserv and ECN. > > > > Yes, my error. I was not suggesting we change the traffic class field. > > > > >The problem with this is that the text we have today effectively selects > > >option b), since it endorses the pseudo-random value. If we do nothing, > > >we have effectively chosen the intserv-only usage. That's why I started > > >this thread. > > > > I agree. It was good to ask the question. > > > > The point I was trying to make is that while we have now many QOS > > standards, we don't have very much deployment experience. As such it is > > hard to tell if it is worthwhile to use these 20 bits to optimize QOS > > performance. > > > > Bob > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms15302C37AE71E255E3C79601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjEwMDA3MDhaMCMGCSqGSIb3DQEJBDEWBBS6bxsHSCrdOiaicH5W Cbu2Ggy/1jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gHPT/qxw4M/pOPlVjbqYsgFGmrFcZ/KNH4mgLx/gnwYKM036uCNauO+2GeuvHRpgoVyy4WiL RPnM59ieChZcXxJu0UAl6Dw+qNUkohgmyPdYgPXyMPvQvQeKHShGlwNnK4MJpiJfhBmGaXOS vYglb/YNiENiIU61/tvFuUH7QgSc --------------ms15302C37AE71E255E3C79601-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 17:54:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L0rcC08372 for ipng-dist; Mon, 20 Aug 2001 17:53:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L0r0m08350; Mon, 20 Aug 2001 17:53:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11658; Mon, 20 Aug 2001 17:52:57 -0700 (PDT) Received: from blackrock.internal.simegen.com (co3019724-a.thoms1.vic.optushome.com.au [203.164.36.115]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA00871; Mon, 20 Aug 2001 18:53:08 -0600 (MDT) Received: from anaconda.internal.simegen.com ([10.0.2.1] helo=zeor.simegen.com) by blackrock.internal.simegen.com with esmtp (Exim 3.32 #1 (Debian)) id 15YzjQ-0006AP-00; Tue, 21 Aug 2001 10:49:24 +1000 Message-ID: <3B81B014.8020701@zeor.simegen.com> Date: Tue, 21 Aug 2001 10:49:24 +1000 From: Dancer Vesperman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010816 X-Accept-Language: en-us MIME-Version: 1.0 To: Bill Manning CC: bert hubert , Robert Elz , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <200108151741.f7FHfXE06102@zed.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Manning wrote: > % > % On Wed, Aug 15, 2001 at 09:56:37PM +0700, Robert Elz wrote: > % > Date: Wed, 15 Aug 2001 06:00:34 -0700 (PDT) > % > From: Bill Manning > % > Message-ID: <200108151300.f7FD0YH05643@zed.isi.edu> > % > > % > | Then the Internet is doomed. Either evolution or revolution. > % > > % > In some places, revolution is all that is possible. The evolutionary > % > step is just too big to every take. > % > % I'm butting in here, but it may be interesting to know that quite a number > % of the top-100 resolving nameserver installations out there are still > % running Bind4! I'm doing some research on the big resolvers out there, > % especially the (non-)randomness of the id field. > % > % Some of these people have gone through great lengths to remain at Bind4, > % even though they run late breaking operating system releases. > % > % Regards, > % > % bert hubert > > I'd like to compare numbers. > > I can't talk about the top-100, but I have a fair experience 'in the trenches'. Every geek I know who runs her own nameserver is running bind8 or bind9. Only four companies out of circa 70 that I've done work for since bind8 came out have bind8 (the rest have bind4, and I personally installed three out of those four bind8 setups). Honestly, most DNS admins are barely willing to learn what they currently have, in a minimally effective fashion. Between lame delegations, CNAME abuse, and MX nightmares, it's often amazing that the public internet runs at all. IPv6 is being actively resisted by network admins and managers because it's not an incremental change. It's full of Big Scary Newness(tm). They'd rather extend v4 than step up to v6. It's all very "not on my watch", at the moment. I'd guess that maybe 30% of networks won't even start to take up ipv4 until perhaps more than 50% of the most popular bits of the net are no-longer reachable through it...And you know they will be, for some time. SMTP and WWW traffic will be gatewayed for almost ever, on the evolutionary path. As far as the actual A6 vs AAAA debate goes, it all boils down to this: If we cock this up, then in a hundred years time, the odds are that sysadmins are going to be swearing at us for the mistakes we made. OTOH, if we just sit and talk it back and forth for a while, the status quo will become a fait accompli, and our names still become mud in the future. Hamlet or Othello? Or someone else? D -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 20 20:00:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L2xbG09114 for ipng-dist; Mon, 20 Aug 2001 19:59:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L2wxm09092; Mon, 20 Aug 2001 19:58:59 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27651; Mon, 20 Aug 2001 19:58:57 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13971; Mon, 20 Aug 2001 19:58:57 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f7L2wsm16687; Mon, 20 Aug 2001 19:58:54 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f7L2wpl25521; Mon, 20 Aug 2001 19:58:51 -0700 Message-Id: <200108210258.f7L2wpl25521@zed.isi.edu> Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary To: dancer@zeor.simegen.com Date: Mon, 20 Aug 2001 19:58:51 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), ahu@ds9a.nl (bert hubert), kre@munnari.OZ.AU (Robert Elz), ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-Reply-To: <3B81B014.8020701@zeor.simegen.com> from "Dancer Vesperman" at Aug 21, 2001 10:49:24 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % As far as the actual A6 vs AAAA debate goes, it all boils down to this: % If we cock this up, then in a hundred years time, the odds are that % sysadmins are going to be swearing at us for the mistakes we made. OTOH, % if we just sit and talk it back and forth for a while, the status quo % will become a fait accompli, and our names still become mud in the % future. Hamlet or Othello? Or someone else? % % % D Titania or Puck. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 20 21:00:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L400a09318 for ipng-dist; Mon, 20 Aug 2001 21:00:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L3xum09311 for ; Mon, 20 Aug 2001 20:59:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA05627 for ; Mon, 20 Aug 2001 20:59:58 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA02807 for ; Mon, 20 Aug 2001 22:00:17 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA31872; Mon, 20 Aug 2001 23:59:21 -0400 Date: Mon, 20 Aug 2001 23:59:21 -0400 (EDT) From: Jim Bound To: Alex Conta Cc: Tim Chown , ipng Subject: Re: Higher level question about flow label In-Reply-To: <3B818DEF.C55A979D@txc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, Well aware of RSVP-TE. I believe MPLS to be different than intserv. I also believe MPLS Labels could become moot in theory with the correct use of the flowlabel and become what the label does for MPLS via the flow label. Then I believe tunneling like RSVP-TE could be eliminated to distribute the labels. I don't believe all of this will scale but we will see soon once the economy upturns and broadband is recharged in the market. I would like to see tunnels, NAT, etc all go away. The flowlabel if used correctly can contribute to that possibility. We are at a stand still here. Its too bad. I guess I will have to produce a draft supporting Brian's "b" and state the case and the performance gain on the overall network. I think RSVPv6 is a moot point there is not enough implementations to worry about. But it was a good exercise in using the flow label instead of the IPv4 transport+port fields and digging past the header to define the flowspec and queue classification. Also it can be set for path msgs using the v6 base API which gets past directly to the header. RSVPv6 and the RSVP API (RAPI) peforms better with IPv6 because of the flowlabel and by orders of magnitude from what we saw testing video and audio. I suggest we do this real time at the next Sun Connectathon and show RSVPv6 and take measurements. RSVPv6 is useful to private enterprise Intranets as IPv6 inteserv tool today. But not on across the Internet unless we mesh with diffserv. As far as IPv6 being left behind IPv4 for routing metrics you predict. As far as I am concerned who cares if its not E2E which is being totally lost with IPv4 lack of address space. So I don't accept that argument. IPv4 has no way of differentiating the header or the addresses except by digging past the header. We have the opportunity to do that with IPv6 and fix that error in IPv6 today and not have to bother with all the AND/OR Gates being built in fast path today. Its absurd to continue this with IPv6 IMO. regards, /jim On Mon, 20 Aug 2001, Alex Conta wrote: > Jim, > > Please reexamine. > > As a hint, note that MPLS, which is using *mutable* labels, is using > RSVP-TE (extension of RSVP > for Traffic Engineering) as one of the label distribution mechanisms. > > Alex > > > Jim Bound wrote: > > > > Yes I would as a note. I want what we orginally called for and to make > > sure nothing breaks RSVPv6 which uses the flowlabel too. > > > > /jim > > > > On Fri, 17 Aug 2001, Tim Chown wrote: > > > > > On Fri, 17 Aug 2001, Francis Dupont wrote: > > > > > > > In your previous mail you wrote: > > > > > > > > I think the WG needs to decide once and for all whether the flow label is > > > > a) a CATNIP or MPLS-like routing handle > > > > or b) a QOS hint for intserv only > > > > or c) a QOS hint for intserv and diffserv > > > > or d) a waste of bits > > > > > > > > => I vote for b) > > > > > > So would you vote to mandate that the field is non-mutable in transit too? > > > > > > tim > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Aug 20 21:20:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L4Iw509360 for ipng-dist; Mon, 20 Aug 2001 21:18:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L4Ism09353 for ; Mon, 20 Aug 2001 21:18:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18354 for ; Mon, 20 Aug 2001 21:18:56 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA12228 for ; Mon, 20 Aug 2001 22:19:14 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA29984; Tue, 21 Aug 2001 00:18:18 -0400 Date: Tue, 21 Aug 2001 00:18:18 -0400 (EDT) From: Jim Bound Reply-To: Jim Bound To: Alex Conta Cc: Bob Hinden , Brian E Carpenter , ipng Subject: Re: Higher level question about flow label In-Reply-To: <3B81A62A.669B5911@txc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, > Jim, > > Jim Bound wrote: > > > > I think we should do b via an experimental draft. Go write some code and > > see if it works in the test beds (e.g. 6bone, 6init, Eurosix, DoD). Then > > report back. This will give us some experience. > > > > I think doing anything to promote routing based on transport+port is a bad > > technical idea and strategy for IPv6. > > I am afraid, there is a misunderstanding. Nobody advocated > transport+port to promote routing > or as a strategy. So advocating port numbers in the flowlabel is not the view of the current thinking? Thats good then. If I missed that I will have to go back and check. > > > > IPv6 should put an end to that type > > of route lookup and forwarding now. > > > > Also regarding the argument of not knowing the length of headers, Itojun > > is correct we cannot put that in the flow label it will create bugs and is > > not prudent. > > I am afraid again of a misunderstanding. > > As I do not expect everyone to understand or care about bit shifting, I > should mention > just for the sake of the record, that it was shown, that the details can > be crafted to eliminate > the risk mentioned by Itojun, regarding length. I saw that mail. That is not the only bug. The other bug will be assuming the extensions and when to update the length. Adding this to the IPv6 processing would need to be reviewed very carefully at this point. Because it can be bit shifted does not mean it will work. > > > We have long known that the forwarding path will have to > > live with extensibile headers. It is a done deal and we should move > > forward. > > We have also known from day one, that the flow label is an aid to > forwarding, and to QoS, and that > we still have to work on it. > Of course. > > Let the best engineers win who are are the smartest to create > > algorithms that can adapt to IPv6 extensibility. > > No question, IPv6 extensibility which is the ability to define and stack > options in the 'hop by hop' headers, or 'destination' headers, is a > plus. Also completely new prototcols. > But we should minimize the price paid for it, that is the price for > variable IPv6 headers of variable size. Cause variable size, during > packet forwarding, is as bad, if not worse than variable size addresses, > and we know where we (Steve, Bob, Jim, I, and many others) were on that > many years ago. I agree and that was for the address too. But if one follows the extension chain all works correctly no matter what size or how many extensions exist. > Minimizing the price paid is even more necessary, when we examine the > gain on extensibility, by counting the IPv6 options which were > standardized. and compare, them to the IPv4 standard options. IPv4 options don't work? I am missing the point? But I think we should maybe define the reqs we are trying to achieve? If we could all agree on that we may be able to move forward. But that gets back to Brian's mail on choosing a-e. I think waiting is not a good idea though. We should figure this out now. regards, /jim > > Alex > > > > > /jim > > > > On Fri, 17 Aug 2001, Bob Hinden wrote: > > > > > Brian, > > > > > > > > I don't think that we have enough experience to pick between a), b), or c) > > > > > now, and think that something might come up in the future where 28 bits in > > > > > the IPv6 header might be very useful. This might not have anything to do > > > > > with QOS. > > > > > > > >I think you mean 20 bits. The traffic class octet is fully standardised by > > > >diffserv and ECN. > > > > > > Yes, my error. I was not suggesting we change the traffic class field. > > > > > > >The problem with this is that the text we have today effectively selects > > > >option b), since it endorses the pseudo-random value. If we do nothing, > > > >we have effectively chosen the intserv-only usage. That's why I started > > > >this thread. > > > > > > I agree. It was good to ask the question. > > > > > > The point I was trying to make is that while we have now many QOS > > > standards, we don't have very much deployment experience. As such it is > > > hard to tell if it is worthwhile to use these 20 bits to optimize QOS > > > performance. > > > > > > Bob > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Aug 20 22:28:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L5R5D09455 for ipng-dist; Mon, 20 Aug 2001 22:27:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L5R1m09448 for ; Mon, 20 Aug 2001 22:27:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10200 for ; Mon, 20 Aug 2001 22:26:55 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02562 for ; Mon, 20 Aug 2001 22:26:55 -0700 (PDT) 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 WAA26121; Mon, 20 Aug 2001 22:26:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7L5QVQ02434; Mon, 20 Aug 2001 22:26:31 -0700 X-mProtect: Mon, 20 Aug 2001 22:26:31 -0700 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdA14EEg; Mon, 20 Aug 2001 22:26:29 PDT Message-ID: <3B81F0A1.639DB063@iprg.nokia.com> Date: Mon, 20 Aug 2001 22:24:49 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu CC: john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 References: <0C1353ABB1DEB74DB067ADFF749C4EEF094175@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, Has there been any further determination about where the AAAv6 work should proceed? It seems to me that it does fit within the AAA working group now. If an URP working group is created in the future, and they want to have the work item, a transfer could be discussed at that time. In the meantime, we could start to have more discussion about particulars. Regards, Charlie P. john.loughney@nokia.com wrote: > Hi Bernard, > > RE: AAAv6 draft > > > Has this draft been presented within the IPNG WG? Since IPv6 > > architecture occurs within IPNG WG, the proposed IPv6/AAA > > authentication architecture would need to be presented and > > gain consensus within the IPNG WG before a AAA WG work item > > could be considered. > > Charlie Perkins presented the AAAv6 draft he has been writing > to the IPNG WG. There seemed to be general consensus that > this was good work (in general) and be persued. It seemed to > the group that IPNG WG was not the best place for this, but > the AAA could be one possibility. Erik Nordmark also suggested > that URP could be another home. > > Of course, if I have mis-interpreted the consensus, I' sure > someone (Steve?) could correct me. > > I'm in favor of this going forward. I think that no official > decision has been made on URP (whether or not it is to be a > WG) - perhaps the Area Directors & Work Group chairs could > discuss where the best place for this work is. > > best regards, > John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 02:38:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7L9c6r10593 for ipng-dist; Tue, 21 Aug 2001 02:38:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L9c3m10586 for ; Tue, 21 Aug 2001 02:38:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04190 for ; Tue, 21 Aug 2001 02:38:06 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA21605 for ; Tue, 21 Aug 2001 03:38:24 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 11:38:07 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECA9DB@mail.kebne.se> From: Thomas Eklund To: "'Alex Conta'" , Thomas Narten Cc: Brian E Carpenter , Bob Hinden , ipng Subject: RE: Higher level question about flow label Date: Tue, 21 Aug 2001 11:37:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree alex. It gets worse for people that are doing ASIC which is not programmable, then they need to spin a new version their ASIC when the protocols changes. For people that are doing programmable ASIC (network processors etc) this is not a problem. But common for both approaches is that the header format is really challenge for the ASIC engineers -- thomas >-----Original Message----- >From: Alex Conta [mailto:aconta@txc.com] >Sent: den 20 augusti 2001 22:15 >To: Thomas Narten >Cc: Brian E Carpenter; Bob Hinden; ipng >Subject: Re: Higher level question about flow label > > > > >Thomas Narten wrote: >> >> [...] When someone can make a compelling argument for why >> the bits need to be defined in a certain way (i.e., there is a real >> application for which using the bits provides significant benefits, >> and those benefits do not appear achievable through other means) that >> is the time to define the bits. What I do sense with many of the >> recent discussions surrounding the Flow Label is that there are many >> folks (i.e., folks putting IPv6 into hardware) that want to know what >> they should implement w.r.t. the Flow Label. While it would >be nice to >> be able tell them what to do, we shouldn't standardize something just >> for the sake of having a definition. >> >> Thomas > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2 >instructions of a hypothetical >1Ghz processor which can execute one instruction per cycle. That's a >hell of a requirement. > >As consumers, we all enjoy the very cost-effective availability of >100Mb/sec line speed packet processing in almost every >Notebook, or PC. > >IP and QoS Engines implemented in silicon, on a chip or a few chips, by >IBM, INTEL, and many, many others, is one of the reasons of the low >costs, along with the ability to optimizing the hardware >in so many more and different ways than the software (for instance >parallel header, or parallel header field processing). > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just >around the >corner, with 40Gb/sec following not long after. > >With such drastic "timing" requirements, implementing engines in >silicon, and inventing *clever* mechanisms to handle the sequential >processing of headers alone, will not be sufficient to implement very >cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a >disadvantage relative to IPv4. > >We need all the help we can get from the protocol, that is headers, and >their fields, for forwarding and QoS processing, and by that I >mean both >Intserv, and Diffserv. > >Regards, >Alex > > > > > > > > > > > > > > >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home 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 Aug 21 05:07:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LC6be11509 for ipng-dist; Tue, 21 Aug 2001 05:06:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LC6Xm11499 for ; Tue, 21 Aug 2001 05:06:34 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15627 for ; Tue, 21 Aug 2001 05:06:35 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28274 for ; Tue, 21 Aug 2001 05:06:34 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 08:06:33 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054780@ftmail> From: George Tsirtsis To: "'Bernard Aboba'" , Charlie Perkins Cc: aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 08:06:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It seams to me that the subject of "AAA for IPv6" has at least two components that may potentially belong to different WGs. One is the communication between the end node and the access router and the other is the communication between the AAA client in the Access Router and the rest of the AAA infrastructure. The latter is all about IPv6 support in the AAA protocol (Radius, diameter, cops)...and thus belongs to the AAA/COPS WGs... The former is about challenging the end node and transporting the identification and authentication parameters over the access link. This is not part of the AAA protocol (e.g.: typically Radius does not run over the access link). What is needed is a "carrier" mechanism for the parameters that need to be fed to the AAA protocol. PPPv6 for example provides such a carrier. MIPv4 also provides such a carrier to IPv4 nodes that use Mobile IP but, MIPv6, due to the lack of FAs, does not provide such an obvious carrier...hence Charlie's work. Now, there are a couple of things that can be done IMO. 1. Use Neighbor Discovery (ND) as a carrier for the AAA parameters. e.g.: extend Neighbor Advertisements and Router Advertisements to carry challenge/response messages....this to me is the job of IPv6 WG and could be the start of a much bigger fish called authenticated ND or 2. Create a new carrier, independent from ND and with the specific task of carrying the appropriate challenge/response parameters...this to me belongs to URP WG. ...my two drachma Regards George -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Tuesday, August 21, 2001 8:06 AM To: Charlie Perkins Cc: aaa-wg@merit.edu; john.loughney@nokia.com; ipng@sunroof.eng.sun.com; urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 The AAA WG only considers work items resulting from a consensus draft within a subject area WG. Until the IPNG or URP WG progresses a draft on the subject, we cannot consider a work item relating to AAA for IPV6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 05:24:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LCNYu11579 for ipng-dist; Tue, 21 Aug 2001 05:23:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LCNUm11572 for ; Tue, 21 Aug 2001 05:23:30 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16986 for ; Tue, 21 Aug 2001 05:23:31 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06857 for ; Tue, 21 Aug 2001 05:23:30 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 14:23:33 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECA9E0@mail.kebne.se> From: Thomas Eklund To: "'George Tsirtsis'" , "'Bernard Aboba'" , Charlie Perkins Cc: aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 14:23:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear George, What you are suggesting is already done in the draft. It proposes two mechanism to do access control for IPv6 where, one way of doing it is a stateful approach is based on ND and the other is to do it in the stateful approach with DHCPv6. Instead of people bouncing back and forth I belive that the correct WG now is the AAA WG. -- thomas >-----Original Message----- >From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] >Sent: den 21 augusti 2001 14:07 >To: 'Bernard Aboba'; Charlie Perkins >Cc: aaa-wg@merit.edu; john.loughney@nokia.com; >ipng@sunroof.eng.sun.com; >urp@research.telcordia.com >Subject: RE: [AAA-WG]: AAA for IPv6 > > >It seams to me that the subject of "AAA for IPv6" has at least two >components that may potentially belong to different WGs. One is the >communication between the end node and the access router and >the other is >the communication between the AAA client in the Access Router >and the rest >of the AAA infrastructure. > >The latter is all about IPv6 support in the AAA protocol >(Radius, diameter, >cops)...and thus belongs to the AAA/COPS WGs... > >The former is about challenging the end node and transporting the >identification and authentication parameters over the access >link. This is >not part of the AAA protocol (e.g.: typically Radius does not >run over the >access link). What is needed is a "carrier" mechanism for the >parameters >that need to be fed to the AAA protocol. PPPv6 for example >provides such a >carrier. MIPv4 also provides such a carrier to IPv4 nodes that >use Mobile IP >but, MIPv6, due to the lack of FAs, does not provide such an obvious >carrier...hence Charlie's work. Now, there are a couple of >things that can >be done IMO. > >1. Use Neighbor Discovery (ND) as a carrier for the AAA >parameters. e.g.: >extend Neighbor Advertisements and Router Advertisements to carry >challenge/response messages....this to me is the job of IPv6 >WG and could be >the start of a much bigger fish called authenticated ND or > >2. Create a new carrier, independent from ND and with the >specific task of >carrying the appropriate challenge/response parameters...this >to me belongs >to URP WG. > >...my two drachma > >Regards >George >-----Original Message----- >From: Bernard Aboba [mailto:aboba@internaut.com] >Sent: Tuesday, August 21, 2001 8:06 AM >To: Charlie Perkins >Cc: aaa-wg@merit.edu; john.loughney@nokia.com; >ipng@sunroof.eng.sun.com; >urp@research.telcordia.com >Subject: Re: [AAA-WG]: AAA for IPv6 > > >The AAA WG only considers work items resulting from a consensus draft >within a subject area WG. Until the IPNG or URP WG progresses >a draft on >the subject, we cannot consider a work item relating to AAA for IPV6. > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 06:02:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LD26E11781 for ipng-dist; Tue, 21 Aug 2001 06:02:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LD22m11774 for ; Tue, 21 Aug 2001 06:02:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26285 for ; Tue, 21 Aug 2001 06:02:04 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA04582 for ; Tue, 21 Aug 2001 07:01:59 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA19588; Tue, 21 Aug 2001 08:57:34 -0400 Date: Tue, 21 Aug 2001 08:57:34 -0400 (EDT) From: Jim Bound To: Thomas Eklund Cc: "'Alex Conta'" , Thomas Narten , Brian E Carpenter , Bob Hinden , ipng Subject: RE: Higher level question about flow label In-Reply-To: <31A473DBB655D21180850008C71E251A04ECA9DB@mail.kebne.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thomas, that is why if we can treat the flowlabel as part of tuple with src address and identify a connection which identifies the forwarding path the challenge is reduced. there is nothing needed but the header for the look up and forward. I believe this can be made to work. the traffic class will provide diff serv metric and the flow identifies the E2E connection with the src addr. The src addr MUST be a global address. Site-Local can be done too but don't want to get into that right now. One can ask if the Ipv6 address is global why have the flow for per connection as above. This is a good question and needs discussion. First the flow assists with the lookup in a binary tree, queue type, or archaic hash. Its the hint to the next leaf, bucket, or queue entry. duplicat highorder bits would cause a branch. This could speed up the search before even getting to the global address. The src + flow could also be used as label for MPLS and its in the IPv6 header. The business reason could also be that end users would create SLAs for their flow labels in addition the bits set for the traffic class. This is how QOS Int Serv could be realized. And I guess conjunct with diff serv but that would need to be specified too. This also benefits client and server boxes too (gateways too). We can now potentially keep one protocol control block for user connections. tcp, sctp, and dcp per connection data structures would not have to be kept above the internet per connection datastructures (e.g. bsd inpcb would be enough). This is a performance win for clients and servers for IPv6 not just routers or switches or gateways. If we put a length in the flow yes it can be made to work but not without being verified by the router as the packet is parsed or "policed" then we have just put new processing far worse than the IP checksum which we removed from the IPv6 router. And opens up opportunity for bugs at that code point we don't have today. I also don't support the field being mutable as it transits the network path to the end destination. The reason is that we should make IPv6 E2E perform in the network as fas as possible. If you look at all the work to do VPN, L2TP, NAT, Virtual Routing, et al that is emerging pervasive for IPv4 the root reasons are lack of IPv4 address space, the desire to do fast layer 2 switching, and security inspection (e.g. firewalls). The later two above are the only valid visions. We need to eliminate in our thinking the mind set developed because of lack of IPv4 address space. I could argue that what is happening to IPv4 is pure professional irresponsibility on our part as Internet engineers. The Internet should remain E2E. This is not a politcal comment or even social comment. Its a comment stating my assumptions about how the Internet should operate. I think we need to discuss our assumptions for the requirements with the solutions we define. ADSL box providers actually market that NAT helps you because you don't have to worry about address space. This is absurd and professionally irresponsible in the market. We should stop this with IPv6. The way to do that is give routers the means to forward packets E2E by only looking at the header of IPv6. That is what Brian's "b" solution does. Plus it benefits all nodes besides routes for IPv6 as I state above. As far as IPv6 extensions. The payload length gives the router the entire length of the packet. If the flowlabel can be used to identify forwarding the packet in addition to the address and other parts as I state above then there is no challenge for ASIC vendors for strict forwarding of IPv6 packets. If those vendors want to add more value by digging past the header then that is their option to add value but I don't believe it is required for fast forwarding of IPv6 packets. Steve's design works and I believe can be extended with the flowlabell and we can get rid of the mess IPv4 is making of the Internet because of the band-aids being applied. I believe the End System (and that could be a router in some cases or a broker router) should set the flowlabel at the access exit before the edge. But thats another discussion. Another discussion is how do we pick good random numbers for the flowlabel at the access exit end system or even a client. regards, /jim On Tue, 21 Aug 2001, Thomas Eklund wrote: > I agree alex. > > It gets worse for people that are doing ASIC which is not programmable, then > they need to spin a new version their ASIC when the protocols changes. For > people that are doing programmable ASIC (network processors etc) this is not > a problem. > > But common for both approaches is that the header format is really challenge > for the ASIC engineers > > -- thomas > > >-----Original Message----- > >From: Alex Conta [mailto:aconta@txc.com] > >Sent: den 20 augusti 2001 22:15 > >To: Thomas Narten > >Cc: Brian E Carpenter; Bob Hinden; ipng > >Subject: Re: Higher level question about flow label > > > > > > > > > >Thomas Narten wrote: > >> > >> [...] When someone can make a compelling argument for why > >> the bits need to be defined in a certain way (i.e., there is a real > >> application for which using the bits provides significant benefits, > >> and those benefits do not appear achievable through other means) that > >> is the time to define the bits. What I do sense with many of the > >> recent discussions surrounding the Flow Label is that there are many > >> folks (i.e., folks putting IPv6 into hardware) that want to know what > >> they should implement w.r.t. the Flow Label. While it would > >be nice to > >> be able tell them what to do, we shouldn't standardize something just > >> for the sake of having a definition. > >> > >> Thomas > > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2 > >instructions of a hypothetical > >1Ghz processor which can execute one instruction per cycle. That's a > >hell of a requirement. > > > >As consumers, we all enjoy the very cost-effective availability of > >100Mb/sec line speed packet processing in almost every > >Notebook, or PC. > > > >IP and QoS Engines implemented in silicon, on a chip or a few chips, by > >IBM, INTEL, and many, many others, is one of the reasons of the low > >costs, along with the ability to optimizing the hardware > >in so many more and different ways than the software (for instance > >parallel header, or parallel header field processing). > > > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just > >around the > >corner, with 40Gb/sec following not long after. > > > >With such drastic "timing" requirements, implementing engines in > >silicon, and inventing *clever* mechanisms to handle the sequential > >processing of headers alone, will not be sufficient to implement very > >cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a > >disadvantage relative to IPv4. > > > >We need all the help we can get from the protocol, that is headers, and > >their fields, for forwarding and QoS processing, and by that I > >mean both > >Intserv, and Diffserv. > > > >Regards, > >Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> -------------------------------------------------------------------- > >> IETF IPng Working Group Mailing List > >> IPng Home 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 Tue Aug 21 06:21:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LDKlZ11958 for ipng-dist; Tue, 21 Aug 2001 06:20:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LDKhm11951 for ; Tue, 21 Aug 2001 06:20:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28389 for ; Tue, 21 Aug 2001 06:20:46 -0700 (PDT) Received: from hygro.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 HAA06881 for ; Tue, 21 Aug 2001 07:21:00 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f7LDI3c01321; Tue, 21 Aug 2001 09:18:07 -0400 Message-Id: <200108211318.f7LDI3c01321@hygro.adsl.duke.edu> To: Bernard Aboba cc: Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 In-Reply-To: Message from Bernard Aboba of "Tue, 21 Aug 2001 00:05:40 PDT." Date: Tue, 21 Aug 2001 09:18:03 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bernard, Can you clarify a bit on what sort of consensus draft you would want out of a subject area WG. Would that be (for example) a problem statement and a corresponding set of requirements, as opposed to a particular solution? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 06:46:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LDheI12015 for ipng-dist; Tue, 21 Aug 2001 06:43:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LDhOm12008 for ; Tue, 21 Aug 2001 06:43:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24530 for ; Tue, 21 Aug 2001 06:42:58 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01889 for ; Tue, 21 Aug 2001 07:42:53 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LDhJ311699 for ; Tue, 21 Aug 2001 16:43:20 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 21 Aug 2001 16:42:48 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVYLKA>; Tue, 21 Aug 2001 16:42:48 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FDB@esebe004.NOE.Nokia.com> To: seamus@bit-net.com, thomas.eklund@xelerated.com Cc: aconta@txc.com, narten@raleigh.ibm.com, brian@hursley.ibm.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Tue, 21 Aug 2001 16:42:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Nice rant :-) Could you elaborate on the pseudo-random nature of the flow label. It seems to me that if it did not need to be pseudo-random, people could go on "signaling off-line" about the flow label values (in SLAs, this seems to be what Alex & Brian want). I see no harm in allowing such practice, but it would be best if there is only one format for the flow label, as it would be faster to decode. Jarno > -----Original Message----- > From: ext Jim Bound [mailto:seamus@bit-net.com] > Sent: 21. elokuuta 2001 15:58 > To: Thomas Eklund > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob Hinden; ipng > Subject: RE: Higher level question about flow label > > > thomas, > > that is why if we can treat the flowlabel as part of tuple with src > address and identify a connection which identifies the forwarding path > the challenge is reduced. there is nothing needed but the > header for the > look up and forward. I believe this can be made to work. > > the traffic class will provide diff serv metric and the flow > identifies > the E2E connection with the src addr. > > The src addr MUST be a global address. > > Site-Local can be done too but don't want to get into that right now. > > One can ask if the Ipv6 address is global why have the flow for per > connection as above. This is a good question and needs discussion. > > First the flow assists with the lookup in a binary tree, > queue type, or > archaic hash. Its the hint to the next leaf, bucket, or queue entry. > duplicat highorder bits would cause a branch. This could speed up the > search before even getting to the global address. > > The src + flow could also be used as label for MPLS and its > in the IPv6 > header. > > The business reason could also be that end users would create SLAs for > their flow labels in addition the bits set for the traffic > class. This is > how QOS Int Serv could be realized. And I guess conjunct > with diff serv > but that would need to be specified too. > > This also benefits client and server boxes too (gateways > too). We can now > potentially keep one protocol control block for user connections. tcp, > sctp, and dcp per connection data structures would not have to be kept > above the internet per connection datastructures (e.g. bsd > inpcb would be > enough). This is a performance win for clients and servers > for IPv6 not > just routers or switches or gateways. > > If we put a length in the flow yes it can be made to work but > not without > being verified by the router as the packet is parsed or > "policed" then we > have just put new processing far worse than the IP checksum which we > removed from the IPv6 router. And opens up opportunity for > bugs at that > code point we don't have today. > > I also don't support the field being mutable as it transits > the network > path to the end destination. > > The reason is that we should make IPv6 E2E perform in the > network as fas > as possible. If you look at all the work to do VPN, L2TP, > NAT, Virtual > Routing, et al that is emerging pervasive for IPv4 the root > reasons are > lack of IPv4 address space, the desire to do fast layer 2 > switching, and > security inspection (e.g. firewalls). > > The later two above are the only valid visions. We need to > eliminate in > our thinking the mind set developed because of lack of IPv4 > address space. > I could argue that what is happening to IPv4 is pure professional > irresponsibility on our part as Internet engineers. The > Internet should > remain E2E. This is not a politcal comment or even social > comment. Its a > comment stating my assumptions about how the Internet should operate. > > I think we need to discuss our assumptions for the > requirements with the > solutions we define. > > ADSL box providers actually market that NAT helps you because > you don't > have to worry about address space. This is absurd and professionally > irresponsible in the market. We should stop this with IPv6. > > The way to do that is give routers the means to forward packets E2E by > only looking at the header of IPv6. That is what Brian's "b" solution > does. Plus it benefits all nodes besides routes for IPv6 as I state > above. > > As far as IPv6 extensions. The payload length gives the > router the entire > length of the packet. If the flowlabel can be used to > identify forwarding > the packet in addition to the address and other parts as I state above > then there is no challenge for ASIC vendors for strict > forwarding of IPv6 > packets. > > If those vendors want to add more value by digging past the > header then > that is their option to add value but I don't believe it is > required for > fast forwarding of IPv6 packets. > > Steve's design works and I believe can be extended with the > flowlabell and > we can get rid of the mess IPv4 is making of the Internet > because of the > band-aids being applied. > > I believe the End System (and that could be a router in some > cases or a > broker router) should set the flowlabel at the access exit before the > edge. But thats another discussion. > > Another discussion is how do we pick good random numbers for > the flowlabel > at the access exit end system or even a client. > > regards, > /jim > > > On Tue, 21 Aug 2001, Thomas Eklund wrote: > > > I agree alex. > > > > It gets worse for people that are doing ASIC which is not > programmable, then > > they need to spin a new version their ASIC when the > protocols changes. For > > people that are doing programmable ASIC (network processors > etc) this is not > > a problem. > > > > But common for both approaches is that the header format is > really challenge > > for the ASIC engineers > > > > -- thomas > > > > >-----Original Message----- > > >From: Alex Conta [mailto:aconta@txc.com] > > >Sent: den 20 augusti 2001 22:15 > > >To: Thomas Narten > > >Cc: Brian E Carpenter; Bob Hinden; ipng > > >Subject: Re: Higher level question about flow label > > > > > > > > > > > > > > >Thomas Narten wrote: > > >> > > >> [...] When someone can make a compelling argument for why > > >> the bits need to be defined in a certain way (i.e., > there is a real > > >> application for which using the bits provides > significant benefits, > > >> and those benefits do not appear achievable through > other means) that > > >> is the time to define the bits. What I do sense with many of the > > >> recent discussions surrounding the Flow Label is that > there are many > > >> folks (i.e., folks putting IPv6 into hardware) that want > to know what > > >> they should implement w.r.t. the Flow Label. While it would > > >be nice to > > >> be able tell them what to do, we shouldn't standardize > something just > > >> for the sake of having a definition. > > >> > > >> Thomas > > > > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2 > > >instructions of a hypothetical > > >1Ghz processor which can execute one instruction per > cycle. That's a > > >hell of a requirement. > > > > > >As consumers, we all enjoy the very cost-effective availability of > > >100Mb/sec line speed packet processing in almost every > > >Notebook, or PC. > > > > > >IP and QoS Engines implemented in silicon, on a chip or a > few chips, by > > >IBM, INTEL, and many, many others, is one of the reasons of the low > > >costs, along with the ability to optimizing the hardware > > >in so many more and different ways than the software (for instance > > >parallel header, or parallel header field processing). > > > > > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just > > >around the > > >corner, with 40Gb/sec following not long after. > > > > > >With such drastic "timing" requirements, implementing engines in > > >silicon, and inventing *clever* mechanisms to handle the sequential > > >processing of headers alone, will not be sufficient to > implement very > > >cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a > > >disadvantage relative to IPv4. > > > > > >We need all the help we can get from the protocol, that is > headers, and > > >their fields, for forwarding and QoS processing, and by that I > > >mean both > > >Intserv, and Diffserv. > > > > > >Regards, > > >Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > -------------------------------------------------------------------- > > >> IETF IPng Working Group Mailing List > > >> IPng Home Page: > http://playground.sun.com/ipng > > >> FTP archive: > ftp://playground.sun.com/pub/ipng > > >> Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > >> > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 06:51:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LDoT212125 for ipng-dist; Tue, 21 Aug 2001 06:50:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LDoQm12118 for ; Tue, 21 Aug 2001 06:50:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11270 for ; Tue, 21 Aug 2001 06:50:28 -0700 (PDT) Received: from iwavehost2.iwave.net (PPP-200-7-169.bng.vsnl.net.in [203.200.7.169]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20324 for ; Tue, 21 Aug 2001 06:50:23 -0700 (PDT) Received: from iwave008 ([192.168.2.109]) by iwavehost2.iwave.net (8.11.0/8.8.7) with SMTP id f7LDp3002378 for ; Tue, 21 Aug 2001 19:21:03 +0530 Message-ID: <00ae01c12a48$eeceb2a0$6d02a8c0@iwave008> Reply-To: "Anurag" From: "Anurag" To: Subject: query Date: Tue, 21 Aug 2001 19:24:51 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009F_01C12A76.F2FC40D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_009F_01C12A76.F2FC40D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi alex I have one query . "The Linux support new socket type ,SOCKET_PACKET ,That provides access = to data link ,similar to DLPI. I want to know how application communicates directly with the data link = layer ,Is there any special functions and data structures? thanks. RESPECT OTHER'S ,U'LL GET RESPECT Anurag Uxa IWave Embedded Systems Bangalore India PH:6786243/5 Extn:206 ------=_NextPart_000_009F_01C12A76.F2FC40D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi alex
I have one query .
"The Linux support new socket type=20 ,SOCKET_PACKET ,That provides access to data link ,similar to = DLPI.
I want to know how application = communicates=20 directly with the data link layer ,Is there any special functions and = data=20 structures?
thanks.
 
RESPECT OTHER'S ,U'LL GET = RESPECT
 
Anurag Uxa
IWave Embedded=20 Systems
Bangalore India
PH:6786243/5=20 Extn:206
------=_NextPart_000_009F_01C12A76.F2FC40D0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 06:55:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LDs9K12160 for ipng-dist; Tue, 21 Aug 2001 06:54:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LDs5m12152 for ; Tue, 21 Aug 2001 06:54:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11580 for ; Tue, 21 Aug 2001 06:53:08 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08823 for ; Tue, 21 Aug 2001 07:53:02 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LDrT317226 for ; Tue, 21 Aug 2001 16:53:29 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 21 Aug 2001 16:53:03 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVYL4G>; Tue, 21 Aug 2001 16:53:03 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D494@esebe004.NOE.Nokia.com> To: thomas.eklund@xelerated.com, G.Tsirtsis@flarion.com, aboba@internaut.com, charliep@IPRG.nokia.com Cc: aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com, Basavaraj.Patil@nokia.com, subir@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 16:52:52 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, The WG chairs may correct me if I misunderstood, but at the last AAA WG meeting it was evident that even work clearly on the current charter, like Mobile IPv6 Application (extension), do not get taken up by the WG. At least not before the current work is finished, and maybe the WG is re-chartered etc. So it seems hopeless to even think about work on areas outside, or bordering the current charter. I think the URP WG should be chartered ASAP and AAAv6 taken there as a possible solution. Where can I find the current proposal for the URP charter? With regards, Jarno > -----Original Message----- > From: ext Thomas Eklund [mailto:thomas.eklund@xelerated.com] > Sent: 21. elokuuta 2001 15:23 > To: 'George Tsirtsis'; 'Bernard Aboba'; Charlie Perkins > Cc: aaa-wg@merit.edu; john.loughney@nokia.com; > ipng@sunroof.eng.sun.com; > urp@research.telcordia.com > Subject: RE: [AAA-WG]: AAA for IPv6 > > > Dear George, > What you are suggesting is already done in the draft. > > It proposes two mechanism to do access control for IPv6 > where, one way of > doing it is a stateful approach is based on ND and the other > is to do it in > the stateful approach with DHCPv6. > > Instead of people bouncing back and forth I belive that the > correct WG now > is the AAA WG. > > -- thomas > > >-----Original Message----- > >From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] > >Sent: den 21 augusti 2001 14:07 > >To: 'Bernard Aboba'; Charlie Perkins > >Cc: aaa-wg@merit.edu; john.loughney@nokia.com; > >ipng@sunroof.eng.sun.com; > >urp@research.telcordia.com > >Subject: RE: [AAA-WG]: AAA for IPv6 > > > > > >It seams to me that the subject of "AAA for IPv6" has at least two > >components that may potentially belong to different WGs. One is the > >communication between the end node and the access router and > >the other is > >the communication between the AAA client in the Access Router > >and the rest > >of the AAA infrastructure. > > > >The latter is all about IPv6 support in the AAA protocol > >(Radius, diameter, > >cops)...and thus belongs to the AAA/COPS WGs... > > > >The former is about challenging the end node and transporting the > >identification and authentication parameters over the access > >link. This is > >not part of the AAA protocol (e.g.: typically Radius does not > >run over the > >access link). What is needed is a "carrier" mechanism for the > >parameters > >that need to be fed to the AAA protocol. PPPv6 for example > >provides such a > >carrier. MIPv4 also provides such a carrier to IPv4 nodes that > >use Mobile IP > >but, MIPv6, due to the lack of FAs, does not provide such an obvious > >carrier...hence Charlie's work. Now, there are a couple of > >things that can > >be done IMO. > > > >1. Use Neighbor Discovery (ND) as a carrier for the AAA > >parameters. e.g.: > >extend Neighbor Advertisements and Router Advertisements to carry > >challenge/response messages....this to me is the job of IPv6 > >WG and could be > >the start of a much bigger fish called authenticated ND or > > > >2. Create a new carrier, independent from ND and with the > >specific task of > >carrying the appropriate challenge/response parameters...this > >to me belongs > >to URP WG. > > > >...my two drachma > > > >Regards > >George > >-----Original Message----- > >From: Bernard Aboba [mailto:aboba@internaut.com] > >Sent: Tuesday, August 21, 2001 8:06 AM > >To: Charlie Perkins > >Cc: aaa-wg@merit.edu; john.loughney@nokia.com; > >ipng@sunroof.eng.sun.com; > >urp@research.telcordia.com > >Subject: Re: [AAA-WG]: AAA for IPv6 > > > > > >The AAA WG only considers work items resulting from a consensus draft > >within a subject area WG. Until the IPNG or URP WG progresses > >a draft on > >the subject, we cannot consider a work item relating to AAA > for IPV6. > > > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home Page: http://playground.sun.com/ipng > >FTP archive: ftp://playground.sun.com/pub/ipng > >Direct all administrative requests to majordomo@sunroof.eng.sun.com > >-------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Aug 21 07:05:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LE4Ye12413 for ipng-dist; Tue, 21 Aug 2001 07:04:34 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LE4Um12406 for ; Tue, 21 Aug 2001 07:04:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13043 for ; Tue, 21 Aug 2001 07:04:32 -0700 (PDT) Received: from uniwest1.redstonecom.com ([65.194.140.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29231 for ; Tue, 21 Aug 2001 08:04:51 -0600 (MDT) Received: by mailwest.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 10:04:25 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02AC4860@mailwest.unispherenetworks.com> From: "Deshpande, Prasad" To: ipng@sunroof.eng.sun.com Subject: Ipv6IfIndex and IPv4 ifIndex Date: Tue, 21 Aug 2001 10:04:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, If IPv6 and IPv4 unicast forwarding are enabled on the same physical interface, would values of Ipv6IfIndex and ifIndex (IPv4) be the same i.e. would the same row show up in both ifTable and ipv6IfTable. Is this implementation dependent? I couldnt find any draft/RFC that talks about this. thanks -prasad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 08:02:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LF1eC12692 for ipng-dist; Tue, 21 Aug 2001 08:01:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LF1Zm12685 for ; Tue, 21 Aug 2001 08:01:35 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10963 for ; Tue, 21 Aug 2001 08:01:27 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12163 for ; Tue, 21 Aug 2001 08:01:25 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA33132; Tue, 21 Aug 2001 10:57:52 -0400 Received: from rotala.raleigh.ibm.com (root@[9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA33850; Tue, 21 Aug 2001 10:57:00 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id KAA24176; Tue, 21 Aug 2001 10:40:54 -0400 Message-Id: <200108211440.KAA24176@rotala.raleigh.ibm.com> To: George Tsirtsis cc: "'Bernard Aboba'" , Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 In-Reply-To: Message from George Tsirtsis of "Tue, 21 Aug 2001 08:06:30 EDT." <8C92E23A3E87FB479988285F9E22BE46054780@ftmail> Date: Tue, 21 Aug 2001 10:40:54 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It seams to me that the subject of "AAA for IPv6" has at least two > components that may potentially belong to different WGs. One is the > communication between the end node and the access router This first component would appear to be exactly what the URP effort is focusing on. That is, URP is focused on the problem of how does an edge device "log in" and authenticate itself to the network. This initial step (becoming authorized to use the network) may be tied in with access control on a router, but that is a separate issue and does not appear to be directly tied to the URP protocol. I.e., URP allows a device to authenticate itself with some local server, that local server may then (behind the scenes) grant permission to other devices on the local network (e.g., routers) to allow packets from the device to be forwarded. But the mechanism for doing that would likely be separate (and possibly already existing) protocols rather than URP itself. > the other is the communication between the AAA client in the Access > Router and the rest of the AAA infrastructure. Note specifically that this interaction does not directly involve the client device that is seeking access to the network. I would expect that this is already being handled in the AAA WG and that IPv6 is already being supported (e.g., via diameter). Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 08:09:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LF9Dk12771 for ipng-dist; Tue, 21 Aug 2001 08:09:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LF9Am12764 for ; Tue, 21 Aug 2001 08:09:10 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14515 for ; Tue, 21 Aug 2001 08:09:11 -0700 (PDT) Received: from bridge.axiowave.com (mail.axiowave.com [209.6.34.2]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17368 for ; Tue, 21 Aug 2001 08:09:06 -0700 (PDT) Message-ID: From: Dimitry Haskin To: "'Deshpande, Prasad'" , ipng@sunroof.eng.sun.com Subject: RE: Ipv6IfIndex and IPv4 ifIndex Date: Tue, 21 Aug 2001 11:09:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Prasad, ipv6IfIndex defines a logical IPv6 interface. There is no requirement for its value being equal to an ifIndex value. Generally, it should be possible to configure multiple logical IPv6 interfaces on a single physical interface. Regards, Dimitry > -----Original Message----- > From: Deshpande, Prasad [mailto:PDeshpande@unispherenetworks.com] > Sent: Tuesday, August 21, 2001 10:04 AM > To: ipng@sunroof.eng.sun.com > Subject: Ipv6IfIndex and IPv4 ifIndex > > > > Hi, > > If IPv6 and IPv4 unicast forwarding are enabled on the same physical > interface, would values of Ipv6IfIndex and ifIndex (IPv4) be the same > i.e. would the same row show up in both ifTable and ipv6IfTable. Is > this implementation dependent? > > I couldnt find any draft/RFC that talks about this. > > thanks > -prasad > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Aug 21 08:47:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LFksd13440 for ipng-dist; Tue, 21 Aug 2001 08:46:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LFknm13433 for ; Tue, 21 Aug 2001 08:46:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18992 for ; Tue, 21 Aug 2001 08:46:50 -0700 (PDT) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05477 for ; Tue, 21 Aug 2001 09:47:08 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LFltI17051 for ; Tue, 21 Aug 2001 10:47:55 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 10:46:47 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 10:46:47 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 10:46:47 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E843F@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: AAA for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEqSWN6nylJ8ZY8EdWxLgAIx6TWeAADy1mA From: "Patil Basavaraj (NET/Dallas)" To: "Rajahalme Jarno (NRC/Helsinki)" , , , , "Perkins Charles (IPRG)" Cc: , "Loughney John (NRC/Helsinki)" , , , X-OriginalArrivalTime: 21 Aug 2001 15:46:47.0595 (UTC) FILETIME=[7C6AD7B0:01C12A58] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LFkom13434 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jarno, > >Thomas, > >The WG chairs may correct me if I misunderstood, but at the last AAA WG >meeting it was evident that even work clearly on the current charter, like >Mobile IPv6 Application (extension), do not get taken up by the WG. At least >not before the current work is finished, and maybe the WG is re-chartered >etc. So it seems hopeless to even think about work on areas outside, or >bordering the current charter. > I agree with your assesment of the conclusions reached at the AAA WG meeting at the last IETF. The AAA WG currently has "Diameter Mobile IPv4 Application (draft-ietf-aaa-diameter-mobileip-07.txt)" as a WG item. At IETF51 we proposed "Diameter Mobile IPv6 Application" (draft-le-aaa-diameter-mobileipv6-00.txt) to be considered as a WG item. The response was that the AAA WG charter would need to be modified before new work items were taken up. This may happen before the next IETF meeting or sooner (at least from what I understood at the meeting in London). But I am not completely clear why the WG has to be recharterd to take on a new application when the same application for IPv4 is already a part of the WG agenda. I can accept the AAA WG not taking on the Diameter for MIPv6 application immediatley, because MIPv6 itself is not complete (yet). >I think the URP WG should be chartered ASAP and AAAv6 taken there as a >possible solution. Taking up solutions while we are still grappling with the URP charter and the specific boundaries of the problem may seem a bit like placing the cart before the horse. >Where can I find the current proposal for the URP >charter? > We are currently working on a new charter and will publish it soon. The charter that we had going into IETF51 can be obtained from the WG/BOFs agendas URL. I will also send a copy of the previous charter to the URP list if it helps. >With regards, > >Jarno > Cheers, -Basavaraj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 09:03:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LG2TU13725 for ipng-dist; Tue, 21 Aug 2001 09:02:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LG2Pm13718 for ; Tue, 21 Aug 2001 09:02:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22170 for ; Tue, 21 Aug 2001 09:02:27 -0700 (PDT) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28635 for ; Tue, 21 Aug 2001 10:02:22 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LG2Ui17233 for ; Tue, 21 Aug 2001 11:02:30 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 21 Aug 2001 11:02:25 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 11:02:25 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 11:02:24 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF441E8442@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: AAA for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEqVmJd+wTEdJZDEdWJUgAIx6TWpQABFvVA From: "Patil Basavaraj (NET/Dallas)" To: "'ext Thomas Narten'" , "George Tsirtsis" Cc: "'Bernard Aboba'" , "Perkins Charles (IPRG)" , , "Loughney John (NRC/Helsinki)" , , X-OriginalArrivalTime: 21 Aug 2001 16:02:25.0063 (UTC) FILETIME=[AB311B70:01C12A5A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LG2Qm13719 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> It seams to me that the subject of "AAA for IPv6" has at least two >> components that may potentially belong to different WGs. One is the >> communication between the end node and the access router > It may be the "access router" or some other entity in the access network. >This first component would appear to be exactly what the URP effort is >focusing on. That is, URP is focused on the problem of how does an >edge device "log in" and authenticate itself to the network. This >initial step (becoming authorized to use the network) may be tied in >with access control on a router, but that is a separate issue and does >not appear to be directly tied to the URP protocol. I.e., URP allows a >device to authenticate itself with some local server, that local >server may then (behind the scenes) grant permission to other devices >on the local network (e.g., routers) to allow packets from the device >to be forwarded. But the mechanism for doing that would likely be >separate (and possibly already existing) protocols rather than URP >itself. > Precisely. Thank you Thomas for "URP in a nutshell". >Thomas > -Basavaraj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:17:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIFf915907 for ipng-dist; Tue, 21 Aug 2001 11:15:41 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIFbm15900 for ; Tue, 21 Aug 2001 11:15:37 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIDfW29083 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:13:41 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FNmID15509; Wed, 15 Aug 2001 16:48:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28112; Wed, 15 Aug 2001 16:48:19 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16160; Wed, 15 Aug 2001 17:48:14 -0600 (MDT) Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 7AFAC3190D; Wed, 15 Aug 2001 16:48:15 -0700 (PDT) Date: Thu, 16 Aug 2001 01:47:01 +0200 (CEST) From: Roy Arends To: bert hubert Cc: Robert Elz , Bill Manning , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010815172026.K28995@fork.powerdns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 15 Aug 2001, bert hubert wrote: > I'm butting in here, but it may be interesting to know that quite a number > of the top-100 resolving nameserver installations out there are still > running Bind4! I'm interested in the algorithm to determine that list of top-100 resolving nameserver installations. > I'm doing some research on the big resolvers out there, > especially the (non-)randomness of the id field. That is indeed interesting. I am working on a thingy to identify specific dns implementations by determining the response behaviour. (Non)randomness of the ID field might help to identify. Roy Arends Nominum ------------- 0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:17:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIGeH15947 for ipng-dist; Tue, 21 Aug 2001 11:16:40 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIGbm15937 for ; Tue, 21 Aug 2001 11:16:37 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIEcY29113 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:14:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L3w0m09299 for ; Mon, 20 Aug 2001 20:58:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00182 for ; Mon, 20 Aug 2001 20:58:02 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09102 for ; Mon, 20 Aug 2001 21:57:56 -0600 (MDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 21 Aug 2001 09:37:44 +0530 Received: from sivarka (sivarka.future.futsoft.com [10.20.6.73]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f7L3vfe17069 for ; Tue, 21 Aug 2001 09:27:41 +0530 Reply-To: From: "Sivaramakrishnan A" To: Subject: Preferred and Valid Lifetimes Date: Tue, 21 Aug 2001 09:22:10 +0530 Message-Id: <000601c129f4$a8891640$4906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a doubt regarding Router Advertisement specified in RFC 2461 (Neighbor Discovery for IPv6). Our implementation is purely a Router. The doubt is regarding the following: AdvValidLifetime The value to be placed in the Valid Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. Implementations MUST allow AdvValidLifetime to be specified in two ways: - a time that decrements in real time, that is, one that will result in a Lifetime of zero at the specified time in the future, or - a fixed time that stays the same in consecutive advertisements. Default: 2592000 seconds (30 days), fixed (i.e., stays the same in consecutive advertisements). AdvPreferredLifetime The value to be placed in the Preferred Lifetime in the Prefix Information option, in seconds. The designated value of all 1's (0xffffffff) represents infinity. See [ADDRCONF] for details on how this value is used. Implementations MUST allow AdvPreferredLifetime to be specified in two ways: - a time that decrements in real time, that is, one that will result in a Lifetime of zero at a specified time in the future, or - a fixed time that stays the same in consecutive advertisements. Default: 604800 seconds (7 days), fixed (i.e., stays the same in consecutive advertisements). When the ValidLifeTime and PreferredLifeTime are specified in two ways given, there exists a conflict on when to set the lifetime as fixed /decrementing. What is the condition under which the LifeTime is set to be fixed and under which situation is it to be set decrementing? Is there any way to configure them by SNMP Manager. If yes, what is the standard MIB to be used? (I couldn't find any relevant object in standard MIB specified under RFC 2465!) Thanks, Sivarama Krishnan. A -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:18:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIHb315993 for ipng-dist; Tue, 21 Aug 2001 11:17:37 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIHYm15984 for ; Tue, 21 Aug 2001 11:17:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIFaZ29143 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:15:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L7DGm09847 for ; Tue, 21 Aug 2001 00:13:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA04127 for ; Tue, 21 Aug 2001 00:13:18 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA09150 for ; Tue, 21 Aug 2001 00:13:18 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id AAA17863; Tue, 21 Aug 2001 00:05:40 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 21 Aug 2001 00:05:40 -0700 (PDT) From: Bernard Aboba To: Charlie Perkins cc: aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 In-Reply-To: <3B81F0A1.639DB063@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The AAA WG only considers work items resulting from a consensus draft within a subject area WG. Until the IPNG or URP WG progresses a draft on the subject, we cannot consider a work item relating to AAA for IPV6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 11:19:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LII7m16013 for ipng-dist; Tue, 21 Aug 2001 11:18:07 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LII5m16006 for ; Tue, 21 Aug 2001 11:18:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIG6u29173 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:16:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LEbhm12573 for ; Tue, 21 Aug 2001 07:37:44 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07402 for ; Tue, 21 Aug 2001 07:37:43 -0700 (PDT) Received: from seymour39.SNMP.COM (seymour39.snmp.com [192.147.142.39]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16552 for ; Tue, 21 Aug 2001 07:37:42 -0700 (PDT) Received: from sol8.snmp.com (sol8.snmp.com [192.147.142.173]) by seymour39.SNMP.COM (8.9.3/m.000221) with ESMTP id KAA08925; Tue, 21 Aug 2001 10:37:10 -0400 (EDT) Received: from sol8.snmp.com (localhost [127.0.0.1]) by sol8.snmp.com (8.11.2/8.11.2/snmpclient.mc-011018) with ESMTP id f7LEbAe11459; Tue, 21 Aug 2001 10:37:10 -0400 (EDT) Message-Id: <200108211437.f7LEbAe11459@sol8.snmp.com> To: "Dave Thaler" cc: "Daniel Chuang" , ipng@sunroof.eng.sun.com, snmpv3@lists.tislabs.com Subject: Re: ipv6IfStateChange traps in RFC2465 In-reply-to: Your message of Mon, 20 Aug 2001 16:12:41 -0700. <2E33960095B58E40A4D3345AB9F65EC1B5814F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Tue, 21 Aug 2001 10:37:10 -0400 From: Steve Moulton Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Monday, August 20 2001, "Dave Thaler" wrote: > > > > From: Daniel Chuang [mailto:ipv6_dchuang@yahoo.com] > > > > [...] what kind of information > > will be put into the "agent-addr" in the v1 Trap > > PDU in the ipv6-only node? > > > > A couple of options: > > > > 1. SNMPv1 traps are not allowed for ipv6-only node. > > > > 2. modify RFC1157. > > > > 3. any other creative methods !! > > It looks to me like the answer is (1). > > Cc'ing SNMPv3 list, where other experts reside. Currently, as best as I can tell, this can't be done. Please pardon me for being didactic - I'm figuring this out for the first time myself. Talking to: If you are using the coexistence framework (rfc2576), the notification destination is specified in the snmpTargetAddrTable. The address is specified using the TDomain and TAddress textual conventions. rfc1906 defines the OIDs for TDomain, but they can also be defined elsewhere, though as far as I can tell, no domain has been defined in an RFC for IPv6 addresses. There is a proposal to add new transport domain OIDs for IPv6 in draft-ops-taddress-mib-00.txt. I'm pretty sure this is also in draft-ops-taddress-mib-01.txt, but both have expired, and I don't have the text for it. So, there is currently no way to specify an IPv6 target address in a standard fashion, though either the IETF or vendors will have to deal with this as IPv6 support demand increases. Juergen, Mike, am I up to date here? Talking about: As for the trap contents itself, the agent address parameter is a NetworkAddress, a choice that has only one defined type, IpAddress, an implicit octet string of length 4. So it appears that either the NetworkAddress type must change, or the Trap-PDU (an obsolete pdu) must change, to convey IPv6 addresses in an SNMPv1 packet. In both cases, interoperability would be lost. Dave, thanks for tossing this over the wall. - Steve --- Steve Moulton SNMP Research, Inc voice: +1 865 573 1434 Sr Software Engineer 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 moulton@snmp.com Knoxville, TN 37920-9716 USA http://www.snmp.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 Aug 21 11:19:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIIXD16026 for ipng-dist; Tue, 21 Aug 2001 11:18:33 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIITm16019 for ; Tue, 21 Aug 2001 11:18:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIGVc29203 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:16:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LGRdm14346 for ; Tue, 21 Aug 2001 09:27:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27529 for ; Tue, 21 Aug 2001 09:27:41 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22728 for ; Tue, 21 Aug 2001 10:27:36 -0600 (MDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA18647; Tue, 21 Aug 2001 09:20:06 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 21 Aug 2001 09:20:06 -0700 (PDT) From: Bernard Aboba To: "Patil Basavaraj (NET/Dallas)" cc: "Rajahalme Jarno (NRC/Helsinki)" , thomas.eklund@xelerated.com, G.Tsirtsis@flarion.com, "Perkins Charles (IPRG)" , aaa-wg@merit.edu, "Loughney John (NRC/Helsinki)" , ipng@sunroof.eng.sun.com, urp@research.telcordia.com, subir@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <697DAA22C5004B4596E033803A7CEF441E843F@daebe007.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I can accept the AAA WG not taking on the Diameter for MIPv6 > application immediatley, because MIPv6 itself is not complete (yet). Bingo. Once the remaining MIPv6 issues are ironed out, we can consider this. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:20:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIJIC16044 for ipng-dist; Tue, 21 Aug 2001 11:19:18 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIJGm16037 for ; Tue, 21 Aug 2001 11:19:16 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIH2j29233 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:17:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LGZmm14412 for ; Tue, 21 Aug 2001 09:35:48 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10574 for ; Tue, 21 Aug 2001 09:35:46 -0700 (PDT) Received: from femail25.sdc1.sfba.home.com (femail25.sdc1.sfba.home.com [24.254.60.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17938 for ; Tue, 21 Aug 2001 09:35:44 -0700 (PDT) Received: from dperkins-nb2.dsperkins.com ([24.250.160.97]) by femail25.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010821163541.CRWX21066.femail25.sdc1.sfba.home.com@dperkins-nb2.dsperkins.com>; Tue, 21 Aug 2001 09:35:41 -0700 Message-Id: <5.0.2.1.2.20010821085354.0273d8d0@mail.scruznet.com> X-Sender: dperkins@mail.scruznet.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 21 Aug 2001 09:26:57 -0700 To: Steve Moulton , "Dave Thaler" From: "David T. Perkins" Subject: Re: ipv6IfStateChange traps in RFC2465 Cc: "Daniel Chuang" , ipng@sunroof.eng.sun.com, snmpv3@lists.tislabs.com In-Reply-To: <200108211437.f7LEbAe11459@sol8.snmp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk HI, There is NO PROBLEM in sending a v1TRAP (or sending v2TRAP or INFORM with SNMPv2c) using IPv6! NO PROBLEM! Comments below... At 10:37 AM 8/21/2001 -0400, Steve Moulton wrote >On Monday, August 20 2001, "Dave Thaler" wrote: >> > From: Daniel Chuang [mailto:ipv6_dchuang@yahoo.com] >> > >> > [...] what kind of information >> > will be put into the "agent-addr" in the v1 Trap >> > PDU in the ipv6-only node? >> > >> > A couple of options: >> > >> > 1. SNMPv1 traps are not allowed for ipv6-only node. >> > >> > 2. modify RFC1157. >> > >> > 3. any other creative methods !! This question is ALREADY asked and answered. The value is 0.0.0.0, which should be the value ALWAYS. I'll leave it for Steve to find the documents. Hint: what do you put in the field when running over IPX, see RFC 1420. >> It looks to me like the answer is (1). No, the value 0.0.0.0 MUST be used. >> Cc'ing SNMPv3 list, where other experts reside. > >Currently, as best as I can tell, this can't be done. Incorrect. Do more homework. >Please pardon me for being didactic - I'm figuring this out >for the first time myself. > >Talking to: > >If you are using the coexistence framework (rfc2576), the >notification destination is specified in the snmpTargetAddrTable. >The address is specified using the TDomain and TAddress >textual conventions. rfc1906 defines the OIDs for TDomain, >but they can also be defined elsewhere, though as far as >I can tell, no domain has been defined in an RFC for IPv6 addresses. Well, one of the "wonderful properties" of OID values is that they can be defined by anyone, and, thus, there is 1) no way of knowing all assignments, or 2) no way of knowing if there are duplicate assignments. So it is possible for some WG to have defined an OID that identifies the value as an IPv6 transport address, or that one or more vendors have created definitions. >There is a proposal to add new transport domain OIDs for IPv6 in >draft-ops-taddress-mib-00.txt. I'm pretty sure this >is also in draft-ops-taddress-mib-01.txt, but both >have expired, and I don't have the text for it. So, there is currently no way >to specify an IPv6 target address in a standard fashion, though >either the IETF or vendors will have to deal with this as IPv6 support demand >increases. If your data is accurate, then there is no "standard" identification, but there is a standard way to specify IPv6 addresses. >Juergen, Mike, am I up to date here? > >Talking about: > >As for the trap contents itself, the agent address >parameter is a NetworkAddress, a choice that has >only one defined type, IpAddress, an implicit octet >string of length 4. > >So it appears that either the NetworkAddress type must >change, or the Trap-PDU (an obsolete pdu) must change, to >convey IPv6 addresses in an SNMPv1 packet. In both >cases, interoperability would be lost. No, the NetworkAddress type does not need to change, and v1Traps do not need to be changed. The agent address is 0.0.0.0. One determines the "source" of the information contained in the v1 TRAP (and v2Trap and Inform used in SNMPv2c) from the transport address of the sender (the "reporter") and the community string value. On receiving a v1Trap (or v2Trap or Inform with SNMPv2c), the trap receiver must use the pair of the transport address (more likely just the Network address) and the community string together to figure out the source. In v3 speak, the source is an EngineID and context string. Remember the community string field and the transport address is just an associative key pair to get the triple: isProxy(and, if so, proxy info), context, and security info. (Table snmpCommunityTable is just one way, which is not too useful in an SNMPv1 or SNMPv2c environment, of describing the triple.) If the above is not clear, please provide example scenarios and I'll fill in the values. > - Steve Regards, /david t. perkins -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:21:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIJRO16053 for ipng-dist; Tue, 21 Aug 2001 11:19:27 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIJOm16046 for ; Tue, 21 Aug 2001 11:19:24 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIHQS29263 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:17:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7G8sMD16263 for ; Thu, 16 Aug 2001 01:54:23 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25853 for ; Thu, 16 Aug 2001 01:54:24 -0700 (PDT) Received: from fork.powerdns.com (fork.powerdns.com [213.244.168.244]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA00496 for ; Thu, 16 Aug 2001 01:54:23 -0700 (PDT) Received: (qmail 8921 invoked by uid 1011); 16 Aug 2001 08:54:17 -0000 Date: Thu, 16 Aug 2001 10:54:17 +0200 From: bert hubert To: Roy Arends Cc: Robert Elz , Bill Manning , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary Message-ID: <20010816105417.A8843@fork.powerdns.com> Mail-Followup-To: bert hubert , Roy Arends , Robert Elz , Bill Manning , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se References: <20010815172026.K28995@fork.powerdns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Roy.Arends@nominum.com on Thu, Aug 16, 2001 at 01:47:01AM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Aug 16, 2001 at 01:47:01AM +0200, Roy Arends wrote: > On Wed, 15 Aug 2001, bert hubert wrote: > > > I'm butting in here, but it may be interesting to know that quite a number > > of the top-100 resolving nameserver installations out there are still > > running Bind4! > > I'm interested in the algorithm to determine that list of top-100 > resolving nameserver installations. You just tcpdump a lot on nameservers hosting a lot of domains. I personally use dns-us1.powerdns.com and dns-eu1.powerdns.com, as well as ns1.i.am and ns2.i.am - these cover around 4000 domains, including the widely used 'i.am' one. Regards, bert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:26:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIPli16172 for ipng-dist; Tue, 21 Aug 2001 11:25:47 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIPim16165 for ; Tue, 21 Aug 2001 11:25:44 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LINkD29293 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:23:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GDYUD17557; Thu, 16 Aug 2001 06:34:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06456; Thu, 16 Aug 2001 06:34:32 -0700 (PDT) Received: from snout.autonomica.se (ipaddr-no-82.not.yet.in.use.at.autonomica.se [213.89.0.82] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07002; Thu, 16 Aug 2001 07:34:44 -0600 (MDT) Received: by snout.autonomica.se (Postfix, from userid 1211) id 20BD01ED08; Thu, 16 Aug 2001 15:34:22 +0200 (CEST) To: Nathan Jones Cc: Jun-ichiro itojun Hagino , Robert Elz , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary References: <2674.997874182@brandenburg.cs.mu.OZ.AU> <20010815114010.CA9C17BA@starfruit.itojun.org> <20010815225428.A11162@connect.com.au> From: Johan Ihren Date: 16 Aug 2001 15:34:22 +0200 In-Reply-To: Nathan Jones's message of "Wed, 15 Aug 2001 22:54:28 +1000" Message-ID: <2cwv44gmch.fsf@snout.autonomica.se> Lines: 32 User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nathan Jones writes: > itojun wrote: > > you should care about this. there's no guarantee that AAAA synthesis > > happen between end client and master/slave nameservers. AAAA will > > leak from leaf to the core. > > David Terrell's suggestion that AAAA synth be performed by > nameservers which are authoritative for zones with A6 data seems > worth considering here. I think that is a very dangerous idea that we shouldn't use anywhere in an argument to ease a possible transistion to A6 + AAAA synthesis. Many authoritative servers run in non-recursive mode for security reasons, which is sound practice. Doing synthesis in the authoritative end would a) expose the servers doing it to possible cache pollution b) remove incentive from leaf sites to enable synthesis in the local full-service resolver thereby prolonging and increasing the leakage of AAAA queries into the core ("hey, it already works, why should we upgrade"). Both are bad. If AAAA synthesis turns out to be the correct answer then it should be done in the right place. Johan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:27:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIQEn16201 for ipng-dist; Tue, 21 Aug 2001 11:26:14 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIQCm16194 for ; Tue, 21 Aug 2001 11:26:12 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIOD929323 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:24:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GFY1D18709 for ; Thu, 16 Aug 2001 08:34:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00955 for ; Thu, 16 Aug 2001 08:34:04 -0700 (PDT) Received: from mail.kcc.com (redgate.kcc.com [192.136.16.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA22508 for ; Thu, 16 Aug 2001 08:34:03 -0700 (PDT) Received: from 165.28.96.57 by mail.kcc.com with ESMTP (:Unauthorized access prohibited (MMS v4.7)); Thu, 16 Aug 2001 10:34:43 -0500 X-Server-Uuid: fc96bae8-3f98-11d2-a40d-00805f199815 Received: by ustcax01.kcc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 10:33:59 -0500 Message-ID: From: "Ochoa, Julio" To: ipng@sunroof.eng.sun.com Subject: Information about Field Bus Protocols (Ethernet, ProfiBus, Device Net, etc.) Date: Thu, 16 Aug 2001 10:32:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 17653799770690-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I need information about differents Field Bus protocols in the web. Can someone help me with this information? I accept a books recomendation too. Thanks, Julio Ochoa Kimberly Clark Corp. Colombia, South America jochoa@kcc.com ------------------------------------------------------------------------------ This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law. If you have received this message in error, please inform us promptly by reply e-mail, then delete the e-mail and destroy any printed copy. Thank you. ============================================================================== -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:27:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIQbw16227 for ipng-dist; Tue, 21 Aug 2001 11:26:37 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIQZm16220 for ; Tue, 21 Aug 2001 11:26:35 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIOaA29353 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:24:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GG8dD19014; Thu, 16 Aug 2001 09:08:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11179; Thu, 16 Aug 2001 09:08:42 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20406; Thu, 16 Aug 2001 10:08:37 -0600 (MDT) Received: from localhost (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id B1EFE3190C; Thu, 16 Aug 2001 09:08:38 -0700 (PDT) Date: Thu, 16 Aug 2001 18:07:23 +0200 (CEST) From: Roy Arends To: bert hubert Cc: Roy Arends , Robert Elz , Bill Manning , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <20010816105417.A8843@fork.powerdns.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, 16 Aug 2001, bert hubert wrote: > On Thu, Aug 16, 2001 at 01:47:01AM +0200, Roy Arends wrote: > > On Wed, 15 Aug 2001, bert hubert wrote: > > > > > I'm butting in here, but it may be interesting to know that quite a number > > > of the top-100 resolving nameserver installations out there are still > > > running Bind4! > > > > I'm interested in the algorithm to determine that list of top-100 > > resolving nameserver installations. > > You just tcpdump a lot on nameservers hosting a lot of domains. I personally > use dns-us1.powerdns.com and dns-eu1.powerdns.com, as well as ns1.i.am and > ns2.i.am - these cover around 4000 domains, including the widely used > 'i.am' one. Ah, yeah, but it will be fairly difficult to do an assesment of ID randomness in the received queries (unless incremental). I am interested in the survey results, could you dump your results on the lists ? Thanks Roy Arends Nominum ------------- 0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:28:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIR0I16236 for ipng-dist; Tue, 21 Aug 2001 11:27:00 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIQvm16229 for ; Tue, 21 Aug 2001 11:26:57 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIOxi29383 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:24:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GGxxD19241 for ; Thu, 16 Aug 2001 09:59:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21259; Thu, 16 Aug 2001 09:59:59 -0700 (PDT) Received: from yue.hongo.wide.ad.jp ([203.178.139.94]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10492; Thu, 16 Aug 2001 11:00:09 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id CAA18823; Fri, 17 Aug 2001 02:02:35 +0900 To: Erik.Nordmark@eng.sun.com Cc: jinmei@isl.rdc.toshiba.co.jp, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010817020235M.yoshfuji@wide.ad.jp> Date: Fri, 17 Aug 2001 02:02:35 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article (at Thu, 16 Aug 2001 17:31:26 +0200 (CEST)), Erik Nordmark says: > When you ship a new release that supports a link ids, site ids, etc > won't you also ship a getaddrinfo and getnameinfo which can handle those? We need some paths to keep backward compatibility on systems such that kernel / library and applications may be developed / distributed separately by respective maintainers. ex.) linux kernel, glibc and other utilities such as ping6, net-snmp etc. Atsushi Onoe wrote: > I won't oppose that an implementation accepts the values which don't match > the scope type, but at least it MUST NOT returns such values to applications, > IMHO. So just "MUST NOT" is not acceptable. To leave meaning of 0-scope unspecified (for kernel<->userland) may be ok. --yoshfuji -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:28:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIRLu16247 for ipng-dist; Tue, 21 Aug 2001 11:27:21 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIRIm16240 for ; Tue, 21 Aug 2001 11:27:18 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIPJr29414 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:25:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7H7uoL22516; Fri, 17 Aug 2001 00:56:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05765; Fri, 17 Aug 2001 00:56:54 -0700 (PDT) Received: from citadel.cequrux.com ([192.96.22.18]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18014; Fri, 17 Aug 2001 00:56:44 -0700 (PDT) Received: (from nobody@localhost) by citadel.cequrux.com (8.8.8/8.6.9) id JAA17610; Fri, 17 Aug 2001 09:54:59 +0200 (SAST) Received: by citadel.cequrux.com via recvmail id 17521; Fri Aug 17 09:54:09 2001 X-Authentication-Warning: apb.cequrux.com: apb owned process doing -bs Date: Fri, 17 Aug 2001 09:54:03 +0200 (SAST) From: Alan Barrett To: Johan Ihren cc: , , , Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary In-Reply-To: <2cwv44gmch.fsf@snout.autonomica.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 16 Aug 2001, Johan Ihren wrote: > Many authoritative servers run in non-recursive mode for security > reasons, which is sound practice. The information that the authoritative servers would need to perform AAAA synthesis could conceivably be provided as "glue". There's no absolute need for it to be obtained via any sort of recursive query. --apb (Alan Barrett) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:28:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIRie16267 for ipng-dist; Tue, 21 Aug 2001 11:27:44 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIRfm16256 for ; Tue, 21 Aug 2001 11:27:41 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7LIPgm29444 for ipng@sunroof.eng.sun.com; Tue, 21 Aug 2001 11:25:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LHuam15347 for ; Tue, 21 Aug 2001 10:56:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00505 for ; Tue, 21 Aug 2001 10:56:38 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01471 for ; Tue, 21 Aug 2001 11:56:54 -0600 (MDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA18763; Tue, 21 Aug 2001 10:48:59 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 21 Aug 2001 10:48:59 -0700 (PDT) From: Bernard Aboba To: jarno.rajahalme@nokia.com cc: thomas.eklund@xelerated.com, G.Tsirtsis@flarion.com, charliep@IPRG.nokia.com, aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com, Basavaraj.Patil@nokia.com, subir@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <009CA59D1752DD448E07F8EB2F91175715D494@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The WG chairs may correct me if I misunderstood, but at the last AAA WG > meeting it was evident that even work clearly on the current charter, like > Mobile IPv6 Application (extension), do not get taken up by the WG. At least > not before the current work is finished, and maybe the WG is re-chartered > etc. So it seems hopeless to even think about work on areas outside, or > bordering the current charter. The AAA WG requires that subject area WGs come to consensus before considering a work item. That ensures that the AAA WG is working cooperatively with other WGs. So if you want to look at MIPv6/AAA, the first thing to do is to finish MIPv6. If you want to look at URP/AAA, then you first need to come to consensus on URP. If you want to work on AAAv6, you've got to get consensus within IPNG WG that this approach makes sense. Same with SIP/AAA -- the SIP community needs to come to consensus first. This approach has worked well so far with MIPv4, NASREQ and ROAMOPS. Those WGs investigated their problem spaces, wrote and discussed requirements documents, and came to consensus. At that point, AAA WG picked up and responded to their requirements. Having an architectural framework and problem statement agreed to beforehand makes the AAA work straightforward and easy to deal with. Where the relevant communities are willing and able to do the required work to think through the architectural issues, and develop a framework that is the solution to a real problem, I suspect that the AAA issues will sort themselves out naturally, and AAA WG will not be a bottleneck. > > I think the URP WG should be chartered ASAP and AAAv6 taken there as a > possible solution. Where can I find the current proposal for the URP > charter? > Just as the AAA WG is not the appropriate place to do the work of subject area WGs, it is not appropriate for subject area WGs to design AAA protocols. We have separate WGs so that subject matter experts can congregate and focus on their area of expertise. So it would be best for URP to be handled in URP WG, AAA in AAA WG, and IPv6 in IPNG WG. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 11:57:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LIuoj17168 for ipng-dist; Tue, 21 Aug 2001 11:56:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LIukm17156 for ; Tue, 21 Aug 2001 11:56:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10315 for ; Tue, 21 Aug 2001 11:56:47 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15805 for ; Tue, 21 Aug 2001 12:56:42 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 20:56:48 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECA9E7@mail.kebne.se> From: Thomas Eklund To: "'Bernard Aboba '" , "'Charlie Perkins '" Cc: "'aaa-wg@merit.edu '" , "'john.loughney@nokia.com '" , "'ipng@sunroof.eng.sun.com '" , "'urp@research.telcordia.com '" Subject: RE: [AAA-WG]: AAA for IPv6 Date: Tue, 21 Aug 2001 20:56:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bernard, It was rough consenus on the IPv6 WG meeting that this was something that is of interest of IPv6 WG and the WG supports that it becomes a AAA WG item. -- Regards Thomas -----Original Message----- From: Bernard Aboba To: Charlie Perkins Cc: aaa-wg@merit.edu; john.loughney@nokia.com; ipng@sunroof.eng.sun.com; urp@research.telcordia.com Sent: 2001-08-21 09:05 Subject: Re: [AAA-WG]: AAA for IPv6 The AAA WG only considers work items resulting from a consensus draft within a subject area WG. Until the IPNG or URP WG progresses a draft on the subject, we cannot consider a work item relating to AAA for IPV6. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 12:06:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LJ57a17537 for ipng-dist; Tue, 21 Aug 2001 12:05:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LJ52m17522 for ; Tue, 21 Aug 2001 12:05:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08559 for ; Tue, 21 Aug 2001 12:05:03 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15695 for ; Tue, 21 Aug 2001 12:05:02 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA25234; Tue, 21 Aug 2001 20:05:00 +0100 Received: from hursley.ibm.com ([9.2.89.80]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA48512; Tue, 21 Aug 2001 20:05:00 +0100 Message-ID: <3B82BF62.886F3EF8@hursley.ibm.com> Date: Tue, 21 Aug 2001 15:06:58 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Eklund CC: "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label References: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> 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 f7LJ53m17523 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, The diffserv issue is that diffserv currently cannot properly classify packets that are hidden by ESP headers. If it wasn't for that, I personally wouldn't have gone near the flow label. I believe that mixing the two types of semantics in one field is an unacceptable complication that we should avoid on general engineering principles. Even mixing two types of QOS semantics bothers me, but not as much. Brian Thomas Eklund wrote: > > Dear Brian, > The intention is not to combine those at the same time the idea I support is > to let people have both and let the user decide. > > Baically I see two different scenarios: > 1) service provider, hop-by-hop semantic and wants the flowlabel to resemble > mpls flow label > 2) enterprise, end-to-end (within the admin doman i.e. the enerprise) where > you probably would like a intserv model. > > I dont see the need for defining a diffserv model since you have a diffserv > label today, but if there is many ISP that want more DSCP then I would > support it (eventhough the ISP talk is not looking for that in a near > future). > regards > Thomas > > -----Original Message----- > From: Brian E Carpenter > To: Thomas Eklund > Cc: 'Francis Dupont '; 'ipng ' > Sent: 2001-08-19 21:30 > Subject: Re: Higher level question about flow label > > Thomas, > > How can you combine a routing handle usage with intserv usage? > These usages are totally disjoint. It's one or the other. > > The historical fact (thanks to Frank Solensky for pointing this out in > private mail) is that we rejected the routing handle usage right at > the beginning of IPv6, even though some people disagreed and still > regret > it. But we also moved the language about the flow label to an appendix > in RFC 2460, which means that many implementors seem to have ignored it. > I believe it is time to clean up that ambiguity. > > BTW it's the presence of an ESP header that tells you if the packet is > encrypted. I don't see any need for a bit. > > Brian > > Thomas Eklund wrote: > > > > I vote for a semantics where you have MPLS or intserv style semantics > and I > > would also like a bit telling if the packet is encrypted or not. > > > > -Francis.Dupont@enst-bretagne.fr > > -PS: Intserv is not 100% dead because there is an environment > (wireless) > > -where to get more bandwidth is really expensive (in Europe at least > :-). > > -PPS: there is another usage: flow-based switching for fast routing > > -but I don't believe this really helps (petabit router vendors?) > > > > --> No there is no need in term of a flow based switching fast routing > since > > the memory where you store the routing tables are so huge today. 512 K > IPv4 > > prefixes could be stored in one CAM memory and usually you can use > several > > to obtain larger tables - all the CAM vendors support between 1 - 4 M > IPv4 > > prefixes to be stored in their CAM and do one look up in a clock > cycle. > > > > But many people are using flow to do traffic engneering and that's > where I > > belive the "mpls" op by hop semantic is needed. for the flow label. It > would > > also be easier to signal up to the routing protocls like IS-IS, OSPF. > BGP > > etc when a change occured. > > > > -- thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 12:15:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LJEb517706 for ipng-dist; Tue, 21 Aug 2001 12:14:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LJEXm17699 for ; Tue, 21 Aug 2001 12:14:33 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06665 for ; Tue, 21 Aug 2001 12:14:35 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08953 for ; Tue, 21 Aug 2001 12:14:33 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA30902; Tue, 21 Aug 2001 20:14:31 +0100 Received: from hursley.ibm.com ([9.2.89.80]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA48588; Tue, 21 Aug 2001 20:14:31 +0100 Message-ID: <3B82C19C.77DE244@hursley.ibm.com> Date: Tue, 21 Aug 2001 15:16:28 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Narten CC: Alex Conta , Bob Hinden , ipng Subject: Re: Higher level question about flow label References: <200108201753.NAA21705@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: ... > In my view, deciding on the right useage of the bits requires first > understanding the problem that needs to be solved. I think that from the QOS viewpoint, we do understand the problem very well, hence the proposal to add a diffserv usage to the existing intserv usage. The intserv usage is documented and somewhat implemented, and I don't think we can hide behind the weasel words in RFC 2460 any longer. I don't pretend to understand the routing handle usage (but then, I'm of the school of thought that doesn't understand why anyone would want MPLS either). 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 Aug 21 12:30:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LJTFL17764 for ipng-dist; Tue, 21 Aug 2001 12:29:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LJTBm17757 for ; Tue, 21 Aug 2001 12:29:12 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16798 for ; Tue, 21 Aug 2001 12:29:09 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26730 for ; Tue, 21 Aug 2001 12:29:08 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA25334; Tue, 21 Aug 2001 20:29:05 +0100 Received: from hursley.ibm.com ([9.2.89.80]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA51760; Tue, 21 Aug 2001 20:29:05 +0100 Message-ID: <3B82C505.588E9695@hursley.ibm.com> Date: Tue, 21 Aug 2001 15:31:01 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: seamus@bit-net.com, thomas.eklund@xelerated.com, aconta@txc.com, narten@raleigh.ibm.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757197FDB@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno, The Carpenter/Conta proposal does include two formats for the label (one aimed at intserv flows and one aimed at diffserv flows), but if you use the field only for rapid routing lookup, you don't care about that; in both cases you can treat the label as 20 opaque bits I think. You only care which format it is when you are doing specific intserv or diffserv packet classification. Brian jarno.rajahalme@nokia.com wrote: > > Jim, > > Nice rant :-) > > Could you elaborate on the pseudo-random nature of the flow label. It seems > to me that if it did not need to be pseudo-random, people could go on > "signaling off-line" about the flow label values (in SLAs, this seems to be > what Alex & Brian want). I see no harm in allowing such practice, but it > would be best if there is only one format for the flow label, as it would be > faster to decode. > > Jarno > > > -----Original Message----- > > From: ext Jim Bound [mailto:seamus@bit-net.com] > > Sent: 21. elokuuta 2001 15:58 > > To: Thomas Eklund > > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob Hinden; ipng > > Subject: RE: Higher level question about flow label > > > > > > thomas, > > > > that is why if we can treat the flowlabel as part of tuple with src > > address and identify a connection which identifies the forwarding path > > the challenge is reduced. there is nothing needed but the > > header for the > > look up and forward. I believe this can be made to work. > > > > the traffic class will provide diff serv metric and the flow > > identifies > > the E2E connection with the src addr. > > > > The src addr MUST be a global address. > > > > Site-Local can be done too but don't want to get into that right now. > > > > One can ask if the Ipv6 address is global why have the flow for per > > connection as above. This is a good question and needs discussion. > > > > First the flow assists with the lookup in a binary tree, > > queue type, or > > archaic hash. Its the hint to the next leaf, bucket, or queue entry. > > duplicat highorder bits would cause a branch. This could speed up the > > search before even getting to the global address. > > > > The src + flow could also be used as label for MPLS and its > > in the IPv6 > > header. > > > > The business reason could also be that end users would create SLAs for > > their flow labels in addition the bits set for the traffic > > class. This is > > how QOS Int Serv could be realized. And I guess conjunct > > with diff serv > > but that would need to be specified too. > > > > This also benefits client and server boxes too (gateways > > too). We can now > > potentially keep one protocol control block for user connections. tcp, > > sctp, and dcp per connection data structures would not have to be kept > > above the internet per connection datastructures (e.g. bsd > > inpcb would be > > enough). This is a performance win for clients and servers > > for IPv6 not > > just routers or switches or gateways. > > > > If we put a length in the flow yes it can be made to work but > > not without > > being verified by the router as the packet is parsed or > > "policed" then we > > have just put new processing far worse than the IP checksum which we > > removed from the IPv6 router. And opens up opportunity for > > bugs at that > > code point we don't have today. > > > > I also don't support the field being mutable as it transits > > the network > > path to the end destination. > > > > The reason is that we should make IPv6 E2E perform in the > > network as fas > > as possible. If you look at all the work to do VPN, L2TP, > > NAT, Virtual > > Routing, et al that is emerging pervasive for IPv4 the root > > reasons are > > lack of IPv4 address space, the desire to do fast layer 2 > > switching, and > > security inspection (e.g. firewalls). > > > > The later two above are the only valid visions. We need to > > eliminate in > > our thinking the mind set developed because of lack of IPv4 > > address space. > > I could argue that what is happening to IPv4 is pure professional > > irresponsibility on our part as Internet engineers. The > > Internet should > > remain E2E. This is not a politcal comment or even social > > comment. Its a > > comment stating my assumptions about how the Internet should operate. > > > > I think we need to discuss our assumptions for the > > requirements with the > > solutions we define. > > > > ADSL box providers actually market that NAT helps you because > > you don't > > have to worry about address space. This is absurd and professionally > > irresponsible in the market. We should stop this with IPv6. > > > > The way to do that is give routers the means to forward packets E2E by > > only looking at the header of IPv6. That is what Brian's "b" solution > > does. Plus it benefits all nodes besides routes for IPv6 as I state > > above. > > > > As far as IPv6 extensions. The payload length gives the > > router the entire > > length of the packet. If the flowlabel can be used to > > identify forwarding > > the packet in addition to the address and other parts as I state above > > then there is no challenge for ASIC vendors for strict > > forwarding of IPv6 > > packets. > > > > If those vendors want to add more value by digging past the > > header then > > that is their option to add value but I don't believe it is > > required for > > fast forwarding of IPv6 packets. > > > > Steve's design works and I believe can be extended with the > > flowlabell and > > we can get rid of the mess IPv4 is making of the Internet > > because of the > > band-aids being applied. > > > > I believe the End System (and that could be a router in some > > cases or a > > broker router) should set the flowlabel at the access exit before the > > edge. But thats another discussion. > > > > Another discussion is how do we pick good random numbers for > > the flowlabel > > at the access exit end system or even a client. > > > > regards, > > /jim > > > > > > On Tue, 21 Aug 2001, Thomas Eklund wrote: > > > > > I agree alex. > > > > > > It gets worse for people that are doing ASIC which is not > > programmable, then > > > they need to spin a new version their ASIC when the > > protocols changes. For > > > people that are doing programmable ASIC (network processors > > etc) this is not > > > a problem. > > > > > > But common for both approaches is that the header format is > > really challenge > > > for the ASIC engineers > > > > > > -- thomas > > > > > > >-----Original Message----- > > > >From: Alex Conta [mailto:aconta@txc.com] > > > >Sent: den 20 augusti 2001 22:15 > > > >To: Thomas Narten > > > >Cc: Brian E Carpenter; Bob Hinden; ipng > > > >Subject: Re: Higher level question about flow label > > > > > > > > > > > > > > > > > > > >Thomas Narten wrote: > > > >> > > > >> [...] When someone can make a compelling argument for why > > > >> the bits need to be defined in a certain way (i.e., > > there is a real > > > >> application for which using the bits provides > > significant benefits, > > > >> and those benefits do not appear achievable through > > other means) that > > > >> is the time to define the bits. What I do sense with many of the > > > >> recent discussions surrounding the Flow Label is that > > there are many > > > >> folks (i.e., folks putting IPv6 into hardware) that want > > to know what > > > >> they should implement w.r.t. the Flow Label. While it would > > > >be nice to > > > >> be able tell them what to do, we shouldn't standardize > > something just > > > >> for the sake of having a definition. > > > >> > > > >> Thomas > > > > > > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per byte, or 3.2 > > > >instructions of a hypothetical > > > >1Ghz processor which can execute one instruction per > > cycle. That's a > > > >hell of a requirement. > > > > > > > >As consumers, we all enjoy the very cost-effective availability of > > > >100Mb/sec line speed packet processing in almost every > > > >Notebook, or PC. > > > > > > > >IP and QoS Engines implemented in silicon, on a chip or a > > few chips, by > > > >IBM, INTEL, and many, many others, is one of the reasons of the low > > > >costs, along with the ability to optimizing the hardware > > > >in so many more and different ways than the software (for instance > > > >parallel header, or parallel header field processing). > > > > > > > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just > > > >around the > > > >corner, with 40Gb/sec following not long after. > > > > > > > >With such drastic "timing" requirements, implementing engines in > > > >silicon, and inventing *clever* mechanisms to handle the sequential > > > >processing of headers alone, will not be sufficient to > > implement very > > > >cost-effective IPv6 forwarding and QoS solutions, and IPv6 is at a > > > >disadvantage relative to IPv4. > > > > > > > >We need all the help we can get from the protocol, that is > > headers, and > > > >their fields, for forwarding and QoS processing, and by that I > > > >mean both > > > >Intserv, and Diffserv. > > > > > > > >Regards, > > > >Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 12:32:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LJVdc17797 for ipng-dist; Tue, 21 Aug 2001 12:31:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LJVZm17790 for ; Tue, 21 Aug 2001 12:31:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17498 for ; Tue, 21 Aug 2001 12:31:37 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17891 for ; Tue, 21 Aug 2001 13:31:32 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA05192; Tue, 21 Aug 2001 20:31:33 +0100 Received: from hursley.ibm.com ([9.2.89.80]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA46646; Tue, 21 Aug 2001 20:31:34 +0100 Message-ID: <3B82C599.E464F53D@hursley.ibm.com> Date: Tue, 21 Aug 2001 15:33:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta CC: Jim Bound , Tim Chown , ipng Subject: Re: Higher level question about flow label References: <3B818DEF.C55A979D@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hmm... it seems to me that both the formats we are suggesting (pseudo-random and diffserv PHB ID) are immutable. Brian Alex Conta wrote: > > Jim, > > Please reexamine. > > As a hint, note that MPLS, which is using *mutable* labels, is using > RSVP-TE (extension of RSVP > for Traffic Engineering) as one of the label distribution mechanisms. > > Alex > > Jim Bound wrote: > > > > Yes I would as a note. I want what we orginally called for and to make > > sure nothing breaks RSVPv6 which uses the flowlabel too. > > > > /jim > > > > On Fri, 17 Aug 2001, Tim Chown wrote: > > > > > On Fri, 17 Aug 2001, Francis Dupont wrote: > > > > > > > In your previous mail you wrote: > > > > > > > > I think the WG needs to decide once and for all whether the flow label is > > > > a) a CATNIP or MPLS-like routing handle > > > > or b) a QOS hint for intserv only > > > > or c) a QOS hint for intserv and diffserv > > > > or d) a waste of bits > > > > > > > > => I vote for b) > > > > > > So would you vote to mandate that the field is non-mutable in transit too? > > > > > > tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 12:49:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LJm1B17826 for ipng-dist; Tue, 21 Aug 2001 12:48:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LJlwm17819 for ; Tue, 21 Aug 2001 12:47:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20564 for ; Tue, 21 Aug 2001 12:47:59 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA03677 for ; Tue, 21 Aug 2001 13:47:55 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Aug 2001 12:46:59 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 12:46:59 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 12:46:52 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 21 Aug 2001 12:46:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Ipv6IfIndex and IPv4 ifIndex Date: Tue, 21 Aug 2001 12:46:36 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B58155@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ipv6IfIndex and IPv4 ifIndex thread-index: AcEqU7lNQUW/C5JAQ4mt5wDC/+AJtgAJbXaw From: "Dave Thaler" To: "Dimitry Haskin" Cc: "Deshpande, Prasad" , X-OriginalArrivalTime: 21 Aug 2001 19:46:37.0781 (UTC) FILETIME=[FDA2F850:01C12A79] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7LJlwm17820 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What's a "logical IPv6 interface" and where is it defined? If you're using VLANs or whatever else, you can do it with ifIndex values, and this buys you a lot (you get the ifStackTable, stats, etc). I see no advantage to introducing another numbering space and trying to get people to understand it. So I agree that Dimitry's answer applies to RFC 2465, but we don't keep this concept in the new MIB drafts. -Dave > -----Original Message----- > From: Dimitry Haskin [mailto:dhaskin@axiowave.com] > Sent: Tuesday, August 21, 2001 8:09 AM > To: 'Deshpande, Prasad'; ipng@sunroof.eng.sun.com > Subject: RE: Ipv6IfIndex and IPv4 ifIndex > > Prasad, > > ipv6IfIndex defines a logical IPv6 interface. There is no requirement for > its value being equal to an ifIndex value. Generally, it should be > possible > to configure multiple logical IPv6 interfaces on a single physical > interface. > > Regards, > Dimitry > > > -----Original Message----- > > From: Deshpande, Prasad [mailto:PDeshpande@unispherenetworks.com] > > Sent: Tuesday, August 21, 2001 10:04 AM > > To: ipng@sunroof.eng.sun.com > > Subject: Ipv6IfIndex and IPv4 ifIndex > > > > Hi, > > > > If IPv6 and IPv4 unicast forwarding are enabled on the same physical > > interface, would values of Ipv6IfIndex and ifIndex (IPv4) be the same > > i.e. would the same row show up in both ifTable and ipv6IfTable. Is > > this implementation dependent? > > > > I couldnt find any draft/RFC that talks about this. > > > > thanks > > -prasad > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Tue Aug 21 13:08:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LK67f18052 for ipng-dist; Tue, 21 Aug 2001 13:06:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LK64m18045 for ; Tue, 21 Aug 2001 13:06:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16362 for ; Tue, 21 Aug 2001 13:06:06 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19904 for ; Tue, 21 Aug 2001 14:06:01 -0600 (MDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7LK62s62455; Tue, 21 Aug 2001 16:06:02 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7LK60350380; Tue, 21 Aug 2001 16:06:01 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id QAA02895; Tue, 21 Aug 2001 16:05:59 -0400 (EDT) Message-Id: <200108212005.QAA02895@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Brian E Carpenter cc: ipng Subject: Re: Higher level question about flow label In-reply-to: Your message of "Tue, 21 Aug 2001 15:16:28 CDT." <3B82C19C.77DE244@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Aug 2001 16:05:59 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter wrote: > Thomas Narten wrote: > ... > > In my view, deciding on the right useage of the bits requires first > > understanding the problem that needs to be solved. > > I think that from the QOS viewpoint, we do understand the problem very well, > hence the proposal to add a diffserv usage to the existing intserv usage.' When I think about the most popular usage of protocol/port classification for QoS (clamping down Napster traffic on university LANs), I don't see how the new flow label proposal will solve that problem. Protocol/port classification is only a "requirement" of Diffserv because we haven't solved the problem of enabling the host to put meaningful values in the DSCP. I would prefer to try to solve that problem. > The intserv usage is documented and somewhat implemented, and I don't > think we can hide behind the weasel words in RFC 2460 any longer. I think the requirement that the flow label be a PRN could be relaxed: as long as it is unique per-host it should suffice for Intserv and other flow-caching usages. > I don't pretend to understand the routing handle usage (but then, > I'm of the school of thought that doesn't understand why anyone would > want MPLS either). Because some folks want Frame Relay NG, for a variety of reasons, including multi-protocol support. Which is why trying to fit label switching into IPv6 is completely besides the point. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 13:12:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LKBOD18090 for ipng-dist; Tue, 21 Aug 2001 13:11:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LKBKm18083 for ; Tue, 21 Aug 2001 13:11:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25086 for ; Tue, 21 Aug 2001 13:11:20 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24389 for ; Tue, 21 Aug 2001 14:11:15 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7LKBMn00812; Tue, 21 Aug 2001 13:11:22 -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 ACY12784; Tue, 21 Aug 2001 13:11:10 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA19546; Tue, 21 Aug 2001 13:11:09 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.49245.24268.283937@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 13:11:09 -0700 (PDT) To: Brian E Carpenter Cc: Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label In-Reply-To: <3B82BF62.886F3EF8@hursley.ibm.com> References: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> <3B82BF62.886F3EF8@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Thomas, > > The diffserv issue is that diffserv currently cannot properly classify packets > that are hidden by ESP headers. If it wasn't for that, I personally wouldn't > have gone near the flow label. Huh? I thought that one of the requirements for ESP was to copy the DSCP to the outer header. If I recall correctly, this bothers some people from a traffic analysis standpoint, but that seems to be part and parcel with QoS so that doesn't hold much water IMO. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 13:19:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LKIKc18143 for ipng-dist; Tue, 21 Aug 2001 13:18:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LKIGm18136 for ; Tue, 21 Aug 2001 13:18:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26282 for ; Tue, 21 Aug 2001 13:18:03 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18890 for ; Tue, 21 Aug 2001 13:17:59 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA23840; Tue, 21 Aug 2001 21:17:57 +0100 Received: from hursley.ibm.com ([9.2.89.80]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA46712; Tue, 21 Aug 2001 21:17:57 +0100 Message-ID: <3B82D06B.7A76ED4D@hursley.ibm.com> Date: Tue, 21 Aug 2001 16:19:39 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Steve Blake CC: ipng Subject: Re: Higher level question about flow label References: <200108212005.QAA02895@castillo.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Blake wrote: > > Brian Carpenter wrote: > > > Thomas Narten wrote: > > ... > > > In my view, deciding on the right useage of the bits requires first > > > understanding the problem that needs to be solved. > > > > I think that from the QOS viewpoint, we do understand the problem very well, > > hence the proposal to add a diffserv usage to the existing intserv usage.' > > When I think about the most popular usage of protocol/port classification > for QoS (clamping down Napster traffic on university LANs), I don't see > how the new flow label proposal will solve that problem. I hope not. It wasn't designed to. At the risk of repeating myself, the idea is to partially alleviate the problem of classifying encrypted packets. > Protocol/port classification is only a "requirement" of Diffserv because > we haven't solved the problem of enabling the host to put meaningful > values in the DSCP. I would prefer to try to solve that problem. That is really a small matter of programming. AIX has been able to set DSCPs at source for a couple of years, and so has Linux and one or two other o/s. The issue is getting QOS policy managers into the hosts, and optionally adding code to applications to interact with the policy manager and set the DSCP on the socket. IMHO there is no IETF issue here. > > The intserv usage is documented and somewhat implemented, and I don't > > think we can hide behind the weasel words in RFC 2460 any longer. > > I think the requirement that the flow label be a PRN could be relaxed: > as long as it is unique per-host it should suffice for Intserv and other > flow-caching usages. Probably. I don't really remember the argument for PRN but it may have been gut feeling about hashing efficiency. > > > I don't pretend to understand the routing handle usage (but then, > > I'm of the school of thought that doesn't understand why anyone would > > want MPLS either). > > Because some folks want Frame Relay NG, for a variety of reasons, including > multi-protocol support. Which is why trying to fit label switching into > IPv6 is completely besides the point. Fully agree. When we rejected CATNIP in 1994, we rejected this. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 13:27:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LKOrw18185 for ipng-dist; Tue, 21 Aug 2001 13:24:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LKOnm18178 for ; Tue, 21 Aug 2001 13:24:49 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05335 for ; Tue, 21 Aug 2001 13:24:51 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25428 for ; Tue, 21 Aug 2001 13:24:49 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA18966; Tue, 21 Aug 2001 21:24:47 +0100 Received: from hursley.ibm.com ([9.2.89.80]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA45476; Tue, 21 Aug 2001 21:24:47 +0100 Message-ID: <3B82D204.66CE4372@hursley.ibm.com> Date: Tue, 21 Aug 2001 16:26:28 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: "''ipng ' '" Subject: Re: Higher level question about flow label References: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> <3B82BF62.886F3EF8@hursley.ibm.com> <15234.49245.24268.283937@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The point is that when a packet crosses an administrative domain boundary, the downstream ISP typically wants to reclassify the packet all over again, i.e. does not accept the incoming DSCP as definitive. This was a very clearly stated ISP requirement at the start of diffserv and is fundamental in the diffserv architecture. Brian Michael Thomas wrote: > > Brian E Carpenter writes: > > Thomas, > > > > The diffserv issue is that diffserv currently cannot properly classify packets > > that are hidden by ESP headers. If it wasn't for that, I personally wouldn't > > have gone near the flow label. > > Huh? I thought that one of the requirements for ESP was to > copy the DSCP to the outer header. If I recall correctly, > this bothers some people from a traffic analysis standpoint, > but that seems to be part and parcel with QoS so that doesn't > hold much water IMO. > > Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 13:34:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LKWv718221 for ipng-dist; Tue, 21 Aug 2001 13:32:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LKWrm18214 for ; Tue, 21 Aug 2001 13:32:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22097 for ; Tue, 21 Aug 2001 13:32:55 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03874 for ; Tue, 21 Aug 2001 14:33:12 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7LKX2n15701; Tue, 21 Aug 2001 13:33:03 -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 ACY13424; Tue, 21 Aug 2001 13:32:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA19549; Tue, 21 Aug 2001 13:32:50 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.50546.492164.937269@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 13:32:50 -0700 (PDT) To: Brian E Carpenter Cc: Michael Thomas , "''ipng ' '" Subject: Re: Higher level question about flow label In-Reply-To: <3B82D204.66CE4372@hursley.ibm.com> References: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> <3B82BF62.886F3EF8@hursley.ibm.com> <15234.49245.24268.283937@thomasm-u1.cisco.com> <3B82D204.66CE4372@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > The point is that when a packet crosses an administrative domain boundary, > the downstream ISP typically wants to reclassify the packet all over again, > i.e. does not accept the incoming DSCP as definitive. This was a very > clearly stated ISP requirement at the start of diffserv and is fundamental > in the diffserv architecture. Right... I must be missing something. You copy the inner DSCP to the tunneled packet header, it traverses the network just like normal with whatever re-writing rules apply at the administrative edges, and once the packet is decapsulated, you copy the outer DSCP back into the inner and goes along its merry way. What am I missing? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 13:41:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LKeUB18284 for ipng-dist; Tue, 21 Aug 2001 13:40:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LKeQm18277 for ; Tue, 21 Aug 2001 13:40:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23479 for ; Tue, 21 Aug 2001 13:40:24 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05848 for ; Tue, 21 Aug 2001 13:40:19 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA17888; Tue, 21 Aug 2001 21:40:16 +0100 Received: from hursley.ibm.com ([9.2.89.80]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA31500; Tue, 21 Aug 2001 21:40:17 +0100 Message-ID: <3B82D5A3.24A87922@hursley.ibm.com> Date: Tue, 21 Aug 2001 16:41:55 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: "''ipng ' '" Subject: Re: Higher level question about flow label References: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> <3B82BF62.886F3EF8@hursley.ibm.com> <15234.49245.24268.283937@thomasm-u1.cisco.com> <3B82D204.66CE4372@hursley.ibm.com> <15234.50546.492164.937269@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: > > Brian E Carpenter writes: > > The point is that when a packet crosses an administrative domain boundary, > > the downstream ISP typically wants to reclassify the packet all over again, > > i.e. does not accept the incoming DSCP as definitive. This was a very > > clearly stated ISP requirement at the start of diffserv and is fundamental > > in the diffserv architecture. > > Right... I must be missing something. You copy the inner DSCP > to the tunneled packet header, it traverses the network just like > normal with whatever re-writing rules apply at the administrative > edges, and once the packet is decapsulated, you copy the outer > DSCP back into the inner and goes along its merry way. > > What am I missing? The tunnel aspect is discussed in RFC 2983 in some detail. The problem I mention is when the packet is inside a transport mode ESP header when it crosses an ISP boundary, and the SLA in place requires reclassification (i.e.the downstream ISP has not contracted to honor the upstream ISP's DSCP values). I think you're missing the distinction in diffserv between BA and MF classifiers (see RFC 2474 and 2475). 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 Aug 21 13:47:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LKkSq18372 for ipng-dist; Tue, 21 Aug 2001 13:46:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LKkPm18365 for ; Tue, 21 Aug 2001 13:46:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02639 for ; Tue, 21 Aug 2001 13:46:27 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23861 for ; Tue, 21 Aug 2001 14:46:22 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7LKkfT22408; Tue, 21 Aug 2001 13:46:41 -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 ACY13871; Tue, 21 Aug 2001 13:46:23 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA19555; Tue, 21 Aug 2001 13:46:22 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15234.51358.518560.857445@thomasm-u1.cisco.com> Date: Tue, 21 Aug 2001 13:46:22 -0700 (PDT) To: Brian E Carpenter Cc: Michael Thomas , "''ipng ' '" Subject: Re: Higher level question about flow label In-Reply-To: <3B82D204.66CE4372@hursley.ibm.com> References: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> <3B82BF62.886F3EF8@hursley.ibm.com> <15234.49245.24268.283937@thomasm-u1.cisco.com> <3B82D204.66CE4372@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > The point is that when a packet crosses an administrative domain boundary, > the downstream ISP typically wants to reclassify the packet all over again, > i.e. does not accept the incoming DSCP as definitive. This was a very > clearly stated ISP requirement at the start of diffserv and is fundamental > in the diffserv architecture. Oh. I now see what I missed. Why doesn't including the SPI into the flow key work? You wouldn't be able to police based on port numbers (ie try to be a firewall), but some would say that's a feature not a bug. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 21 16:42:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7LNfXj18751 for ipng-dist; Tue, 21 Aug 2001 16:41:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LNfUm18744 for ; Tue, 21 Aug 2001 16:41:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13147 for ; Tue, 21 Aug 2001 16:41:31 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15525 for ; Tue, 21 Aug 2001 16:41:31 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id TAA28959; Tue, 21 Aug 2001 19:42:26 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id TAA04878; Tue, 21 Aug 2001 19:42:26 -0400 Message-ID: <3B82F1D5.6F9F63FB@txc.com> Date: Tue, 21 Aug 2001 19:42:13 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Jim Bound , Tim Chown , ipng Subject: Re: Higher level question about flow label References: <3B818DEF.C55A979D@txc.com> <3B82C599.E464F53D@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms29D2D27E0ABA6C1962A7F5CB" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms29D2D27E0ABA6C1962A7F5CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In my view, we didn't restrict it to be "non-mutable", but that is in the boundaries set by: " (c) A flow label is assigned to a flow by the flow's source node. It can be changed en-route, with the condition that its original significance be maintained, or restored, when necessary. " at page 15, in the draft. "(c)" protects the value of the flow label, or rather, its meaning, where it is relevant to protect it. That is because, the value in itself, alone, is not meaningful. It is the meaning of the value, which is important, and as long as that meaning is preserved, the value can change. Regards, Alex Brian E Carpenter wrote: > > Hmm... it seems to me that both the formats we are suggesting (pseudo-random > and diffserv PHB ID) are immutable. > > Brian > > Alex Conta wrote: > > > > Jim, > > > > Please reexamine. > > > > As a hint, note that MPLS, which is using *mutable* labels, is using > > RSVP-TE (extension of RSVP > > for Traffic Engineering) as one of the label distribution mechanisms. > > > > Alex > > > > Jim Bound wrote: > > > > > > Yes I would as a note. I want what we orginally called for and to make > > > sure nothing breaks RSVPv6 which uses the flowlabel too. > > > > > > /jim > > > > > > On Fri, 17 Aug 2001, Tim Chown wrote: > > > > > > > On Fri, 17 Aug 2001, Francis Dupont wrote: > > > > > > > > > In your previous mail you wrote: > > > > > > > > > > I think the WG needs to decide once and for all whether the flow label is > > > > > a) a CATNIP or MPLS-like routing handle > > > > > or b) a QOS hint for intserv only > > > > > or c) a QOS hint for intserv and diffserv > > > > > or d) a waste of bits > > > > > > > > > > => I vote for b) > > > > > > > > So would you vote to mandate that the field is non-mutable in transit too? > > > > > > > > tim --------------ms29D2D27E0ABA6C1962A7F5CB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjEyMzQyMTVaMCMGCSqGSIb3DQEJBDEWBBTyWldaJDrkCSX7HkwP 2Y5hFfELmTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gHAy5YSOqMzwVsQjSh0kuLxAqsD8LYbq4G2CENdfB5Ity638oPFX9TaeuyfuCUPXnkqxheBc RXjaEvuLdKUOy2dc0IpfUmt/T6itbIzEz1NAGc8SsCzYqPOIDkLksOS+sil5EL+lEi4qlMcT vvYxuGBfk9kbxE2OeJoEqvy8q0dp --------------ms29D2D27E0ABA6C1962A7F5CB-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 17:46:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M0jNU18813 for ipng-dist; Tue, 21 Aug 2001 17:45:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M0jJm18806 for ; Tue, 21 Aug 2001 17:45:19 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01806 for ; Tue, 21 Aug 2001 17:45:22 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13809 for ; Tue, 21 Aug 2001 17:45:20 -0700 (PDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.9.3/8.9.3) with SMTP id JAA10859; Wed, 22 Aug 2001 09:45:28 +0900 (KST) Message-ID: <003a01c12aa4$0eb6f900$10e0d5a5@cychong> From: "Chae-yong Chong" To: "Anurag" , References: <00ae01c12a48$eeceb2a0$6d02a8c0@iwave008> Subject: Re: query Date: Wed, 22 Aug 2001 09:47:44 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f7M0jKm18807 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi.. I think you're saying "SOCK_PACKET" not "SOCKET_PACKET". In my understanding, SOCK_PACKET is not a new one. Linux has supported SOCK_PACKET socket type which you states. This is a part of "linux/include/asm-i386/socket.h" file. #define SOCK_PACKET 10 /* linux specific way of */ /* getting packets at the dev */ /* level. For writing rarp and */ /* other similar things on the */ /* user level. */ You can use this socket just like any other socket. Here is an example which send "Gratuitous ARP" directly data link layer. This is a part of implementation of Mobile IP(Binghamton University) Hope this helpful :-) void send_gratarp (char *device, u_long ipaddr, char *hwaddr, u_long destipaddr) { char frame[60]; struct ethhdr *ehdr; Arphdr *ahdr; int sockid; struct sockaddr sa; if ((sockid = socket (AF_INET, SOCK_PACKET, htons (ETH_P_802_3))) < 0) { perror ("Socket call failed in send_gratarp():"); return; } bzero ((void *) frame, sizeof (frame)); /* Ethernet header */ ehdr = (struct ethhdr *) frame; hwaddread (ehdr->h_dest, "ff:ff:ff:ff:ff:ff"); bcopy (hwaddr, ehdr->h_source, 6); ehdr->h_proto = htons (ETH_P_ARP); ahdr = (Arphdr *) (frame + sizeof (struct ethhdr)); /* Arp header */ ahdr->ar_hrd = htons (ARPHRD_ETHER); ahdr->ar_pro = htons (ETH_P_IP); ahdr->ar_hln = 6; ahdr->ar_pln = 4; ahdr->ar_op = htons (ARPOP_REQUEST); bcopy (hwaddr, ahdr->ar_sha, 6); bcopy (&ipaddr, ahdr->ar_sip, 4); bzero (ahdr->ar_tha, 6); bcopy (&ipaddr, ahdr->ar_tip, 4); sa.sa_family = AF_INET; strcpy (sa.sa_data, device); if (sendto (sockid, frame, sizeof (frame), 0, &sa, sizeof (sa)) < 0) { perror ("Sendto failed:"); exit (-1); } } Regards Chae-yong ----- Original Message ----- From: Anurag To: ipng@sunroof.eng.sun.com Sent: Tuesday, August 21, 2001 10:54 PM Subject: query hi alex I have one query . "The Linux support new socket type ,SOCKET_PACKET ,That provides access to data link ,similar to DLPI. I want to know how application communicates directly with the data link layer ,Is there any special functions and data structures? thanks. RESPECT OTHER'S ,U'LL GET RESPECT Anurag Uxa IWave Embedded Systems Bangalore India PH:6786243/5 Extn:206 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 20:42:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M3fmV19020 for ipng-dist; Tue, 21 Aug 2001 20:41:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M3fim19013 for ; Tue, 21 Aug 2001 20:41:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20488 for ; Tue, 21 Aug 2001 20:41:46 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07056 for ; Tue, 21 Aug 2001 21:42:04 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id XAA31162; Tue, 21 Aug 2001 23:42:41 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id XAA10631; Tue, 21 Aug 2001 23:42:39 -0400 Message-ID: <3B832A28.FE578626@txc.com> Date: Tue, 21 Aug 2001 23:42:32 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound CC: Bob Hinden , Brian E Carpenter , ipng Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF909EBEABD8B5FC1962733D6" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF909EBEABD8B5FC1962733D6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jim Bound wrote: > > Alex, > > > Jim, > > [...] > > I am afraid, there is a misunderstanding. Nobody advocated > > transport+port to promote routing or as a strategy. > > [...] > > As I do not expect everyone to understand or care about bit shifting, I > > should mention just for the sake of the record, that it was shown, t > > hat the details can be crafted to eliminate the risk [...] > > I saw that mail. That is not the only bug. The other bug will be > assuming the extensions and when to update the length. Adding this to the > IPv6 processing would need to be reviewed very carefully at this point. > Because it can be bit shifted does not mean it will work. > You must have skipped one or more of my earlier messages. > > [...] > > > > No question, IPv6 extensibility which is the ability to define and stack > > options in the 'hop by hop' headers, or 'destination' headers, is a > > plus. > > Also completely new prototcols. > What does "completely new protocols" have to do with IPv6 extensibility??? What do you mean? > [...] > I agree and that was for the address too. But if one follows the > extension chain all works correctly no matter what size or how many > extensions exist. > > > Minimizing the price paid is even more necessary, when we examine the > > gain on extensibility, by counting the IPv6 options which were > > standardized. and compare, them to the IPv4 standard options. > > IPv4 options don't work? I am missing the point? > You missed some of the earlier messages - mine, Thomas Eklund, etc... Sequential header processing is OK in software, or in host, but prevents parallel header fields and headers processing in hardware implementations, in routers, where fast IPv6 header processing is critical, and the price paid is high. The IPv4 options worked, but as it turned out, few were useful, so few are mandatory. This should be an additional indication, that options, in reality, are not that valuable. Based on the number of current standard IPv6 options -- how many? a handful? -- we should try really hard to minimize the cost of extensibility 'cause I see more pain than gain. Alex --------------msF909EBEABD8B5FC1962733D6 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjIwMzQyMzRaMCMGCSqGSIb3DQEJBDEWBBQCXDNSbh2/b0RUPrgi fAy/QJT9ZzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gIYMVjNenf/wXOQRPpu3LJQBZ8wUnoNPl7arQPxzmC7OCyHRWZbdgVtgckPtTqHMtu1T3cIv vO5MzO46wpIyE+3H13t5eR8ZqoBrvii438S+juR+b7OE81LNoXuacCKLZfFWzQLwtuCjGS0/ yFKGEgZqqCMto6qKXM5YPcCuagKz --------------msF909EBEABD8B5FC1962733D6-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 21:43:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M4gqs19131 for ipng-dist; Tue, 21 Aug 2001 21:42:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M4gnm19124 for ; Tue, 21 Aug 2001 21:42:49 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11537 for ; Tue, 21 Aug 2001 21:42:51 -0700 (PDT) Received: from web9207.mail.yahoo.com (web9207.mail.yahoo.com [216.136.129.40]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA19700 for ; Tue, 21 Aug 2001 21:42:51 -0700 (PDT) Message-ID: <20010822044251.47354.qmail@web9207.mail.yahoo.com> Received: from [161.139.68.13] by web9207.mail.yahoo.com; Tue, 21 Aug 2001 21:42:51 PDT Date: Tue, 21 Aug 2001 21:42:51 -0700 (PDT) From: pat nanthan Subject: ipv6 proposal To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-525239103-998455371=:43917" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-525239103-998455371=:43917 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline i'm a masters student from University of Technology Malaysia who are doing research on ecommerce security issues and ipv6. I need some specific suggestions on this area for further research if this area could be a preferred masters topic.I would be glad if anyone could help me. thanks __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-525239103-998455371=:43917-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 21 23:15:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M6EVT19234 for ipng-dist; Tue, 21 Aug 2001 23:14:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M6EQm19227 for ; Tue, 21 Aug 2001 23:14:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04975 for ; Tue, 21 Aug 2001 23:14:29 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17503 for ; Tue, 21 Aug 2001 23:14:28 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA19658; Tue, 21 Aug 2001 23:07:00 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 21 Aug 2001 23:07:00 -0700 (PDT) From: Bernard Aboba To: Thomas Narten cc: Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 In-Reply-To: <200108211318.f7LDI3c01321@hygro.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For NASREQ, MIPv4, and ROAMOPS we had drafts specifying the architecture/framework, as well as requirements for a solution. The access protocols (e.g. PPP, MIPv4) were also well specified. That meant that the AAA WG only had to interface AAA to an architecture and access protocol that was understood. This makes the job *much* easier. On Tue, 21 Aug 2001, Thomas Narten wrote: > Bernard, > > Can you clarify a bit on what sort of consensus draft you would want > out of a subject area WG. Would that be (for example) a problem > statement and a corresponding set of requirements, as opposed to a > particular solution? > > 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 Wed Aug 22 01:43:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7M8gl419653 for ipng-dist; Wed, 22 Aug 2001 01:42:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M8gim19646 for ; Wed, 22 Aug 2001 01:42:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA08718 for ; Wed, 22 Aug 2001 01:42:45 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA00959 for ; Wed, 22 Aug 2001 02:43:03 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7M8h8305808 for ; Wed, 22 Aug 2001 11:43:08 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 22 Aug 2001 11:42:36 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVY8HV>; Wed, 22 Aug 2001 11:41:43 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FDC@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, jarno.rajahalme@nokia.com Cc: seamus@bit-net.com, thomas.eklund@xelerated.com, aconta@txc.com, narten@raleigh.ibm.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Wed, 22 Aug 2001 11:41:30 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Let's then just say that it would be architecturally better to only have one format that satisfies all the needs. With better I mean things like less text in the specification, simpler implementations, less bugs, better interoperability etc. At this point no-one has established that there is a need or a requirement for multiple formats of flow labels. You and Alex have brought up a requirement that the flow label value needs to be somehow constant for the diffserv for a form of MF classification for diffserv usage. The traditional intserv has no requirement to the specific value being used, as the value is being explicitly signaled. It seems that both the old ("intserv") and new ("diffserv") requirements can be met with single flow label format (current format with no pseudo-random requirement). Earlier it has been thought that the pseudo-random nature of the flow label would make lookups easier by allowing the flow label to be used as a hash as such. There are some specific difficulties with this, however: 1) Routers can not know how good pseudo random numbers the flow-labels injected by hosts are in practice. Bad pseudo random numbers used by large class of hosts could constitute a kind of DoS attack against router implementations relying on the pseudo-random number nature of the flow label. [Maybe someone actually implementing look-ups on hardware based on the flow label could bring additional light on this matter (Alex?)] 2) If there is an alternative format, that is not pseudo-random (as being proposed), the routers will have to implement look-ups that function efficiently with that format. Since we do not know what portion of the traffic in the future would use this non-pseudo-random format, the implementations have to assume that all traffic can be labeled with this alternative format. It follows that there is no additional benefit of the pseudo-random nature of the original format. Therefore it would be best to combine these formats into one, that is non-pseudo-random. I.e. the current format with no pseudo-random requirement. This would present the minimal change to the current specification. Also, current (intserv) implementations could keep on using the current pseudo-random numbers without breaking anything. Jarno > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 21. elokuuta 2001 23:31 > To: jarno.rajahalme@nokia.com > Cc: seamus@bit-net.com; thomas.eklund@xelerated.com; aconta@txc.com; > narten@raleigh.ibm.com; hinden@iprg.nokia.com; > ipng@sunroof.eng.sun.com > Subject: Re: Higher level question about flow label > > > Jarno, > > The Carpenter/Conta proposal does include two formats for the > label (one aimed > at intserv flows and one aimed at diffserv flows), but if you > use the field > only for rapid routing lookup, you don't care about that; in > both cases you can treat > the label as 20 opaque bits I think. > > You only care which format it is when you are doing specific > intserv or diffserv > packet classification. > > Brian > > jarno.rajahalme@nokia.com wrote: > > > > Jim, > > > > Nice rant :-) > > > > Could you elaborate on the pseudo-random nature of the flow > label. It seems > > to me that if it did not need to be pseudo-random, people > could go on > > "signaling off-line" about the flow label values (in SLAs, > this seems to be > > what Alex & Brian want). I see no harm in allowing such > practice, but it > > would be best if there is only one format for the flow > label, as it would be > > faster to decode. > > > > Jarno > > > > > -----Original Message----- > > > From: ext Jim Bound [mailto:seamus@bit-net.com] > > > Sent: 21. elokuuta 2001 15:58 > > > To: Thomas Eklund > > > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob > Hinden; ipng > > > Subject: RE: Higher level question about flow label > > > > > > > > > thomas, > > > > > > that is why if we can treat the flowlabel as part of > tuple with src > > > address and identify a connection which identifies the > forwarding path > > > the challenge is reduced. there is nothing needed but the > > > header for the > > > look up and forward. I believe this can be made to work. > > > > > > the traffic class will provide diff serv metric and the flow > > > identifies > > > the E2E connection with the src addr. > > > > > > The src addr MUST be a global address. > > > > > > Site-Local can be done too but don't want to get into > that right now. > > > > > > One can ask if the Ipv6 address is global why have the > flow for per > > > connection as above. This is a good question and needs > discussion. > > > > > > First the flow assists with the lookup in a binary tree, > > > queue type, or > > > archaic hash. Its the hint to the next leaf, bucket, or > queue entry. > > > duplicat highorder bits would cause a branch. This could > speed up the > > > search before even getting to the global address. > > > > > > The src + flow could also be used as label for MPLS and its > > > in the IPv6 > > > header. > > > > > > The business reason could also be that end users would > create SLAs for > > > their flow labels in addition the bits set for the traffic > > > class. This is > > > how QOS Int Serv could be realized. And I guess conjunct > > > with diff serv > > > but that would need to be specified too. > > > > > > This also benefits client and server boxes too (gateways > > > too). We can now > > > potentially keep one protocol control block for user > connections. tcp, > > > sctp, and dcp per connection data structures would not > have to be kept > > > above the internet per connection datastructures (e.g. bsd > > > inpcb would be > > > enough). This is a performance win for clients and servers > > > for IPv6 not > > > just routers or switches or gateways. > > > > > > If we put a length in the flow yes it can be made to work but > > > not without > > > being verified by the router as the packet is parsed or > > > "policed" then we > > > have just put new processing far worse than the IP > checksum which we > > > removed from the IPv6 router. And opens up opportunity for > > > bugs at that > > > code point we don't have today. > > > > > > I also don't support the field being mutable as it transits > > > the network > > > path to the end destination. > > > > > > The reason is that we should make IPv6 E2E perform in the > > > network as fas > > > as possible. If you look at all the work to do VPN, L2TP, > > > NAT, Virtual > > > Routing, et al that is emerging pervasive for IPv4 the root > > > reasons are > > > lack of IPv4 address space, the desire to do fast layer 2 > > > switching, and > > > security inspection (e.g. firewalls). > > > > > > The later two above are the only valid visions. We need to > > > eliminate in > > > our thinking the mind set developed because of lack of IPv4 > > > address space. > > > I could argue that what is happening to IPv4 is pure professional > > > irresponsibility on our part as Internet engineers. The > > > Internet should > > > remain E2E. This is not a politcal comment or even social > > > comment. Its a > > > comment stating my assumptions about how the Internet > should operate. > > > > > > I think we need to discuss our assumptions for the > > > requirements with the > > > solutions we define. > > > > > > ADSL box providers actually market that NAT helps you because > > > you don't > > > have to worry about address space. This is absurd and > professionally > > > irresponsible in the market. We should stop this with IPv6. > > > > > > The way to do that is give routers the means to forward > packets E2E by > > > only looking at the header of IPv6. That is what Brian's > "b" solution > > > does. Plus it benefits all nodes besides routes for IPv6 > as I state > > > above. > > > > > > As far as IPv6 extensions. The payload length gives the > > > router the entire > > > length of the packet. If the flowlabel can be used to > > > identify forwarding > > > the packet in addition to the address and other parts as > I state above > > > then there is no challenge for ASIC vendors for strict > > > forwarding of IPv6 > > > packets. > > > > > > If those vendors want to add more value by digging past the > > > header then > > > that is their option to add value but I don't believe it is > > > required for > > > fast forwarding of IPv6 packets. > > > > > > Steve's design works and I believe can be extended with the > > > flowlabell and > > > we can get rid of the mess IPv4 is making of the Internet > > > because of the > > > band-aids being applied. > > > > > > I believe the End System (and that could be a router in some > > > cases or a > > > broker router) should set the flowlabel at the access > exit before the > > > edge. But thats another discussion. > > > > > > Another discussion is how do we pick good random numbers for > > > the flowlabel > > > at the access exit end system or even a client. > > > > > > regards, > > > /jim > > > > > > > > > On Tue, 21 Aug 2001, Thomas Eklund wrote: > > > > > > > I agree alex. > > > > > > > > It gets worse for people that are doing ASIC which is not > > > programmable, then > > > > they need to spin a new version their ASIC when the > > > protocols changes. For > > > > people that are doing programmable ASIC (network processors > > > etc) this is not > > > > a problem. > > > > > > > > But common for both approaches is that the header format is > > > really challenge > > > > for the ASIC engineers > > > > > > > > -- thomas > > > > > > > > >-----Original Message----- > > > > >From: Alex Conta [mailto:aconta@txc.com] > > > > >Sent: den 20 augusti 2001 22:15 > > > > >To: Thomas Narten > > > > >Cc: Brian E Carpenter; Bob Hinden; ipng > > > > >Subject: Re: Higher level question about flow label > > > > > > > > > > > > > > > > > > > > > > > > >Thomas Narten wrote: > > > > >> > > > > >> [...] When someone can make a compelling argument for why > > > > >> the bits need to be defined in a certain way (i.e., > > > there is a real > > > > >> application for which using the bits provides > > > significant benefits, > > > > >> and those benefits do not appear achievable through > > > other means) that > > > > >> is the time to define the bits. What I do sense with > many of the > > > > >> recent discussions surrounding the Flow Label is that > > > there are many > > > > >> folks (i.e., folks putting IPv6 into hardware) that want > > > to know what > > > > >> they should implement w.r.t. the Flow Label. While it would > > > > >be nice to > > > > >> be able tell them what to do, we shouldn't standardize > > > something just > > > > >> for the sake of having a definition. > > > > >> > > > > >> Thomas > > > > > > > > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per > byte, or 3.2 > > > > >instructions of a hypothetical > > > > >1Ghz processor which can execute one instruction per > > > cycle. That's a > > > > >hell of a requirement. > > > > > > > > > >As consumers, we all enjoy the very cost-effective > availability of > > > > >100Mb/sec line speed packet processing in almost every > > > > >Notebook, or PC. > > > > > > > > > >IP and QoS Engines implemented in silicon, on a chip or a > > > few chips, by > > > > >IBM, INTEL, and many, many others, is one of the > reasons of the low > > > > >costs, along with the ability to optimizing the hardware > > > > >in so many more and different ways than the software > (for instance > > > > >parallel header, or parallel header field processing). > > > > > > > > > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just > > > > >around the > > > > >corner, with 40Gb/sec following not long after. > > > > > > > > > >With such drastic "timing" requirements, implementing > engines in > > > > >silicon, and inventing *clever* mechanisms to handle > the sequential > > > > >processing of headers alone, will not be sufficient to > > > implement very > > > > >cost-effective IPv6 forwarding and QoS solutions, and > IPv6 is at a > > > > >disadvantage relative to IPv4. > > > > > > > > > >We need all the help we can get from the protocol, that is > > > headers, and > > > > >their fields, for forwarding and QoS processing, and by that I > > > > >mean both > > > > >Intserv, and Diffserv. > > > > > > > > > >Regards, > > > > >Alex > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 22 03:33:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MAWxF20144 for ipng-dist; Wed, 22 Aug 2001 03:32:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MAWtm20137 for ; Wed, 22 Aug 2001 03:32:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16941 for ; Wed, 22 Aug 2001 03:32:59 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02469 for ; Wed, 22 Aug 2001 04:32:54 -0600 (MDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA05549; Wed, 22 Aug 2001 11:32:56 +0100 (BST) Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA23497; Wed, 22 Aug 2001 11:32:54 +0100 (BST) Date: Wed, 22 Aug 2001 11:32:55 +0100 (BST) From: Tim Chown To: Alex Conta cc: ipng Subject: Re: Higher level question about flow label In-Reply-To: <3B82F1D5.6F9F63FB@txc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 21 Aug 2001, Alex Conta wrote: > at page 15, in the draft. "(c)" protects the value of the flow label, or > rather, its meaning, where it is relevant to protect it. > > That is because, the value in itself, alone, is not meaningful. It is > the meaning of the value, which is important, and as long as that > meaning is preserved, the value can change. But the only way to preserve the meaning - the fact that the combination of source address and flow label uniquely identifies the flow because the source host guarantees that each flow has a unique label - would be to restore the value to the orginal value previous to any munging/tunelling in the middle. If you alter the value, where do you store the original value? tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 22 04:02:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MB1k120221 for ipng-dist; Wed, 22 Aug 2001 04:01:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MB1fm20214 for ; Wed, 22 Aug 2001 04:01:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18502 for ; Wed, 22 Aug 2001 04:01:45 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24147 for ; Wed, 22 Aug 2001 04:01:45 -0700 (PDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA05781; Wed, 22 Aug 2001 12:01:43 +0100 (BST) Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA27789; Wed, 22 Aug 2001 12:01:40 +0100 (BST) Date: Wed, 22 Aug 2001 12:01:42 +0100 (BST) From: Tim Chown To: Jim Bound cc: ipng Subject: RE: Higher level question about flow label In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 21 Aug 2001, Jim Bound wrote: > the traffic class will provide diff serv metric and the flow identifies > the E2E connection with the src addr. My intuitive feeling is that if we leverage the end to end properties of IPv6 in the address space, then we should do likewise, end to end, for an identifier that allows recognition of unique flows, and thus keep the field immutable. > The src addr MUST be a global address. > Site-Local can be done too but don't want to get into that right now. We will want to recognise flows on site-level networks at some stage, so we shouldn't lock that out just yet. > One can ask if the Ipv6 address is global why have the flow for per > connection as above. This is a good question and needs discussion. If we adopt Francis' (reasonable) suggestion that the label can be written from a non-zero value only once, then it becomes much harder to assert that the src/label combination represents a unique flow on a fully end to end basis. Maybe in end-to-end H.323 to a handset you may want to prioritise the voice udp rtp flow over the video udp rtp flow, where the source IP is the same. I think it is quite possible that in the future we will see more systems where multiple flows will require different QoS handling and packet treatment per flow, so we should keep options open to enable that. You could use a different IPv6 source addresses for a similar purpose, but that probably adds more complexity (see how hard it is now to negotiate H.323 through a firewall). tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 22 06:37:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MDbBH20565 for ipng-dist; Wed, 22 Aug 2001 06:37:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MDb7m20558 for ; Wed, 22 Aug 2001 06:37:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16680 for ; Wed, 22 Aug 2001 06:37:08 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12060 for ; Wed, 22 Aug 2001 07:37:24 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7MDehG29776 for ; Wed, 22 Aug 2001 16:40:48 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 22 Aug 2001 16:36:56 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVZ3T7>; Wed, 22 Aug 2001 16:36:56 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D496@esebe004.NOE.Nokia.com> To: aboba@internaut.com, jarno.rajahalme@nokia.com Cc: thomas.eklund@xelerated.com, G.Tsirtsis@flarion.com, charliep@IPRG.nokia.com, aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com, Basavaraj.Patil@nokia.com, subir@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Wed, 22 Aug 2001 16:36:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bernard Aboba wrote: > > > > I think the URP WG should be chartered ASAP and AAAv6 taken > there as a > > possible solution. Where can I find the current proposal for the URP > > charter? > > > > Just as the AAA WG is not the appropriate place to do the > work of subject > area WGs, it is not appropriate for subject area WGs to design AAA > protocols. We have separate WGs so that subject matter experts can > congregate and focus on their area of expertise. So it would > be best for > URP to be handled in URP WG, AAA in AAA WG, and IPv6 in IPNG WG. > Well, I meant the part of the AAAv6 draft that is applicable to the URP scope. The protocol stuff in the draft is focused on the interface(s) between the host and an "attendant" node in the network, which clearly is not in the AAA WG scope. 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 Aug 22 07:43:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MEgu420798 for ipng-dist; Wed, 22 Aug 2001 07:42:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MEgqm20791 for ; Wed, 22 Aug 2001 07:42:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16030 for ; Wed, 22 Aug 2001 07:42:56 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAB06205 for ; Wed, 22 Aug 2001 08:42:51 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 10:42:52 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054796@ftmail> From: George Tsirtsis To: "'Bernard Aboba'" , Thomas Narten Cc: Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: RE: [AAA-WG]: AAA for IPv6 Date: Wed, 22 Aug 2001 10:42:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I wonder if people think that IPv6 introduces additional requirements to the AAA protocols (Radius/Diameter). My viewpoint is that a AAA protocol has to be able to do 2 things to be compatible with IPv6: 1. Use IPv6 for transport i.e.: a AAA client in an IPv6 Only or Dual Stack node to be able to communicate over IPv6 with a AAA server of similar configuration. Same requirements holds between AAA servers. 2. All the AVPs (or equivalent) in the AAA protocol that happen to include IP addresses should also support IPv6 addresses. e.g.: NASREQ related AVPs should work for both IPv4 and IPv6 end nodes. Both of the above are I hope already taken care of. Now, the question is, are there new AVPs or other requirements that IPv6 introduces with no IPv4 equivalents? If there are then I will have to agree with Bernard that other WGs should define these requirements before they are taken up by AAA WG. So, extensions to DHCPv6 for end node credentials should be defined in DHC WG, and a URP carrier for these purpose should be defined in URP WG...any new requirements to AAA that might come up from that may then be fed back to AAA WG for consideration. Regards George -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Wednesday, August 22, 2001 7:07 AM To: Thomas Narten Cc: Charlie Perkins; aaa-wg@merit.edu; john.loughney@nokia.com; ipng@sunroof.eng.sun.com; urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 For NASREQ, MIPv4, and ROAMOPS we had drafts specifying the architecture/framework, as well as requirements for a solution. The access protocols (e.g. PPP, MIPv4) were also well specified. That meant that the AAA WG only had to interface AAA to an architecture and access protocol that was understood. This makes the job *much* easier. On Tue, 21 Aug 2001, Thomas Narten wrote: > Bernard, > > Can you clarify a bit on what sort of consensus draft you would want > out of a subject area WG. Would that be (for example) a problem > statement and a corresponding set of requirements, as opposed to a > particular solution? > > 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 Wed Aug 22 07:50:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MEnrY20854 for ipng-dist; Wed, 22 Aug 2001 07:49:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MEnnm20847 for ; Wed, 22 Aug 2001 07:49:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17194 for ; Wed, 22 Aug 2001 07:49:52 -0700 (PDT) Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA24670 for ; Wed, 22 Aug 2001 08:50:11 -0600 (MDT) Received: (qmail 14760 invoked by uid 500); 22 Aug 2001 14:37:47 -0000 Date: Wed, 22 Aug 2001 07:37:46 -0700 From: Pat Calhoun To: Bernard Aboba Cc: Thomas Narten , Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com Subject: Re: [AAA-WG]: AAA for IPv6 Message-ID: <20010822073746.B14728@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , Thomas Narten , Charlie Perkins , aaa-wg@merit.edu, john.loughney@nokia.com, ipng@sunroof.eng.sun.com, urp@research.telcordia.com References: <200108211318.f7LDI3c01321@hygro.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Tue, Aug 21, 2001 at 11:07:00PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Although I do agree with Bernard on some points, I believe that waiting for MIPv6 to be RFCed may be too late. The issue is that many folks will need an AAA infrastructure to deploy MIPv6, and waiting for the RFC will simply push out MIPv6 deployments. The issues with MIPv6 are mostly in the security area (specifically in binding updates), and we can simply not specify any AAA interactions for binding updates until a later time). Personally, I think we should begin the work once our current specs are out of our hands. my 2 cents, PatC On Tue, Aug 21, 2001 at 11:07:00PM -0700, Bernard Aboba wrote: > For NASREQ, MIPv4, and ROAMOPS we had drafts specifying the > architecture/framework, as well as requirements for a solution. > The access protocols (e.g. PPP, MIPv4) were also well specified. > That meant that the AAA WG only had to interface AAA to an architecture > and access protocol that was understood. This makes the job *much* easier. > > On Tue, 21 Aug 2001, Thomas Narten wrote: > > > Bernard, > > > > Can you clarify a bit on what sort of consensus draft you would want > > out of a subject area WG. Would that be (for example) a problem > > statement and a corresponding set of requirements, as opposed to a > > particular solution? > > > > 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 Wed Aug 22 08:13:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MFCw921026 for ipng-dist; Wed, 22 Aug 2001 08:12:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MFCtm21019 for ; Wed, 22 Aug 2001 08:12:55 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21107 for ; Wed, 22 Aug 2001 08:12:59 -0700 (PDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19164 for ; Wed, 22 Aug 2001 08:12:58 -0700 (PDT) Received: from xparelay1.corp.hp.com (unknown [15.58.136.173]) by palrel1.hp.com (Postfix) with ESMTP id ABFE510F9 for ; Wed, 22 Aug 2001 08:12:56 -0700 (PDT) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 5F9521F507 for ; Wed, 22 Aug 2001 08:12:56 -0700 (PDT) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 Aug 2001 08:12:56 -0700 Message-ID: From: "MANDAVILLI,SWAMY J (HP-FtCollins,ex1)" To: "'ipng@sunroof.eng.sun.com'" Subject: Layer II for IPv6 vs. IPv4 networks Date: Wed, 22 Aug 2001 08:12:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! Are there any differences between IPv6 networks and IPv4 networks with respect to Layer II (i.e., vlans etc.)? I would appreciate your help. Thanks in advance! Regards, Swamy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 22 12:57:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MJuOQ21865 for ipng-dist; Wed, 22 Aug 2001 12:56:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MJuLm21858 for ; Wed, 22 Aug 2001 12:56:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25876 for ; Wed, 22 Aug 2001 12:56:25 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06418 for ; Wed, 22 Aug 2001 13:56:20 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA15996; Wed, 22 Aug 2001 20:56:22 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA18870; Wed, 22 Aug 2001 20:56:22 +0100 Message-ID: <3B840BEB.4162E8A@hursley.ibm.com> Date: Wed, 22 Aug 2001 14:45:47 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: "''ipng ' '" Subject: Re: Higher level question about flow label References: <31A473DBB655D21180850008C71E251A04ECA9B6@mail.kebne.se> <3B82BF62.886F3EF8@hursley.ibm.com> <15234.49245.24268.283937@thomasm-u1.cisco.com> <3B82D204.66CE4372@hursley.ibm.com> <15234.51358.518560.857445@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: > > Brian E Carpenter writes: > > The point is that when a packet crosses an administrative domain boundary, > > the downstream ISP typically wants to reclassify the packet all over again, > > i.e. does not accept the incoming DSCP as definitive. This was a very > > clearly stated ISP requirement at the start of diffserv and is fundamental > > in the diffserv architecture. > > Oh. I now see what I missed. Why doesn't including > the SPI into the flow key work? You wouldn't be > able to police based on port numbers (ie try to be > a firewall), but some would say that's a feature > not a bug. That probably depends on your degree of paranoia about traffic analysis :-) The SPI is certainly a possible way to identify a flow, but it doesn't help you decide whether that flow needs real time or best effort service. 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 Aug 22 13:05:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MK5Hp21890 for ipng-dist; Wed, 22 Aug 2001 13:05:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MK5Em21883 for ; Wed, 22 Aug 2001 13:05:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20843 for ; Wed, 22 Aug 2001 13:05:11 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13744 for ; Wed, 22 Aug 2001 14:05:06 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA05140; Wed, 22 Aug 2001 21:05:07 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA38864; Wed, 22 Aug 2001 21:05:07 +0100 Message-ID: <3B840DE5.9D4C7CDB@hursley.ibm.com> Date: Wed, 22 Aug 2001 14:54:13 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757197FDC@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I certainly don't care about the pseudo-random requirement for unique-per-host opaque flow labels, but if we agree that the flow label may be used for diffserv then it has to have semantics (i.e. it is not an opaque value). For that I am sure we need the MSB as a flag bit, so that a classifier can tell whether it is looking at an opaque value or at a value with semantics. Brian jarno.rajahalme@nokia.com wrote: > > Brian, > > Let's then just say that it would be architecturally better to only have one > format that satisfies all the needs. With better I mean things like less > text in the specification, simpler implementations, less bugs, better > interoperability etc. > > At this point no-one has established that there is a need or a requirement > for multiple formats of flow labels. You and Alex have brought up a > requirement that the flow label value needs to be somehow constant for the > diffserv for a form of MF classification for diffserv usage. The traditional > intserv has no requirement to the specific value being used, as the value is > being explicitly signaled. > > It seems that both the old ("intserv") and new ("diffserv") requirements can > be met with single flow label format (current format with no pseudo-random > requirement). > > Earlier it has been thought that the pseudo-random nature of the flow label > would make lookups easier by allowing the flow label to be used as a hash as > such. There are some specific difficulties with this, however: > > 1) Routers can not know how good pseudo random numbers the flow-labels > injected by hosts are in practice. Bad pseudo random numbers used by large > class of hosts could constitute a kind of DoS attack against router > implementations relying on the pseudo-random number nature of the flow > label. [Maybe someone actually implementing look-ups on hardware based on > the flow label could bring additional light on this matter (Alex?)] > > 2) If there is an alternative format, that is not pseudo-random (as being > proposed), the routers will have to implement look-ups that function > efficiently with that format. Since we do not know what portion of the > traffic in the future would use this non-pseudo-random format, the > implementations have to assume that all traffic can be labeled with this > alternative format. > > It follows that there is no additional benefit of the pseudo-random nature > of the original format. Therefore it would be best to combine these formats > into one, that is non-pseudo-random. I.e. the current format with no > pseudo-random requirement. This would present the minimal change to the > current specification. Also, current (intserv) implementations could keep on > using the current pseudo-random numbers without breaking anything. > > Jarno > > > -----Original Message----- > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: 21. elokuuta 2001 23:31 > > To: jarno.rajahalme@nokia.com > > Cc: seamus@bit-net.com; thomas.eklund@xelerated.com; aconta@txc.com; > > narten@raleigh.ibm.com; hinden@iprg.nokia.com; > > ipng@sunroof.eng.sun.com > > Subject: Re: Higher level question about flow label > > > > > > Jarno, > > > > The Carpenter/Conta proposal does include two formats for the > > label (one aimed > > at intserv flows and one aimed at diffserv flows), but if you > > use the field > > only for rapid routing lookup, you don't care about that; in > > both cases you can treat > > the label as 20 opaque bits I think. > > > > You only care which format it is when you are doing specific > > intserv or diffserv > > packet classification. > > > > Brian > > > > jarno.rajahalme@nokia.com wrote: > > > > > > Jim, > > > > > > Nice rant :-) > > > > > > Could you elaborate on the pseudo-random nature of the flow > > label. It seems > > > to me that if it did not need to be pseudo-random, people > > could go on > > > "signaling off-line" about the flow label values (in SLAs, > > this seems to be > > > what Alex & Brian want). I see no harm in allowing such > > practice, but it > > > would be best if there is only one format for the flow > > label, as it would be > > > faster to decode. > > > > > > Jarno > > > > > > > -----Original Message----- > > > > From: ext Jim Bound [mailto:seamus@bit-net.com] > > > > Sent: 21. elokuuta 2001 15:58 > > > > To: Thomas Eklund > > > > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob > > Hinden; ipng > > > > Subject: RE: Higher level question about flow label > > > > > > > > > > > > thomas, > > > > > > > > that is why if we can treat the flowlabel as part of > > tuple with src > > > > address and identify a connection which identifies the > > forwarding path > > > > the challenge is reduced. there is nothing needed but the > > > > header for the > > > > look up and forward. I believe this can be made to work. > > > > > > > > the traffic class will provide diff serv metric and the flow > > > > identifies > > > > the E2E connection with the src addr. > > > > > > > > The src addr MUST be a global address. > > > > > > > > Site-Local can be done too but don't want to get into > > that right now. > > > > > > > > One can ask if the Ipv6 address is global why have the > > flow for per > > > > connection as above. This is a good question and needs > > discussion. > > > > > > > > First the flow assists with the lookup in a binary tree, > > > > queue type, or > > > > archaic hash. Its the hint to the next leaf, bucket, or > > queue entry. > > > > duplicat highorder bits would cause a branch. This could > > speed up the > > > > search before even getting to the global address. > > > > > > > > The src + flow could also be used as label for MPLS and its > > > > in the IPv6 > > > > header. > > > > > > > > The business reason could also be that end users would > > create SLAs for > > > > their flow labels in addition the bits set for the traffic > > > > class. This is > > > > how QOS Int Serv could be realized. And I guess conjunct > > > > with diff serv > > > > but that would need to be specified too. > > > > > > > > This also benefits client and server boxes too (gateways > > > > too). We can now > > > > potentially keep one protocol control block for user > > connections. tcp, > > > > sctp, and dcp per connection data structures would not > > have to be kept > > > > above the internet per connection datastructures (e.g. bsd > > > > inpcb would be > > > > enough). This is a performance win for clients and servers > > > > for IPv6 not > > > > just routers or switches or gateways. > > > > > > > > If we put a length in the flow yes it can be made to work but > > > > not without > > > > being verified by the router as the packet is parsed or > > > > "policed" then we > > > > have just put new processing far worse than the IP > > checksum which we > > > > removed from the IPv6 router. And opens up opportunity for > > > > bugs at that > > > > code point we don't have today. > > > > > > > > I also don't support the field being mutable as it transits > > > > the network > > > > path to the end destination. > > > > > > > > The reason is that we should make IPv6 E2E perform in the > > > > network as fas > > > > as possible. If you look at all the work to do VPN, L2TP, > > > > NAT, Virtual > > > > Routing, et al that is emerging pervasive for IPv4 the root > > > > reasons are > > > > lack of IPv4 address space, the desire to do fast layer 2 > > > > switching, and > > > > security inspection (e.g. firewalls). > > > > > > > > The later two above are the only valid visions. We need to > > > > eliminate in > > > > our thinking the mind set developed because of lack of IPv4 > > > > address space. > > > > I could argue that what is happening to IPv4 is pure professional > > > > irresponsibility on our part as Internet engineers. The > > > > Internet should > > > > remain E2E. This is not a politcal comment or even social > > > > comment. Its a > > > > comment stating my assumptions about how the Internet > > should operate. > > > > > > > > I think we need to discuss our assumptions for the > > > > requirements with the > > > > solutions we define. > > > > > > > > ADSL box providers actually market that NAT helps you because > > > > you don't > > > > have to worry about address space. This is absurd and > > professionally > > > > irresponsible in the market. We should stop this with IPv6. > > > > > > > > The way to do that is give routers the means to forward > > packets E2E by > > > > only looking at the header of IPv6. That is what Brian's > > "b" solution > > > > does. Plus it benefits all nodes besides routes for IPv6 > > as I state > > > > above. > > > > > > > > As far as IPv6 extensions. The payload length gives the > > > > router the entire > > > > length of the packet. If the flowlabel can be used to > > > > identify forwarding > > > > the packet in addition to the address and other parts as > > I state above > > > > then there is no challenge for ASIC vendors for strict > > > > forwarding of IPv6 > > > > packets. > > > > > > > > If those vendors want to add more value by digging past the > > > > header then > > > > that is their option to add value but I don't believe it is > > > > required for > > > > fast forwarding of IPv6 packets. > > > > > > > > Steve's design works and I believe can be extended with the > > > > flowlabell and > > > > we can get rid of the mess IPv4 is making of the Internet > > > > because of the > > > > band-aids being applied. > > > > > > > > I believe the End System (and that could be a router in some > > > > cases or a > > > > broker router) should set the flowlabel at the access > > exit before the > > > > edge. But thats another discussion. > > > > > > > > Another discussion is how do we pick good random numbers for > > > > the flowlabel > > > > at the access exit end system or even a client. > > > > > > > > regards, > > > > /jim > > > > > > > > > > > > On Tue, 21 Aug 2001, Thomas Eklund wrote: > > > > > > > > > I agree alex. > > > > > > > > > > It gets worse for people that are doing ASIC which is not > > > > programmable, then > > > > > they need to spin a new version their ASIC when the > > > > protocols changes. For > > > > > people that are doing programmable ASIC (network processors > > > > etc) this is not > > > > > a problem. > > > > > > > > > > But common for both approaches is that the header format is > > > > really challenge > > > > > for the ASIC engineers > > > > > > > > > > -- thomas > > > > > > > > > > >-----Original Message----- > > > > > >From: Alex Conta [mailto:aconta@txc.com] > > > > > >Sent: den 20 augusti 2001 22:15 > > > > > >To: Thomas Narten > > > > > >Cc: Brian E Carpenter; Bob Hinden; ipng > > > > > >Subject: Re: Higher level question about flow label > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Thomas Narten wrote: > > > > > >> > > > > > >> [...] When someone can make a compelling argument for why > > > > > >> the bits need to be defined in a certain way (i.e., > > > > there is a real > > > > > >> application for which using the bits provides > > > > significant benefits, > > > > > >> and those benefits do not appear achievable through > > > > other means) that > > > > > >> is the time to define the bits. What I do sense with > > many of the > > > > > >> recent discussions surrounding the Flow Label is that > > > > there are many > > > > > >> folks (i.e., folks putting IPv6 into hardware) that want > > > > to know what > > > > > >> they should implement w.r.t. the Flow Label. While it would > > > > > >be nice to > > > > > >> be able tell them what to do, we shouldn't standardize > > > > something just > > > > > >> for the sake of having a definition. > > > > > >> > > > > > >> Thomas > > > > > > > > > > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per > > byte, or 3.2 > > > > > >instructions of a hypothetical > > > > > >1Ghz processor which can execute one instruction per > > > > cycle. That's a > > > > > >hell of a requirement. > > > > > > > > > > > >As consumers, we all enjoy the very cost-effective > > availability of > > > > > >100Mb/sec line speed packet processing in almost every > > > > > >Notebook, or PC. > > > > > > > > > > > >IP and QoS Engines implemented in silicon, on a chip or a > > > > few chips, by > > > > > >IBM, INTEL, and many, many others, is one of the > > reasons of the low > > > > > >costs, along with the ability to optimizing the hardware > > > > > >in so many more and different ways than the software > > (for instance > > > > > >parallel header, or parallel header field processing). > > > > > > > > > > > >1Gb/sec IPv4 packet forwarding is a reality, 10Gb/sec is just > > > > > >around the > > > > > >corner, with 40Gb/sec following not long after. > > > > > > > > > > > >With such drastic "timing" requirements, implementing > > engines in > > > > > >silicon, and inventing *clever* mechanisms to handle > > the sequential > > > > > >processing of headers alone, will not be sufficient to > > > > implement very > > > > > >cost-effective IPv6 forwarding and QoS solutions, and > > IPv6 is at a > > > > > >disadvantage relative to IPv4. > > > > > > > > > > > >We need all the help we can get from the protocol, that is > > > > headers, and > > > > > >their fields, for forwarding and QoS processing, and by that I > > > > > >mean both > > > > > >Intserv, and Diffserv. > > > > > > > > > > > >Regards, > > > > > >Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 22 13:20:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MKJM521929 for ipng-dist; Wed, 22 Aug 2001 13:19:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MKJIm21922 for ; Wed, 22 Aug 2001 13:19:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23366 for ; Wed, 22 Aug 2001 13:19:23 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24931 for ; Wed, 22 Aug 2001 14:19:18 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7MKJk313624 for ; Wed, 22 Aug 2001 23:19:46 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 22 Aug 2001 23:19:21 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVZTLY>; Wed, 22 Aug 2001 23:19:21 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FDE@esebe004.NOE.Nokia.com> To: dfawcus@cisco.com, brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Wed, 22 Aug 2001 23:19:16 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Derek Fawcus wrote: > > > 2) If there is an alternative format, that is not pseudo-random (as being > > proposed), the routers will have to implement look-ups that function > > efficiently with that format. Since we do not know what portion of the > > traffic in the future would use this non-pseudo-random format, the > > implementations have to assume that all traffic can be labeled with this > > alternative format. > > Lookups only occur when a QoS type funtion is applied to the flow label, > say we've been told about a flow by RSVP. In this case a PRN still helps > since we can reduce the cost of lookups by hashing on the flow label to > pick a subset of flows before doing a search/comparison. > > But then if the flow lable was a PRN, we'd simply skip the hash and use > some of it's bits as a hash bucket index, before jumping to the search > and comparision phase. > There is specific proposal on the table , that proposes changing the current IPv6 flow label specification to add a non-pseudo-random-number format in addition to the existing format. In my message I noted that if this is done, implementations (HW or SW) will need to be able to look up on the basis of both formats, which led me to think that a single format fulfilling all the requirements might be better. Also, as currently defined, most packets are sent out with flow label value 0x00000, which makes it particularly bad field for a generic route distribution hash. Now, if some portion of the non-zero flow label values are going to be non-random, what is the value of having the rest of them to be pseudo-random, especially if it is unknown what the distribution between the random and non-random formats is? If the pseudo-random nature of the current flow label specification is very important and cannot be changed because of router (HW) implementation issues (of which I do not really know much), then the proposal in the draft cannot be supported at all. On the other hand, if the pseudo-random number nature of the flow label is not that important, why keep it? If it is deemed that the flow label shall support the route distribution for load balancing then each flow should be assigned a flow label value independent of the flow QoS requirement (i.e. the default flow label value should not be used at all). Even then the pseudo-random number requirement seems too strong, as usage of a simple incremental value (+1 for each new flow) would seem to result in balanced distribution as well. 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 Aug 22 13:36:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MKZb921992 for ipng-dist; Wed, 22 Aug 2001 13:35:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MKZYm21985 for ; Wed, 22 Aug 2001 13:35:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02087 for ; Wed, 22 Aug 2001 13:35:39 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25661 for ; Wed, 22 Aug 2001 13:35:38 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA25282; Wed, 22 Aug 2001 21:35:35 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA39384; Wed, 22 Aug 2001 21:35:33 +0100 Message-ID: <3B8414BB.7D6080F5@hursley.ibm.com> Date: Wed, 22 Aug 2001 15:23:23 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Derek Fawcus CC: jarno.rajahalme@nokia.com, ipng Subject: Re: Higher level question about flow label References: <3B7BCE71.BE8DB82E@hursley.ibm.com> <20010822184638.A995@dfawcus-gw-home.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Derek Fawcus wrote: > > On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote: > > I think the WG needs to decide once and for all whether the flow label is > > a) a CATNIP or MPLS-like routing handle > > or b) a QOS hint for intserv only > > or c) a QOS hint for intserv and diffserv > > or d) a waste of bits > > > > We can get back to the details once we have a consensus on this. > > I'd suggest e) A flow identifier for router optimisation. > > I sort of see this as a variation of b), i.e. it identifies a flow using > a PRN but does not imply any QoS usage. However it doesn't preclude the > flow label being used in scenario b). > > Specifically - I see it as a way of replacing the srcPort/dstPort tuple > that routers peek at in the TCP/UDP header. Currently I only see this > being used in one scenario, that is for load balancing across multiple > paths. Can't parse. By "currently I only see" do you mean -- this is what I see happening in the real world today or -- this is what I envisage for the future ? The fact is that port numbers are used for both intserv and diffserv classifucation, and this won't go away. > > At the moment (for v4) if a lookup on the dst address address leads to > a route with multiple paths, and the route is appropriatly marked, > the flows of packets can be shared across these multiple paths. This > is done (for min size IPv4 headers, carrying TCP or UDP) by hashing > the srcIP/dstIP/srcPort/dstPort and using this to help choose which > path to forward the packet over. Yes, such hacks are not unknown. I don't think we should endorse this sort of thing in the design of the IPv6 header. > > Given that for IPv6 we can't guarentee the TCP/UDP header is at any > given offset, or even that it's readable. One would need some other > way of identifying flows if the above load balancing was to be performed. > > For v6 a core router engine (either s/w path, or ASIC [as fix logic > or programable device as someone suggested]) one will not be looking > beyond the base IPv6 header. For an edge rouer engine, one may well > be looking inside the packet for say classification. > > Hence use the flowID. Without this we could only hash based upon the > srcIP/dstIP and hence all flows between a given src/dst pair will hit > the same path. > > With this info in the flow label, one would be able to hash together > the srcIP/flowLabel to find the correct path. As a router in this > situation one would always have to combine the src IP address, but > if the flow label was defined to uniquely distinguish a given > dstIP/srcPort/dstPort flow, one could skip compining the dstIP at > the router. > > The reason for specifying that it be a PRN is simply to make the hashing > cheaper at the router. > > I said above that this doesn't preclude using the flow label for scenario > b), this can be achieved simply by picking a PRN for scenario b) from > the same number pool as for scenario e). Thus if intserv QoS is being > used, a (set of) routers would have been informed (via RSVP) > about the relationship between that flow label and certain QoS > requirements, any other routers in the path of the packet flow that > don't know about intserv/RSVP will simply treat packets in the flow as > scenario e). Unfortunately your suggestion does preclude diffserv classification for encrypted traffic. Since it's also in support of a hack, I'm against it. > > So the usage becomes one that is (potentially) orthogonal to QoS. It > will be usable for non QoS'ed (intserv or diffserv) packets, as well > as with both intserv and diffserv. No, it is of no value for diffserv. The only way the flow label can be of use to diffserv is if it has semantics. 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 Aug 22 13:42:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MKfk222034 for ipng-dist; Wed, 22 Aug 2001 13:41:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MKfhm22027 for ; Wed, 22 Aug 2001 13:41:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28336 for ; Wed, 22 Aug 2001 13:41:48 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10093 for ; Wed, 22 Aug 2001 14:42:04 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7MKg8316909 for ; Wed, 22 Aug 2001 23:42:08 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 22 Aug 2001 23:41:36 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVZTNW>; Wed, 22 Aug 2001 23:41:36 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FDF@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Wed, 22 Aug 2001 23:41:31 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Current (intserv) usage requires signaling to convey the semantics for the opaque flow label values. The diffserv usage would allow the flow label itself to function as a pointer to the semantics (taken out of configuration file or equivalent). In both cases the classifier will most likely do same kind of a search on the flow label, but the population of the data found for the matching entry is different (configuration vs. signaling). Also, an source knowing about well known values would know not to use those values for opaque ones. Additionally, it might not be harmful even if it would be possible to signal a specific (overloaded) semantics for a "well known" flow label (for a specific source). I'm assuming here that the only difference between the two cases being discussed (from the classification point-of-view) is that for the intserv case the same flow label value would carry the same semantics for all possible sources, while the semantics for the opaque values are specific to the source IP address. Jarno > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 22. elokuuta 2001 22:54 > To: Rajahalme Jarno (NRC/Helsinki) > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Higher level question about flow label > > > I certainly don't care about the pseudo-random requirement > for unique-per-host > opaque flow labels, but if we agree that the flow label may > be used for diffserv > then it has to have semantics (i.e. it is not an opaque > value). For that I am sure > we need the MSB as a flag bit, so that a classifier can tell > whether it is looking > at an opaque value or at a value with semantics. > > Brian > > jarno.rajahalme@nokia.com wrote: > > > > Brian, > > > > Let's then just say that it would be architecturally better > to only have one > > format that satisfies all the needs. With better I mean > things like less > > text in the specification, simpler implementations, less > bugs, better > > interoperability etc. > > > > At this point no-one has established that there is a need > or a requirement > > for multiple formats of flow labels. You and Alex have brought up a > > requirement that the flow label value needs to be somehow > constant for the > > diffserv for a form of MF classification for diffserv > usage. The traditional > > intserv has no requirement to the specific value being > used, as the value is > > being explicitly signaled. > > > > It seems that both the old ("intserv") and new ("diffserv") > requirements can > > be met with single flow label format (current format with > no pseudo-random > > requirement). > > > > Earlier it has been thought that the pseudo-random nature > of the flow label > > would make lookups easier by allowing the flow label to be > used as a hash as > > such. There are some specific difficulties with this, however: > > > > 1) Routers can not know how good pseudo random numbers the > flow-labels > > injected by hosts are in practice. Bad pseudo random > numbers used by large > > class of hosts could constitute a kind of DoS attack against router > > implementations relying on the pseudo-random number nature > of the flow > > label. [Maybe someone actually implementing look-ups on > hardware based on > > the flow label could bring additional light on this matter (Alex?)] > > > > 2) If there is an alternative format, that is not > pseudo-random (as being > > proposed), the routers will have to implement look-ups that function > > efficiently with that format. Since we do not know what > portion of the > > traffic in the future would use this non-pseudo-random format, the > > implementations have to assume that all traffic can be > labeled with this > > alternative format. > > > > It follows that there is no additional benefit of the > pseudo-random nature > > of the original format. Therefore it would be best to > combine these formats > > into one, that is non-pseudo-random. I.e. the current format with no > > pseudo-random requirement. This would present the minimal > change to the > > current specification. Also, current (intserv) > implementations could keep on > > using the current pseudo-random numbers without breaking anything. > > > > Jarno > > > > > -----Original Message----- > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: 21. elokuuta 2001 23:31 > > > To: jarno.rajahalme@nokia.com > > > Cc: seamus@bit-net.com; thomas.eklund@xelerated.com; > aconta@txc.com; > > > narten@raleigh.ibm.com; hinden@iprg.nokia.com; > > > ipng@sunroof.eng.sun.com > > > Subject: Re: Higher level question about flow label > > > > > > > > > Jarno, > > > > > > The Carpenter/Conta proposal does include two formats for the > > > label (one aimed > > > at intserv flows and one aimed at diffserv flows), but if you > > > use the field > > > only for rapid routing lookup, you don't care about that; in > > > both cases you can treat > > > the label as 20 opaque bits I think. > > > > > > You only care which format it is when you are doing specific > > > intserv or diffserv > > > packet classification. > > > > > > Brian > > > > > > jarno.rajahalme@nokia.com wrote: > > > > > > > > Jim, > > > > > > > > Nice rant :-) > > > > > > > > Could you elaborate on the pseudo-random nature of the flow > > > label. It seems > > > > to me that if it did not need to be pseudo-random, people > > > could go on > > > > "signaling off-line" about the flow label values (in SLAs, > > > this seems to be > > > > what Alex & Brian want). I see no harm in allowing such > > > practice, but it > > > > would be best if there is only one format for the flow > > > label, as it would be > > > > faster to decode. > > > > > > > > Jarno > > > > > > > > > -----Original Message----- > > > > > From: ext Jim Bound [mailto:seamus@bit-net.com] > > > > > Sent: 21. elokuuta 2001 15:58 > > > > > To: Thomas Eklund > > > > > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob > > > Hinden; ipng > > > > > Subject: RE: Higher level question about flow label > > > > > > > > > > > > > > > thomas, > > > > > > > > > > that is why if we can treat the flowlabel as part of > > > tuple with src > > > > > address and identify a connection which identifies the > > > forwarding path > > > > > the challenge is reduced. there is nothing needed but the > > > > > header for the > > > > > look up and forward. I believe this can be made to work. > > > > > > > > > > the traffic class will provide diff serv metric and the flow > > > > > identifies > > > > > the E2E connection with the src addr. > > > > > > > > > > The src addr MUST be a global address. > > > > > > > > > > Site-Local can be done too but don't want to get into > > > that right now. > > > > > > > > > > One can ask if the Ipv6 address is global why have the > > > flow for per > > > > > connection as above. This is a good question and needs > > > discussion. > > > > > > > > > > First the flow assists with the lookup in a binary tree, > > > > > queue type, or > > > > > archaic hash. Its the hint to the next leaf, bucket, or > > > queue entry. > > > > > duplicat highorder bits would cause a branch. This could > > > speed up the > > > > > search before even getting to the global address. > > > > > > > > > > The src + flow could also be used as label for MPLS and its > > > > > in the IPv6 > > > > > header. > > > > > > > > > > The business reason could also be that end users would > > > create SLAs for > > > > > their flow labels in addition the bits set for the traffic > > > > > class. This is > > > > > how QOS Int Serv could be realized. And I guess conjunct > > > > > with diff serv > > > > > but that would need to be specified too. > > > > > > > > > > This also benefits client and server boxes too (gateways > > > > > too). We can now > > > > > potentially keep one protocol control block for user > > > connections. tcp, > > > > > sctp, and dcp per connection data structures would not > > > have to be kept > > > > > above the internet per connection datastructures (e.g. bsd > > > > > inpcb would be > > > > > enough). This is a performance win for clients and servers > > > > > for IPv6 not > > > > > just routers or switches or gateways. > > > > > > > > > > If we put a length in the flow yes it can be made to work but > > > > > not without > > > > > being verified by the router as the packet is parsed or > > > > > "policed" then we > > > > > have just put new processing far worse than the IP > > > checksum which we > > > > > removed from the IPv6 router. And opens up opportunity for > > > > > bugs at that > > > > > code point we don't have today. > > > > > > > > > > I also don't support the field being mutable as it transits > > > > > the network > > > > > path to the end destination. > > > > > > > > > > The reason is that we should make IPv6 E2E perform in the > > > > > network as fas > > > > > as possible. If you look at all the work to do VPN, L2TP, > > > > > NAT, Virtual > > > > > Routing, et al that is emerging pervasive for IPv4 the root > > > > > reasons are > > > > > lack of IPv4 address space, the desire to do fast layer 2 > > > > > switching, and > > > > > security inspection (e.g. firewalls). > > > > > > > > > > The later two above are the only valid visions. We need to > > > > > eliminate in > > > > > our thinking the mind set developed because of lack of IPv4 > > > > > address space. > > > > > I could argue that what is happening to IPv4 is pure > professional > > > > > irresponsibility on our part as Internet engineers. The > > > > > Internet should > > > > > remain E2E. This is not a politcal comment or even social > > > > > comment. Its a > > > > > comment stating my assumptions about how the Internet > > > should operate. > > > > > > > > > > I think we need to discuss our assumptions for the > > > > > requirements with the > > > > > solutions we define. > > > > > > > > > > ADSL box providers actually market that NAT helps you because > > > > > you don't > > > > > have to worry about address space. This is absurd and > > > professionally > > > > > irresponsible in the market. We should stop this with IPv6. > > > > > > > > > > The way to do that is give routers the means to forward > > > packets E2E by > > > > > only looking at the header of IPv6. That is what Brian's > > > "b" solution > > > > > does. Plus it benefits all nodes besides routes for IPv6 > > > as I state > > > > > above. > > > > > > > > > > As far as IPv6 extensions. The payload length gives the > > > > > router the entire > > > > > length of the packet. If the flowlabel can be used to > > > > > identify forwarding > > > > > the packet in addition to the address and other parts as > > > I state above > > > > > then there is no challenge for ASIC vendors for strict > > > > > forwarding of IPv6 > > > > > packets. > > > > > > > > > > If those vendors want to add more value by digging past the > > > > > header then > > > > > that is their option to add value but I don't believe it is > > > > > required for > > > > > fast forwarding of IPv6 packets. > > > > > > > > > > Steve's design works and I believe can be extended with the > > > > > flowlabell and > > > > > we can get rid of the mess IPv4 is making of the Internet > > > > > because of the > > > > > band-aids being applied. > > > > > > > > > > I believe the End System (and that could be a router in some > > > > > cases or a > > > > > broker router) should set the flowlabel at the access > > > exit before the > > > > > edge. But thats another discussion. > > > > > > > > > > Another discussion is how do we pick good random numbers for > > > > > the flowlabel > > > > > at the access exit end system or even a client. > > > > > > > > > > regards, > > > > > /jim > > > > > > > > > > > > > > > On Tue, 21 Aug 2001, Thomas Eklund wrote: > > > > > > > > > > > I agree alex. > > > > > > > > > > > > It gets worse for people that are doing ASIC which is not > > > > > programmable, then > > > > > > they need to spin a new version their ASIC when the > > > > > protocols changes. For > > > > > > people that are doing programmable ASIC (network processors > > > > > etc) this is not > > > > > > a problem. > > > > > > > > > > > > But common for both approaches is that the header format is > > > > > really challenge > > > > > > for the ASIC engineers > > > > > > > > > > > > -- thomas > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Alex Conta [mailto:aconta@txc.com] > > > > > > >Sent: den 20 augusti 2001 22:15 > > > > > > >To: Thomas Narten > > > > > > >Cc: Brian E Carpenter; Bob Hinden; ipng > > > > > > >Subject: Re: Higher level question about flow label > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Thomas Narten wrote: > > > > > > >> > > > > > > >> [...] When someone can make a compelling argument for why > > > > > > >> the bits need to be defined in a certain way (i.e., > > > > > there is a real > > > > > > >> application for which using the bits provides > > > > > significant benefits, > > > > > > >> and those benefits do not appear achievable through > > > > > other means) that > > > > > > >> is the time to define the bits. What I do sense with > > > many of the > > > > > > >> recent discussions surrounding the Flow Label is that > > > > > there are many > > > > > > >> folks (i.e., folks putting IPv6 into hardware) that want > > > > > to know what > > > > > > >> they should implement w.r.t. the Flow Label. > While it would > > > > > > >be nice to > > > > > > >> be able tell them what to do, we shouldn't standardize > > > > > something just > > > > > > >> for the sake of having a definition. > > > > > > >> > > > > > > >> Thomas > > > > > > > > > > > > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per > > > byte, or 3.2 > > > > > > >instructions of a hypothetical > > > > > > >1Ghz processor which can execute one instruction per > > > > > cycle. That's a > > > > > > >hell of a requirement. > > > > > > > > > > > > > >As consumers, we all enjoy the very cost-effective > > > availability of > > > > > > >100Mb/sec line speed packet processing in almost every > > > > > > >Notebook, or PC. > > > > > > > > > > > > > >IP and QoS Engines implemented in silicon, on a chip or a > > > > > few chips, by > > > > > > >IBM, INTEL, and many, many others, is one of the > > > reasons of the low > > > > > > >costs, along with the ability to optimizing the hardware > > > > > > >in so many more and different ways than the software > > > (for instance > > > > > > >parallel header, or parallel header field processing). > > > > > > > > > > > > > >1Gb/sec IPv4 packet forwarding is a reality, > 10Gb/sec is just > > > > > > >around the > > > > > > >corner, with 40Gb/sec following not long after. > > > > > > > > > > > > > >With such drastic "timing" requirements, implementing > > > engines in > > > > > > >silicon, and inventing *clever* mechanisms to handle > > > the sequential > > > > > > >processing of headers alone, will not be sufficient to > > > > > implement very > > > > > > >cost-effective IPv6 forwarding and QoS solutions, and > > > IPv6 is at a > > > > > > >disadvantage relative to IPv4. > > > > > > > > > > > > > >We need all the help we can get from the protocol, that is > > > > > headers, and > > > > > > >their fields, for forwarding and QoS processing, > and by that I > > > > > > >mean both > > > > > > >Intserv, and Diffserv. > > > > > > > > > > > > > >Regards, > > > > > > >Alex > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 22 14:07:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7ML6Fx22128 for ipng-dist; Wed, 22 Aug 2001 14:06:15 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7ML6Bm22121 for ; Wed, 22 Aug 2001 14:06:11 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23216; Wed, 22 Aug 2001 17:06:16 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f7ML5d012677; Wed, 22 Aug 2001 17:05:39 -0400 (EDT) Message-Id: <200108222105.f7ML5d012677@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: Brian E Carpenter , Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label In-reply-to: Your message of "Tue, 21 Aug 2001 13:11:09 PDT." <15234.49245.24268.283937@thomasm-u1.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 22 Aug 2001 17:05:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Huh? I thought that one of the requirements for ESP was to > copy the DSCP to the outer header. If I recall correctly, > this bothers some people from a traffic analysis standpoint, > but that seems to be part and parcel with QoS so that doesn't > hold much water IMO. It seems that it would be appropriate for an implementation to "reclassify" packets at the time of encapsulation into ESP -- the packet is, after all, going through a logical trust boundary as it's being encrypted.. This reclassification could involve copying the inner DSCP into the outer header, or it could involve painting all packets the same shade of black to discourage traffic analysis, or running it through some other mapping function. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 22 14:09:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7ML9Hc22146 for ipng-dist; Wed, 22 Aug 2001 14:09:17 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7ML9Dm22139 for ; Wed, 22 Aug 2001 14:09:13 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23665; Wed, 22 Aug 2001 17:09:18 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f7ML8f012713; Wed, 22 Aug 2001 17:08:41 -0400 (EDT) Message-Id: <200108222108.f7ML8f012713@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: Brian E Carpenter , "''ipng ' '" Subject: Re: Higher level question about flow label In-reply-to: Your message of "Tue, 21 Aug 2001 13:46:22 PDT." <15234.51358.518560.857445@thomasm-u1.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 22 Aug 2001 17:08:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Oh. I now see what I missed. Why doesn't including > the SPI into the flow key work? You wouldn't be > able to police based on port numbers (ie try to be > a firewall), but some would say that's a feature > not a bug. Well, except that there's no such thing as a "well known SPI".. When done correctly, SPI's are random and short lived, with semantics only visible to the SA endpoints, so they just turn into a slightly less useful form of pseudorandom flow label (since multiple "flows" may share an SA, and the SPI's change over time as the SA's time out and are rekeyed). - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 22 14:22:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MLMAD22276 for ipng-dist; Wed, 22 Aug 2001 14:22:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MLM6m22269 for ; Wed, 22 Aug 2001 14:22:06 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03707 for ; Wed, 22 Aug 2001 14:22:06 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13436; Wed, 22 Aug 2001 14:22:05 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7MLM4Q19629; Wed, 22 Aug 2001 14:22:04 -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 AAE10356; Wed, 22 Aug 2001 14:22:03 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA19883; Wed, 22 Aug 2001 14:22:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15236.8827.323100.546364@thomasm-u1.cisco.com> Date: Wed, 22 Aug 2001 14:22:03 -0700 (PDT) To: sommerfeld@east.sun.com Cc: Michael Thomas , Brian E Carpenter , Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label In-Reply-To: <200108222105.f7ML5d012677@thunk.east.sun.com> References: <15234.49245.24268.283937@thomasm-u1.cisco.com> <200108222105.f7ML5d012677@thunk.east.sun.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 Bill Sommerfeld writes: > > Huh? I thought that one of the requirements for ESP was to > > copy the DSCP to the outer header. If I recall correctly, > > this bothers some people from a traffic analysis standpoint, > > but that seems to be part and parcel with QoS so that doesn't > > hold much water IMO. > > It seems that it would be appropriate for an implementation to > "reclassify" packets at the time of encapsulation into ESP -- the > packet is, after all, going through a logical trust boundary as it's > being encrypted.. If I understand Brian's concern correctly, that may not necessarily be the case. The security gateway may be on egress from my network and hence controlled by me. If the service provider wants to reclassify those packets, it would need to be done at the next hop router from the security gateway (ie on a router they controlled). I'm still not sure I understand the policing they are trying to accomplish though; it seems sort of weird to have port level classification on the other side of the trust boundary to set the proper DSCP, unless it's just provide a service that could (should?) have been done at your egress router. Otherwise it seems like the user would be shooting themselves in the foot since the normal method is for the policer to police to a certain SLA on a given aggregate traffic class. This to my mind would argue for the classification to be done on *before* it is encapsulated with ESP, but the policing done on the aggregate where it doesn't care about the port data. Ie: luserdata------------>SG---------------------->AR (classifies, (polices remarks dscp, SLA against encrypts) DSCP, remarks) Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 22 14:36:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MLZaB22398 for ipng-dist; Wed, 22 Aug 2001 14:35:36 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MLZWm22391 for ; Wed, 22 Aug 2001 14:35:33 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25988; Wed, 22 Aug 2001 17:35:37 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f7MLZ0013174; Wed, 22 Aug 2001 17:35:00 -0400 (EDT) Message-Id: <200108222135.f7MLZ0013174@thunk.east.sun.com> From: Bill Sommerfeld To: Michael Thomas cc: sommerfeld@east.sun.com, Brian E Carpenter , Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label In-reply-to: Your message of "Wed, 22 Aug 2001 14:22:03 PDT." <15236.8827.323100.546364@thomasm-u1.cisco.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 22 Aug 2001 17:35:00 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > It seems that it would be appropriate for an implementation to > > "reclassify" packets at the time of encapsulation into ESP -- the > > packet is, after all, going through a logical trust boundary as it's > > being encrypted.. > > If I understand Brian's concern correctly, that may > not necessarily be the case. The security gateway may > be on egress from my network and hence controlled by me. ... > luserdata------------>SG---------------------->AR > (classifies, (polices > remarks dscp, SLA against > encrypts) DSCP, remarks) No, there are two trust boundaries in the above network; the subscriber's is inside SG, and the provider's is inside AR... - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 22 14:43:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MLgpr22482 for ipng-dist; Wed, 22 Aug 2001 14:42:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MLglm22475 for ; Wed, 22 Aug 2001 14:42:47 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18558 for ; Wed, 22 Aug 2001 14:42:53 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27854; Wed, 22 Aug 2001 14:42:53 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7MLh4n10315; Wed, 22 Aug 2001 14:43:04 -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 AAE10956; Wed, 22 Aug 2001 14:42:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA19890; Wed, 22 Aug 2001 14:42:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15236.10075.671287.264594@thomasm-u1.cisco.com> Date: Wed, 22 Aug 2001 14:42:51 -0700 (PDT) To: sommerfeld@east.sun.com Cc: Michael Thomas , Brian E Carpenter , Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label In-Reply-To: <200108222135.f7MLZ0013174@thunk.east.sun.com> References: <15236.8827.323100.546364@thomasm-u1.cisco.com> <200108222135.f7MLZ0013174@thunk.east.sun.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 Bill Sommerfeld writes: > > > It seems that it would be appropriate for an implementation to > > > "reclassify" packets at the time of encapsulation into ESP -- the > > > packet is, after all, going through a logical trust boundary as it's > > > being encrypted.. > > > > If I understand Brian's concern correctly, that may > > not necessarily be the case. The security gateway may > > be on egress from my network and hence controlled by me. > ... > > > luserdata------------>SG---------------------->AR > > (classifies, (polices > > remarks dscp, SLA against > > encrypts) DSCP, remarks) > > No, there are two trust boundaries in the above network; the > subscriber's is inside SG, and the provider's is inside AR... Correct, however I'm not sure why that's pertinent to what I wrote. I'm trying to understand why this setup is deficient. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 22 15:07:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MM6Se22693 for ipng-dist; Wed, 22 Aug 2001 15:06:28 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MM6Qm22686 for ; Wed, 22 Aug 2001 15:06:26 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7MM4VE10908 for ipng@sunroof.eng.sun.com; Wed, 22 Aug 2001 15:04:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MHmWm21501 for ; Wed, 22 Aug 2001 10:48:32 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24872 for ; Wed, 22 Aug 2001 10:48:38 -0700 (PDT) Received: from dfawcus-laptop.cisco.com (ams-clip-nat-ext1.cisco.com [64.103.37.2]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA22550 for ; Wed, 22 Aug 2001 10:48:33 -0700 (PDT) Received: (qmail 1101 invoked by uid 69022); 22 Aug 2001 17:47:00 -0000 Date: Wed, 22 Aug 2001 18:46:38 +0100 From: Derek Fawcus To: Brian E Carpenter , jarno.rajahalme@nokia.com Cc: ipng Subject: Re: Higher level question about flow label Message-ID: <20010822184638.A995@dfawcus-gw-home.cisco.com> Mail-Followup-To: Brian E Carpenter , jarno.rajahalme@nokia.com, ipng References: <3B7BCE71.BE8DB82E@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <009CA59D1752DD448E07F8EB2F911757197FDC@esebe004.NOE.Nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote: > I think the WG needs to decide once and for all whether the flow label is > a) a CATNIP or MPLS-like routing handle > or b) a QOS hint for intserv only > or c) a QOS hint for intserv and diffserv > or d) a waste of bits > > We can get back to the details once we have a consensus on this. I'd suggest e) A flow identifier for router optimisation. I sort of see this as a variation of b), i.e. it identifies a flow using a PRN but does not imply any QoS usage. However it doesn't preclude the flow label being used in scenario b). Specifically - I see it as a way of replacing the srcPort/dstPort tuple that routers peek at in the TCP/UDP header. Currently I only see this being used in one scenario, that is for load balancing across multiple paths. At the moment (for v4) if a lookup on the dst address address leads to a route with multiple paths, and the route is appropriatly marked, the flows of packets can be shared across these multiple paths. This is done (for min size IPv4 headers, carrying TCP or UDP) by hashing the srcIP/dstIP/srcPort/dstPort and using this to help choose which path to forward the packet over. Given that for IPv6 we can't guarentee the TCP/UDP header is at any given offset, or even that it's readable. One would need some other way of identifying flows if the above load balancing was to be performed. For v6 a core router engine (either s/w path, or ASIC [as fix logic or programable device as someone suggested]) one will not be looking beyond the base IPv6 header. For an edge rouer engine, one may well be looking inside the packet for say classification. Hence use the flowID. Without this we could only hash based upon the srcIP/dstIP and hence all flows between a given src/dst pair will hit the same path. With this info in the flow label, one would be able to hash together the srcIP/flowLabel to find the correct path. As a router in this situation one would always have to combine the src IP address, but if the flow label was defined to uniquely distinguish a given dstIP/srcPort/dstPort flow, one could skip compining the dstIP at the router. The reason for specifying that it be a PRN is simply to make the hashing cheaper at the router. I said above that this doesn't preclude using the flow label for scenario b), this can be achieved simply by picking a PRN for scenario b) from the same number pool as for scenario e). Thus if intserv QoS is being used, a (set of) routers would have been informed (via RSVP) about the relationship between that flow label and certain QoS requirements, any other routers in the path of the packet flow that don't know about intserv/RSVP will simply treat packets in the flow as scenario e). So the usage becomes one that is (potentially) orthogonal to QoS. It will be usable for non QoS'ed (intserv or diffserv) packets, as well as with both intserv and diffserv. On Wed, Aug 22, 2001 at 11:41:30AM +0300, jarno.rajahalme@nokia.com wrote: > Earlier it has been thought that the pseudo-random nature of the flow label > would make lookups easier by allowing the flow label to be used as a hash as > such. There are some specific difficulties with this, however: > > 1) Routers can not know how good pseudo random numbers the flow-labels > injected by hosts are in practice. Bad pseudo random numbers used by large > class of hosts could constitute a kind of DoS attack against router > implementations relying on the pseudo-random number nature of the flow > label. [Maybe someone actually implementing look-ups on hardware based on > the flow label could bring additional light on this matter (Alex?)] I'd disagree. The router should only use the RPN in a situation where a DoS can't occur. Take my example above - the route has already been looked up (using the dst IP address), and we've got multiple paths. We're now going to use the flow label to help pick the path. So say a set of originating hosts pick a poor PRN, all that happens is that they end up getting less available bandwith for all of their flows. This on the assumption that their choice of a poor PRN causes a sub set of the available paths to be picked. Note however that this doesn't affect other hosts with a good PRNG which will be able to use more/all of the available paths. It also doesn't mean that a DoS on any given path will occur - since queuing (say WRED) will occur after having picked a path. The only party hurt by their choice of a poor PRN is themselves. > 2) If there is an alternative format, that is not pseudo-random (as being > proposed), the routers will have to implement look-ups that function > efficiently with that format. Since we do not know what portion of the > traffic in the future would use this non-pseudo-random format, the > implementations have to assume that all traffic can be labeled with this > alternative format. Lookups only occur when a QoS type funtion is applied to the flow label, say we've been told about a flow by RSVP. In this case a PRN still helps since we can reduce the cost of lookups by hashing on the flow label to pick a subset of flows before doing a search/comparison. But then if the flow lable was a PRN, we'd simply skip the hash and use some of it's bits as a hash bucket index, before jumping to the search and comparision phase. If QoS is not in use for that particular route & flow label, then if the value was not random, we'd have to use a more complex hash algorithm in order to make sure we had got a good bucket distribution. DF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 22 15:44:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7MMhpO22957 for ipng-dist; Wed, 22 Aug 2001 15:43:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7MMhlm22950 for ; Wed, 22 Aug 2001 15:43:47 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29592 for ; Wed, 22 Aug 2001 15:43:52 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22024 for ; Wed, 22 Aug 2001 15:43:51 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7MMhmm78406; Wed, 22 Aug 2001 18:43:48 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7MMhl166910; Wed, 22 Aug 2001 18:43:47 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id SAA18818; Wed, 22 Aug 2001 18:43:47 -0400 (EDT) Message-Id: <200108222243.SAA18818@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Derek Fawcus cc: ipng Subject: Re: Higher level question about flow label In-reply-to: Your message of "Wed, 22 Aug 2001 18:46:38 BST." <20010822184638.A995@dfawcus-gw-home.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Aug 2001 18:43:46 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Derek Fawcus wrote: > Specifically - I see it as a way of replacing the srcPort/dstPort tuple > that routers peek at in the TCP/UDP header. Currently I only see this > being used in one scenario, that is for load balancing across multiple > paths. > > At the moment (for v4) if a lookup on the dst address address leads to > a route with multiple paths, and the route is appropriatly marked, > the flows of packets can be shared across these multiple paths. This > is done (for min size IPv4 headers, carrying TCP or UDP) by hashing > the srcIP/dstIP/srcPort/dstPort and using this to help choose which > path to forward the packet over. > > Given that for IPv6 we can't guarentee the TCP/UDP header is at any > given offset, or even that it's readable. One would need some other > way of identifying flows if the above load balancing was to be performed. > > For v6 a core router engine (either s/w path, or ASIC [as fix logic > or programable device as someone suggested]) one will not be looking > beyond the base IPv6 header. For an edge rouer engine, one may well > be looking inside the packet for say classification. > > Hence use the flowID. Without this we could only hash based upon the > srcIP/dstIP and hence all flows between a given src/dst pair will hit > the same path. Including srcPort/dstPort in a load-balancing hash is generally a bad idea, as documented in RFC2991 pg. 3. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure (919)472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 22 17:59:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N0pOA23299 for ipng-dist; Wed, 22 Aug 2001 17:51:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N0pGm23292 for ; Wed, 22 Aug 2001 17:51:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19331 for ; Wed, 22 Aug 2001 17:49:57 -0700 (PDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA27672 for ; Wed, 22 Aug 2001 18:49:52 -0600 (MDT) Received: from 157.54.9.100 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Aug 2001 17:49:19 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 22 Aug 2001 17:49:19 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 22 Aug 2001 17:49:19 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 22 Aug 2001 17:49:04 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.5701.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Higher level question about flow label Date: Wed, 22 Aug 2001 17:49:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Higher level question about flow label Thread-Index: AcErWD6yrPrBlssESO2XSu19Z0ywfAAEu+xg From: "Christian Huitema" To: "Brian E Carpenter" Cc: "ipng" X-OriginalArrivalTime: 23 Aug 2001 00:49:04.0125 (UTC) FILETIME=[681D12D0:01C12B6D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7N0pLm23293 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote: > > I think the WG needs to decide once and for all whether the flow label > is > > a) a CATNIP or MPLS-like routing handle > > or b) a QOS hint for intserv only > > or c) a QOS hint for intserv and diffserv > > or d) a waste of bits I think that the most useful use is probably (c). Option (a) is not terribly interesting: if you want to do MPLS, just insert an MPLS header; MP in MPLS stands for multi-protocol, which means that MPLS is always going to have a "layer of indirection" for v4, v6, and whatever else the ISP wants to run on it. Option (b) really means "a set of random bits" and is not terribly useful either: it would require that the routers trusts the random generation in the hosts, which is not going to happen (the trust, I mean.) Option (c) really means "tell me something useful about the content of the packet so I can use it for classification." Suppose I place here the port number that identifies the service, e.g. 25 for mail, 80 for web, etc., plus an indication of whether this is UDP or TCP. This plus the addresses would enable some easy filtering into intserv or diffserv classifications, without requiring that the router go deep into the header chain. It would enable easy traffic statistics. It would be easy to implement for the host (pick the lowest of dest or source port.) It would work even if the packet is encrypted. We could reserve values for specific traffics, e.g. RTP-audio, RTP-video. It would work even if we use ESP. From an information theory point of view, this looks much more useful than either random bits or null values. Indeed, the bits will have to be set by the host. But then, so are the port numbers. Nothing prevent cooperating hosts from running NFS over port 80... In fact, if the router is willing to inspect the full header chain, it could rewrite the bits to a "trusted" value. Also, some hosts may not be willing to provide the information, e.g. when they actually want to hide the nature of the encrypted traffic; these hosts could use a null field, which would be classified to some default rule by the diffserv filters (you cannot have it both ways.) Count my vote for (c). -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 22 18:04:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N13iW23368 for ipng-dist; Wed, 22 Aug 2001 18:03:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N12im23346; Wed, 22 Aug 2001 18:02:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA17842; Wed, 22 Aug 2001 18:02:45 -0700 (PDT) Received: from INET-VRS-06.redmond.corp.microsoft.com ([131.107.3.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA03093; Wed, 22 Aug 2001 19:02:40 -0600 (MDT) Received: from 157.54.9.101 by INET-VRS-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Aug 2001 18:02:08 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 22 Aug 2001 18:02:07 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 22 Aug 2001 18:02:06 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 22 Aug 2001 18:01:47 -0700 x-mimeole: Produced By Microsoft Exchange V6.0.5701.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary Date: Wed, 22 Aug 2001 18:01:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (ngtrans) Joint DNSEXT & NGTRANS summary Thread-Index: AcEqb0oPJGg0alQTQ5KjB1qFd0NkLgA/xIog From: "Christian Huitema" To: "Jun-ichiro itojun Hagino" , "Robert Elz" Cc: , , , X-OriginalArrivalTime: 23 Aug 2001 01:01:47.0679 (UTC) FILETIME=[2F3A2AF0:01C12B6F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7N12pm23347 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In retrospect, I believe I made at least one mistake when writing the A6 RFC, which is going for a "full recursion" model. This triggers all kinds of "interesting" possibilities. Going for a site model would have been more appropriate: basically, one could request that the "prefix domain name" points to a set of AAAA records, allowing for exactly one level of indirection. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 23 02:27:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7N9QY724271 for ipng-dist; Thu, 23 Aug 2001 02:26:34 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7N9QUm24264 for ; Thu, 23 Aug 2001 02:26:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26553 for ; Thu, 23 Aug 2001 02:26:36 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10981 for ; Thu, 23 Aug 2001 02:26:35 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 11:26:38 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECA9F7@mail.kebne.se> From: Thomas Eklund To: "'Derek Fawcus'" , Brian E Carpenter , jarno.rajahalme@nokia.com Cc: ipng Subject: RE: Higher level question about flow label Date: Thu, 23 Aug 2001 11:26:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Derek, Basically I agree with your line of thinking. That the reason why I wanted a "mpls" style flow where you would do traffic engineering on. But what is TE? TE optimise and could also load balance the traffic in your network to utilize the network as efficient as possible. So from a functional point of view is very similar when you do load balancing across multiple paths (composite links, ECMP etc). I also saw Steve Blakes comment that is not recommended to use TCP/UDP ports in the hash key for ECMP but the one of the biggest problem with the bundling is to send one TCP flow over different path since it might end up in packet re-ordering due the different delays etc and trigger TCP slow start. To me it makes a lot of sense then to include the TCP/UDP ports when you have your "hash key" since you would like that the same TCP flow take the same path to not experience these problems. One problem of course is maintaining per state flow info in the classifier since it needs to be refreshed when the flow expires. It is also problematic to update the CAM/SRAM in the forwarding plane with the flow info at wirespeed. That is mostly handled by the control plane (or "slow path")to update your flow tables (that sits in CAM/SRAM). But there I see that the hop-by-hop option is very useful to signal "inband" or with the packet that a new flow is going to be set up in the flow tables, since the first thing you must check is that it is not next header 0 pointer and if it is you must process that header. -- thomas >-----Original Message----- >From: Derek Fawcus [mailto:dfawcus@cisco.com] >Sent: den 22 augusti 2001 19:47 >To: Brian E Carpenter; jarno.rajahalme@nokia.com >Cc: ipng >Subject: Re: Higher level question about flow label > > >On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote: >> I think the WG needs to decide once and for all whether the >flow label is >> a) a CATNIP or MPLS-like routing handle >> or b) a QOS hint for intserv only >> or c) a QOS hint for intserv and diffserv >> or d) a waste of bits >> >> We can get back to the details once we have a consensus on this. > >I'd suggest e) A flow identifier for router optimisation. > >I sort of see this as a variation of b), i.e. it identifies a >flow using >a PRN but does not imply any QoS usage. However it doesn't >preclude the >flow label being used in scenario b). > > >Specifically - I see it as a way of replacing the srcPort/dstPort tuple >that routers peek at in the TCP/UDP header. Currently I only see this >being used in one scenario, that is for load balancing across multiple >paths. > >At the moment (for v4) if a lookup on the dst address address leads to >a route with multiple paths, and the route is appropriatly marked, >the flows of packets can be shared across these multiple paths. This >is done (for min size IPv4 headers, carrying TCP or UDP) by hashing >the srcIP/dstIP/srcPort/dstPort and using this to help choose which >path to forward the packet over. > >Given that for IPv6 we can't guarentee the TCP/UDP header is at any >given offset, or even that it's readable. One would need some other >way of identifying flows if the above load balancing was to be >performed. > >For v6 a core router engine (either s/w path, or ASIC [as fix logic >or programable device as someone suggested]) one will not be looking >beyond the base IPv6 header. For an edge rouer engine, one may well >be looking inside the packet for say classification. > >Hence use the flowID. Without this we could only hash based upon the >srcIP/dstIP and hence all flows between a given src/dst pair will hit >the same path. > >With this info in the flow label, one would be able to hash together >the srcIP/flowLabel to find the correct path. As a router in this >situation one would always have to combine the src IP address, but >if the flow label was defined to uniquely distinguish a given >dstIP/srcPort/dstPort flow, one could skip compining the dstIP at >the router. > >The reason for specifying that it be a PRN is simply to make >the hashing >cheaper at the router. > >I said above that this doesn't preclude using the flow label >for scenario >b), this can be achieved simply by picking a PRN for scenario b) from >the same number pool as for scenario e). Thus if intserv QoS is being >used, a (set of) routers would have been informed (via RSVP) >about the relationship between that flow label and certain QoS >requirements, any other routers in the path of the packet flow that >don't know about intserv/RSVP will simply treat packets in the flow as >scenario e). > >So the usage becomes one that is (potentially) orthogonal to QoS. It >will be usable for non QoS'ed (intserv or diffserv) packets, as well >as with both intserv and diffserv. > > >On Wed, Aug 22, 2001 at 11:41:30AM +0300, >jarno.rajahalme@nokia.com wrote: >> Earlier it has been thought that the pseudo-random nature of >the flow label >> would make lookups easier by allowing the flow label to be >used as a hash as >> such. There are some specific difficulties with this, however: >> >> 1) Routers can not know how good pseudo random numbers the >flow-labels >> injected by hosts are in practice. Bad pseudo random numbers >used by large >> class of hosts could constitute a kind of DoS attack against router >> implementations relying on the pseudo-random number nature >of the flow >> label. [Maybe someone actually implementing look-ups on >hardware based on >> the flow label could bring additional light on this matter (Alex?)] > >I'd disagree. The router should only use the RPN in a >situation where a DoS >can't occur. > >Take my example above - the route has already been looked up (using the >dst IP address), and we've got multiple paths. We're now going to use >the flow label to help pick the path. > >So say a set of originating hosts pick a poor PRN, all that happens is >that they end up getting less available bandwith for all of >their flows. >This on the assumption that their choice of a poor PRN causes a sub set >of the available paths to be picked. > >Note however that this doesn't affect other hosts with a good >PRNG which >will be able to use more/all of the available paths. It also doesn't >mean that a DoS on any given path will occur - since queuing (say WRED) >will occur after having picked a path. > >The only party hurt by their choice of a poor PRN is themselves. > >> 2) If there is an alternative format, that is not >pseudo-random (as being >> proposed), the routers will have to implement look-ups that function >> efficiently with that format. Since we do not know what >portion of the >> traffic in the future would use this non-pseudo-random format, the >> implementations have to assume that all traffic can be >labeled with this >> alternative format. > >Lookups only occur when a QoS type funtion is applied to the >flow label, >say we've been told about a flow by RSVP. In this case a PRN >still helps >since we can reduce the cost of lookups by hashing on the flow label to >pick a subset of flows before doing a search/comparison. > >But then if the flow lable was a PRN, we'd simply skip the >hash and use >some of it's bits as a hash bucket index, before jumping to the search >and comparision phase. > >If QoS is not in use for that particular route & flow label, >then if the >value was not random, we'd have to use a more complex hash >algorithm in >order to make sure we had got a good bucket distribution. > >DF > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Aug 23 03:14:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NAE9j24472 for ipng-dist; Thu, 23 Aug 2001 03:14:09 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NAE3m24465 for ; Thu, 23 Aug 2001 03:14:04 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f7NAE2N01283; Thu, 23 Aug 2001 12:14:02 +0200 (MET DST) Date: Thu, 23 Aug 2001 12:10:47 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: [AAA-WG]: AAA for IPv6 To: Thomas Eklund Cc: "'Bernard Aboba '" , "'Charlie Perkins '" , "'aaa-wg@merit.edu '" , "'john.loughney@nokia.com '" , "'ipng@sunroof.eng.sun.com '" , "'urp@research.telcordia.com '" In-Reply-To: "Your message with ID" <31A473DBB655D21180850008C71E251A04ECA9E7@mail.kebne.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bernard, > It was rough consenus on the IPv6 WG meeting that this was something that is > of interest of IPv6 WG and the WG supports that it becomes a AAA WG item. I'm not sure about that one. For one thing the "this" above can have rather different interpretations: - the general problem area - the more specific problem as specified in the draft in question - the solution specified in the draft At the most IPNG discussed the first bullet as I recall. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 23 07:37:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NEamL25158 for ipng-dist; Thu, 23 Aug 2001 07:36:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NEaim25151 for ; Thu, 23 Aug 2001 07:36:44 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17895; Thu, 23 Aug 2001 07:36:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00601; Thu, 23 Aug 2001 07:36:37 -0700 (PDT) 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 HAA15279; Thu, 23 Aug 2001 07:36:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7NEaQK07786; Thu, 23 Aug 2001 07:36:26 -0700 X-mProtect: Thu, 23 Aug 2001 07:36:26 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdeaKUkM; Thu, 23 Aug 2001 07:36:25 PDT Message-ID: <3B8514E9.282BAFE6@iprg.nokia.com> Date: Thu, 23 Aug 2001 07:36:25 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: "'ipng@sunroof.eng.sun.com '" , "'urp@research.telcordia.com '" Subject: Re: [AAA-WG]: AAA for IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Erik, As I remember, the people attending the IPv6 working group meeting agreed that the general problem area should be considered as a work item within the AAA working group. I purposefully did not ask whether the specific solution in our AAAv6 draft should be considered, because that would be premature as long as the AAA working group had not yet made the consideration. However, it seems to me that there isn't any clear dividing line between these two: - the general problem area - the more specific problem as specified in the draft in question since the draft in question does try to discuss the general problem area. Can you say more about the distinction you had in mind? Regards, Charlie P. Erik Nordmark wrote: > > > Bernard, > > It was rough consenus on the IPv6 WG meeting that this was something that is > > of interest of IPv6 WG and the WG supports that it becomes a AAA WG item. > > I'm not sure about that one. > For one thing the "this" above can have rather different > interpretations: > - the general problem area > - the more specific problem as specified in the draft in question > - the solution specified in the draft > > At the most IPNG discussed the first bullet as I recall. > > Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 23 07:55:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NEt2H25199 for ipng-dist; Thu, 23 Aug 2001 07:55:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NEswm25192 for ; Thu, 23 Aug 2001 07:54:59 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04458 for ; Thu, 23 Aug 2001 07:55:02 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11010 for ; Thu, 23 Aug 2001 07:55:00 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7NEsvw86045; Thu, 23 Aug 2001 10:54:57 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7NEsvl75320; Thu, 23 Aug 2001 10:54:57 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id KAA26185; Thu, 23 Aug 2001 10:54:51 -0400 (EDT) Message-Id: <200108231454.KAA26185@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Thomas Eklund cc: ipng Subject: Re: Higher level question about flow label In-reply-to: Your message of "Thu, 23 Aug 2001 11:26:37 +0200." <31A473DBB655D21180850008C71E251A04ECA9F7@mail.kebne.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Aug 2001 10:54:51 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Eklund wrote: > I also saw Steve Blakes comment that is not recommended to use TCP/UDP ports > in the hash key for ECMP but the one of the biggest problem with the > bundling is to send one TCP flow over different path since it might end up > in packet re-ordering due the different delays etc and trigger TCP slow > start. To me it makes a lot of sense then to include the TCP/UDP ports when > you have your "hash key" since you would like that the same TCP flow take > the same path to not experience these problems. If you only hash on , then all of the flows between the two end-points will follow the same path. There is a good paper by Cao, Wang, and Zegura analyzing the performance of various hashing schemes at http://www.ieee-infocom.org/2000/papers/650.ps. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 08:26:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NFPNq25318 for ipng-dist; Thu, 23 Aug 2001 08:25:23 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NFPJm25311 for ; Thu, 23 Aug 2001 08:25:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04164 for ; Thu, 23 Aug 2001 08:25:23 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13006 for ; Thu, 23 Aug 2001 09:25:18 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 17:25:25 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECAA00@mail.kebne.se> From: Thomas Eklund To: "'Steve Blake'" , Thomas Eklund Cc: ipng Subject: RE: Higher level question about flow label Date: Thu, 23 Aug 2001 17:25:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Steve, But thats very strange way of hashing since the bulk of for instance enterprise traffic is probably on port 80 and would take the same path. Its ok as long it is the same session that take the same path but you would like to load balance the traffic for the same TCP port but for different src IP adresses over your composite links. In the report you refer to their conclusion was that the CRC 16 on the five tuple (src IP, dst, IP src port, dst port, prot id) shows the best load balancing distribution performance. In this case it could be a 20-bit CRC on the fivetuple that builds up the flow label. -- thomas >-----Original Message----- >From: Steve Blake [mailto:slblake@torrentnet.com] >Sent: den 23 augusti 2001 16:55 >To: Thomas Eklund >Cc: ipng >Subject: Re: Higher level question about flow label > > >Thomas Eklund wrote: > > >> I also saw Steve Blakes comment that is not recommended to >use TCP/UDP ports >> in the hash key for ECMP but the one of the biggest problem with the >> bundling is to send one TCP flow over different path since >it might end up >> in packet re-ordering due the different delays etc and >trigger TCP slow >> start. To me it makes a lot of sense then to include the >TCP/UDP ports when >> you have your "hash key" since you would like that the same >TCP flow take >> the same path to not experience these problems. > >If you only hash on , then all of the flows >between the >two end-points will follow the same path. > >There is a good paper by Cao, Wang, and Zegura analyzing the >performance >of various hashing schemes at >http://www.ieee->infocom.org/2000/papers/650.ps. > > >Regards, > > > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven L. Blake >Ericsson IP Infrastructure 919-472-9913 > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 11:04:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NI48o26014 for ipng-dist; Thu, 23 Aug 2001 11:04:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NI44m26007 for ; Thu, 23 Aug 2001 11:04:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19945 for ; Thu, 23 Aug 2001 11:04:09 -0700 (PDT) Received: from web14908.mail.yahoo.com (web14908.mail.yahoo.com [216.136.225.60]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA11636 for ; Thu, 23 Aug 2001 12:04:05 -0600 (MDT) Message-ID: <20010823180408.39823.qmail@web14908.mail.yahoo.com> Received: from [148.202.15.7] by web14908.mail.yahoo.com; Thu, 23 Aug 2001 13:04:08 CDT Date: Thu, 23 Aug 2001 13:04:08 -0500 (CDT) From: =?iso-8859-1?q?Harold=20De=20Dios?= Subject: RE: [AAA-WG]: AAA for IPv6 To: Erik Nordmark , Thomas Eklund Cc: "'Bernard Aboba '" , "'Charlie Perkins '" , "'aaa-wg@merit.edu '" , "'john.loughney@nokia.com '" , "'ipng@sunroof.eng.sun.com '" , "'urp@research.telcordia.com '" In-Reply-To: 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 Hi i have been having troubles whit a cisco 3640, i installed cisco IOS image 12.2T. This i s my problem im triyng to use this router whit IPv6 when i try to ping my host whit my router this not respond, but when i intent to ping my host and my interface ethernet it dont work. But when i conect my router to my network and my host (dual stack)it work it can see my router and vice versa. Could you help me whit this please. This is my configuration.(router) Using 1149 out of 129016 bytes ! version 12.2 no parser cache no service single-slot-reload-enable service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname CUCI ! no logging buffered logging rate-limit console 10 except errors ! ! ! ip subnet-zero ! ! ! no ip dhcp-client network-discovery ipv6 unicast-routing mgcp --More--  mgcp call-agent 148.202.200.250 service-type mgcp version 0.1 mgcp dtmf-relay voip codec low-bit-rate mode cisco mgcp sdp simple no mgcp timer receive-rtcp call rsvp-sync ! ! ! ! ! ccm-manager mgcp ! ! ! ! interface Ethernet0/0 ip address 148.202.15.8 255.255.255.0 half-duplex ipv6 enable ipv6 address 3FFE:94CA:F:8::/64 eui-64 ! interface Ethernet1/0 no ip address --More--   half-duplex ipv6 enable ipv6 address 3FFE:94CA:F:7::/64 eui-64 ! ip default-gateway 148.202.15.253 ip classless ip route 0.0.0.0 0.0.0.0 148.202.15.253 no ip http server ! ! ! ! dial-peer cor custom ! ! ! dial-peer voice 1 pots application mgcpapp ! dial-peer voice 2 pots application mgcpapp ! dial-peer voice 3 pots --More--   application mgcpapp ! dial-peer voice 4 pots application mgcpapp ! ! line con 0 line aux 0 line vty 0 4 login ! ! end CUCI# --- Erik Nordmark escribi: > > Bernard, > > It was rough consenus on the IPv6 WG meeting that > this was something that is > > of interest of IPv6 WG and the WG supports that it > becomes a AAA WG item. > > I'm not sure about that one. > For one thing the "this" above can have rather > different > interpretations: > - the general problem area > - the more specific problem as specified in the > draft in question > - the solution specified in the draft > > At the most IPNG discussed the first bullet as I > recall. > > 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 > -------------------------------------------------------------------- _________________________________________________________ Do You Yahoo!? Construye tu pgina personal en Yahoo! GeoCities. Es fcil, rpido y gratis! http://geocities.yahoo.com.mx -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 11:33:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NIWkD26068 for ipng-dist; Thu, 23 Aug 2001 11:32:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NIWfm26061 for ; Thu, 23 Aug 2001 11:32:42 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29789; Thu, 23 Aug 2001 11:32:38 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16171; Thu, 23 Aug 2001 11:32:36 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id LAA22481; Thu, 23 Aug 2001 11:25:00 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 23 Aug 2001 11:25:00 -0700 (PDT) From: Bernard Aboba To: =?iso-8859-1?q?Harold=20De=20Dios?= cc: Erik Nordmark , Thomas Eklund , "'Charlie Perkins '" , "'aaa-wg@merit.edu '" , "'john.loughney@nokia.com '" , "'ipng@sunroof.eng.sun.com '" , "'urp@research.telcordia.com '" Subject: RE: [AAA-WG]: AAA for IPv6 In-Reply-To: <20010823180408.39823.qmail@web14908.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please take this to the Cisco TAC, rather than spamming multiple IETF mailing lists. On Thu, 23 Aug 2001, [iso-8859-1] Harold De Dios wrote: > > Hi i have been having troubles whit a cisco 3640, > i installed cisco IOS image 12.2T. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 13:45:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) id f7NKiaT26313 for ipng-dist; Thu, 23 Aug 2001 13:44:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7NKiWm26306 for ; Thu, 23 Aug 2001 13:44:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10966 for ; Thu, 23 Aug 2001 13:44:37 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08899 for ; Thu, 23 Aug 2001 13:44:37 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA02732; Thu, 23 Aug 2001 16:45:33 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA08705; Thu, 23 Aug 2001 16:45:33 -0400 Message-ID: <3B856B58.1299F4C3@txc.com> Date: Thu, 23 Aug 2001 16:45:12 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Chown CC: ipng Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms446DB735C3CD002D4E98E83F" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms446DB735C3CD002D4E98E83F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tim Chown wrote: > > On Tue, 21 Aug 2001, Alex Conta wrote: > > > at page 15, in the draft. "(c)" protects the value of the flow label, or > > rather, its meaning, where it is relevant to protect it. > > > > That is because, the value in itself, alone, is not meaningful. It is > > the meaning of the value, which is important, and as long as that > > meaning is preserved, the value can change. > > But the only way to preserve the meaning - the fact that the combination > of source address and flow label uniquely identifies the flow because the > source host guarantees that each flow has a unique label - would be to > restore the value to the orginal value previous to any munging/tunelling > in the middle. If you alter the value, where do you store the original > value? > > tim Nodes that change the value would store information that would help preserving the meaning. This could be done for instance by routers in a routing domain. Such technologies already exist, even though not specifically for IPv6. The storing of information can be pseudo-manual under the control of an operator, or dynamic-automated, under the control of some protocol engine, running on each router. --------------ms446DB735C3CD002D4E98E83F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjMyMDQ1MjRaMCMGCSqGSIb3DQEJBDEWBBRpZRar7uAzJscRBw/Y kgRa4c12GTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gFgLc3oJpiV0vNecDAmMN7l0OqgfD3ZNnwohsmNfKmx+91Wd3j6LJMzkfK3dsTzJuU3mQwUM K2Z40wlbWgco3hLJIio3mwHK5tzJXu48H4LxPJH5JThCSaYXFwU2OyeHJkQl6ttgk+oI0B49 HJv+5+phSj0T9lT43bpOYS1g+kbw --------------ms446DB735C3CD002D4E98E83F-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 14:45:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7NLje1O026565 for ; Thu, 23 Aug 2001 14:45:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7NLjd7m026564 for ipng-dist; Thu, 23 Aug 2001 14:45:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7NLja1O026557 for ; Thu, 23 Aug 2001 14:45:36 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24014 for ; Thu, 23 Aug 2001 14:45:41 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08895 for ; Thu, 23 Aug 2001 14:45:40 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id RAA03948; Thu, 23 Aug 2001 17:46:36 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id RAA11701; Thu, 23 Aug 2001 17:46:34 -0400 Message-ID: <3B8579AF.95A76917@txc.com> Date: Thu, 23 Aug 2001 17:46:23 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757197FDC@esebe004.NOE.Nokia.com> <3B840DE5.9D4C7CDB@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms54919D64133B781351FE5621" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms54919D64133B781351FE5621 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, You covered the essence, so, I will just expend a little on the use of MSB: The differentiation between Intserv, and Diffserv flow label values is helpful when a. and b. bellow are both true: a. - packet source nodes send both Intserv and Diffserv traffic to the same router, or set of routers, and b. - the router or the set of routers receiving the Intserv and Diffserv traffic, do both Intserv and Diffserv classification. If b. is not true, e.g. the router, or set of routers do Intserv, or Diffserv, but not both in the same time, then the differentiation is not really necessary. Can we be sure that b. is not true. I do not think so. If a. is true, it is sufficient for the source node to pick up flow label values from two distinct sets of numbers. The set can be interleaved, as long, as the Diffserv values are known the router(s), and the Intserv values are signaled to the routers. For instance 1, 2, 4, 7 can be Intserv, 3, 5, 6 can be Diffserv. 1, 2, 4, 7 are signaled to the routers, 3, 5, 6 are known to the routers. Using MSB draws a separation line that makes things simple. Jarno's idea to have just one way of setting the bits in the flow label has value, if we leave to the source node the problem of making sure Intserv and Diffserv values do not overlap, or if we make sure that a router would never do both Intserv, and DIffserv classification. If the values overlap, it is OK, as long as NO router does both Intserv, and Diffserv. If a router does both Intserv, and Diffserv, and values overlap, then the result is quite unpredictable. Regards, Alex Brian E Carpenter wrote: > > I certainly don't care about the pseudo-random requirement for unique-per-host > opaque flow labels, but if we agree that the flow label may be used for diffserv > then it has to have semantics (i.e. it is not an opaque value). For that I am sure > we need the MSB as a flag bit, so that a classifier can tell whether it is looking > at an opaque value or at a value with semantics. > > Brian > > jarno.rajahalme@nokia.com wrote: > > > > Brian, > > > > Let's then just say that it would be architecturally better to only have one > > format that satisfies all the needs. With better I mean things like less > > text in the specification, simpler implementations, less bugs, better > > interoperability etc. > > > > At this point no-one has established that there is a need or a requirement > > for multiple formats of flow labels. You and Alex have brought up a > > requirement that the flow label value needs to be somehow constant for the > > diffserv for a form of MF classification for diffserv usage. The traditional > > intserv has no requirement to the specific value being used, as the value is > > being explicitly signaled. > > > > It seems that both the old ("intserv") and new ("diffserv") requirements can > > be met with single flow label format (current format with no pseudo-random > > requirement). > > > > Earlier it has been thought that the pseudo-random nature of the flow label > > would make lookups easier by allowing the flow label to be used as a hash as > > such. There are some specific difficulties with this, however: > > > > 1) Routers can not know how good pseudo random numbers the flow-labels > > injected by hosts are in practice. Bad pseudo random numbers used by large > > class of hosts could constitute a kind of DoS attack against router > > implementations relying on the pseudo-random number nature of the flow > > label. [Maybe someone actually implementing look-ups on hardware based on > > the flow label could bring additional light on this matter (Alex?)] > > > > 2) If there is an alternative format, that is not pseudo-random (as being > > proposed), the routers will have to implement look-ups that function > > efficiently with that format. Since we do not know what portion of the > > traffic in the future would use this non-pseudo-random format, the > > implementations have to assume that all traffic can be labeled with this > > alternative format. > > > > It follows that there is no additional benefit of the pseudo-random nature > > of the original format. Therefore it would be best to combine these formats > > into one, that is non-pseudo-random. I.e. the current format with no > > pseudo-random requirement. This would present the minimal change to the > > current specification. Also, current (intserv) implementations could keep on > > using the current pseudo-random numbers without breaking anything. > > > > Jarno > > > > > -----Original Message----- > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > Sent: 21. elokuuta 2001 23:31 > > > To: jarno.rajahalme@nokia.com > > > Cc: seamus@bit-net.com; thomas.eklund@xelerated.com; aconta@txc.com; > > > narten@raleigh.ibm.com; hinden@iprg.nokia.com; > > > ipng@sunroof.eng.sun.com > > > Subject: Re: Higher level question about flow label > > > > > > > > > Jarno, > > > > > > The Carpenter/Conta proposal does include two formats for the > > > label (one aimed > > > at intserv flows and one aimed at diffserv flows), but if you > > > use the field > > > only for rapid routing lookup, you don't care about that; in > > > both cases you can treat > > > the label as 20 opaque bits I think. > > > > > > You only care which format it is when you are doing specific > > > intserv or diffserv > > > packet classification. > > > --------------ms54919D64133B781351FE5621 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjMyMTQ2MjVaMCMGCSqGSIb3DQEJBDEWBBTSHhIblYpPxyJ98nhL zaObJEetGDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gEy5+dOkHfsVdZqebnURIVJkMDKG8vbF3vOcsyct+X/JxUZutGgv6BkR4Tp6HOftfpwDDsy5 ldDPE78AGtINU3uBC3MattADGzQNsobbYjzm4aLq7/rEPMiB2PcBx5dwBqSkPubsek6kUSej O3IfbBJrmf51s9r1W1Q4SZNn661W --------------ms54919D64133B781351FE5621-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 15:16:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7NMGB1O026604 for ; Thu, 23 Aug 2001 15:16:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7NMGBl7026603 for ipng-dist; Thu, 23 Aug 2001 15:16:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7NMG71O026596 for ; Thu, 23 Aug 2001 15:16:07 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00781 for ; Thu, 23 Aug 2001 15:16:11 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22680 for ; Thu, 23 Aug 2001 15:16:10 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id SAA04408; Thu, 23 Aug 2001 18:17:08 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA12753; Thu, 23 Aug 2001 18:17:06 -0400 Message-ID: <3B8580D8.2E09350F@txc.com> Date: Thu, 23 Aug 2001 18:16:57 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: brian@hursley.ibm.com, itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: [Fwd: draft-conta-ipv6-flow-label-02.txt] References: <009CA59D1752DD448E07F8EB2F911757197FD6@esebe004.NOE.Nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms3F6FEC29A216D36BD32140FB" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms3F6FEC29A216D36BD32140FB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jarno, I completely agree! Intserv would work fine with ANY other mechanism for selecting flow label values. It does not have to be PRN. Intserv seems to work fine with FILTER_SPEC C-type 1, and 2, i.e. based on "port numbers", which are not PRN. Furthermore, work on classification mechanisms has made such a progress, that "hashing", as lookup for flow state information, as suggested in Appendix A, RFC 2460, is obsolete. Even more, IMHO, it is not the business of a IETF standard, to tell what mechanism to implement for classification, whether is "hashing" or something else. Regards, Alex jarno.rajahalme@nokia.com wrote: > > Brian wrote: > > The distinction made in the proposal by the MSB is between a > > pseudo-random > > value as defined in RFC 2460 Appendix A (for intserv) and a > > non-random value > > (for diffserv). But they are both e2e values, unlike the > > DSCP. This should > > be documented. > > > > But who need any of the values to be pseudo-random? Intserv would work just > fine if the flow label values would be taken out of the sequence 1,2,3,4,... > Intserv signaling should provide for no problem of re-use after reboot > either, since after a reboot the signaling would be done again before any > use of the flow label. > > Jarno --------------ms3F6FEC29A216D36BD32140FB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjMyMjE2NThaMCMGCSqGSIb3DQEJBDEWBBRWfzaqaZdmNS6ZVzlO jj6WqlBaVTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gHCpHY836uz1AhAP1qjqNi6HS/A01us1ndPhTUrj3/s3T97uAWtphi0ZMfBJzd+WhBxHxatc cCsDBuKJ2WLsUgBb6c8525sUi6YH+Rbpfg912QJiqNRZfhhZyWv5y7a0PsRV25j92wc4mdwB sCP2zqNJSk9XbvaH/cV42WaVWioI --------------ms3F6FEC29A216D36BD32140FB-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 17:51:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O0pE1O026793 for ; Thu, 23 Aug 2001 17:51:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7O0pEkn026792 for ipng-dist; Thu, 23 Aug 2001 17:51:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O0pA1O026785 for ; Thu, 23 Aug 2001 17:51:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16608 for ; Thu, 23 Aug 2001 17:51:15 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12782 for ; Thu, 23 Aug 2001 18:51:11 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id UAA06160; Thu, 23 Aug 2001 20:52:12 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id UAA16523; Thu, 23 Aug 2001 20:52:11 -0400 Message-ID: <3B85A530.ADEAA505@txc.com> Date: Thu, 23 Aug 2001 20:52:00 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Hinden CC: Brian E Carpenter , ipng Subject: a), b), c), d), or e) References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0BDE503772D911450810C123" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms0BDE503772D911450810C123 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian, Bob, I respect very much the IPv6 WG, the WG's chairs, and the participants to the thread that Brian started, in an effort to move in the right direction. But in my opinion -- perhaps as usual, less politically correct than Brian -- I do not think that the IPv6 WG has a choice, that we have a choice. IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's IPv6. This puts a tremendous responsibility, but also demands a certain code of conduct, or direction of thinking for all of us. If that is not captured in the charter, I think it should. The IPv6 WG is not a preferential club, or an exclusivist group. The IPv6 WG is not to tell the IETF what standard is good and what standard is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works with, and it supports the other IETF standards. Intserv, and RSVP completed work (WGs closed). Diffserv started is well on its way. They are TWO IETF models for IP QoS, and are both on the IETF standards track. So, in terms of mechanisms to be standardized for the IPv6 flow label, it is no question in my mind that right now WE MUST DO: c) - standardization of the flow label for IP QoS, e.g. Intserv, and Diffserv. The choice is the user's, e.g. end users and network providers, to use or not, one (Intserv), the other (Diffserv), or both, when deploying IPv6. Furthermore, personally, I think that if the IPv6 flow label would have been done right, we would not have MPLS, and IPv6 would have given even more reasons to be adopted/deployed. At this point is too late, if for no other reason than just that MPLS is a IETF standard on its way, and its own right, and that with the current IPv6 header format, the flow label cannot match the efficiency of all MPLS's features anyway. As I think that no standard should be excluded, I think that IPv6 WG should do its best, to make IPv6 work well, friendly with MPLS. Which is in a way [a subset of a)]+c). Regards, Alex P.S. Please note that MPLS labels are forwarding handles, that can also include a QoS hint (Intserv, or Diffserv). Bob Hinden wrote: > > Brian, > > At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote: > >I think the WG needs to decide once and for all whether the flow label is > > a) a CATNIP or MPLS-like routing handle > >or b) a QOS hint for intserv only > >or c) a QOS hint for intserv and diffserv > >or d) a waste of bits > > I would like to suggest another choice: > > e) a set of bits we hold in reserve for the future > > I don't think that we have enough experience to pick between a), b), or c) > now, and think that something might come up in the future where 28 bits in > the IPv6 header might be very useful. This might not have anything to do > with QOS. > > Bob > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms0BDE503772D911450810C123 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjQwMDUyMDFaMCMGCSqGSIb3DQEJBDEWBBRsFw8o0Tfpsy90YNKu I9gcoNZ5jDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gAVsQezdSbuOXWynDp8ojj4mg6VCbw1Nx80MdLD/kNaO9Y+U4hHoSZ1PtreYe4RQ/KExQ2Ou ShhNtVIjL6VjAH6LCJCJRkyco9CJ+R/nWvL5LJZUKM629OGP79UFFZJN8glS7xH39Jk2YFwk +t41ib14mM+ktYVbgTrLrwNezaMD --------------ms0BDE503772D911450810C123-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 18:00:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O10M1O026887 for ; Thu, 23 Aug 2001 18:00:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7O10M8h026886 for ipng-dist; Thu, 23 Aug 2001 18:00:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O10J1O026879 for ; Thu, 23 Aug 2001 18:00:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18007; Thu, 23 Aug 2001 18:00:23 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA25481; Thu, 23 Aug 2001 19:00:42 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id VAA06257; Thu, 23 Aug 2001 21:01:18 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id VAA16753; Thu, 23 Aug 2001 21:01:17 -0400 Message-ID: <3B85A750.715B4853@txc.com> Date: Thu, 23 Aug 2001 21:01:04 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Hinden CC: ipng@sunroof.eng.sun.com, deering@cisco.com, nordmark@eng.sun.com, narten@raleigh.ibm.com Subject: Re: Updated Charter and acronym change References: <4.3.2.7.2.20010622141253.0213ddb0@mailhost.iprg.nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms692FEA0B4284905D081723CF" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms692FEA0B4284905D081723CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, Steve, I think there is an important element that is missing, or I missed from the charter: "The IPv6 WG will make sure that IPv6, as an IETF standard for IP, will support, or work well with the other IETF standard protocols and mechanisms" Regards, Alex Bob Hinden wrote: > > Folks, > > Attached is an updated proposed charter that the chairs and ADs have > reached consensus on. Most of the changes are related to making it current > (i.e., remove completed work items, updated milestones, revise some work > items to reflect current work, etc.). > > After some thought the chairs and ADs think it would be best to also change > the working group acronym from IPng to IPv6. The down side of this is that > new drafts will have to be labeled as IPv6 (i.e., > draft-ietf-ipv6-xxxx-00.txt) and this may cause some additional work > keeping track of existing drafts. The other issue is that the online > version charter at http://www.ietf.org will not list the documents produced > while the working group was named IPng. This is being addressed by > creating a link to the old charter in the new charter. > > Our conclusion is that changing the working group acronym from IPng to IPv6 > will cause some short term annoyances, overall it will be simpler to have > the working group name and acronym match. > > Please let us know if you disagree. > > Thanks, > Bob Hinden and Steve Deering > > p.s. We will also see about making both ipng and ipv6 work for the mailing > list. > > _____________________________________________________________________ > > IP Version 6 Working Group (IPv6) > > Chair(s): > > Bob Hinden > Steve Deering > > Document Editor > > Bob Hinden (hinden@iprg.nokia.com) > > Internet Area Director(s): > > Thomas Narten > Erik Nordmark > > Internet Area Advisor: > > Thomas Narten > > Mailing Lists: > > General Discussion:ipng@sunroof.eng.sun.com > To Subscribe: majordomo@sunroof.eng.sun.com > In Body: in body: subscribe ipng > Archive: ftp://playground.sun.com/pub/ipng/mail-archive > > Web Pages: > > Charter: http://www.ietf.org/html.charters/ipv6-charter.html > Working group info: http://playground.sun.com/ipv6/ > Previous charter: http://www.ietf.org/html.charters/ipngwg-charter.html > > Description of Working Group: > > IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) > is intended to support the continued growth of the Internet, both in > size and capabilities, by offering a greatly increased IP address space > and other enhancements over IPv4. The IP Next Generation (IPng) working > group was originally chartered by the IESG to implement the > recommendations of the IPng Area Directors as outlined at the July 1994 > IETF meeting and in "The Recommendation for the IP Next Generation > Protocol," RFC1752, January 1995. Most of the tasks in that original > charter have been completed, and the core IPv6 protocol specifications > are now on the IETF standards track. > > This charter focuses on completing the remaining work items and providing > a home for IPv6 work that spans multiple IETF working groups. The > working group is being renamed the IP Version 6 Working Group (IPv6) > because it is a better description of the working group's focus. > > The specific working group's ongoing responsibilities are as follows: > > - Complete work from the original charter and follow-on work, as > outlined below. > > - Keep all IPv6 working group documents moving along publication / > standardization track. > > - Serve as a review board and body of competence and coordination for > IPv6 architectural issues that span multiple IETF working groups. > > - Provide a home for IPv6-related work that doesn't fit in an existing > IETF working group and doesn't merit a working group of its own. > > - Provide technical input to the IAB, IANA and Internet Address > Registries with regard to IPv6 address allocation policies and > procedures. > > The list of the working group's current work items is as follows: > > - Revise and advance to Draft Standard the IPv6 Address > Architecture document [RFC 2373] > - Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], > removing the policy aspects that are considered RIR issues. > - Complete work on recommended address-selection algorithms > - Revise ICMPv6 spec [RFC 2463] (scope-exceeded err, no error to > redirect, editorial) > - Revise Generic Tunneling spec [RFC 2473] (add bidirectional > tunnels) > - Update Basic and Advanced API specs [RFC 2553, RFC 2292] > - Complete Scoped Address Architecture spec and any necessary revisions > to other working group drafts required to properly implement support > for IPv6 address scoping > - Work on host-based solutions to site-multihoming problems (in > coordination with multi6) > - Complete work on local IPv6 networking as part of IPv6 > plug-and-play (to be coordinated with other WGs as appropriate, > e.g., dnsext, zeroconf, etc.) > - Document IPv6 renumbering model > - Complete the IPv6 Node Information Queries spec > - Revise and update the base IPv4/IPv6 MIBs and produce a new > consistent set of MIBs that cover IPv4 and IPv6 together. > RFCs to be looked at together: 2011, 2012, 2013, 2096, 2851, > 2452, 2454, 2465, 2466 and possibly 3019. > > New work items not listed above require the approval of the working > group and Internet Area directors before they will be taken on by the > working group. > > The working group would welcome contributions on the following topics > (this is not an exhaustive list): > > - Flow label standardization > - Solutions to other multihoming issues, beyond those specific to > site-multihoming > - Integration of autoconfiguration, mobility, DNS, service discovery > and other technologies to enhance IPv6 plug-and-play > - IPv6 dial-up issues relating to address assignment, use of Neighbor > Discovery, etc. (not including AAA work) > - Specifications for IPv6 over additional media > - Host use of anycast; TCP use of anycast > - Support for multi-link subnets (single subnet spans multiple links) > - Scope-name discovery > - IPv6 protocol extensions to accommodate mobile wireless networks. > > Goals and Milestones: > > Jun 2001 Revise IPv6 Address Architecture and resubmit to IESG for > Draft Standard > > Jul 2001 Revise IPv6 Aggregatable Unicast Addresses and submit for > Draft Standard > > Jul 2001 Resubmit the IPv6 Node Information Queries spec > > Aug 2001 Compete Address Selection specification and submit for Proposed > Standard > > Dec 2001 Update ICMP document and resubmit for Draft Standard > > Dec 2001 Complete DNS Discovery draft and submit for Proposed Standard > > Dec 2001 Update Generic Tunneling specification and resubmit for > Proposed Standard > > Dec 2001 Complete updates to Basic and Advanced API specifications > and submit for Informational > > Mar 2002 Complete Scoped Address Architecture and submit for Proposed > Standard > > May 2002 Submit document describing IPv6 renumbering model for > Informational. > > _____________________________________________________________________ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------ms692FEA0B4284905D081723CF Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjQwMTAxMDhaMCMGCSqGSIb3DQEJBDEWBBSK7gCykmG5xSe/KRMV HVnFqYwApDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gBNSRjH2wkv88QSE/GnwrMkayFTUdEVXuBzPxEmPfVyQg3jxk/ED5+Frs4F5ezsAByvSkWC+ xbF8cQRHLr+zzrXFl+f783nsZvEulO2XBOCnUpvnAFvKaWixxpCtWuetdcf8N1LiYCl3rgiV ATn6hQ2DXzFNqWaTOw8dGPsyDV/E --------------ms692FEA0B4284905D081723CF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 23 21:45:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O4jA1O027159 for ; Thu, 23 Aug 2001 21:45:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7O4jA74027158 for ipng-dist; Thu, 23 Aug 2001 21:45:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7O4j61O027151 for ; Thu, 23 Aug 2001 21:45:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07035 for ; Thu, 23 Aug 2001 21:45:11 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA16406 for ; Thu, 23 Aug 2001 22:45:07 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA20556; Fri, 24 Aug 2001 00:44:36 -0400 Date: Fri, 24 Aug 2001 00:44:36 -0400 (EDT) From: Jim Bound To: Alex Conta Cc: Bob Hinden , Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B85A530.ADEAA505@txc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk given alex's mail and christians I change my vote to "c". but I would like to hear from Steve Deering at this point which could change my vote again. but either we should progress soon or I think we heed Thomas Nartens mail that we may just want to leave all alone for now and the bits MBZ if not used by existing intserv implementations. /jim On Thu, 23 Aug 2001, Alex Conta wrote: > Brian, Bob, > > I respect very much the IPv6 WG, the WG's chairs, and the participants > to the thread that Brian > started, in an effort to move in the right direction. > > But in my opinion -- perhaps as usual, less politically correct than > Brian -- I do not think that the IPv6 WG has a choice, that we have a > choice. > > IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's > IPv6. > > This puts a tremendous responsibility, but also demands a certain code > of conduct, or direction of thinking for all of us. If that is not > captured in the charter, I think it should. > > The IPv6 WG is not a preferential club, or an exclusivist group. The > IPv6 WG is not to tell the IETF what standard is good and what standard > is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works > with, and it supports the other IETF standards. > > Intserv, and RSVP completed work (WGs closed). Diffserv started is well > on its way. They are TWO IETF models for IP QoS, and are both on the > IETF standards track. > > So, in terms of mechanisms to be standardized for the IPv6 flow label, > it is no question in my mind that right now WE MUST DO: > > c) - standardization of the flow label for IP QoS, e.g. Intserv, and > Diffserv. > > The choice is the user's, e.g. end users and network providers, to use > or not, one (Intserv), the other (Diffserv), or both, when deploying > IPv6. > > Furthermore, personally, I think that if the IPv6 flow label would have > been done right, we would not have MPLS, and IPv6 would have given even > more reasons to be adopted/deployed. > > At this point is too late, if for no other reason than just that MPLS is > a IETF standard on its way, and its own right, and that with the current > IPv6 header format, the flow label cannot match the efficiency of all > MPLS's features anyway. > > As I think that no standard should be excluded, I think that IPv6 WG > should do its best, to make IPv6 work well, friendly with MPLS. Which is > in a way [a subset of a)]+c). > > Regards, > Alex > > P.S. Please note that MPLS labels are forwarding handles, that can also > include a QoS hint > (Intserv, or Diffserv). > > > > > Bob Hinden wrote: > > > > Brian, > > > > At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote: > > >I think the WG needs to decide once and for all whether the flow label is > > > a) a CATNIP or MPLS-like routing handle > > >or b) a QOS hint for intserv only > > >or c) a QOS hint for intserv and diffserv > > >or d) a waste of bits > > > > I would like to suggest another choice: > > > > e) a set of bits we hold in reserve for the future > > > > I don't think that we have enough experience to pick between a), b), or c) > > now, and think that something might come up in the future where 28 bits in > > the IPv6 header might be very useful. This might not have anything to do > > with QOS. > > > > Bob > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 03:47:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OAlZ1O027603 for ; Fri, 24 Aug 2001 03:47:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OAlZ5X027602 for ipng-dist; Fri, 24 Aug 2001 03:47:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OAlV1O027595 for ; Fri, 24 Aug 2001 03:47:31 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21279 for ; Fri, 24 Aug 2001 03:47:35 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25271 for ; Fri, 24 Aug 2001 03:47:34 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7OAlx325900 for ; Fri, 24 Aug 2001 13:47:59 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Aug 2001 13:47:33 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV6LC8>; Fri, 24 Aug 2001 13:47:32 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE9@esebe004.NOE.Nokia.com> To: huitema@windows.microsoft.com, brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Fri, 24 Aug 2001 13:47:26 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, I still believe that "bits are bits". As you pointed out, there is no certainty that a packet to port 80 will carry HTTP. Therefore we should not pretend to know. Any classification based on this "make believe" is inherently flawed (IHO). The DSCP (for diffserv) and address + flow label (for intserv) are all that is needed for determining the right treatment for the packet. Information theory wise, the port number stuff you propose is either redundant or a mistake (the latter in the case of ESP with non-NULL encryption). The last thing the Internet needs is "content based charging" for transport, or "good QoS for supported (read $$$) applications only", both scenarios likely if the scheme you propose would be in place. Then again, I might be wrong :-) Jarno > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@windows.microsoft.com] > Sent: 23. elokuuta 2001 3:49 > To: Brian E Carpenter > Cc: ipng > Subject: RE: Higher level question about flow label > > > > On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote: > > > I think the WG needs to decide once and for all whether the flow > label > > is > > > a) a CATNIP or MPLS-like routing handle > > > or b) a QOS hint for intserv only > > > or c) a QOS hint for intserv and diffserv > > > or d) a waste of bits > > I think that the most useful use is probably (c). Option (a) is not > terribly interesting: if you want to do MPLS, just insert an MPLS > header; MP in MPLS stands for multi-protocol, which means that MPLS is > always going to have a "layer of indirection" for v4, v6, and whatever > else the ISP wants to run on it. Option (b) really means "a set of > random bits" and is not terribly useful either: it would require that > the routers trusts the random generation in the hosts, which is not > going to happen (the trust, I mean.) > > Option (c) really means "tell me something useful about the content of > the packet so I can use it for classification." Suppose I > place here the > port number that identifies the service, e.g. 25 for mail, 80 for web, > etc., plus an indication of whether this is UDP or TCP. This plus the > addresses would enable some easy filtering into intserv or diffserv > classifications, without requiring that the router go deep into the > header chain. It would enable easy traffic statistics. It > would be easy > to implement for the host (pick the lowest of dest or source port.) It > would work even if the packet is encrypted. We could reserve > values for > specific traffics, e.g. RTP-audio, RTP-video. It would work even if we > use ESP. From an information theory point of view, this looks > much more > useful than either random bits or null values. > > Indeed, the bits will have to be set by the host. But then, so are the > port numbers. Nothing prevent cooperating hosts from running NFS over > port 80... In fact, if the router is willing to inspect the > full header > chain, it could rewrite the bits to a "trusted" value. Also, > some hosts > may not be willing to provide the information, e.g. when they actually > want to hide the nature of the encrypted traffic; these hosts > could use > a null field, which would be classified to some default rule by the > diffserv filters (you cannot have it both ways.) > > Count my vote for (c). > > -- Christian Huitema > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 03:49:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OAnO1O027626 for ; Fri, 24 Aug 2001 03:49:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OAnNCN027625 for ipng-dist; Fri, 24 Aug 2001 03:49:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OAnJ1Q027612 for ; Fri, 24 Aug 2001 03:49:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01840 for ; Fri, 24 Aug 2001 03:24:04 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA10162 for ; Fri, 24 Aug 2001 04:23:58 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7OAOR315291 for ; Fri, 24 Aug 2001 13:24:27 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Aug 2001 13:24:00 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV6JY0>; Fri, 24 Aug 2001 13:24:00 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FE8@esebe004.NOE.Nokia.com> To: aconta@txc.com, hinden@iprg.nokia.com Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Fri, 24 Aug 2001 13:23:46 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, I don't think it has been shown yet, that the diffserv architecture actually needs any specific support from the IPv6 flow label. While the MF-classification is mentioned in the diffserv architecture, the value of that on the administrative boundaries is less than clear. An SLA between two domains could well be specified to only consider DSCP values, and the associated PHB, volume, charging, etc. Could someone please explain why this could not work, and what specifically is the value of signaling the PHB in the flow label field? Jarno > -----Original Message----- > From: ext Alex Conta [mailto:aconta@txc.com] > Sent: 24. elokuuta 2001 3:52 > To: Hinden Bob (IPRG) > Cc: Brian E Carpenter; ipng > Subject: a), b), c), d), or e) > > > Brian, Bob, > > I respect very much the IPv6 WG, the WG's chairs, and the participants > to the thread that Brian > started, in an effort to move in the right direction. > > But in my opinion -- perhaps as usual, less politically correct than > Brian -- I do not think that the IPv6 WG has a choice, that we have a > choice. > > IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's > IPv6. > > This puts a tremendous responsibility, but also demands a certain code > of conduct, or direction of thinking for all of us. If that is not > captured in the charter, I think it should. > > The IPv6 WG is not a preferential club, or an exclusivist group. The > IPv6 WG is not to tell the IETF what standard is good and > what standard > is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that > IPv6 works > with, and it supports the other IETF standards. > > Intserv, and RSVP completed work (WGs closed). Diffserv > started is well > on its way. They are TWO IETF models for IP QoS, and are both on the > IETF standards track. > > So, in terms of mechanisms to be standardized for the IPv6 flow label, > it is no question in my mind that right now WE MUST DO: > > c) - standardization of the flow label for IP QoS, e.g. Intserv, and > Diffserv. > > The choice is the user's, e.g. end users and network providers, to use > or not, one (Intserv), the other (Diffserv), or both, when deploying > IPv6. > > Furthermore, personally, I think that if the IPv6 flow label > would have > been done right, we would not have MPLS, and IPv6 would have > given even > more reasons to be adopted/deployed. > > At this point is too late, if for no other reason than just > that MPLS is > a IETF standard on its way, and its own right, and that with > the current > IPv6 header format, the flow label cannot match the efficiency of all > MPLS's features anyway. > > As I think that no standard should be excluded, I think that IPv6 WG > should do its best, to make IPv6 work well, friendly with > MPLS. Which is > in a way [a subset of a)]+c). > > Regards, > Alex > > P.S. Please note that MPLS labels are forwarding handles, > that can also > include a QoS hint > (Intserv, or Diffserv). > > > > > Bob Hinden wrote: > > > > Brian, > > > > At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote: > > >I think the WG needs to decide once and for all whether > the flow label is > > > a) a CATNIP or MPLS-like routing handle > > >or b) a QOS hint for intserv only > > >or c) a QOS hint for intserv and diffserv > > >or d) a waste of bits > > > > I would like to suggest another choice: > > > > e) a set of bits we hold in reserve for the future > > > > I don't think that we have enough experience to pick > between a), b), or c) > > now, and think that something might come up in the future > where 28 bits in > > the IPv6 header might be very useful. This might not have > anything to do > > with QOS. > > > > Bob > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 03:49:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OAnc1O027629 for ; Fri, 24 Aug 2001 03:49:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OAncUr027628 for ipng-dist; Fri, 24 Aug 2001 03:49:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OAnJ1O027612 for ; Fri, 24 Aug 2001 03:49:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02004 for ; Fri, 24 Aug 2001 03:25:35 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA22591 for ; Fri, 24 Aug 2001 04:25:52 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7OANVl01924; Fri, 24 Aug 2001 17:23:33 +0700 (ICT) From: Robert Elz To: Alex Conta cc: Bob Hinden , Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B85A530.ADEAA505@txc.com> References: <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Aug 2001 17:23:31 +0700 Message-ID: <1922.998648611@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 23 Aug 2001 20:52:00 -0400 From: Alex Conta Message-ID: <3B85A530.ADEAA505@txc.com> To be even less politically correct ... | The IPv6 WG is not a preferential club, or an exclusivist group. The | IPv6 WG is not to tell the IETF what standard is good and what standard | is bad. That is true, but | While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works | with, and it supports the other IETF standards. that is simple nonsense. There are all kinds of IETF standards around - a proportion of them are utter crap. In general, that is no problem - the vast majority of the rubbish that is proposed, worked on, and then progressed can simply be ignored - I know it is never going to affect me, because I am going to ignore it forever. But, if you're trying to tell us all that we have to go look at every IETF standard (and by that I assume you mean PS and up, as there aren't actually all that many full standards) and make sure that they are supported by IPv6, then you're way off base. Rather, if there are people who actually care about the other work, and need it to be supported, and they don't think it is, then they need to come to ipngwg (or whatever the name is this week) and argue for it. Make a persuasive case for some proposal, and whatever support is needed & possible is likely to appear. On the other hand, if ipngwg doesn't accept your request, then tough. Up to this point, exactly the right thing had been happening here, with the request, and the debate (with no clear decision yet that I could make out). But attempting to tell the WG that our hands are tied because some other WG claims to need some feature or other is way off base. The equivalent would be if ipngwg sent a message to diffserv saying that they had to make things work with nothing more than a random number, addresses, and encrypted payload, because that's all they're getting - after all, IPv6 is a much more mature standard than diffserv. By your reasoning, diffserv would be compelled to support IPv6 that way. I actually treat this message as a concession that there are no strong enough arguments that can be made to ipngwg that would cause model (c) for the flow label to be adopted. 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 Aug 24 03:58:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OAwp1O027667 for ; Fri, 24 Aug 2001 03:58:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OAwpNR027666 for ipng-dist; Fri, 24 Aug 2001 03:58:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OAwl1O027659 for ; Fri, 24 Aug 2001 03:58:47 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA10013 for ; Fri, 24 Aug 2001 03:58:51 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29265 for ; Fri, 24 Aug 2001 03:58:50 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7OAxF301104 for ; Fri, 24 Aug 2001 13:59:15 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 24 Aug 2001 13:58:49 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV6LXY>; Fri, 24 Aug 2001 13:58:49 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D4AA@esebe004.NOE.Nokia.com> To: aconta@txc.com, brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Fri, 24 Aug 2001 13:58:47 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, My point was that even in the case of a router doing both diffserv and intserv if could tell the flow labels apart by the signaling that was done for intserv. As a HW person, could you enlighten me if the flow label look-up for a packet ("data plane") would need to be different in the intserv and diffserv cases? My understanding has been that the difference would remain only in the population of the flow-label tables/data ("control plane"). Jarno > -----Original Message----- > From: ext Alex Conta [mailto:aconta@txc.com] > Sent: 24. elokuuta 2001 0:46 > To: Brian E Carpenter > Cc: Rajahalme Jarno (NRC/Helsinki); ipng@sunroof.eng.sun.com > Subject: Re: Higher level question about flow label > > > Brian, > > You covered the essence, so, I will just expend a little on the use of > MSB: > > The differentiation between Intserv, and Diffserv flow label values is > helpful when a. and b. bellow are both true: > > a. - packet source nodes send both Intserv and Diffserv > traffic to the > same router, or set of routers, and > b. - the router or the set of routers receiving the Intserv and > Diffserv traffic, do both Intserv and Diffserv classification. > > If b. is not true, e.g. the router, or set of routers do Intserv, or > Diffserv, but not both in the same time, then the > differentiation is not > really necessary. Can we be sure that b. is not true. > I do not think so. > > If a. is true, it is sufficient for the source node to pick up flow > label values from two distinct sets of numbers. The set can be > interleaved, as long, as the Diffserv values are known the router(s), > and the Intserv values are signaled to the routers. For instance 1, 2, > 4, 7 can be Intserv, 3, 5, 6 can be Diffserv. 1, 2, 4, 7 are > signaled to > the routers, 3, 5, 6 are known to the routers. Using MSB draws a > separation line that makes things simple. > > Jarno's idea to have just one way of setting the bits in the > flow label > has value, if we leave to the source node the problem of making sure > Intserv and Diffserv values do not overlap, or if we make sure that a > router would never do both Intserv, and DIffserv > classification. If the > values overlap, it is OK, as long as NO router does both Intserv, and > Diffserv. If a router does > both Intserv, and Diffserv, and values overlap, then the > result is quite > unpredictable. > > Regards, > Alex > > > Brian E Carpenter wrote: > > > > I certainly don't care about the pseudo-random requirement > for unique-per-host > > opaque flow labels, but if we agree that the flow label may > be used for diffserv > > then it has to have semantics (i.e. it is not an opaque > value). For that I am sure > > we need the MSB as a flag bit, so that a classifier can > tell whether it is looking > > at an opaque value or at a value with semantics. > > > > Brian > > > > jarno.rajahalme@nokia.com wrote: > > > > > > Brian, > > > > > > Let's then just say that it would be architecturally > better to only have one > > > format that satisfies all the needs. With better I mean > things like less > > > text in the specification, simpler implementations, less > bugs, better > > > interoperability etc. > > > > > > At this point no-one has established that there is a need > or a requirement > > > for multiple formats of flow labels. You and Alex have > brought up a > > > requirement that the flow label value needs to be somehow > constant for the > > > diffserv for a form of MF classification for diffserv > usage. The traditional > > > intserv has no requirement to the specific value being > used, as the value is > > > being explicitly signaled. > > > > > > It seems that both the old ("intserv") and new > ("diffserv") requirements can > > > be met with single flow label format (current format with > no pseudo-random > > > requirement). > > > > > > Earlier it has been thought that the pseudo-random nature > of the flow label > > > would make lookups easier by allowing the flow label to > be used as a hash as > > > such. There are some specific difficulties with this, however: > > > > > > 1) Routers can not know how good pseudo random numbers > the flow-labels > > > injected by hosts are in practice. Bad pseudo random > numbers used by large > > > class of hosts could constitute a kind of DoS attack > against router > > > implementations relying on the pseudo-random number > nature of the flow > > > label. [Maybe someone actually implementing look-ups on > hardware based on > > > the flow label could bring additional light on this > matter (Alex?)] > > > > > > 2) If there is an alternative format, that is not > pseudo-random (as being > > > proposed), the routers will have to implement look-ups > that function > > > efficiently with that format. Since we do not know what > portion of the > > > traffic in the future would use this non-pseudo-random format, the > > > implementations have to assume that all traffic can be > labeled with this > > > alternative format. > > > > > > It follows that there is no additional benefit of the > pseudo-random nature > > > of the original format. Therefore it would be best to > combine these formats > > > into one, that is non-pseudo-random. I.e. the current > format with no > > > pseudo-random requirement. This would present the minimal > change to the > > > current specification. Also, current (intserv) > implementations could keep on > > > using the current pseudo-random numbers without breaking anything. > > > > > > Jarno > > > > > > > -----Original Message----- > > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: 21. elokuuta 2001 23:31 > > > > To: jarno.rajahalme@nokia.com > > > > Cc: seamus@bit-net.com; thomas.eklund@xelerated.com; > aconta@txc.com; > > > > narten@raleigh.ibm.com; hinden@iprg.nokia.com; > > > > ipng@sunroof.eng.sun.com > > > > Subject: Re: Higher level question about flow label > > > > > > > > > > > > Jarno, > > > > > > > > The Carpenter/Conta proposal does include two formats for the > > > > label (one aimed > > > > at intserv flows and one aimed at diffserv flows), but if you > > > > use the field > > > > only for rapid routing lookup, you don't care about that; in > > > > both cases you can treat > > > > the label as 20 opaque bits I think. > > > > > > > > You only care which format it is when you are doing specific > > > > intserv or diffserv > > > > packet classification. > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 09:45:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGjC1O028484 for ; Fri, 24 Aug 2001 09:45:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OGjC49028483 for ipng-dist; Fri, 24 Aug 2001 09:45:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGj81O028476 for ; Fri, 24 Aug 2001 09:45:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17898 for ; Fri, 24 Aug 2001 09:45:13 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26861 for ; Fri, 24 Aug 2001 10:45:08 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA21600; Fri, 24 Aug 2001 17:45:09 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA33910; Fri, 24 Aug 2001 17:45:10 +0100 Message-ID: <3B8683DE.10E3A88D@hursley.ibm.com> Date: Fri, 24 Aug 2001 11:42:06 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757197FDF@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My understanding is different. I thought that diffserv classifiers would learn and cache the flow ID from the first packet of an intserv flow, such that for subsequent packets they can classify simply on the 2uple {source address, flow label}. You don't seem to accept that there is a fundamental difference between intserv classifiers (which are specific to microflows) and diffserv classifiers (which are specific to traffic classes and blind to microflows). This is why there have to be two formats if we want to support both intserv and diffserv with the flow label. Brian jarno.rajahalme@nokia.com wrote: > > Brian, > > Current (intserv) usage requires signaling to convey the semantics for the > opaque flow label values. The diffserv usage would allow the flow label > itself to function as a pointer to the semantics (taken out of configuration > file or equivalent). In both cases the classifier will most likely do same > kind of a search on the flow label, but the population of the data found for > the matching entry is different (configuration vs. signaling). > > Also, an source knowing about well known values would know not to use those > values for opaque ones. Additionally, it might not be harmful even if it > would be possible to signal a specific (overloaded) semantics for a "well > known" flow label (for a specific source). > > I'm assuming here that the only difference between the two cases being > discussed (from the classification point-of-view) is that for the intserv > case the same flow label value would carry the same semantics for all > possible sources, while the semantics for the opaque values are specific to > the source IP address. > > Jarno > > > -----Original Message----- > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > Sent: 22. elokuuta 2001 22:54 > > To: Rajahalme Jarno (NRC/Helsinki) > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: Higher level question about flow label > > > > > > I certainly don't care about the pseudo-random requirement > > for unique-per-host > > opaque flow labels, but if we agree that the flow label may > > be used for diffserv > > then it has to have semantics (i.e. it is not an opaque > > value). For that I am sure > > we need the MSB as a flag bit, so that a classifier can tell > > whether it is looking > > at an opaque value or at a value with semantics. > > > > Brian > > > > jarno.rajahalme@nokia.com wrote: > > > > > > Brian, > > > > > > Let's then just say that it would be architecturally better > > to only have one > > > format that satisfies all the needs. With better I mean > > things like less > > > text in the specification, simpler implementations, less > > bugs, better > > > interoperability etc. > > > > > > At this point no-one has established that there is a need > > or a requirement > > > for multiple formats of flow labels. You and Alex have brought up a > > > requirement that the flow label value needs to be somehow > > constant for the > > > diffserv for a form of MF classification for diffserv > > usage. The traditional > > > intserv has no requirement to the specific value being > > used, as the value is > > > being explicitly signaled. > > > > > > It seems that both the old ("intserv") and new ("diffserv") > > requirements can > > > be met with single flow label format (current format with > > no pseudo-random > > > requirement). > > > > > > Earlier it has been thought that the pseudo-random nature > > of the flow label > > > would make lookups easier by allowing the flow label to be > > used as a hash as > > > such. There are some specific difficulties with this, however: > > > > > > 1) Routers can not know how good pseudo random numbers the > > flow-labels > > > injected by hosts are in practice. Bad pseudo random > > numbers used by large > > > class of hosts could constitute a kind of DoS attack against router > > > implementations relying on the pseudo-random number nature > > of the flow > > > label. [Maybe someone actually implementing look-ups on > > hardware based on > > > the flow label could bring additional light on this matter (Alex?)] > > > > > > 2) If there is an alternative format, that is not > > pseudo-random (as being > > > proposed), the routers will have to implement look-ups that function > > > efficiently with that format. Since we do not know what > > portion of the > > > traffic in the future would use this non-pseudo-random format, the > > > implementations have to assume that all traffic can be > > labeled with this > > > alternative format. > > > > > > It follows that there is no additional benefit of the > > pseudo-random nature > > > of the original format. Therefore it would be best to > > combine these formats > > > into one, that is non-pseudo-random. I.e. the current format with no > > > pseudo-random requirement. This would present the minimal > > change to the > > > current specification. Also, current (intserv) > > implementations could keep on > > > using the current pseudo-random numbers without breaking anything. > > > > > > Jarno > > > > > > > -----Original Message----- > > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > Sent: 21. elokuuta 2001 23:31 > > > > To: jarno.rajahalme@nokia.com > > > > Cc: seamus@bit-net.com; thomas.eklund@xelerated.com; > > aconta@txc.com; > > > > narten@raleigh.ibm.com; hinden@iprg.nokia.com; > > > > ipng@sunroof.eng.sun.com > > > > Subject: Re: Higher level question about flow label > > > > > > > > > > > > Jarno, > > > > > > > > The Carpenter/Conta proposal does include two formats for the > > > > label (one aimed > > > > at intserv flows and one aimed at diffserv flows), but if you > > > > use the field > > > > only for rapid routing lookup, you don't care about that; in > > > > both cases you can treat > > > > the label as 20 opaque bits I think. > > > > > > > > You only care which format it is when you are doing specific > > > > intserv or diffserv > > > > packet classification. > > > > > > > > Brian > > > > > > > > jarno.rajahalme@nokia.com wrote: > > > > > > > > > > Jim, > > > > > > > > > > Nice rant :-) > > > > > > > > > > Could you elaborate on the pseudo-random nature of the flow > > > > label. It seems > > > > > to me that if it did not need to be pseudo-random, people > > > > could go on > > > > > "signaling off-line" about the flow label values (in SLAs, > > > > this seems to be > > > > > what Alex & Brian want). I see no harm in allowing such > > > > practice, but it > > > > > would be best if there is only one format for the flow > > > > label, as it would be > > > > > faster to decode. > > > > > > > > > > Jarno > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Jim Bound [mailto:seamus@bit-net.com] > > > > > > Sent: 21. elokuuta 2001 15:58 > > > > > > To: Thomas Eklund > > > > > > Cc: 'Alex Conta'; Thomas Narten; Brian E Carpenter; Bob > > > > Hinden; ipng > > > > > > Subject: RE: Higher level question about flow label > > > > > > > > > > > > > > > > > > thomas, > > > > > > > > > > > > that is why if we can treat the flowlabel as part of > > > > tuple with src > > > > > > address and identify a connection which identifies the > > > > forwarding path > > > > > > the challenge is reduced. there is nothing needed but the > > > > > > header for the > > > > > > look up and forward. I believe this can be made to work. > > > > > > > > > > > > the traffic class will provide diff serv metric and the flow > > > > > > identifies > > > > > > the E2E connection with the src addr. > > > > > > > > > > > > The src addr MUST be a global address. > > > > > > > > > > > > Site-Local can be done too but don't want to get into > > > > that right now. > > > > > > > > > > > > One can ask if the Ipv6 address is global why have the > > > > flow for per > > > > > > connection as above. This is a good question and needs > > > > discussion. > > > > > > > > > > > > First the flow assists with the lookup in a binary tree, > > > > > > queue type, or > > > > > > archaic hash. Its the hint to the next leaf, bucket, or > > > > queue entry. > > > > > > duplicat highorder bits would cause a branch. This could > > > > speed up the > > > > > > search before even getting to the global address. > > > > > > > > > > > > The src + flow could also be used as label for MPLS and its > > > > > > in the IPv6 > > > > > > header. > > > > > > > > > > > > The business reason could also be that end users would > > > > create SLAs for > > > > > > their flow labels in addition the bits set for the traffic > > > > > > class. This is > > > > > > how QOS Int Serv could be realized. And I guess conjunct > > > > > > with diff serv > > > > > > but that would need to be specified too. > > > > > > > > > > > > This also benefits client and server boxes too (gateways > > > > > > too). We can now > > > > > > potentially keep one protocol control block for user > > > > connections. tcp, > > > > > > sctp, and dcp per connection data structures would not > > > > have to be kept > > > > > > above the internet per connection datastructures (e.g. bsd > > > > > > inpcb would be > > > > > > enough). This is a performance win for clients and servers > > > > > > for IPv6 not > > > > > > just routers or switches or gateways. > > > > > > > > > > > > If we put a length in the flow yes it can be made to work but > > > > > > not without > > > > > > being verified by the router as the packet is parsed or > > > > > > "policed" then we > > > > > > have just put new processing far worse than the IP > > > > checksum which we > > > > > > removed from the IPv6 router. And opens up opportunity for > > > > > > bugs at that > > > > > > code point we don't have today. > > > > > > > > > > > > I also don't support the field being mutable as it transits > > > > > > the network > > > > > > path to the end destination. > > > > > > > > > > > > The reason is that we should make IPv6 E2E perform in the > > > > > > network as fas > > > > > > as possible. If you look at all the work to do VPN, L2TP, > > > > > > NAT, Virtual > > > > > > Routing, et al that is emerging pervasive for IPv4 the root > > > > > > reasons are > > > > > > lack of IPv4 address space, the desire to do fast layer 2 > > > > > > switching, and > > > > > > security inspection (e.g. firewalls). > > > > > > > > > > > > The later two above are the only valid visions. We need to > > > > > > eliminate in > > > > > > our thinking the mind set developed because of lack of IPv4 > > > > > > address space. > > > > > > I could argue that what is happening to IPv4 is pure > > professional > > > > > > irresponsibility on our part as Internet engineers. The > > > > > > Internet should > > > > > > remain E2E. This is not a politcal comment or even social > > > > > > comment. Its a > > > > > > comment stating my assumptions about how the Internet > > > > should operate. > > > > > > > > > > > > I think we need to discuss our assumptions for the > > > > > > requirements with the > > > > > > solutions we define. > > > > > > > > > > > > ADSL box providers actually market that NAT helps you because > > > > > > you don't > > > > > > have to worry about address space. This is absurd and > > > > professionally > > > > > > irresponsible in the market. We should stop this with IPv6. > > > > > > > > > > > > The way to do that is give routers the means to forward > > > > packets E2E by > > > > > > only looking at the header of IPv6. That is what Brian's > > > > "b" solution > > > > > > does. Plus it benefits all nodes besides routes for IPv6 > > > > as I state > > > > > > above. > > > > > > > > > > > > As far as IPv6 extensions. The payload length gives the > > > > > > router the entire > > > > > > length of the packet. If the flowlabel can be used to > > > > > > identify forwarding > > > > > > the packet in addition to the address and other parts as > > > > I state above > > > > > > then there is no challenge for ASIC vendors for strict > > > > > > forwarding of IPv6 > > > > > > packets. > > > > > > > > > > > > If those vendors want to add more value by digging past the > > > > > > header then > > > > > > that is their option to add value but I don't believe it is > > > > > > required for > > > > > > fast forwarding of IPv6 packets. > > > > > > > > > > > > Steve's design works and I believe can be extended with the > > > > > > flowlabell and > > > > > > we can get rid of the mess IPv4 is making of the Internet > > > > > > because of the > > > > > > band-aids being applied. > > > > > > > > > > > > I believe the End System (and that could be a router in some > > > > > > cases or a > > > > > > broker router) should set the flowlabel at the access > > > > exit before the > > > > > > edge. But thats another discussion. > > > > > > > > > > > > Another discussion is how do we pick good random numbers for > > > > > > the flowlabel > > > > > > at the access exit end system or even a client. > > > > > > > > > > > > regards, > > > > > > /jim > > > > > > > > > > > > > > > > > > On Tue, 21 Aug 2001, Thomas Eklund wrote: > > > > > > > > > > > > > I agree alex. > > > > > > > > > > > > > > It gets worse for people that are doing ASIC which is not > > > > > > programmable, then > > > > > > > they need to spin a new version their ASIC when the > > > > > > protocols changes. For > > > > > > > people that are doing programmable ASIC (network processors > > > > > > etc) this is not > > > > > > > a problem. > > > > > > > > > > > > > > But common for both approaches is that the header format is > > > > > > really challenge > > > > > > > for the ASIC engineers > > > > > > > > > > > > > > -- thomas > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > >From: Alex Conta [mailto:aconta@txc.com] > > > > > > > >Sent: den 20 augusti 2001 22:15 > > > > > > > >To: Thomas Narten > > > > > > > >Cc: Brian E Carpenter; Bob Hinden; ipng > > > > > > > >Subject: Re: Higher level question about flow label > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Thomas Narten wrote: > > > > > > > >> > > > > > > > >> [...] When someone can make a compelling argument for why > > > > > > > >> the bits need to be defined in a certain way (i.e., > > > > > > there is a real > > > > > > > >> application for which using the bits provides > > > > > > significant benefits, > > > > > > > >> and those benefits do not appear achievable through > > > > > > other means) that > > > > > > > >> is the time to define the bits. What I do sense with > > > > many of the > > > > > > > >> recent discussions surrounding the Flow Label is that > > > > > > there are many > > > > > > > >> folks (i.e., folks putting IPv6 into hardware) that want > > > > > > to know what > > > > > > > >> they should implement w.r.t. the Flow Label. > > While it would > > > > > > > >be nice to > > > > > > > >> be able tell them what to do, we shouldn't standardize > > > > > > something just > > > > > > > >> for the sake of having a definition. > > > > > > > >> > > > > > > > >> Thomas > > > > > > > > > > > > > > > >10Gb/sec time wise means 100 psec/bit, or 0.8 nsec per > > > > byte, or 3.2 > > > > > > > >instructions of a hypothetical > > > > > > > >1Ghz processor which can execute one instruction per > > > > > > cycle. That's a > > > > > > > >hell of a requirement. > > > > > > > > > > > > > > > >As consumers, we all enjoy the very cost-effective > > > > availability of > > > > > > > >100Mb/sec line speed packet processing in almost every > > > > > > > >Notebook, or PC. > > > > > > > > > > > > > > > >IP and QoS Engines implemented in silicon, on a chip or a > > > > > > few chips, by > > > > > > > >IBM, INTEL, and many, many others, is one of the > > > > reasons of the low > > > > > > > >costs, along with the ability to optimizing the hardware > > > > > > > >in so many more and different ways than the software > > > > (for instance > > > > > > > >parallel header, or parallel header field processing). > > > > > > > > > > > > > > > >1Gb/sec IPv4 packet forwarding is a reality, > > 10Gb/sec is just > > > > > > > >around the > > > > > > > >corner, with 40Gb/sec following not long after. > > > > > > > > > > > > > > > >With such drastic "timing" requirements, implementing > > > > engines in > > > > > > > >silicon, and inventing *clever* mechanisms to handle > > > > the sequential > > > > > > > >processing of headers alone, will not be sufficient to > > > > > > implement very > > > > > > > >cost-effective IPv6 forwarding and QoS solutions, and > > > > IPv6 is at a > > > > > > > >disadvantage relative to IPv4. > > > > > > > > > > > > > > > >We need all the help we can get from the protocol, that is > > > > > > headers, and > > > > > > > >their fields, for forwarding and QoS processing, > > and by that I > > > > > > > >mean both > > > > > > > >Intserv, and Diffserv. > > > > > > > > > > > > > > > >Regards, > > > > > > > >Alex > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 09:48:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGma1O028519 for ; Fri, 24 Aug 2001 09:48:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OGma94028518 for ipng-dist; Fri, 24 Aug 2001 09:48:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGmW1O028511 for ; Fri, 24 Aug 2001 09:48:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29021 for ; Fri, 24 Aug 2001 09:48:37 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29654; Fri, 24 Aug 2001 10:48:31 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA14460; Fri, 24 Aug 2001 17:48:32 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA20840; Fri, 24 Aug 2001 17:48:28 +0100 Message-ID: <3B868499.FDF9CC90@hursley.ibm.com> Date: Fri, 24 Aug 2001 11:45:13 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: sommerfeld@east.sun.com, Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label References: <15234.49245.24268.283937@thomasm-u1.cisco.com> <200108222105.f7ML5d012677@thunk.east.sun.com> <15236.8827.323100.546364@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The issue is that if the packet is classified prior to being encrypted, what do you do if a downstream ISP declines to believe the classification (DCSP value) and wishes to reclassify the packet? The proposal is to put enough semantics in the flow label to allow some degree of classification. Brian Michael Thomas wrote: > > Bill Sommerfeld writes: > > > Huh? I thought that one of the requirements for ESP was to > > > copy the DSCP to the outer header. If I recall correctly, > > > this bothers some people from a traffic analysis standpoint, > > > but that seems to be part and parcel with QoS so that doesn't > > > hold much water IMO. > > > > It seems that it would be appropriate for an implementation to > > "reclassify" packets at the time of encapsulation into ESP -- the > > packet is, after all, going through a logical trust boundary as it's > > being encrypted.. > > If I understand Brian's concern correctly, that may > not necessarily be the case. The security gateway may > be on egress from my network and hence controlled by me. > If the service provider wants to reclassify those packets, > it would need to be done at the next hop router from the > security gateway (ie on a router they controlled). > > I'm still not sure I understand the policing they are > trying to accomplish though; it seems sort of weird > to have port level classification on the other side of the > trust boundary to set the proper DSCP, unless it's just > provide a service that could (should?) have been done at > your egress router. Otherwise it seems like > the user would be shooting themselves in the foot since > the normal method is for the policer to police to a > certain SLA on a given aggregate traffic class. This > to my mind would argue for the classification to be > done on *before* it is encapsulated with ESP, but the > policing done on the aggregate where it doesn't care > about the port data. > > Ie: > > luserdata------------>SG---------------------->AR > (classifies, (polices > remarks dscp, SLA against > encrypts) DSCP, remarks) > > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 09:56:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGuk1O028542 for ; Fri, 24 Aug 2001 09:56:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OGukRZ028541 for ipng-dist; Fri, 24 Aug 2001 09:56:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OGug1O028534 for ; Fri, 24 Aug 2001 09:56:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04164 for ; Fri, 24 Aug 2001 09:56:42 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05290 for ; Fri, 24 Aug 2001 10:56:34 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA23618; Fri, 24 Aug 2001 17:56:34 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA53056; Fri, 24 Aug 2001 17:56:35 +0100 Message-ID: <3B868673.99703BB5@hursley.ibm.com> Date: Fri, 24 Aug 2001 11:53:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F91175715D4AA@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As I just said - I don't believe the flow label is signalled in the intserv model - but you are on a good point, the classifier at the input to a router that is running both intserv and diffserv has to kick the packets into one of three paths (intserv, diffserv, default). For that choice the flow label should be an opaque value; it would only be treated as having semantics within the diffserv path. Brian jarno.rajahalme@nokia.com wrote: > > Alex, > > My point was that even in the case of a router doing both diffserv and > intserv if could tell the flow labels apart by the signaling that was done > for intserv. > > As a HW person, could you enlighten me if the flow label look-up for a > packet ("data plane") would need to be different in the intserv and diffserv > cases? My understanding has been that the difference would remain only in > the population of the flow-label tables/data ("control plane"). > > Jarno > > > -----Original Message----- > > From: ext Alex Conta [mailto:aconta@txc.com] > > Sent: 24. elokuuta 2001 0:46 > > To: Brian E Carpenter > > Cc: Rajahalme Jarno (NRC/Helsinki); ipng@sunroof.eng.sun.com > > Subject: Re: Higher level question about flow label > > > > > > Brian, > > > > You covered the essence, so, I will just expend a little on the use of > > MSB: > > > > The differentiation between Intserv, and Diffserv flow label values is > > helpful when a. and b. bellow are both true: > > > > a. - packet source nodes send both Intserv and Diffserv > > traffic to the > > same router, or set of routers, and > > b. - the router or the set of routers receiving the Intserv and > > Diffserv traffic, do both Intserv and Diffserv classification. > > > > If b. is not true, e.g. the router, or set of routers do Intserv, or > > Diffserv, but not both in the same time, then the > > differentiation is not > > really necessary. Can we be sure that b. is not true. > > I do not think so. > > > > If a. is true, it is sufficient for the source node to pick up flow > > label values from two distinct sets of numbers. The set can be > > interleaved, as long, as the Diffserv values are known the router(s), > > and the Intserv values are signaled to the routers. For instance 1, 2, > > 4, 7 can be Intserv, 3, 5, 6 can be Diffserv. 1, 2, 4, 7 are > > signaled to > > the routers, 3, 5, 6 are known to the routers. Using MSB draws a > > separation line that makes things simple. > > > > Jarno's idea to have just one way of setting the bits in the > > flow label > > has value, if we leave to the source node the problem of making sure > > Intserv and Diffserv values do not overlap, or if we make sure that a > > router would never do both Intserv, and DIffserv > > classification. If the > > values overlap, it is OK, as long as NO router does both Intserv, and > > Diffserv. If a router does > > both Intserv, and Diffserv, and values overlap, then the > > result is quite > > unpredictable. > > > > Regards, > > Alex > > > > > > Brian E Carpenter wrote: > > > > > > I certainly don't care about the pseudo-random requirement > > for unique-per-host > > > opaque flow labels, but if we agree that the flow label may > > be used for diffserv > > > then it has to have semantics (i.e. it is not an opaque > > value). For that I am sure > > > we need the MSB as a flag bit, so that a classifier can > > tell whether it is looking > > > at an opaque value or at a value with semantics. > > > > > > Brian > > > > > > jarno.rajahalme@nokia.com wrote: > > > > > > > > Brian, > > > > > > > > Let's then just say that it would be architecturally > > better to only have one > > > > format that satisfies all the needs. With better I mean > > things like less > > > > text in the specification, simpler implementations, less > > bugs, better > > > > interoperability etc. > > > > > > > > At this point no-one has established that there is a need > > or a requirement > > > > for multiple formats of flow labels. You and Alex have > > brought up a > > > > requirement that the flow label value needs to be somehow > > constant for the > > > > diffserv for a form of MF classification for diffserv > > usage. The traditional > > > > intserv has no requirement to the specific value being > > used, as the value is > > > > being explicitly signaled. > > > > > > > > It seems that both the old ("intserv") and new > > ("diffserv") requirements can > > > > be met with single flow label format (current format with > > no pseudo-random > > > > requirement). > > > > > > > > Earlier it has been thought that the pseudo-random nature > > of the flow label > > > > would make lookups easier by allowing the flow label to > > be used as a hash as > > > > such. There are some specific difficulties with this, however: > > > > > > > > 1) Routers can not know how good pseudo random numbers > > the flow-labels > > > > injected by hosts are in practice. Bad pseudo random > > numbers used by large > > > > class of hosts could constitute a kind of DoS attack > > against router > > > > implementations relying on the pseudo-random number > > nature of the flow > > > > label. [Maybe someone actually implementing look-ups on > > hardware based on > > > > the flow label could bring additional light on this > > matter (Alex?)] > > > > > > > > 2) If there is an alternative format, that is not > > pseudo-random (as being > > > > proposed), the routers will have to implement look-ups > > that function > > > > efficiently with that format. Since we do not know what > > portion of the > > > > traffic in the future would use this non-pseudo-random format, the > > > > implementations have to assume that all traffic can be > > labeled with this > > > > alternative format. > > > > > > > > It follows that there is no additional benefit of the > > pseudo-random nature > > > > of the original format. Therefore it would be best to > > combine these formats > > > > into one, that is non-pseudo-random. I.e. the current > > format with no > > > > pseudo-random requirement. This would present the minimal > > change to the > > > > current specification. Also, current (intserv) > > implementations could keep on > > > > using the current pseudo-random numbers without breaking anything. > > > > > > > > Jarno > > > > > > > > > -----Original Message----- > > > > > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > > > > > Sent: 21. elokuuta 2001 23:31 > > > > > To: jarno.rajahalme@nokia.com > > > > > Cc: seamus@bit-net.com; thomas.eklund@xelerated.com; > > aconta@txc.com; > > > > > narten@raleigh.ibm.com; hinden@iprg.nokia.com; > > > > > ipng@sunroof.eng.sun.com > > > > > Subject: Re: Higher level question about flow label > > > > > > > > > > > > > > > Jarno, > > > > > > > > > > The Carpenter/Conta proposal does include two formats for the > > > > > label (one aimed > > > > > at intserv flows and one aimed at diffserv flows), but if you > > > > > use the field > > > > > only for rapid routing lookup, you don't care about that; in > > > > > both cases you can treat > > > > > the label as 20 opaque bits I think. > > > > > > > > > > You only care which format it is when you are doing specific > > > > > intserv or diffserv > > > > > packet classification. > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Aug 24 10:05:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OH5q1O028578 for ; Fri, 24 Aug 2001 10:05:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OH5qO6028577 for ipng-dist; Fri, 24 Aug 2001 10:05:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OH5m1O028570 for ; Fri, 24 Aug 2001 10:05:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02470 for ; Fri, 24 Aug 2001 10:05:53 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18830 for ; Fri, 24 Aug 2001 11:06:13 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA23664; Fri, 24 Aug 2001 18:05:49 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA16960; Fri, 24 Aug 2001 18:05:50 +0100 Message-ID: <3B868890.7439C79@hursley.ibm.com> Date: Fri, 24 Aug 2001 12:02:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: aconta@txc.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) References: <009CA59D1752DD448E07F8EB2F911757197FE8@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno, As diffserv WG co-chair I have been making the argument why diffserv will work better with an appropriate format of flow label throughout this discussion, and I think it has been shown that diffserv *does* need such support in the case of ESP headers. Brian jarno.rajahalme@nokia.com wrote: > > Alex, > > I don't think it has been shown yet, that the diffserv architecture actually > needs any specific support from the IPv6 flow label. While the > MF-classification is mentioned in the diffserv architecture, the value of > that on the administrative boundaries is less than clear. > > An SLA between two domains could well be specified to only consider DSCP > values, and the associated PHB, volume, charging, etc. > > Could someone please explain why this could not work, and what specifically > is the value of signaling the PHB in the flow label field? > > Jarno > > > -----Original Message----- > > From: ext Alex Conta [mailto:aconta@txc.com] > > Sent: 24. elokuuta 2001 3:52 > > To: Hinden Bob (IPRG) > > Cc: Brian E Carpenter; ipng > > Subject: a), b), c), d), or e) > > > > > > Brian, Bob, > > > > I respect very much the IPv6 WG, the WG's chairs, and the participants > > to the thread that Brian > > started, in an effort to move in the right direction. > > > > But in my opinion -- perhaps as usual, less politically correct than > > Brian -- I do not think that the IPv6 WG has a choice, that we have a > > choice. > > > > IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's > > IPv6. > > > > This puts a tremendous responsibility, but also demands a certain code > > of conduct, or direction of thinking for all of us. If that is not > > captured in the charter, I think it should. > > > > The IPv6 WG is not a preferential club, or an exclusivist group. The > > IPv6 WG is not to tell the IETF what standard is good and > > what standard > > is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that > > IPv6 works > > with, and it supports the other IETF standards. > > > > Intserv, and RSVP completed work (WGs closed). Diffserv > > started is well > > on its way. They are TWO IETF models for IP QoS, and are both on the > > IETF standards track. > > > > So, in terms of mechanisms to be standardized for the IPv6 flow label, > > it is no question in my mind that right now WE MUST DO: > > > > c) - standardization of the flow label for IP QoS, e.g. Intserv, and > > Diffserv. > > > > The choice is the user's, e.g. end users and network providers, to use > > or not, one (Intserv), the other (Diffserv), or both, when deploying > > IPv6. > > > > Furthermore, personally, I think that if the IPv6 flow label > > would have > > been done right, we would not have MPLS, and IPv6 would have > > given even > > more reasons to be adopted/deployed. > > > > At this point is too late, if for no other reason than just > > that MPLS is > > a IETF standard on its way, and its own right, and that with > > the current > > IPv6 header format, the flow label cannot match the efficiency of all > > MPLS's features anyway. > > > > As I think that no standard should be excluded, I think that IPv6 WG > > should do its best, to make IPv6 work well, friendly with > > MPLS. Which is > > in a way [a subset of a)]+c). > > > > Regards, > > Alex > > > > P.S. Please note that MPLS labels are forwarding handles, > > that can also > > include a QoS hint > > (Intserv, or Diffserv). > > > > > > > > > > Bob Hinden wrote: > > > > > > Brian, > > > > > > At 08:45 AM 8/16/2001 -0500, Brian E Carpenter wrote: > > > >I think the WG needs to decide once and for all whether > > the flow label is > > > > a) a CATNIP or MPLS-like routing handle > > > >or b) a QOS hint for intserv only > > > >or c) a QOS hint for intserv and diffserv > > > >or d) a waste of bits > > > > > > I would like to suggest another choice: > > > > > > e) a set of bits we hold in reserve for the future > > > > > > I don't think that we have enough experience to pick > > between a), b), or c) > > > now, and think that something might come up in the future > > where 28 bits in > > > the IPv6 header might be very useful. This might not have > > anything to do > > > with QOS. > > > > > > Bob > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 10:08:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OH8b1O028615 for ; Fri, 24 Aug 2001 10:08:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OH8bjA028614 for ipng-dist; Fri, 24 Aug 2001 10:08:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OH8X1O028607 for ; Fri, 24 Aug 2001 10:08:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29960 for ; Fri, 24 Aug 2001 10:08:39 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22724 for ; Fri, 24 Aug 2001 10:08:38 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA21644; Fri, 24 Aug 2001 18:08:35 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA53128; Fri, 24 Aug 2001 18:08:35 +0100 Message-ID: <3B868932.AB2D4815@hursley.ibm.com> Date: Fri, 24 Aug 2001 12:04:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Elz CC: Alex Conta , Bob Hinden , ipng Subject: Re: a), b), c), d), or e) References: <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: ... > I actually treat this message as a concession that there are no strong > enough arguments that can be made to ipngwg that would cause model (c) > for the flow label to be adopted. I don't see where you get that from. As I just said to Jarno, a flow label with diffserv semantics enhances the diffserv model in the case of ESP headers. No such enhancement is possible for IPv4. Does the WG want this? Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 24 10:22:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHMl1O028718 for ; Fri, 24 Aug 2001 10:22:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OHMk1J028717 for ipng-dist; Fri, 24 Aug 2001 10:22:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHMh1O028710 for ; Fri, 24 Aug 2001 10:22:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06411 for ; Fri, 24 Aug 2001 10:22:48 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25362 for ; Fri, 24 Aug 2001 11:22:44 -0600 (MDT) Received: from fedex.cisco.com (fedex.cisco.com [171.69.17.28]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7OHN5629103 for ; Fri, 24 Aug 2001 10:23:05 -0700 (PDT) Received: from cisco.com (dhcp-171-69-42-236.cisco.com [171.69.42.236]) by fedex.cisco.com (Mirapoint) with ESMTP id ACC03108 (AUTH mchawla); Fri, 24 Aug 2001 10:22:46 -0700 (PDT) Message-ID: <3B868FA1.BAD959A6@cisco.com> Date: Fri, 24 Aug 2001 10:32:17 -0700 From: Mukul Chawla X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: draft-ietf-ipngwg-uni-based-mcast-02.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Im not clear why draft-ietf-ipngwg-uni-based-mcast-02.txt, Section 3 looks _only_ at IPv6 mcast addresses created by mapping 32 bit IEEE 802 MAC addresses (RFC2373, 2.7.2) rather than creating an SSM service range in IPv6 which uses 112 bit group IDs? What am I missing here? Is there an IPv6 SSM range which uses 112 bit group IDs? Thanks, Mukul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 10:33:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHX01O028748 for ; Fri, 24 Aug 2001 10:33:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OHX0FO028747 for ipng-dist; Fri, 24 Aug 2001 10:33:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHWu1O028740 for ; Fri, 24 Aug 2001 10:32:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12112 for ; Fri, 24 Aug 2001 10:33:02 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05328 for ; Fri, 24 Aug 2001 10:33:00 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7OHWSp03381 for ; Fri, 24 Aug 2001 13:32:33 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Fri, 24 Aug 2001 13:32:34 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R3S8VLX1; Fri, 24 Aug 2001 13:32:32 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5N1YP; Fri, 24 Aug 2001 13:32:32 -0400 Message-ID: <3B868FAD.3737D381@americasm06.nt.com> Date: Fri, 24 Aug 2001 13:32:29 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mukul Chawla CC: "ipng@sunroof.eng.sun.com" Subject: Re: draft-ietf-ipngwg-uni-based-mcast-02.txt References: <3B868FA1.BAD959A6@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukul, For the same reason that RFC 2373 only uses the lower 32 bits for multicast group IDs. It makes the mapping into IEEE 802 multicast MAC addresses less likely to lead to collisions. Regards, Brian Mukul Chawla wrote: > > Im not clear why draft-ietf-ipngwg-uni-based-mcast-02.txt, Section 3 > looks _only_ at IPv6 mcast addresses created by mapping 32 bit IEEE 802 > MAC addresses (RFC2373, 2.7.2) rather than creating an SSM service range > in IPv6 which uses 112 bit group IDs? What am I missing here? Is there > an IPv6 SSM range which uses 112 bit group IDs? > > Thanks, > Mukul > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Aug 24 10:36:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHaU1O028782 for ; Fri, 24 Aug 2001 10:36:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OHaTmI028781 for ipng-dist; Fri, 24 Aug 2001 10:36:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHaQ1O028774 for ; Fri, 24 Aug 2001 10:36:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06129 for ; Fri, 24 Aug 2001 10:36:31 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05733 for ; Fri, 24 Aug 2001 11:36:50 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7OHZGl02866; Sat, 25 Aug 2001 00:35:18 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: Alex Conta , Bob Hinden , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B868932.AB2D4815@hursley.ibm.com> References: <3B868932.AB2D4815@hursley.ibm.com> <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Aug 2001 00:35:16 +0700 Message-ID: <2864.998674516@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 24 Aug 2001 12:04:50 -0500 From: Brian E Carpenter Message-ID: <3B868932.AB2D4815@hursley.ibm.com> | > I actually treat this message as a concession that there are no strong | > enough arguments that can be made to ipngwg that would cause model (c) | > for the flow label to be adopted. | | I don't see where you get that from. That's because you misread it I think. I didn't say that there were no arguments in favour of (c), but that I would treat Alex's message as conceding that there are none. That doesn't mean that you have to agree with him. Personally, I have no idea, I'm not picking any of them. Abstain. The "I actually treat" was because Alex's argument amounted to "you have to pick (c) because you're required to support other standards, and diffserv is one of them". That's the "because I said so" line of reasoning, which is generally used (between peers) only when there is no other reasonable argument available to be made. 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 Aug 24 11:01:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OI1q1O028815 for ; Fri, 24 Aug 2001 11:01:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OI1pWg028814 for ipng-dist; Fri, 24 Aug 2001 11:01:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OI1m1O028807 for ; Fri, 24 Aug 2001 11:01:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13110 for ; Fri, 24 Aug 2001 11:01:54 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27394 for ; Fri, 24 Aug 2001 12:01:49 -0600 (MDT) Received: from fedex.cisco.com (fedex.cisco.com [171.69.17.28]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7OI1rX24436; Fri, 24 Aug 2001 11:01:53 -0700 (PDT) Received: from cisco.com (dhcp-171-69-42-236.cisco.com [171.69.42.236]) by fedex.cisco.com (Mirapoint) with ESMTP id ACC04301 (AUTH mchawla); Fri, 24 Aug 2001 11:01:50 -0700 (PDT) Message-ID: <3B8698C9.4A69558@cisco.com> Date: Fri, 24 Aug 2001 11:11:21 -0700 From: Mukul Chawla X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian Haberman CC: "ipng@sunroof.eng.sun.com" Subject: Re: draft-ietf-ipngwg-uni-based-mcast-02.txt References: <3B868FA1.BAD959A6@cisco.com> <3B868FAD.3737D381@americasm06.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Okay, looks like Im unclear with the basics of IPv6 mcast addresses: I could use 112 bit group IDs, as long as some mechanism for mapping 112 bit IDs to ethernet mcast addresses exists, right? Does such a mechanism exist? Is there an RFC/draft discussing using 112 bit group IDs? Mukul Brian Haberman wrote: > Mukul, > For the same reason that RFC 2373 only uses the lower 32 bits > for multicast group IDs. It makes the mapping into IEEE 802 multicast > MAC addresses less likely to lead to collisions. > > Regards, > Brian > > Mukul Chawla wrote: > > > > Im not clear why draft-ietf-ipngwg-uni-based-mcast-02.txt, Section 3 > > looks _only_ at IPv6 mcast addresses created by mapping 32 bit IEEE 802 > > MAC addresses (RFC2373, 2.7.2) rather than creating an SSM service range > > in IPv6 which uses 112 bit group IDs? What am I missing here? Is there > > an IPv6 SSM range which uses 112 bit group IDs? > > > > Thanks, > > Mukul > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Aug 24 14:19:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLJq1O029072 for ; Fri, 24 Aug 2001 14:19:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OLJqCw029071 for ipng-dist; Fri, 24 Aug 2001 14:19:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLJm1O029064 for ; Fri, 24 Aug 2001 14:19:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25071 for ; Fri, 24 Aug 2001 14:19:54 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21241 for ; Fri, 24 Aug 2001 14:19:54 -0700 (PDT) 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 OAA24397; Fri, 24 Aug 2001 14:19:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7OLJrK08489; Fri, 24 Aug 2001 14:19:53 -0700 X-mProtect: Fri, 24 Aug 2001 14:19:53 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdQkfYy6; Fri, 24 Aug 2001 14:19:50 PDT Message-Id: <4.3.2.7.2.20010824141512.02211990@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Aug 2001 14:19:26 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "An analysis of IPv6 anycast" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as an Informational RFC: Title : An analysis of IPv6 anycast Author(s) : J. Hagino et al. Filename : draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt Pages : 10 Date : 16-Jul-01 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two week from today on September 7, 2001. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 24 14:30:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLUY1O029104 for ; Fri, 24 Aug 2001 14:30:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OLUXBl029103 for ipng-dist; Fri, 24 Aug 2001 14:30:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLUU1O029096 for ; Fri, 24 Aug 2001 14:30:30 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27156 for ; Fri, 24 Aug 2001 14:30:35 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA07899 for ; Fri, 24 Aug 2001 14:30:34 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15aOXC-000IWL-00 for ipng@sunroof.eng.sun.com; Fri, 24 Aug 2001 14:30:34 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "An analysis of IPv6 anycast" References: <4.3.2.7.2.20010824141512.02211990@mailhost.iprg.nokia.com> Message-Id: Date: Fri, 24 Aug 2001 14:30:34 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There are two kind of "anycast" proposed and operated for IPv4 - One is > RFC1546 [Partridge, 1993] anycast. Another is what we call "BGP anycast" > in this document; this is for replicating unicast servers by BGP trick. > We concentrate into the former in this document. as it is used for dns etc. *within* a single provider, it can be an igp which is used, not bgp. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 24 14:53:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLrV1O029158 for ; Fri, 24 Aug 2001 14:53:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OLrUHt029157 for ipng-dist; Fri, 24 Aug 2001 14:53:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLrQ1O029150 for ; Fri, 24 Aug 2001 14:53:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00033 for ; Fri, 24 Aug 2001 14:53:32 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA03261 for ; Fri, 24 Aug 2001 14:53:32 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 24 Aug 2001 14:53:25 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 14:53:25 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 14:53:24 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 24 Aug 2001 14:53:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Ipv6IfIndex and IPv4 ifIndex Date: Fri, 24 Aug 2001 14:53:07 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E60E@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ipv6IfIndex and IPv4 ifIndex Thread-Index: AcEs1MrcihgZR9+2QgSkkAS5CsmelgAEiA+g From: "Dave Thaler" To: "Deshpande, Prasad" Cc: X-OriginalArrivalTime: 24 Aug 2001 21:53:08.0265 (UTC) FILETIME=[29282990:01C12CE7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7OLrR1O029151 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Deshpande, Prasad [mailto:PDeshpande@unispherenetworks.com] > > IpIfStatsEntry in draft-ietf-ipngwg-rfc2011-update-00.txt has only one > set of statistcs for each ipIfStatsIfIndex. So if IPv4 and IPv6 are > enabled > on the same physical interface, wont you need 2 seperate ifIndex values to > get seperate statistics? No, you don't. If you look at the INDEX clause of the IfStatsTable, you'll see that it's: INDEX { ipIfStatsAFType, ipIfStatsIfIndex } where ipIfStatsAFType identifies IPv4 or IPv6. Hence, there's separate rows for IPv4 vs IPv6 statistics. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 14:56:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLuW1O029178 for ; Fri, 24 Aug 2001 14:56:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OLuWVf029177 for ipng-dist; Fri, 24 Aug 2001 14:56:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLuU1O029170 for ; Fri, 24 Aug 2001 14:56:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7OLsX228538 for ipng@sunroof.eng.sun.com; Fri, 24 Aug 2001 14:54:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OHP11O028727 for ; Fri, 24 Aug 2001 10:25:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03360 for ; Fri, 24 Aug 2001 10:25:07 -0700 (PDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27270 for ; Fri, 24 Aug 2001 11:25:02 -0600 (MDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 13:23:13 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P5AJK5YD; Fri, 24 Aug 2001 13:24:47 -0400 From: "Kastenholz, Frank" To: ipng@sunroof.eng.sun.com Message-Id: <5.0.2.1.2.20010824131420.0266cce0@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 24 Aug 2001 13:27:53 -0400 Subject: Re: Higher level question about flow label Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All this talk about the format of the flow-id field is rather interesting. But one thing has been missing -- input from someone who will actually _look_ at the field, at very very very high speeds, in hardware, and make forwarding decisions based on it. I am fairly confident in saying that there will not be many sqmm of silicon devoted to determining if the flow id is 'intserv-format' or 'diff-serv format' or 'tennis-serv format'. The edit/compile /debug loop of silicon is such that we can not react soon enough to the next format that is developed. This means that the flowid looker- upper will be very very general. That means that we don't care what the format is. We just take the whole 20-bits and look 'em up (e.g., throw them all at a CAM, and see what comes out) The only thing that would make the looker-upper's job easier is to know that the flow-id is going going to be shorter than 20 bits (maybe via the protocol specification, maybe via some software magic ala MPLS label negotiations). A looker-upper that is limited to 4 bits is a different beast than a looker-upper that does 20. So, you folks can argue all you want about the format of the flow-id and those format differences may matter at some level in the software. But to the people who are the actual customers of the bits -- the silicon forwarders -- it just doesn't matter. Frank Kastenholz -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 24 14:57:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLv01O029191 for ; Fri, 24 Aug 2001 14:57:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OLuxCK029190 for ipng-dist; Fri, 24 Aug 2001 14:56:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLuv1O029183 for ; Fri, 24 Aug 2001 14:56:57 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7OLt1n28568 for ipng@sunroof.eng.sun.com; Fri, 24 Aug 2001 14:55:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OIXc1O028855 for ; Fri, 24 Aug 2001 11:33:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22004 for ; Fri, 24 Aug 2001 11:33:41 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09026 for ; Fri, 24 Aug 2001 11:33:40 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f7OIXIp13056 for ; Fri, 24 Aug 2001 14:33:18 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Fri, 24 Aug 2001 14:33:27 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RDHH3P60; Fri, 24 Aug 2001 14:33:24 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5N1ZZ; Fri, 24 Aug 2001 14:33:25 -0400 Message-ID: <3B869DF1.60235F63@americasm06.nt.com> Date: Fri, 24 Aug 2001 14:33:21 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mukul Chawla CC: "ipng@sunroof.eng.sun.com" Subject: Re: draft-ietf-ipngwg-uni-based-mcast-02.txt References: <3B868FA1.BAD959A6@cisco.com> <3B868FAD.3737D381@americasm06.nt.com> <3B8698C9.4A69558@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukul, There is no one RFC that discusses IP-layer multicast address mapping to MAC-layer multicast addresses. In IPv6, it is covered in the individual IPv6-over-foo specs. Take a look at section 7 of RFC 2464. That shows the mapping of IPv6 multicast addresses to ethernet multicast addresses. Because of this mapping, RFC 2373 discusses only using 32-bit group IDs for IPv6 multicast addresses. Regards, Brian Mukul Chawla wrote: > > Okay, looks like Im unclear with the basics of IPv6 mcast addresses: I could > use 112 bit group IDs, as long as some mechanism for mapping 112 bit IDs to > ethernet mcast addresses exists, right? Does such a mechanism exist? Is there > an RFC/draft discussing using 112 bit group IDs? > > Mukul > > Brian Haberman wrote: > > > Mukul, > > For the same reason that RFC 2373 only uses the lower 32 bits > > for multicast group IDs. It makes the mapping into IEEE 802 multicast > > MAC addresses less likely to lead to collisions. > > > > Regards, > > Brian > > > > Mukul Chawla wrote: > > > > > > Im not clear why draft-ietf-ipngwg-uni-based-mcast-02.txt, Section 3 > > > looks _only_ at IPv6 mcast addresses created by mapping 32 bit IEEE 802 > > > MAC addresses (RFC2373, 2.7.2) rather than creating an SSM service range > > > in IPv6 which uses 112 bit group IDs? What am I missing here? Is there > > > an IPv6 SSM range which uses 112 bit group IDs? > > > > > > Thanks, > > > Mukul > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 Fri Aug 24 14:57:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLvV1O029212 for ; Fri, 24 Aug 2001 14:57:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OLvVpn029211 for ipng-dist; Fri, 24 Aug 2001 14:57:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OLvS1O029204 for ; Fri, 24 Aug 2001 14:57:28 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7OLtVV28598 for ipng@sunroof.eng.sun.com; Fri, 24 Aug 2001 14:55:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OJfX1O028942 for ; Fri, 24 Aug 2001 12:41:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08273 for ; Fri, 24 Aug 2001 12:41:37 -0700 (PDT) Received: from uniwest1.redstonecom.com ([65.194.140.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10671 for ; Fri, 24 Aug 2001 13:41:57 -0600 (MDT) Received: by mailwest.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 Aug 2001 15:41:36 -0400 Message-ID: <49FF5C6DDBD8D311BBBD009027DE980C02AC4880@mailwest.unispherenetworks.com> From: "Deshpande, Prasad" To: "'Dave Thaler'" , Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: RE: Ipv6IfIndex and IPv4 ifIndex Date: Fri, 24 Aug 2001 15:41:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dave, IpIfStatsEntry in draft-ietf-ipngwg-rfc2011-update-00.txt has only one set of statistcs for each ipIfStatsIfIndex. So if IPv4 and IPv6 are enabled on the same physical interface, wont you need 2 seperate ifIndex values to get seperate statistics? thanks -prasad > -----Original Message----- > From: Dave Thaler [mailto:dthaler@windows.microsoft.com] > Sent: Tuesday, August 21, 2001 3:47 PM > To: Dimitry Haskin > Cc: Deshpande, Prasad; ipng@sunroof.eng.sun.com > Subject: RE: Ipv6IfIndex and IPv4 ifIndex > > > What's a "logical IPv6 interface" and where is it defined? > > If you're using VLANs or whatever else, you can do it > with ifIndex values, and this buys you a lot > (you get the ifStackTable, stats, etc). > > I see no advantage to introducing another numbering space > and trying to get people to understand it. > > So I agree that Dimitry's answer applies to RFC 2465, > but we don't keep this concept in the new MIB drafts. > > -Dave > > > -----Original Message----- > > From: Dimitry Haskin [mailto:dhaskin@axiowave.com] > > Sent: Tuesday, August 21, 2001 8:09 AM > > To: 'Deshpande, Prasad'; ipng@sunroof.eng.sun.com > > Subject: RE: Ipv6IfIndex and IPv4 ifIndex > > > > Prasad, > > > > ipv6IfIndex defines a logical IPv6 interface. There is no > requirement > for > > its value being equal to an ifIndex value. Generally, it should be > > possible > > to configure multiple logical IPv6 interfaces on a single physical > > interface. > > > > Regards, > > Dimitry > > > > > -----Original Message----- > > > From: Deshpande, Prasad [mailto:PDeshpande@unispherenetworks.com] > > > Sent: Tuesday, August 21, 2001 10:04 AM > > > To: ipng@sunroof.eng.sun.com > > > Subject: Ipv6IfIndex and IPv4 ifIndex > > > > > > Hi, > > > > > > If IPv6 and IPv4 unicast forwarding are enabled on the same > physical > > > interface, would values of Ipv6IfIndex and ifIndex (IPv4) be the > same > > > i.e. would the same row show up in both ifTable and > ipv6IfTable. Is > > > this implementation dependent? > > > > > > I couldnt find any draft/RFC that talks about this. > > > > > > thanks > > > -prasad > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 Fri Aug 24 15:29:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OMTg1O029343 for ; Fri, 24 Aug 2001 15:29:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OMTfJs029342 for ipng-dist; Fri, 24 Aug 2001 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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OMTc1O029335 for ; Fri, 24 Aug 2001 15:29:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07913 for ; Fri, 24 Aug 2001 15:29:32 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14014 for ; Fri, 24 Aug 2001 15:29:31 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA11118; Fri, 24 Aug 2001 23:29:28 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA26642; Fri, 24 Aug 2001 23:29:27 +0100 Message-ID: <3B86D0EA.50CC1CC8@hursley.ibm.com> Date: Fri, 24 Aug 2001 17:10:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Kastenholz, Frank" CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <5.0.2.1.2.20010824131420.0266cce0@uniwest1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Frank, Not all network processors have the degree of inertia you describe. I know of at least one that can adapt to format changes without new silicon. But that aside, what I am talking about is multi-field classifiers in border routers, not what happens in core/trunk routers where you are completely correct - that is why the diffserv code point is 6 bits (sorry, we couldn't squeeze to 4). Multi-field classifiers don't need to be "slow path" but they aren't subject to quite the constraints you mention, in the diffserv architecture. This is the essence of why diffserv scales and intserv doesn't- you only need to do multi-field classification at the borders. Actually the format we are proposing simplifies MF classifiers because it takes away the need to look at port and protocol numbers. Brian "Kastenholz, Frank" wrote: > > All this talk about the format of the flow-id field > is rather interesting. But one thing has been missing -- > input from someone who will actually _look_ at the > field, at very very very high speeds, in hardware, > and make forwarding decisions based on it. > > I am fairly confident in saying that there will not > be many sqmm of silicon devoted to determining > if the flow id is 'intserv-format' or 'diff-serv > format' or 'tennis-serv format'. The edit/compile > /debug loop of silicon is such that we can not > react soon enough to the next format that is > developed. This means that the flowid looker- > upper will be very very general. That means > that we don't care what the format is. We just > take the whole 20-bits and look 'em up (e.g., > throw them all at a CAM, and see what comes out) > > The only thing that would make the looker-upper's > job easier is to know that the flow-id is going > going to be shorter than 20 bits (maybe via the > protocol specification, maybe via some software > magic ala MPLS label negotiations). A looker-upper > that is limited to 4 bits is a different beast > than a looker-upper that does 20. > > So, you folks can argue all you want about the format > of the flow-id and those format differences may matter > at some level in the software. But to the people who > are the actual customers of the bits -- the silicon > forwarders -- it just doesn't matter. > > Frank Kastenholz > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Aug 24 15:44:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OMiF1O029362 for ; Fri, 24 Aug 2001 15:44:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OMiFcP029361 for ipng-dist; Fri, 24 Aug 2001 15: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OMiC1O029354 for ; Fri, 24 Aug 2001 15:44:12 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26723 for ; Fri, 24 Aug 2001 15:44:16 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07474 for ; Fri, 24 Aug 2001 15:44:14 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Sat, 25 Aug 2001 00:44:12 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECAA0F@mail.kebne.se> From: Thomas Eklund To: "'Kastenholz, Frank '" , "'ipng@sunroof.eng.sun.com '" Subject: RE: Higher level question about flow label Date: Sat, 25 Aug 2001 00:44:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Frank I agree, And in fact we do hardware for speeds up to OC-768 which are fully programmable so for us it does not matter, but it matters for guys that do fixed function ASICs. But you right in the sense that it is not difficult to classify the 20 bits of the flow label and store it in CAM. The problems sits in the action steps associated with that flow label lookup, where in fact people would like to do different things. Other issues are of course how to update yor CAM's with new "flows" and write them in to the CAM. In fact this is where I think that there could be more things that needs to be standardized for updating the CAM(SRAM)tables with new flow which could be signalled with "hop-by-hop option flow setup messages" which could trigger the HW to update the CAM wirespeed in the forwarding plane instead of letting the control plane deal with it. -- thomas -----Original Message----- From: Kastenholz, Frank To: ipng@sunroof.eng.sun.com Sent: 2001-08-24 19:27 Subject: Re: Higher level question about flow label All this talk about the format of the flow-id field is rather interesting. But one thing has been missing -- input from someone who will actually _look_ at the field, at very very very high speeds, in hardware, and make forwarding decisions based on it. I am fairly confident in saying that there will not be many sqmm of silicon devoted to determining if the flow id is 'intserv-format' or 'diff-serv format' or 'tennis-serv format'. The edit/compile /debug loop of silicon is such that we can not react soon enough to the next format that is developed. This means that the flowid looker- upper will be very very general. That means that we don't care what the format is. We just take the whole 20-bits and look 'em up (e.g., throw them all at a CAM, and see what comes out) The only thing that would make the looker-upper's job easier is to know that the flow-id is going going to be shorter than 20 bits (maybe via the protocol specification, maybe via some software magic ala MPLS label negotiations). A looker-upper that is limited to 4 bits is a different beast than a looker-upper that does 20. So, you folks can argue all you want about the format of the flow-id and those format differences may matter at some level in the software. But to the people who are the actual customers of the bits -- the silicon forwarders -- it just doesn't matter. Frank Kastenholz -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Aug 24 15:56:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OMuN1O029382 for ; Fri, 24 Aug 2001 15:56:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OMuNLl029381 for ipng-dist; Fri, 24 Aug 2001 15:56:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OMuJ1O029374 for ; Fri, 24 Aug 2001 15:56:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28994 for ; Fri, 24 Aug 2001 15:56:24 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03261 for ; Fri, 24 Aug 2001 16:56:45 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Sat, 25 Aug 2001 00:56:20 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECAA10@mail.kebne.se> From: Thomas Eklund To: "'Brian E Carpenter '" , "'Kastenholz, Frank '" Cc: "'ipng@sunroof.eng.sun.com '" Subject: RE: Higher level question about flow label Date: Sat, 25 Aug 2001 00:56:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, This is the key since many that do network processors are in fact fixed function ASICs (or configurale state machine approaches) and those are not programmable they are only configurable. Count us in as the second you know. And in fact most of the network processors have MF classifiers in the fast path (forwarding plane). The limiting factor is of course the speed of the CAM's. -- thomas -----Original Message----- From: Brian E Carpenter To: Kastenholz, Frank Cc: ipng@sunroof.eng.sun.com Sent: 2001-08-25 00:10 Subject: Re: Higher level question about flow label Frank, Not all network processors have the degree of inertia you describe. I know of at least one that can adapt to format changes without new silicon. But that aside, what I am talking about is multi-field classifiers in border routers, not what happens in core/trunk routers where you are completely correct - that is why the diffserv code point is 6 bits (sorry, we couldn't squeeze to 4). Multi-field classifiers don't need to be "slow path" but they aren't subject to quite the constraints you mention, in the diffserv architecture. This is the essence of why diffserv scales and intserv doesn't- you only need to do multi-field classification at the borders. Actually the format we are proposing simplifies MF classifiers because it takes away the need to look at port and protocol numbers. Brian "Kastenholz, Frank" wrote: > > All this talk about the format of the flow-id field > is rather interesting. But one thing has been missing -- > input from someone who will actually _look_ at the > field, at very very very high speeds, in hardware, > and make forwarding decisions based on it. > > I am fairly confident in saying that there will not > be many sqmm of silicon devoted to determining > if the flow id is 'intserv-format' or 'diff-serv > format' or 'tennis-serv format'. The edit/compile > /debug loop of silicon is such that we can not > react soon enough to the next format that is > developed. This means that the flowid looker- > upper will be very very general. That means > that we don't care what the format is. We just > take the whole 20-bits and look 'em up (e.g., > throw them all at a CAM, and see what comes out) > > The only thing that would make the looker-upper's > job easier is to know that the flow-id is going > going to be shorter than 20 bits (maybe via the > protocol specification, maybe via some software > magic ala MPLS label negotiations). A looker-upper > that is limited to 4 bits is a different beast > than a looker-upper that does 20. > > So, you folks can argue all you want about the format > of the flow-id and those format differences may matter > at some level in the software. But to the people who > are the actual customers of the bits -- the silicon > forwarders -- it just doesn't matter. > > Frank Kastenholz > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Fri Aug 24 15:58:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OMwY1O029401 for ; Fri, 24 Aug 2001 15:58:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7OMwY9e029400 for ipng-dist; Fri, 24 Aug 2001 15:58:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7OMwU1O029393 for ; Fri, 24 Aug 2001 15:58:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10753 for ; Fri, 24 Aug 2001 15:58:35 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22956 for ; Fri, 24 Aug 2001 15:58:34 -0700 (PDT) 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 PAA01296; Fri, 24 Aug 2001 15:58:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7OMwYg26650; Fri, 24 Aug 2001 15:58:34 -0700 X-mProtect: Fri, 24 Aug 2001 15:58:34 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdB8MSHZ; Fri, 24 Aug 2001 15:58:31 PDT Message-Id: <4.3.2.7.2.20010824154601.0250edd8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Aug 2001 15:58:07 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "IP Version 6 Addressing Architecture" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a short IPng working group last call for comments on advancing the following document as an Draft Standard: Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-06.txt Pages : 27 Date : 19-Jul-01 A complete list of changes from RFC-2373 is in Appendix B of the draft and is reproduced below. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end one week from today on August 31, 2001. We are doing a short w.g. last call because there have been earlier w.g. and IETF last calls on this document and wanted to insure that the changes in the current draft has been reviewed by the w.g. Bob Hinden / Steve Deering -------------------------------------------------------------------------- APPENDIX B: Changes from RFC-2373 --------------------------------- The following changes were made from RFC-2373 "IP Version 6 Addressing Architecture": - Many small changes to clarify and make the text more consistent. - Revised sections 2.4 and 2.5.6 to simplify and clarify how different address types are identified. This was done to insure that implementations do not build in any knowledge about global unicast format prefixes. Changes include: o Removed Format Prefix (FP) terminology o Revised list of address types only includes exceptions to global unicast and a singe entry that identifies everything else as Global Unicast. o Removed list of defined prefix exceptions from section 2.5.6 as it is now the main part of section 2.4. - Clarified text relating to EUI-64 identifiers to distinguish between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-64 identifiers. - Combined the sections on the Global Unicast Addresses and NSAP Addresses into a single section on Global Unicast Addresses, generalized the Global Unicast format, and cited [AGGR] and [NSAP] as examples. - Reordered sections 2.5.4 and 2.5.5. - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses because this is being redefined elsewhere. - Added an IANA considerations section that updates the IANA IPv6 address allocations and documents the NSAP and AGGR allocations. - Added clarification that the "IPv4-compatible IPv6 address" must use global IPv4 unicast addresses. - Divided references in to normative and non-normative sections. - Added reference to [PRIV] in section 2.5.1 - Revised section 2.4 Address Type Representation to - Added clarification that routers must not forward multicast packets outside of the scope indicated in the multicast address. - Added clarification that routers must not forward packets with source address of the unspecified address. - Added clarification that routers must drop packets received on an interface with destination address of loopback. - Clarified the definition of IPv4-mapped addresses. - Removed the ABNF Description of Text Representations Appendix. - Removed the address block reserved for IPX addresses. - Multicast scope changes: o Changed name of scope value 1 from "node-local" to "interface- local" o Defined scope value 3 for "subnet-local" for multi-link subnets o Defined scope value 4 as "admin-local" - Corrected reference to RFC1933 and updated references. ------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 25 02:21:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7P9Lk1O029693 for ; Sat, 25 Aug 2001 02:21:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19/Submit) id f7P9Lkf3029692 for ipng-dist; Sat, 25 Aug 2001 02:21:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta19+Sun/8.12.0.Beta19) with ESMTP id f7P9Lh1O029685 for ; Sat, 25 Aug 2001 02:21:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11958 for ; Sat, 25 Aug 2001 02:21:48 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06608 for ; Sat, 25 Aug 2001 03:22:11 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7P9Lhc21981; Sat, 25 Aug 2001 12:21:43 +0300 Date: Sat, 25 Aug 2001 12:21:42 +0300 (EEST) From: Pekka Savola To: Randy Bush cc: Subject: Re: W.G. Last Call on "An analysis of IPv6 anycast" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 24 Aug 2001, Randy Bush wrote: > > There are two kind of "anycast" proposed and operated for IPv4 - One is > > RFC1546 [Partridge, 1993] anycast. Another is what we call "BGP anycast" > > in this document; this is for replicating unicast servers by BGP trick. > > We concentrate into the former in this document. > > as it is used for dns etc. *within* a single provider, it can be an igp > which is used, not bgp. Yeah. I think "routing trick" anycast like with IPv4 is a much simpler approach, and actually _works_ rather well (as there is no constraint the address must not be used as a source). 6to4 relay, isatap router, shipworm server, ... All of these use the IPv4 anycast mechanism, and will often be more commonplace in IGP rather than BGP for non-technical reasons (you often don't want to provide service outside your domain for free). -- 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 Aug 25 11:48:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PImm40000160 for ; Sat, 25 Aug 2001 11:48:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7PImmtl000159 for ipng-dist; Sat, 25 Aug 2001 11:48:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PImi40000150 for ; Sat, 25 Aug 2001 11:48:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10029 for ; Sat, 25 Aug 2001 11:48:45 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14366; Sat, 25 Aug 2001 12:48:40 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7PImb507142; Sat, 25 Aug 2001 11:48:37 -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 AAJ20894; Sat, 25 Aug 2001 11:48:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA21004; Sat, 25 Aug 2001 11:48:18 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15239.62194.117588.888735@thomasm-u1.cisco.com> Date: Sat, 25 Aug 2001 11:48:18 -0700 (PDT) To: Brian E Carpenter Cc: Michael Thomas , sommerfeld@east.sun.com, Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label In-Reply-To: <3B868499.FDF9CC90@hursley.ibm.com> References: <15234.49245.24268.283937@thomasm-u1.cisco.com> <200108222105.f7ML5d012677@thunk.east.sun.com> <15236.8827.323100.546364@thomasm-u1.cisco.com> <3B868499.FDF9CC90@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > The issue is that if the packet is classified prior to being > encrypted, what do you do if a downstream ISP declines to > believe the classification (DCSP value) and wishes to reclassify > the packet? The proposal is to put enough semantics in the flow > label to allow some degree of classification. I'm sorry, but this sounds like you're approaching the problem backward. If you want transport friendliness so that you can reclassify packets, you should beat up on the Ipsec WG to revive the transport friendly ESP as working group item. Trying to jam the relevant transport header into a 20 bit field sounds like a *way* losing proposition which has a zero percent possibility of being future proof. It's bad enough that we have these middle boxes trying to look at L4+ headers, but trying to *replicate* data into an obviously too small field for every unknown and uninvented protocol going forward... ick. Mike > > Brian > > Michael Thomas wrote: > > > > Bill Sommerfeld writes: > > > > Huh? I thought that one of the requirements for ESP was to > > > > copy the DSCP to the outer header. If I recall correctly, > > > > this bothers some people from a traffic analysis standpoint, > > > > but that seems to be part and parcel with QoS so that doesn't > > > > hold much water IMO. > > > > > > It seems that it would be appropriate for an implementation to > > > "reclassify" packets at the time of encapsulation into ESP -- the > > > packet is, after all, going through a logical trust boundary as it's > > > being encrypted.. > > > > If I understand Brian's concern correctly, that may > > not necessarily be the case. The security gateway may > > be on egress from my network and hence controlled by me. > > If the service provider wants to reclassify those packets, > > it would need to be done at the next hop router from the > > security gateway (ie on a router they controlled). > > > > I'm still not sure I understand the policing they are > > trying to accomplish though; it seems sort of weird > > to have port level classification on the other side of the > > trust boundary to set the proper DSCP, unless it's just > > provide a service that could (should?) have been done at > > your egress router. Otherwise it seems like > > the user would be shooting themselves in the foot since > > the normal method is for the policer to police to a > > certain SLA on a given aggregate traffic class. This > > to my mind would argue for the classification to be > > done on *before* it is encapsulated with ESP, but the > > policing done on the aggregate where it doesn't care > > about the port data. > > > > Ie: > > > > luserdata------------>SG---------------------->AR > > (classifies, (polices > > remarks dscp, SLA against > > encrypts) DSCP, remarks) > > > > 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 > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > > "We shall need a number of efficient librarian types > to keep us in order." - Alan Turing, 1947. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 25 14:20:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PLKk40000294 for ; Sat, 25 Aug 2001 14:20:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7PLKk4P000293 for ipng-dist; Sat, 25 Aug 2001 14:20:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PLKg40000284 for ; Sat, 25 Aug 2001 14:20:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03610 for ; Sat, 25 Aug 2001 14:20:48 -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 PAA09574 for ; Sat, 25 Aug 2001 15:20:43 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7PLKcS25464; Sun, 26 Aug 2001 00:20:38 +0300 Date: Sun, 26 Aug 2001 00:20:38 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" In-Reply-To: <4.3.2.7.2.20010824154601.0250edd8@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 24 Aug 2001, Bob Hinden wrote: > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end one > week from today on August 31, 2001. 2.1 Addressing Model reads: A single interface may also be assigned multiple IPv6 addresses of any type (unicast, anycast, and multicast) or scope. I don't think it's good practise to talk about assigning multicast addresses to an interface. This may confuse people, and make people think of doing stuff like 'ifconfig xl0 inet6 ff0e::1 alias' ie. actually assign it to as a regular IPv6 address, which might confuse source address selection a bit and be a little funky to say at least. Editorial nit: first CIDR reference is in 2.3. 2.5.5 IPv6 Addresses with Embedded IPv4 Addresses: This discussion, dating back a few years, is based on times when there were only compatible/mapped addresses which embed IPv4 addresses. Now there are more, and more on the way. I'm not sure whether it's sensible to include all of them in this draft, but a decision should be made whether the current ones are really that much needed either or enough, given others also exist. Personally I think mapped address, stuff like SIIT aside, should be fundamentally different than compatible address, and at least mapped addr should be discussed in this draft. Compatible is just a transitionary mechanism that happens to use FP 000. 2.6 Anycast Addresses Anycast usage scenarios listed in the draft are very router-centric, and I doubt they have been used at all (or very little). Therefore, based on IPv6 anycast analysis draft, I think this would be perfect time to remove/edit(move to recommendation or something) this: o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only. Lest we be burdened for this for another 3 years or whatever, if e.g. a DNS server wants to use anycast addresses. The source address restriction is trickier business... 2.7 Multicast Addresses FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface (i.e., the same node) as the sender. FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the sender. Perhaps it would make sense to point out the differences of: - interface - link - node wrt. scoping (ref to scoping draft?), especially on scenarios where interface != link. (interface really only includes the loopback, I think). I think "interface-local" is a bit of a misnomer, but I guess changing it to "node-local" at this point may be too late. This has been discussed IIRC before, but it may not exactly obvious if some first-timer reads the draft. 2.8 A Node's Required Addresses Editorial: o It's required Link-Local Address for each interface. Its. Editorial: [TRAN] reference should probably be updated to point at RFC2893, not RFC1933. There's some fluctuation in the casing of some special words, like 'the unspecified address' and 'loopback address'. The preferred form should be decided and the occurrences where they're being used,fixed. -- 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 Aug 25 16:32:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PNWt40000398 for ; Sat, 25 Aug 2001 16:32:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7PNWtji000397 for ipng-dist; Sat, 25 Aug 2001 16:32:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7PNWp40000390 for ; Sat, 25 Aug 2001 16:32:51 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06380 for ; Sat, 25 Aug 2001 16:32:55 -0700 (PDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23759 for ; Sat, 25 Aug 2001 16:32:54 -0700 (PDT) Received: from henkell.ibr.cs.tu-bs.de (root@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id BAA14243; Sun, 26 Aug 2001 01:32:45 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id SAA15843; Wed, 22 Aug 2001 18:07:00 +0200 Date: Wed, 22 Aug 2001 18:07:00 +0200 Message-Id: <200108221607.SAA15843@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: moulton@snmp.com CC: dthaler@windows.microsoft.com, ipv6_dchuang@yahoo.com, ipng@sunroof.eng.sun.com, snmpv3@lists.tislabs.com In-reply-to: <200108211437.f7LEbAe11459@sol8.snmp.com> (message from Steve Moulton on Tue, 21 Aug 2001 10:37:10 -0400) Subject: Re: ipv6IfStateChange traps in RFC2465 References: <200108211437.f7LEbAe11459@sol8.snmp.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> Steve Moulton writes: Steve> though as far as I can tell, no domain has been defined in an Steve> RFC for IPv6 addresses. Correct. This is one of the infrastructure pieces we are really bad in getting done in a timely manner. Steve> There is a proposal to add new transport domain OIDs for IPv6 Steve> in draft-ops-taddress-mib-00.txt. I'm pretty sure this is also Steve> in draft-ops-taddress-mib-01.txt, but both have expired, and I Steve> don't have the text for it. So, there is currently no way to Steve> specify an IPv6 target address in a standard fashion, though Steve> either the IETF or vendors will have to deal with this as IPv6 Steve> support demand increases. I prefer a standard definition and that is why I started to write a while back. For those interested, you can find a copy at: One problem with TAddress/TDomain is that the community does not have a clear concensus whether definitions contain specific SNMP semantics or not. The current usage of TAddress/TDomain outside the SNMP specs of course assumes that there are no special SNMP semantics associated with TAddress/TDomain definitions... /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 26 07:31:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7QEVH40000828 for ; Sun, 26 Aug 2001 07:31:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7QEVHQ5000827 for ipng-dist; Sun, 26 Aug 2001 07:31:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7QEVD40000820 for ; Sun, 26 Aug 2001 07:31:13 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07064 for ; Sun, 26 Aug 2001 07:31:17 -0700 (PDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17617 for ; Sun, 26 Aug 2001 07:31:16 -0700 (PDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7QEVDX27241 for ; Sun, 26 Aug 2001 10:31:14 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Aug 2001 16:31:02 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D4A046D@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "C. M. Heard" , ipng@sunroof.eng.sun.com, mibs@ops.ietf.org Subject: RE: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 Date: Sun, 26 Aug 2001 16:30:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Inline > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: dinsdag 7 augustus 2001 1:29 > To: ipng@sunroof.eng.sun.com; mibs@ops.ietf.org > Subject: Re: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 > > > [ NOTE: this is cross-posted to the MIBS list > because the discussion concerns both IPv4 and > IPv6. The "new MIBS" referred to are those in > draft-ietf-ipngwg-rfc2011-update-00.txt, > draft-ietf-ipngwg-rfc2012-update-00.txt, > draft-ietf-ipngwg-rfc2013-update-00.txt, and > draft-ietf-ipngwg-rfc2096-update-00.txt. ] > > On Fri, 27 Jul 2001, Bill Fenner wrote: > > The plan is to deprecate the existing objects in these RFCs > > in favor of the protocol-independent ones. The exact plan is not > > yet known (e.g. publish a new revision with all objects listed > > as deprecated vs. reclassify the old RFCs as historic, etc.). > > And as one can see explicitly from the drafts themselves, the intent > is also to deprecate all of the IPv4-specific stuff in RFC 2011, > RFC 2012, RFC 2013, and RFC 2096. Note that the MIB modules in the > first three of these RFCs are simply translations into SMIv2 of > the MIB-II IP group (less routing table), TCP group, and UDP group, > respectively; the substance is unchanged from RFC 1213. > > > The intent is definitely not to suddenly cause existing > implementations > > to be non-standard, but to encourage evolution. > > But that's PRECISELY what adoption of these drafts in their present > form would do. Where new compliance statements exist, they make the > new version-independent objects unconditionally mandatory and don't > mention the version-specific objects. That makes existing > implementations > non-compliant and (if the drafts were to be adopted as standards) > non-standard. > I doubt that this is true. The objects are DEPRECATED, which means they are they are specifically there for backward compatibility and continued interoperability with old/existing implementations. If we wanted to break with backward compatibility, then we would OBSOLETE those objects. See RFC2578 section 6.1 for details. > Notice that it is not just existing implementations of the existing > IPv6 MIBs in RFC 2452, RFC 2454, RFC 2465, and RFC 2466 that would > be destandardized, but also existing implementations of the MIB-II > IP, TCP, and UDP groups. The older IPv4-specific objects have in all > cases been deprecated in favor of the new protocol-independent objects, > and so have the old IPv4-specific compliance statements. > So we want to encourage new implementations to use the new objects while existing ones can continue to use the old ones. The old ones in fact are still at Full Standard (RFC1213) for quite a while to come. I hope this eases some of your concerns. Bert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 26 07:51:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7QEpO40000870 for ; Sun, 26 Aug 2001 07:51:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7QEpO27000869 for ipng-dist; Sun, 26 Aug 2001 07:51:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7QEpJ40000862 for ; Sun, 26 Aug 2001 07:51:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07706 for ; Sun, 26 Aug 2001 07:51:23 -0700 (PDT) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19860 for ; Sun, 26 Aug 2001 07:51:23 -0700 (PDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f7QEpIX28827 for ; Sun, 26 Aug 2001 10:51:18 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Aug 2001 16:51:09 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D4A0475@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Schoenwaelder , moulton@snmp.com Cc: dthaler@windows.microsoft.com, ipv6_dchuang@yahoo.com, ipng@sunroof.eng.sun.com, snmpv3@lists.tislabs.com Subject: RE: ipv6IfStateChange traps in RFC2465 Date: Sun, 26 Aug 2001 16:51:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I prefer a standard definition and that is why I started to write > a while back. For those interested, > you can find a copy at: > > I have made the one in the I-D repository resurected. > One problem with TAddress/TDomain is that the community does not have > a clear concensus whether definitions contain specific SNMP semantics > or not. The current usage of TAddress/TDomain outside the SNMP specs > of course assumes that there are no special SNMP semantics associated > with TAddress/TDomain definitions... > Let us define a set of TDomains and TAddresses that have no SNMP semantics. They can then be used in SNMP specific objects, in which case maybe they do get some SNMP meaning. But they can then also be used for other purpuses. Bert > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 > Braunschweig, Germany > Fax: +49 531 391 5936 > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 01:05:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7R85540001669 for ; Mon, 27 Aug 2001 01:05:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7R85503001668 for ipng-dist; Mon, 27 Aug 2001 01:05:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7R85140001661 for ; Mon, 27 Aug 2001 01:05:01 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14753 for ; Mon, 27 Aug 2001 01:04:37 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17513 for ; Mon, 27 Aug 2001 01:04:33 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7R84v318511 for ; Mon, 27 Aug 2001 11:04:57 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Aug 2001 11:04:27 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV7GND>; Mon, 27 Aug 2001 11:03:06 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FEB@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, mat@cisco.com Cc: sommerfeld@east.sun.com, thomas.eklund@xelerated.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Mon, 27 Aug 2001 11:02:57 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I think this is the make or break question for the whole current flow label discussion: Has the validity of the scenario you describe (MF-classification between diffserv ISPs) been discussed somewhere? Some specific questions: (model: sender -> ... -> upstream ISP -> downstream ISP -> ... -> receiver) Q1: Why couldn't the ISP's agree on the DSCP-to-PHB mapping (SLA, "off-line signaling"), with the downstream ISP policing the traffic to the SLA (and possibly remarking)? Q2: Why the downstream ISP would not "believe" the DSCP value, but would believe the flow label value? Q3: Presumably the upstream ISP is transmitting traffic originated by his customers, so the upstream ISP has no control of the transport protocols and port numbers being transmitted. WHY would an SLA between two ISPs be based on port numbers (MF-classification) set by a third party (the packet originator)? I see that the problem you have in the diffserv architecture is that the DSCP values are meaningless outside a diffserv domain, and that you'd like to utilize the flow-label field to carry the globally unique identifier of the PHB. IMO, this would be MUCH better than any traditional micro-flow MF-classification in the context of diffserv. But what I fail to understand is that, since SLAs between ISPs are needed anyway to specify the policy for each traffic aggregate (however the classification is done), why couldn't the DSCP->PHB mapping be a part of the same SLA? In this model there would be NO question of anyone "believing" any values, as the downstream ISP would NOT CARE what any of the header values are, as all the traffic would be policed to the SLA, regardless of the actual contents of any headers above the IP header. It would be the responsibility of the upstream ISP to (re-)mark the DSCPs in the packets to get the best utilization of the SLA. IMO this would also be the most performance efficient method for all parties involved. Jarno Brian wrote: > The issue is that if the packet is classified prior to being > encrypted, what do you do if a downstream ISP declines to > believe the classification (DCSP value) and wishes to reclassify > the packet? The proposal is to put enough semantics in the flow > label to allow some degree of classification. > > Brian > > Michael Thomas wrote: > > > > Bill Sommerfeld writes: > > > > Huh? I thought that one of the requirements for ESP was to > > > > copy the DSCP to the outer header. If I recall correctly, > > > > this bothers some people from a traffic analysis standpoint, > > > > but that seems to be part and parcel with QoS so > that doesn't > > > > hold much water IMO. > > > > > > It seems that it would be appropriate for an implementation to > > > "reclassify" packets at the time of encapsulation into ESP -- the > > > packet is, after all, going through a logical trust > boundary as it's > > > being encrypted.. > > > > If I understand Brian's concern correctly, that may > > not necessarily be the case. The security gateway may > > be on egress from my network and hence controlled by me. > > If the service provider wants to reclassify those packets, > > it would need to be done at the next hop router from the > > security gateway (ie on a router they controlled). > > > > I'm still not sure I understand the policing they are > > trying to accomplish though; it seems sort of weird > > to have port level classification on the other side of the > > trust boundary to set the proper DSCP, unless it's just > > provide a service that could (should?) have been done at > > your egress router. Otherwise it seems like > > the user would be shooting themselves in the foot since > > the normal method is for the policer to police to a > > certain SLA on a given aggregate traffic class. This > > to my mind would argue for the classification to be > > done on *before* it is encapsulated with ESP, but the > > policing done on the aggregate where it doesn't care > > about the port data. > > > > Ie: > > > > luserdata------------>SG---------------------->AR > > (classifies, (polices > > remarks dscp, SLA against > > encrypts) DSCP, remarks) > > > > 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 > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > > "We shall need a number of efficient librarian types > to keep us in order." - Alan Turing, 1947. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Aug 27 06:13:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RDDr40002010 for ; Mon, 27 Aug 2001 06:13:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RDDqvh002009 for ipng-dist; Mon, 27 Aug 2001 06:13:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RDDm40002002 for ; Mon, 27 Aug 2001 06:13:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05175 for ; Mon, 27 Aug 2001 06:13:55 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07202 for ; Mon, 27 Aug 2001 07:14:14 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E8FCA7BC; Mon, 27 Aug 2001 21:41:37 +0900 (JST) To: Randy Bush Cc: ipng@sunroof.eng.sun.com In-reply-to: randy's message of Fri, 24 Aug 2001 14:30:34 MST. 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: W.G. Last Call on "An analysis of IPv6 anycast" From: Jun-ichiro itojun Hagino Date: Mon, 27 Aug 2001 21:41:37 +0900 Message-Id: <20010827124137.E8FCA7BC@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> There are two kind of "anycast" proposed and operated for IPv4 - One is >> RFC1546 [Partridge, 1993] anycast. Another is what we call "BGP anycast" >> in this document; this is for replicating unicast servers by BGP trick. >> We concentrate into the former in this document. >as it is used for dns etc. *within* a single provider, it can be an igp >which is used, not bgp. i see, but are there such practice exist? how do they cope with server failures and IGP flaps? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 06:16:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RDGw40002046 for ; Mon, 27 Aug 2001 06:16:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RDGwaE002045 for ipng-dist; Mon, 27 Aug 2001 06:16:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RDGs40002038 for ; Mon, 27 Aug 2001 06:16:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15641 for ; Mon, 27 Aug 2001 06:16:58 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23194; Mon, 27 Aug 2001 06:16:55 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id JAA23379; Mon, 27 Aug 2001 09:17:55 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id JAA22225; Mon, 27 Aug 2001 09:17:54 -0400 Message-ID: <3B8A4870.F412E939@txc.com> Date: Mon, 27 Aug 2001 09:17:36 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Brian E Carpenter , sommerfeld@east.sun.com, Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label References: <15234.49245.24268.283937@thomasm-u1.cisco.com> <200108222105.f7ML5d012677@thunk.east.sun.com> <15236.8827.323100.546364@thomasm-u1.cisco.com> <3B868499.FDF9CC90@hursley.ibm.com> <15239.62194.117588.888735@thomasm-u1.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msFAD093ABF17A8DC1F77702A0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msFAD093ABF17A8DC1F77702A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Brian E Carpenter writes: > > The issue is that if the packet is classified prior to being > > encrypted, what do you do if a downstream ISP declines to > > believe the classification (DCSP value) and wishes to reclassify > > the packet? The proposal is to put enough semantics in the flow > > label to allow some degree of classification. > > I'm sorry, but this sounds like you're approaching the > problem backward. If you want transport friendliness so > that you can reclassify packets, you should beat up on > the Ipsec WG to revive the transport friendly ESP as > working group item. Trying to jam the relevant transport > header into a 20 bit field sounds like a *way* losing > proposition which has a zero percent possibility of being > future proof. It's bad enough that we have these middle > boxes trying to look at L4+ headers, but trying to > *replicate* data into an obviously too small field for > every unknown and uninvented protocol going forward... > ick. > The problem is simple, in spite of all the twists and spins. You need to identify flows, and for that you use some fields in the network header and/or host-to-host header. Reviving the transport friendly ESP would do only partial good, since the problem of walking though all the extension headers remains. And thus, the validity of the request to have the flow label available for all IP QoS, including Diffserv, remains. Alex --------------msFAD093ABF17A8DC1F77702A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjcxMzE3MzhaMCMGCSqGSIb3DQEJBDEWBBQF+W2Fgs1l+h+CwYb2 RY4iwdVcjjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gD7mMVWaw1IHr817gX+JpDA8HAYQZdSwj/xSZX0h2NjH0ciom8w21SPiSVg8y4I9lEBPeVvv 9gTpXGlg5dqw2jlbA68wa1zHaoUY0ZHI8qooMdf1/tjTTXAu80A/Wsv4vegDusbN0+g9LyxM IqGpHMyVwTz2WN7UGjPkGzsLHmdY --------------msFAD093ABF17A8DC1F77702A0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 06:19:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RDJb40002069 for ; Mon, 27 Aug 2001 06:19:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RDJbga002068 for ipng-dist; Mon, 27 Aug 2001 06:19:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RDJX40002058 for ; Mon, 27 Aug 2001 06:19:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15915 for ; Mon, 27 Aug 2001 06:19:42 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08756 for ; Mon, 27 Aug 2001 07:19:37 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id JAA23443; Mon, 27 Aug 2001 09:20:41 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id JAA22467; Mon, 27 Aug 2001 09:20:40 -0400 Message-ID: <3B8A491C.DFAABBB5@txc.com> Date: Mon, 27 Aug 2001 09:20:28 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: hinden@iprg.nokia.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) References: <009CA59D1752DD448E07F8EB2F911757197FE8@esebe004.NOE.Nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms851E435364616898B2B3DABE" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms851E435364616898B2B3DABE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jarno, jarno.rajahalme@nokia.com wrote: > > Alex, > > I don't think it has been shown yet, that the diffserv architecture actually > needs any specific support from the IPv6 flow label. The needs of the architecture is materialized through the needs of the mechanisms. This has been shown repeatedly, and I thought you were here. > While the > MF-classification is mentioned in the diffserv architecture, the value of > that on the administrative boundaries is less than clear. The benefit of the MF classifiers is very clear. The draft has mentioned also the benefit for access networks. I thought you've read the draft. > An SLA between two domains could well be specified to only consider DSCP > values, and the associated PHB, volume, charging, etc. > > Could someone please explain why this could not work, and what specifically > is the value of signaling the PHB in the flow label field? > > Jarno > I am afraid you're starting a vicious circle. Please reread Brian's messages. It is also significant that using a IANA number was discussed, and proposed - the recent draft is a refining of an earlier proposal. Alex --------------ms851E435364616898B2B3DABE Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjcxMzIwMjhaMCMGCSqGSIb3DQEJBDEWBBSSFKCKUlPU+zdBZ7Qn Ugtrn11PYjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gHfVd5RzwpLkt1fYM4OzqmYx5CSG1gZ4iX9RlZG1kwCS+1qtREyRb607Yy39pzTDkN2QOarv rYm5e63YJbt9O9jMZR7VTLfzuDwMq+A+5UwVj3VNuc1xKY+dGBrStDFRAxm5xQ0Iclm7458p TNnqe3kaJLS9owXbrT0q+VsFilM4 --------------ms851E435364616898B2B3DABE-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 06:27:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RDRW40002098 for ; Mon, 27 Aug 2001 06:27:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RDRV8B002097 for ipng-dist; Mon, 27 Aug 2001 06:27:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RDRR40002090 for ; Mon, 27 Aug 2001 06:27:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16637 for ; Mon, 27 Aug 2001 06:27:36 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13395 for ; Mon, 27 Aug 2001 07:27:27 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 83C5C7BB; Mon, 27 Aug 2001 22:27:18 +0900 (JST) To: Alex Conta Cc: Bob Hinden , Brian E Carpenter , ipng In-reply-to: aconta's message of Thu, 23 Aug 2001 20:52:00 -0400. <3B85A530.ADEAA505@txc.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: a), b), c), d), or e) From: Jun-ichiro itojun Hagino Date: Mon, 27 Aug 2001 22:27:15 +0900 Message-Id: <20010827132718.83C5C7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >As I think that no standard should be excluded, I think that IPv6 WG >should do its best, to make IPv6 work well, friendly with MPLS. Which is >in a way [a subset of a)]+c). could you describe "[a subset of a] + c" in more detail so that people can understand you better? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 07:44:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7REij40002233 for ; Mon, 27 Aug 2001 07:44:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7REij8k002232 for ipng-dist; Mon, 27 Aug 2001 07:44:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7REif40002225 for ; Mon, 27 Aug 2001 07:44:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26262 for ; Mon, 27 Aug 2001 07:44:48 -0700 (PDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17628 for ; Mon, 27 Aug 2001 08:45:11 -0600 (MDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id QAA22808; Mon, 27 Aug 2001 16:44:45 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id QAA23935; Mon, 27 Aug 2001 16:44:45 +0200 Date: Mon, 27 Aug 2001 16:44:45 +0200 Message-Id: <200108271444.QAA23935@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: heard@pobox.com CC: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org In-reply-to: (heard@pobox.com) Subject: Re: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> C M Heard writes: Mike> Some, but not all. I am still troubled that the drafts that are Mike> proposed to replace RFC 2012 and RFC 2013 (IPv4-only TCP and UDP Mike> MIBs) and RFC 2452 and RFC 2454 (IPv6-only TCP and UDP MIBs) are Mike> fixing some things that are not actually broken. Maybe it is Mike> more elegant to have one combined version-independent connection Mike> table/listener table instead to two version-specific ones, but Mike> there is no gain at all in functionality. The IPv6 MIBs introduced the notion of an Ipv6IfIndex which creates another namespace which does not seem to be needed. The current TCP and UDP MIB drafts avoid the Ipv6IfIndex namespace since the InetAddress definitions already take care of the details. /js -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 08:24:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RFO840002295 for ; Mon, 27 Aug 2001 08:24:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RFO8KN002294 for ipng-dist; Mon, 27 Aug 2001 08:24:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RFO440002287 for ; Mon, 27 Aug 2001 08:24:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19479 for ; Mon, 27 Aug 2001 08:24:12 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02112 for ; Mon, 27 Aug 2001 09:24:07 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA31014; Mon, 27 Aug 2001 16:24:09 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA21616; Mon, 27 Aug 2001 16:24:10 +0100 Message-ID: <3B8A65DD.9A30E569@hursley.ibm.com> Date: Mon, 27 Aug 2001 10:23:09 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bob Hinden CC: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <4.3.2.7.2.20010824154601.0250edd8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - Revised sections 2.4 and 2.5.6 to simplify and clarify how > different address types are identified. This was done to insure > that implementations do not build in any knowledge about global > unicast format prefixes. Changes include: > o Removed Format Prefix (FP) terminology > o Revised list of address types only includes exceptions to > global unicast and a singe entry that identifies everything > else as Global Unicast. I apologise. I hadn't noticed this change before and I think it is very confusing. I think the detail you have dropped from the table at the beginning of 2.4 and replaced by Global unicast (everything else) was useful. Hiding this detail in pointers and references in the text is a mistake in terms of document clarity. I also think that abolishing the term "format prefix" is obfuscation. The fact is that the leading bits of an address *are* a format prefix and implementors *will* look at those bits before processing an address. Why obscure that fact? The goal of ensuring that global unicast addresses are treated opaquely except by the routing system is a good one of course. However, I think this was not the best way to achieve it, or rather you have gone too far. (Also, there are options that multi6 might adopt that would change things so that hosts would look inside global unicast addresses. This would cause us to re-invent the format prefix PDQ.) 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 Aug 27 08:38:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RFcN40002385 for ; Mon, 27 Aug 2001 08:38:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RFcMZ4002384 for ipng-dist; Mon, 27 Aug 2001 08:38:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RFcJ40002377 for ; Mon, 27 Aug 2001 08:38:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21497 for ; Mon, 27 Aug 2001 08:38:27 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26217; Mon, 27 Aug 2001 08:38:24 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA10498; Mon, 27 Aug 2001 16:38:23 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA40270; Mon, 27 Aug 2001 16:38:22 +0100 Message-ID: <3B8A6927.A658B18A@hursley.ibm.com> Date: Mon, 27 Aug 2001 10:37:11 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: mat@cisco.com, sommerfeld@east.sun.com, thomas.eklund@xelerated.com, Francis.Dupont@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757197FEB@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno, The diffserv architectire is the *result* of that discussion, with ISP engineers, at the beginning of the diffserv effort, most specifically at the interim WG meeting in June 1998. Comments below... jarno.rajahalme@nokia.com wrote: > > Brian, > > I think this is the make or break question for the whole current flow label > discussion: > > Has the validity of the scenario you describe (MF-classification between > diffserv ISPs) been discussed somewhere? > > Some specific questions: > > (model: sender -> ... -> upstream ISP -> downstream ISP -> ... -> receiver) > > Q1: Why couldn't the ISP's agree on the DSCP-to-PHB mapping (SLA, "off-line > signaling"), with the downstream ISP policing the traffic to the SLA (and > possibly remarking)? The ISPs specifically requested flexibility to *not* use the same mappings. Of course the downstream will always police anyway. > > Q2: Why the downstream ISP would not "believe" the DSCP value, but would > believe the flow label value? That's a key question. With non-ESP traffic, you can equally ask why they would believe the port and protocol numbers. It's really a question of what the SLA says - if it doesn't say that they will honor the upstream DSCP, they will use the rest of the header to reclassify the packet. > > Q3: Presumably the upstream ISP is transmitting traffic originated by his > customers, so the upstream ISP has no control of the transport protocols and > port numbers being transmitted. WHY would an SLA between two ISPs be based > on port numbers (MF-classification) set by a third party (the packet > originator)? That's a business decision. The ISPs told us they wanted a standard that left them free to make their business decisions. > > I see that the problem you have in the diffserv architecture is that the > DSCP values are meaningless outside a diffserv domain, and that you'd like > to utilize the flow-label field to carry the globally unique identifier of > the PHB. IMO, this would be MUCH better than any traditional micro-flow > MF-classification in the context of diffserv. > > But what I fail to understand is that, since SLAs between ISPs are needed > anyway to specify the policy for each traffic aggregate (however the > classification is done), why couldn't the DSCP->PHB mapping be a part of the > same SLA? It could, but the IETF has nothing to say about SLAs. > > In this model there would be NO question of anyone "believing" any values, > as the downstream ISP would NOT CARE what any of the header values are, as > all the traffic would be policed to the SLA, regardless of the actual > contents of any headers above the IP header. It would be the responsibility > of the upstream ISP to (re-)mark the DSCPs in the packets to get the best > utilization of the SLA. Indeed. If I was an ISP I might well do that. But they asked for the flexibility to do other things too. 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 Aug 27 08:40:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RFel40002402 for ; Mon, 27 Aug 2001 08:40:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RFekpn002401 for ipng-dist; Mon, 27 Aug 2001 08:40:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RFeg40002394 for ; Mon, 27 Aug 2001 08:40:43 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06579 for ; Mon, 27 Aug 2001 08:40:50 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28448; Mon, 27 Aug 2001 08:40:48 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA15884; Mon, 27 Aug 2001 16:40:46 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA45912; Mon, 27 Aug 2001 16:40:43 +0100 Message-ID: <3B8A69B1.4A05C1FF@hursley.ibm.com> Date: Mon, 27 Aug 2001 10:39:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Alex Conta CC: Michael Thomas , sommerfeld@east.sun.com, Thomas Eklund , "''Francis Dupont ' '" , "''ipng ' '" Subject: Re: Higher level question about flow label References: <15234.49245.24268.283937@thomasm-u1.cisco.com> <200108222105.f7ML5d012677@thunk.east.sun.com> <15236.8827.323100.546364@thomasm-u1.cisco.com> <3B868499.FDF9CC90@hursley.ibm.com> <15239.62194.117588.888735@thomasm-u1.cisco.com> <3B8A4870.F412E939@txc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For sure you can't squeeze all the bits into 20, which is why we went for the PHB ID option where no squeezing is required. As for beating up on IPSEC... that would take a bigger guy than me :-) Brian Alex Conta wrote: > > Michael Thomas wrote: > > > > Brian E Carpenter writes: > > > The issue is that if the packet is classified prior to being > > > encrypted, what do you do if a downstream ISP declines to > > > believe the classification (DCSP value) and wishes to reclassify > > > the packet? The proposal is to put enough semantics in the flow > > > label to allow some degree of classification. > > > > I'm sorry, but this sounds like you're approaching the > > problem backward. If you want transport friendliness so > > that you can reclassify packets, you should beat up on > > the Ipsec WG to revive the transport friendly ESP as > > working group item. Trying to jam the relevant transport > > header into a 20 bit field sounds like a *way* losing > > proposition which has a zero percent possibility of being > > future proof. It's bad enough that we have these middle > > boxes trying to look at L4+ headers, but trying to > > *replicate* data into an obviously too small field for > > every unknown and uninvented protocol going forward... > > ick. > > > > The problem is simple, in spite of all the twists and spins. > > You need to identify flows, and for that you use some fields in the > network header and/or host-to-host header. Reviving the transport > friendly ESP would do only partial good, since the problem of > walking though all the extension headers remains. > > And thus, the validity of the request to have the flow label available > for all IP QoS, including Diffserv, remains. > > Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 09:00:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RG0V40002453 for ; Mon, 27 Aug 2001 09:00:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RG0VTV002452 for ipng-dist; Mon, 27 Aug 2001 09:00:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RG0R40002445 for ; Mon, 27 Aug 2001 09:00:27 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24972 for ; Mon, 27 Aug 2001 09:00:35 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09858 for ; Mon, 27 Aug 2001 09:00:34 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id MAA27007; Mon, 27 Aug 2001 12:01:34 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA00897; Mon, 27 Aug 2001 12:01:32 -0400 Message-ID: <3B8A6ECE.D7703FD6@txc.com> Date: Mon, 27 Aug 2001 12:01:18 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: Bob Hinden , Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) References: <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms87CFA4CC002C078B577734CA" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms87CFA4CC002C078B577734CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Elz wrote: > > Date: Thu, 23 Aug 2001 20:52:00 -0400 > From: Alex Conta > Message-ID: <3B85A530.ADEAA505@txc.com> > > To be even less politically correct ... > > | The IPv6 WG is not a preferential club, or an exclusivist group. The > | IPv6 WG is not to tell the IETF what standard is good and what standard > | is bad. > > That is true, but > > | While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works > | with, and it supports the other IETF standards. > > that is simple nonsense. > > There are all kinds of IETF standards around - a proportion of them are > utter crap. In general, that is no problem - the vast majority of the > rubbish that is proposed, worked on, and then progressed can simply be > ignored - I know it is never going to affect me, because I am going to > ignore it forever. > > But, if you're trying to tell us all that we have to go look at every IETF > standard (and by that I assume you mean PS and up, as there aren't actually > all that many full standards) and make sure that they are supported by IPv6, > then you're way off base. You know well, I was directly referring to QoS support for IP, i.e. network layer protocols. As you know that there are standards to which my statements applies. You do not have to go to an extreme. However, you seem to contradict yourself - you said earlier "that is true". Anyway, standards are in general made because people need or want them. Some may look bad for one, or for a group. But they're good standards as long as they help people that need them. > > Rather, if there are people who actually care about the other work, and need > it to be supported, and they don't think it is, then they need to come to > ipngwg (or whatever the name is this week) and argue for it. Make a persuasive > case for some proposal, and whatever support is needed & possible is likely > to appear. On the other hand, if ipngwg doesn't accept your request, then > tough. > > Up to this point, exactly the right thing had been happening here, with the > request, and the debate (with no clear decision yet that I could make out). > You are in fact POLITICALLY VERY CORRECT. I am not. To have a group of people, within a WG, decide to support with one of the protocol functions, (flow label), only one QoS standard, and not the other QoS standard, just shows me how the process can go wrong. > But attempting to tell the WG that our hands are tied because some other > WG claims to need some feature or other is way off base. The equivalent > would be if ipngwg sent a message to diffserv saying that they had to make > things work with nothing more than a random number, addresses, and > encrypted payload, because that's all they're getting - after all, IPv6 > is a much more mature standard than diffserv. By your reasoning, diffserv > would be compelled to support IPv6 that way. > That is nonsense. It is not just "some feature". There is no equivalence. The flow label part is not mature - you ignore RFC 2460 itself. Furthermore, "random number" is not part of the standard, and rightly so. > I actually treat this message as a concession that there are no strong > enough arguments that can be made to ipngwg that would cause model (c) > for the flow label to be adopted. > > kre There is no concession at all. It brings things in perspective: getting bogged down in details blurs the essence, the very simple principle. IPv6 supports QoS. IPv6 supports currently Intserv, but it support ONLY a subset of Diffserv: BA. We need to add the same level of support for Diffserv. That does not affect any of the current support of Intserv. To have to argue at such a length for the full support of Diffserv, to have to argue for adding the same level of support as it is provided for Intserv, is surrealist, is absurd. --------------ms87CFA4CC002C078B577734CA Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjcxNjAxMjBaMCMGCSqGSIb3DQEJBDEWBBT4JaNbkOtG98Ypu7Xx W/Ztod0zLzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gHiGR5tAI6PjSInnQmSX11X8CakBWa//RDaJ6wzSMdsQ7csrLMJWsJMMO10N2+uNha0LQX93 ScdK05zaeKr3Z9S+ZhazzkYeqYDLxsjZy+rvrxcrXqHHxDoteOnGcdAcTISKlbSIP+BpKZZ3 J9dJ7LdKVum6ZgS+HHfJoFQ9htqy --------------ms87CFA4CC002C078B577734CA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 09:09:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RG9N40002502 for ; Mon, 27 Aug 2001 09:09:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RG9NrH002501 for ipng-dist; Mon, 27 Aug 2001 09:09:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RG9J40002494 for ; Mon, 27 Aug 2001 09:09:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26415 for ; Mon, 27 Aug 2001 09:09:28 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08568 for ; Mon, 27 Aug 2001 10:09:23 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id MAA27214; Mon, 27 Aug 2001 12:10:27 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA01335; Mon, 27 Aug 2001 12:10:27 -0400 Message-ID: <3B8A70E5.168BE24A@txc.com> Date: Mon, 27 Aug 2001 12:10:13 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: huitema@windows.microsoft.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757197FE9@esebe004.NOE.Nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms039FD856179FE31862BFC8E4" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms039FD856179FE31862BFC8E4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jarno, jarno.rajahalme@nokia.com wrote: > > Christian, > > I still believe that "bits are bits". As you pointed out, there is no > certainty that a packet to port 80 will carry HTTP. Therefore we should not > pretend to know. Any classification based on this "make believe" is > inherently flawed (IHO). > > The DSCP (for diffserv) and address + flow label (for intserv) are all that > is needed for determining the right treatment for the packet. > You're forcing the use of a subset of Diffserv on everybody. One MUST be able to use Diffserv with IPv6, at a not lesser extent than Intserv with IPv6. This is even more so, when it does not cost anything, or much, as you seemed to agree at one point. > Information theory wise, the port number stuff you propose is either > redundant or a mistake (the latter in the case of ESP with non-NULL > encryption). > The port number is just a way to represent. Whether you use something else, or not, it does not really matter. Do not get carried away in the "other" semantics of the port number. > The last thing the Internet needs is "content based charging" for transport, > or "good QoS for supported (read $$$) applications only", both scenarios > likely if the scheme you propose would be in place. > > Then again, I might be wrong :-) > > Jarno > --------------ms039FD856179FE31862BFC8E4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjcxNjEwMTVaMCMGCSqGSIb3DQEJBDEWBBQNooYL2IHDGlElVb9q sNmirSAUIjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gFdFhtzwA0KekP9BT5Ys4EKSJi3nc3dx/+LAkcogmTlW7Y6qdt/Qm0EJAFmVZuvKcQdyKPZv VXTm6rBsUZ4EyOzZW+cg/9ixZdHy9t36M/7TxNmuTt0NUaJyFQPPuRihVQKy5iF53MLsdAYz XaizbCvct00LksMYAf3tz78C5b+d --------------ms039FD856179FE31862BFC8E4-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 09:45:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RGji40002643 for ; Mon, 27 Aug 2001 09:45:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RGjiwk002642 for ipng-dist; Mon, 27 Aug 2001 09:45:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RGje40002635 for ; Mon, 27 Aug 2001 09:45:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14781 for ; Mon, 27 Aug 2001 09:45:49 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08427 for ; Mon, 27 Aug 2001 10:45:44 -0600 (MDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7RGjlR26552 for ; Mon, 27 Aug 2001 12:45:47 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7RGjlQ21781 for ; Mon, 27 Aug 2001 12:45:47 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id MAA15994 for ; Mon, 27 Aug 2001 12:45:46 -0400 (EDT) Message-Id: <200108271645.MAA15994@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label In-reply-to: Your message of "Mon, 27 Aug 2001 12:10:13 EDT." <3B8A70E5.168BE24A@txc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Aug 2001 12:45:46 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > You're forcing the use of a subset of Diffserv on everybody. > > One MUST be able to use Diffserv with IPv6, at a not lesser extent than > Intserv with IPv6. > > This is even more so, when it does not cost anything, or much, as you > seemed to agree at one point. IPv6 supports Diffserv today in precisely the same way that IPv4 does. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 11:22:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RIMZ40002760 for ; Mon, 27 Aug 2001 11:22:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RIMZsQ002759 for ipng-dist; Mon, 27 Aug 2001 11:22:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RIMV40002752 for ; Mon, 27 Aug 2001 11:22:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10740 for ; Mon, 27 Aug 2001 11:22:39 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01402 for ; Mon, 27 Aug 2001 12:22:34 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id OAA30078; Mon, 27 Aug 2001 14:23:37 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA07906; Mon, 27 Aug 2001 14:23:37 -0400 Message-ID: <3B8A901F.8217ED36@txc.com> Date: Mon, 27 Aug 2001 14:23:27 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Blake CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <200108271645.MAA15994@castillo.torrentnet.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms205A881422A0637C0BAB77B8" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms205A881422A0637C0BAB77B8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Blake wrote: > > > IPv6 supports Diffserv today in precisely the same way that IPv4 does. > IPv6 has the flow label, and it has extension headers for more than just IPsec, which IPv4 has not. The flow label has a QoS purpose, which means precisely Intserv, and Diffserv. Regards, Alex --------------ms205A881422A0637C0BAB77B8 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjcxODIzMjhaMCMGCSqGSIb3DQEJBDEWBBT5GDe1et7oFUG/YnMi C5EQoP6m+zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gDWTvQ9EtR7Hx6mMSBgbw3zJPUJ/ACNGfM11WGEWd9LDBHz264ux/iO22659RBAp2/6bOlUh xK3j5YLfFMgfJ6S/yn6P1yUJfsuNr50+Hjlm65hgtFoIez2ohXBQtN2hLCHrOywTmTzP+fCw VV8LSc9jXqM3dwfWI3a/DUHnZFru --------------ms205A881422A0637C0BAB77B8-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 12:09:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RJ9f40002869 for ; Mon, 27 Aug 2001 12:09:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RJ9eEj002868 for ipng-dist; Mon, 27 Aug 2001 12:09:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RJ9b40002861 for ; Mon, 27 Aug 2001 12:09:37 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25909 for ; Mon, 27 Aug 2001 12:09:45 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20883 for ; Mon, 27 Aug 2001 12:09:43 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 27 Aug 2001 12:09:05 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id F72967B344724DEA89795D91E28B19FE for plus 2 more; Mon, 27 Aug 2001 12:09:05 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" , "Steve Blake" Cc: Subject: RE: Higher level question about flow label Date: Mon, 27 Aug 2001 12:09:04 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8A901F.8217ED36@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: A73AEE8E-CBBA4E17-B42B97F4-2A8DC5DC Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7RJ9b40002862 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > The flow label has a QoS purpose, which means precisely Intserv, and > Diffserv. While the original purpose of the proposal for the flow label may have been QoS, there is nothing restricting it to that usage. Brian's original note tainted this discussion by including intserv and diffserv in the list. I would argue that options b & c be replaced with: an end-to-end immutable field which may provide a hint to the routers that the sequence of packets with this marking are related How the routers treat that hint is a local administration issue, and outside the scope of any specific QoS model. The routers in the same administrative domain of the originating host may treat those as intserv bits, while an intermediate ISP may ignore them, and at the same time the destination administrative domain may have enough information to treat them as modifiers to a diffserv infrastructure. The point is they are simply a hint from the originator that packets between the src/dst pair are related as far as it is concerned. The only one that may care is the destination host, so trying to invert the non-transitive relationship between the flow label and QoS models is simply wrong. The knowledge that the originator has related a set of packets may be of some use in building a QoS model, while the fact that there is no single definition of QoS across administrative domains means that it is impossible to use any single set of bits to create that definition. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 12:23:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RJNK40002897 for ; Mon, 27 Aug 2001 12:23:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RJNKAd002896 for ipng-dist; Mon, 27 Aug 2001 12: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RJNG40002889 for ; Mon, 27 Aug 2001 12:23:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28404 for ; Mon, 27 Aug 2001 12:23:19 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25165 for ; Mon, 27 Aug 2001 13:23:45 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id PAA31176; Mon, 27 Aug 2001 15:24:17 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id PAA10705; Mon, 27 Aug 2001 15:24:17 -0400 Message-ID: <3B8A9E4E.B1C43558@txc.com> Date: Mon, 27 Aug 2001 15:23:58 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Eklund CC: "'Brian E Carpenter '" , "'Kastenholz, Frank '" , "'ipng@sunroof.eng.sun.com '" Subject: Re: Higher level question about flow label References: <31A473DBB655D21180850008C71E251A04ECAA10@mail.kebne.se> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms18B482E9C51B6199E5A48BDD" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms18B482E9C51B6199E5A48BDD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please note that at lower line speeds, you may find silicon QoS engines, which for lowering the costs, have implementations of classifiers without using CAMs. The MF classification is still in the fast path, and of course is still critical. Alex Thomas Eklund wrote: > > Brian, > This is the key since many that do network processors are in fact fixed > function ASICs (or configurale state machine approaches) and those are not > programmable they are only configurable. > > Count us in as the second you know. > > And in fact most of the network processors have MF classifiers in the fast > path (forwarding plane). The limiting factor is of course the speed of the > CAM's. > > -- thomas > > -----Original Message----- > From: Brian E Carpenter > To: Kastenholz, Frank > Cc: ipng@sunroof.eng.sun.com > Sent: 2001-08-25 00:10 > Subject: Re: Higher level question about flow label > > Frank, > > Not all network processors have the degree of inertia > you describe. I know of at least one that can adapt to > format changes without new silicon. But that aside, > what I am talking about is multi-field classifiers in > border routers, not what happens in core/trunk routers > where you are completely correct - that is why the diffserv > code point is 6 bits (sorry, we couldn't squeeze to 4). > Multi-field classifiers don't need to be "slow path" but > they aren't subject to quite the constraints you mention, > in the diffserv architecture. > > This is the essence of why diffserv scales and intserv > doesn't- you only need to do multi-field classification > at the borders. Actually the format we are proposing > simplifies MF classifiers because it takes away the need > to look at port and protocol numbers. > > Brian > > "Kastenholz, Frank" wrote: > > > > All this talk about the format of the flow-id field > > is rather interesting. But one thing has been missing -- > > input from someone who will actually _look_ at the > > field, at very very very high speeds, in hardware, > > and make forwarding decisions based on it. > > > > I am fairly confident in saying that there will not > > be many sqmm of silicon devoted to determining > > if the flow id is 'intserv-format' or 'diff-serv > > format' or 'tennis-serv format'. The edit/compile > > /debug loop of silicon is such that we can not > > react soon enough to the next format that is > > developed. This means that the flowid looker- > > upper will be very very general. That means > > that we don't care what the format is. We just > > take the whole 20-bits and look 'em up (e.g., > > throw them all at a CAM, and see what comes out) > > > > The only thing that would make the looker-upper's > > job easier is to know that the flow-id is going > > going to be shorter than 20 bits (maybe via the > > protocol specification, maybe via some software > > magic ala MPLS label negotiations). A looker-upper > > that is limited to 4 bits is a different beast > > than a looker-upper that does 20. > > > > So, you folks can argue all you want about the format > > of the flow-id and those format differences may matter > > at some level in the software. But to the people who > > are the actual customers of the bits -- the silicon > > forwarders -- it just doesn't matter. > > > > Frank Kastenholz > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- --------------ms18B482E9C51B6199E5A48BDD Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjcxOTI0MTRaMCMGCSqGSIb3DQEJBDEWBBTRUuhv/J7ukcZ9dalA 7Gf0SwkwxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gIb450JbgS5GfBlmqvwE1UROAGfFifbdfNvyPEv5RMC6jtrnGfrAgkpeaU0XcPonTRShw4cS ZPGQobrlhduFYX2zWZP3tQ055RT+csGaR6/GEDoBz2KiVwdWLzhYj/FNy1fDGPp/50fRkn5V TvbrM+2qEhfDe+jsRml3/zcJDaSs --------------ms18B482E9C51B6199E5A48BDD-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 13:17:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RKHH40002960 for ; Mon, 27 Aug 2001 13:17:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RKHHRU002959 for ipng-dist; Mon, 27 Aug 2001 13:17:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RKHD40002952 for ; Mon, 27 Aug 2001 13:17:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18442 for ; Mon, 27 Aug 2001 13:17:20 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19680 for ; Mon, 27 Aug 2001 14:17:43 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA32130; Mon, 27 Aug 2001 16:18:18 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA13199; Mon, 27 Aug 2001 16:18:17 -0400 Message-ID: <3B8AAB06.99B0C6F5@txc.com> Date: Mon, 27 Aug 2001 16:18:14 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: Bob Hinden , Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) References: <20010827132718.83C5C7BB@starfruit.itojun.org> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms318034DED719BE2CB6A349B9" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms318034DED719BE2CB6A349B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To avoid repeating pretty much what was already said, please see Thomas Eklund messages. Jun-ichiro itojun Hagino wrote: > > >As I think that no standard should be excluded, I think that IPv6 WG > >should do its best, to make IPv6 work well, friendly with MPLS. Which is > >in a way [a subset of a)]+c). > > could you describe "[a subset of a] + c" in more detail so that > people can understand you better? > > itojun --------------ms318034DED719BE2CB6A349B9 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjcyMDE4MTRaMCMGCSqGSIb3DQEJBDEWBBQu4hpmhCxWT2LOjB+p g0geF6F1tTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gJfie8VnBhJMssHc1PafqSuby5Z8n1LKD142sT80osY/ds1uxUwiBpY2VzyTxTe/fxdaR7yj b4S/M9FsyvNp7eg1vAZUYu8wNDhk7SyHpylatK/IfaA85DNKruUz6tcbi4aluEBkU5esiSYm fTDzZh76zjH+cUVuPIlx/Di+Jrsj --------------ms318034DED719BE2CB6A349B9-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 13:27:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RKR140002981 for ; Mon, 27 Aug 2001 13:27:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RKR1O1002980 for ipng-dist; Mon, 27 Aug 2001 13:27:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RKQv40002973 for ; Mon, 27 Aug 2001 13:26:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00708 for ; Mon, 27 Aug 2001 13:27:06 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24465 for ; Mon, 27 Aug 2001 14:27:28 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA32266; Mon, 27 Aug 2001 16:28:04 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA13630; Mon, 27 Aug 2001 16:28:04 -0400 Message-ID: <3B8AAD50.866665BB@txc.com> Date: Mon, 27 Aug 2001 16:28:00 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms710ADCF96F53499AC1014CDF" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms710ADCF96F53499AC1014CDF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > [...]The > only one that may care is the destination host, could you please clarify/elaborate? > so trying to invert > the non-transitive relationship between the flow label and QoS models > is simply wrong. could you please clarify/elaborate? > [...] while the fact > that there is no single definition of QoS across administrative domains > means that it is impossible to use any single set of bits to create > that definition. > > Tony could you please clarify/elaborate? Thanks, Alex --------------ms710ADCF96F53499AC1014CDF Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjcyMDI4MDJaMCMGCSqGSIb3DQEJBDEWBBRI1qSs4P4kB80XeB6U cTf2/FI2dTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gIV/FxQZMlTiajgueZXgWrhoqNQCILqEOtUJkCxGEduKi0tGoNCRSvk/8m/ovx2/OBedHcSl y2KG0iWw1wt4hQ3/jMmIxHOK294DnOWKUPVMaz8Bl/2Ko9ZmtFX1evQi2UhfHiQUdC+Ge5cA g+BsrdwWKJzadtN5UrZVjZqlQLk2 --------------ms710ADCF96F53499AC1014CDF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 13:39:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RKdq40003010 for ; Mon, 27 Aug 2001 13:39:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RKdqqL003009 for ipng-dist; Mon, 27 Aug 2001 13:39:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RKdm40003002 for ; Mon, 27 Aug 2001 13:39:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03516 for ; Mon, 27 Aug 2001 13:39:57 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12348 for ; Mon, 27 Aug 2001 14:39:52 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA08512; Mon, 27 Aug 2001 21:39:54 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA37348; Mon, 27 Aug 2001 21:39:53 +0100 Message-ID: <3B8AADC7.A75A1BE8@hursley.ibm.com> Date: Mon, 27 Aug 2001 15:29:59 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Steve Blake CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <200108271645.MAA15994@castillo.torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Blake wrote: > > > You're forcing the use of a subset of Diffserv on everybody. > > > > One MUST be able to use Diffserv with IPv6, at a not lesser extent than > > Intserv with IPv6. > > > > This is even more so, when it does not cost anything, or much, as you > > seemed to agree at one point. > > IPv6 supports Diffserv today in precisely the same way that IPv4 does. Indeed. The proposal on the table is to give IPv6 an edge in the case of ESP packets. 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 Aug 27 14:05:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RL5A40003093 for ; Mon, 27 Aug 2001 14:05:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RL59Z3003092 for ipng-dist; Mon, 27 Aug 2001 14:05:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RL5240003085 for ; Mon, 27 Aug 2001 14:05:03 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19963 for ; Mon, 27 Aug 2001 14:05:06 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11943 for ; Mon, 27 Aug 2001 14:05:04 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA21236; Mon, 27 Aug 2001 22:05:02 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA40400; Mon, 27 Aug 2001 22:04:56 +0100 Message-ID: <3B8AB364.33865DF2@hursley.ibm.com> Date: Mon, 27 Aug 2001 15:53:56 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Alex Conta , Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Tony Hain wrote: > > Alex Conta wrote: > > > The flow label has a QoS purpose, which means precisely Intserv, and > > Diffserv. > > While the original purpose of the proposal for the flow label may have > been QoS, there is nothing restricting it to that usage. Brian's original > note tainted this discussion by including intserv and diffserv in the > list. I would argue that options b & c be replaced with: > > an end-to-end immutable field which may provide a hint to the routers > that the sequence of packets with this marking are related I have to disagree very strongly with this. The proposal on the table is much stronger, is directly based on the IETF's two QOS mechanisms, is specific, and doesn't "taint" anything at all. Your text is vague, and it prejudges the "immutability" which is more a consequence of the intserv and proposed diffserv usages than a precondition. > How the routers treat that hint is a local administration issue, and > outside the scope of any specific QoS model. Not at all. Our two QOS mechanisms are specific. There will be local configuration issues for both diffserv and intserv, but the mechanisms are universal and specific. > The routers in the same > administrative domain of the originating host may treat those as > intserv bits, while an intermediate ISP may ignore them, and at the > same time the destination administrative domain may have enough > information to treat them as modifiers to a diffserv infrastructure. No. There is no meaningful way that the same flow label can serve both intserv and diffserv. The mechanisms involved are just plain different. > The point is they are simply a hint from the originator that packets > between the src/dst pair are related as far as it is concerned. The Thet are actually more than a hint. In the proposal on the table, there are three very specific statements that the flow label may make: a) this {source address, flow label} identifies a specific microflow b) this {flow label} identifies traffic requiring a specific per-hop bahavior c) this {flow label = 0} identifies no QOS requirement > only one that may care is the destination host, No, the destination host is the least likely system to care (although it might do some inbound queue handling based on the flow label, this is certainly not a baseline requirement). > so trying to invert > the non-transitive relationship between the flow label and QoS models > is simply wrong. This statement defeats me. In the intserv case the flow label is an arbitrary number and in the proposed diffserv case it is in a 1:1 relationship with the QOS service class - that is why we chose the PHB ID option. It's as transitive as they come. > The knowledge that the originator has related a set > of packets may be of some use in building a QoS model, Which QOS model? We have two, and they are different and require different flow label semantics to work. > while the fact > that there is no single definition of QoS across administrative domains > means that it is impossible to use any single set of bits to create > that definition. See RFC 3140. 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 Aug 27 14:14:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RLEC40003112 for ; Mon, 27 Aug 2001 14:14:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RLEBo9003111 for ipng-dist; Mon, 27 Aug 2001 14:14:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RLE840003104 for ; Mon, 27 Aug 2001 14:14:08 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21836 for ; Mon, 27 Aug 2001 14:14:17 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02778 for ; Mon, 27 Aug 2001 14:14:16 -0700 (PDT) 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 OAA13333; Mon, 27 Aug 2001 14:14:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7RLEEE06601; Mon, 27 Aug 2001 14:14:14 -0700 X-mProtect: Mon, 27 Aug 2001 14:14:14 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpd8hHjH6; Mon, 27 Aug 2001 14:13:20 PDT Message-Id: <4.3.2.7.2.20010827140650.01ca2d70@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 14:12:12 -0700 To: Alex Conta From: Bob Hinden Subject: Re: Higher level question about flow label Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3B8A901F.8217ED36@txc.com> References: <200108271645.MAA15994@castillo.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, >IPv6 has the flow label, and it has extension headers for more than just >IPsec, which IPv4 has not. >The flow label has a QoS purpose, which means precisely Intserv, and >Diffserv. There are other uses of flows (and possibly the flow label field) that have nothing to do with QOS. It isn't limited to Intserv/Diffserv. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 14:32:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RLW540003138 for ; Mon, 27 Aug 2001 14:32:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RLW5MR003137 for ipng-dist; Mon, 27 Aug 2001 14:32:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RLW240003130 for ; Mon, 27 Aug 2001 14:32:02 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04463 for ; Mon, 27 Aug 2001 14:32:11 -0700 (PDT) Received: from roam.psg.com ([210.61.172.63]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10421 for ; Mon, 27 Aug 2001 14:32:10 -0700 (PDT) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bTzK-0004Jq-00; Tue, 28 Aug 2001 05:32:06 +0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "An analysis of IPv6 anycast" References: <20010827124137.E8FCA7BC@starfruit.itojun.org> Message-Id: Date: Tue, 28 Aug 2001 05:32:06 +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> as it is used for dns etc. *within* a single provider, it can be an igp >> which is used, not bgp. > i see, but are there such practice exist? only for the large providers and for over five years. > how do they cope with server failures and IGP flaps? inject into igp. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 14:49:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RLn840003173 for ; Mon, 27 Aug 2001 14:49:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RLn8Fe003172 for ipng-dist; Mon, 27 Aug 2001 14:49:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RLn440003165 for ; Mon, 27 Aug 2001 14:49:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07994 for ; Mon, 27 Aug 2001 14:49:13 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02374 for ; Mon, 27 Aug 2001 15:49:09 -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 OAA15804; Mon, 27 Aug 2001 14:49:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7RLnAp00991; Mon, 27 Aug 2001 14:49:10 -0700 X-mProtect: Mon, 27 Aug 2001 14:49:10 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdBIi1qa; Mon, 27 Aug 2001 14:48:38 PDT Message-Id: <4.3.2.7.2.20010827111610.0225c1b8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 14:48:09 -0700 To: Alex Conta From: Bob Hinden Subject: Re: a), b), c), d), or e) Cc: ipng In-Reply-To: <3B85A530.ADEAA505@txc.com> References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, I am responding because you sent the email to me directly. At 08:52 PM 8/23/2001 -0400, Alex Conta wrote: >Brian, Bob, > >I respect very much the IPv6 WG, the WG's chairs, and the participants >to the thread that Brian >started, in an effort to move in the right direction. Thanks you. >But in my opinion -- perhaps as usual, less politically correct than >Brian -- I do not think that the IPv6 WG has a choice, that we have a >choice. The IPv6, or any other working group for that matter, always have any choices. The process is driven by "rough consensus". The scope of a working group work is defined by it's charter. The only mention of the flow label in the new IPv6 w.g. charter recently approved by the IESG is: The working group would welcome contributions on the following topics (this is not an exhaustive list): - Flow label standardization ..... This is far from saying the working group must do something. Many working groups do less than their charter :-) >IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's >IPv6. > >This puts a tremendous responsibility, but also demands a certain code >of conduct, or direction of thinking for all of us. If that is not >captured in the charter, I think it should. > >The IPv6 WG is not a preferential club, or an exclusivist group. The The chairs try to keep the working group process open and fair. >IPv6 WG is not to tell the IETF what standard is good and what standard >is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works >with, and it supports the other IETF standards. I don't think your statements are correct. There is not a formal IETF requirement that the working groups output support all other IETF standards. >Intserv, and RSVP completed work (WGs closed). Diffserv started is well >on its way. They are TWO IETF models for IP QoS, and are both on the >IETF standards track. Correct. There may also be new methods for IP QoS defined in the future. If I remember correctly, Diffserv was created after the scaling problems with Intserv/RSVP were better understood. >So, in terms of mechanisms to be standardized for the IPv6 flow label, >it is no question in my mind that right now WE MUST DO: You are, of course, entitled to your opinion. >c) - standardization of the flow label for IP QoS, e.g. Intserv, and >Diffserv. > >The choice is the user's, e.g. end users and network providers, to use >or not, one (Intserv), the other (Diffserv), or both, when deploying >IPv6. "c)" is one of the choices being discussed on the mailing list. From my read of the list, I don't see a consensus on any of the choices. >Furthermore, personally, I think that if the IPv6 flow label would have >been done right, we would not have MPLS, and IPv6 would have given even >more reasons to be adopted/deployed. I do not agree with this statement and would note that it ignores the use of MPLS for IPv4. IPv4 does not have a flow label field. >At this point is too late, if for no other reason than just that MPLS is >a IETF standard on its way, and its own right, and that with the current >IPv6 header format, the flow label cannot match the efficiency of all >MPLS's features anyway. MPLS will swim or sink on it's own merits. I don't think this has much to do with IPv6. >As I think that no standard should be excluded, I think that IPv6 WG >should do its best, to make IPv6 work well, friendly with MPLS. Which is >in a way [a subset of a)]+c). The IETF creates a lot of standards. They cover all parts of the protocol stack. Did you really mean to include all of them in your assertion? For example, I bet we could figure out way of including of encoding a DNS name in the flow label field to improve the performance of reverse lookups. Email addresses? Perhaps you only meant to include MPLS, Diff Serv, and Int Serv standards in your assertion. In this case, I don't think that the w.g. has to do this (i.e., MUST). I think we could standardize a specific use of the flow label field (beyond what is in the current RFC) if there was a compelling technical argument made and there was a rough consensus around that approach instead of the other choices. However, it will have to a reason more compelling than other IETF working groups have standardized something. Bob p.s. For what it is worth, my current thinking is that I would prefer not use the flow label field for any specific QOS approach(s). I am open to something that makes it easier to identify flows. This could be used for QOS or other flow related applications. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 27 15:29:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RMTg40003202 for ; Mon, 27 Aug 2001 15:29:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RMTgjB003201 for ipng-dist; Mon, 27 Aug 2001 15:29:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RMTc40003194 for ; Mon, 27 Aug 2001 15:29:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00328 for ; Mon, 27 Aug 2001 15:29:41 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28524 for ; Mon, 27 Aug 2001 16:29:36 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA24434; Mon, 27 Aug 2001 23:29:38 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA20956; Mon, 27 Aug 2001 23:29:39 +0100 Message-ID: <3B8ACA09.5F8C3EBB@hursley.ibm.com> Date: Mon, 27 Aug 2001 17:30:33 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bob Hinden CC: Alex Conta , ipng Subject: Re: a), b), c), d), or e) References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <4.3.2.7.2.20010827111610.0225c1b8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Responding to your final comment, which I guess you made while out of the chair for a second... Bob Hinden wrote: > ... > p.s. For what it is worth, my current thinking is that I would prefer not > use the flow label field for any specific QOS approach(s). I am open to > something that makes it easier to identify flows. This could be used for > QOS or other flow related applications. The flaw in this is that one of the IETF's two QOS models is *not* flow oriented - that is the entire reason why diffserv would need a flow label with defined semantics. We could decide not to give diffserv such a flow label, of course. But that is a binary decision that IMHO needs to be taken soon. So let me try to reduce this to a yes/no question for this WG: Should we give half the flow label space to diffserv as an e2e field, as at the beginning of section 7.1 of draft-conta-ipv6-flow-label-02.txt, specifically so that IPv6 can support diffserv for ESP packets? (This specifically does not address the encoding of the diffserv flow label, which on balance is probably a matter for diffserv.) > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Pseudo-Random Value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Diffserv IPv6 Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 15:35:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RMZw40003227 for ; Mon, 27 Aug 2001 15:35:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RMZwk0003226 for ipng-dist; Mon, 27 Aug 2001 15:35:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RMZs40003219 for ; Mon, 27 Aug 2001 15:35:54 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17361 for ; Mon, 27 Aug 2001 15:36:02 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23134 for ; Mon, 27 Aug 2001 15:36:00 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 27 Aug 2001 15:35:22 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id D5ACC65983FF47A48D4F85819366377F for plus 4 more; Mon, 27 Aug 2001 15:35:22 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" Cc: "Alex Conta" , "Steve Blake" , Subject: RE: Higher level question about flow label Date: Mon, 27 Aug 2001 15:35:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8AB364.33865DF2@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: D60E5299-FA454416-903E5469-2FD59605 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7RMZs40003220 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: >> ... >> an end-to-end immutable field which may provide a hint to the routers >> that the sequence of packets with this marking are related > > I have to disagree very strongly with this. The proposal on the table > is much stronger, is directly based on the IETF's two QOS mechanisms, > is specific, and doesn't "taint" anything at all. Your text > is vague, and > it prejudges the "immutability" which is more a consequence > of the intserv > and proposed diffserv usages than a precondition. > I am sorry, I did not intend to be vague. The proposed wording is intended to be a precise definition for the field, and explicitly leaves out the letters Q, o, & S. > > How the routers treat that hint is a local administration issue, and > > outside the scope of any specific QoS model. > > Not at all. Our two QOS mechanisms are specific. There will be local > configuration issues for both diffserv and intserv, but the mechanisms > are universal and specific. > My original statement here was poorly worded. Yes QoS handling is very specific. My point was that the field is not strictly tied to QoS, and therefore the interpretation of the field is a local administration issue. > > The routers in the same > > administrative domain of the originating host may treat those as > > intserv bits, while an intermediate ISP may ignore them, and at the > > same time the destination administrative domain may have enough > > information to treat them as modifiers to a diffserv infrastructure. > > No. There is no meaningful way that the same flow label can serve both > intserv and diffserv. The mechanisms involved are just plain > different. > Yes the mechanisms are different, but that does not mean they are exclusive. It is not hard to imagine a site with rules for intserv use of the bits which slightly reduce the randomness of the flow label in a way that the traffic class field could be reconstructed by the destination site after the ISPs randomize it. This would of course require the destination site to know the rules the origin used, but nothing precludes that. Once reconstructed the destination site could make decisions based on the TC, while the origin used intserv based on the flow label. > > The point is they are simply a hint from the originator that packets > > between the src/dst pair are related as far as it is concerned. The > > Thet are actually more than a hint. In the proposal on the table, > there are three very specific statements that the flow label may make: > > a) this {source address, flow label} identifies a specific microflow > b) this {flow label} identifies traffic requiring a specific > per-hop bahavior > c) this {flow label = 0} identifies no QOS requirement > I didn't read the original message that way. In any case what I was trying to argue is a), strictly worded as it is here without any mention of QoS handling, or implication that 'microflow' means intserv. All the originator is doing is telling anyone that cares to listen that the set of packets with this marking are related. > > only one that may care is the destination host, > > No, the destination host is the least likely system to care > (although it might > do some inbound queue handling based on the flow label, this > is certainly > not a baseline requirement). > It might also want to use that field to demux flows over port 443 to enable an application to work through a firewall. The point is it is an end-to-end immutable field that the source uses to identify a specific set of packets as a flow. > > so trying to invert > > the non-transitive relationship between the flow label and > QoS models > > is simply wrong. > > This statement defeats me. In the intserv case the flow label > is an arbitrary > number and in the proposed diffserv case it is in a 1:1 relationship > with the QOS service class - that is why we chose the PHB ID option. > It's as transitive as they come. > >From the viewpoint that the field is limited to use for QoS those are hard relationships. My point was that QoS is not the only possible use for the field. Overlaying a QoS interpretation is fine, but insisting that all other interpretations are invalid is wrong. > > The knowledge that the originator has related a set > > of packets may be of some use in building a QoS model, > > Which QOS model? We have two, and they are different and require > different flow label semantics to work. > I fail to understand how either would break if they simply intrepret the flow label semantics as 'the source has identified this set of packtes as related'. In either case there is an out-of-band mechansim to translate the value to a router task. The place you appear to be struggling is finding a standard mapping between a psuedo random value and the Traffic Class field. Since the Traffic Class field is itself a non-standard value (and effectivly psuedo random from an end-to-end perspective) this seems pointless. > > while the fact > > that there is no single definition of QoS across > administrative domains > > means that it is impossible to use any single set of bits to create > > that definition. > > See RFC 3140. > >From the above: In a given network domain, there is a locally defined mapping between DSCP values and PHBs. Therefore my statement stands, there is no single definition of QoS across administrative domains. > Brian Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 15:40:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RMev40003299 for ; Mon, 27 Aug 2001 15:40:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RMevqw003298 for ipng-dist; Mon, 27 Aug 2001 15:40:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RMet40003291 for ; Mon, 27 Aug 2001 15:40:55 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7RMcx003241 for ipng@sunroof.eng.sun.com; Mon, 27 Aug 2001 15:38:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7QJ7340001055 for ; Sun, 26 Aug 2001 12:07:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08818 for ; Sun, 26 Aug 2001 12:07:07 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05590 for ; Sun, 26 Aug 2001 13:07:31 -0600 (MDT) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id MAA02041; Sun, 26 Aug 2001 12:07:06 -0700 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sun, 26 Aug 2001 12:07:05 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org Subject: RE: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0D4A046D@nl0006exch002u.nl.lucent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 26 Aug 2001, Wijnen, Bert (Bert) wrote: > > -----Original Message----- > > From: C. M. Heard [mailto:heard@pobox.com] > > Sent: dinsdag 7 augustus 2001 1:29 > > To: ipng@sunroof.eng.sun.com; mibs@ops.ietf.org > > Subject: Re: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 [ ... ] > > > > On Fri, 27 Jul 2001, Bill Fenner wrote: > > > The plan is to deprecate the existing objects in these RFCs > > > in favor of the protocol-independent ones. The exact plan is not > > > yet known (e.g. publish a new revision with all objects listed > > > as deprecated vs. reclassify the old RFCs as historic, etc.). > > > > And as one can see explicitly from the drafts themselves, the intent > > is also to deprecate all of the IPv4-specific stuff in RFC 2011, > > RFC 2012, RFC 2013, and RFC 2096. Note that the MIB modules in the > > first three of these RFCs are simply translations into SMIv2 of > > the MIB-II IP group (less routing table), TCP group, and UDP group, > > respectively; the substance is unchanged from RFC 1213. > > > > > The intent is definitely not to suddenly cause existing > > > implementations to be non-standard, but to encourage evolution. > > > > But that's PRECISELY what adoption of these drafts in their present > > form would do. Where new compliance statements exist, they make the > > new version-independent objects unconditionally mandatory and don't > > mention the version-specific objects. That makes existing > > implementations > > non-compliant and (if the drafts were to be adopted as standards) > > non-standard. > > > I doubt that this is true. The objects are DEPRECATED, which means they > are they are specifically there for backward compatibility and continued > interoperability with old/existing implementations. > If we wanted to break with backward compatibility, then we would OBSOLETE > those objects. See RFC2578 section 6.1 for details. RFC 2578 says: The value "obsolete" means the definition is obsolete and should not be implemented and/or can be removed if previously implemented. While the value "deprecated" also indicates an obsolete definition, it permits new/continued implementation in order to foster interoperability with older/existing implementations. Note well: this _permits_ new/continued implementation of deprecated objects, but does not _require_ it. It is left to the module's compliance statements to specify whether the deprecated objects are optional, conditionally mandatory, or unconditionally mandatory. Because of the wide deployment of the stuff in RFC 2011, RFC 2012, and RFC 2013 (i.e. the IP, ICMP, TCP, and UDP groups in RFC 1213 less the ipRouteTable), continued interoperation with deployed IPv4-only managers (respectively agents) will _require_ that new agents (respectively managers) implement the IPv4-only objects in these MIB modules. Thus, to avoid a break with backward compatibility, it seems to me that the compliance statements in the documents that replace RFC 2011, RFC 2012, and RFC 2013 need to make these objects manadatory for implementations that support IPv4. The present round of drafts does not do this. > > Notice that it is not just existing implementations of the existing > > IPv6 MIBs in RFC 2452, RFC 2454, RFC 2465, and RFC 2466 that would > > be destandardized, but also existing implementations of the MIB-II > > IP, TCP, and UDP groups. The older IPv4-specific objects have in all > > cases been deprecated in favor of the new protocol-independent objects, > > and so have the old IPv4-specific compliance statements. > > > So we want to encourage new implementations to use the new objects while > existing ones can continue to use the old ones. The old ones in fact > are still at Full Standard (RFC1213) for quite a while to come. But the new implementations need to implement the old IPv4-only objects in RFC 1213 in order to interoperate with old implementations. Shouldn't this be an explicit _requirement_ of the conformance statements in the new documents? > I hope this eases some of your concerns. Some, but not all. I am still troubled that the drafts that are proposed to replace RFC 2012 and RFC 2013 (IPv4-only TCP and UDP MIBs) and RFC 2452 and RFC 2454 (IPv6-only TCP and UDP MIBs) are fixing some things that are not actually broken. Maybe it is more elegant to have one combined version-independent connection table/listener table instead to two version-specific ones, but there is no gain at all in functionality. I ask again: it it worth the implementation churn to make what is, in effect, and aesthetic change? I can see a reason to republish RFC 2452 and RFC 2454 to improve the compliance statements (i.e. to explicity reference the necessary objects from RFC 2012 and RFC 2013), but I can't see what it buys to replace the version-specific connection and listener tables, especially since the the IPv4-specifc ones need to be implemented anyway in order to maintain interoperability with deployed implementations. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 15:44:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RMie40003318 for ; Mon, 27 Aug 2001 15:44:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RMie55003317 for ipng-dist; Mon, 27 Aug 2001 15:44:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RMia40003310 for ; Mon, 27 Aug 2001 15:44:36 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09641 for ; Mon, 27 Aug 2001 15:44:43 -0700 (PDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA26216 for ; Mon, 27 Aug 2001 15:44:43 -0700 (PDT) Received: from 157.54.9.108 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Aug 2001 15:44:11 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:44:07 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:44:10 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:43:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: a), b), c), d), or e) Date: Mon, 27 Aug 2001 15:43:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a), b), c), d), or e) Thread-Index: AcEvSBkrIvYRct5RSfS+zxnLQMKLmAAAOjuA From: "Christian Huitema" To: "Brian E Carpenter" , "Bob Hinden" Cc: "Alex Conta" , "ipng" X-OriginalArrivalTime: 27 Aug 2001 22:43:48.0143 (UTC) FILETIME=[BC4DFBF0:01C12F49] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7RMia40003311 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| Pseudo-Random Value | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| Diffserv IPv6 Flow Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Could we be a bit parcimonious and reserve a couple of header bits "for further use"? We don't seem to have a level of consensus in the group that people can guarantee that either a bunch of random bits, or a diffserv flow label, are absolutely the best thing since sliced bread. Not at the same level as the payload type or payload length, in any case. It would be nice to be able to invent something like ECN in 2010... Maybe we could make it something like 4 bits of "label type" and 16 bits of label value, defining then the possibilities for "0-0", "0-random" and "1-diffserv" -- whatever that means. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 16:07:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RN7H40003360 for ; Mon, 27 Aug 2001 16:07:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RN7HG4003359 for ipng-dist; Mon, 27 Aug 2001 16:07:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RN7C40003352 for ; Mon, 27 Aug 2001 16:07:13 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23254 for ; Mon, 27 Aug 2001 16:07:20 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04314 for ; Mon, 27 Aug 2001 16:07:19 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 27 Aug 2001 16:06:37 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 521D87A5E84E4CC099C85B586D66647D for plus 3 more; Mon, 27 Aug 2001 16:06:37 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" , "Bob Hinden" Cc: "Alex Conta" , "ipng" Subject: RE: a), b), c), d), or e) Date: Mon, 27 Aug 2001 16:06:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8ACA09.5F8C3EBB@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 57204625-CD4341BD-A8AEE1DC-384490C2 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7RN7E40003353 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > The flaw in this is that one of the IETF's two QOS models is > *not* flow > oriented - that is the entire reason why diffserv would need > a flow label > with defined semantics. This appears to defy logic. The way I read it, we have a QoS mechanism that by-design is not end-to-end oriented, so we MUST define a way for the middle to interpret what the end points are telling each other.?!? There is absolutly no reason to tie the Flow Label field and the Traffic Class field together, which is the only point of defining diffserv semantics for the Flow Label. There is no more need for a diffserv host to use a structured value for the Flow Label than there is for an intserv host to do so. The field is an end-to-end identification of packet relationships, nothing more. The Traffic Class field identifies PHBs, nothing more. They both exist in the packet from the origin, so why is it required that there be a relationship? The set of packets identified as a flow will be the same with either QoS mechansim, so why is there a need to have distinct semantics unless someone in the middle wants to interpret them? Since the middle is supposed to be per-hop and not end-to-end, why would it care what the endpoints are saying? Basically, why is it suddenly required that we define end-to-end semantics for a DSCP in the FL field, when the diffserv WG refused to do so for the TC field? If diffserv needs end-to-end agreement on the DSCP/PHB mappings (which I believe it does for non-technical reasons) then the work should be done in the TC field. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 16:59:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RNxN40003411 for ; Mon, 27 Aug 2001 16:59:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7RNxNJc003410 for ipng-dist; Mon, 27 Aug 2001 16:59:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7RNxJ40003403 for ; Mon, 27 Aug 2001 16:59:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03785 for ; Mon, 27 Aug 2001 16:59:27 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18488 for ; Mon, 27 Aug 2001 17:59:21 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id DC1897C2; Tue, 28 Aug 2001 08:59:13 +0900 (JST) To: Randy Bush Cc: ipng@sunroof.eng.sun.com In-reply-to: randy's message of Tue, 28 Aug 2001 05:32:06 +0800. 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: W.G. Last Call on "An analysis of IPv6 anycast" From: Jun-ichiro itojun Hagino Date: Tue, 28 Aug 2001 08:59:13 +0900 Message-Id: <20010827235913.DC1897C2@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> as it is used for dns etc. *within* a single provider, it can be an igp >>> which is used, not bgp. >> i see, but are there such practice exist? >only for the large providers and for over five years. >> how do they cope with server failures and IGP flaps? >inject into igp. what i was asking is, what happens when: - IGP route is not stable at this point (*) - someone try to establish TCP to the (IGP) anycast address - first packet goes to server A, and second goes to server B (*) may mean that the provider is in unstable state:-) anyway, the technique is just for short-lived transaction, just as stated in the draft. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 17:05:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S05I40003430 for ; Mon, 27 Aug 2001 17:05:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7S05IJG003429 for ipng-dist; Mon, 27 Aug 2001 17:05:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S05E40003422 for ; Mon, 27 Aug 2001 17:05:15 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19160 for ; Mon, 27 Aug 2001 17:05:23 -0700 (PDT) Received: from roam.psg.com ([210.61.172.63]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24485 for ; Mon, 27 Aug 2001 17:05:21 -0700 (PDT) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bWNW-0004QM-00; Tue, 28 Aug 2001 08:05:14 +0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "An analysis of IPv6 anycast" References: <20010827235913.DC1897C2@starfruit.itojun.org> Message-Id: Date: Tue, 28 Aug 2001 08:05:14 +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > what i was asking is, what happens when: > - IGP route is not stable at this point (*) > - someone try to establish TCP to the (IGP) anycast address > - first packet goes to server A, and second goes to server B much talk and fud about this. in practice, this does not seem to be a problem. e.g. some years back, we did a two hour streaming videocast to over 100k users, 200mb of traffic, from a dozen anycast servers. not one noc call. not that i would advise running nuclear weapons on long-lived tcp to anycast. but we don't need to prevent people using what they use today. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 27 23:12:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S6CA40003584 for ; Mon, 27 Aug 2001 23:12:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7S6CAra003583 for ipng-dist; Mon, 27 Aug 2001 23:12:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S6C640003576 for ; Mon, 27 Aug 2001 23:12:06 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25600 for ; Mon, 27 Aug 2001 23:12:16 -0700 (PDT) Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05741 for ; Mon, 27 Aug 2001 23:12:15 -0700 (PDT) Received: from rami (root@varis.cs.tut.fi [130.230.4.42]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id JAA01777 for ; Tue, 28 Aug 2001 09:12:14 +0300 (EET DST) From: "Rami Lehtonen" To: "ipng" Subject: RE: a), b), c), d), or e) Date: Tue, 28 Aug 2001 09:12:51 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: <4.3.2.7.2.20010827111610.0225c1b8@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > p.s. For what it is worth, my current thinking is that I would prefer not > use the flow label field for any specific QOS approach(s). I am open to > something that makes it easier to identify flows. This could be used for > QOS or other flow related applications. I'm not followed the whole chain of the flow label discussion, but I was curious enough to ask what are the reasons why we doesn't use the flow label just for identification of different flows. We could calculate e.g. a hash value from the IP addresses, port numbers and protocol number at the client side and then put that value in the flow label field. That value could be efficiently used by the network or the receiver to different flow identification purposes even with ESP headers. - Rami Lehtonen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 01:04:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S84I40003740 for ; Tue, 28 Aug 2001 01:04:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7S84It9003739 for ipng-dist; Tue, 28 Aug 2001 01:04:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S84C40003732 for ; Tue, 28 Aug 2001 01:04:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03181 for ; Tue, 28 Aug 2001 01:04:04 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00056 for ; Tue, 28 Aug 2001 02:03:56 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7S822l03111; Tue, 28 Aug 2001 15:02:04 +0700 (ICT) From: Robert Elz To: Alex Conta cc: Bob Hinden , Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B8A6ECE.D7703FD6@txc.com> References: <3B8A6ECE.D7703FD6@txc.com> <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Aug 2001 15:02:02 +0700 Message-ID: <3109.998985722@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 27 Aug 2001 12:01:18 -0400 From: Alex Conta Message-ID: <3B8A6ECE.D7703FD6@txc.com> | You know well, I was directly referring to QoS support for IP, i.e. | network layer protocols. I know what you were referring to, but I can't think of any good reason to limit the principle to that, if there were to be such a principle. That is, unless you're suggesting that QoS protocols are somehow of magnified status that requires them to be considered where no other protocol would be? | However, you seem to contradict yourself - you said earlier "that is | true". What I mean there is that it isn't for ipngwg to go look at diffserv, or intserv, or anything else, and then send a recommendation to the IESG (or anyone) that protocol X is no good, and should be moved to experimental, or historic, or something. Especially not when there's another WG involved. But that's vastly different than saying that ipngwg (or anyone else) is compelled to add support in its protocol for any other random protocol. If the need is apparent enough, then you won't find it hard to convince the WG of the requirement (like it didn't take much discussion for the WG to decide that it really needed to support TCP and UDP - on the other hand (v4) ICMP was discarded and a (similar) replacement invented). | To have a group of people, within a WG, decide to support with one of | the protocol functions, (flow label), only one QoS standard, and not the | other QoS standard, just shows me how the process can go wrong. I don't see that happening, even if the diffserv arguments aren't accepted. That isn't the argument that anyone is making. | There is no concession at all. Then why are you attempting to argue this bizarre "the WG must do it" line, instead of just showing on the merits that it is the right thing to do? If the merits are there, or even if you just believe they are, that's what you'd be doing, surely - it has to be much easier. When people start arguing technicalities, and even more, when they're far fetched unlikely ones, then it is usually a pretty good sign that they have no substantiative arguments that they find convincing. | To have to argue at such a length for the full support of Diffserv, to | have to argue for adding the same level of support as it is provided for | Intserv, is surrealist, is absurd. Once again, I am an outsider to this argument, just watching what is happening. But as I understand it, the "level of support provided for intserv" is more just that it happens to fit the flow model label use that the inpgwg has in mind. The use that you want to impose requires more semantics than the WG might want to load into it. Pardon my ignorance a minute, let me ask you, and Brian (and anyone else who knows), a few questions. It seems that the current flow label is defined to be an immutable field which should be set to a PRNG to identify flows (related packet streams). Right? The only reason for PRNG that I have seen identified, is to allow routers in the path to use it as a ready made hash, and so optimise their lookups. Right? Or is there some other reason? Obviously routers can't rely on that (ie: they can hope for it, and use it to their benefit where possible, but they can't assume that hosts will necessarily do the right thing). So, if a host decided to use 1 2 3 rather than PRNG values, the world wouldn't collapse, right? In response to an earlier question, Brian pointed out that there isn't really an issue of hoaxing the flow label field to get better service, as I'd be being billed for whatever service I actually get (if I ask for good service I get billed more, I assume, and get given good service, even if by any normal criteria my SMTP doesn't really need it... If I ask for cheap service, I get it, and poor service as well, even if my video conference would have preferred something better). Right? Leaving aside the question of how you know it is me who asked for this (I assume there's some way of doing this), what I do know is that there's no way that you can bill me for anything, if we don't have a prior agreement. Or rather, you can send whatever bills you like, but you're not going to get paid. So, I assume there's a relationship between the sending host (its adminstrators or owners), and the diffserv routers (or their admins, operators, or owners) Right? (Probably the same for intserv). Given that relationship, and assuming that the world can cope with any value in the flow label field, is there any reason that the host and the diffserv router(s) it is using can't simply agree with each other on the interpretation of the flow label field? That is, the diffserv routers say "put this value there, and I'll give you this kind of service". Where "this number" may be "a number computed by this algorithm using this input data", for any algorithm that the router & host can manage to agree upon. The agreement has already been presumed, we're not dealing with random associations here, right? To anyone who doesn't understand the diffserv algorithms, that number will look random - sure, it won't pass any statistical tests on randomness, but no-one is suggesting that the flow label field is required to contain that kind of value, are they? So, why do we need to reserve a bit (or Christian's group of bits) to let the arbitrary world know what the format of the field is, when it only actually matters to those who have agreed between themselves how to interpret it? Whatever way we go, there isn't space to stick in multiple different labels, to identify the packet to multiple different QoS algorithms (one for the first ISP's routers, then a different one for the next, then yet another, ...) So, we don't need something to allo each to identify what part is meant for it. Nor is there a problem of the ipngwg having specified meanings to all of those bits, which you need to be able to find a way to work around. ie: we don't need a bit saying "that other interpretation doesn't apply". They're just a random collection of bits that the sending host can set however meets its needs. It seems to me that all that's needed here is for diffserv to go away and define "For doing diffserv using IPv6, set the IPv6 flow label field as defined in section P.Q of this document". That's still meeting the needs of ipngwg as I see them, it isn't compromising anyone else's uses of the bits, if they're not doing diffserv, and you can tell the difference, as you have an agreement with the diffserv users (which you need to be able to bill them) and with that agreement you can assume they'll use the field the way that you like. If it helps you, by all means include an "on/off" bit for your algorithm in the definition that you use, so you can tell which packets (flows) are actually requesting diffserv service, and which are not. If the client doesn't abide by the agreement, and starts sending diffserv looking labels, then you just interpret them that way, and bill them that way, that's what you agreed with the client to do, after all. So, it seems to me that there's nothing at all for ipngwg to do here, other than to continue with the definition of the flow label in its current form, and not start insisting that the value satisfy any particular tests of randomness (which would be truly silly, as there's no guarantee that any particular router will ever see more than one flow label value from any particular source - and by definition, any value is equally likely if the number is randomly chosen, so anything goes). 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 Aug 28 01:57:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S8vV40003850 for ; Tue, 28 Aug 2001 01:57:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7S8vV9h003849 for ipng-dist; Tue, 28 Aug 2001 01:57:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S8vR40003842 for ; Tue, 28 Aug 2001 01:57:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26769 for ; Tue, 28 Aug 2001 01:57:36 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29983 for ; Tue, 28 Aug 2001 02:57:26 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7S91PG09941 for ; Tue, 28 Aug 2001 12:01:25 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 28 Aug 2001 11:57:24 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV8P2T>; Tue, 28 Aug 2001 11:57:07 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FEC@esebe004.NOE.Nokia.com> To: alh-ietf@tndh.net, brian@hursley.ibm.com, hinden@iprg.nokia.com Cc: aconta@txc.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Tue, 28 Aug 2001 11:53:51 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Now that I read the draft-conta-ipv6-flow-label-02.txt again in the context of this discussion, few remarks: - The draft discusses "diffserv MF-classifier" use for the flow label, while what really is proposed is a diffserv behavior aggregate (BA) classification based on standard, non-mappable PHB identifiers. Since DSCP is mappable to a local convention (for whatever political reasons), now the flow label is proposed to replace the DSCP field on the domain boundaries. - RFC 3140 defines PHB-ID as 16 bits, out of which 6 bits are used in the "standards action" defined PHBs. These 6 bits are the recommended bits for the DSCP field by the PHB definition (that can be mapped locally to different set of bits). If there is no local mapping (but the domain routers are configured to understand and use the recommended DSCP values for each supported PHB), the 6 bits in the PHB-ID are the same as the 6 bits in the DSCP in the Traffic Class field. The other variant (*experimental* and *local use*, e.g. intra-domain) use more of the 16 bits. - Since the PHB-ID carries only 6 bits of information between diffserv domains, it would seem entirely reasonable, that at diffserv domain egress, all DSCPs are mapped to the equivalent recommended DSCP values, that will then be understood by the receiving diffserv domain. The egress could base the mapping to whatever MF-classification or just map from locally used DSCPs. So, as an alternative to make the IPv6 flow label NOT identify flows, I'd propose the diffserv WG to specify that (for IPv6) a diffserv domain MUST remark the DSCP value of the Traffic Class field at egress to use the PHB-definition recommended ("standards action") DSCP value, including the case that *local use* or *experimental* PHBs are mapped to the default PHB ('000000') at domain egress. In addition to more efficient classification and policing on the domain ingress, this could have a side effect of encouraging the operators to actually use the recommended DSCP values intra-domain as well :-) The only argument against this I have seen to date is that "operators wanted" the DSCP bits to be locally mappable (and perhaps so that reverse mapping back to the standard values may be hard?). Has there been any discussion with these operators on the possibility that instead of agreeing with their peers about the DSCP values to be used *at the domain boundaries* (could still use locally mapped values intra-domain), they would base their mutual SLAs on an end-to-end field set by the IP host originating the traffic? IHO this is way different from the MF-classification discussed in the diffserv specs (since the proposal in the draft is actually about a behavior aggregate classification). Jarno Tony Hain wrote: > > Brian E Carpenter wrote: > > > The flaw in this is that one of the IETF's two QOS models is > > *not* flow > > oriented - that is the entire reason why diffserv would need > > a flow label > > with defined semantics. > > This appears to defy logic. The way I read it, we have a QoS > mechanism that by-design is not end-to-end oriented, so we MUST > define a way for the middle to interpret what the end points > are telling each other.?!? There is absolutly no reason to tie the > Flow Label field and the Traffic Class field together, which is > the only point of defining diffserv semantics for the Flow Label. > > There is no more need for a diffserv host to use a structured value > for the Flow Label than there is for an intserv host to do so. > The field is an end-to-end identification of packet relationships, > nothing more. The Traffic Class field identifies PHBs, nothing more. > They both exist in the packet from the origin, so why is it required > that there be a relationship? The set of packets identified as a > flow will be the same with either QoS mechansim, so why is there > a need to have distinct semantics unless someone in the middle wants > to interpret them? Since the middle is supposed to be per-hop and > not end-to-end, why would it care what the endpoints are saying? > > Basically, why is it suddenly required that we define end-to-end > semantics for a DSCP in the FL field, when the diffserv WG refused > to do so for the TC field? If diffserv needs end-to-end agreement > on the DSCP/PHB mappings (which I believe it does for non-technical > reasons) then the work should be done in the TC field. > > Tony > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 02:18:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S9IA40003896 for ; Tue, 28 Aug 2001 02:18:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7S9IAZH003895 for ipng-dist; Tue, 28 Aug 2001 02:18:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7S9Hp40003888 for ; Tue, 28 Aug 2001 02:17:51 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09662 for ; Tue, 28 Aug 2001 02:17:20 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12293 for ; Tue, 28 Aug 2001 02:17:15 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7S9L9G19385 for ; Tue, 28 Aug 2001 12:21:09 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 28 Aug 2001 12:17:12 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV8QV3>; Tue, 28 Aug 2001 12:16:49 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FED@esebe004.NOE.Nokia.com> To: kre@munnari.OZ.AU, aconta@txc.com Cc: hinden@iprg.nokia.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Tue, 28 Aug 2001 12:16:38 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, Very well put! Just some additional thoughts: - If diffserv WG so wants, it can even define a specific (standard) DSCP value to be used between domains to signify that the flow label in the same IP header has "diffserv semantics". This way the classification could be done the same for all source addresses (otherwise ingress router would need to know which source addresses use diffserv semantics for the flow label?). - If there is a diffserv relationship between a client and an ISP, the client could still use intserv for select flows by doing intserv signaling, which would explicitly tell the ISP that the associated flow label does not have any diffserv semantics. Jarno Robert Elz wrote: ... > Pardon my ignorance a minute, let me ask you, and Brian (and anyone > else who knows), a few questions. > > It seems that the current flow label is defined to be an > immutable field > which should be set to a PRNG to identify flows (related > packet streams). > Right? > > The only reason for PRNG that I have seen identified, is to > allow routers > in the path to use it as a ready made hash, and so optimise > their lookups. > Right? Or is there some other reason? > > Obviously routers can't rely on that (ie: they can hope for > it, and use > it to their benefit where possible, but they can't assume > that hosts will > necessarily do the right thing). So, if a host decided to use 1 2 3 > rather than PRNG values, the world wouldn't collapse, right? > > In response to an earlier question, Brian pointed out that there isn't > really an issue of hoaxing the flow label field to get better > service, as > I'd be being billed for whatever service I actually get (if I ask for > good service I get billed more, I assume, and get given good > service, even > if by any normal criteria my SMTP doesn't really need it... > If I ask for > cheap service, I get it, and poor service as well, even if my video > conference would have preferred something better). Right? > > Leaving aside the question of how you know it is me who asked for this > (I assume there's some way of doing this), what I do know is > that there's > no way that you can bill me for anything, if we don't have a prior > agreement. Or rather, you can send whatever bills you like, > but you're > not going to get paid. > > So, I assume there's a relationship between the sending host > (its adminstrators > or owners), and the diffserv routers (or their admins, > operators, or owners) > Right? (Probably the same for intserv). > > Given that relationship, and assuming that the world can cope with any > value in the flow label field, is there any reason that the > host and the > diffserv router(s) it is using can't simply agree with each > other on the > interpretation of the flow label field? That is, the > diffserv routers > say "put this value there, and I'll give you this kind of service". > Where "this number" may be "a number computed by this > algorithm using this > input data", for any algorithm that the router & host can manage to > agree upon. The agreement has already been presumed, we're > not dealing > with random associations here, right? > > To anyone who doesn't understand the diffserv algorithms, > that number will > look random - sure, it won't pass any statistical tests on > randomness, but > no-one is suggesting that the flow label field is required to > contain that > kind of value, are they? > > So, why do we need to reserve a bit (or Christian's group of > bits) to let > the arbitrary world know what the format of the field is, when it only > actually matters to those who have agreed between themselves how to > interpret it? > > Whatever way we go, there isn't space to stick in multiple > different labels, > to identify the packet to multiple different QoS algorithms > (one for the > first ISP's routers, then a different one for the next, then > yet another, ...) > So, we don't need something to allo each to identify what > part is meant > for it. > > Nor is there a problem of the ipngwg having specified > meanings to all of > those bits, which you need to be able to find a way to work around. > ie: we don't need a bit saying "that other interpretation > doesn't apply". > They're just a random collection of bits that the sending host can set > however meets its needs. > > It seems to me that all that's needed here is for diffserv to > go away and > define "For doing diffserv using IPv6, set the IPv6 flow > label field as > defined in section P.Q of this document". > > That's still meeting the needs of ipngwg as I see them, it > isn't compromising > anyone else's uses of the bits, if they're not doing > diffserv, and you can > tell the difference, as you have an agreement with the diffserv users > (which you need to be able to bill them) and with that > agreement you can > assume they'll use the field the way that you like. If it > helps you, by > all means include an "on/off" bit for your algorithm in the > definition that > you use, so you can tell which packets (flows) are actually requesting > diffserv service, and which are not. > > If the client doesn't abide by the agreement, and starts > sending diffserv > looking labels, then you just interpret them that way, and > bill them that > way, that's what you agreed with the client to do, after all. > > So, it seems to me that there's nothing at all for ipngwg to do here, > other than to continue with the definition of the flow label in its > current form, and not start insisting that the value satisfy > any particular > tests of randomness (which would be truly silly, as there's > no guarantee > that any particular router will ever see more than one flow > label value from > any particular source - and by definition, any value is > equally likely if > the number is randomly chosen, so anything goes). > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 03:21:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SALl40003978 for ; Tue, 28 Aug 2001 03:21:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SALlTL003977 for ipng-dist; Tue, 28 Aug 2001 03:21:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SALh40003970 for ; Tue, 28 Aug 2001 03:21:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22787 for ; Tue, 28 Aug 2001 03:21:51 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA09142 for ; Tue, 28 Aug 2001 04:21:46 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA08331; Tue, 28 Aug 2001 12:21:48 +0200 (MET DST) Date: Tue, 28 Aug 2001 12:21:48 +0200 From: Ignatios Souvatzis To: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "An analysis of IPv6 anycast" Message-ID: <20010828122148.D7865@theory.cs.uni-bonn.de> References: <20010827124137.E8FCA7BC@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Qf1oXS95uex85X0R" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010827124137.E8FCA7BC@starfruit.itojun.org>; from itojun@iijlab.net on Mon, Aug 27, 2001 at 09:41:37PM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Qf1oXS95uex85X0R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2001 at 09:41:37PM +0900, Jun-ichiro itojun Hagino wrote: > >> There are two kind of "anycast" proposed and operated for IPv4 - One is > >> RFC1546 [Partridge, 1993] anycast. Another is what we call "BGP anyca= st" > >> in this document; this is for replicating unicast servers by BGP trick. > >> We concentrate into the former in this document. > >as it is used for dns etc. *within* a single provider, it can be an igp > >which is used, not bgp. >=20 > i see, but are there such practice exist? how do they cope > with server failures and IGP flaps? Same problem as for BGP anycast, I guess. Regards, -is --Qf1oXS95uex85X0R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO4twuDCn4om+4LhpAQGBaAf/VtviNUt8/Lm0368RRA2++rVXNT1nRxUe sBFw6cTrI0ftXG4xU1UuOYlQG4UrFKIfZ+CGCfZmXqt977OViAKdI2uTWItE6lLt ZynkdlmH9KcuVL20XSVqBFwnW4qubBW9sU9pcYTbP2YQaw+Cx7nJY5NzFpPpsgVF v6TKUMnTE5E3gJSAvCD8TUWzXGu093zz+KgsJ3GQTvHf9fF0OoOWk0Gk3ZAuXiaB WCvXfq0kNQlt9C1QMFnzQA/YedaueBC8h0If8a0Ck/oqEmLo8d5nOatNrnTf6CjT dC0ocx2fXUKc8/+bJqjzlIdBdMWMCoVs9jX8fwi+9Ztww8xOnYHWNw== =tJLi -----END PGP SIGNATURE----- --Qf1oXS95uex85X0R-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 05:52:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SCqr40004070 for ; Tue, 28 Aug 2001 05:52:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SCqrd8004069 for ipng-dist; Tue, 28 Aug 2001 05:52:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SCqn40004062 for ; Tue, 28 Aug 2001 05:52:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24490 for ; Tue, 28 Aug 2001 05:52:57 -0700 (PDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03860 for ; Tue, 28 Aug 2001 05:52:56 -0700 (PDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f7SCoqn01616; Tue, 28 Aug 2001 08:50:52 -0400 Message-Id: <200108281250.f7SCoqn01616@hygro.adsl.duke.edu> To: Randy Bush cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "An analysis of IPv6 anycast" In-Reply-To: Message from Randy Bush of "Tue, 28 Aug 2001 08:05:14 +0800." Date: Tue, 28 Aug 2001 08:50:52 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > much talk and fud about this. in practice, this does not seem to be > a problem. It is clear that there is a *potential* for trouble. If one controls the environment sufficiently, uses protocols that are relatively robust to network failures, one can make it work. Even work quite well it would seem. That is fine and we should acknowledge this. But it is also not helpful to just assert "it works in practice" without acknowledging that there are real dangers when used inappropriately. i.e., the "it" needs to be qualified, as not all "its" will work equally well. > e.g. some years back, we did a two hour streaming videocast to over > 100k users, 200mb of traffic, from a dozen anycast servers. not one > noc call. If the metric of "it works" is defined by "how many calls to the NOC", we're in pretty bad shape. My experience in calling various NOCs is that it is a waste of time. Only bother when things are totally broken and they haven't fixed themselves after a prolonged period of time. I.e., call the NOC only after exhausting all other alternatives. YMMV. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 06:39:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SDdI40004107 for ; Tue, 28 Aug 2001 06:39:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SDdI6D004106 for ipng-dist; Tue, 28 Aug 2001 06:39:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SDdE40004099 for ; Tue, 28 Aug 2001 06:39:14 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00948 for ; Tue, 28 Aug 2001 06:39:23 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22214 for ; Tue, 28 Aug 2001 06:39:21 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA28430; Tue, 28 Aug 2001 14:39:18 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA58776; Tue, 28 Aug 2001 14:39:18 +0100 Message-ID: <3B8B9F35.E4327BB4@hursley.ibm.com> Date: Tue, 28 Aug 2001 08:40:05 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Bob Hinden , Alex Conta , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Tony Hain wrote: > > Brian E Carpenter wrote: > > > The flaw in this is that one of the IETF's two QOS models is > > *not* flow > > oriented - that is the entire reason why diffserv would need > > a flow label > > with defined semantics. > > This appears to defy logic. The way I read it, we have a QoS > mechanism that by-design is not end-to-end oriented, so we MUST > define a way for the middle to interpret what the end points > are telling each other.?!? The endpoints in diffserv don't tell each other anything; diffserv is an entirely hop-by-hop model. Each hop may choose to look at the entire packet header in order to reclassify it. > There is absolutly no reason to tie the > Flow Label field and the Traffic Class field together, which is > the only point of defining diffserv semantics for the Flow Label. No, the point is to provide partial replacement of the {port, protocol} semantics that are hidden by ESP. There is no tying together of Traffic Class and Flow Label. They remain orthogonal. > > There is no more need for a diffserv host to use a structured value > for the Flow Label than there is for an intserv host to do so. Wrong (see previous point). > The field is an end-to-end identification of packet relationships, > nothing more. That was the old (non-normative) definition. We are proposing to change it. > The Traffic Class field identifies PHBs, nothing more. It contains a code point value that identifies PHBs *within a given administrative domain*. It is not an e2e value. > They both exist in the packet from the origin, so why is it required > that there be a relationship? There is no relationship. The DSCP is a per-domain value and the proposed PHB ID version of the flow label is an e2e value. Whether or not they coincide depends on local diffserv configuration in each domain the packet passes through. > The set of packets identified as a > flow will be the same with either QoS mechansim, so why is there > a need to have distinct semantics unless someone in the middle wants > to interpret them? Diffserv is blind to microflows; there is no flow identification. However, diffserv classifiers in the middle *do* need to (re)interpret packet headers. That is how diffserv works. > Since the middle is supposed to be per-hop and > not end-to-end, why would it care what the endpoints are saying? Because reclassification may occur per-domain. That is how diffserv works. > > Basically, why is it suddenly required that we define end-to-end > semantics for a DSCP in the FL field, It is *NOT* a DSCP. Please read RFC 3140. There is fundamental difference between DSCP values (locally mappable) and PHB IDs (globally unique). > when the diffserv WG refused > to do so for the TC field? We did what the ISPs wanted: locally mappable semantics. > If diffserv needs end-to-end agreement > on the DSCP/PHB mappings It doesn't; again see RFC 3140 and reread the diffserv architecture. > (which I believe it does for non-technical > reasons) then the work should be done in the TC field. That is precisely what the ISPs told us not to do, from the beginning of diffserv. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 06:46:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SDk240004124 for ; Tue, 28 Aug 2001 06:46:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SDk140004123 for ipng-dist; Tue, 28 Aug 2001 06:46:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SDjw40004116 for ; Tue, 28 Aug 2001 06:45:58 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01562 for ; Tue, 28 Aug 2001 06:46:07 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21534 for ; Tue, 28 Aug 2001 06:46:06 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA08170; Tue, 28 Aug 2001 14:46:03 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA27352; Tue, 28 Aug 2001 14:46:02 +0100 Message-ID: <3B8BA0C5.FDADB303@hursley.ibm.com> Date: Tue, 28 Aug 2001 08:46:45 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Christian Huitema CC: Bob Hinden , Alex Conta , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, In fact the diffserv requirement is for a 16 bit field, so we could adopt: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0| Diffserv IPv6 Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or something similar, to conserve bits. Brian Christian Huitema wrote: > > > > 0 1 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0| Pseudo-Random Value | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > 0 1 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1| Diffserv IPv6 Flow Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Could we be a bit parcimonious and reserve a couple of header bits "for > further use"? We don't seem to have a level of consensus in the group > that people can guarantee that either a bunch of random bits, or a > diffserv flow label, are absolutely the best thing since sliced bread. > Not at the same level as the payload type or payload length, in any > case. It would be nice to be able to invent something like ECN in > 2010... > > Maybe we could make it something like 4 bits of "label type" and 16 bits > of label value, defining then the possibilities for "0-0", "0-random" > and "1-diffserv" -- whatever that means. > > -- Christian Huitema -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 06:47:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SDlK40004143 for ; Tue, 28 Aug 2001 06:47:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SDlKr3004142 for ipng-dist; Tue, 28 Aug 2001 06:47:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SDlG40004135 for ; Tue, 28 Aug 2001 06:47:16 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08972 for ; Tue, 28 Aug 2001 06:47:25 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22223 for ; Tue, 28 Aug 2001 06:47:23 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA08178; Tue, 28 Aug 2001 14:47:20 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA21352; Tue, 28 Aug 2001 14:47:19 +0100 Message-ID: <3B8BA111.BA48C1C6@hursley.ibm.com> Date: Tue, 28 Aug 2001 08:48:01 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Rami Lehtonen CC: ipng Subject: Re: a), b), c), d), or e) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rami, Such a hash, being irreversible, would be of no use for diffserv classification. Brian Rami Lehtonen wrote: > > > p.s. For what it is worth, my current thinking is that I would prefer not > > use the flow label field for any specific QOS approach(s). I am open to > > something that makes it easier to identify flows. This could be used for > > QOS or other flow related applications. > > I'm not followed the whole chain of the flow label discussion, but I was > curious enough to ask what are the reasons why we doesn't use the flow label > just for identification of different flows. We could calculate e.g. a hash > value from the IP addresses, port numbers and protocol number at the client > side and then put that value in the flow label field. That value could be > efficiently used by the network or the receiver to different flow > identification purposes even with ESP headers. > > - Rami Lehtonen > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 07:28:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SESA40004246 for ; Tue, 28 Aug 2001 07:28:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SES986004245 for ipng-dist; Tue, 28 Aug 2001 07:28:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SES540004238 for ; Tue, 28 Aug 2001 07:28:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04906 for ; Tue, 28 Aug 2001 07:28:13 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10472 for ; Tue, 28 Aug 2001 08:28:37 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA34612; Tue, 28 Aug 2001 15:28:08 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA46780; Tue, 28 Aug 2001 15:28:08 +0100 Message-ID: <3B8BAA88.2D610245@hursley.ibm.com> Date: Tue, 28 Aug 2001 09:28:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Elz CC: Alex Conta , Bob Hinden , ipng Subject: Re: a), b), c), d), or e) References: <3B8A6ECE.D7703FD6@txc.com> <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> <3109.998985722@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: ... > That is, unless you're suggesting that QoS protocols are somehow of > magnified status that requires them to be considered where no other > protocol would be? The only concrete proposals I have ever seen for use of the Flow Label are for QOS. Everything else has been hand-waving. We need to decide. It's unthinkable to leave this big mystery gap in the middle of the IPv6 header. ... > It seems that the current flow label is defined to be an immutable field > which should be set to a PRNG to identify flows (related packet streams). > Right? But it is not defined in normative text, and the text we have is vague on the actual usage - even worse than the text on the TOS byte in RFC 791, for example. ... > Given that relationship, and assuming that the world can cope with any > value in the flow label field, is there any reason that the host and the > diffserv router(s) it is using can't simply agree with each other on the > interpretation of the flow label field? That is, the diffserv routers > say "put this value there, and I'll give you this kind of service". > Where "this number" may be "a number computed by this algorithm using this > input data", for any algorithm that the router & host can manage to > agree upon. The agreement has already been presumed, we're not dealing > with random associations here, right? Diffserv routers have no relationship with sending hosts; they are configured within an admin domain (ISP or whatever) according to local policy. There is no way to agree on anything except global semantics, and for that to work we need a diffserv-specific format for the flow label. There simply isn't any other way. > > To anyone who doesn't understand the diffserv algorithms, that number will > look random - sure, it won't pass any statistical tests on randomness, but > no-one is suggesting that the flow label field is required to contain that > kind of value, are they? True, but remember the value is *not* going to be unique-per-host - it doesn't identify a microflow. > > So, why do we need to reserve a bit (or Christian's group of bits) to let > the arbitrary world know what the format of the field is, when it only > actually matters to those who have agreed between themselves how to > interpret it? There is no mutual agreement; diffserv is stateless and has no signalling. If this isn't reserved in the IPv6 header, a router somewhere downstream on the data path has to *guess* that the value is a valid diffserv flow label, rather than an arbitrary value that just happens to have a diffservish value. That is hardly good engineering. > > Whatever way we go, there isn't space to stick in multiple different labels, > to identify the packet to multiple different QoS algorithms (one for the > first ISP's routers, then a different one for the next, then yet another, ...) > So, we don't need something to allo each to identify what part is meant > for it. This isn't an issue. PHB IDs are globally defined. > > Nor is there a problem of the ipngwg having specified meanings to all of > those bits, which you need to be able to find a way to work around. > ie: we don't need a bit saying "that other interpretation doesn't apply". > They're just a random collection of bits that the sending host can set > however meets its needs. I think I just showed why this is false. The downstream routers must be able to interpret the bits statelessly, and that means it has to be an encoded field. > > It seems to me that all that's needed here is for diffserv to go away and > define "For doing diffserv using IPv6, set the IPv6 flow label field as > defined in section P.Q of this document". There is no way we can risk using the flow label for diffserv as it is defined today, since from a normative point of view it isn't defined at all, and downstream routers have to guess. > > That's still meeting the needs of ipngwg as I see them, it isn't compromising > anyone else's uses of the bits, if they're not doing diffserv, and you can > tell the difference, as you have an agreement with the diffserv users > (which you need to be able to bill them) No, no, no. You have *no* such agreement with the users. You may (or may not, in theory) have an SLA with your peer ISPs. But the mechanisms are stateless at each point. You don't know whether a particular traffic source has set a PRNG value or a diffserv value unless it tells you in each packet. > and with that agreement you can > assume they'll use the field the way that you like. If it helps you, by > all means include an "on/off" bit for your algorithm in the definition that > you use, so you can tell which packets (flows) are actually requesting > diffserv service, and which are not. That's exactly the point - that bit has to be defined for *every* IPv6 packet. Otherwise it's guesswork. > > If the client doesn't abide by the agreement, and starts sending diffserv > looking labels, then you just interpret them that way, and bill them that > way, that's what you agreed with the client to do, after all. Sure, you will always bill in the way the upstream SLA tells you to. If the source lies, too bad for the bill-payer. > > So, it seems to me that there's nothing at all for ipngwg to do here, > other than to continue with the definition of the flow label in its > current form, If that is the conclusion, diffserv cannot use it and IPv6 will have no advantage over IPv4 for diffserv. > and not start insisting that the value satisfy any particular > tests of randomness (which would be truly silly, as there's no guarantee > that any particular router will ever see more than one flow label value from > any particular source - and by definition, any value is equally likely if > the number is randomly chosen, so anything goes). I agree. In the non-diffserv usage, unique-per-source is necessary and sufficient (with PRNG being a possible optimisation for some router technologies). 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 Aug 28 07:37:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SEbe40004268 for ; Tue, 28 Aug 2001 07:37:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SEbeC3004267 for ipng-dist; Tue, 28 Aug 2001 07:37:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SEba40004260 for ; Tue, 28 Aug 2001 07:37:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17936 for ; Tue, 28 Aug 2001 07:37:44 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15561 for ; Tue, 28 Aug 2001 08:38:08 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA35344; Tue, 28 Aug 2001 15:37:39 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA52990; Tue, 28 Aug 2001 15:37:38 +0100 Message-ID: <3B8BACBB.EE32E7B6@hursley.ibm.com> Date: Tue, 28 Aug 2001 09:37:47 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: alh-ietf@tndh.net, hinden@iprg.nokia.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) References: <009CA59D1752DD448E07F8EB2F911757197FEC@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: > > Now that I read the draft-conta-ipv6-flow-label-02.txt again in the context > of this discussion, few remarks: > > - The draft discusses "diffserv MF-classifier" use for the flow label, while > what really is proposed is a diffserv behavior aggregate (BA) classification > based on standard, non-mappable PHB identifiers. Since DSCP is mappable to a > local convention (for whatever political reasons), now the flow label is > proposed to replace the DSCP field on the domain boundaries. Exactly, since it can convey e2e semantics from the source. > > - RFC 3140 defines PHB-ID as 16 bits, out of which 6 bits are used in the > "standards action" defined PHBs. These 6 bits are the recommended bits for > the DSCP field by the PHB definition (that can be mapped locally to > different set of bits). If there is no local mapping (but the domain routers > are configured to understand and use the recommended DSCP values for each > supported PHB), the 6 bits in the PHB-ID are the same as the 6 bits in the > DSCP in the Traffic Class field. The other variant (*experimental* and > *local use*, e.g. intra-domain) use more of the 16 bits. Correct. The idea was that people could register PHB IDs with IANA to go beyond the formally standardised ones. > > - Since the PHB-ID carries only 6 bits of information between diffserv No, the DSCP is limited to 6 bits; the PHB-ID has a full 16 bits. The mapping to DSCP is a decision made by the classifier in an ingress border router. > domains, it would seem entirely reasonable, that at diffserv domain egress, > all DSCPs are mapped to the equivalent recommended DSCP values, that will > then be understood by the receiving diffserv domain. It might be reasonable, but we can't assume it. This depends entirely on the SLA between the two ISPs concerned and is a business decision. > The egress could base > the mapping to whatever MF-classification or just map from locally used > DSCPs. > > So, as an alternative to make the IPv6 flow label NOT identify flows, I'd > propose the diffserv WG to specify that (for IPv6) a diffserv domain MUST > remark the DSCP value of the Traffic Class field at egress to use the > PHB-definition recommended ("standards action") DSCP value, including the > case that *local use* or *experimental* PHBs are mapped to the default PHB > ('000000') at domain egress. Impossible. This is not something the IETF can mandate, and in particular ISPs are free to implement non-standard PHBs (e.g. multiple independent implementations of EF, or more than four AF classes, or some proprietary PHB). > > In addition to more efficient classification and policing on the domain > ingress, this could have a side effect of encouraging the operators to > actually use the recommended DSCP values intra-domain as well :-) This is not in our power. > > The only argument against this I have seen to date is that "operators > wanted" the DSCP bits to be locally mappable (and perhaps so that reverse > mapping back to the standard values may be hard?). Has there been any > discussion with these operators on the possibility that instead of agreeing > with their peers about the DSCP values to be used *at the domain boundaries* > (could still use locally mapped values intra-domain), they would base their > mutual SLAs on an end-to-end field set by the IP host originating the > traffic? IHO this is way different from the MF-classification discussed in > the diffserv specs (since the proposal in the draft is actually about a > behavior aggregate classification). This is not a discussion one can have with ISPs. What they do in their bilateral agreements is a private, confidential matter. 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 Aug 28 07:44:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SEiT40004291 for ; Tue, 28 Aug 2001 07:44:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SEiT8O004290 for ipng-dist; Tue, 28 Aug 2001 07:44:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SEiP40004283 for ; Tue, 28 Aug 2001 07:44:25 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09972 for ; Tue, 28 Aug 2001 07:44:33 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21437 for ; Tue, 28 Aug 2001 07:44:30 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA23146; Tue, 28 Aug 2001 15:44:22 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA25980; Tue, 28 Aug 2001 15:44:22 +0100 Message-ID: <3B8BAE45.370DE6A@hursley.ibm.com> Date: Tue, 28 Aug 2001 09:44:21 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: kre@munnari.OZ.AU, aconta@txc.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) References: <009CA59D1752DD448E07F8EB2F911757197FED@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: > > Robert, > > Very well put! Just some additional thoughts: > > - If diffserv WG so wants, it can even define a specific (standard) DSCP > value to be used between domains to signify that the flow label in the same > IP header has "diffserv semantics". This way the classification could be > done the same for all source addresses (otherwise ingress router would need > to know which source addresses use diffserv semantics for the flow label?). That's an interesting thought, but I think it doesn't work. The egress router has to *know* that the flow label is in diffserv format, and I think that requires some magic. > > - If there is a diffserv relationship between a client and an ISP, the > client could still use intserv for select flows by doing intserv signaling, > which would explicitly tell the ISP that the associated flow label does not > have any diffserv semantics. Only for unencrypted traffic I think? The problem case is encrypted traffic, where all you can "see" are the IP addresses and the flow label. I think the intserv flow spec will be insufficient in that case. 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 Aug 28 07:49:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SEnW40004313 for ; Tue, 28 Aug 2001 07:49:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SEnWNj004312 for ipng-dist; Tue, 28 Aug 2001 07:49:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SEnS40004305 for ; Tue, 28 Aug 2001 07:49:28 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01020 for ; Tue, 28 Aug 2001 07:49:36 -0700 (PDT) Received: from indica.wipsys.stph.net ([203.197.249.146]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24058 for ; Tue, 28 Aug 2001 07:49:33 -0700 (PDT) Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.11.4/8.11.4) with SMTP id f7SEnKR16089 for ; Tue, 28 Aug 2001 20:19:20 +0530 (IST) Received: from lbmail.mail.wipro.com ([196.12.37.250]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GIS96G00.EQG for ; Tue, 28 Aug 2001 20:19:28 +0530 Received: from 6c3 ([196.12.37.230]) by lbmail.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GIS96G00.40Z for ; Tue, 28 Aug 2001 20:19:28 +0530 Message-ID: <009c01c12fd0$42d5dea0$e6250cc4@wipsys.stph.net> Reply-To: "srinivas nalluri" From: "Srinivasa Rao Nalluri" To: "IPng" Subject: a doubt on MTU discovery in IPv6 Date: Tue, 28 Aug 2001 20:16:46 +0530 Organization: Wipro Technologies MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C12FFE.5C5BC000" ------=_NextPart_000_0099_01C12FFE.5C5BC000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi in IPv6 networks different IP packets from same source to same = distention may travel through different paths. then how path MTU discovery process can help to find MTU value? we don't know through how many different paths packets may travel = between same source and distention. can anybody explain how this will happen in IPv6 networks. regards Srinivas Nalluri=20 ------=_NextPart_000_0099_01C12FFE.5C5BC000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi
 
in IPv6 networks different IP packets = from same=20 source to same distention may travel through different = paths.
then how path MTU discovery process can = help to=20 find MTU value?
we don't know through how many = different paths=20 packets may travel between same source and distention.
 
can anybody explain how this will = happen in IPv6=20 networks.
 
regards
Srinivas Nalluri 
 
------=_NextPart_000_0099_01C12FFE.5C5BC000-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" The Information contained and transmitted by this E-MAIL is proprietary to Wipro Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at mailadmin@wipro.com --------------InterScan_NT_MIME_Boundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 08:03:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SF3Z40004359 for ; Tue, 28 Aug 2001 08:03:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SF3ZhM004358 for ipng-dist; Tue, 28 Aug 2001 08:03:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SF3V40004351 for ; Tue, 28 Aug 2001 08:03:31 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03074 for ; Tue, 28 Aug 2001 08:03:39 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01250 for ; Tue, 28 Aug 2001 08:03:38 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA10448 for ; Tue, 28 Aug 2001 16:03:36 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA22786 for ; Tue, 28 Aug 2001 16:03:36 +0100 Message-ID: <3B8BB2B6.1B35C0C5@hursley.ibm.com> Date: Tue, 28 Aug 2001 10:03:18 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng Subject: Another idea for the flow label References: <3B8BA0C5.FDADB303@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How would people feel about this encoding for the flow label (deemed to be immutable end to end)? 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Per-microflow unique value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Non-unique value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'm not yet 100% convinced that the second case is sufficient for diffserv, but at least it would be a more generic approach than reserving half the space for diffserv. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 08:17:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SFGx40004420 for ; Tue, 28 Aug 2001 08:16:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SFGx1E004419 for ipng-dist; Tue, 28 Aug 2001 08:16:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SFGe40004412 for ; Tue, 28 Aug 2001 08:16:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12189 for ; Tue, 28 Aug 2001 08:16:08 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07004 for ; Tue, 28 Aug 2001 09:16:34 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id LAA13760; Tue, 28 Aug 2001 11:17:08 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA18046; Tue, 28 Aug 2001 11:17:08 -0400 Message-ID: <3B8BB5F2.6A695FF4@txc.com> Date: Tue, 28 Aug 2001 11:17:06 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC71F6E953F8F2FCE58E7ADAB" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msC71F6E953F8F2FCE58E7ADAB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony, I answer, since you addressed this to me. Tony Hain wrote: > > Alex Conta wrote: > > [...] > While the original purpose of the proposal for the flow label may have > been QoS, there is nothing restricting it to that usage. > I do not think that the Carpenter/Conta draft tries to exclude anything. It tries to include Diffserv along Intserv. It is some of the Intserv supporters that try to keep Diffserv out (excluded). > > an end-to-end immutable field Requesting "immutability" makes sense only when a group of routers on the path, in a routing domain for instance, are not capable of preserving the meaning from ingress to egress of that domain, when and if that meaning is significant further downstream. If the routers are capable of preserving the meaning, or there is no significance downstream, then "mutability" is a non-issue. So, "immutable" has to be at the most conditional, and therefore not part of the main definition. > which may provide a hint to the routers > that the sequence of packets with this marking are related > > How the routers treat that hint is a local administration issue, and > outside the scope of any specific QoS model. If treating the hint is outside the scope of the QoS model, how do we know how to treat the flow label bits for QoS? That, to me, excludes QoS, and so it cannot be accepted. > The routers in the same > administrative domain of the originating host may treat those as > intserv bits, If the bits may be treated as intserv bits, the flow label must be in the scope of the Intserv model. This contradicts your previous statement. Access routers could police/shape the traffic using Diffserv. > while an intermediate ISP may ignore them, and at the > same time the destination administrative domain may have enough > information to treat them as modifiers to a diffserv infrastructure. Are you saying that the flow label bits can be used by Diffserv? That's fine, however, there is still a contradiction, in my view, with your previous "scope" statement. > The point is they are simply a hint from the originator that packets > between the src/dst pair are related as far as it is concerned. This is an oversimplification, and vagueness, with no practical benefit. At this stage, I do not think, we can afford that. > The > only one that may care is the destination host, So, you provide in the flow label an additional hint to the destination beside the pair of ports that are in the host-to-host header? and that hint is using 20 bits of the main network layer header? Oh NO, I do not think we can afford that for that purpose. The IPv6 main header is very expensive real estate. Processing at wire speed in the forwarding and QoS infrastructure is too, too critical, that's where the flow label must be used. And then why to duplicate information that the destination host has full access to anyway (ports, destination options, etc...)? > [...] Sorry, without clarification, I could not make sense out of the rest of what you wrote, so I discarded. > Tony Alex --------------msC71F6E953F8F2FCE58E7ADAB Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjgxNTE3MDZaMCMGCSqGSIb3DQEJBDEWBBTzU80qqU6ZSPoiJqO0 K39AwtcP0zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gLuLQ/zMDqjcpk5ANfPrBrp+DzEbNVMppQYUdoXAZk1JEUjboNYa6VddJlaWAZ2ugSBnTi6T JdaRt8h5mG3H8JnZmWg3k0j1QYZHhtYFpJOEk7u+8hAiDJqMJsK+LlASbkGIrmoZeL8a6BiJ M3/ie8GkDN6aJmDhECoHeCurOh0A --------------msC71F6E953F8F2FCE58E7ADAB-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 08:59:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SFxe40004584 for ; Tue, 28 Aug 2001 08:59:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SFxe4P004583 for ipng-dist; Tue, 28 Aug 2001 08:59:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SFxa40004576 for ; Tue, 28 Aug 2001 08:59:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12399 for ; Tue, 28 Aug 2001 08:59:45 -0700 (PDT) Received: from host.ott.igs.net (host.ott.igs.net [216.58.1.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29849 for ; Tue, 28 Aug 2001 08:59:22 -0700 (PDT) Received: from [216.58.50.251] (i216-58-50-251.igs.net [216.58.50.251]) by host.ott.igs.net (8.11.4/8.11.4) with ESMTP id f7SFw6q50920; Tue, 28 Aug 2001 11:58:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kgk@host.igs.net Message-Id: In-Reply-To: References: Date: Tue, 28 Aug 2001 12:04:55 -0400 To: "Christian Huitema" , "Brian E Carpenter" , "Bob Hinden" From: Keith Knightson Subject: RE: a), b), c), d), or e) Cc: "Alex Conta" , "ipng" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Guys, Why is it not possible to use the field for different purposes if the purpose can be suitably identified by some included mechanism Christian has suggested. Some values being for "standardized" usages and a few reserved? That way everyone could get what they want. Or is this a stupid suggestion? Keith Knightson At 3:43 PM -0700 8/27/01, Christian Huitema wrote: > >Could we be a bit parcimonious and reserve a couple of header bits "for >further use"? We don't seem to have a level of consensus in the group >that people can guarantee that either a bunch of random bits, or a >diffserv flow label, are absolutely the best thing since sliced bread. >Not at the same level as the payload type or payload length, in any >case. It would be nice to be able to invent something like ECN in >2010... > >Maybe we could make it something like 4 bits of "label type" and 16 bits >of label value, defining then the possibilities for "0-0", "0-random" >and "1-diffserv" -- whatever that means. > >-- Christian Huitema >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 09:14:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGEB40004626 for ; Tue, 28 Aug 2001 09:14:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SGEBUJ004625 for ipng-dist; Tue, 28 Aug 2001 09:14:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGE740004618 for ; Tue, 28 Aug 2001 09:14:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04721 for ; Tue, 28 Aug 2001 09:14:15 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06448 for ; Tue, 28 Aug 2001 10:14:10 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id MAA14945; Tue, 28 Aug 2001 12:15:16 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id MAA21361; Tue, 28 Aug 2001 12:15:15 -0400 Message-ID: <3B8BC390.8AAF6B53@txc.com> Date: Tue, 28 Aug 2001 12:15:12 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Hinden CC: ipng Subject: Re: a), b), c), d), or e) References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <4.3.2.7.2.20010827111610.0225c1b8@mailhost.iprg.nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA088A1B2E523BDD07E8C8971" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msA088A1B2E523BDD07E8C8971 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, Bob Hinden wrote: > > Alex, > > I am responding because you sent the email to me directly. > It was in response to Brian, and you - your addition to Brian's list of options. But it is good to hear your opinion, and now I know how to get it (-: > >IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's > >IPv6. > > [...] > >The IPv6 WG is not a preferential club, or an exclusivist group. The > > The chairs try to keep the working group process open and fair. To keep the process open and fair may be challenging. It is nice that the chairs try. > > >IPv6 WG is not to tell the IETF what standard is good and what standard > >is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works > >with, and it supports the other IETF standards. > > I don't think your statements are correct. There is not a formal IETF > requirement that the working groups output support all other IETF standards. > I didn't say "all". I was referring directly to the QoS standards, which are part of the IP layer's set of standards (IPsec is another). It applies to others as well, non-IP, like transports, etc... I think I qualified that already in an earlier message to Kre. > "c)" is one of the choices being discussed on the mailing list. From my > read of the list, I don't see a consensus on any of the choices. Brian was generous. He didn't put "f) Diffserv only" in his list. Maybe some people that are not convinced about Intserv/RSVP would have voted for that. It would have been interesting for a consensus building process. c) is a nice consensus building block, it can be seen as a superset of b) It does not exclude Intserv, it only adds Diffserv. It is a WIN-WIN (hint, hint). > [...] Perhaps you only meant to include MPLS, Diff > Serv, and Int Serv standards in your assertion. > > In this case, I don't think that the w.g. has to do this (i.e., MUST). > [...] > However, it will have to a reason more compelling than > other IETF working groups have standardized something. If this is indeed the process, then it gives an unfair power to IPv6 WG to undersupport (could read undermine) standards created by other WGs (Diffserv), which are IP standards, and which inter-depend with IPv6. This is in my view a broken process. . The appropriate and fair process would be, in my view, for the IPv6 WG to standardize functions that other IP standards depend on, unless there is a consensus on a compelling reason, that it should not do so. > p.s. For what it is worth, my current thinking is that I would prefer not > use the flow label field for any specific QOS approach(s). I do not think we can afford not to support specific QoS models. In fact, it is stringent to add the Diffserv support -- there are many vendors building IPv4 forwarding and QoS engines in silicon. Many do IPv6 as well, and it is a struggle to make that cost/performance comparable with IPv4. > I am open to > something that makes it easier to identify flows. This is already done. > This could be used for > QOS or other flow related applications. I wish you were more specific. Flow related applications other than QoS in the network layer, to me, to many, do not mean much, besides forwarding. And that is already done by MPLS. Based on your response, I would not expect your encouraging of functions that would be friendly to MPLS, so I am a bit puzzled. Alex --------------msA088A1B2E523BDD07E8C8971 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjgxNjE1MTNaMCMGCSqGSIb3DQEJBDEWBBRfb1AF1UnEEzW2fzUZ HVxGQGNWrzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gFhBAYM0P7etG30rhtqsTi1+E0+Zhd/3m5TvWo2rFIs8x8oTxl/5xoO3gPXzCfoQnlnecskN vt/rua5KLfKxzBjZUduFHkExQJIM5dLKQs2tvJdyPoQLcpvdqTkXCAJfB6Na+I0p6RzzLPXB S3DQO7Ba3Eyq/AQ3+kMPIvKakZA8 --------------msA088A1B2E523BDD07E8C8971-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 09:14:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGE340004616 for ; Tue, 28 Aug 2001 09:14:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SGE3QY004615 for ipng-dist; Tue, 28 Aug 2001 09:14:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGDw40004605 for ; Tue, 28 Aug 2001 09:13:58 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03023 for ; Tue, 28 Aug 2001 09:14:07 -0700 (PDT) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09991 for ; Tue, 28 Aug 2001 09:14:00 -0700 (PDT) Received: from jariws1 ([62.248.154.197]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20010828161354.WDP1085.fep06-app.kolumbus.fi@jariws1>; Tue, 28 Aug 2001 19:13:54 +0300 Message-ID: <008701c12fdc$78b01200$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "srinivas nalluri" , "IPng" References: <009c01c12fd0$42d5dea0$e6250cc4@wipsys.stph.net> Subject: Re: a doubt on MTU discovery in IPv6 Date: Tue, 28 Aug 2001 19:14:10 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >in IPv6 networks different IP packets from same source to same >distention may travel through different paths >then how path MTU discovery process can help to find MTU value? I suppose you would eventually get the ICMPv6 Packet Too Bigs from all the possible paths, and would set the path MTU to the minimum of the received values. Jari Arkko -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 09:24:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGO140004655 for ; Tue, 28 Aug 2001 09:24:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SGO0qZ004654 for ipng-dist; Tue, 28 Aug 2001 09:24:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGNv40004647 for ; Tue, 28 Aug 2001 09:23:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17504 for ; Tue, 28 Aug 2001 09:24:05 -0700 (PDT) Received: from hygro.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 KAA16717 for ; Tue, 28 Aug 2001 10:24:29 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f7SGMAO01786; Tue, 28 Aug 2001 12:22:10 -0400 Message-Id: <200108281622.f7SGMAO01786@hygro.adsl.duke.edu> To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) In-Reply-To: Message from Brian E Carpenter of "Tue, 28 Aug 2001 09:37:47 CDT." <3B8BACBB.EE32E7B6@hursley.ibm.com> Date: Tue, 28 Aug 2001 12:22:10 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Correct. The idea was that people could register PHB IDs with IANA to > go beyond the formally standardised ones. Has anyone done so, or are you aware of any plans at the present time to do this? (The IANA page doesn't seem to have any listed.) I'm trying to understand if this is something that people feel is useful today, or whether defining the Flow Label is intended to provide additional encouragement for folks to do so. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 09:29:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGT740004672 for ; Tue, 28 Aug 2001 09:29:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SGT7Jb004671 for ipng-dist; Tue, 28 Aug 2001 09:29:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGT340004664 for ; Tue, 28 Aug 2001 09:29:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08145 for ; Tue, 28 Aug 2001 09:29:12 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19726 for ; Tue, 28 Aug 2001 10:29:35 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA26206; Tue, 28 Aug 2001 17:29:08 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA25914; Tue, 28 Aug 2001 17:29:05 +0100 Message-ID: <3B8BC611.D258CDA9@hursley.ibm.com> Date: Tue, 28 Aug 2001 11:25:53 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: "Kastenholz, Frank" CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <5.0.2.1.2.20010824131420.0266cce0@uniwest1> <5.0.2.1.2.20010828100429.027ac010@uniwest1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Understood. This is all fine as long as the ASIC or network processor can use a common solution for per-flow and per-traffic-class classification - in that case it doesn't care what the bits in the flow label are (although the software that configures the tables that drive the classifier might care). Brian "Kastenholz, Frank" wrote: > > Brian > > You're missing my point. > > Yes, there are some silicon forwarders that can be > easily adapted to changes in the header fields -- > assuming that those changes are within the range of > flexibility that was already placed in the silicon. > ASICs are less flexibile than FPGAs which are less > flexible than NP's. But all that is more or less > irrelevant. > > The issue is the "format" of the flowid. I'd code things > up to classify on the full 20 bits of the flowid and > be done with it. That way, I will not have to go back > into the forwarder design, _regardless_ of the > environment. Any time we have to change code, it's > a bad thing -- bugs can creep in, unintended behaviors > can result, performance can suffer. Even if the silicon > is flexible, it has some "programming" and that programming > would have to change if I made it too aware of the internal > details of the field. > > Frank Kastenholz > > At 05:10 PM 8/24/01 -0500, Brian E Carpenter wrote: > >Frank, > > > >Not all network processors have the degree of inertia > >you describe. I know of at least one that can adapt to > >format changes without new silicon. But that aside, > >what I am talking about is multi-field classifiers in > >border routers, not what happens in core/trunk routers > >where you are completely correct - that is why the diffserv > >code point is 6 bits (sorry, we couldn't squeeze to 4). > >Multi-field classifiers don't need to be "slow path" but > >they aren't subject to quite the constraints you mention, > >in the diffserv architecture. > > > >This is the essence of why diffserv scales and intserv > >doesn't- you only need to do multi-field classification > >at the borders. Actually the format we are proposing > >simplifies MF classifiers because it takes away the need > >to look at port and protocol numbers. > > > > Brian > > > >"Kastenholz, Frank" wrote: > >> > >> All this talk about the format of the flow-id field > >> is rather interesting. But one thing has been missing -- > >> input from someone who will actually _look_ at the > >> field, at very very very high speeds, in hardware, > >> and make forwarding decisions based on it. > >> > >> I am fairly confident in saying that there will not > >> be many sqmm of silicon devoted to determining > >> if the flow id is 'intserv-format' or 'diff-serv > >> format' or 'tennis-serv format'. The edit/compile > >> /debug loop of silicon is such that we can not > >> react soon enough to the next format that is > >> developed. This means that the flowid looker- > >> upper will be very very general. That means > >> that we don't care what the format is. We just > >> take the whole 20-bits and look 'em up (e.g., > >> throw them all at a CAM, and see what comes out) > >> > >> The only thing that would make the looker-upper's > >> job easier is to know that the flow-id is going > >> going to be shorter than 20 bits (maybe via the > >> protocol specification, maybe via some software > >> magic ala MPLS label negotiations). A looker-upper > >> that is limited to 4 bits is a different beast > >> than a looker-upper that does 20. > >> > >> So, you folks can argue all you want about the format > >> of the flow-id and those format differences may matter > >> at some level in the software. But to the people who > >> are the actual customers of the bits -- the silicon > >> forwarders -- it just doesn't matter. > >> > >> Frank Kastenholz -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 09:41:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGf140004700 for ; Tue, 28 Aug 2001 09:41:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SGf0Lq004699 for ipng-dist; Tue, 28 Aug 2001 09:41:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGeu40004692 for ; Tue, 28 Aug 2001 09:40:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10634 for ; Tue, 28 Aug 2001 09:41:05 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29782 for ; Tue, 28 Aug 2001 10:41:01 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7SGcaV22556; Tue, 28 Aug 2001 09:38:57 -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 AAP09735; Tue, 28 Aug 2001 09:40:29 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA21918; Tue, 28 Aug 2001 09:40:29 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15243.51581.16003.942205@thomasm-u1.cisco.com> Date: Tue, 28 Aug 2001 09:40:29 -0700 (PDT) To: Brian E Carpenter Cc: Robert Elz , Alex Conta , Bob Hinden , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B8BAA88.2D610245@hursley.ibm.com> References: <3B8A6ECE.D7703FD6@txc.com> <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> <3109.998985722@brandenburg.cs.mu.OZ.AU> <3B8BAA88.2D610245@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > The only concrete proposals I have ever seen for use of the Flow Label > are for QOS. Everything else has been hand-waving. We need to decide. > It's unthinkable to leave this big mystery gap in the middle of the > IPv6 header. You know, this reminds me of having a bright shiney quarter burning to be spent by virtue of the fact that it's there. The eight bits in the ip4 header for TOS were standardized but not widely implemented. That allowed us to go back 20 years later with a little bit more time and understanding to create a solution that's at least plausible. Considering that most QoS is still at the leap of faith stage, prudence seems like a perfectly reasonable stance. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 09:43:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGhn40004723 for ; Tue, 28 Aug 2001 09:43:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SGhnjl004722 for ipng-dist; Tue, 28 Aug 2001 09:43:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGhj40004715 for ; Tue, 28 Aug 2001 09:43:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28097 for ; Tue, 28 Aug 2001 09:43:53 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02247 for ; Tue, 28 Aug 2001 10:43:48 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA09198; Tue, 28 Aug 2001 17:43:48 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA20642; Tue, 28 Aug 2001 17:43:48 +0100 Message-ID: <3B8BC973.F7316797@hursley.ibm.com> Date: Tue, 28 Aug 2001 11:40:19 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Alex Conta , Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, [lots deleted since I think the nub of our mutual misunderstanding is in this bit] > > Which QOS model? We have two, and they are different and require > > different flow label semantics to work. > > > I fail to understand how either would break if they simply intrepret the > flow label semantics as 'the source has identified this set of packtes > as related'. In either case there is an out-of-band mechansim to > translate the value to a router task. But in the diffserv case, which is stateless (no signalling, no soft state) the only out-of-band mechanism that works is if the flow label has intrinsic semantics. The fact that the packet belongs to a class is useless information on its own; you need to know what that class means, and that can only be conveyed by an encoded field, since there is no signalling or state. > The place you appear to be > struggling is finding a standard mapping between a psuedo random value > and the Traffic Class field. Yes, because it's impossible. > Since the Traffic Class field is itself > a non-standard value (and effectivly psuedo random from an end-to-end > perspective) this seems pointless. No, it's the whole point: the classifier at a domain ingress must choose an appropriate DSCP value to write into the TC field, and that *requires* the classifier to interpret the semantics of some set of fields in the packet header. > > > > > while the fact > > > that there is no single definition of QoS across > > administrative domains > > > means that it is impossible to use any single set of bits to create > > > that definition. > > > > See RFC 3140. > > > >From the above: > In a given network domain, there is a locally defined mapping between > DSCP values and PHBs. > > Therefore my statement stands, there is no single definition of QoS > across administrative domains. Indeed. The problem to be solved is choosing the most appropriate PHB and DSCP for the given domain. The proposed solution is to use the globally defined PHB ID to drive the classifier. 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 Aug 28 09:55:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGtK40004768 for ; Tue, 28 Aug 2001 09:55:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SGtKrC004767 for ipng-dist; Tue, 28 Aug 2001 09:55:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SGtG40004760 for ; Tue, 28 Aug 2001 09:55:17 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24334 for ; Tue, 28 Aug 2001 09:55:25 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02281 for ; Tue, 28 Aug 2001 09:55:23 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA32450; Tue, 28 Aug 2001 17:55:20 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA47208; Tue, 28 Aug 2001 17:55:20 +0100 Message-ID: <3B8BCC16.AA04DCDE@hursley.ibm.com> Date: Tue, 28 Aug 2001 11:51:34 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) References: <200108281622.f7SGMAO01786@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > > Correct. The idea was that people could register PHB IDs with IANA to > > go beyond the formally standardised ones. > > Has anyone done so, or are you aware of any plans at the present time > to do this? (The IANA page doesn't seem to have any listed.) > > I'm trying to understand if this is something that people feel is > useful today, or whether defining the Flow Label is intended to > provide additional encouragement for folks to do so. I don't believe that any have been registered yet. Frankly I'm not surprised, since the communities expected to use the PHB ID first (bandwidth broker, MPLS, ATM) are still busy working out how to handle the standardised PHBs. Indeed, if this usage for the flow label is added, it might well be a stimulus, but that is not my motivation :-) 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 Aug 28 10:01:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SH1l40004788 for ; Tue, 28 Aug 2001 10:01:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SH1l67004787 for ipng-dist; Tue, 28 Aug 2001 10:01:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SH1i40004780 for ; Tue, 28 Aug 2001 10:01:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13716 for ; Tue, 28 Aug 2001 10:01:52 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07023 for ; Tue, 28 Aug 2001 11:02:17 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA09044; Tue, 28 Aug 2001 18:01:48 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA22784; Tue, 28 Aug 2001 18:01:47 +0100 Message-ID: <3B8BCD80.35FDD4FC@hursley.ibm.com> Date: Tue, 28 Aug 2001 11:57:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: Robert Elz , Alex Conta , Bob Hinden , ipng Subject: Re: a), b), c), d), or e) References: <3B8A6ECE.D7703FD6@txc.com> <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> <3109.998985722@brandenburg.cs.mu.OZ.AU> <3B8BAA88.2D610245@hursley.ibm.com> <15243.51581.16003.942205@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, One of the alternatives on the table is to define the field as reserved for future use. I think that would answer your point. At the moment we have a header field described only in non-normative text. I feel that is very confusing for implementors. Brian Michael Thomas wrote: > > Brian E Carpenter writes: > > The only concrete proposals I have ever seen for use of the Flow Label > > are for QOS. Everything else has been hand-waving. We need to decide. > > It's unthinkable to leave this big mystery gap in the middle of the > > IPv6 header. > > You know, this reminds me of having a bright shiney > quarter burning to be spent by virtue of the fact > that it's there. The eight bits in the ip4 header > for TOS were standardized but not widely > implemented. That allowed us to go back > 20 years later with a little bit more time and > understanding to create a solution that's at > least plausible. Considering that most QoS is > still at the leap of faith stage, prudence > seems like a perfectly reasonable stance. > > Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 10:02:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SH2g40004818 for ; Tue, 28 Aug 2001 10:02:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SH2ge5004817 for ipng-dist; Tue, 28 Aug 2001 10:02:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SH2c40004810 for ; Tue, 28 Aug 2001 10:02:38 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13929 for ; Tue, 28 Aug 2001 10:02:47 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01905 for ; Tue, 28 Aug 2001 10:02:46 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA19972; Tue, 28 Aug 2001 18:02:43 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id SAA24018; Tue, 28 Aug 2001 18:02:43 +0100 Message-ID: <3B8BCDB7.7B309E3A@hursley.ibm.com> Date: Tue, 28 Aug 2001 11:58:31 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Keith Knightson CC: Christian Huitema , Bob Hinden , Alex Conta , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't think that is in the least stupid, but some people seem to :-) Brian Keith Knightson wrote: > > Guys, > > Why is it not possible to use the field for different purposes if > the purpose can be suitably identified by some included mechanism > Christian has suggested. Some values being for "standardized" usages > and a few reserved? > > That way everyone could get what they want. > > Or is this a stupid suggestion? > > Keith Knightson > > At 3:43 PM -0700 8/27/01, Christian Huitema wrote: > > > >Could we be a bit parcimonious and reserve a couple of header bits "for > >further use"? We don't seem to have a level of consensus in the group > >that people can guarantee that either a bunch of random bits, or a > >diffserv flow label, are absolutely the best thing since sliced bread. > >Not at the same level as the payload type or payload length, in any > >case. It would be nice to be able to invent something like ECN in > >2010... > > > >Maybe we could make it something like 4 bits of "label type" and 16 bits > >of label value, defining then the possibilities for "0-0", "0-random" > >and "1-diffserv" -- whatever that means. > > > >-- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 10:33:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SHX640004889 for ; Tue, 28 Aug 2001 10:33:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SHX5qm004888 for ipng-dist; Tue, 28 Aug 2001 10:33:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SHX240004881 for ; Tue, 28 Aug 2001 10:33:02 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08195 for ; Tue, 28 Aug 2001 10:33:11 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21499 for ; Tue, 28 Aug 2001 10:33:06 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 10:32:13 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id FA47360836174C5699598D65FBC2750B for plus 4 more; Tue, 28 Aug 2001 10:32:12 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" Cc: "Bob Hinden" , "Alex Conta" , "ipng" Subject: RE: a), b), c), d), or e) Date: Tue, 28 Aug 2001 10:32:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8B9F35.E4327BB4@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: F9B88DD4-F0544935-8047EC7A-08F00F2F Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7SHX240004882 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, It is obvious we are in violent agreement about how the current mechanisms work. I think the difficulty arises from the use of diffserv as a justification for the real goal of exposing the port/protocol # that ESP specifically hides. > > This appears to defy logic. The way I read it, we have a QoS > > mechanism that by-design is not end-to-end oriented, so we MUST > > define a way for the middle to interpret what the end points > > are telling each other.?!? > > The endpoints in diffserv don't tell each other anything; > diffserv is an entirely hop-by-hop model. Each hop may choose > to look at the entire packet header in order to reclassify it. > > > There is absolutly no reason to tie the > > Flow Label field and the Traffic Class field together, which is > > the only point of defining diffserv semantics for the Flow Label. > > No, the point is to provide partial replacement of the {port, > protocol} > semantics that are hidden by ESP. There is no tying together of > Traffic Class and Flow Label. They remain orthogonal. Yes, diffserv is a hop-by-hop mechanism specifically targeting the Traffic Class field, but your arguments on this thread are asking for a part of the Flow Label field for diffserv use, so you are tying them together. What you stated above though is that the real goal has nothing to do with diffserv per se, but one of the capabilities that diffserv based networks typically take advantage of in the ability to deduce what the application is doing through snooping the port/protocol #. As I said, you are looking for a mechanism for the middle boxes to interpret what the end points are telling each other. Mixing diffserv with the desire to expose what ESP is hiding is the disconnect. Those efforts are orthogonal except in environments where people refuse to trust the DSCP bits but will trust the port # bits. We should not be breaking the architecture of ESP or the Flow Label simply to accommodate someone who is paranoid about one set of bits but trusts another set in the same header! If the diffserv network really needs to know what the application is up to then it should use the signaled DCLASS approach of RFC2966. If it is not willing to go that approach, why are we trying to explicitly expose what ESP hides? Either they trust the application to tell them what they need to know through signaling, or they don't; in which case why would they believe anything in the Flow Label? If it is simply a matter of domain specific interpretation of the DSCP has proven to be an operationally useless concept, then the diffserv group should fix that. Usurping another set of bits to accomplish what the Traffic Class field should be used for (but can't for political reasons), is simply the wrong approach. Your proposal is looking for an exposed set of bits that will be consistent end-to-end, so people can make local decisions about how to deliver an end-to-end level of service through a set of concatenated PHB's (by randomly setting the DSCP in each domain). Fix the DSCP so those bits are consistent end-to-end and stay out of the Flow Label field. Its purpose is for the origin node to identify a set of packets that are related, nothing more. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 10:34:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SHYn40004909 for ; Tue, 28 Aug 2001 10:34:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SHYnuk004908 for ipng-dist; Tue, 28 Aug 2001 10:34:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SHYj40004901 for ; Tue, 28 Aug 2001 10:34:45 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02585 for ; Tue, 28 Aug 2001 10:34:55 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16994 for ; Tue, 28 Aug 2001 10:34:54 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id NAA16408; Tue, 28 Aug 2001 13:35:55 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id NAA25026; Tue, 28 Aug 2001 13:35:55 -0400 Message-ID: <3B8BD677.85DDCB87@txc.com> Date: Tue, 28 Aug 2001 13:35:51 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) References: <3B8A6ECE.D7703FD6@txc.com> <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> <3109.998985722@brandenburg.cs.mu.OZ.AU> <3B8BAA88.2D610245@hursley.ibm.com> <15243.51581.16003.942205@thomasm-u1.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msAFC77758CC7127CE5B2A846F" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msAFC77758CC7127CE5B2A846F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Brian E Carpenter writes: > > The only concrete proposals I have ever seen for use of the Flow Label > > are for QOS. Everything else has been hand-waving. We need to decide. > > It's unthinkable to leave this big mystery gap in the middle of the > > IPv6 header. > > You know, this reminds me of having a bright shiney > quarter burning to be spent by virtue of the fact > that it's there. The eight bits in the ip4 header > for TOS were standardized but not widely > implemented. That allowed us to go back > 20 years later with a little bit more time and > understanding to create a solution that's at > least plausible. Considering that most QoS is > still at the leap of faith stage, prudence > seems like a perfectly reasonable stance. > > Mike Plenty, including your company, have used the TOS bits, for CoS, long before the Diffserv effort. I do not think we can afford to reserve 20 bits in the IPv6 main header. IPv6 forwarding and QoS processing at line speeds, at 10G or higher, are very challenging efforts. The Network Layer header must be used efficiently for what is needed. Fields can always be re-defined, or re-used, on a per need basis, in the future. Alex --------------msAFC77758CC7127CE5B2A846F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjgxNzM1NTNaMCMGCSqGSIb3DQEJBDEWBBQXUihH+H9uFXJccsuc TyNrcMmL1jBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gCZF6ZG5qNLjzf1wBG8iv+/+itF/Q+rFD67lAaDXeerT9MCh+MTntE7xHInUR93/wPi8In6O zIETcYbkqCS026EFRL+YNbF0cFHtOvY2IMeoUFcZXi2pbgDgNYzhFU/QS0Bzih/K3RinsxJz BeWOXuhwV5PyQTYFRi7Sf5NVFKv3 --------------msAFC77758CC7127CE5B2A846F-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 11:06:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SI6n40004952 for ; Tue, 28 Aug 2001 11:06:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SI6now004951 for ipng-dist; Tue, 28 Aug 2001 11:06:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SI6j40004944 for ; Tue, 28 Aug 2001 11:06:45 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15903 for ; Tue, 28 Aug 2001 11:06:54 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08956 for ; Tue, 28 Aug 2001 11:06:53 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 11:06:24 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 57A88924B4754500AD484132EB9DF2D3 for plus 1 more; Tue, 28 Aug 2001 11:06:23 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" Cc: Subject: RE: Higher level question about flow label Date: Tue, 28 Aug 2001 11:06:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8BB5F2.6A695FF4@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: CACB6FCB-B73145F2-B3E7DBBB-B441C9AB Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7SI6k40004945 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > ... snip ... It is some of the Intserv > supporters that try to keep Diffserv out (excluded). I am not trying to exclude diffserv, just make the point that diffserv already has a field to work with and is finding that it can't get the job done without taking over another field with imutable properties. > Requesting "immutability" makes sense only when a group of routers on > the path, in a routing domain for instance, are not capable of > preserving the meaning from ingress to egress of that domain, when and > if that > meaning is significant further downstream. If the routers are > capable of > preserving the meaning, or there is no significance downstream, then > "mutability" is a non-issue. Since the network can't possibly know if there is significance downstream (say at the end host), the field has to be imutable. > > The point is they are simply a hint from the originator that packets > > between the src/dst pair are related as far as it is concerned. > > This is an oversimplification, and vagueness, with no > practical benefit. There is nothing vague about that. The originator is identifying a set of packets as related. It would only be vague to a middle box that has no context. In fact in many cases there is practical benifit in preventing the middle boxes from acquiring context. > At this stage, I do not think, we can afford that. At this point what we can't afford is redefining a field simply because the diffserv WG refused to create a set of end-to-end consistent bits. It is no surprise that people are finding it difficult to build hardware that will make consistent decisions when all the bits in the header are random. Since the diffserv mechanism is the one that needs a consistent set of bits for hardware acceleration, that WG should have provided them. Instead the DSCP is effectively a random set of bits with no global context, and we are being asked to redefine another set of bits to provide the necessary end-to-end consistency since the diffserv WG refuses to. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 11:18:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIIh40004982 for ; Tue, 28 Aug 2001 11:18:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SIIhxc004981 for ipng-dist; Tue, 28 Aug 2001 11:18:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIId40004973 for ; Tue, 28 Aug 2001 11:18:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01809 for ; Tue, 28 Aug 2001 11:18:37 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19803 for ; Tue, 28 Aug 2001 12:19:02 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7SIHwF18796; Tue, 28 Aug 2001 21:17:59 +0300 Date: Tue, 28 Aug 2001 21:17:58 +0300 (EEST) From: Pekka Savola To: Srinivasa Rao Nalluri cc: IPng Subject: Re: a doubt on MTU discovery in IPv6 In-Reply-To: <009c01c12fd0$42d5dea0$e6250cc4@wipsys.stph.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 28 Aug 2001, Srinivasa Rao Nalluri wrote: > in IPv6 networks different IP packets from same source to same > distention may travel through different paths. This is true with IPv4 too, and exactly equivalent if you put Don't Fragment bit in IPv4 datagrams. > then how path MTU discovery process can help to find MTU value? > > we don't know through how many different paths packets may travel between same source and distention. If the path changes so radically that MTU changes, ICMPv6 "Packet too Big" message will be sent to the source, MTU will be reduced and the packet re-sent. Your confusion may be based on the difference that in IPv4, routers also may fragment packets. IPv6 fragmentation is end-to-end, and you either use minimum MTU 1280, or implement Path MTU Discovery (above). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 11:18:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIId40004972 for ; Tue, 28 Aug 2001 11:18:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SIIdEY004971 for ipng-dist; Tue, 28 Aug 2001 11:18:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIIX40004964 for ; Tue, 28 Aug 2001 11:18:33 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA01995 for ; Tue, 28 Aug 2001 11:18:38 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14610 for ; Tue, 28 Aug 2001 11:18:37 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 11:16:34 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id E21B53F2F277473C8C9C42F61D7B3611 for plus 5 more; Tue, 28 Aug 2001 11:16:34 -0700 Reply-To: From: "Tony Hain" To: "Keith Knightson" , "Christian Huitema" , "Brian E Carpenter" , "Bob Hinden" Cc: "Alex Conta" , "ipng" Subject: RE: a), b), c), d), or e) Date: Tue, 28 Aug 2001 11:16:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 063E9CE1-F9564D37-9D9B3995-7AE92401 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7SIIZ40004965 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Knightson wrote: > Or is this a stupid suggestion? There are no stupid questions. Some of the pushback is simply based on the fact that the diffserv model of QoS is inherently broken because there is no end-to-end immutable set of bits for local decisions to be based on. What we have on the table is a proposal to take over part of another field to create that set of bits, but even that contains the argument that the bits should be mutable. As soon as that is deployed and proven inadequate they will be back for another set of bits. The diffserv WG should have defined a set of PHBs with global context and mapped a set of DSCPs to those. It chose not to, and now to make products work people are looking for another set of bits. That is the wrong process. The diffserv WG should go back and fix the immutability problem they created. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 11:23:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SINU40005009 for ; Tue, 28 Aug 2001 11:23:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SINUQr005008 for ipng-dist; Tue, 28 Aug 2001 11:23:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SINQ40005001 for ; Tue, 28 Aug 2001 11:23:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03167 for ; Tue, 28 Aug 2001 11:23:29 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09755 for ; Tue, 28 Aug 2001 11:23:28 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7SINKw18830; Tue, 28 Aug 2001 21:23:20 +0300 Date: Tue, 28 Aug 2001 21:23:20 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Christian Huitema , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B8BA0C5.FDADB303@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 28 Aug 2001, Brian E Carpenter wrote: > Christian, > > In fact the diffserv requirement is for a 16 bit field, so we could > adopt: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1 0 0 0| Diffserv IPv6 Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > or something similar, to conserve bits. I support this, but for different reasons. IPv6 base header has _way_ too few "reserved" bits (none), and this would get us 3. It's arrogant to believe we might not find use for them in the future. (you could always define extension headers to do the thing, but it might be good to reserve some space for enhancements-to-be in the primary header too). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 11:30:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIUC40005029 for ; Tue, 28 Aug 2001 11:30:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SIUCPO005028 for ipng-dist; Tue, 28 Aug 2001 11:30:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIU740005021 for ; Tue, 28 Aug 2001 11:30:08 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04540 for ; Tue, 28 Aug 2001 11:30:14 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20456 for ; Tue, 28 Aug 2001 11:30:10 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 11:29:32 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id F2404828EDCD4D97A1EE1430EF6687A0 for plus 3 more; Tue, 28 Aug 2001 11:29:32 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" Cc: "Alex Conta" , "Steve Blake" , Subject: RE: Higher level question about flow label Date: Tue, 28 Aug 2001 11:29:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8BC973.F7316797@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 4513BB20-88C34159-89CFCAB6-FCD0CEF8 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7SIU840005022 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > But in the diffserv case, which is stateless (no signalling, There is RFC2996 to fix this problem... > the only out-of-band mechanism that works is if the flow label has > intrinsic semantics. The fact that the packet belongs to a class is > useless information on its own; you need to know what that > class means, > and that can only be conveyed by an encoded field, since there is no > signalling or state. No argument about needing an immutable encoded field, just that it doesn't need to be the Flow Label. There is still the opportunity for the diffserv WG to create a standard set of encodings for the TC field that are immutable end-to-end, and as you note below that is in process. > No, it's the whole point: the classifier at a domain ingress must > choose an appropriate DSCP value to write into the TC field, and that > *requires* the classifier to interpret the semantics of some set of > fields in the packet header. Or simply to expect that the value in the TC already is the classifier and configure the local PHBs accordingly. > ... The proposed solution is to use > the globally > defined PHB ID to drive the classifier. So why do we also need to usurp part of the FL field, when a global PHB will result in an end-to-end consistent TC field? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 11:33:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIX140005051 for ; Tue, 28 Aug 2001 11:33:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SIX1n8005050 for ipng-dist; Tue, 28 Aug 2001 11:33:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIWu40005043 for ; Tue, 28 Aug 2001 11:32:57 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21893 for ; Tue, 28 Aug 2001 11:32:59 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21932 for ; Tue, 28 Aug 2001 11:32:59 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id OAA17656; Tue, 28 Aug 2001 14:33:59 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA27882; Tue, 28 Aug 2001 14:33:59 -0400 Message-ID: <3B8BE40B.10DA157A@txc.com> Date: Tue, 28 Aug 2001 14:33:47 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Robert Elz , ipng Subject: Re: a), b), c), d), or e) References: <3B8A6ECE.D7703FD6@txc.com> <3B85A530.ADEAA505@txc.com> <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <1922.998648611@brandenburg.cs.mu.OZ.AU> <3109.998985722@brandenburg.cs.mu.OZ.AU> <3B8BAA88.2D610245@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF50B3733F5013B7FCED1F3CF" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF50B3733F5013B7FCED1F3CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert, I will make just a few comments, where it adds value to what Brian already said. Brian E Carpenter wrote: > > Robert Elz wrote: > ... > > It seems that the current flow label is defined to be an immutable field > > which should be set to a PRNG to identify flows (related packet streams). > > Right? > > But it is not defined in normative text, and the text we have is vague > on the actual usage - even worse than the text on the TOS byte in RFC 791, > for example. > In fact, provisions were made, to have the field mutable. For instance transport (IPv6) checksum, and IPsec authentication skip the field, to allow its modification en-route. So, it does not have to be immutable. Non-normative text in RFC 2460 defines setting the value as a PRN, as an aid to hashing based lookups of flow state in routers. Please note, that in absence of a "perfect hashing function", using hashing by itself, will not deliver the lookup result, some additional steps, like a sequential lookup in a hash bucket, may be necessary. However, Intserv/RSVP specifications, and Diffserv specification go into more detail of how classifiers are used. Consequently mechanisms were developed for very efficient classification processing, which hardly resemble the model (vaguely) suggested in RFC 2460. Hardware classifiers for processing at high line speeds are often implemented based on Content Addressable Memories (CAMs), in which PRNs does not help at all. Unfortunately, some take the use of PRN, like an axiom, which is wrong. In fact, Jarno, Christian, myself, and maybe others showed on this thread, that the flow label does not need be a PRN. Brian and I discussed it also in the Carpenter/Conta draft. However, PRNs have the negative effect, that prevent the use of classification or filtering that do not have/use a signaling mechanism to transmit the value of the PRN to the routers. This is one of the impediments for the use of the RFC 2460 definition with Diffserv, or with filtering other than Intserv/RSVP. > > > > To anyone who doesn't understand the diffserv algorithms, that number will > > look random - sure, it won't pass any statistical tests on randomness, but > > no-one is suggesting that the flow label field is required to contain that > > kind of value, are they? > Well, the non-normative RFC 2460 requires PRN. As it has been said, based on current knowledge and experience, there is no good enough reason for using PRN. > [...] > Brian Alex --------------msF50B3733F5013B7FCED1F3CF Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjgxODMzNTdaMCMGCSqGSIb3DQEJBDEWBBS6A98oNhRNUtGsr+l8 5rIwnUXtRTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gJItBczXi6GH6tbaaOFPKwn3xYzc5ZdYW4uW1TnX1THRAQyuu/UsFkTToZQZCW8Eq5UdmXcs V5GYSgUs+UrsKJ0RJMOICxFVCubpMDoQAprEXHpTijtHYC1avKG3i3TEGzRcvHTnmV78UTns RYQ0Y3bmPLiOeoyRkDBC9dbAlOqu --------------msF50B3733F5013B7FCED1F3CF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 11:49:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SInA40005087 for ; Tue, 28 Aug 2001 11:49:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SInAR9005086 for ipng-dist; Tue, 28 Aug 2001 11:49:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SIn640005079 for ; Tue, 28 Aug 2001 11:49:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09131 for ; Tue, 28 Aug 2001 11:49:14 -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 MAA05741 for ; Tue, 28 Aug 2001 12:49:38 -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 LAA16991; Tue, 28 Aug 2001 11:49:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7SInC323223; Tue, 28 Aug 2001 11:49:12 -0700 X-mProtect: Tue, 28 Aug 2001 11:49:12 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdaDhA25; Tue, 28 Aug 2001 11:49:10 PDT Message-Id: <4.3.2.7.2.20010828100846.02328ed0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Aug 2001 10:46:18 -0700 To: Alex Conta From: Bob Hinden Subject: Re: a), b), c), d), or e) Cc: ipng In-Reply-To: <3B8BC390.8AAF6B53@txc.com> References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <4.3.2.7.2.20010827111610.0225c1b8@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, >If this is indeed the process, then it gives an unfair power to IPv6 WG >to undersupport (could read undermine) standards created by other WGs >(Diffserv), which are IP standards, and which inter-depend with IPv6. >This is in my view a broken process. Process wise I think what you are suggesting doesn't scale. The IETF creates many standards. Some of the standards are widely used operationally, others are lightly used, and some are not used at all. If every IETF w.g. was required to support all other IETF standards, then I doubt the output would be very good. Individual working groups need to be able to make their own decision that is appropriate for the work they are doing. I understand you are only really saying that IPv6 w.g. must support the proposed Diffserv flow label definition as proposed in the draft, but you keep doing it in general terms. If you wish to change the IETF standards process to add the requirement that IETF w.g. must support every other IETF standard (or perhaps that they must support Diffserv), then the POISED w.g. is the place to propose it. I think you are going a bit far to suggest that the fate of Diffserv depends on what the IPv6 w.g. does with the flow label field. I suspect that Diffserv will live or die based on IPv4 usage. Also, as IPv6 is deployed much of it will be initially carried over IPv4. Any QoS solution that is going to be end-to-end will have to deal with a mix of native IPv6 and IPv4/IPv6 headers. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 12:03:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SJ3P40005241 for ; Tue, 28 Aug 2001 12:03:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SJ3PE2005240 for ipng-dist; Tue, 28 Aug 2001 12:03:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SJ3L40005233 for ; Tue, 28 Aug 2001 12:03:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12721 for ; Tue, 28 Aug 2001 12:03:29 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12737 for ; Tue, 28 Aug 2001 13:03:52 -0600 (MDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7SJ3Ov41420; Tue, 28 Aug 2001 15:03:24 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7SJ3MV38438; Tue, 28 Aug 2001 15:03:23 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id PAA03756; Tue, 28 Aug 2001 15:03:15 -0400 (EDT) Message-Id: <200108281903.PAA03756@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: alh-ietf@tndh.net cc: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label In-reply-to: Your message of "Tue, 28 Aug 2001 11:06:23 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Aug 2001 15:03:11 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > At this point what we can't afford is redefining a field simply > because the diffserv WG refused to create a set of end-to-end > consistent bits. It is no surprise that people are finding it > difficult to build hardware that will make consistent decisions > when all the bits in the header are random. Since the diffserv > mechanism is the one that needs a consistent set of bits for > hardware acceleration, that WG should have provided them. Instead > the DSCP is effectively a random set of bits with no global > context, and we are being asked to redefine another set of bits > to provide the necessary end-to-end consistency since the > diffserv WG refuses to. I agree with your conclusion, but I disagree with the assumptions you are making about diffserv (for the sake of argument, say). RFC2475 was built on the assumption of bilateral agreements between peering providers, because that was the only model that had a hope of being deployed. The Diffserv flow-label proposal is trying to invent an end-to-end, in-band QoS "signaling" mechanism to operate in parallel with the hop-by-hop DSCP "signaling". The only additional in-band information that would be remotely useful for Diffserv would be a credit card account number. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 13:08:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SK8h40005336 for ; Tue, 28 Aug 2001 13:08:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SK8hk9005335 for ipng-dist; Tue, 28 Aug 2001 13:08:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SK8d40005328 for ; Tue, 28 Aug 2001 13:08:39 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24227 for ; Tue, 28 Aug 2001 13:08:43 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05669 for ; Tue, 28 Aug 2001 13:08:38 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 13:08:34 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 1F1BC34F490B46CBB0A673594558A75E for plus 1 more; Tue, 28 Aug 2001 13:08:33 -0700 Reply-To: From: "Tony Hain" To: "Steve Blake" Cc: Subject: RE: Higher level question about flow label Date: Tue, 28 Aug 2001 13:08:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200108281903.PAA03756@castillo.torrentnet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: D4C347CA-16C64451-A657C4DC-025DF461 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7SK8d40005329 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Blake wrote: > I agree with your conclusion, but I disagree with the assumptions > you are making about diffserv (for the sake of argument, say). I assume you are talking about the WG not the protocol. :) > RFC2475 was built on the assumption of bilateral agreements between > peering providers, because that was the only model that had a hope > of being deployed. But bi-lat's don't necessarily require mutability of the TC field. That was simply a concession to those who wanted knobs to make it more difficult for the less skilled. Now we have a mechanism that only has a hope of being deployed, but is operationally useless on a global scale because it lacks any context. > The Diffserv flow-label proposal is trying to > invent an end-to-end, in-band QoS "signaling" mechanism to operate in > parallel with the hop-by-hop DSCP "signaling". Basically the hop-by-hop decisions have to be based on consistent end-to-end semantics of a set of bits, but the TC field was allowed to be randomized so it is currently useless for that purpose. This is still fixable by locking down the PHBs and matching DSCPs, so there is no need for taking additional header bits. > The only additional > in-band information that would be remotely useful for Diffserv would > be a credit card account number. Not if the proposed new end-to-end signaling is left as mutable. There will be a never-ending series of requests for bits until it is accepted that what is required is an end-to-end immutable set that the origin node uses to identify its intent for the packets, (in or out of band). The intervening networks will always make local decisions based on those bits, so there is no need to rewrite them at every domain boundary. All the TC field is used for now is an embedded MPLS type tag, so why is it embedded? Shouldn't it be the end-to-end consistent set of bits and let MPLS do the tagging it will undoubtedly do for TE purposes anyway? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 14:20:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLKm40005417 for ; Tue, 28 Aug 2001 14:20:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SLKmoa005416 for ipng-dist; Tue, 28 Aug 2001 14:20:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLKT40005409 for ; Tue, 28 Aug 2001 14:20:29 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11637 for ; Tue, 28 Aug 2001 14:20:38 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08586 for ; Tue, 28 Aug 2001 14:20:36 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA28830; Tue, 28 Aug 2001 22:20:32 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA20560; Tue, 28 Aug 2001 22:20:33 +0100 Message-ID: <3B8C07D6.E3C6F7B1@hursley.ibm.com> Date: Tue, 28 Aug 2001 16:06:30 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bob Hinden CC: Alex Conta , ipng Subject: Re: a), b), c), d), or e) References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <4.3.2.7.2.20010827111610.0225c1b8@mailhost.iprg.nokia.com> <4.3.2.7.2.20010828100846.02328ed0@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > .. > I think you are going a bit far to suggest that the fate of Diffserv > depends on what the IPv6 w.g. does with the flow label field. I suspect > that Diffserv will live or die based on IPv4 usage. Also, as IPv6 is > deployed much of it will be initially carried over IPv4. Any QoS solution > that is going to be end-to-end will have to deal with a mix of native IPv6 > and IPv4/IPv6 headers. Indeed, and since I don't quite see how IPSEC and NAT-PT are going to work together, the need that triggered this discussion (the need to classify ESP packets in the middle of the Internet) really doesn't arise in the case of translated packets. The concern is for a native IPv6 environment. 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 Aug 28 14:21:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLLp40005427 for ; Tue, 28 Aug 2001 14:21:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SLLpZD005426 for ipng-dist; Tue, 28 Aug 2001 14:21:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLLl40005419 for ; Tue, 28 Aug 2001 14:21:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26201 for ; Tue, 28 Aug 2001 14:21:56 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08597 for ; Tue, 28 Aug 2001 15:21:51 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA31644; Tue, 28 Aug 2001 22:21:52 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA20578; Tue, 28 Aug 2001 22:21:52 +0100 Message-ID: <3B8C0821.DD46869B@hursley.ibm.com> Date: Tue, 28 Aug 2001 16:07:45 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Pekka Savola CC: Christian Huitema , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So would you prefer the choice of redefining the flow label as a "reserved, must be zero" field? Brian Pekka Savola wrote: > > On Tue, 28 Aug 2001, Brian E Carpenter wrote: > > > Christian, > > > > In fact the diffserv requirement is for a 16 bit field, so we could > > adopt: > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1 0 0 0| Diffserv IPv6 Flow Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > or something similar, to conserve bits. > > I support this, but for different reasons. IPv6 base header has _way_ too > few "reserved" bits (none), and this would get us 3. It's arrogant to > believe we might not find use for them in the future. > > (you could always define extension headers to do the thing, but it might > be good to reserve some space for enhancements-to-be in the primary header > too). > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 14:27:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLRi40005451 for ; Tue, 28 Aug 2001 14:27:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SLRijv005450 for ipng-dist; Tue, 28 Aug 2001 14:27:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLRe40005443 for ; Tue, 28 Aug 2001 14:27:41 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10280 for ; Tue, 28 Aug 2001 14:27:50 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11786 for ; Tue, 28 Aug 2001 14:27:48 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7SLRko43265; Tue, 28 Aug 2001 17:27:46 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7SLRk540341; Tue, 28 Aug 2001 17:27:46 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id RAA06132; Tue, 28 Aug 2001 17:27:40 -0400 (EDT) Message-Id: <200108282127.RAA06132@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: alh-ietf@tndh.net cc: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label In-reply-to: Your message of "Tue, 28 Aug 2001 13:08:33 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Aug 2001 17:27:40 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > Steve Blake wrote: > > > I agree with your conclusion, but I disagree with the assumptions > > you are making about diffserv (for the sake of argument, say). > I assume you are talking about the WG not the protocol. :) Actually, the opposite. :) > > RFC2475 was built on the assumption of bilateral agreements between > > peering providers, because that was the only model that had a hope > > of being deployed. > But bi-lat's don't necessarily require mutability of the TC field. That > was simply a concession to those who wanted knobs to make it more > difficult for the less skilled. Now we have a mechanism that only has > a hope of being deployed, but is operationally useless on a global > scale because it lacks any context. Diffserv on a global scale is useless, in the sense that, I don't care what QoS you want for your packet unless you are paying me directly, or paying me via a proxy that I peer with, ad infinitum. > > The Diffserv flow-label proposal is trying to > > invent an end-to-end, in-band QoS "signaling" mechanism to operate in > > parallel with the hop-by-hop DSCP "signaling". > Basically the hop-by-hop decisions have to be based on consistent > end-to-end semantics of a set of bits, but the TC field was allowed > to be randomized so it is currently useless for that purpose. This > is still fixable by locking down the PHBs and matching DSCPs, so > there is no need for taking additional header bits. There is no need to take additional header bits period, in my view, irrespective of whether the hop-by-hop semantics of the DSCP are changed. Diffserv does support some "flexibility" that in retrospect is more silly than useful, IMHO, but even if the mapping of DHCP-to-PHB were fixed, the PHBs have been defined in such a way that they have no obvious relationship to a particular user's or application's QoS preferences, and even if that were not the case, the DSCP still remains mutable, because a network has to be able to protect it resources from upstream freeloaders. > > The only additional > > in-band information that would be remotely useful for Diffserv would > > be a credit card account number. > Not if the proposed new end-to-end signaling is left as mutable. There > will be a never-ending series of requests for bits until it is accepted > that what is required is an end-to-end immutable set that the origin > node uses to identify its intent for the packets, (in or out of band). > The intervening networks will always make local decisions based on > those bits, so there is no need to rewrite them at every domain boundary. > All the TC field is used for now is an embedded MPLS type tag, so why is > it embedded? Shouldn't it be the end-to-end consistent set of bits and > let MPLS do the tagging it will undoubtedly do for TE purposes anyway? As I said, the only useful immutable information is a billing account number. That could be propagated via signaling (Intserv), although that does not appear to be a popular option these days. There is no way we will ever try to shoehorn that kind of information in-band into packets. The Diffserv model is to aggregate classification information at domain boundaries, so that the billing model will scale. The DSCP is the field that conveys this information between boundaries. It must remain mutable to protect from freeloaders (as an alternative to simply discarding their packets). I haven't seen any evidence that six bits isn't adequate for this purpose. We cannot rely on MPLS labeling because MPLS isn't pervasive (yet). The argument that Diffserv critically depends on the ability of a router to classify the application type in the middle of the network is incorrect; the Diffserv model will work if this function is restricted to the edges of the network, and then only because of the lack of infrastructure which would allow the source host to mark the DSCP meaningfully. I would personally prefer that the flow label would remain an end-to-end immutable field that uniquely identifies flows originated by a particular source node, though as a forwarding engine designer, it doesn't matter; we will find the bits we need to find regardless. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 14:28:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLSI40005461 for ; Tue, 28 Aug 2001 14:28:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SLSH15005460 for ipng-dist; Tue, 28 Aug 2001 14:28:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLSE40005453 for ; Tue, 28 Aug 2001 14:28:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23149 for ; Tue, 28 Aug 2001 14:28:23 -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 PAA12885 for ; Tue, 28 Aug 2001 15:28:18 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7SLSHd20009; Wed, 29 Aug 2001 00:28:17 +0300 Date: Wed, 29 Aug 2001 00:28:17 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Christian Huitema , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B8C0821.DD46869B@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 28 Aug 2001, Brian E Carpenter wrote: > So would you prefer the choice of redefining the flow label > as a "reserved, must be zero" field? Yes, at least partially. > Pekka Savola wrote: > > > > On Tue, 28 Aug 2001, Brian E Carpenter wrote: > > > > > Christian, > > > > > > In fact the diffserv requirement is for a 16 bit field, so we could > > > adopt: > > > > > > 0 1 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1 0 0 0| Diffserv IPv6 Flow Label | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > or something similar, to conserve bits. > > > > I support this, but for different reasons. IPv6 base header has _way_ too > > few "reserved" bits (none), and this would get us 3. It's arrogant to > > believe we might not find use for them in the future. > > > > (you could always define extension headers to do the thing, but it might > > be good to reserve some space for enhancements-to-be in the primary header > > too). > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 14:40:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLeV40005518 for ; Tue, 28 Aug 2001 14:40:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SLeVwt005517 for ipng-dist; Tue, 28 Aug 2001 14:40:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLeR40005510 for ; Tue, 28 Aug 2001 14:40:27 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00058 for ; Tue, 28 Aug 2001 14:40:32 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17813 for ; Tue, 28 Aug 2001 14:40:30 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA20164; Tue, 28 Aug 2001 22:40:27 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA21384; Tue, 28 Aug 2001 22:40:27 +0100 Message-ID: <3B8C0C49.432F59FF@hursley.ibm.com> Date: Tue, 28 Aug 2001 16:25:29 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Keith Knightson , Christian Huitema , Bob Hinden , Alex Conta , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Keith Knightson wrote: > > > Or is this a stupid suggestion? > > There are no stupid questions. Some of the pushback is > simply based on the fact that the diffserv model of QoS > is inherently broken because there is no end-to-end > immutable set of bits for local decisions to be based on. This is a very unfair comment. Diffserv is just fine in the case of unencrypted traffic. It has a problem (and so does intserv I suspect) with tunnel or transport mode ESP. > What we have on the table is a proposal to take over > part of another field to create that set of bits, but > even that contains the argument that the bits should be > mutable. No it doesn't. They should be set at source. (But anyway, why would it matter if they are mutable, since they aren't covered by checksum? I'm not aware of a law of nature against mutable bits.) > As soon as that is deployed and proven > inadequate they will be back for another set of bits. There would indeed be the option of defining an IPv6 header not covered by ESP for this. But I think that would raise traffic analysis issues way beyond those raised by the current proposal. Anyway, in this last sentence you have stopped arguing on the merits. > The diffserv WG should have defined a set of PHBs with > global context and mapped a set of DSCPs to those. It > chose not to, No, that is in fact what we did, but at the specific insistence of the ISPs active in the design of diffserv, we made all of the mappings SHOULD instead of MUST. You want to ding the WG for meeting a clearly stated key requirement of the principal customer set? > and now to make products work people are > looking for another set of bits. er, try "to give IPv6 an advantage over IPv4 in the case of encrypted traffic with a QOS requirement..." Products work just fine the way things are. > That is the wrong > process. The diffserv WG should go back and fix the > immutability problem they created. Immutablity isn't the problem. Encryption of the port and protocol numbers is the problem. I could equally well say that IPSEC should go back and fix the invisibility problem they created. What I am actually saying is that this WG should go back and fix the ambiguity problem created by the Appendix to RFC 2460. 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 Aug 28 14:50:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLoh40005537 for ; Tue, 28 Aug 2001 14:50:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SLohZ8005536 for ipng-dist; Tue, 28 Aug 2001 14:50:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLod40005529 for ; Tue, 28 Aug 2001 14:50:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15113 for ; Tue, 28 Aug 2001 14:50:48 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10488 for ; Tue, 28 Aug 2001 14:50:47 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA20410; Tue, 28 Aug 2001 22:50:44 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA47268; Tue, 28 Aug 2001 22:50:45 +0100 Message-ID: <3B8C0E9C.13CDB728@hursley.ibm.com> Date: Tue, 28 Aug 2001 16:35:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Alex Conta , ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, ... > At this point what we can't afford is redefining a field simply > because the diffserv WG refused to create a set of end-to-end > consistent bits. Please don't use this kind of language. As I just said on the other thread, diffserv reached consensus (in 1998) on a completely self- consistent model meeting the key requirements stated by ISPs. > It is no surprise that people are finding it > difficult to build hardware that will make consistent decisions > when all the bits in the header are random. What on earth do you mean? The DSCP to PHB mapping is configured, but there is nothing random involved. If you actually study the diffserv MIB, you will discover just how structured it is. (You won't actually find any PHBs in the MIB, since PHBs are just composed from queues and schedulers). > Since the diffserv > mechanism is the one that needs a consistent set of bits for > hardware acceleration, No, it needs to examine header semantics at administrative domain boundaries. That might or might not be a hardware based process, depending on technology. But the core routers don't need to examine header semantics. > that WG should have provided them. Instead > the DSCP is effectively a random set of bits with no global > context, Again, there is nothing random about them, and the mapping is configured via the MIB or some such mechanism. > and we are being asked to redefine another set of bits > to provide the necessary end-to-end consistency since the > diffserv WG refuses to. Again, it isn't a question of "refuses". See above. 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 Aug 28 14:54:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLsh40005554 for ; Tue, 28 Aug 2001 14:54:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SLshq8005553 for ipng-dist; Tue, 28 Aug 2001 14:54:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SLsd40005546 for ; Tue, 28 Aug 2001 14:54:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18860 for ; Tue, 28 Aug 2001 14:54:49 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01769 for ; Tue, 28 Aug 2001 15:54:44 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id RAA22011; Tue, 28 Aug 2001 17:55:49 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id RAA08469; Tue, 28 Aug 2001 17:55:49 -0400 Message-ID: <3B8C1361.A0875668@txc.com> Date: Tue, 28 Aug 2001 17:55:45 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA270D1CD4371B036B08D0962" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msA270D1CD4371B036B08D0962 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > Alex Conta wrote: > > I am not trying to exclude diffserv, just make the point that > diffserv already has a field to work with The DSCP field and its numbering space is not sufficient for everything that one may want Diffserv for. Diffserv has two types of classifiers, the B-A, and M-F. For good reasons, each achieving different purposes. Intserv can use addresses, and ports as filter_spec(s) in both IPv4, and IPv6. Diffserv can use addresses, ports, and protocol IDs, for M-F classifiers, in both IPv4, and IPv6. Intserv can use addresses and IPv6 flow labels in IPv6, where the flow labels are replacing ports. Diffserv could use addresses and IPv6 flow labels in IPv6, to replace ports and protocol IDs in M-F classifiers. > and is finding that it can't get the job done without taking over another field > with imutable properties. It can get the job done, but less efficient than in IPv4, and that is not because work done by the Diffserv WG. If Intserv can take advantage of the flow label, and be more efficient, since it can use the functions that were designed for this in IPv6, why should Diffserv not take advantage as well? You oppose that only because it has to share the flow label space with Intserv? If the flow label were to be used ala RFC 2460, the entire space from 00000 ot fffff would be allocated to Intserv. If my customers, or just people in general, do not choose to use Intserv/RSVP, but want to use Diffserv, with M-F classifiers, for them, the flow label and its numbering space is a waste. > > Since the network can't possibly know if there is significance > downstream (say at the end host), the field has to be imutable. > Your assumption is wrong. The network can know, through various means, which of course include signaling. Ad absurdum, if the routers in a domain, do not know, or there is no mechanism to know, but they can have a use of a mutable flow label, then they would work together, and have the egress restore the original value when packets leave the domain. My making the flow label an absolute immutable field, you would lose this capability, as well as potential for future development. > > > The point is they are simply a hint from the originator that packets > > > between the src/dst pair are related as far as it is concerned. > > > > This is an oversimplification, and vagueness, with no > > practical benefit. > > There is nothing vague about that. It is vague in its final practical purpose. A definition devoid of purpose makes little sense. It is like saying we define the TCP, and UDP ports just for the sake of having some ports in the header. > > At this stage, I do not think, we can afford that. > > At this point what we can't afford is redefining a field simply > because the diffserv WG refused to create a set of end-to-end > consistent bits. You are missing the point. The Intserv, and Diffserv have not created sets of bits to be used for Intserv classifiers, or Diffserv M-F classification purposes with IPv4. IPv6 has the flow label, which is defined and advertised as an important (QoS) diffentiator. In reality besides being a differentiator, it is used to compensate for the inefficiency introduced by the IPv6 "extensibility". For people that do not want to use Intserv/RSVP, without adding flow label support for Diffserv, that advertized differentiator is just smoke, it does not exist, while they pay the efficiency penalty of the "extensibility". On one hand, you suggest this vague, no final purpose, definition of flow labels, which is practically a waste of the bits, and on the other hand you oppose a good practical use of those bits, just because there is an attempt to structure them in a certain way. > It is no surprise that people are finding it > difficult to build hardware that will make consistent decisions > when all the bits in the header are random. Since the diffserv > mechanism is the one that needs a consistent set of bits for > hardware acceleration, that WG should have provided them. That working group does not standardize the IPv6 headers. > [..] > and we are being asked to redefine another set of bits > to provide the necessary end-to-end consistency since the > diffserv WG refuses to. That "another set of bits" is already there. You just give them a use for which they are there for, which is QoS, and a structure. > > Tony Alex --------------msA270D1CD4371B036B08D0962 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjgyMTU1NDhaMCMGCSqGSIb3DQEJBDEWBBTc9DyMXestbEFuVhx7 X1t0opcBXjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gAf/YaY/yRdBI0A6Z9wXny7hZ65whfW8mlyDm3z7sNvhz183N9DGdu0TGaZYmWHvAkjz3ppr 8HkiNJCZThbMXklC5QrM2tziSvFBG/h4jn64CVvubBg9RsMQKxFWwJ3/ROBjAEk9pqJMKoAE jlIqVTPdM5DKWOtVUSKIwzlxcgYK --------------msA270D1CD4371B036B08D0962-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 15:02:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SM2b40005602 for ; Tue, 28 Aug 2001 15:02:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SM2bCp005601 for ipng-dist; Tue, 28 Aug 2001 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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SM2X40005594 for ; Tue, 28 Aug 2001 15:02:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17218 for ; Tue, 28 Aug 2001 15:02:43 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15451 for ; Tue, 28 Aug 2001 15:02:42 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA32942; Tue, 28 Aug 2001 23:02:39 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA22888; Tue, 28 Aug 2001 23:02:40 +0100 Message-ID: <3B8C1148.C93C4BC5@hursley.ibm.com> Date: Tue, 28 Aug 2001 16:46:48 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Brian, > > > But in the diffserv case, which is stateless (no signalling, > > There is RFC2996 to fix this problem... That only works up to the first diffserv domain on the traffic path. As the packets enters a 2nd, 3rd etc. diffserv domain, the problem reappears. By the way, the absence of signalling is a virtue, not a problem, from the scaling viewpoint. > > > the only out-of-band mechanism that works is if the flow label has > > intrinsic semantics. The fact that the packet belongs to a class is > > useless information on its own; you need to know what that > > class means, > > and that can only be conveyed by an encoded field, since there is no > > signalling or state. > > No argument about needing an immutable encoded field, just that > it doesn't need to be the Flow Label. There is still the opportunity > for the diffserv WG to create a standard set of encodings for the > TC field that are immutable end-to-end, and as you note below that > is in process. No it isn't. By construction, DSCPs are "SHOULDs" and are always mappable. PHB IDs are meta-values. > > No, it's the whole point: the classifier at a domain ingress must > > choose an appropriate DSCP value to write into the TC field, and that > > *requires* the classifier to interpret the semantics of some set of > > fields in the packet header. > > Or simply to expect that the value in the TC already is the > classifier and configure the local PHBs accordingly. This is exactly what ISPs have always said they will not do in the general case, although of course they will if the SLA in place says so. > > > ... The proposed solution is to use > > the globally > > defined PHB ID to drive the classifier. > > So why do we also need to usurp part of the FL field, when a > global PHB will result in an end-to-end consistent TC field? Because the diffserv architecture requires the option to reclassify traffic, because that's what the ISPs say they need. I don't like the word "usurp". If the flow label was already standardised and in habitual use, it would be appropriate, but then we wouldn't be having this conversation anyway. Since it is not standardised, there is nothing to usurp. 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 Aug 28 15:07:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SM7Y40005619 for ; Tue, 28 Aug 2001 15:07:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SM7Ycp005618 for ipng-dist; Tue, 28 Aug 2001 15:07:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SM7U40005611 for ; Tue, 28 Aug 2001 15:07:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05864 for ; Tue, 28 Aug 2001 15:07:40 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17500 for ; Tue, 28 Aug 2001 15:07:39 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id SAA22258; Tue, 28 Aug 2001 18:08:41 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA08920; Tue, 28 Aug 2001 18:08:41 -0400 Message-ID: <3B8C1667.3F9F260D@txc.com> Date: Tue, 28 Aug 2001 18:08:39 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2C630AC2094C81D9767042A8" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms2C630AC2094C81D9767042A8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > [...] Some of the pushback is > simply based on the fact that the diffserv model of QoS > is inherently broken because there is no end-to-end > immutable set of bits for local decisions to be based on. I hate to say it, but your conclusion is grotesquely false. The Diffserv QOS model is not broken at all - I don't know how, where, and why you got that. For IPv4 M-F classification, Diffserv can use the well-known 5-tuple. src, dst addresses, src, dst ports, and protocol ID. For IPv6, it can use the same 5-tuple. However, using the same tuple presents a number of problems, which the use of the flow label alleviates. That is in a similar fashion to the Intserv use of filter_specs, with addresses, and ports, and addresses and flow labels. > What we have on the table is a proposal to take over > part of another field to create that set of bits, but > even that contains the argument that the bits should be > mutable. These are false conclusions. This is ignoring or ignorance, of some basic facts. First the FLOW LABEL WAS DEFINED WITH MUTABILITY IN MIND - the checksum calculation (IPv6), and the IPv6 IPsec authentication skip the flow label field, on purpose to allow en-route changes. You assume that the flow label MUST be immutable, because you base your thinking on an absolute model. An absolute model is closed, and unnecessarily restrictive, not allowing future development or enhancements. As the value of the flow label can change as long as the meaning is preserved, the model can be relative, and thus be opened for future development. > As soon as that is deployed and proven > inadequate they will be back for another set of bits. This is a grotesque ignoring of facts, and misleading statements. The flow label value space is there (00000-fffff). If Intserv is using the flow label ala RFC 2460, than the entire label space is given to Intserv. If Diffserv is using the flow label, and that is as legitimate as the use by Intserv, it has to simply share the same label space. A simple way is to keep a static separation, and divide it in two. > The diffserv WG should have defined a set of PHBs with > global context and mapped a set of DSCPs to those. It > chose not to, and now to make products work people are > looking for another set of bits. That is the wrong > process. The diffserv WG should go back and fix the > immutability problem they created. > > Tony What are you talking about? This seems to be a grotesque random mixing of things, and getting to false conclusions and misleading statements. Alex --------------ms2C630AC2094C81D9767042A8 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjgyMjA4MzlaMCMGCSqGSIb3DQEJBDEWBBQHim0XtZvkMB6b4ffe wSzyW2zECzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gFLQT+uhzlD1jw7n0cyufTpR4nBL4jETDdFJOtrOrndhTBjX7RzECGaZeVPpMTVWw/Mf4HKV lXiK0hsxE9cp/eaCejyPmrwxgyYRbffrzlWElzB34zHLoi1cyZjW3jqKjVSWxoTjqwiKhPHn CchD99zNxtBPtTRcrSC1gZ53a3Mz --------------ms2C630AC2094C81D9767042A8-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 15:18:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SMI140005641 for ; Tue, 28 Aug 2001 15:18:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SMI1AU005640 for ipng-dist; Tue, 28 Aug 2001 15:18:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SMHu40005633 for ; Tue, 28 Aug 2001 15:17:56 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20210 for ; Tue, 28 Aug 2001 15:18:03 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03647 for ; Tue, 28 Aug 2001 15:18:02 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA26098; Tue, 28 Aug 2001 23:17:59 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA38524; Tue, 28 Aug 2001 23:17:59 +0100 Message-ID: <3B8C14A9.C63B5464@hursley.ibm.com> Date: Tue, 28 Aug 2001 17:01:13 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Preamble: this is getting pretty far away from the core of the debate. I'd like the chairs to make some consensus calls, because we are going round in circles. Tony Hain wrote: > > Steve Blake wrote: > > > I agree with your conclusion, but I disagree with the assumptions > > you are making about diffserv (for the sake of argument, say). > I assume you are talking about the WG not the protocol. :) > > > RFC2475 was built on the assumption of bilateral agreements between > > peering providers, because that was the only model that had a hope > > of being deployed. > But bi-lat's don't necessarily require mutability of the TC field. That > was simply a concession to those who wanted knobs to make it more > difficult for the less skilled. Now we have a mechanism that only has > a hope of being deployed, but is operationally useless on a global > scale because it lacks any context. I think that is quite unproven. Specifically (apart from a few researchers) the kind of thing I expect major ISPs to do with the flexibility is to implement multiple instances of the standard PHBs, which requires them to use additional DSCP values for the multiple instances. The context will be provided by a QOS policy management system and their SLAs. > > The Diffserv flow-label proposal is trying to > > invent an end-to-end, in-band QoS "signaling" mechanism to operate in > > parallel with the hop-by-hop DSCP "signaling". > Basically the hop-by-hop decisions have to be based on consistent > end-to-end semantics of a set of bits, but the TC field was allowed > to be randomized so it is currently useless for that purpose. This > is still fixable by locking down the PHBs and matching DSCPs, so This is a dream. It isn't going to happen. I went through denial/anger/acceptance on this three years ago. > there is no need for taking additional header bits. Abolish IPSEC and I will agree with you. > > > The only additional > > in-band information that would be remotely useful for Diffserv would > > be a credit card account number. > Not if the proposed new end-to-end signaling is left as mutable. There > will be a never-ending series of requests for bits until it is accepted > that what is required is an end-to-end immutable set that the origin > node uses to identify its intent for the packets, (in or out of band). There is no request for a new mutable field. On the contrary, diffserv classification needs something that is globally unique. > The intervening networks will always make local decisions based on > those bits, so there is no need to rewrite them at every domain boundary. > All the TC field is used for now is an embedded MPLS type tag, so why is > it embedded? That's a *complete* mischaracterisation. It doesn't resemble an MPLS tag in any shape or form. It's in the IP header becasue it is used to drive schedulers for queues of IP packets. > Shouldn't it be the end-to-end consistent set of bits and > let MPLS do the tagging it will undoubtedly do for TE purposes anyway? MPLS is not the e2e protocol in the Internet, and is probably only a passing phase anyway. Diffserv traffic will get mapped onto a variety of hardware layers; but diffserv is about IP packet scheduling, not about lower layer frame scheduling. 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 Aug 28 15:26:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SMQK40005658 for ; Tue, 28 Aug 2001 15:26:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SMQKau005657 for ipng-dist; Tue, 28 Aug 2001 15:26:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SMQG40005650 for ; Tue, 28 Aug 2001 15:26:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09459 for ; Tue, 28 Aug 2001 15:26:24 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22655 for ; Tue, 28 Aug 2001 16:26:50 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id SAA22496; Tue, 28 Aug 2001 18:27:24 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA09536; Tue, 28 Aug 2001 18:27:24 -0400 Message-ID: <3B8C1AC9.B0FA28B4@txc.com> Date: Tue, 28 Aug 2001 18:27:21 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Hinden CC: ipng Subject: Re: a), b), c), d), or e) References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <4.3.2.7.2.20010827111610.0225c1b8@mailhost.iprg.nokia.com> <4.3.2.7.2.20010828100846.02328ed0@mailhost.iprg.nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5828E88D0D59B99D0A53B381" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms5828E88D0D59B99D0A53B381 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Hinden wrote: > > Alex, > > >If this is indeed the process, then it gives an unfair power to IPv6 WG > >to undersupport (could read undermine) standards created by other WGs > >(Diffserv), which are IP standards, and which inter-depend with IPv6. > >This is in my view a broken process. > > Process wise I think what you are suggesting doesn't scale. The IETF > creates many standards. Some of the standards are widely used > operationally, others are lightly used, and some are not used at all. If > every IETF w.g. was required to support all other IETF standards, then I > doubt the output would be very good. Individual working groups need to be > able to make their own decision that is appropriate for the work they are > doing. > Indeed. You are absolutely right, the process would have scaleability problems if extended to the entire IETF. > I understand you are only really saying that IPv6 w.g. must support the > proposed Diffserv flow label definition as proposed in the draft, but you > keep doing it in general terms. I am talking only about standards that are inter-related, interdependent. I am saying, that IPv6 should support Diffserv in its entirety, and not just pieces, and that is independent of the Carpenter/Conta proposal. > > If you wish to change the IETF standards process to add the requirement > that IETF w.g. must support every other IETF standard (or perhaps that they > must support Diffserv), then the POISED w.g. is the place to propose it. > As already stated, not every other, but inter-dependent. I think you understood what I meant. Poised may be an option, but would have to check more on the definition of the process, since I am not an expert on that. > I think you are going a bit far to suggest that the fate of Diffserv > depends on what the IPv6 w.g. does with the flow label field. I suspect > that Diffserv will live or die based on IPv4 usage. Also, as IPv6 is > deployed much of it will be initially carried over IPv4. Any QoS solution > that is going to be end-to-end will have to deal with a mix of native IPv6 > and IPv4/IPv6 headers. > > Bob I am particularly concerned, and the proposal refers to that, about access networks, where, the address space is IPv6, i.e. before tunneling over IPv4. Alex --------------ms5828E88D0D59B99D0A53B381 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjgyMjI3MjJaMCMGCSqGSIb3DQEJBDEWBBQjIt7AmuSceCB3IZVh Xfnv68YiazBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gEDYkyinNsJzOdJX/kojAm+eOq/CN13sSQdukg5l2/opBiUgOqCA81I3N9ZO/3ZF8juChF3z o+tPpZXvwEBJAhoKSh/Z4d+gjAmIUjUJoPkmS/3mOm+1/XYwsyUtaWb4VgptysKMZKhZ03XR Havyki1DIjhk7Rc2fRbgrO5OKT7S --------------ms5828E88D0D59B99D0A53B381-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 16:47:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SNl240005791 for ; Tue, 28 Aug 2001 16:47:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7SNl2HI005790 for ipng-dist; Tue, 28 Aug 2001 16: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SNkw40005783 for ; Tue, 28 Aug 2001 16:46:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11439 for ; Tue, 28 Aug 2001 16:47:06 -0700 (PDT) Received: from roam.psg.com (ip-172-63.meeting.hinet.net [210.61.172.63] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA23603 for ; Tue, 28 Aug 2001 17:47:32 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15bsZN-0004mu-00; Wed, 29 Aug 2001 07:46:57 +0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Thomas Narten Cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "An analysis of IPv6 anycast" References: <200108281250.f7SCoqn01616@hygro.adsl.duke.edu> Message-Id: Date: Wed, 29 Aug 2001 07:46:57 +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> much talk and fud about this. in practice, this does not seem to be >> a problem. > It is clear that there is a *potential* for trouble. yup. and there is a potential for an earthquake. as an engineer, i deal with the pragmatic realities i face, and don't make american-style laws to prevent my self from being in a tall building in case there is an earthquake. > If one controls the environment sufficiently, uses protocols that are > relatively robust to network failures, one can make it work. Even work > quite well it would seem. That is fine and we should acknowledge this. and not prevent it, thank you. > But it is also not helpful to just assert "it works in practice" > without acknowledging that there are real dangers when used > inappropriately. i.e., the "it" needs to be qualified, as not all > "its" will work equally well. sure. as many weasel words as folk need, within reason. but don't code against it in routers, hosts, ... randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 17:07:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T07E40005812 for ; Tue, 28 Aug 2001 17:07:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T07E5W005811 for ipng-dist; Tue, 28 Aug 2001 17:07:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T07A40005804 for ; Tue, 28 Aug 2001 17:07:10 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10036 for ; Tue, 28 Aug 2001 17:07:18 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18380 for ; Tue, 28 Aug 2001 17:07:17 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 17:06:29 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id C1085DDFDB5C4F4FA5CD66C1572D4412 for plus 5 more; Tue, 28 Aug 2001 17:06:28 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" Cc: "Keith Knightson" , "Christian Huitema" , "Bob Hinden" , "Alex Conta" , "ipng" Subject: RE: a), b), c), d), or e) Date: Tue, 28 Aug 2001 17:06:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C0C49.432F59FF@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 86C8080E-FF3541AD-ADE21827-9A76E450 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7T07B40005805 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter wrote: > This is a very unfair comment. Diffserv is just fine in the > case of unencrypted traffic. It has a problem (and so does > intserv I suspect) with tunnel or transport mode ESP. But that is the point. If IPsec had been widely deployed in the IPv4 Internet, diffserv would have been forced to fix the DSCP end-to-end, because that would be the only alternative. > No it doesn't. They should be set at source. (But anyway, why > would it matter if they are mutable, since they aren't covered > by checksum? I'm not aware of a law of nature against mutable bits.) Speak to your co-author who keeps insisting that they are mutable. In any case, the point is that for diffserv to work there has to be a visible set of bits that are immutable end-to-end with well-known semantics. Currently that is the protocol/port, simply because ESP wasn't in widespread use. In IPv6 we assume it will be, so diffserv needs another set of bits that have an immutable well-known end-to-end semantic. > No, that is in fact what we did, but at the specific insistence > of the ISPs active in the design of diffserv, we made all of > the mappings SHOULD instead of MUST. You want to ding the WG > for meeting a clearly stated key requirement of the principal > customer set? In this case yes, because that requirement results in an inoperable state when security is applied. RFC 2475 starts the discussion about IPsec interactions, but only from the perspective of protecting the DSCP. It misses the point that when ESP is in use there is no visible set of bits to base decisions on for each domain to set the DSCP. The only set of bits there is left to work with is the SPI, and the semantics of that are only known between the endpoints unless signalled via RSVP. > Products work just fine the way things are. In fact that is a false statement because those products can't work today if one tries to use an encrypted channel. > Immutablity isn't the problem. Encryption of the port and protocol > numbers is the problem. I could equally well say that IPSEC should > go back and fix the invisibility problem they created. That is a specific feature. There are many times when you don't want traffic analysis done on the ports in use and number or sequence of packets between them. > What I am actually > saying is that this WG should go back and fix the ambiguity problem > created by the Appendix to RFC 2460. No argument, but the only ambiguity I see is the comment about control protocols. The rest of the text is very clear. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 17:27:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T0RO40005831 for ; Tue, 28 Aug 2001 17:27:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T0ROEw005830 for ipng-dist; Tue, 28 Aug 2001 17:27:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T0RK40005823 for ; Tue, 28 Aug 2001 17:27:20 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01335 for ; Tue, 28 Aug 2001 17:27:29 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26489 for ; Tue, 28 Aug 2001 17:27:28 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 17:26:55 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 5832BA02B498495F9FEC30E8485ACE6C for plus 2 more; Tue, 28 Aug 2001 17:26:55 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" Cc: "Alex Conta" , Subject: RE: Higher level question about flow label Date: Tue, 28 Aug 2001 17:26:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C0E9C.13CDB728@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 0E805E16-FF294F68-8DA63121-A5EC046F Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7T0RL40005824 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Please don't use this kind of language. As I just said on the other > thread, diffserv reached consensus (in 1998) on a completely self- > consistent model meeting the key requirements stated by ISPs. I did not mean to be inflammatory, I was just reacting to the statement by Alex about what we can afford to do at this point in time. While the diffserv WG has a self-consistent model, it is incomplete and in fact unworkable in the presence of IPsec and multiple domains. > What on earth do you mean? The DSCP to PHB mapping is configured, > but there is nothing random involved. >From an end-to-end perspective it is completely random. Yes there is structure within each domain, but there is no way to predict how each provider will set those bits, so one provider can't use the settings from another as a basis for decisions. > Again, it isn't a question of "refuses". See above. I understand there was a contingent of the WG that insisted on the current behavior, but in doing so they created a situation where the WG refused to make static mappings for those bits a MUST. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 17:42:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T0ga40005853 for ; Tue, 28 Aug 2001 17:42:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T0gaTJ005852 for ipng-dist; Tue, 28 Aug 2001 17:42:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T0gX40005845 for ; Tue, 28 Aug 2001 17:42:33 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03201 for ; Tue, 28 Aug 2001 17:42:42 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01585 for ; Tue, 28 Aug 2001 17:42:41 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 17:42:11 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id D577D625D9A2411DB79DA1D54A99D52F for plus 1 more; Tue, 28 Aug 2001 17:42:11 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" Cc: Subject: RE: Higher level question about flow label Date: Tue, 28 Aug 2001 17:42:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C1361.A0875668@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: BEAC639E-FB194C1B-B131D835-831641D6 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7T0gX40005846 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > > and is finding that it can't get the job done without > taking over another field > > with imutable properties. > > It can get the job done, but less efficient than in IPv4, and that is > not because > work done by the Diffserv WG. In fact, diffserv can't get the job done across multiple domains in the presence of ESP. There simply are no visible bits with well-known semantics to base the decisions on. Allowing the DSCP to be mutable was explicitly the work of the diffserv WG, and therein lies the reason you are looking for another set of immutable bits. > Ad absurdum, if the routers in a domain, do not know, or there is no > mechanism to know, > but they can have a use of a mutable flow label, then they would work > together, and have the egress restore the original value when packets > leave the domain. Talk about ambiguity, what is the point of rewriting the flow label only to restore it later? Even if you wanted to, where is the protocol that communicates the value from edge to edge? > That working group does not standardize the IPv6 headers. They wrote RFC 2474 didn't they. As far as I can tell that means they are responsible for the content of the TS field. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 18:07:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T17d40005895 for ; Tue, 28 Aug 2001 18:07:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T17dXG005894 for ipng-dist; Tue, 28 Aug 2001 18:07:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T17Z40005887 for ; Tue, 28 Aug 2001 18:07:35 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18515 for ; Tue, 28 Aug 2001 18:07:44 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10419 for ; Tue, 28 Aug 2001 18:07:43 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 18:07:39 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 6E20F375A054459EAB9525B7BE34683D for plus 1 more; Tue, 28 Aug 2001 18:07:39 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" Cc: Subject: RE: Higher level question about flow label Date: Tue, 28 Aug 2001 18:07:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C1148.C93C4BC5@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 13806C88-2E764BD1-B6197DD2-344672C3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7T17Z40005888 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > There is RFC2996 to fix this problem... > > That only works up to the first diffserv domain on the traffic path. > As the packets enters a 2nd, 3rd etc. diffserv domain, the problem > reappears. By the way, the absence of signalling is a virtue, not a > problem, from the scaling viewpoint. The absence of signalling is not the virtue, limiting the points where the signalling is interpreted is. Removing signalling explicitly kills any hope that the endpoint is capable of expressing its willingness to pay for enhanced services. Basically there can't be a sustainable QoS business model that is strictly based on diffserv, because the person with the cash has no means to control which packets get which level of service. The whole diffserv effort was so overbiased by the provider viewpoint of limiting abuse that it forgot that there has to be some means for the originator to state intent and see value in return. > Because the diffserv architecture requires the option to > reclassify traffic, because that's what the ISPs say they need. But have they got any paying customers for that service? Or for that matter any hope of having any? > I don't like the word "usurp". If the flow label was already > standardised and in habitual use, it would be appropriate, > but then we wouldn't be having this conversation anyway. Since > it is not standardised, there is nothing to usurp. I will grant you that we have no Standards in this space, but to the status of 2460 I believe it is standardized as: A flow label is assigned to a flow by the flow's source node. New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF hex. All packets belonging to the same flow must be sent with the same source address, destination address, and flow label. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 18:18:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T1I840005927 for ; Tue, 28 Aug 2001 18:18:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T1I8uh005926 for ipng-dist; Tue, 28 Aug 2001 18:18:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T1I240005919 for ; Tue, 28 Aug 2001 18:18:03 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24173 for ; Tue, 28 Aug 2001 18:18:12 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13713 for ; Tue, 28 Aug 2001 18:18:11 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 18:17:38 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 82DC907FF89449FCACD6E1D7D7FC8857 for plus 2 more; Tue, 28 Aug 2001 18:17:37 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" Cc: "Brian E Carpenter" , "ipng" Subject: RE: a), b), c), d), or e) Date: Tue, 28 Aug 2001 18:17:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C1667.3F9F260D@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 167E4AC7-6CAB4F1E-8E864372-A620E0AC Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7T1I440005920 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > I hate to say it, but your conclusion is grotesquely false. > The Diffserv QOS model is not broken at all - I don't know > how, where, and why you got that. How does it work if I am encrypting my traffic (independent of protocol version)? On top of that the diffserv model provides no control to the originator of the packets, and that is the source of the money which makes a business model work. Yes there is a technical definition for diffserv QoS, but there is no sustainable business and operational model which includes the source of the packets & money. A strict diffserv network is a providers fantasy land. There must be a mechanism for the endpoint to inject intent or there will be no reason to pay. > You assume that the flow label MUST be immutable, because you > base your > thinking on an absolute model. No, I base my thinking on the fact that for diffserv to work there has to be a visisble set of immutable bits with well-known end-to-end semantics. Otherwise each provider can't figure out which PHB is appropriate. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 18:15:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T1FN40005915 for ; Tue, 28 Aug 2001 18:15:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T1FMcH005914 for ipng-dist; Tue, 28 Aug 2001 18:15:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T1F940005907 for ; Tue, 28 Aug 2001 18:15:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19281 for ; Tue, 28 Aug 2001 18:15:19 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21007 for ; Tue, 28 Aug 2001 19:15:14 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id VAA24353; Tue, 28 Aug 2001 21:16:19 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id VAA14119; Tue, 28 Aug 2001 21:16:19 -0400 Message-ID: <3B8C425E.1D4E33C9@txc.com> Date: Tue, 28 Aug 2001 21:16:14 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Brian E Carpenter , Keith Knightson , Christian Huitema , Bob Hinden , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms4F4865D28917B5C778866761" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms4F4865D28917B5C778866761 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > > [...] (But anyway, why > > would it matter if they are mutable, since they aren't covered > > by checksum? I'm not aware of a law of nature against mutable bits.) > > Speak to your co-author who keeps insisting that they are > mutable. In any case, the point is that for diffserv to work there > has to be a visible set of bits that are immutable end-to-end > with well-known semantics. I do insist on the distinction between the bits in the field, and the meaning carried by the bits. So let me clarify this once more, for the last time. The bits in the field are mutable, they are "read/write". Checksum, and authentication skip them. It was very wise that the WG decided and did it so. The meaning of the Diffserv flow label bits is immutable. There seem to be a mixing of the two, and an insisting on the immutability of the bits, on your side. But I think in reality, you care about the immutability of the meaning of the bits. That is the essence, and one should not care of what happens with the bits, as long as the meaning is preserved, which is the point I am trying to get across, perhaps not clearly enough. I hope it is clearer now. > [...] . It misses the point that when ESP is in > use there is no visible set of bits to base decisions on for > each domain to set the DSCP. The only set of bits there is left > to work with is the SPI, and the semantics of that are only > known between the endpoints unless signalled via RSVP. > You are pointing to tunnel mode ESP, and not transport mode ESP. > > Products work just fine the way things are. > > In fact that is a false statement because those products can't > work today if one tries to use an encrypted channel. > > > Immutablity isn't the problem. Encryption of the port and protocol > > numbers is the problem. I could equally well say that IPSEC should > > go back and fix the invisibility problem they created. > Brian refers to transport mode ESP. > [...] > Tony Alex --------------ms4F4865D28917B5C778866761 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjkwMTE2MTZaMCMGCSqGSIb3DQEJBDEWBBTP1ZKQ8nH40aD/+CHn PlVIpJIgGzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gLRUE4lh9qfRvXOcYc6IwnM9CI+ofEa1HZXeQgk3wHzDTkxk1V7EEn2YAXaXBL1varmU/NJG LAPZ+JIxbNK48JsTkqfHg/Uo3GieexMXAwXMo/QWaZkZzTmCzK3LtmXQEAkou4Q8nD7E4vY4 O+CeKhynXiQJnDKW3wxmrmNkQ+We --------------ms4F4865D28917B5C778866761-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 18:26:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T1QE40005967 for ; Tue, 28 Aug 2001 18:26:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T1Q8YR005966 for ipng-dist; Tue, 28 Aug 2001 18:26:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T1Q340005959 for ; Tue, 28 Aug 2001 18:26:04 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24891 for ; Tue, 28 Aug 2001 18:26:13 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA16094 for ; Tue, 28 Aug 2001 18:26:12 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 18:25:35 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 914F2CC0F8D642859E2F493D52733984 for plus 5 more; Tue, 28 Aug 2001 18:25:35 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" Cc: "Brian E Carpenter" , "Keith Knightson" , "Christian Huitema" , "Bob Hinden" , "ipng" Subject: RE: a), b), c), d), or e) Date: Tue, 28 Aug 2001 18:25:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C425E.1D4E33C9@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 4A1A9BF2-6BEF4559-B0F4DFF5-855FB0E9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7T1Q540005960 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > The bits in the field are mutable, they are "read/write". ... > The meaning of the Diffserv flow label bits is immutable. This makes no sense... Those are the same bits, so they have to be one or the other. Since you are promoting a diffserv usage, I have to assume you intend them to be immutable end-to-end with a well known semantic, but you keep insisting they are mutable. As long as the TC field is mutable, there has to be another one that is visible and immutable. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 18:48:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T1mO40005995 for ; Tue, 28 Aug 2001 18:48:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T1mOCq005994 for ipng-dist; Tue, 28 Aug 2001 18:48:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T1mJ40005987 for ; Tue, 28 Aug 2001 18:48:19 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07826 for ; Tue, 28 Aug 2001 18:48:29 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22548 for ; Tue, 28 Aug 2001 18:48:28 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Tue, 28 Aug 2001 18:48:21 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id E36FBDFBA9C340B4852D86DAFEF7D398 for plus 2 more; Tue, 28 Aug 2001 18:48:21 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" Cc: "Steve Blake" , Subject: RE: Higher level question about flow label Date: Tue, 28 Aug 2001 18:48:21 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C14A9.C63B5464@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 4863CB7E-611B443F-94837A77-D9D54950 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7T1mK40005988 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Preamble: this is getting pretty far away from the core of the debate. Actually I thought the threads were very focused on the topic. Do we need to redefine the FL field to allow diffserv to have an immutable field with well-known end-to-end semantics, or not? Since the diffserv WG didn't want to use the field it was given that way why should we give it part of another one? If those are not the core of the debate I am really confused. > I'd like the chairs to make some consensus calls, because > we are going round in circles. Since the conversation is not widespread this may help spark further input. > There is no request for a new mutable field. On the contrary, diffserv > classification needs something that is globally unique. I agree with you about what diffserv needs, but Alex keeps insisting that those bits remain mutable. If that happens diffserv will have two mutable fields and still won't work. > That's a *complete* mischaracterisation. It doesn't resemble an MPLS > tag in any shape or form. It's in the IP header becasue it is used to > drive schedulers for queues of IP packets. Both are a set of bits that only have context within an administrative domain, and both are used for identifying the outgoing packet queue in the router. The only difference is that one gets added and stripped off at every domain boundary, while the other is simply overwritten. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 28 19:35:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T2ZV40006047 for ; Tue, 28 Aug 2001 19:35:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T2ZVo9006046 for ipng-dist; Tue, 28 Aug 2001 19:35:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T2ZR40006039 for ; Tue, 28 Aug 2001 19:35:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02078 for ; Tue, 28 Aug 2001 19:35:31 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22240 for ; Tue, 28 Aug 2001 20:35:26 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id WAA25043; Tue, 28 Aug 2001 22:36:31 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id WAA15903; Tue, 28 Aug 2001 22:36:30 -0400 Message-ID: <3B8C5528.CE908DE@txc.com> Date: Tue, 28 Aug 2001 22:36:24 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2B7048488CD3C05B329DFA95" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms2B7048488CD3C05B329DFA95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > I did not mean to be inflammatory, I was just reacting to the statement > by Alex about what we can afford to do at this point in time. > Tony, I asked for clarifications. You didn't respond. I am sorry, in their absence, I would repeat again, what I said based on what I understood you saying, and you were quite vague in that sentence: I strongly believe, and am not the only one, please see earlier messages in the thread, packet forwarding and QoS processing in line cards on routers at wire speed is too critical to afford the use of flow label in the network layer header, to pass duplicate information from source to destination, that has no network layer meaning, or use in the network. Alex --------------ms2B7048488CD3C05B329DFA95 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjkwMjM2MjZaMCMGCSqGSIb3DQEJBDEWBBR8Rgcj1YiBkkLSXcnr VDGOQyPazzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gF94myRWqCTBUQlAcNH2Q/ip3wjs9s1KzCo7bSP0Wv9RVmXZCvmwQJ4ssmCKJxrDAmc2incB HA44ibUcgfQcEUOjPGRu2JA91OMMYKYsFMltsN1czgd6W5y8zk/08qyJUrjxwaVYEyALla04 s/zLcBwPK64Ooms5/mX0jrY7cwwm --------------ms2B7048488CD3C05B329DFA95-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 21:20:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T4KQ40006211 for ; Tue, 28 Aug 2001 21:20:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T4KQLo006210 for ipng-dist; Tue, 28 Aug 2001 21:20:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T4KM40006203 for ; Tue, 28 Aug 2001 21:20:22 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06300 for ; Tue, 28 Aug 2001 21:20:31 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05585 for ; Tue, 28 Aug 2001 21:20:30 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id AAA25831; Wed, 29 Aug 2001 00:21:31 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id AAA18287; Wed, 29 Aug 2001 00:21:30 -0400 Message-ID: <3B8C6DC3.57D7F95@txc.com> Date: Wed, 29 Aug 2001 00:21:23 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE64BD38159CDE9102EE146EF" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msE64BD38159CDE9102EE146EF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > Alex Conta wrote: > > In fact, diffserv can't get the job done across multiple domains in > the presence of ESP. There simply are no visible bits with well-known > semantics to base the decisions on. Allowing the DSCP to be mutable was > explicitly the work of the diffserv WG, and therein lies the reason you > are looking for another set of immutable bits. > I think you are talking about tunnel mode ESP, and Brian talks about transport mode ESP. Brian's reason to use the flow label is for M-F classification, with transport mode ESP. Ports and protocol ID, are encrypted, while BA classification, can still be done, since the DSCP is in clear. The tunnel mode ESP is a completely different beast, I have not looked at that in detail, since it is beyond the scope of the Carpenter/Conta proposal. > > Ad absurdum, if the routers in a domain, do not know, or there is no > > mechanism to know, > > but they can have a use of a mutable flow label, then they would work > > together, and have the egress restore the original value when packets > > leave the domain. > > Talk about ambiguity, what is the point of rewriting the flow label > only to restore it later? Even if you wanted to, where is the protocol > that communicates the value from edge to edge? > A model is there: MPLS label distribution, which includes RSVP-TE. > > That working group does not standardize the IPv6 headers. > > They wrote RFC 2474 didn't they. As far as I can tell that means they > are responsible for the content of the TS field. > > Tony Likely, Brian can answer this much better than I can, since I have not been involved in the Diffserv architecture work. To me it is simple: I see the IPv6 main header divided into functions for forwarding, and functions for QoS. The 8 bit TS is part of the QoS fields, and is the Diffserv BA classification field, similar between IPv4, and IPv6 - great similarity/compatibility achievement, from model, architecture, specifications, to implementation in devices, and practical use by providers, and providers' customers. The 20 bit flow label is also a QoS field, which up to the Carpenter/Conta proposal was a field defined normatively for QoS, and non-normatively for Intserv/RSVP. There is conceptual similarity between Intserv non-flow label based classifiers, and Diffserv M-F classifiers. Intserv classifiers can use the flow label, and so could the Diffserv M-F classifiers, in which case they would share the 20 bit space. It is late here, so please bear with me... You seem to see the problem in terms of bit allocation. You seem to say that the Diffserv architecture should accommodate all its functions in 8 bits for IPv6, because the TS is all that DIffserv would ever get, and that is because the 20 bits of the flow label, used by Intserv, are too precious to share with Diffserv. OK, so the alternative that you suggest, means to have the DIffserv WG rework a completely different Diffserv model, mechanisms, architecture, specifications which some are already on the standards track, IETF marketing, etc... for IPv6. This means dropping, the model, architecture, mechanisms, implementation similarity/compatibility between IPv6 and IPv4, and dropping the complete similarity or commonality of the user/provider, and provider/provider model between IPv4, and IPv6, and all the other implications. Is that what you really mean? Alex Alex --------------msE64BD38159CDE9102EE146EF Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjkwNDIxMjVaMCMGCSqGSIb3DQEJBDEWBBSZjTtGxEt8WP5Ss7ik Qx6W4+DLzTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gG+tocJvtTr8hjrsrS4CmYXgNcq3p80HDs/bFU3k25jap1e5U7WpLAiYu/M6Q+FOiPbMfLms 12pMD/2gKP8dh51ELw/I9uu+CexWkw8n99uJQOfYRmUgBQ+wqxKQrKWkRntHevLjGEssxUE1 aR632AoudyFPLZaERiLMt4wgCkZ3 --------------msE64BD38159CDE9102EE146EF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 22:00:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T50e40006274 for ; Tue, 28 Aug 2001 22:00:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T50dP6006273 for ipng-dist; Tue, 28 Aug 2001 22:00:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T50Z40006266 for ; Tue, 28 Aug 2001 22:00:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA26568 for ; Tue, 28 Aug 2001 22:00:45 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27665 for ; Tue, 28 Aug 2001 23:01:09 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id BAA26101; Wed, 29 Aug 2001 01:01:45 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id BAA19127; Wed, 29 Aug 2001 01:01:45 -0400 Message-ID: <3B8C7730.3DBE1742@txc.com> Date: Wed, 29 Aug 2001 01:01:36 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Brian E Carpenter , Keith Knightson , Christian Huitema , Bob Hinden , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msB6FE8BBE309FF072871FFC0B" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msB6FE8BBE309FF072871FFC0B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > Alex Conta wrote: > > > The bits in the field are mutable, they are "read/write". > ... > > The meaning of the Diffserv flow label bits is immutable. > > This makes no sense... Those are the same bits, so they have > to be one or the other. Since you are promoting a diffserv > usage, I have to assume you intend them to be immutable > end-to-end with a well known semantic, but you keep insisting > they are mutable. As long as the TC field is mutable, there > has to be another one that is visible and immutable. > > Tony > Let's take an example. Let's say flow label value 50, is RT traffic between A and B. C, D, and E are routers between A, and B. Between A, and C, the RT traffic to B, has flow label 50. At router C, the value of 50 changes to 60, and it stays that way, to E, where it is changed back from 60 to 50. Between C and E, the meaning was the same, as between A, and C, and E, and B, that is the RT traffic between A and B. The flow label bits were mutable, the meaning was immutable. Alex --------------msB6FE8BBE309FF072871FFC0B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjkwNTAxMzlaMCMGCSqGSIb3DQEJBDEWBBQWzNajpBJlnM5ti3pu 93rNWHTnbDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gF7t5iTikZDcEOH57KNbaTpkVZDcTWzpdWWc/2bX57MH2vKIKvBBf68jDxiIb8yMF+T/m8ia bh377IN7neZU8TEJ+NmKBYpXiI7eZBJUTNqp73xhG164nZVYXRSVqN8SHeEDkAAGZaQqzSxR iIygeLTUxs2AMCiRu0uYItGYofOM --------------msB6FE8BBE309FF072871FFC0B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 28 22:08:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T58V40006293 for ; Tue, 28 Aug 2001 22:08:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T58VZA006292 for ipng-dist; Tue, 28 Aug 2001 22:08:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T58R40006285 for ; Tue, 28 Aug 2001 22:08:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25528 for ; Tue, 28 Aug 2001 22:08:37 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA17873 for ; Tue, 28 Aug 2001 22:08:36 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id BAA26157; Wed, 29 Aug 2001 01:09:38 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id BAA19289; Wed, 29 Aug 2001 01:09:38 -0400 Message-ID: <3B8C7908.49EB0E4@txc.com> Date: Wed, 29 Aug 2001 01:09:28 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE6E17D7B680FD14FEF5204B4" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msE6E17D7B680FD14FEF5204B4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > > How does it work if I am encrypting my traffic (independent of > protocol version)? In transport mode ESP, the BA part works, in fact better than Intserv. The MF part has the same issues as Intserv. In tunnel mode ESP, the MF Diffserv and Intserv face both the same problems. So it would seem that both Intserv, and Diffserv face problems with ESP, and so no QoS model gets a free ride, except Diffserv BA with transport mode ESP. > [...] A strict diffserv network is a > providers fantasy land. There must be a mechanism for the > endpoint to inject intent or there will be no reason to pay. > There is little experience with IP QoS billing. But how about FR and ATM services, where PVCs do not give users any more control than Diffserv, and various levels of QoS and billing are available. How about Internet access networks. A billing model existed and worked, when the Internet access was based on analog modems, and you had the choice between per minute charge or unlimited service charge. It works today when some of the Internet access is done with DSL, or Cable. There is a basic, simple SLA/TCA, and the users pay today a basic monthly fee. I see no reason, why that would not work with Diffserv, with a few QoS levels, and policing, and shaping, which would not be different conceptually from the FR or ATM model. > [..] > No, I base my thinking on the fact that for diffserv to work > there has to be a visisble set of immutable bits with well-known > end-to-end semantics. Otherwise each provider can't figure out > which PHB is appropriate. > > Tony > What you are saying is absolutely right. --------------msE6E17D7B680FD14FEF5204B4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjkwNTA5MzFaMCMGCSqGSIb3DQEJBDEWBBTgG137dRBH+R8pXGG9 c2rkEUi1cDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gA6l9CXk8SET3iELQXJOZfPt/vtnikcBR2beGRxZVK6n55hr8CAPdmIQsvpxXvAXv25DUHdT sl/2FuytzHLD5mQjJMhhnw0E+MEt/D1QuGL/DWNyPWfTrB/5liDVK7d3SxwCwXPlSFVMjj82 ax2yT+CnNoLi/Thpa24ugfGcdo8X --------------msE6E17D7B680FD14FEF5204B4-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 00:48:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T7m740006371 for ; Wed, 29 Aug 2001 00:48:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T7m7oU006370 for ipng-dist; Wed, 29 Aug 2001 00:48:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T7m340006363 for ; Wed, 29 Aug 2001 00:48:03 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09822 for ; Wed, 29 Aug 2001 00:48:01 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14352 for ; Wed, 29 Aug 2001 00:48:00 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7T7pqG01450 for ; Wed, 29 Aug 2001 10:51:53 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Aug 2001 10:47:53 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV9QDN>; Wed, 29 Aug 2001 10:46:53 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FF3@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com Cc: kre@munnari.OZ.AU, aconta@txc.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 10:46:40 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > jarno.rajahalme@nokia.com wrote: > > > > Robert, > > > > Very well put! Just some additional thoughts: > > > > - If diffserv WG so wants, it can even define a specific > (standard) DSCP > > value to be used between domains to signify that the flow > label in the same > > IP header has "diffserv semantics". This way the > classification could be > > done the same for all source addresses (otherwise ingress > router would need > > to know which source addresses use diffserv semantics for > the flow label?). > > That's an interesting thought, but I think it doesn't work. > The egress router > has to *know* that the flow label is in diffserv format, and > I think that > requires some magic. > Wouldn't the absence of intserv state for the flow at the domain egress be the magic for this determination? A related question: Flow label field is presumably end-to-end, i.e. non-mutable. How can some random diffserv domain egress router know if the flow label value should be honored or not (even if it had a specific format for the PHB-ID)? > > > > - If there is a diffserv relationship between a client and > an ISP, the > > client could still use intserv for select flows by doing > intserv signaling, > > which would explicitly tell the ISP that the associated > flow label does not > > have any diffserv semantics. > > Only for unencrypted traffic I think? The problem case is > encrypted traffic, > where all you can "see" are the IP addresses and the flow > label. I think the > intserv flow spec will be insufficient in that case. > I thought the current definition of the MF-classifier in intserv would allow usage of the flow label field for classification. At least this has been the whole function of the flow label: to enable flow classification based on the IPv6 header data only (e.g. even in the non-encrypted case IPv6 transport headers should NEVER be used for flow classification). If the flow label is not part of the intserv classifier specs, then maybe we need to revisit RSVP (RSVPv6?). Or perhaps the starting NSIS work will make this happen? 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 Aug 29 01:02:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T82140006431 for ; Wed, 29 Aug 2001 01:02:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7T821FX006430 for ipng-dist; Wed, 29 Aug 2001 01: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7T81v40006423 for ; Wed, 29 Aug 2001 01:01:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12629 for ; Wed, 29 Aug 2001 01:02:06 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09258 for ; Wed, 29 Aug 2001 01:02:05 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7T861G08227 for ; Wed, 29 Aug 2001 11:06:01 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Aug 2001 11:02:01 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV9RA4>; Wed, 29 Aug 2001 11:01:31 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FF4@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com Cc: alh-ietf@tndh.net, hinden@iprg.nokia.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 11:01:12 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > jarno.rajahalme@nokia.com wrote: > > > > Now that I read the draft-conta-ipv6-flow-label-02.txt > again in the context > > of this discussion, few remarks: > > > > - The draft discusses "diffserv MF-classifier" use for the > flow label, while > > what really is proposed is a diffserv behavior aggregate > (BA) classification > > based on standard, non-mappable PHB identifiers. Since DSCP > is mappable to a > > local convention (for whatever political reasons), now the > flow label is > > proposed to replace the DSCP field on the domain boundaries. > > Exactly, since it can convey e2e semantics from the source. > > > > > - RFC 3140 defines PHB-ID as 16 bits, out of which 6 bits > are used in the > > "standards action" defined PHBs. These 6 bits are the > recommended bits for > > the DSCP field by the PHB definition (that can be mapped locally to > > different set of bits). If there is no local mapping (but > the domain routers > > are configured to understand and use the recommended DSCP > values for each > > supported PHB), the 6 bits in the PHB-ID are the same as > the 6 bits in the > > DSCP in the Traffic Class field. The other variant > (*experimental* and > > *local use*, e.g. intra-domain) use more of the 16 bits. > > Correct. The idea was that people could register PHB IDs with IANA to > go beyond the formally standardized ones. > > > > > - Since the PHB-ID carries only 6 bits of information > between diffserv > > No, the DSCP is limited to 6 bits; the PHB-ID has a full 16 bits. > The mapping to DSCP is a decision made by the classifier in an ingress > border router. > My precise point was that *between domains* PHB-ID carries 6 bits of information only (the standardized DSCP values). Any *local use* values would not be used inter-domain, and any *experimental* value usage would need bilateral agreements (perhaps as part of the SLAs), so for this info (mapping from an *experimental* PHB-ID to the actual behavior definition) an out-of-band signaling method (online or offline) exists already. > > domains, it would seem entirely reasonable, that at > diffserv domain egress, > > all DSCPs are mapped to the equivalent recommended DSCP > values, that will > > then be understood by the receiving diffserv domain. > > It might be reasonable, but we can't assume it. This depends entirely > on the SLA between the two ISPs concerned and is a business decision. > Hopefully the SLAs specify what treatment should be given to which packets. It is not up to IETF to standardize redundant technologies just because a "business decision says so". In my opinion, you have not yet shown a convincing scenario, where the proposed behavior aggregate usage of the IPv6 flow label field actually provides something we don't already have. You should provide a concrete example showing the relationships between the operators, who marks what (end-to-end/hop-by-hop), how the traffic is policed etc. > > The egress could base > > the mapping to whatever MF-classification or just map from > locally used > > DSCPs. > > > > So, as an alternative to make the IPv6 flow label NOT > identify flows, I'd > > propose the diffserv WG to specify that (for IPv6) a > diffserv domain MUST > > remark the DSCP value of the Traffic Class field at egress > to use the > > PHB-definition recommended ("standards action") DSCP value, > including the > > case that *local use* or *experimental* PHBs are mapped to > the default PHB > > ('000000') at domain egress. Let's add to the end. "If a bilateral SLA doesn't state otherwise." > > Impossible. This is not something the IETF can mandate, and > in particular ISPs > are free to implement non-standard PHBs (e.g. multiple > independent implementations > of EF, or more than four AF classes, or some proprietary PHB). The whole discussion has been for the case *between operators*, or have I missed something. With my amendment above, the above can easily be mandated by IETF. The main motivation for any standardization is interoperability. IMO what I said above would just facilitate interoperability (in case the operators don't know better). > > > > In addition to more efficient classification and policing > on the domain > > ingress, this could have a side effect of encouraging the > operators to > > actually use the recommended DSCP values intra-domain as well :-) > > This is not in our power. "encouraging" doesn't need too much power, just good will :-) 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 Aug 29 06:15:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TDFi40006751 for ; Wed, 29 Aug 2001 06:15:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TDFifl006750 for ipng-dist; Wed, 29 Aug 2001 06:15:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TDFK40006743 for ; Wed, 29 Aug 2001 06:15:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05576 for ; Wed, 29 Aug 2001 06:15:28 -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 HAA10494 for ; Wed, 29 Aug 2001 07:15:52 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA06755; Wed, 29 Aug 2001 22:15:02 +0900 (JST) Date: Wed, 29 Aug 2001 22:15:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <200108200915.f7K9F4l31391@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200108200915.f7K9F4l31391@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the delayed response, I'm just back from a vacation. >>>>> On Mon, 20 Aug 2001 11:15:04 +0200, >>>>> Francis Dupont said: > In your previous mail you wrote: >> => I prefer real names than xxxNNN. Can we get both (i.e. a config file >> plus a default translation rule)? > I do not object to introducing real names, but I'd like to leave that > part as implementation dependent, and just define the formal aliases > (like "link2") in the scope architecture draft. > => I don't understand your problem there: I prefer fe80::xxxx%eth0 to > fe80::xxxx%link12, I believe you too... Well, as a developer and a user of the KAME IPv6 stack, I prefer fe80::xxxx%eth0 to fe80::xxxs%link12. The implementation (at least currently) assumes one-to-one mapping between interfaces and links, which is natural in a normal operation, and thus eth0 should be more intuitive than link12. However, from a stricter architectural point of view, using interface names as link IDs can be rather confusing, because two different interfaces can belong to a single link. Also, the naming convention might differ among implementations. So, as a co-author of the scoping architecture draft, I'd rather stick to the artificial notation (i.e. "link10", "site5", etc) as the "official" textual representation, which will be described in the draft. Of course, each implementation may introduce more readable and more intuitive "names" (e.g. eth0) as zone IDs, based on its own naming convention. 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 Aug 29 06:25:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TDP540006802 for ; Wed, 29 Aug 2001 06:25:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TDP5C9006801 for ipng-dist; Wed, 29 Aug 2001 06:25:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TDP140006794 for ; Wed, 29 Aug 2001 06:25:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06347 for ; Wed, 29 Aug 2001 06:25:05 -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 HAA23263 for ; Wed, 29 Aug 2001 07:24:59 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA06807; Wed, 29 Aug 2001 22:24:54 +0900 (JST) Date: Wed, 29 Aug 2001 22:25:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy Brabson" Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 20 Aug 2001 08:01:20 -0400, >>>>> "Roy Brabson" said: >> > => I prefer real names than xxxNNN. Can we get both (i.e. a config > file >> > plus a default translation rule)? >> >> I do not object to introducing real names, but I'd like to leave that >> part as implementation dependent, and just define the formal aliases >> (like "link2") in the scope architecture draft. >> >> => I don't understand your problem there: I prefer fe80::xxxx%eth0 to >> fe80::xxxx%link12, I believe you too... > I also prefer eth0 over link12. Using the names used to define the zones > (either the default interface names or actual zone definitions) seems to be > more useful than generating a somewhat arbitrary name and displaying that. > How is the user supposed to correlate link12 back to the actual eth0 > interface, anyway? I imagine another external or display could be used, > but this would seem to introduce yet another step for a user to identify > the particular interface/zone in question. When we can assume one-to-one mapping between interfaces and links, that's true. However, if two (or more) different interfaces belong to a single link, using interface names as link IDs would be rather confusing (we'll lose the uniqueness of the ID, or we'll have to care about which interface is "primary" in the link".) As I said in a previous message, I do not necessarily object to using "names" as an implementation dependent convention. I just would like to stick to "link1" or "site5" in the official textual representation in the scoping architecture draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 07:26:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TEQM40006953 for ; Wed, 29 Aug 2001 07:26:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TEQL6O006952 for ipng-dist; Wed, 29 Aug 2001 07:26:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TEQG40006945 for ; Wed, 29 Aug 2001 07:26:16 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15230 for ; Wed, 29 Aug 2001 07:26:23 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28661 for ; Wed, 29 Aug 2001 07:26:21 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA07244; Wed, 29 Aug 2001 23:22:09 +0900 (JST) Date: Wed, 29 Aug 2001 23:22:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: set@thumper.bellcore.com, narten@raleigh.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: StoredLifetime in RFC 2462 User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a quick question about RFC2462 (stateless address autoconfiguration). I know we've had a similar discussion before, but please let me repeat it... The RFC defines the notion of "StoredLifetime" as follows: e) If the advertised prefix matches the prefix of an autoconfigured address (i.e., one obtained via stateless or stateful address autoconfiguration) in the list of addresses associated with the interface, the specific action to perform depends on the Valid Lifetime in the received advertisement and the Lifetime associated with the previously autoconfigured address (which we call StoredLifetime in the discussion that follows): In my understanding, StoredLifetime is the "remaining" lifetime to expiration at the time when the new Router Advertisement is received. So, for example, if we first received a prefix with the valid lifetime being 7200 seconds, and then received a next advertisement 1800 seconds later, the StoredLifetime corresponding to the address from the prefix should be 5400 (= 7200 - 1800) seconds. I believe this interpretation is correct, and I've implemented RFC 2462 in this manner. However, a user of our implementation said it was *not* what RFC2462 says, because > all "Lifetime associated with the address" pseudo-definitions are > very, very careful not to say the Lifetime is actually being > decremented. (cited the user's message) But is there any other interpretation of StoredLifetime? I'm now confused, so I'd like to hear authors' intention. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 07:25:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TEPl40006943 for ; Wed, 29 Aug 2001 07:25:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TEPknR006942 for ipng-dist; Wed, 29 Aug 2001 07:25:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TEPh40006935 for ; Wed, 29 Aug 2001 07:25:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15154 for ; Wed, 29 Aug 2001 07:25:50 -0700 (PDT) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05890 for ; Wed, 29 Aug 2001 08:25:44 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA45926; Wed, 29 Aug 2001 09:23:35 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7TEPkH259050; Wed, 29 Aug 2001 10:25:46 -0400 Subject: Re: Wrap up and last call: sin6_scope_id semantics To: JINMEI Tatuya / =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Wed, 29 Aug 2001 10:25:34 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/29/2001 10:25:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, 08/29/2001 at 10:25 ZE9, JINMEI Tatuya / $B?@L@C#:H(B wrote: > > I also prefer eth0 over link12. Using the names used to define the zones > > (either the default interface names or actual zone definitions) seems to be > > more useful than generating a somewhat arbitrary name and displaying that. > > How is the user supposed to correlate link12 back to the actual eth0 > > interface, anyway? I imagine another external or display could be used, > > but this would seem to introduce yet another step for a user to identify > > the particular interface/zone in question. > > When we can assume one-to-one mapping between interfaces and links, > that's true. However, if two (or more) different interfaces belong > to a single link, using interface names as link IDs would be rather > confusing (we'll lose the uniqueness of the ID, or we'll have to care > about which interface is "primary" in the link".) True, if two interfaces are in the same link-local zone then the interface name will not uniquely identify the zone. But the current scoping architecture draft indicates that configuration is required to identify that two interfaces are in the same zone, and the name used in this configuration can be used for display of the zone name. > As I said in a previous message, I do not necessarily object to using > "names" as an implementation dependent convention. I just would like > to stick to "link1" or "site5" in the official textual representation > in the scoping architecture draft. I would prefer to use the textual representation which matches what is used in configuring the zones. It just makes more sense to echo back what a user placed in a configuration file instead of displaying an arbitrary value dynamically created by a given stack. How exactly would a user correlate an arbitrary value such as "link1" or "site5" to the given zone which they want to use, anyway? This would seem to be the equivalent of telling a user they need to "guess" the correct interface ID without proving if_nametoindex() to perform the translation of the configured interface name to the corresponding interface ID. Roy Brabson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 08:18:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TFIi40007139 for ; Wed, 29 Aug 2001 08:18:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TFIiYU007138 for ipng-dist; Wed, 29 Aug 2001 08:18:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TFIe40007131 for ; Wed, 29 Aug 2001 08:18:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22487 for ; Wed, 29 Aug 2001 08:18:42 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19764 for ; Wed, 29 Aug 2001 08:18:41 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7TFD2i26136; Wed, 29 Aug 2001 18:13:02 +0300 Date: Wed, 29 Aug 2001 18:13:02 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: , , Subject: Re: StoredLifetime in RFC 2462 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 29 Aug 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > I have a quick question about RFC2462 (stateless address > autoconfiguration). I know we've had a similar discussion before, but > please let me repeat it... > > The RFC defines the notion of "StoredLifetime" as follows: > > e) If the advertised prefix matches the prefix of an autoconfigured > address (i.e., one obtained via stateless or stateful address > autoconfiguration) in the list of addresses associated with the > interface, the specific action to perform depends on the Valid > Lifetime in the received advertisement and the Lifetime > associated with the previously autoconfigured address (which we > call StoredLifetime in the discussion that follows): > > In my understanding, StoredLifetime is the "remaining" lifetime to > expiration at the time when the new Router Advertisement is received. > So, for example, if we first received a prefix with the valid lifetime > being 7200 seconds, and then received a next advertisement 1800 > seconds later, the StoredLifetime corresponding to the address from > the prefix should be 5400 (= 7200 - 1800) seconds. > > I believe this interpretation is correct, and I've implemented RFC > 2462 in this manner. However, a user of our implementation said it > was *not* what RFC2462 says, because Well, this is the only interpretation that works with lifetimes less than 7200, which (partially) triggered the "Jim Bound rule" (Date: Sun, 08 Nov 1998 10:57:59 -0500) thread in the first place. So, it's obviously the "right" interpretation. But is it what it actually says? Wording is IMO very ambiguous: > Lifetime > associated with the previously autoconfigured address (which we > call StoredLifetime in the discussion that follows): The name StoredLifetime implies it's stored once, not decremented. Why else would there even be need for 'StoredLifetime', why just use 'Lifetime' there? 'Lifetime associated with the previously autoconfigured address', autoconfigured hints at static ValidLifetime, there is no clear definition of Lifetime, much less the whole deal. And: IPv6 addresses are leased to an interface for a fixed (possibly infinite) length of time. Each address has an associated lifetime that indicates how long the address is bound to an interface. When a lifetime expires [...] Lifetime is originally derived from advertised ValidLifetime, which is not decremented but updated. This doesn't specify whether variable "Lifetime" is really a decrementing timer or only a value, which is updated by advertisements, _and_ having separate timer decrementing that. As above, you can deduce the intention there if you think about it, but again, I'm not sure that's what the spec _exactly_ says. (yeah, it was my message :-) Speaking of which, would it soon be time to move ND/autoconf forward, and at the same time, clarify the text? -- 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 Aug 29 09:29:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TGTH40007274 for ; Wed, 29 Aug 2001 09:29:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TGTHNr007273 for ipng-dist; Wed, 29 Aug 2001 09:29:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TGT840007266 for ; Wed, 29 Aug 2001 09:29:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07415 for ; Wed, 29 Aug 2001 09:29:16 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA01215 for ; Wed, 29 Aug 2001 10:29:40 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Aug 2001 09:29:01 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 09:29:01 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 09:29:01 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 09:28:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 09:28:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a), b), c), d), or e) Thread-Index: AcEwCiO9oL0yHcdLTtSfwX5xmg7hZQAnABRA From: "Christian Huitema" To: "Brian E Carpenter" , Cc: "ipng" X-OriginalArrivalTime: 29 Aug 2001 16:28:39.0285 (UTC) FILETIME=[A8CE5250:01C130A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TGTE40007267 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > There are no stupid questions. Some of the pushback is > > simply based on the fact that the diffserv model of QoS > > is inherently broken because there is no end-to-end > > immutable set of bits for local decisions to be based on. > > This is a very unfair comment. Diffserv is just fine in the > case of unencrypted traffic. It has a problem (and so does > intserv I suspect) with tunnel or transport mode ESP. ESP is just one of the cases in which "looking at the port numbers" does not provide sufficient information to make an informed decision. There are many examples that do not involve ESP, e.g. an audio stream can carry different levels of hierarchical encoding on successive ports, an HTTP transaction can carry a medical transaction just as well as recreational content, a file transfer may be a virus update or a virus propagation. At some point, the classification decision has to rely on information provided by the source. In fact, there is no contradiction between the "immutable" requirement that Tony is advocating and Brian's "diffserv handle" requirement. In the diffserv model, the actual classification is based on the 6 classifier bits; there is no context that this can be mutable, since ISPs must be authorized to reclassify traffic. The reclassification is based on information carried in the packet, part of which is the label affixed by the source; making that label immutable is a good thing, since it prevents intermediaries from removing the information that can be used by a downstream router. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 09:36:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TGat40007315 for ; Wed, 29 Aug 2001 09:36:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TGatFX007314 for ipng-dist; Wed, 29 Aug 2001 09:36:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TGap40007307 for ; Wed, 29 Aug 2001 09:36:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22768 for ; Wed, 29 Aug 2001 09:37:00 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00862 for ; Wed, 29 Aug 2001 10:36:55 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f7TGb2N13821; Wed, 29 Aug 2001 09:37:02 -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 AAP35757; Wed, 29 Aug 2001 09:36:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA22322; Wed, 29 Aug 2001 09:36:49 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15245.6689.284979.158207@thomasm-u1.cisco.com> Date: Wed, 29 Aug 2001 09:36:49 -0700 (PDT) To: Brian E Carpenter Cc: alh-ietf@tndh.net, Bob Hinden , Alex Conta , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B8B9F35.E4327BB4@hursley.ibm.com> References: <3B8B9F35.E4327BB4@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry if this is redundant; it's been a hard thread to keep up with. Brian E Carpenter writes: > > There is absolutly no reason to tie the > > Flow Label field and the Traffic Class field together, which is > > the only point of defining diffserv semantics for the Flow Label. > > No, the point is to provide partial replacement of the {port, protocol} > semantics that are hidden by ESP. There is no tying together of > Traffic Class and Flow Label. They remain orthogonal. I've got what may be a pertinent question: do the re-classifiers require actual knowledge of the contents of the encrypted headers, or do they just require the ability to differentiate the unique flows associated with a particular DSCP? If it's the former, I think I object to requiring a node to _have_ to reveal information (quite valuable information, if you consider it) in order to obtain QoS. At the very least, how is a non-signaled diffserv host to know whether it should or should not insert the revealing information into the flow label? If the answer is that it always has to do that, you have effectively defeated one of the useful protections of ESP. This would be very bad. > > The set of packets identified as a > > flow will be the same with either QoS mechansim, so why is there > > a need to have distinct semantics unless someone in the middle wants > > to interpret them? > > Diffserv is blind to microflows; there is no flow identification. > However, diffserv classifiers in the middle *do* need to (re)interpret > packet headers. That is how diffserv works. I'm afraid that this makes no sense at all. A microflow is nothing more than a tuple made up of some set of fields in the packet. If part of the protocol(s) takes some action based on that tuple, I'd say that it is certainly microflow aware, unless you add to the definition that a microflow also requires saved state in the router too. Even with that restriction, you are merely drawing the slim difference between frozen uflow classifer state (eg, provisioned ACL's...) vs. dynamic classifer state (ala intserv). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 10:01:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TH1U40007358 for ; Wed, 29 Aug 2001 10:01:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TH1Uen007357 for ipng-dist; Wed, 29 Aug 2001 10:01:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TH1Q40007350 for ; Wed, 29 Aug 2001 10:01:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27603 for ; Wed, 29 Aug 2001 10:01:34 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14347 for ; Wed, 29 Aug 2001 10:01:34 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7TH1PH16045; Wed, 29 Aug 2001 10:01:25 -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 AAP36520; Wed, 29 Aug 2001 10:01:04 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA22328; Wed, 29 Aug 2001 10:01:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15245.8143.962122.748253@thomasm-u1.cisco.com> Date: Wed, 29 Aug 2001 10:01:03 -0700 (PDT) To: Alex Conta Cc: alh-ietf@tndh.net, Brian E Carpenter , Keith Knightson , Christian Huitema , Bob Hinden , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B8C425E.1D4E33C9@txc.com> References: <3B8C425E.1D4E33C9@txc.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 Alex Conta writes: > . It misses the point that when ESP is in > > use there is no visible set of bits to base decisions on for > > each domain to set the DSCP. The only set of bits there is left > > to work with is the SPI, and the semantics of that are only > > known between the endpoints unless signalled via RSVP. > > > > You are pointing to tunnel mode ESP, and not transport mode ESP. Wrong. Everything at L4+ is encrypted with transport mode ESP. The only difference between tunnel and transport is the visibility of the inner IP addresses. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 10:05:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TH4x40007388 for ; Wed, 29 Aug 2001 10:04:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TH4x36007387 for ipng-dist; Wed, 29 Aug 2001 10:04:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TH4t40007380 for ; Wed, 29 Aug 2001 10:04:56 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28342 for ; Wed, 29 Aug 2001 10:05:04 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27916 for ; Wed, 29 Aug 2001 10:05:04 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7TH55l13088; Wed, 29 Aug 2001 10:05:05 -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 AAP36616; Wed, 29 Aug 2001 10:04:32 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA22331; Wed, 29 Aug 2001 10:04:32 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15245.8351.839546.109577@thomasm-u1.cisco.com> Date: Wed, 29 Aug 2001 10:04:31 -0700 (PDT) To: Brian E Carpenter Cc: Bob Hinden , Alex Conta , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B8C07D6.E3C6F7B1@hursley.ibm.com> References: <4.3.2.7.2.20010816152757.021a4020@mailhost.iprg.nokia.com> <4.3.2.7.2.20010827111610.0225c1b8@mailhost.iprg.nokia.com> <4.3.2.7.2.20010828100846.02328ed0@mailhost.iprg.nokia.com> <3B8C07D6.E3C6F7B1@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Bob Hinden wrote: > > > .. > > I think you are going a bit far to suggest that the fate of Diffserv > > depends on what the IPv6 w.g. does with the flow label field. I suspect > > that Diffserv will live or die based on IPv4 usage. Also, as IPv6 is > > deployed much of it will be initially carried over IPv4. Any QoS solution > > that is going to be end-to-end will have to deal with a mix of native IPv6 > > and IPv4/IPv6 headers. > > Indeed, and since I don't quite see how IPSEC and NAT-PT are going to > work together, the need that triggered this discussion (the need to > classify ESP packets in the middle of the Internet) really doesn't arise > in the case of translated packets. The concern is for a native IPv6 environment. The current proposed lossage involves ESP over UDP. In fact, that would probably provide you with what you need for both v4 and v6. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 10:06:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TH6040007405 for ; Wed, 29 Aug 2001 10:06:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TH60af007404 for ipng-dist; Wed, 29 Aug 2001 10:06:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TH5u40007397 for ; Wed, 29 Aug 2001 10:05:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05225 for ; Wed, 29 Aug 2001 10:06:04 -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 LAA27115 for ; Wed, 29 Aug 2001 11:05:59 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA08151; Thu, 30 Aug 2001 02:05:56 +0900 (JST) Date: Thu, 30 Aug 2001 02:06:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy Brabson" Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 53 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 29 Aug 2001 10:25:34 -0400, >>>>> "Roy Brabson" said: >> When we can assume one-to-one mapping between interfaces and links, >> that's true. However, if two (or more) different interfaces belong >> to a single link, using interface names as link IDs would be rather >> confusing (we'll lose the uniqueness of the ID, or we'll have to care >> about which interface is "primary" in the link".) > True, if two interfaces are in the same link-local zone then the interface > name will not uniquely identify the zone. But the current scoping > architecture draft indicates that configuration is required to identify > that two interfaces are in the same zone, and the name used in this > configuration can be used for display of the zone name. I don't see such indication of the draft...which text of the draft do you really mean? > I would prefer to use the textual representation which matches what is used > in configuring the zones. It just makes more sense to echo back what a > user placed in a configuration file instead of displaying an arbitrary > value dynamically created by a given stack. How exactly would a user > correlate an arbitrary value such as "link1" or "site5" to the given zone > which they want to use, anyway? This would seem to be the equivalent of > telling a user they need to "guess" the correct interface ID without > proving if_nametoindex() to perform the translation of the configured > interface name to the corresponding interface ID. I admit that "link1" is not user-friendly. But please note that the textual representation described in the scoping architecture draft basically defines numerical zone IDs only, which are also "user-unfriendly". But the draft also allows implementations to introduce more intuitive, more user-friendly format such as interface names for links, assuming one-to-one mapping between interfaces and links. Since the notion of "names" can be different among implementations, I don't think the architecture draft should define the details of "names". The problem with the 4+28 split model, however, is that numerical identifiers would even annoy users (not just be user-unfriendly), because we'd see IDs like "1342177281" (which is 0x50000001, i.e. a site ID of site index 1). So, "site1" is just a readable alias for "1342177281", which is a different kind of notion from "names". Again, I don't oppose to introducing "names" in each implementation. However, I'd stick to the numerical identifiers and their aliases for readability, as the bottom line in the scoping architecture draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 10:10:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THA940007422 for ; Wed, 29 Aug 2001 10:10:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THA90h007421 for ipng-dist; Wed, 29 Aug 2001 10:10:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THA540007414 for ; Wed, 29 Aug 2001 10:10:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05959 for ; Wed, 29 Aug 2001 10:10:09 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00652 for ; Wed, 29 Aug 2001 11:10:04 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 10:09:38 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 8DC6342FE53A4269BE3C4843AB1EBC75 for plus 1 more; Wed, 29 Aug 2001 10:09:37 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" Cc: Subject: RE: Higher level question about flow label Date: Wed, 29 Aug 2001 10:09:37 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C5528.CE908DE@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: F88392CD-F5224AC4-89480C7E-B9286B91 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7THA640007415 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > I asked for clarifications. You didn't respond. > I am sorry, in their absence, I would repeat again, what > I said based on what I understood you saying, and you were quite vague > in that sentence: I thought I did respond. The use of the bits would only appear to be vague if a middle-box without context were looking at them. If you will recall the fundamental principle of the Internet is its end-to-end nature, so the fact that some bits only have meaning between the endpoints is not surprising. > I strongly believe, and am not the only one, please see > earlier messages > in the thread, packet forwarding and QoS processing in line > cards on routers at wire > speed is too critical to afford the use of flow label in the network > layer header, to pass duplicate information from source to > destination, > that has no network layer meaning, or use in the network. And there are probably more of us who strongly believe that there must be header bits that have immutable context from end-to-end. The network elements are not the drivers here, the endpoints are. If we allow the middle boxes to control our actions we end up with the POTS network, and loose the ability to deploy new and innovative applications. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 10:29:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THTj40007520 for ; Wed, 29 Aug 2001 10:29:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THTjQZ007519 for ipng-dist; Wed, 29 Aug 2001 10:29:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THTf40007512 for ; Wed, 29 Aug 2001 10:29:41 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09979 for ; Wed, 29 Aug 2001 10:29:50 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11874 for ; Wed, 29 Aug 2001 10:29:46 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA67106; Wed, 29 Aug 2001 12:27:31 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97) with ESMTP id f7THTgH225992; Wed, 29 Aug 2001 13:29:42 -0400 Subject: Re: Wrap up and last call: sin6_scope_id semantics To: JINMEI Tatuya / =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Wed, 29 Aug 2001 13:29:30 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 08/29/2001 01:29:41 PM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, 08/30/2001 at 02:06 ZE9, JINMEI Tatuya / $B?@L@C#:H(B wrote: > > True, if two interfaces are in the same link-local zone then the interface > > name will not uniquely identify the zone. But the current scoping > > architecture draft indicates that configuration is required to identify > > that two interfaces are in the same zone, and the name used in this > > configuration can be used for display of the zone name. > > I don't see such indication of the draft...which text of the draft do > you really mean? The text is in section 6, which covers zone indicies (cut and pasted below): | There is at present no way for a node to automatically determine | which of its interfaces belong to the same zones, e.g., the same link | or the same site. In the future, protocols may be developed to | determine that information. In the absence of such protocols, an | implementation must provide a means for manual assignment and/or | reassignment of zone indices. Furthermore, to avoid the need to | perform manual configuration in most cases, an implementation should, | by default, initially assign zone indices as follows, and only as | follows: | | o A unique interface index for each interface | | o A unique link index for each interface | | o A unique subnet (multicast "scop" value 3) index for each | interface | | Then, manual configuration would be necessary only for the less | common cases of nodes with multiple interfaces to a single link or a | single subnet, interfaces to different sites, or interfaces to zones | of different (multicast-only) scopes. The diagram which follows shows, as a default, what is described above: that two interfaces on a single link are, by default, given unique link-local scope IDs. This doesn't address an automatic way to learn about a link-local or site-local zone, but then again any such mechanism can be made to include the appropriate zone name at the same time it configures the zone. > > I would prefer to use the textual representation which matches what is used > > in configuring the zones. It just makes more sense to echo back what a > > user placed in a configuration file instead of displaying an arbitrary > > value dynamically created by a given stack. How exactly would a user > > correlate an arbitrary value such as "link1" or "site5" to the given zone > > which they want to use, anyway? This would seem to be the equivalent of > > telling a user they need to "guess" the correct interface ID without > > proving if_nametoindex() to perform the translation of the configured > > interface name to the corresponding interface ID. > > I admit that "link1" is not user-friendly. But please note that the > textual representation described in the scoping architecture draft > basically defines numerical zone IDs only, which are also > "user-unfriendly". But the draft also allows implementations to > introduce more intuitive, more user-friendly format such as interface > names for links, assuming one-to-one mapping between interfaces and > links. > > Since the notion of "names" can be different among implementations, I > don't think the architecture draft should define the details of > "names". The problem with the 4+28 split model, however, is that > numerical identifiers would even annoy users (not just be > user-unfriendly), because we'd see IDs like "1342177281" (which is > 0x50000001, i.e. a site ID of site index 1). So, "site1" is just a > readable alias for "1342177281", which is a different kind of notion > from "names". The textual representation is more readable, but I don't find it substantially more useful. It still doesn't help anyone understand which site or which link is being used. How does someone using a zone such as "site1" have any idea which zone the packet will be sent, or which interfaces are defined to be within that zone? The "names" used to configure zones is going to be platform-unique. I guess I'd just prefer to see the values used by and returned from the DNS resolver incorporate those names vs. something like "link1" or "site1". By default, for link-local this is the interface name. Roy Brabson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 10:30:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THUV40007543 for ; Wed, 29 Aug 2001 10:30:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THUVeQ007542 for ipng-dist; Wed, 29 Aug 2001 10:30:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THUQ40007529 for ; Wed, 29 Aug 2001 10:30:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16726 for ; Wed, 29 Aug 2001 10:30:33 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19231 for ; Wed, 29 Aug 2001 11:30:28 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 10:30:03 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 8B2D6C03C55E42559296465837C175D1 for plus 1 more; Wed, 29 Aug 2001 10:30:03 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" Cc: Subject: RE: Higher level question about flow label Date: Wed, 29 Aug 2001 10:30:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C6DC3.57D7F95@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: DD15B8A8-F9DF4BF0-9795F30E-07D36BA3 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7THUR40007530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > I think you are talking about tunnel mode ESP, and Brian talks about > transport > mode ESP. I am not mixing them. Diffserv only works within a single domain when ESP is used, because in that context there is a hope that the SPI carries enough context for the first hop provider to construct the DSCP. Once the domain boundary is crossed that capability is lost so the next provider has no clue how to set the DSCP. If those were fixed bits end-to-end, the first hop could have set them and all the rest could process accordingly. > ... Ports and protocol ID, are encrypted, while BA > classification, can still > be done, since the DSCP is in clear. But the point is that no provider will understand or trust the DSCP as it is passed between domains, so BA classification will fail after the first provider, and it will even fail there if that provider doesn't trust the host to mark it correctly. > To me it is simple: I see the IPv6 main header divided into functions > for forwarding, > and functions for QoS. You appear to have forgotten that the endpoints need to communicate with each other. The header is also used for that primary function, or the others will not matter. > You seem to see the problem in terms of bit allocation. That is not my point, and you are the one that keeps raising the value of the bits... Anyway the point is that we are being asked to change an existing definition to accomidate a capability that another WG really needs, but refused to create for itself in the field it had to work with. Why should we do that? > OK, so the alternative that you suggest, means to have the DIffserv WG > rework a completely different Diffserv model, mechanisms, > architecture, > specifications which some are already on the standards track, IETF > marketing, etc... for IPv6. > > This means dropping, the model, architecture, mechanisms, > implementation similarity/compatibility between IPv6 and IPv4 No in fact that is what your proposal does. IPv4 does not have the flow label to fall back on, so your proposal makes the mechanisms different between the versions. All I am saying is that the diffserv WG should go back and define a set of DSCP values with global context, then there would be no need for modification of the flow label definition. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 10:30:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THUT40007537 for ; Wed, 29 Aug 2001 10:30:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THUS2X007536 for ipng-dist; Wed, 29 Aug 2001 10:30:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THUL40007522 for ; Wed, 29 Aug 2001 10:30:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16708 for ; Wed, 29 Aug 2001 10:30:30 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00474 for ; Wed, 29 Aug 2001 10:30:30 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7THUOl02559; Wed, 29 Aug 2001 10:30:24 -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 AAP37495; Wed, 29 Aug 2001 10:30:22 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA22338; Wed, 29 Aug 2001 10:30:22 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15245.9902.410862.795130@thomasm-u1.cisco.com> Date: Wed, 29 Aug 2001 10:30:22 -0700 (PDT) To: Brian E Carpenter Cc: alh-ietf@tndh.net, Alex Conta , Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label In-Reply-To: <3B8BC973.F7316797@hursley.ibm.com> References: <3B8BC973.F7316797@hursley.ibm.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > No, it's the whole point: the classifier at a domain ingress must > choose an appropriate DSCP value to write into the TC field, and that > *requires* the classifier to interpret the semantics of some set of > fields in the packet header. I don't think this is quite right: you MAY set up a classifier at the edge of your domain to remark packets, but it is not a requirement. You could simply believe that the packet is classified appropriately and police to the appropriate SLA and remark to the appropriate outbound traffic class. This allows for the obvious situation where I, on my own network, have an SLA with my upstream provider for x% EF traffic, and that it's completely my own business which traffic I chose to mark as EF. The upstream provider shouldn't be either required or even desired to remark the traffic; that's my problem. His job is only to police to our SLA. What you seem to want is a provider-centric model where you always know better than I do which traffic should be separated into which buckets. That's *a* model, but certainly not the only model, and indeed as is painfully obvious here, suffers greatly from the middlebox syndrome as encyption vividly demonstrates. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 10:33:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THXR40007607 for ; Wed, 29 Aug 2001 10:33:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THXRKt007606 for ipng-dist; Wed, 29 Aug 2001 10:33:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THXO40007599 for ; Wed, 29 Aug 2001 10:33:24 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17244 for ; Wed, 29 Aug 2001 10:33:33 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22290 for ; Wed, 29 Aug 2001 11:33:28 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f7THD9V11027; Wed, 29 Aug 2001 10:26:28 -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 AAP36953; Wed, 29 Aug 2001 10:15:02 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA22335; Wed, 29 Aug 2001 10:15:02 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15245.8982.469052.649969@thomasm-u1.cisco.com> Date: Wed, 29 Aug 2001 10:15:02 -0700 (PDT) To: Alex Conta Cc: alh-ietf@tndh.net, Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B8C1667.3F9F260D@txc.com> References: <3B8C1667.3F9F260D@txc.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 Alex Conta writes: > Tony Hain wrote: > > [...] Some of the pushback is > > simply based on the fact that the diffserv model of QoS > > is inherently broken because there is no end-to-end > > immutable set of bits for local decisions to be based on. > > I hate to say it, but your conclusion is grotesquely false. > The Diffserv QOS model is not broken at all - I don't know > how, where, and why you got that. > > For IPv4 M-F classification, Diffserv can use the well-known 5-tuple. > src, dst addresses, src, dst ports, and protocol ID. The problem is that the 5-tuple is exactly *one* kind of definition of a uflow. RFC 2207 defines another kind which instead of requiring IPsec to conform to RSVP's desire for a 5-tuple, defines another kind of uflow based on SRC,DST,SPI instead. This does not compromise the privacy of the flow itself since what the SPI represents is opaque to the classifier. What you are proposing is that that opaqueness is bogus and that I should always reveal the 5 tuple for all to see. I disagree. If there's lossage here, we should err on the side of privacy. What you all are proposing effectively renders ESP protection of transport headers a dead letter if you want diffserv QoS. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 10:35:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THZc40007627 for ; Wed, 29 Aug 2001 10:35:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THZbIT007626 for ipng-dist; Wed, 29 Aug 2001 10:35:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THZY40007619 for ; Wed, 29 Aug 2001 10:35:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05203 for ; Wed, 29 Aug 2001 10:35:43 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09510 for ; Wed, 29 Aug 2001 11:36:05 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id NAA05476; Wed, 29 Aug 2001 13:36:39 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id NAA15652; Wed, 29 Aug 2001 13:36:39 -0400 Message-ID: <3B8D2820.5F2FF1EA@txc.com> Date: Wed, 29 Aug 2001 13:36:32 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBB653987F196B8E40E026648" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msBB653987F196B8E40E026648 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tony Hain wrote: > > Alex Conta wrote: > > > I strongly believe, and am not the only one, please see > > earlier messages > > in the thread, packet forwarding and QoS processing in line > > cards on routers at wire > > speed is too critical to afford the use of flow label in the network > > layer header, to pass duplicate information from source to > > destination, > > that has no network layer meaning, or use in the network. > > And there are probably more of us who strongly believe that there > must be header bits that have immutable context from end-to-end. > The network elements are not the drivers here, the endpoints are. > If we allow the middle boxes to control our actions we end up with > the POTS network, and loose the ability to deploy new and > innovative applications. > > Tony I agree, and you are right, we do not have to get to a place, where the network controls everything. In the same time, we have to be careful to not overload the main network layer header with functions or information that are not critical to fast header processing in the network. I think with flexibility, and wisdom, we can accommodate any end-node needs. IPv6 has this wonderful thing - we all know (-: - called "destination options" headers that can carry information relevant to the end-nodes, if that information is not pertinent to packet forwarding or QoS in the network. There are also the transport and application headers, which are just for end-node consumption. For information that is pertinent, and critical to both network and end nodes, for functions related to the network, we should make every effort to include them in the main header. Alex --------------msBB653987F196B8E40E026648 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA4MjkxNzM2MzRaMCMGCSqGSIb3DQEJBDEWBBRg9IgYh9fdCOke6mCE 7V7jb7iqrjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gEQ8khHektdVLThQCeTQ58qQTUZ7w9PnhhSXBdl41hdsG4qm3T+y0/q17/7H8dZcaCjFNPd8 hV8ul5YqIq3M+GCQIpmN9b2eb06xabtEXYaLSbEJbI63UopfPPiKe4OWvwf9NIQU53Pg/DTv rH9IUBL+1WpNzBf7K3F0BcWKGB6u --------------msBB653987F196B8E40E026648-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 10:37:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THb040007658 for ; Wed, 29 Aug 2001 10:37:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THb0CF007657 for ipng-dist; Wed, 29 Aug 2001 10:37:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THaq40007650 for ; Wed, 29 Aug 2001 10:36:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21740 for ; Wed, 29 Aug 2001 10:36:56 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25146 for ; Wed, 29 Aug 2001 11:36:48 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 10:35:14 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 88EC007DB9D24EB59E0F16A5EA62BD76 for plus 5 more; Wed, 29 Aug 2001 10:35:13 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" Cc: "Brian E Carpenter" , "Keith Knightson" , "Christian Huitema" , "Bob Hinden" , "ipng" Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 10:35:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C7730.3DBE1742@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 97A27375-CC504122-B1ED8DCE-98BC0985 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7THav40007651 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > Let's take an example. > > Let's say flow label value 50, is RT traffic between A and B. > > C, D, and E are routers between A, and B. Between A, and C, the RT > traffic to B, has flow > label 50. At router C, the value of 50 changes to 60, and it > stays that > way, to E, where it is changed back from 60 to 50. > > Between C and E, the meaning was the same, as between A, and C, and E, > and B, that is > the RT traffic between A and B. > > The flow label bits were mutable, the meaning was immutable. And exactly how did C tell E that it would need to remark the packet to a particular value, or even know that it should do that, or who to tell? If you are assuming all the routers are all within the same domain, then yes, you can replace the entire header with 12 if every exit router knows that 12 means put a header on that exactly matches the original. The point is that every administrative domain and the destination will be looking at the same set of bits, not how some intermediate domain chooses to mangle packets. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 10:56:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THuH40007715 for ; Wed, 29 Aug 2001 10:56:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7THuHTR007714 for ipng-dist; Wed, 29 Aug 2001 10:56:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7THuD40007707 for ; Wed, 29 Aug 2001 10:56:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22093 for ; Wed, 29 Aug 2001 10:56:21 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12585 for ; Wed, 29 Aug 2001 11:56:16 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 10:55:47 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 9FD974A39CCD432683229F7F6498191C for plus 2 more; Wed, 29 Aug 2001 10:55:47 -0700 Reply-To: From: "Tony Hain" To: "Alex Conta" Cc: "Brian E Carpenter" , "ipng" Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 10:55:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8C7908.49EB0E4@txc.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 207EC376-4DF34488-80FDA5CD-B9E53DA6 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7THuE40007708 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex Conta wrote: > There is little experience with IP QoS billing. And that will continue until people figure out that a real-time modification to an SLA structure is required for the end user to perceive enough value to be willing to pay. > But how about FR and ATM > services, where PVCs do not give users any more control than Diffserv, > and various levels of QoS and billing are available. Hop-by-hop labeled circuit services are exactly what MPLS provides, but Brian felt I was being unfair by characterizing diffserv that way. If a user is going to bother to get QoS from the Internet, it will have to provide more capability than F/R or ATM, or it will have to be significantly cheaper. Since I don't see the latter happening because diffserv is too labor intensive, I can only expect we will get more capability. If all you are offering is to match capability Internet QoS will go nowhere. > There is a basic, simple SLA/TCA, and the users pay today a basic > monthly fee. But there is no mechanism for the end user to say that he is willing to pay Nx his normal rate *right-now* because it is really important that this get done. It is also impossible to sort between business use of an app vs. recreational use. Strict diffserv has a limited domain of applicability, and as I said before it is a providers fantsyland because it allows the provider complete control without giving any mechansim for input or negotiation from the person paying the bill. > I see no reason, why that would not work with Diffserv, with a few QoS > levels, and policing, and shaping, which would not be different > conceptually from the FR or ATM model. True; see above. Tony > -----Original Message----- > From: [mailto:aconta@txc.com] > Sent: Tuesday, August 28, 2001 10:09 PM > To: ALH-IETF > Cc: Brian E Carpenter; ipng > Subject: Re: a), b), c), d), or e) > > > > > Tony Hain wrote: > > > > > > How does it work if I am encrypting my traffic (independent of > > protocol version)? > > In transport mode ESP, the BA part works, in fact better than > Intserv. > The MF part has the same issues as Intserv. > > In tunnel mode ESP, the MF Diffserv and Intserv face both the same > problems. > > So it would seem that both Intserv, and Diffserv face > problems with ESP, > and so > no QoS model gets a free ride, except Diffserv BA with transport mode > ESP. > > > [...] A strict diffserv network is a > > providers fantasy land. There must be a mechanism for the > > endpoint to inject intent or there will be no reason to pay. > > > > > How about Internet access networks. A billing model existed > and worked, > when the Internet access was based on analog modems, and you had the > choice between per minute charge or unlimited service charge. It works > today when some of the Internet access is done with DSL, or > Cable. > > > [..] > > No, I base my thinking on the fact that for diffserv to work > > there has to be a visisble set of immutable bits with well-known > > end-to-end semantics. Otherwise each provider can't figure out > > which PHB is appropriate. > > > > Tony > > > > What you are saying is absolutely right. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 12:09:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TJ9P40007915 for ; Wed, 29 Aug 2001 12:09:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TJ9P0B007914 for ipng-dist; Wed, 29 Aug 2001 12:09:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TJ9L40007907 for ; Wed, 29 Aug 2001 12:09:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13250 for ; Wed, 29 Aug 2001 12:09:29 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA15052 for ; Wed, 29 Aug 2001 13:09:24 -0600 (MDT) Received: from 157.54.9.100 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Aug 2001 12:08:43 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 12:08:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 12:08:44 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 12:08:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Wrap up and last call: sin6_scope_id semantics Date: Wed, 29 Aug 2001 12:08:21 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E640@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Wrap up and last call: sin6_scope_id semantics Thread-Index: AcEwkB7m3gkt1bh3R9eAnAOGv1fCJgALZafg From: "Dave Thaler" To: "JINMEI Tatuya / ????" , "Roy Brabson" Cc: X-OriginalArrivalTime: 29 Aug 2001 19:08:21.0948 (UTC) FILETIME=[F884A7C0:01C130BD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TJ9M40007908 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei writes: > > I also prefer eth0 over link12. Using the names used to define the > zones > > (either the default interface names or actual zone definitions) seems to > be > > more useful than generating a somewhat arbitrary name and displaying > that. > > How is the user supposed to correlate link12 back to the actual eth0 > > interface, anyway? I imagine another external or display could be used, > > but this would seem to introduce yet another step for a user to identify > > the particular interface/zone in question. > > When we can assume one-to-one mapping between interfaces and links, > that's true. However, if two (or more) different interfaces belong > to a single link, using interface names as link IDs would be rather > confusing (we'll lose the uniqueness of the ID, or we'll have to care > about which interface is "primary" in the link".) I'd point out that with the "flexible 4+28" method, specifying "eth0" in place of "link12" would work, regardless of whether there was 1 or multiple interfaces attached to link12. Another advantage of the flexible method :) -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 12:20:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TJKf40007934 for ; Wed, 29 Aug 2001 12:20:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TJKfla007933 for ipng-dist; Wed, 29 Aug 2001 12:20:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TJKb40007926 for ; Wed, 29 Aug 2001 12:20:37 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15531 for ; Wed, 29 Aug 2001 12:20:45 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15152 for ; Wed, 29 Aug 2001 12:20:44 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TJL9304434 for ; Wed, 29 Aug 2001 22:21:09 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Aug 2001 22:20:13 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0J9K>; Wed, 29 Aug 2001 22:20:42 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FFA@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: Another idea for the flow label Date: Wed, 29 Aug 2001 22:20:41 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, What you propose below is already MUCH better. If you can achieve what you think is needed for diffserv usage with that, I'm all for it. 0. You may want to REVERSE the usage of the MSB you suggested below: presumably '00000' will need to remain to mean "best effort". This value has the MSB as '0', and definitely is "non-unique value". Also, if '0' is used for "non-unique value", then '00000' will likely match with the value for the Default PHB? See my comments below: Brian E Carpenter wrote: > How would people feel about this encoding for the flow label > (deemed to be immutable end to end)? > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Per-microflow unique value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 1. so this should be the case where MSB = '1' (see my comment above) 2. Does NOT need to be a PRN 3. this case needs to be end-to-end immutable (to protect against router failures and resulting state loss in a portion of a network; routers still having the state would have the right value The current (RFC2460 App.A) semantics does NOT require "microflow" semantics, but only the IP addressing & routing aspects of the packets with the same flow label need to be the same. I.e. same "flow" may include different transport protocols and source and destination ports for each packet. Presumably the flow label will be set by the source so that the packets marked by the same flow label, however, belong logically to the same "flow". Usually this would map 1:1 to a microflow. Therefore: 4. this should not be restricted to a "microflow", but the source may bundle multiple microflows to the same "flow label"-flow, as long as they have the same source address, destination address, and routing related option headers. 5. the significance of this form of a flow label must be established out-of-band (relative to the flow label itself), i.e. this kind of a flow label does not carry any semantics by itself. > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Non-unique value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > 6. so this should be the case where MSB = '0' 7. source & destination addresses, as well as any routing headers may have different values for packets marked with the same flow label of this type. 8. values and their meanings are standardized, registered with IANA, no local mapping! Routers may employ a number of methods to get the configuration needed (INCLUDING signaling), this is admin.. domain specific. 9. this form is MUTABLE: If the intention is to enable contractual aggregation needed by e.g. the diffserv model, domain must be able to remark the value (change it), but also the new value needs to be taken from the set of standardized values, so that the semantics of the value is always unambiguous. The mutability allows cutting off "freeloaders" (as put so eloquently by Steve Blake), and enables the diffserv aggregation model. 10. This form may be further subdivided FOR ADMINISTRATIVE reasons. This subdivision SHOULD have no HW/ASIC/NP classification code implications. The highest nibble of '0' (bits: '0000') should be used for the PHB-ID name space to utilize the all-zeroes == Default PHB == best effort semantics. Four highest bits of '0111' could signify an administratively reserved name space for the rest of the bits, but this should be IGNORED by HW/ASIC/NP implementations implementing look-up. 11. IANA please: Do not use any of the reserved namespace for duplicating any info in the transport headers (Maybe this should go in the IANA considerations section :-) 12. Note that knowing the difference between the MSB 0/1 CAN be utilized by HW implementations to ignore the addressing in the lookup for the "non-unique" form. > I'm not yet 100% convinced that the second case is sufficient for > diffserv, but at least it would be a more generic approach > than reserving half the space for diffserv. > I think we can have it both ways. This more generic definition should keep all specifics of e.g. diffserv usage on the control plane, allowing people to build generic HW classifiers, when the MSB is the only bit that affects how other IP header fields ought to be used in the classification. With regards, 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 Aug 29 12:58:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TJwf40008014 for ; Wed, 29 Aug 2001 12:58:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TJwf5V008013 for ipng-dist; Wed, 29 Aug 2001 12:58:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TJwb40008006 for ; Wed, 29 Aug 2001 12:58:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23082 for ; Wed, 29 Aug 2001 12:58:46 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22308 for ; Wed, 29 Aug 2001 13:58:41 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 12:57:49 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id C1469BDC607D45AFB926AC857624A1F0 for plus 2 more; Wed, 29 Aug 2001 12:57:48 -0700 Reply-To: From: "Tony Hain" To: , , Subject: RE: Another idea for the flow label Date: Wed, 29 Aug 2001 12:57:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009CA59D1752DD448E07F8EB2F911757197FFA@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 50DA6A2E-643A472A-94507687-528DC921 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TJwc40008007 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno Rajahalme wrote: > 9. this form is MUTABLE: > > If the intention is to enable contractual aggregation needed > by e.g. the > diffserv model, domain must be able to remark the value > (change it), but > also the new value needs to be taken from the set of > standardized values, so > that the semantics of the value is always unambiguous. The > mutability allows > cutting off "freeloaders" (as put so eloquently by Steve > Blake), and enables > the diffserv aggregation model. I am sorry, but this is BS. The diffserv model already has a mutable field giving the provider ultimate control and doesn't need a second one. In fact allowing this proposed use to be mutable will ensure that subsiquent providers have no clue what the origin intended. If the provider wants to cut people off, it can set the TC to 0, or drop the packet. Allowing providers to modify these bits adds no value to the existing diffserv capabilities. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 13:01:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TK1040008024 for ; Wed, 29 Aug 2001 13:01:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TK10w3008023 for ipng-dist; Wed, 29 Aug 2001 13:01:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TK0M40008016 for ; Wed, 29 Aug 2001 13:00:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23326 for ; Wed, 29 Aug 2001 13:00:00 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18516 for ; Wed, 29 Aug 2001 12:59:59 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TK3uG20038 for ; Wed, 29 Aug 2001 23:03:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Aug 2001 22:59:14 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0K15>; Wed, 29 Aug 2001 22:59:57 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FFB@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, alh-ietf@tndh.net Cc: kgk@igs.net, huitema@windows.microsoft.com, hinden@iprg.nokia.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 22:59:55 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) 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 f7TK0q40008017 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just some comments for clarifying some stuff that keeps coming up repeatedly: Brian E Carpenter wrote: > > This is a very unfair comment. Diffserv is just fine in the > case of unencrypted traffic. It has a problem (and so does > intserv I suspect) with tunnel or transport mode ESP. > IPv4 intserv shares the same difficulty of doing MF-classification with ESP. However, in IPv6 the flow label can be used in MF-classification for intserv semantics, even when ESP is used. > > What we have on the table is a proposal to take over > > part of another field to create that set of bits, but > > even that contains the argument that the bits should be > > mutable. > > No it doesn't. They should be set at source. (But anyway, why > would it matter if they are mutable, since they aren't covered > by checksum? I'm not aware of a law of nature against mutable bits.) > For the proposed diffserv usage the flow label should be mutable to enable policing and aggregation. The point is that the flow label should NOT be locally mappable, it MUST always contain a standardized value, or it's semantics must be signaled (la intserv). > > The diffserv WG should have defined a set of PHBs with > > global context and mapped a set of DSCPs to those. It > > chose not to, > > No, that is in fact what we did, but at the specific insistence > of the ISPs active in the design of diffserv, we made all of > the mappings SHOULD instead of MUST. You want to ding the WG > for meeting a clearly stated key requirement of the principal > customer set? > It may be that diffserv cannot be changed NOT to allow local mapping any more, but where are these ISPs NOW? > Immutablity isn't the problem. Encryption of the port and protocol > numbers is the problem. I could equally well say that IPSEC should > go back and fix the invisibility problem they created. As I said above, it seem to me that any diffserv usage would need mutability. Encryption is NOT the problem either. The problem is the local mappability of the DSCP field. Amending the flow label field to include very "broad definitions for flows" (indeed, behavior aggregated flows) can be a plausible remedy to this problem. (No harm unless we conclude that 19 bits is not enough for host-to-host specific flows.) The IPsec invisibility *feature* is by design. Another problem is the MF-classification defined by the diffserv: How long you think it takes for the SLAs to be updated end-to-end (or more precisely, hop-by-hop), when two consenting hosts switch to SCTP instead of TCP? No such problem with intserv, since the signaling carried out before the session using SCTP would have it's MF-classifier say 'SCTP' instead of 'TCP' (or better yet, specify the MF-classifier in terms of flow label and IP addresses only). Possibly the same problem when changing from IPv4 to IPv6 (if MF-classifiers in the diffserv ingress specify address (prefixes)). I hope that if we'll have the flow label support for what Brian is asking (standard, non-mappable behavior aggregates), he'll promise to remove the MF-classifiers peeking into transport headers from the diffserv specs :-) (also from the non-ESP case). > What I am actually > saying is that this WG should go back and fix the ambiguity problem > created by the Appendix to RFC 2460. This I think we all agree. I think esp. HW and commercial OS vendors (roughly similar lead times?) would be grateful to have the ambiguity resolved. 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 Aug 29 13:11:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TKBg40008063 for ; Wed, 29 Aug 2001 13:11:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TKBfSJ008062 for ipng-dist; Wed, 29 Aug 2001 13:11:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TKBb40008055 for ; Wed, 29 Aug 2001 13:11:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25681 for ; Wed, 29 Aug 2001 13:11:46 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01616 for ; Wed, 29 Aug 2001 14:11:36 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TKC5314363 for ; Wed, 29 Aug 2001 23:12:05 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Aug 2001 23:11:09 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KGV>; Wed, 29 Aug 2001 23:09:42 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FFC@esebe004.NOE.Nokia.com> To: slblake@torrentnet.com, alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Wed, 29 Aug 2001 23:11:36 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Blake wrote: > RFC2475 was built on the assumption of bilateral agreements between > peering providers, because that was the only model that had a hope > of being deployed. Has this changed? Would there be hope for non-locally-mappable DSCP deployment NOW? I've understood the standardized values already exist (the PHB definition recommended DSCP values). > The Diffserv flow-label proposal is trying to > invent an end-to-end, in-band QoS "signaling" mechanism to operate in > parallel with the hop-by-hop DSCP "signaling". I can see this to be useful, IF DSCP cannot be made non-mappable, and the proposed flow label usage would be mutable. > The only additional > in-band information that would be remotely useful for Diffserv would > be a credit card account number. Assuming that the flow label usage would be immutable. The first operator that doesn't see the transitive out-of-band credit card should re-mark the flow label to '00000'. 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 Aug 29 13:29:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TKTH40008085 for ; Wed, 29 Aug 2001 13:29:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TKTHNx008084 for ipng-dist; Wed, 29 Aug 2001 13:29:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TKTD40008077 for ; Wed, 29 Aug 2001 13:29:13 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28727 for ; Wed, 29 Aug 2001 13:29:22 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18964 for ; Wed, 29 Aug 2001 13:29:20 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TKTj317293 for ; Wed, 29 Aug 2001 23:29:45 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Aug 2001 23:29:01 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0K23>; Wed, 29 Aug 2001 23:26:33 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FFD@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, alh-ietf@tndh.net Cc: aconta@txc.com, slblake@torrentnet.com, ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Wed, 29 Aug 2001 23:28:28 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In hope of maybe clearing out some of the confusion: Brian E Carpenter wrote: > > I fail to understand how either would break if they simply intrepret the > > flow label semantics as 'the source has identified this set of packtes > > as related'. In either case there is an out-of-band mechansim to > > translate the value to a router task. This could include "behavior aggregate flows"? > But in the diffserv case, which is stateless (no signalling, > no soft state) > the only out-of-band mechanism that works is if the flow label has > intrinsic semantics. The fact that the packet belongs to a class is > useless information on its own; you need to know what that > class means, > and that can only be conveyed by an encoded field, since there is no > signalling or state. A PHB-ID in the flow label is NOT the semantics, but a pointer to the semantics. The actual semantics are found from the respective specification, and since all the possible (future) PHB-ID pointed semantics cannot be hard-coded into the router, they need to be delivered to the router by some out-of-band mechanism. This out-of-band mechanism will indeed establish state at the router, not source specific state, but behavior aggregate flow specific state. One could even imagine establishing this state with an end-to-end signaling mechanism, which would result in a kind of host-to-host specific behavior aggregate flow (RFC 2460 App.A could be read this way already). Could be useful for e.g. experimental use?? 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 Aug 29 13:31:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TKVB40008112 for ; Wed, 29 Aug 2001 13:31:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TKVBYP008111 for ipng-dist; Wed, 29 Aug 2001 13:31:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TKV740008104 for ; Wed, 29 Aug 2001 13:31:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29326 for ; Wed, 29 Aug 2001 13:31:15 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15737 for ; Wed, 29 Aug 2001 14:31:36 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TKZ6G25413 for ; Wed, 29 Aug 2001 23:35:06 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 29 Aug 2001 23:30:24 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0K26>; Wed, 29 Aug 2001 23:29:08 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D4CB@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, hinden@iprg.nokia.com Cc: aconta@txc.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 23:31:02 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Maybe Bob meant just IPv6 tunneled over IPv4, not protocol translation? Jarno Brian E Carpenter wrote: > Bob Hinden wrote: > > > .. > > I think you are going a bit far to suggest that the fate of Diffserv > > depends on what the IPv6 w.g. does with the flow label > field. I suspect > > that Diffserv will live or die based on IPv4 usage. Also, > as IPv6 is > > deployed much of it will be initially carried over IPv4. > Any QoS solution > > that is going to be end-to-end will have to deal with a mix > of native IPv6 > > and IPv4/IPv6 headers. > > Indeed, and since I don't quite see how IPSEC and NAT-PT are going to > work together, the need that triggered this discussion (the need to > classify ESP packets in the middle of the Internet) really > doesn't arise > in the case of translated packets. The concern is for a > native IPv6 environment. > > 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 Aug 29 14:05:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TL5X40008245 for ; Wed, 29 Aug 2001 14:05:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TL5XMH008244 for ipng-dist; Wed, 29 Aug 2001 14:05:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TL5T40008237 for ; Wed, 29 Aug 2001 14:05:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01147 for ; Wed, 29 Aug 2001 14:05:33 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12075 for ; Wed, 29 Aug 2001 15:05:27 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TL5u324148 for ; Thu, 30 Aug 2001 00:05:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 00:02:33 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KLQ>; Thu, 30 Aug 2001 00:03:33 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D4CC@esebe004.NOE.Nokia.com> To: alh-ietf@tndh.net, aconta@txc.com Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Thu, 30 Aug 2001 00:05:26 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > There is a basic, simple SLA/TCA, and the users pay today a basic > > monthly fee. > > But there is no mechanism for the end user to say that he is > willing to pay Nx his normal rate *right-now* because it is > really important that this get done. It is also impossible to > sort between business use of an app vs. recreational use. > Strict diffserv has a limited domain of applicability, and as > I said before it is a providers fantsyland because it allows > the provider complete control without giving any mechansim > for input or negotiation from the person paying the bill. > An SLA between the user and the provider could do all this with diffserv. You just mark the more expensive packets with a different DSCP, and you will be charged accordingly, as specified in the SLA. To work in practice this would probably need its own PHB-group definition (n price levels), and well implemented support in the end system. 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 Aug 29 14:16:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLGC40008265 for ; Wed, 29 Aug 2001 14:16:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TLGBYV008264 for ipng-dist; Wed, 29 Aug 2001 14:16:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLG640008257 for ; Wed, 29 Aug 2001 14:16:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21093 for ; Wed, 29 Aug 2001 14:16:08 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA08002 for ; Wed, 29 Aug 2001 15:16:35 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TLGW326377 for ; Thu, 30 Aug 2001 00:16:32 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 00:12:54 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KMP>; Thu, 30 Aug 2001 00:14:09 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D4CD@esebe004.NOE.Nokia.com> To: alh-ietf@tndh.net, aconta@txc.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Thu, 30 Aug 2001 00:16:00 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > But the point is that no provider will understand or trust the > DSCP as it is passed between domains, so BA classification will > fail after the first provider, and it will even fail there if > that provider doesn't trust the host to mark it correctly. > There is no question of trust here. Every packet needs to be policed as marked (i.e. if you "lie", you also pay more, or get down-marked). If there would be no local mapping of the DSCP value, I don't see why it should not work over multiple domains. > > > To me it is simple: I see the IPv6 main header divided > into functions > > for forwarding, > > and functions for QoS. > > You appear to have forgotten that the endpoints need to > communicate with each other. The header is also used for > that primary function, or the others will not matter. > That's why there is the source address in the header, in addition to the "functions for forwarding". The only other field in the IPv6 header that is NOT used for forwarding or QoS, is the "Next Header" field. Well, there is the Version field as well, but I agree with Alex, the main IPv6 header has only functions for forwarding and QoS (forwarding treatment). 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 Aug 29 14:21:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLLN40008287 for ; Wed, 29 Aug 2001 14:21:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TLLNgx008286 for ipng-dist; Wed, 29 Aug 2001 14:21:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLLJ40008279 for ; Wed, 29 Aug 2001 14:21:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11042 for ; Wed, 29 Aug 2001 14:21:28 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23219 for ; Wed, 29 Aug 2001 15:21:23 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TLLq327594 for ; Thu, 30 Aug 2001 00:21:52 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 00:18:29 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KNH>; Thu, 30 Aug 2001 00:19:29 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D4CE@esebe004.NOE.Nokia.com> To: huitema@windows.microsoft.com, brian@hursley.ibm.com, alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Thu, 30 Aug 2001 00:21:20 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, I might be wrong, but it seems that a downstream (operator) router CANNOT use end-to-end immutable information. If the policer in the 1st operators domain concludes that the customer is not paying enough for the treatment he's asking, the "treatment indicator" needs to be downgraded. If that is not allowed, the only other option would be to drop the packet altogether. Jarno Christian Huitema wrote: > > > There are no stupid questions. Some of the pushback is > > > simply based on the fact that the diffserv model of QoS > > > is inherently broken because there is no end-to-end > > > immutable set of bits for local decisions to be based on. > > > > This is a very unfair comment. Diffserv is just fine in the > > case of unencrypted traffic. It has a problem (and so does > > intserv I suspect) with tunnel or transport mode ESP. > > ESP is just one of the cases in which "looking at the port > numbers" does > not provide sufficient information to make an informed decision. There > are many examples that do not involve ESP, e.g. an audio stream can > carry different levels of hierarchical encoding on successive > ports, an > HTTP transaction can carry a medical transaction just as well as > recreational content, a file transfer may be a virus update or a virus > propagation. At some point, the classification decision has to rely on > information provided by the source. > > In fact, there is no contradiction between the "immutable" requirement > that Tony is advocating and Brian's "diffserv handle" requirement. In > the diffserv model, the actual classification is based on the 6 > classifier bits; there is no context that this can be mutable, since > ISPs must be authorized to reclassify traffic. The reclassification is > based on information carried in the packet, part of which is the label > affixed by the source; making that label immutable is a good thing, > since it prevents intermediaries from removing the > information that can > be used by a downstream router. > > -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 14:33:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLXp40008309 for ; Wed, 29 Aug 2001 14:33:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TLXo0V008308 for ipng-dist; Wed, 29 Aug 2001 14:33:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLXl40008301 for ; Wed, 29 Aug 2001 14:33:47 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07341 for ; Wed, 29 Aug 2001 14:33:56 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20474 for ; Wed, 29 Aug 2001 14:33:55 -0700 (PDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7TLXpY54746; Wed, 29 Aug 2001 17:33:51 -0400 (EDT) Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id f7TLXpc53469; Wed, 29 Aug 2001 17:33:51 -0400 (EDT) Received: from castillo.torrentnet.com (localhost.torrentnet.com [127.0.0.1]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id RAA20414; Wed, 29 Aug 2001 17:33:50 -0400 (EDT) Message-Id: <200108292133.RAA20414@castillo.torrentnet.com> X-Mailer: exmh version 2.0.2 2/24/98 To: jarno.rajahalme@nokia.com cc: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label In-reply-to: Your message of "Wed, 29 Aug 2001 23:11:36 +0300." <009CA59D1752DD448E07F8EB2F911757197FFC@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Aug 2001 17:33:50 -0400 From: Steve Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno Rajahalme wrote: > Steve Blake wrote: > > RFC2475 was built on the assumption of bilateral agreements between > > peering providers, because that was the only model that had a hope > > of being deployed. > > Has this changed? Would there be hope for non-locally-mappable DSCP > deployment NOW? I've understood the standardized values already exist (the > PHB definition recommended DSCP values). Not to my knowledge. I fail to see much use for privately defining the DSCP->PHB mapping for the standardized PHBs, but I also don't see any reason why someone who wanted that feature would be willing to give it up, and I don't see any mechanism by which they could be forced. > > The Diffserv flow-label proposal is trying to > > invent an end-to-end, in-band QoS "signaling" mechanism to operate in > > parallel with the hop-by-hop DSCP "signaling". > > I can see this to be useful, IF DSCP cannot be made non-mappable, and the > proposed flow label usage would be mutable. Why would it be useful? > > The only additional > > in-band information that would be remotely useful for Diffserv would > > be a credit card account number. > > Assuming that the flow label usage would be immutable. The first operator > that doesn't see the transitive out-of-band credit card should re-mark the > flow label to '00000'. I don't get your point. The flow label is in-band. A mutable flow label is just a 20-bit DSCP. Why would we want that? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 14:34:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLY140008319 for ; Wed, 29 Aug 2001 14:34:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TLY1Y8008318 for ipng-dist; Wed, 29 Aug 2001 14:34:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLXv40008311 for ; Wed, 29 Aug 2001 14:33:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07417 for ; Wed, 29 Aug 2001 14:34:07 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00997 for ; Wed, 29 Aug 2001 14:34:06 -0700 (PDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TLYV329873 for ; Thu, 30 Aug 2001 00:34:31 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 00:31:08 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0K3K>; Thu, 30 Aug 2001 00:31:19 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FFE@esebe004.NOE.Nokia.com> To: alh-ietf@tndh.net, aconta@txc.com Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Thu, 30 Aug 2001 00:33:09 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > How does it work if I am encrypting my traffic (independent of > protocol version)? On top of that the diffserv model provides > no control to the originator of the packets, and that is the > source of the money which makes a business model work. The originator CAN set the DSCP bits, as specified by the agreement with the access operator. This control SHOULD only propagate as far as his money propagates. If the access operator is not willing to share some of the "value-added" income with the next operator, the RIGHT thing to do by the next operator is to remark the PHB treatment indicator originally set by the originator, and possibly remarked by the access operator. > Yes there > is a technical definition for diffserv QoS, but there is no > sustainable business and operational model which includes the > source of the packets & money. A strict diffserv network is a > providers fantasy land. There must be a mechanism for the > endpoint to inject intent or there will be no reason to pay. > All that is missing is a standardized usage of DSCP between the originator and the access operator and maybe some pretty standard conventions for fee-schedules, or alternatively monthly (or daily) usage limits for each DSCP indicated behavior aggregate. > > > You assume that the flow label MUST be immutable, because you > > base your > > thinking on an absolute model. > > No, I base my thinking on the fact that for diffserv to work > there has to be a visisble set of immutable bits with well-known > end-to-end semantics. Otherwise each provider can't figure out > which PHB is appropriate. It may be hard to map from end-to-end semantics to per-hop-behavior. So maybe you meant more like "standardized semantics". See my comment on mutability above. 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 Aug 29 14:53:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLrb40008388 for ; Wed, 29 Aug 2001 14:53:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TLraug008387 for ipng-dist; Wed, 29 Aug 2001 14:53:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TLrW40008380 for ; Wed, 29 Aug 2001 14:53:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07760 for ; Wed, 29 Aug 2001 14:53:42 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08949 for ; Wed, 29 Aug 2001 14:53:41 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TLvcG09613 for ; Thu, 30 Aug 2001 00:57:38 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 00:50:15 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KPN>; Thu, 30 Aug 2001 00:51:34 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757197FFF@esebe004.NOE.Nokia.com> To: alh-ietf@tndh.net, brian@hursley.ibm.com Cc: kgk@igs.net, huitema@windows.microsoft.com, hinden@iprg.nokia.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Flow label mutability (was RE: a), b), c), d), or e)) Date: Thu, 30 Aug 2001 00:53:25 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, I may be repeating myself, but exactly because the *ports* are immutable, they are *useless* for intra-operator diffserv MF-classification. Having a non-locally-mappable but mutable field with standardized semantics AND SLA-based strict tie-in to policing/charging/remarking is what is needed for diffserv intra-operator BA classification. Now, DSCP would be all that is needed, if it weren't irreversibly mappable. Now it seems that we need to give one bit away from the flow label to fix this. If this will result in network middleboxes snooping less on the host-to-host transport headers, I'm happy :-) The host-to-host flow labels will need to remain immutable. Jarno PS: Aren't the "well known ports" defined just to facilitate end-to-end rendezvous? Quite a leap to base any policy decisions on ports... Tony Hain wrote: > Brian Carpenter wrote: > > > This is a very unfair comment. Diffserv is just fine in the > > case of unencrypted traffic. It has a problem (and so does > > intserv I suspect) with tunnel or transport mode ESP. > > But that is the point. If IPsec had been widely deployed in the > IPv4 Internet, diffserv would have been forced to fix the DSCP > end-to-end, because that would be the only alternative. > > > No it doesn't. They should be set at source. (But anyway, why > > would it matter if they are mutable, since they aren't covered > > by checksum? I'm not aware of a law of nature against mutable bits.) > > Speak to your co-author who keeps insisting that they are > mutable. In any case, the point is that for diffserv to work there > has to be a visible set of bits that are immutable end-to-end > with well-known semantics. Currently that is the protocol/port, > simply because ESP wasn't in widespread use. In IPv6 we assume > it will be, so diffserv needs another set of bits that have an > immutable well-known end-to-end semantic. > > > No, that is in fact what we did, but at the specific insistence > > of the ISPs active in the design of diffserv, we made all of > > the mappings SHOULD instead of MUST. You want to ding the WG > > for meeting a clearly stated key requirement of the principal > > customer set? > > In this case yes, because that requirement results in an > inoperable state when security is applied. RFC 2475 starts the > discussion about IPsec interactions, but only from the perspective > of protecting the DSCP. It misses the point that when ESP is in > use there is no visible set of bits to base decisions on for > each domain to set the DSCP. The only set of bits there is left > to work with is the SPI, and the semantics of that are only > known between the endpoints unless signalled via RSVP. > > > Products work just fine the way things are. > > In fact that is a false statement because those products can't > work today if one tries to use an encrypted channel. > > > Immutablity isn't the problem. Encryption of the port and protocol > > numbers is the problem. I could equally well say that IPSEC should > > go back and fix the invisibility problem they created. > > That is a specific feature. There are many times when you don't > want traffic analysis done on the ports in use and number or sequence > of packets between them. > > > What I am actually > > saying is that this WG should go back and fix the ambiguity problem > > created by the Appendix to RFC 2460. > > No argument, but the only ambiguity I see is the comment about > control protocols. The rest of the text is very clear. > > Tony > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 15:00:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TM0X40008408 for ; Wed, 29 Aug 2001 15:00:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TM0XpM008407 for ipng-dist; Wed, 29 Aug 2001 15:00:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TM0U40008400 for ; Wed, 29 Aug 2001 15:00:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19438 for ; Wed, 29 Aug 2001 15:00:39 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA28270 for ; Wed, 29 Aug 2001 16:01:03 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TM12303633 for ; Thu, 30 Aug 2001 01:01:02 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 00:57:24 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KPY>; Thu, 30 Aug 2001 00:58:39 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198000@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, alh-ietf@tndh.net Cc: slblake@torrentnet.com, ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Thu, 30 Aug 2001 01:00:31 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, In the scenario you provided (multiple instances of the standard PHBs, each mapped to separate DSCP value), the mapping is reversible: the egress router of that domain should be able to map back to the single instance of the recommended DSCP value for the PHB in question. Therefore usage of the recommended DSCPs intra-domain would seem to be sufficient. I might be wrong, but it seems that unless there is a case where a locally used DSCP value for a PHB cannot be mapped back to a standardized, PHB definition recommended DSCP value at the domain egress, there is no need for additional support from the flow label. Also, mutability and standardized semantics would seem to be orthogonal issues. Jarno > -----Original Message----- > From: ext Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: 29. elokuuta 2001 1:01 > To: alh-ietf@tndh.net > Cc: Steve Blake; ipng@sunroof.eng.sun.com > Subject: Re: Higher level question about flow label > > > Preamble: this is getting pretty far away from the core of the debate. > I'd like the chairs to make some consensus calls, because > we are going round in circles. > > Tony Hain wrote: > > > > Steve Blake wrote: > > > > > I agree with your conclusion, but I disagree with the assumptions > > > you are making about diffserv (for the sake of argument, say). > > I assume you are talking about the WG not the protocol. :) > > > > > RFC2475 was built on the assumption of bilateral > agreements between > > > peering providers, because that was the only model that had a hope > > > of being deployed. > > But bi-lat's don't necessarily require mutability of the TC > field. That > > was simply a concession to those who wanted knobs to make it more > > difficult for the less skilled. Now we have a mechanism > that only has > > a hope of being deployed, but is operationally useless on a global > > scale because it lacks any context. > > I think that is quite unproven. Specifically (apart from a > few researchers) > the kind of thing I expect major ISPs to do with the flexibility is > to implement multiple instances of the standard PHBs, which > requires them > to use additional DSCP values for the multiple instances. The > context will > be provided by a QOS policy management system and their SLAs. > > > > The Diffserv flow-label proposal is trying to > > > invent an end-to-end, in-band QoS "signaling" mechanism > to operate in > > > parallel with the hop-by-hop DSCP "signaling". > > Basically the hop-by-hop decisions have to be based on consistent > > end-to-end semantics of a set of bits, but the TC field was allowed > > to be randomized so it is currently useless for that purpose. This > > is still fixable by locking down the PHBs and matching DSCPs, so > > This is a dream. It isn't going to happen. I went through > denial/anger/acceptance on this three years ago. > > > there is no need for taking additional header bits. > > Abolish IPSEC and I will agree with you. > > > > > > The only additional > > > in-band information that would be remotely useful for > Diffserv would > > > be a credit card account number. > > Not if the proposed new end-to-end signaling is left as > mutable. There > > will be a never-ending series of requests for bits until it > is accepted > > that what is required is an end-to-end immutable set that the origin > > node uses to identify its intent for the packets, (in or > out of band). > > There is no request for a new mutable field. On the contrary, diffserv > classification needs something that is globally unique. > > > The intervening networks will always make local decisions based on > > those bits, so there is no need to rewrite them at every > domain boundary. > > All the TC field is used for now is an embedded MPLS type > tag, so why is > > it embedded? > > That's a *complete* mischaracterisation. It doesn't resemble an MPLS > tag in any shape or form. It's in the IP header becasue it is used to > drive schedulers for queues of IP packets. > > > Shouldn't it be the end-to-end consistent set of bits and > > let MPLS do the tagging it will undoubtedly do for TE > purposes anyway? > > MPLS is not the e2e protocol in the Internet, and is probably only > a passing phase anyway. Diffserv traffic will get mapped onto > a variety > of hardware layers; but diffserv is about IP packet > scheduling, not about > lower layer frame scheduling. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 15:24:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TMOn40008438 for ; Wed, 29 Aug 2001 15:24:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TMOnMm008437 for ipng-dist; Wed, 29 Aug 2001 15:24:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TMOj40008430 for ; Wed, 29 Aug 2001 15:24:45 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17700 for ; Wed, 29 Aug 2001 15:24:52 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14480 for ; Wed, 29 Aug 2001 15:24:51 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TMSmG14043 for ; Thu, 30 Aug 2001 01:28:48 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 01:21:25 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KQ6>; Thu, 30 Aug 2001 01:20:07 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198001@esebe004.NOE.Nokia.com> To: slblake@torrentnet.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Thu, 30 Aug 2001 01:24:45 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Blake wrote: > > Jarno Rajahalme wrote: > > > Steve Blake wrote: > > > RFC2475 was built on the assumption of bilateral agreements between > > > peering providers, because that was the only model that had a hope > > > of being deployed. > > > > Has this changed? Would there be hope for non-locally-mappable DSCP > > deployment NOW? I've understood the standardized values already exist (the > > PHB definition recommended DSCP values). > > Not to my knowledge. I fail to see much use for privately defining the > DSCP->PHB mapping for the standardized PHBs, but I also don't see any reason > why someone who wanted that feature would be willing to give it up, and I > don't see any mechanism by which they could be forced. > I have in earlier messages proposed "giving up just a little": map intra-domain DSCP back to a standard recommended DSCP at the domain egress. Next ingress would understand the standard values, and could then again map to it's own intra-domain DSCP->PHB mappings. Brian's answer to this was that this cannot be forced on the operators. > > > The Diffserv flow-label proposal is trying to > > > invent an end-to-end, in-band QoS "signaling" mechanism to operate in > > > parallel with the hop-by-hop DSCP "signaling". > > > > I can see this to be useful, IF DSCP cannot be made non-mappable, and the > > proposed flow label usage would be mutable. > > Why would it be useful? Intra-domain egress would have an idea of what PHB the packet needs (that the next ingress understands). > > > > The only additional > > > in-band information that would be remotely useful for Diffserv would > > > be a credit card account number. > > > > Assuming that the flow label usage would be immutable. The first operator > > that doesn't see the transitive out-of-band credit card should re-mark the > > flow label to '00000'. > > I don't get your point. The flow label is in-band. A > mutable flow label > is just a 20-bit DSCP. Why would we want that? > Well, maybe 16 or just 6 bits depending on the allocation, but non-locally mappable. An alternative would be to get the diffserv WG mandate use of standard recommended DSCP->PHB mappings only. "Intserv" flow label would get to keep 19 bits. What I meant with the remark above is that if the ingress can't associate the "diffserv" flow label with a "payment" should value in the flow label to indicate "best effort" (if not drop the packet). There would be no sense to give preferential treatment for a packet that is not being paid for and then have the operator pay the next operator for preferential treatment. As soon as the money (originating from the packet originator) stops flowing, any preferential treatment should stop. 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 Aug 29 15:33:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TMXp40008462 for ; Wed, 29 Aug 2001 15:33:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TMXoZ8008461 for ipng-dist; Wed, 29 Aug 2001 15:33:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TMXk40008454 for ; Wed, 29 Aug 2001 15:33:46 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27215 for ; Wed, 29 Aug 2001 15:33:54 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA18884 for ; Wed, 29 Aug 2001 15:33:54 -0700 (PDT) Received: from 157.54.9.101 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 29 Aug 2001 15:33:35 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 15:33:34 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 15:26:37 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 29 Aug 2001 15:26:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 15:26:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a), b), c), d), or e) Thread-Index: AcEw0IbLNtD5ecFjRdSKBu+yStcC9AACIiOg From: "Christian Huitema" To: , , Cc: X-OriginalArrivalTime: 29 Aug 2001 22:26:15.0332 (UTC) FILETIME=[9D9B4640:01C130D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TMXl40008455 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe you are wrong. On obvious counter-example comes if the sender has no privilege with the sender's ISP, but the receiver has these privileges. In that case, the packet is marked as "priority high, traffic type X" by the sender; the sender ISP's rewrites that to "priority standard, traffic type X"; the receiver's ISP rewrites to "priority high, traffic type X." By the way, many people seem to believe that diffserv necessarily ties with monetary exchanges. That is not necessary, if for example you implement "alternative best effort" and get 2 best effort classes, one for "high throughput, low loss", and one for "low delay, possible losses." -- Christian Huitema > -----Original Message----- > From: jarno.rajahalme@nokia.com [mailto:jarno.rajahalme@nokia.com] > Sent: Wednesday, August 29, 2001 2:21 PM > To: Christian Huitema; brian@hursley.ibm.com; alh-ietf@tndh.net > Cc: ipng@sunroof.eng.sun.com > Subject: RE: a), b), c), d), or e) > > Christian, > > I might be wrong, but it seems that a downstream (operator) router > CANNOT > use end-to-end immutable information. If the policer in the 1st > operators > domain concludes that the customer is not paying enough for the > treatment > he's asking, the "treatment indicator" needs to be downgraded. If that > is > not allowed, the only other option would be to drop the packet > altogether. > > Jarno > > Christian Huitema wrote: > > > > There are no stupid questions. Some of the pushback is > > > > simply based on the fact that the diffserv model of QoS > > > > is inherently broken because there is no end-to-end > > > > immutable set of bits for local decisions to be based on. > > > > > > This is a very unfair comment. Diffserv is just fine in the > > > case of unencrypted traffic. It has a problem (and so does > > > intserv I suspect) with tunnel or transport mode ESP. > > > > ESP is just one of the cases in which "looking at the port > > numbers" does > > not provide sufficient information to make an informed decision. > There > > are many examples that do not involve ESP, e.g. an audio stream can > > carry different levels of hierarchical encoding on successive > > ports, an > > HTTP transaction can carry a medical transaction just as well as > > recreational content, a file transfer may be a virus update or a > virus > > propagation. At some point, the classification decision has to rely > on > > information provided by the source. > > > > In fact, there is no contradiction between the "immutable" > requirement > > that Tony is advocating and Brian's "diffserv handle" requirement. > In > > the diffserv model, the actual classification is based on the 6 > > classifier bits; there is no context that this can be mutable, since > > ISPs must be authorized to reclassify traffic. The reclassification > is > > based on information carried in the packet, part of which is the > label > > affixed by the source; making that label immutable is a good thing, > > since it prevents intermediaries from removing the > > information that can > > be used by a downstream router. > > > > -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 15:35:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TMZE40008482 for ; Wed, 29 Aug 2001 15:35:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TMZEvS008481 for ipng-dist; Wed, 29 Aug 2001 15:35:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TMZ940008474 for ; Wed, 29 Aug 2001 15:35:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07122 for ; Wed, 29 Aug 2001 15:35:17 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13906 for ; Wed, 29 Aug 2001 16:35:12 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TMZf308753 for ; Thu, 30 Aug 2001 01:35:41 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 01:32:18 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KRM>; Thu, 30 Aug 2001 01:30:32 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198002@esebe004.NOE.Nokia.com> To: alh-ietf@tndh.net, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: Another idea for the flow label Date: Thu, 30 Aug 2001 01:35:12 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Why would any subsequent provider give a S on what the origin intended? Without mutual charging arrangement that is. For that we have the Integrated Services model already. There is difference in "muting" to only locally understood value and to globally standardized values. All this discussion is based on an assumption that a diffserv domain egress cannot map from a local (yes, it's own) DSCP->PHB mapping to a standard recommended DSCP value for the same (or equivalent) PHB. If this mapping CAN be done, that is what NEEDS to be done, and we can forget this whole discussion. This far Brian has maintained that this cannot be forced on The Operators. Jarno Tony Hain wrote: > > Jarno Rajahalme wrote: > > > 9. this form is MUTABLE: > > > > If the intention is to enable contractual aggregation needed > > by e.g. the > > diffserv model, domain must be able to remark the value > > (change it), but > > also the new value needs to be taken from the set of > > standardized values, so > > that the semantics of the value is always unambiguous. The > > mutability allows > > cutting off "freeloaders" (as put so eloquently by Steve > > Blake), and enables > > the diffserv aggregation model. > > I am sorry, but this is BS. The diffserv model already > has a mutable field giving the provider ultimate control > and doesn't need a second one. In fact allowing this > proposed use to be mutable will ensure that subsiquent > providers have no clue what the origin intended. If the > provider wants to cut people off, it can set the TC to 0, > or drop the packet. Allowing providers to modify these > bits adds no value to the existing diffserv capabilities. > > Tony > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 15:56:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TMup40008546 for ; Wed, 29 Aug 2001 15:56:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TMuo2C008545 for ipng-dist; Wed, 29 Aug 2001 15:56:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TMum40008538 for ; Wed, 29 Aug 2001 15:56:48 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f7TMsmd09303 for ipng@sunroof.eng.sun.com; Wed, 29 Aug 2001 15:54:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7SEOL40004227 for ; Tue, 28 Aug 2001 07:24:21 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04289 for ; Tue, 28 Aug 2001 07:24:29 -0700 (PDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11384 for ; Tue, 28 Aug 2001 07:24:27 -0700 (PDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 28 Aug 2001 10:22:41 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P5AJK97L; Tue, 28 Aug 2001 10:24:18 -0400 From: "Kastenholz, Frank" To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Message-Id: <5.0.2.1.2.20010828100429.027ac010@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 28 Aug 2001 10:12:26 -0400 Subject: Re: Higher level question about flow label In-Reply-To: <3B86D0EA.50CC1CC8@hursley.ibm.com> References: <5.0.2.1.2.20010824131420.0266cce0@uniwest1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian You're missing my point. Yes, there are some silicon forwarders that can be easily adapted to changes in the header fields -- assuming that those changes are within the range of flexibility that was already placed in the silicon. ASICs are less flexibile than FPGAs which are less flexible than NP's. But all that is more or less irrelevant. The issue is the "format" of the flowid. I'd code things up to classify on the full 20 bits of the flowid and be done with it. That way, I will not have to go back into the forwarder design, _regardless_ of the environment. Any time we have to change code, it's a bad thing -- bugs can creep in, unintended behaviors can result, performance can suffer. Even if the silicon is flexible, it has some "programming" and that programming would have to change if I made it too aware of the internal details of the field. Frank Kastenholz At 05:10 PM 8/24/01 -0500, Brian E Carpenter wrote: >Frank, > >Not all network processors have the degree of inertia >you describe. I know of at least one that can adapt to >format changes without new silicon. But that aside, >what I am talking about is multi-field classifiers in >border routers, not what happens in core/trunk routers >where you are completely correct - that is why the diffserv >code point is 6 bits (sorry, we couldn't squeeze to 4). >Multi-field classifiers don't need to be "slow path" but >they aren't subject to quite the constraints you mention, >in the diffserv architecture. > >This is the essence of why diffserv scales and intserv >doesn't- you only need to do multi-field classification >at the borders. Actually the format we are proposing >simplifies MF classifiers because it takes away the need >to look at port and protocol numbers. > > Brian > >"Kastenholz, Frank" wrote: >> >> All this talk about the format of the flow-id field >> is rather interesting. But one thing has been missing -- >> input from someone who will actually _look_ at the >> field, at very very very high speeds, in hardware, >> and make forwarding decisions based on it. >> >> I am fairly confident in saying that there will not >> be many sqmm of silicon devoted to determining >> if the flow id is 'intserv-format' or 'diff-serv >> format' or 'tennis-serv format'. The edit/compile >> /debug loop of silicon is such that we can not >> react soon enough to the next format that is >> developed. This means that the flowid looker- >> upper will be very very general. That means >> that we don't care what the format is. We just >> take the whole 20-bits and look 'em up (e.g., >> throw them all at a CAM, and see what comes out) >> >> The only thing that would make the looker-upper's >> job easier is to know that the flow-id is going >> going to be shorter than 20 bits (maybe via the >> protocol specification, maybe via some software >> magic ala MPLS label negotiations). A looker-upper >> that is limited to 4 bits is a different beast >> than a looker-upper that does 20. >> >> So, you folks can argue all you want about the format >> of the flow-id and those format differences may matter >> at some level in the software. But to the people who >> are the actual customers of the bits -- the silicon >> forwarders -- it just doesn't matter. >> >> Frank Kastenholz >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home 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 Aug 29 16:03:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TN3640008565 for ; Wed, 29 Aug 2001 16:03:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TN36au008564 for ipng-dist; Wed, 29 Aug 2001 16:03:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TN3240008557 for ; Wed, 29 Aug 2001 16:03:02 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03010 for ; Wed, 29 Aug 2001 16:03:10 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA02159 for ; Wed, 29 Aug 2001 16:03:09 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 16:02:13 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 32E0947163714D61813E770CB3B8F9A7 for plus 3 more; Wed, 29 Aug 2001 16:02:13 -0700 Reply-To: From: "Tony Hain" To: , Cc: , Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 16:02:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009CA59D1752DD448E07F8EB2F911757197FFE@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 48AAEC66-D89B4467-86AF6F77-146F1F10 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TN3240008558 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno Rajahalme wrote: > The originator CAN set the DSCP bits, as specified by the > agreement with the access operator. Since the setting is not well known you will find that end systems and applications are unable to figure out how to mark them. Consider I use my laptop at home, in the office, and at Starbucks. How does the OS or the app know which SLA is applicable and which way to mark the bits? If I had RSVP with DCLASS the first hop could tell the OS, but we are talking about a strict diffserv environment. > > There must be a mechanism for the > > endpoint to inject intent or there will be no reason to pay. > All that is missing is a standardized usage of DSCP ... Thank you. I have been trying to make this point, but don't seem to be finding the right words. > It may be hard to map from end-to-end semantics to > per-hop-behavior. So > maybe you meant more like "standardized semantics". See my comment on > mutability above. I got the words out of order that time. What I had been saying is 'a visisble set of end-to-end immutable bits with well-known semantics'. The point is that current diffserv networks work because all the providers can see the end-to-end immutable protocol/port bits and make local decisions based on their interpretations of the well-known semantics of those values. There is no reason that using a different set of bits would suddenly mean those have to be mutable. To the extent the system works today with the end-to-end immutable protocol/port bits, it will work with an immutable flow label. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 16:07:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TN7l40008587 for ; Wed, 29 Aug 2001 16:07:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TN7lqJ008586 for ipng-dist; Wed, 29 Aug 2001 16:07:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TN7h40008579 for ; Wed, 29 Aug 2001 16:07:43 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13875 for ; Wed, 29 Aug 2001 16:07:51 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04076 for ; Wed, 29 Aug 2001 16:07:50 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 16:07:17 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id BED471275ADA461C8A921BB92DFC72A6 for plus 2 more; Wed, 29 Aug 2001 16:07:17 -0700 Reply-To: From: "Tony Hain" To: , Cc: Subject: RE: Higher level question about flow label Date: Wed, 29 Aug 2001 16:07:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009CA59D1752DD448E07F8EB2F91175715D4CD@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 31351E7D-E18A4D2C-B0186D9D-D5D1D716 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TN7i40008580 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno Rajahalme wrote: > If there would be no local mapping of the DSCP value, > I don't see why it should not > work over multiple domains. I agree completely, but that was my point about trust. The operators were telling the diffserv WG that they would refuse to deploy unless they had the ability to ignore what the origin said and mark the bits the way they wanted to because they couldn't trust the origin not to lie. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 16:12:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNCr40008626 for ; Wed, 29 Aug 2001 16:12:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TNCrDD008625 for ipng-dist; Wed, 29 Aug 2001 16: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNCn40008618 for ; Wed, 29 Aug 2001 16:12:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27314 for ; Wed, 29 Aug 2001 16:12:57 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01685 for ; Wed, 29 Aug 2001 17:13:22 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TNDK314722 for ; Thu, 30 Aug 2001 02:13:21 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 02:07:12 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KTB>; Thu, 30 Aug 2001 02:07:22 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198003@esebe004.NOE.Nokia.com> To: huitema@windows.microsoft.com, brian@hursley.ibm.com, alh-ietf@tndh.net Cc: ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Thu, 30 Aug 2001 02:12:01 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema wrote: > I believe you are wrong. On obvious counter-example comes if > the sender > has no privilege with the sender's ISP, but the receiver has these > privileges. In that case, the packet is marked as "priority high, > traffic type X" by the sender; the sender ISP's rewrites that to > "priority standard, traffic type X"; the receiver's ISP rewrites to > "priority high, traffic type X." > Assuming that the domain ingress would check the SLA with the eventual next domain after the domain egress, in addition to the SLA with the immediate traffic origin, yes. This in the diffserv specs? Anyway, your example assumes existence of an indication for the traffic type, that does not exist. If it would, it would open opportunities for some interesting DoS attacks, wouldn't it? Another way to a similar scenario would be for the receiver to arrange partial path reservation from the ISP in question onwards with explicit signaling. I'd guess GPRS with the radio bearer QoS extended to the GGSN would suffice as an example. A variation of RSVP could do the same for any IP terminal. I'd believe this will come up in NSIS, when it gets going. But this would be flow specific, intserv-like stuff. > By the way, many people seem to believe that diffserv necessarily ties > with monetary exchanges. That is not necessary, if for example you > implement "alternative best effort" and get 2 best effort classes, one > for "high throughput, low loss", and one for "low delay, possible > losses." > This assumes that the service got from the 2 classes is equally useful (or that the applications that can benefit from these different classes are equally useful to the end users). Would not work if the other is clearly more useful than the other. And even if both classes are equally useful, and there is actual benefit of the 2 best effort classes, the operator's would be fool not to try charge extra (maybe an extra $1/mo?) for offering this choice. Customer retention can also be expressed in monetary terms. People are willing to pay (more) for the more predictably successful "dial-in experience" to their ISPs. At least a year ago the phone operators in U.S. still charged $1/mo for *tone dialing*... Could save by subscribing to pulse dial only :-) I think that by definition, if there is differentiation to the user experience, there needs to be monetary difference somewhere. 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 Aug 29 16:18:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNId40008645 for ; Wed, 29 Aug 2001 16:18:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TNIdRu008644 for ipng-dist; Wed, 29 Aug 2001 16:18:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNIZ40008637 for ; Wed, 29 Aug 2001 16:18:35 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28230 for ; Wed, 29 Aug 2001 16:18:43 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08058 for ; Wed, 29 Aug 2001 16:18:42 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 16:17:27 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id DE1BCBA22E164F7EAB3376C188DAE00A for plus 3 more; Wed, 29 Aug 2001 16:17:27 -0700 Reply-To: From: "Tony Hain" To: , Cc: , Subject: RE: Higher level question about flow label Date: Wed, 29 Aug 2001 16:17:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009CA59D1752DD448E07F8EB2F911757198000@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 79CEF386-7BCE403C-B76D96DF-0D05E193 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TNIa40008638 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno Rajahalme wrote: > I might be wrong, but it seems that unless there is a case > where a locally > used DSCP value for a PHB cannot be mapped back to a standardized, PHB > definition recommended DSCP value at the domain egress, there > is no need for > additional support from the flow label. Thank you for making this point, because you have done it better than I have been able to. If the DSCP is consistent from end-to-end, each domain can make its own decisions. I really don't care what they do with the bits in the middle, as long as they exit the domain like they entered it. We don't need to redefine the flow label if the diffserv WG will simply define a set of standard DSCP values for interdomain use. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 16:26:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNQ740008685 for ; Wed, 29 Aug 2001 16:26:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TNQ7f2008684 for ipng-dist; Wed, 29 Aug 2001 16:26:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNQ440008677 for ; Wed, 29 Aug 2001 16:26:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17549 for ; Wed, 29 Aug 2001 16:26:12 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19190 for ; Wed, 29 Aug 2001 16:26:11 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TNQa316649 for ; Thu, 30 Aug 2001 02:26:36 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 02:20:14 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KTS>; Thu, 30 Aug 2001 02:21:27 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D4D5@esebe004.NOE.Nokia.com> To: alh-ietf@tndh.net, aconta@txc.com Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Thu, 30 Aug 2001 02:26:07 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Jarno Rajahalme wrote: > > > The originator CAN set the DSCP bits, as specified by the > > agreement with the access operator. > > Since the setting is not well known you will find that > end systems and applications are unable to figure out how > to mark them. Consider I use my laptop at home, in the > office, and at Starbucks. How does the OS or the app > know which SLA is applicable and which way to mark the > bits? If I had RSVP with DCLASS the first hop could > tell the OS, but we are talking about a strict diffserv > environment. > AAA should enable the Starbucks domain to know what you are paying for. Agree with the signaling case: Your laptop could ask for specific QoS (hopefully in application independent terms) and the first hop could tell you what DSCP to use to get that. There would probably need to be some monetary flow from you to Starbucks, if best effort would be all they are willing to give away to attract customers. That monetary flow could be via your AAA home domain (that could be e.g. your credit card company), and could be based on either flat rate or per usage charging. But I think somehow the scenario for the diffserv flow label has been intra-domain, between operators. The first hop can be solved by the diffserv WG alone by devising a suitable PHB-group. > > > > There must be a mechanism for the > > > endpoint to inject intent or there will be no reason to pay. > > > All that is missing is a standardized usage of DSCP ... > > Thank you. I have been trying to make this point, but > don't seem to be finding the right words. > > > > It may be hard to map from end-to-end semantics to > > per-hop-behavior. So > > maybe you meant more like "standardized semantics". See my > comment on > > mutability above. > > I got the words out of order that time. What I had been > saying is 'a visisble set of end-to-end immutable bits > with well-known semantics'. The point is that current > diffserv networks work because all the providers can > see the end-to-end immutable protocol/port bits and > make local decisions based on their interpretations > of the well-known semantics of those values. There is > no reason that using a different set of bits would > suddenly mean those have to be mutable. To the extent > the system works today with the end-to-end immutable > protocol/port bits, it will work with an immutable > flow label. The point is, IMO the system doesn't work with the intra-domain 5-tuple MF-classifiers as specified today. Maybe no-one has tried out setting intra-operator SLAs based on protocol fields set by hosts (being outside of the control of both the operators)? 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 Aug 29 16:26:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNQG40008695 for ; Wed, 29 Aug 2001 16:26:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TNQF0g008694 for ipng-dist; Wed, 29 Aug 2001 16:26:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNQB40008687 for ; Wed, 29 Aug 2001 16:26:12 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17595 for ; Wed, 29 Aug 2001 16:26:20 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10900 for ; Wed, 29 Aug 2001 16:26:19 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 16:26:12 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 9851B7D979D44499B94D00C5E1579931 for plus 2 more; Wed, 29 Aug 2001 16:26:11 -0700 Reply-To: From: "Tony Hain" To: , , Subject: RE: Another idea for the flow label Date: Wed, 29 Aug 2001 16:26:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009CA59D1752DD448E07F8EB2F911757198002@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 60F19A87-3E544E4B-9E27ED07-D60E9C8F Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TNQC40008688 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno Rajahalme wrote: > Why would any subsequent provider give a S on what the origin > intended? Because they do that now by snooping the immutable protocol / port bits. If they had a standard set of DSCP values to work with they could use those. > There is difference in "muting" to only locally understood > value and to > globally standardized values. Yes, but if the original meaning is lost one of the downstream providers would have no way to resurect it. > All this discussion is based on an assumption that a diffserv > domain egress > cannot map from a local (yes, it's own) DSCP->PHB mapping to > a standard > recommended DSCP value for the same (or equivalent) PHB. If > this mapping CAN > be done, that is what NEEDS to be done, and we can forget this whole > discussion. I agree completely. > This far Brian has maintained that this cannot be > forced on The Operators. He is correct it can't be forced, but the standard could say MUST and a BCP could be written to enforce it. What he is concerned about is that if those actions were taken several operators have said they will not deploy. Which is worse, having them deploy something that is useless in the end, or refusing to deploy what they will reluctantly have to do in another form? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 16:36:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNaM40008724 for ; Wed, 29 Aug 2001 16:36:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TNaMaJ008723 for ipng-dist; Wed, 29 Aug 2001 16:36:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNaJ40008716 for ; Wed, 29 Aug 2001 16:36:19 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19542 for ; Wed, 29 Aug 2001 16:36:27 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21113 for ; Wed, 29 Aug 2001 17:36:22 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7TNap317890 for ; Thu, 30 Aug 2001 02:36:51 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 30 Aug 2001 02:30:42 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSV0KT8>; Thu, 30 Aug 2001 02:31:42 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175715D4D6@esebe004.NOE.Nokia.com> To: alh-ietf@tndh.net, aconta@txc.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Higher level question about flow label Date: Thu, 30 Aug 2001 02:36:20 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > I agree completely, but that was my point about trust. The > operators were telling the diffserv WG that they would > refuse to deploy unless they had the ability to ignore what > the origin said This far I understand... > and mark the bits the way they wanted to > because they couldn't trust the origin not to lie. ...but I fail to understand why should want to do anything else than remark to best effort if they do not trust the previous operator. Additionally, if the operators have an SLA, they could police the traffic and shape/remark to make the traffic to conform to the SLA without caring a bit about what's in the transport headers. All sort of un-called-for optimizations in the "middle boxes" are very likely to cause problems later on. 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 Aug 29 16:53:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNrn40008749 for ; Wed, 29 Aug 2001 16:53:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TNrniO008748 for ipng-dist; Wed, 29 Aug 2001 16:53:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNrj40008741 for ; Wed, 29 Aug 2001 16:53:45 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03976 for ; Wed, 29 Aug 2001 16:53:53 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA22264 for ; Wed, 29 Aug 2001 16:53:52 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 16:53:17 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 6FE0696B4F5F4D2E83425F73B5AF4A27 for plus 3 more; Wed, 29 Aug 2001 16:53:16 -0700 Reply-To: From: "Tony Hain" To: , Cc: , Subject: RE: a), b), c), d), or e) Date: Wed, 29 Aug 2001 16:53:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009CA59D1752DD448E07F8EB2F91175715D4D5@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: D8DF9424-3EE44034-B34A35BD-62095D3D Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TNrj40008742 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno Rajahalme wrote: > AAA should enable the Starbucks domain to know what you are > paying for. Without a standard set of DSCP values what good does that do me? > But I think somehow the scenario for the diffserv flow label has been > intra-domain, between operators. And this is the problem. The operators are finding that making the DSCP completely random has resulted in a useless technology. The flow label is an end-to-end field so there is a hope they can restore what they need, but at the same time these bits are being made mutable. > The first hop can be solved by the diffserv > WG alone by devising a suitable PHB-group. If they had only done that to begin with. > The point is, IMO the system doesn't work with the > intra-domain 5-tuple > MF-classifiers as specified today. I was being very careful not to use the 5-tuple because the src/dst addresses are mutable thanks to NAT. The only end-to-end consistent bits are the protocol & port, and the flow label. > Maybe no-one has tried out setting > intra-operator SLAs based on protocol fields set by hosts > (being outside of > the control of both the operators)? It works as long as long as there is a trust or financial relationship which creates feedback. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 16:58:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNwn40008768 for ; Wed, 29 Aug 2001 16:58:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7TNwn53008767 for ipng-dist; Wed, 29 Aug 2001 16:58:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7TNwj40008760 for ; Wed, 29 Aug 2001 16:58:45 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24226 for ; Wed, 29 Aug 2001 16:58:54 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24201 for ; Wed, 29 Aug 2001 16:58:53 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 29 Aug 2001 16:58:21 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id F87E45CBFBE14C4794864448C4C5824F for plus 2 more; Wed, 29 Aug 2001 16:58:20 -0700 Reply-To: From: "Tony Hain" To: , Cc: Subject: RE: Higher level question about flow label Date: Wed, 29 Aug 2001 16:58:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <009CA59D1752DD448E07F8EB2F91175715D4D6@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: A1E78B72-1311420F-A7D46F7C-33B1202F Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7TNwk40008761 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno Rajahalme wrote: > ...but I fail to understand why should want to do anything > else than remark > to best effort if they do not trust the previous operator. Because their customer may be the destination and the SLA on that side says treat all protocol X traffic from Y as high priority. > Additionally, if > the operators have an SLA, they could police the traffic and > shape/remark to > make the traffic to conform to the SLA without caring a bit > about what's in > the transport headers. Based on what? > All sort of un-called-for optimizations in the "middle boxes" are very > likely to cause problems later on. No argument... :) Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 20:08:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U38r40009030 for ; Wed, 29 Aug 2001 20:08:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7U38r3r009029 for ipng-dist; Wed, 29 Aug 2001 20:08:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U38n40009022 for ; Wed, 29 Aug 2001 20:08:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26142 for ; Wed, 29 Aug 2001 20:08:57 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22298 for ; Wed, 29 Aug 2001 20:08:54 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA11622; Thu, 30 Aug 2001 12:08:36 +0900 (JST) Date: Thu, 30 Aug 2001 12:08:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy Brabson" Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 51 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 29 Aug 2001 13:29:30 -0400, >>>>> "Roy Brabson" said: > The diagram which follows shows, as a default, what is described above: > that two interfaces on a single link are, by default, given unique > link-local scope IDs. This doesn't address an automatic way to learn about > a link-local or site-local zone, but then again any such mechanism can be > made to include the appropriate zone name at the same time it configures > the zone. Correct, but the draft does not recommend nor suggest to introduce such mechanism. There is no reason to reject it, but there is no reason to force it. Anyway, I guess the point is the next discussion below: > The textual representation is more readable, but I don't find it > substantially more useful. It still doesn't help anyone understand which > site or which link is being used. How does someone using a zone such as > "site1" have any idea which zone the packet will be sent, or which > interfaces are defined to be within that zone? As I have repeatedly said, the textual representation like "site1" is as unusable as numeric identifiers. It's just to improve readability, and the draft does not reject using more intuitive "names"; the draft does just not specify the concrete definition of names, which I think is overspecification in an architecture draft. > The "names" used to configure zones is going to be platform-unique. I > guess I'd just prefer to see the values used by and returned from the DNS > resolver incorporate those names vs. something like "link1" or "site1". By > default, for link-local this is the interface name. So I guess we should treat this issue in a related API discussion. I'd like to propose the following approach: - the scoping architecture draft only defines the numerical zone IDs and their aliases for readability (like "site1") - the scoping architecture draft does NOT define the zone "names", but mentions that implementation can use intuitive names in the textual representation, and that interface names can be used as interface/link/subnet zone IDs by default. - write a separate informational document, which talks about the API of the scoping issues, including possible representation of names, and mapping of numerical identifiers and names. Is this okay for you? 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 Aug 29 20:12:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U3CH40009065 for ; Wed, 29 Aug 2001 20:12:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7U3CHbx009064 for ipng-dist; Wed, 29 Aug 2001 20:12:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U3CC40009057 for ; Wed, 29 Aug 2001 20:12:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA26467 for ; Wed, 29 Aug 2001 20:12:21 -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 VAA19067 for ; Wed, 29 Aug 2001 21:12:13 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA11646; Thu, 30 Aug 2001 12:12:05 +0900 (JST) Date: Thu, 30 Aug 2001 12:12:22 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Dave Thaler" Cc: Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC10290E640@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC10290E640@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 29 Aug 2001 12:08:21 -0700, >>>>> "Dave Thaler" said: >> When we can assume one-to-one mapping between interfaces and links, >> that's true. However, if two (or more) different interfaces belong >> to a single link, using interface names as link IDs would be rather >> confusing (we'll lose the uniqueness of the ID, or we'll have to care >> about which interface is "primary" in the link".) > I'd point out that with the "flexible 4+28" method, specifying "eth0" in > place of "link12" would work, regardless of whether there was 1 or > multiple interfaces attached to link12. Another advantage of the > flexible method :) Probably, but even so, we'll still lose the uniqueness of zone IDs. 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 Aug 29 20:15:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U3Fp40009082 for ; Wed, 29 Aug 2001 20:15:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7U3Fp3v009081 for ipng-dist; Wed, 29 Aug 2001 20:15:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U3Fl40009074 for ; Wed, 29 Aug 2001 20:15:47 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18803 for ; Wed, 29 Aug 2001 20:15:56 -0700 (PDT) Received: from clyde.stargateip.com ([209.237.5.66]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21485 for ; Wed, 29 Aug 2001 20:15:55 -0700 (PDT) Received: from sarayu (dhcp-116.stargateip.com [10.10.5.116]) by clyde.stargateip.com (8.9.1/8.9.1) with SMTP id UAA08291 for ; Wed, 29 Aug 2001 20:10:07 -0700 (PDT) From: "Venkat Bandaaru" To: Subject: Need some inputs Date: Wed, 29 Aug 2001 20:20:35 -0500 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.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi , I am new to networking, and my work is related to ipv6 development. I have a basic question, why do we need the hop-by-hop extension header. If you feel this is a silly question to ask in the forum , please provide me some source from where I can understand all the things. Thanks and Regs -Venkat ============================================================================ This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this e-mail by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 20:53:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U3r740009114 for ; Wed, 29 Aug 2001 20:53:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7U3r68T009113 for ipng-dist; Wed, 29 Aug 2001 20:53:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U3r340009106 for ; Wed, 29 Aug 2001 20:53:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA08891 for ; Wed, 29 Aug 2001 20:53:12 -0700 (PDT) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02985 for ; Wed, 29 Aug 2001 20:53:12 -0700 (PDT) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 29 Aug 2001 21:53:11 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 29 Aug 2001 21:52:03 -0600 From: "Bhuvaneshwar hn" To: , Subject: Re: Need some inputs Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_D18B6AB7.FD9C0857" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_D18B6AB7.FD9C0857 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable IPv4 uses a Variable length header which allows 40 bytes of optional = information after the basic part of the header, but that way of supporting= options has not been successful for various reasons like performance = penalty incurred and the 40 byte limit. In IPv6 the same is supported as extension headers which can be present or = not depending on what type of packet you are sending. Hop by Hop options = header is one of extension header's which is present immediately after the = IPv6 Header which supports carrying large packets up to 4GB. The basic = part of the header limits the size to 16bits. This option header carries = 32bit payload length field for such large packets. Also it supports Router = Alert Option which is used to indicate to the router that the contents of = the packet require additional processing.=20 =20 Refer RFC2460 for further details. =20 >>> "Venkat Bandaaru" 08/30/01 06:50AM >>> Hi , I am new to networking, and my work is related to ipv6 development. I have a basic question, why do we need the hop-by-hop extension header. If you feel this is a silly question to ask in the forum , please provide me some source from where I can understand all the things. Thanks and Regs -Venkat =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this e-mail by anyone else is unauthorized. If you = are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng=20 FTP archive: ftp://playground.sun.com/pub/ipng=20 Direct all administrative requests to majordomo@sunroof.eng.sun.com=20 -------------------------------------------------------------------- --=_D18B6AB7.FD9C0857 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
IPv4 uses a Variable length header which allows  40 bytes of = optional=20 information after the basic part of the header,  but that way=20 of supporting options has not been successful for various reasons = ;like=20 performance penalty incurred and the 40 byte limit.
In IPv6 the same is supported as extension headers which can = be=20 present or not depending on what type of packet you are sending. Hop by = Hop=20 options header is one of extension header's which is present immediately = after=20 the IPv6 Header which supports carrying large packets up to 4GB. The basic = part=20 of the header limits the size to 16bits. This option header carries = 32bit=20 payload length field for such large packets. Also it supports Router = Alert=20 Option which is used to indicate to the router that the contents of the = packet=20 require additional processing.
 
Refer RFC2460 for further details.
 
>>> "Venkat Bandaaru" <venkatb@stargateip.com> = 08/30/01=20 06:50AM >>>
Hi ,
I am new to networking, and my work is = related=20 to ipv6 development.
I have a basic question, why do we need the = hop-by-hop=20 extension header.

If you feel this is a silly question to ask in = the=20 forum ,
please provide me some source from where I can understand all = the=20 things.

Thanks and=20 Regs

-Venkat

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 =20 This email and any files transmitted with it are confidential and=20 are
intended solely for the use of the individual or entity to which = they=20 are
addressed. Access to this e-mail by anyone else is unauthorized. If = you=20 are
not the intended recipient, any disclosure, copying, distribution = or=20 any
action taken or omitted to be taken in reliance on it, is=20 prohibited.

--------------------------------------------------------= ------------
IETF=20 IPng Working Group Mailing List
IPng Home=20 Page:           &nbs= p;         =20 http://playground.sun.com/ipng<= BR>FTP=20 archive:           &= nbsp;         =20 ftp://playground.sun.com/pub/ipn= g
Direct=20 all administrative requests to=20 majordomo@sunroof.eng.sun.com
------------------------------------------= --------------------------
--=_D18B6AB7.FD9C0857-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 29 22:18:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U5Iu40009179 for ; Wed, 29 Aug 2001 22:18:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7U5ItOP009178 for ipng-dist; Wed, 29 Aug 2001 22:18:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U5Iq40009171 for ; Wed, 29 Aug 2001 22:18:52 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09567 for ; Wed, 29 Aug 2001 22:19:02 -0700 (PDT) Received: from web9205.mail.yahoo.com (web9205.mail.yahoo.com [216.136.129.38]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA23994 for ; Wed, 29 Aug 2001 22:19:02 -0700 (PDT) Message-ID: <20010830051901.75981.qmail@web9205.mail.yahoo.com> Received: from [161.139.68.13] by web9205.mail.yahoo.com via HTTP; Wed, 29 Aug 2001 22:19:01 PDT Date: Wed, 29 Aug 2001 22:19:01 -0700 (PDT) From: pat nanthan Subject: ipv6 authentication header To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi.I want to know how am i supposed to develope or proof that in terms of security aspect ipv6 has the capability in authentication,message integrity and privacy and i want to solve confidentiality issue in ecommerce transactions? I need some help here. thanks __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 29 23:12:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U6C740009275 for ; Wed, 29 Aug 2001 23:12:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7U6C7l7009274 for ipng-dist; Wed, 29 Aug 2001 23:12:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7U6C440009267 for ; Wed, 29 Aug 2001 23:12:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13314 for ; Wed, 29 Aug 2001 23:12:13 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA10175 for ; Thu, 30 Aug 2001 00:12:39 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7U6C9W30866; Thu, 30 Aug 2001 09:12:09 +0300 Date: Thu, 30 Aug 2001 09:12:09 +0300 (EEST) From: Pekka Savola To: cc: Subject: Re: Flow label mutability (was RE: a), b), c), d), or e)) In-Reply-To: <009CA59D1752DD448E07F8EB2F911757197FFF@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [snip a lot, including Cc:] On Thu, 30 Aug 2001 jarno.rajahalme@nokia.com wrote: > PS: Aren't the "well known ports" defined just to facilitate end-to-end > rendezvous? Quite a leap to base any policy decisions on ports... I think this may have been your point, but to put it another way: Please note that the list of "well-known ports" is about 430 KB long the last I looked, and they're used quite happily as ephemeral ports. -- 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 Aug 30 04:00:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UB0L40009651 for ; Thu, 30 Aug 2001 04:00:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UB0Kk8009650 for ipng-dist; Thu, 30 Aug 2001 04:00:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UB0H40009643 for ; Thu, 30 Aug 2001 04:00:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01253 for ; Thu, 30 Aug 2001 04:00:24 -0700 (PDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29460 for ; Thu, 30 Aug 2001 05:00:19 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f7UAtSj04670; Thu, 30 Aug 2001 06:55:29 -0400 Message-Id: <200108301055.f7UAtSj04670@hygro.adsl.duke.edu> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: set@thumper.bellcore.com, ipng@sunroof.eng.sun.com Subject: Re: StoredLifetime in RFC 2462 In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Wed, 29 Aug 2001 23:22:27 +0900." Date: Thu, 30 Aug 2001 06:55:28 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > I have a quick question about RFC2462 (stateless address > autoconfiguration). I know we've had a similar discussion before, but > please let me repeat it... > The RFC defines the notion of "StoredLifetime" as follows: > e) If the advertised prefix matches the prefix of an autoconfigured > address (i.e., one obtained via stateless or stateful address > autoconfiguration) in the list of addresses associated with the > interface, the specific action to perform depends on the Valid > Lifetime in the received advertisement and the Lifetime > associated with the previously autoconfigured address (which we > call StoredLifetime in the discussion that follows): > In my understanding, StoredLifetime is the "remaining" lifetime to > expiration at the time when the new Router Advertisement is received. > So, for example, if we first received a prefix with the valid lifetime > being 7200 seconds, and then received a next advertisement 1800 > seconds later, the StoredLifetime corresponding to the address from > the prefix should be 5400 (= 7200 - 1800) seconds. Yes, that is how this should be interpreted. > I believe this interpretation is correct, and I've implemented RFC > 2462 in this manner. However, a user of our implementation said it > was *not* what RFC2462 says, because > > all "Lifetime associated with the address" pseudo-definitions are > > very, very careful not to say the Lifetime is actually being > > decremented. > (cited the user's message) A quick scan of the text suggests to me that this could be worded a bit better than it currently is. > But is there any other interpretation of StoredLifetime? I'm now > confused, so I'd like to hear authors' intention. This author agrees with your original intepretation. 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 Aug 30 04:15:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UBFd40009718 for ; Thu, 30 Aug 2001 04:15:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UBFcEP009717 for ipng-dist; Thu, 30 Aug 2001 04:15:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UBFW40009705 for ; Thu, 30 Aug 2001 04:15:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05666 for ; Thu, 30 Aug 2001 04:15:35 -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 FAA27256 for ; Thu, 30 Aug 2001 05:16:02 -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 HAA09888; Thu, 30 Aug 2001 07:14:11 -0400 (EDT) Message-Id: <200108301114.HAA09888@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-gopinath-host-name-resolution-protocol-ipv6-00.txt Date: Thu, 30 Aug 2001 07:14:11 -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 : Host Name Resolution Protocol (HNRP) for IPv6 nodes Author(s) : G. Sinniah et al. Filename : draft-gopinath-host-name-resolution- protocol-ipv6-00.txt Pages : 13 Date : 29-Aug-01 This document describes a new method, which will automatically acquire the host name of active IPv6 nodes and register it to the local Domain Name System (DNS) server. Active IPv6 nodes are nodes that are connected to a network. Our proposed new protocol, which is called Host Name Resolution Protocol (HNRP) [6], will automatically learn some useful information from all the IPv6 nodes, such as the host name and the IP address. All the information will be kept by HRRP and the host name together with the IPv6 address will be added to the DNS. This will be implemented without the need for any changes at the clients' site. The objective of this document is to specify the new Host Name Resolution Protocol and also the algorithm used in the protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-gopinath-host-name-resolution-protocol-ipv6-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-gopinath-host-name-resolution-protocol-ipv6-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-gopinath-host-name-resolution-protocol-ipv6-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: <20010829144352.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-gopinath-host-name-resolution-protocol-ipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-gopinath-host-name-resolution-protocol-ipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010829144352.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 Aug 30 04:15:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UBFc40009716 for ; Thu, 30 Aug 2001 04:15:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UBFbiM009715 for ipng-dist; Thu, 30 Aug 2001 04:15:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UBFV40009701 for ; Thu, 30 Aug 2001 04:15:31 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02176 for ; Thu, 30 Aug 2001 04:15:38 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27834 for ; Thu, 30 Aug 2001 04:15:38 -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 HAA09931; Thu, 30 Aug 2001 07:14:16 -0400 (EDT) Message-Id: <200108301114.HAA09931@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-roesler-ipngwg-ipngls-00.txt Date: Thu, 30 Aug 2001 07:14:16 -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 : IPNGLS - IP Next Generation Label Switching Author(s) : V. Roesler et al. Filename : draft-roesler-ipngwg-ipngls-00.txt Pages : 17 Date : 29-Aug-01 This document proposes the forwarding of IPv6 packets using label switching techniques, with the same advantages of the Multiprotocol Label Switching (MPLS) architecture. The document proposes the mapping of all MPLS header fields into the IPv6 header, raising several advantages like the simplicity of the model, the decrease of overhead, and others. This mapping was called IP Next Generation Label Switching, or just IPngLS, and can work concurrently with MPLS, i.e. IPv6 packets are forwarded with IPngLS and IPv4 packets are forwarded with MPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-roesler-ipngwg-ipngls-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-roesler-ipngwg-ipngls-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-roesler-ipngwg-ipngls-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: <20010829151222.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-roesler-ipngwg-ipngls-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-roesler-ipngwg-ipngls-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010829151222.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 Aug 30 04:26:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UBQh40009757 for ; Thu, 30 Aug 2001 04:26:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UBQhEv009756 for ipng-dist; Thu, 30 Aug 2001 04:26:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UBQc40009749 for ; Thu, 30 Aug 2001 04:26:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06484 for ; Thu, 30 Aug 2001 04:26:46 -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 FAA10914 for ; Thu, 30 Aug 2001 05:26:40 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id UAA15123; Thu, 30 Aug 2001 20:22:52 +0900 (JST) Date: Thu, 30 Aug 2001 20:23:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: set@thumper.bellcore.com, ipng@sunroof.eng.sun.com Subject: Re: StoredLifetime in RFC 2462 In-Reply-To: <200108301055.f7UAtSj04670@hygro.adsl.duke.edu> References: <200108301055.f7UAtSj04670@hygro.adsl.duke.edu> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 30 Aug 2001 06:55:28 -0400, >>>>> Thomas Narten said: >> I believe this interpretation is correct, and I've implemented RFC >> 2462 in this manner. However, a user of our implementation said it >> was *not* what RFC2462 says, because >> > all "Lifetime associated with the address" pseudo-definitions are >> > very, very careful not to say the Lifetime is actually being >> > decremented. >> (cited the user's message) > A quick scan of the text suggests to me that this could be worded a > bit better than it currently is. >> But is there any other interpretation of StoredLifetime? I'm now >> confused, so I'd like to hear authors' intention. > This author agrees with your original intepretation. I see, thanks for the response. I also agree that the wording could be clearer. 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 Aug 30 05:48:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UCmt40009850 for ; Thu, 30 Aug 2001 05:48:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UCmt7r009849 for ipng-dist; Thu, 30 Aug 2001 05:48:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UCmq40009842 for ; Thu, 30 Aug 2001 05:48:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12684 for ; Thu, 30 Aug 2001 05:49:00 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03214 for ; Thu, 30 Aug 2001 06:49:26 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA14920; Thu, 30 Aug 2001 07:46:41 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7UCmrW58414; Thu, 30 Aug 2001 08:48:53 -0400 Subject: Re: Wrap up and last call: sin6_scope_id semantics To: JINMEI Tatuya / =?iso-2022-jp?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Thu, 30 Aug 2001 08:48:40 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 08/30/2001 08:48:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=iso-2022-jp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, 08/30/2001 at 12:08 ZE9, JINMEI Tatuya / $B?@L@C#:H(B wrote: > I'd like to propose the following approach: > > - the scoping architecture draft only defines the numerical zone IDs > and their aliases for readability (like "site1") This is fine. I've never really objected to the aliases, I just don't find them very useful. > - the scoping architecture draft does NOT define the zone "names", but > mentions that implementation can use intuitive names in the textual > representation, and that interface names can be used as > interface/link/subnet zone IDs by default. Good as well. Maybe something like an implementation MAY choose to display the names used in configuring the zones in the textual representation. I just don't want anyone to read the text and think this type of behavior is somehow precluded. > - write a separate informational document, which talks about the API > of the scoping issues, including possible representation of names, > and mapping of numerical identifiers and names. Yes, I think keeping the API discussion out of the standards track RFC makes sense. And I like having the informational RFC for the API issues as well. Roy Brabson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 30 05:51:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UCpQ40009867 for ; Thu, 30 Aug 2001 05:51:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UCpQ62009866 for ipng-dist; Thu, 30 Aug 2001 05:51:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UCpM40009859 for ; Thu, 30 Aug 2001 05:51:22 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24151 for ; Thu, 30 Aug 2001 05:51:30 -0700 (PDT) Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04348 for ; Thu, 30 Aug 2001 05:51:30 -0700 (PDT) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 4A1E17B55; Thu, 30 Aug 2001 08:51:25 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: pat nanthan Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 authentication header Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 30 Aug 2001 08:51:25 -0400 Message-Id: <20010830125125.4A1E17B55@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <20010830051901.75981.qmail@web9205.mail.yahoo.com>, pat nanthan wri tes: > >hi.I want to know how am i supposed to develope or >proof that in terms of security aspect ipv6 has the >capability in authentication,message integrity and >privacy and i want to solve confidentiality issue in >ecommerce transactions? I need some help here. > See RFC 2401, on IPsec. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 30 06:20:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UDKq40009926 for ; Thu, 30 Aug 2001 06:20:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UDKqp2009925 for ipng-dist; Thu, 30 Aug 2001 06:20:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UDKm40009918 for ; Thu, 30 Aug 2001 06:20:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07585 for ; Thu, 30 Aug 2001 06:20:57 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20898 for ; Thu, 30 Aug 2001 06:20:56 -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 f7UDKDt25930; Thu, 30 Aug 2001 15:20:13 +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 PAA13004; Thu, 30 Aug 2001 15:20:13 +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.11.3/8.11.3) with ESMTP id f7UDKDl87345; Thu, 30 Aug 2001 15:20:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108301320.f7UDKDl87345@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Wed, 29 Aug 2001 22:15:16 +0900. Date: Thu, 30 Aug 2001 15:20:12 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Well, as a developer and a user of the KAME IPv6 stack, I prefer fe80::xxxx%eth0 to fe80::xxxs%link12. The implementation (at least currently) assumes one-to-one mapping between interfaces and links, which is natural in a normal operation, and thus eth0 should be more intuitive than link12. => I just want aliases, not only a standard name (i.e. my concern is about one-to-one mapping between zone IDs and names). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 30 06:30:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UDUT40009943 for ; Thu, 30 Aug 2001 06:30:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UDUTCj009942 for ipng-dist; Thu, 30 Aug 2001 06:30:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UDUQ40009935 for ; Thu, 30 Aug 2001 06:30:26 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13961 for ; Thu, 30 Aug 2001 06:30:35 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22291 for ; Thu, 30 Aug 2001 06:29:59 -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 f7UDTBt26832; Thu, 30 Aug 2001 15:29: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 PAA13109; Thu, 30 Aug 2001 15:29:11 +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.11.3/8.11.3) with ESMTP id f7UDTBl87428; Thu, 30 Aug 2001 15:29:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108301329.f7UDTBl87428@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: "Roy Brabson" , ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-reply-to: Your message of Thu, 30 Aug 2001 12:08:52 +0900. Date: Thu, 30 Aug 2001 15:29:11 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: So I guess we should treat this issue in a related API discussion. I'd like to propose the following approach: - the scoping architecture draft only defines the numerical zone IDs and their aliases for readability (like "site1") - the scoping architecture draft does NOT define the zone "names", but mentions that implementation can use intuitive names in the textual representation, and that interface names can be used as interface/link/subnet zone IDs by default. - write a separate informational document, which talks about the API of the scoping issues, including possible representation of names, and mapping of numerical identifiers and names. => what we need is a more general (than "site1") notion of names and the way to translate names to zone IDs and the reverse. The actual syntax and semantics of names are not very important if some simple rules (no % in names for instance) are given. Regards Francis.Dupont@enst-bretagne.fr PS: I am waiting for a concrete proposal (i.e. a draft) PPS: don't forget to update RFC 2732 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 30 10:33:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UHXY40010350 for ; Thu, 30 Aug 2001 10:33:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UHXYfU010349 for ipng-dist; Thu, 30 Aug 2001 10:33:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UHXT40010342 for ; Thu, 30 Aug 2001 10:33:29 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07146 for ; Thu, 30 Aug 2001 10:33:38 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14624 for ; Thu, 30 Aug 2001 10:33:34 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7UHXgv03475; Thu, 30 Aug 2001 10:33:42 -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 AAU08181; Thu, 30 Aug 2001 10:33:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA22681; Thu, 30 Aug 2001 10:33:18 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15246.30942.258859.793354@thomasm-u1.cisco.com> Date: Thu, 30 Aug 2001 10:33:18 -0700 (PDT) To: jarno.rajahalme@nokia.com Cc: brian@hursley.ibm.com, alh-ietf@tndh.net, kgk@igs.net, huitema@windows.microsoft.com, hinden@iprg.nokia.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) In-Reply-To: <009CA59D1752DD448E07F8EB2F911757197FFB@esebe004.NOE.Nokia.com> References: <009CA59D1752DD448E07F8EB2F911757197FFB@esebe004.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com writes: > Just some comments for clarifying some stuff that keeps coming up > repeatedly: > > Brian E Carpenter wrote: > > > > This is a very unfair comment. Diffserv is just fine in the > > case of unencrypted traffic. It has a problem (and so does > > intserv I suspect) with tunnel or transport mode ESP. > > > > IPv4 intserv shares the same difficulty of doing MF-classification with ESP. > However, in IPv6 the flow label can be used in MF-classification for intserv > semantics, even when ESP is used. This is incorrect. RFC 2207 defines a way to classify ESP traffic for intserv *and* it doesn't compromise privacy. What's being floated here for diffserv requires that I compromise privacy in order to work, which I think is bogus. 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 Aug 30 11:28:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UISx40010528 for ; Thu, 30 Aug 2001 11:28:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UISxCZ010527 for ipng-dist; Thu, 30 Aug 2001 11:28:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UISt40010520 for ; Thu, 30 Aug 2001 11:28:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04708 for ; Thu, 30 Aug 2001 11:29:03 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com ([194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20470 for ; Thu, 30 Aug 2001 12:29:29 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA25118 for ; Thu, 30 Aug 2001 19:28:57 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA23788 for ; Thu, 30 Aug 2001 19:28:57 +0100 Message-ID: <3B8E853A.80459556@hursley.ibm.com> Date: Thu, 30 Aug 2001 13:26:02 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt References: <200108301114.HAA09931@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this is a terrible idea for several reasons. 1) MPLS is not a global solution - if it survives at all in the long term, it will be limited to the core of large networks - and there is therefore no real reason to drag its complex mechanisms up into the simple IP layer. In particular we have IP-in-IP tunnel mechanisms, so the complex extension header replacing the S bit is unnecessary. 2) If MPLS has one major virtue, it is the "MP" for Multi-Protocol. This aspect is lost in the proposal. 3) Using the field currently called "flow label" to carry a swappable MPLS-style label defeats the alternative use of this field as an end-to-end field for QOS. The argument currently raging shows that the WG has no consensus about this field, but there has been very little support for an MPLS-like use. Indeed this was one of the options rejected at the beginning of IPv6, when the CATNIP proposal was rejected. Some people will tell you that is why MPLS was invented in the first place. 4) The blind mapping of the 3 bit "EXP" field into the traffic class field makes no sense. In fact, as far as the EXP field has any meaning, it is a compressed version of the traffic class field; writing this compressed version back into the original field is useless. Brian Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IPNGLS - IP Next Generation Label Switching > Author(s) : V. Roesler et al. > Filename : draft-roesler-ipngwg-ipngls-00.txt > Pages : 17 > Date : 29-Aug-01 > > This document proposes the forwarding of IPv6 packets using label > switching techniques, with the same advantages of the Multiprotocol > Label Switching (MPLS) architecture. The document proposes the > mapping of all MPLS header fields into the IPv6 header, raising > several advantages like the simplicity of the model, the decrease of > overhead, and others. This mapping was called IP Next Generation > Label Switching, or just IPngLS, and can work concurrently with > MPLS, i.e. IPv6 packets are forwarded with IPngLS and IPv4 packets > are forwarded with MPLS. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-roesler-ipngwg-ipngls-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 30 13:20:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UKKg40010674 for ; Thu, 30 Aug 2001 13:20:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UKKgtP010673 for ipng-dist; Thu, 30 Aug 2001 13:20:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UKKc40010666 for ; Thu, 30 Aug 2001 13:20:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09608 for ; Thu, 30 Aug 2001 13:20:44 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20226 for ; Thu, 30 Aug 2001 14:20:38 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA32340 for ; Thu, 30 Aug 2001 21:20:40 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA56150 for ; Thu, 30 Aug 2001 21:20:40 +0100 Message-ID: <3B8E9EA6.7D7E5CB8@hursley.ibm.com> Date: Thu, 30 Aug 2001 15:14:30 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng Subject: Portmanteau reply Re: a), b), c), d), or e) References: 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 f7UKKd40010667 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I gave myself 24 hours off from this thread to draw breath. Here are comments on a bunch of points from various people. Tony Hain wrote: ... > But that is the point. If IPsec had been widely deployed in the > IPv4 Internet, diffserv would have been forced to fix the DSCP > end-to-end, because that would be the only alternative. I can only repeat that diffserv did fix the the DSCP values but only with a SHOULD. My private opinion is that in the end the ISPs will need to settle down to using the recommended values across domain boundaries, but what they do in their bilats or within their domains is not something the IETF can dictate. ... > >(But anyway, why > > would it matter if they are mutable, since they aren't covered > > by checksum? I'm not aware of a law of nature against mutable bits.) > > Speak to your co-author who keeps insisting that they are > mutable. Yes, and I think I disagree with him :-) > In any case, the point is that for diffserv to work there > has to be a visible set of bits that are immutable end-to-end > with well-known semantics. Currently that is the protocol/port, > simply because ESP wasn't in widespread use. In IPv6 we assume > it will be, so diffserv needs another set of bits that have an > immutable well-known end-to-end semantic. Well, Alex is correct to the extent that "immutable" is not an absolute requirement; "globally defined" is necessary and sufficient. But as just stated, I prefer immutable. > > > No, that is in fact what we did, but at the specific insistence > > of the ISPs active in the design of diffserv, we made all of > > the mappings SHOULD instead of MUST. You want to ding the WG > > for meeting a clearly stated key requirement of the principal > > customer set? > > In this case yes, because that requirement results in an > inoperable state when security is applied. Not really. It is quite operable if the SLA in place at each domain boundary recognises the upstream DSCP value (see my first comment in this message). The case that isn't covered is ESP packets with no such SLA, and the result will be that those packets get default QOS. If we don't find a solution for that case, it doesn't break diffserv. ... > > Immutablity isn't the problem. Encryption of the port and protocol > > numbers is the problem. I could equally well say that IPSEC should > > go back and fix the invisibility problem they created. > > That is a specific feature. There are many times when you don't > want traffic analysis done on the ports in use and number or sequence > of packets between them. I agree. Traffic analysis concerns could be a show stopper for paranoid users. Alex Conta wrote: > ... > Let's say flow label value 50, is RT traffic between A and B. > > C, D, and E are routers between A, and B. Between A, and C, the RT > traffic to B, has flow > label 50. At router C, the value of 50 changes to 60, and it stays that > way, to E, where it is changed back from 60 to 50. > > Between C and E, the meaning was the same, as between A, and C, and E, > and B, that is > the RT traffic between A and B. > > The flow label bits were mutable, the meaning was immutable. Yes, it *could* work that way but I would argue against it - I'd much rather keep it simple and have the flow label immutable. jarno.rajahalme@nokia.com wrote: ... > > That's an interesting thought, but I think it doesn't work. > > The egress router > > has to *know* that the flow label is in diffserv format, and > > I think that > > requires some magic. > > > > Wouldn't the absence of intserv state for the flow at the domain egress be > the magic for this determination? That's an interesting thought. if flow label != 0 and there is no intserv state then try diffserv classification This needs a little thought but it looks hopeful to me. > > A related question: Flow label field is presumably end-to-end, i.e. > non-mutable. How can some random diffserv domain egress router know if the > flow label value should be honored or not (even if it had a specific format > for the PHB-ID)? All diffserv classifiers require configuration. This would mean configuring a classifier to look for (say) Destination IP = Big Customer X Source IP = * Flow Label = 12345 This is a new form of diffserv classifier. Alex has a draft ready to ship on this, but we decided to wait. Since "12345" would be a globally defined, well known value, it is just built into the QOS policy repository of any ISP that wants to support it. (This is what Tony thinks should be done with the DSCP values.) ... > > I thought the current definition of the MF-classifier in intserv would allow > usage of the flow label field for classification. Yes, except that RFC 2460 does not describe this in normative text. ... > My precise point was that *between domains* PHB-ID carries 6 bits of > information only (the standardized DSCP values). Any *local use* values > would not be used inter-domain, and any *experimental* value usage would > need bilateral agreements (perhaps as part of the SLAs), so for this info > (mapping from an *experimental* PHB-ID to the actual behavior definition) an > out-of-band signaling method (online or offline) exists already. Correct. This is the point that Tony argues right at the top of this message, with my reply. There is some non-IETF work on signalling for this, but the real world solution today is off-line SLAs. ... > Hopefully the SLAs specify what treatment should be given to which packets. > It is not up to IETF to standardize redundant technologies just because a > "business decision says so". I really don't understand that comment. We have to aim for simplicity, but we also have to solve real world problems. Telling the ISPs what they are allowed to put in theirs SLAs isn't an option. > > In my opinion, you have not yet shown a convincing scenario, where the > proposed behavior aggregate usage of the IPv6 flow label field actually > provides something we don't already have. You should provide a concrete > example showing the relationships between the operators, who marks what > (end-to-end/hop-by-hop), how the traffic is policed etc. There is no new scenario here; the scenario is an absolutely standard diffserv scenario with multiple ISPs on the path, with traffic conditioning at every ISP boundary. What we don't have (with ESP) is the ability to perform full traffic conditioning at those boundaries. Michael Thomas wrote: > > Sorry if this is redundant; it's been a hard thread > to keep up with. Oh really? :-) ... > I've got what may be a pertinent question: do the re-classifiers > require actual knowledge of the contents of the encrypted headers, > or do they just require the ability to differentiate the unique > flows associated with a particular DSCP? It's the former; if an ISP chooses to disbelieve the upstream ISP, and re-classify the traffic, the semantics of the transport header are exactly the information of interest. > > If it's the former, I think I object to requiring a node to > _have_ to reveal information (quite valuable information, if > you consider it) in order to obtain QoS. Indeed, I think this is a basic trade-off: to ask for QOS in the absence of both signalling and SLAs, you have to reveal something. The security question is whether revealing a PHB ID is acceptable. It would allow an intruder to figure out how much traffic of which kind Bob is sending to Mary, but there is less detail than port/protocol numbers would give. Or to put it another way, if your level of paranoia prevents you from revealing a PHB ID, then you have three choices: a) accept default QOS b) use IntServ c) ensure that all ISPs on the path have the right kind of SLA > At the very least, > how is a non-signaled diffserv host to know whether it > should or should not insert the revealing information into > the flow label? If the answer is that it always has to do > that, you have effectively defeated one of the useful > protections of ESP. This would be very bad. I think this would have to be configured by local policy (an interesting blend of security and QOS policy). > > > The set of packets identified as a > > > flow will be the same with either QoS mechansim, so why is there > > > a need to have distinct semantics unless someone in the middle wants > > > to interpret them? > > > > Diffserv is blind to microflows; there is no flow identification. > > However, diffserv classifiers in the middle *do* need to (re)interpret > > packet headers. That is how diffserv works. > > I'm afraid that this makes no sense at all. The point is that the diffserv low level scheduling mechanisms are driven entirely by the 6-bit DSCP field and that is the only thing that core routers look at. That's what we mean when we say diffserv is blind to microflows. The edge classifiers are also very unlikely to be microflow based; although they use 5-tuple classifiers, we expect the addresses and ports to be ranges or wild cards in most cases. In fact it would be quite unusual for a diffserv classifier to look for a specific microflow rather than a large class of microflows. ... > > Indeed, and since I don't quite see how IPSEC and NAT-PT are going to > > work together, the need that triggered this discussion (the need to > > classify ESP packets in the middle of the Internet) really doesn't arise > > in the case of translated packets. The concern is for a native IPv6 environment. > > The current proposed lossage involves ESP over UDP. > In fact, that would probably provide you with what > you need for both v4 and v6. Only in a limited sense, because the actual port and protocol values will be hidden. Diffserv would work just fine, but all ESP/UDP packets would be treated the same. jarno.rajahalme@nokia.com wrote: ... > For the proposed diffserv usage the flow label should be mutable to enable > policing and aggregation. The point is that the flow label should NOT be > locally mappable, it MUST always contain a standardized value, or it's > semantics must be signaled (la intserv). As I noted above, that is a sufficient solution, but I don't think mutability is necessary; when a domain wants to aggregate it can use the diffserv code point to do that. ... > It may be that diffserv cannot be changed NOT to allow local mapping any > more, but where are these ISPs NOW? They went away when RFC 2474 was published, literally saying "we got what we want." Just recently we have got some ISP people back in diffserv, but I haven't seen any attempt to rediscuss the mapping issue, which is of course very deep in all implementations and in the MIB. ... > Another problem is the MF-classification defined by the diffserv: How long > you think it takes for the SLAs to be updated end-to-end (or more precisely, > hop-by-hop), when two consenting hosts switch to SCTP instead of TCP? The SLAs and local policies are database and human driven. They need to anticipate all ports etc to be used in advance. ... > I hope that if we'll have the flow label support for what Brian is asking > (standard, non-mappable behavior aggregates), he'll promise to remove the > MF-classifiers peeking into transport headers from the diffserv specs :-) > (also from the non-ESP case). That's not going to happen. ... > I might be wrong, but it seems that a downstream (operator) router CANNOT > use end-to-end immutable information. If the policer in the 1st operators > domain concludes that the customer is not paying enough for the treatment > he's asking, the "treatment indicator" needs to be downgraded. If that is > not allowed, the only other option would be to drop the packet altogether. This can be done at the DSCP level (mark the packet for best effort). There really is no need to change anything else. Tony Hain wrote: ... > The operators are finding that making > the DSCP completely random has resulted in a useless technology. It isn't random, come on. It's locally configured. If operators want values that cross domain boundaries, they either use the recommended values, write an SLA, or both. This isn't hard. ... > I was being very careful not to use the 5-tuple > because the src/dst addresses are mutable thanks > to NAT. The only end-to-end consistent bits are > the protocol & port, and the flow label. In this case I don't think NATted addresses are a problem at all. The addresses (both source and destination) are both meaningful within a given domain - even Net 10 addresses are meaningful within their own domain - and MF classifiers are configured within a given domain too. Mutable addresses seem to be a problem for intserv since they are signalled in FlowSpecs, but not for diffserv. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 30 13:21:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UKLm40010684 for ; Thu, 30 Aug 2001 13:21:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UKLlGX010683 for ipng-dist; Thu, 30 Aug 2001 13:21:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UKLi40010676 for ; Thu, 30 Aug 2001 13:21:44 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27800 for ; Thu, 30 Aug 2001 13:21:52 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23494 for ; Thu, 30 Aug 2001 13:21:51 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA21856 for ; Thu, 30 Aug 2001 21:21:48 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA38260 for ; Thu, 30 Aug 2001 21:21:42 +0100 Message-ID: <3B8E9F0C.3169EF4A@hursley.ibm.com> Date: Thu, 30 Aug 2001 15:16:12 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Another idea for the flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Tony in this case (see my long portmanteau reply just sent). Brian Tony Hain wrote: > > Jarno Rajahalme wrote: > > > 9. this form is MUTABLE: > > > > If the intention is to enable contractual aggregation needed > > by e.g. the > > diffserv model, domain must be able to remark the value > > (change it), but > > also the new value needs to be taken from the set of > > standardized values, so > > that the semantics of the value is always unambiguous. The > > mutability allows > > cutting off "freeloaders" (as put so eloquently by Steve > > Blake), and enables > > the diffserv aggregation model. > > I am sorry, but this is BS. The diffserv model already > has a mutable field giving the provider ultimate control > and doesn't need a second one. In fact allowing this > proposed use to be mutable will ensure that subsiquent > providers have no clue what the origin intended. If the > provider wants to cut people off, it can set the TC to 0, > or drop the packet. Allowing providers to modify these > bits adds no value to the existing diffserv capabilities. > > Tony -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 30 13:48:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UKmm40010763 for ; Thu, 30 Aug 2001 13:48:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UKmlvT010762 for ipng-dist; Thu, 30 Aug 2001 13:48:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UKmi40010755 for ; Thu, 30 Aug 2001 13:48:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02927 for ; Thu, 30 Aug 2001 13:48:53 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11082 for ; Thu, 30 Aug 2001 14:48:48 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA16908; Thu, 30 Aug 2001 21:48:48 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA57118; Thu, 30 Aug 2001 21:48:47 +0100 Message-ID: <3B8EA53B.8B373205@hursley.ibm.com> Date: Thu, 30 Aug 2001 15:42:35 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: slblake@torrentnet.com, alh-ietf@tndh.net, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757197FFC@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno, this is recursing the DSCP model up to the (proposed) flow label. I don't think it's necessary. On this point I am in agreement with Tony. Brian jarno.rajahalme@nokia.com wrote: > > Steve Blake wrote: > > RFC2475 was built on the assumption of bilateral agreements between > > peering providers, because that was the only model that had a hope > > of being deployed. > > Has this changed? Would there be hope for non-locally-mappable DSCP > deployment NOW? I've understood the standardized values already exist (the > PHB definition recommended DSCP values). > > > The Diffserv flow-label proposal is trying to > > invent an end-to-end, in-band QoS "signaling" mechanism to operate in > > parallel with the hop-by-hop DSCP "signaling". > > I can see this to be useful, IF DSCP cannot be made non-mappable, and the > proposed flow label usage would be mutable. > > > The only additional > > in-band information that would be remotely useful for Diffserv would > > be a credit card account number. > > Assuming that the flow label usage would be immutable. The first operator > that doesn't see the transitive out-of-band credit card should re-mark the > flow label to '00000'. > > Jarno -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 30 13:58:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UKwe40010820 for ; Thu, 30 Aug 2001 13:58:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UKwe9O010819 for ipng-dist; Thu, 30 Aug 2001 13:58:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UKwa40010812 for ; Thu, 30 Aug 2001 13:58:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05025 for ; Thu, 30 Aug 2001 13:58:42 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10758 for ; Thu, 30 Aug 2001 13:58:41 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA18114; Thu, 30 Aug 2001 21:58:39 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA38156; Thu, 30 Aug 2001 21:58:38 +0100 Message-ID: <3B8EA778.714626C6@hursley.ibm.com> Date: Thu, 30 Aug 2001 15:52:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: alh-ietf@tndh.net, slblake@torrentnet.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757198000@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: > > Brian, > > In the scenario you provided (multiple instances of the standard PHBs, each > mapped to separate DSCP value), the mapping is reversible: the egress router > of that domain should be able to map back to the single instance of the > recommended DSCP value for the PHB in question. Therefore usage of the > recommended DSCPs intra-domain would seem to be sufficient. > > I might be wrong, but it seems that unless there is a case where a locally > used DSCP value for a PHB cannot be mapped back to a standardized, PHB > definition recommended DSCP value at the domain egress, there is no need for > additional support from the flow label. If you accept that ESP traffic will get QOS treatment only if there is a suitable SLA at every domain boundary on its path. (Incidentally, the same is true of intserv - if there is no SLA, there is no reason why intserv would work across a domain boundary.) > > Also, mutability and standardized semantics would seem to be orthogonal > issues. Yes, I think so. As I've been trying to communicate, there is nothing to stop ISPs using the standardised DSCP values across domain boundaries today, if they have an SLA in place. 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 Aug 30 14:05:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UL5540010871 for ; Thu, 30 Aug 2001 14:05:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UL54gB010870 for ipng-dist; Thu, 30 Aug 2001 14:05:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UL5140010863 for ; Thu, 30 Aug 2001 14:05:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05100 for ; Thu, 30 Aug 2001 14:05:09 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10279 for ; Thu, 30 Aug 2001 15:05:34 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA25208; Thu, 30 Aug 2001 22:04:57 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA56310; Thu, 30 Aug 2001 22:04:56 +0100 Message-ID: <3B8EA8E9.B4B7DEDF@hursley.ibm.com> Date: Thu, 30 Aug 2001 15:58:17 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: jarno.rajahalme@nokia.com, slblake@torrentnet.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Jarno Rajahalme wrote: > > > I might be wrong, but it seems that unless there is a case > > where a locally > > used DSCP value for a PHB cannot be mapped back to a standardized, PHB > > definition recommended DSCP value at the domain egress, there > > is no need for > > additional support from the flow label. > > Thank you for making this point, because you have done it > better than I have been able to. If the DSCP is consistent > from end-to-end, each domain can make its own decisions. > I really don't care what they do with the bits in the middle, > as long as they exit the domain like they entered it. We don't > need to redefine the flow label if the diffserv WG will > simply define a set of standard DSCP values for interdomain > use. It's been done, by RFC 2474, 2597, and 2598 (soon to be revised, but the DSCP value doesn't change). What we can't do is force ISPs to use them. In particular, we can't force ISPs that don't support diffserv to use them. Like it or not, there *will* be scenarios where an ISP can't rely on the arriving DSCP value. 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 Aug 30 14:07:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UL7M40010922 for ; Thu, 30 Aug 2001 14:07:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UL7Mos010921 for ipng-dist; Thu, 30 Aug 2001 14:07:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UL7I40010912 for ; Thu, 30 Aug 2001 14:07:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06802 for ; Thu, 30 Aug 2001 14:07:27 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11542 for ; Thu, 30 Aug 2001 15:07:54 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA20074; Thu, 30 Aug 2001 22:07:23 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA56064; Thu, 30 Aug 2001 22:07:20 +0100 Message-ID: <3B8EA975.F2196F43@hursley.ibm.com> Date: Thu, 30 Aug 2001 16:00:37 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: alh-ietf@tndh.net, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F91175715D4D6@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: ... > > and mark the bits the way they wanted to > > because they couldn't trust the origin not to lie. > > ...but I fail to understand why should want to do anything else than remark > to best effort if they do not trust the previous operator. Because the destination is a customer with an SLA that specifies QOS levels for incoming traffic. Of course, the ultimate default action is always best effort. 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 Aug 30 14:15:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7ULFL40010963 for ; Thu, 30 Aug 2001 14:15:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7ULFKoF010962 for ipng-dist; Thu, 30 Aug 2001 14:15:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7ULFG40010955 for ; Thu, 30 Aug 2001 14:15:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08989 for ; Thu, 30 Aug 2001 14:15:25 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18187 for ; Thu, 30 Aug 2001 14:15:24 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA16946; Thu, 30 Aug 2001 22:15:21 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA17146; Thu, 30 Aug 2001 22:15:21 +0100 Message-ID: <3B8EAB4B.DFCF133@hursley.ibm.com> Date: Thu, 30 Aug 2001 16:08:27 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: alh-ietf@tndh.net, aconta@txc.com, slblake@torrentnet.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <009CA59D1752DD448E07F8EB2F911757197FFD@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: ... > A PHB-ID in the flow label is NOT the semantics, but a pointer to the > semantics. The actual semantics are found from the respective specification, > and since all the possible (future) PHB-ID pointed semantics cannot be > hard-coded into the router, they need to be delivered to the router by some > out-of-band mechanism. Of course. Diffserv routers have to be configured by a QOS policy system. See the POLICY, RAP and SNMPCONF WGs and the diffserv MIB and PIB. > This out-of-band mechanism will indeed establish > state at the router, not source specific state, but behavior aggregate flow > specific state. One could even imagine establishing this state with an > end-to-end signaling mechanism, which would result in a kind of host-to-host > specific behavior aggregate flow That's what the bandwidth broker and SLS-signalling people are up to, though none of that work is in the IETF yet. 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 Aug 30 14:21:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7ULL640010992 for ; Thu, 30 Aug 2001 14:21:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7ULL5wr010991 for ipng-dist; Thu, 30 Aug 2001 14:21:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7ULL140010984 for ; Thu, 30 Aug 2001 14:21:02 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08212 for ; Thu, 30 Aug 2001 14:21:07 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08203 for ; Thu, 30 Aug 2001 14:21:06 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA19038; Thu, 30 Aug 2001 22:21:03 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id WAA37136; Thu, 30 Aug 2001 22:21:02 +0100 Message-ID: <3B8EAC97.936BE48F@hursley.ibm.com> Date: Thu, 30 Aug 2001 16:13:59 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Brian E Carpenter wrote: > > > > There is RFC2996 to fix this problem... > > > > That only works up to the first diffserv domain on the traffic path. > > As the packets enters a 2nd, 3rd etc. diffserv domain, the problem > > reappears. By the way, the absence of signalling is a virtue, not a > > problem, from the scaling viewpoint. > > The absence of signalling is not the virtue, limiting the points where > the signalling is interpreted is. Removing signalling explicitly kills > any hope that the endpoint is capable of expressing its willingness to > pay for enhanced services. Basically there can't be a sustainable QoS > business model that is strictly based on diffserv, because the person > with the cash has no means to control which packets get which level of > service. Absolutely untrue. The customer's SLA drives the provider's QOS policy configuration which drives the classifiers. There is a direct impact of customer money on this. And it should recurse from ISP to ISP, assuming every bilat inludes an SLA. It is of course at the granularity of traffic aggregates, not flows. > The whole diffserv effort was so overbiased by the provider > viewpoint of limiting abuse that it forgot that there has to be some > means for the originator to state intent and see value in return. It's just as much the destination as the source, but the intent is expressed in the SLA. Also, I agree with you: host marking is a Good Thing and I could name some products that do it. Consistent SLAs allowing consistent use of code points are also a Good Thing. But for scenarios without these Good Things, I would like a pragmatic solution. > > > Because the diffserv architecture requires the option to > > reclassify traffic, because that's what the ISPs say they need. > > But have they got any paying customers for that service? Or for that > matter any hope of having any? I don't know what customers ISPs have, but I do know that diffserv capability is getting into many products and management systems. What I certainly don't know is whether people are signing diffserv- savvy SLAs. > > > I don't like the word "usurp". If the flow label was already > > standardised and in habitual use, it would be appropriate, > > but then we wouldn't be having this conversation anyway. Since > > it is not standardised, there is nothing to usurp. > > I will grant you that we have no Standards in this space, but to > the status of 2460 I believe it is standardized as: > > A flow label is assigned to a flow by the flow's source node. New > flow labels must be chosen (pseudo-)randomly and uniformly from the > range 1 to FFFFF hex. > > All packets belonging to the same flow must be sent with the same > source address, destination address, and flow label. That's Appendix A, which the Area Director has stated is non-normative. 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 Aug 30 15:49:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UMnX40011187 for ; Thu, 30 Aug 2001 15:49:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UMnXV3011186 for ipng-dist; Thu, 30 Aug 2001 15:49:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UMnT40011179 for ; Thu, 30 Aug 2001 15:49:29 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25945 for ; Thu, 30 Aug 2001 15:49:37 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17416 for ; Thu, 30 Aug 2001 15:49:36 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 30 Aug 2001 15:48:58 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 5AC8CE4D89A748EBA77A74DB16293ABE for plus 3 more; Thu, 30 Aug 2001 15:48:58 -0700 Reply-To: From: "Tony Hain" To: "Brian E Carpenter" Cc: , , Subject: RE: Higher level question about flow label Date: Thu, 30 Aug 2001 15:48:58 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B8EA8E9.B4B7DEDF@hursley.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 7C9E2306-56394094-90FC8DA8-F815C937 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7UMnU40011180 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Like it or not, there *will* be scenarios > where an ISP can't rely on the arriving DSCP value. Which is my point in calling them random bits. You are correct that by maintining a chain of integrity in the interpretation, there is no real need for the bits to be consistent. The reality is that the only way to reconstruct a meaning through the inconsistent SLA chain is to go back to the immutable bits. I have no problem with a strongly worded BCP that says all DSCP values should be reset to a set of globally agreed values at exit. I understand that does not force ISPs to abide, but at least it gives them some clue what to do, and the market will sort out the ones that comply from the ones that can't deliver the expected level of service. 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 Aug 30 16:24:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UNO940011230 for ; Thu, 30 Aug 2001 16:24:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UNO98H011229 for ipng-dist; Thu, 30 Aug 2001 16:24:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UNO540011222 for ; Thu, 30 Aug 2001 16:24:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15957 for ; Thu, 30 Aug 2001 16:24:14 -0700 (PDT) From: Aconta@aol.com Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20822 for ; Thu, 30 Aug 2001 17:24:09 -0600 (MDT) Received: from Aconta@aol.com by imo-d05.mx.aol.com (mail_out_v31_r1.4.) id y.170.1252aa (4555); Thu, 30 Aug 2001 19:24:03 -0400 (EDT) Message-ID: <170.1252aa.28c02513@aol.com> Date: Thu, 30 Aug 2001 19:24:03 EDT Subject: clarifications - was RE: Higher level question about flow label To: alh-ietf@tndh.net CC: ipng@sunroof.eng.sun.com, aconta@txc.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_170.1252aa.28c02513_boundary" X-Mailer: AOL 6.0 for Windows US sub 10535 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --part1_170.1252aa.28c02513_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I am on the road, so apologies, if the formatting of this message is messed up. >Tony Hain wrote: > > >>Alex Conta wrote: > > > >> To me it is simple: I see the IPv6 main header divided into functions > >> for forwarding, > >> and functions for QoS. > > > >You appear to have forgotten that the endpoints need to > >communicate with each other. The header is also used for > >that primary function, or the others will not matter. > Perhaps my text was too abstract: "functions for forwarding", above, include the packet forwarding/sending performed by the source host, and the packet receiving performed on the destination host > > Anyway the point is that we are > > being asked to change an existing definition to accomidate > > a capability that another WG really needs, but refused to > > create for itself in the field it had to work with. Why > > should we do that? [...] There are no changes to the normative definition in RFC 2460 -- see the AD clarification. There is a new model added. You make a point, which, I think at this moment, I understand and appreciate well. Regards, Alex --part1_170.1252aa.28c02513_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit
I am on the road, so apologies, if the formatting of this message is messed
up.

>Tony Hain wrote:

>>Alex Conta wrote:
>
>> To me it is simple:  I see the IPv6 main header divided into functions
>> for forwarding,
>> and functions for QoS.
>
>You appear to have forgotten that the endpoints need to
>communicate with each other. The header is also used for
>that primary function, or the others will not matter.


Perhaps my text was too abstract:  "functions for forwarding", above, include
the packet forwarding/sending performed by the source host, and the packet
receiving performed on the destination host


> Anyway the point is that we are
> being asked to change an existing definition to accomidate
> a capability that another WG really needs, but refused to
> create for itself in the field it had to work with. Why
> should we do that? [...]

There are no changes to the normative definition in RFC 2460 -- see the AD
clarification. There is a new model added.

You make a point, which, I think at this moment, I understand and appreciate
well.

Regards,
Alex
--part1_170.1252aa.28c02513_boundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 30 16:24:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UNOI40011240 for ; Thu, 30 Aug 2001 16:24:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7UNOIFb011239 for ipng-dist; Thu, 30 Aug 2001 16:24:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7UNOE40011232 for ; Thu, 30 Aug 2001 16:24:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15973 for ; Thu, 30 Aug 2001 16:24:22 -0700 (PDT) From: Aconta@aol.com Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA15288 for ; Thu, 30 Aug 2001 17:24:49 -0600 (MDT) Received: from Aconta@aol.com by imo-d07.mx.aol.com (mail_out_v31_r1.4.) id b.133.e41129 (4555); Thu, 30 Aug 2001 19:24:14 -0400 (EDT) Message-ID: <133.e41129.28c0251d@aol.com> Date: Thu, 30 Aug 2001 19:24:13 EDT Subject: Re: Portmanteau reply Re: a), b), c), d), or e) To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com CC: aconta@txc.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_133.e41129.28c0251d_boundary" X-Mailer: AOL 6.0 for Windows US sub 10535 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --part1_133.e41129.28c0251d_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/30/01 4:28:13 PM Eastern Daylight Time, brian@hursley.ibm.com writes: I am traveling and cooling off, a little bit is not bad. Apologies for bad formatted text. > I gave myself 24 hours off from this thread to draw breath. Here are > comments on a bunch of points from various people. > > > Speak to your co-author who keeps insisting that they are > > mutable. > > Yes, and I think I disagree with him :-) > We cannot change checksum and authentication calculation anyway. I would be happy with an adequate language. > > In any case, the point is that for diffserv to work there > > has to be a visible set of bits that are immutable end-to-end > > with well-known semantics. Currently that is the protocol/port, > > simply because ESP wasn't in widespread use. In IPv6 we assume > > it will be, so diffserv needs another set of bits that have an > > immutable well-known end-to-end semantic. > > Well, Alex is correct to the extent that "immutable" is not an > absolute requirement; "globally defined" is necessary and sufficient. > But as just stated, I prefer immutable. > Let's not make the language and the rules stronger that they need be. We can write in a language that it does the job for everyone. > > Alex Conta wrote: > > . > > [...] > > The flow label bits were mutable, the meaning was immutable. > > Yes, it *could* work that way but I would argue against it - I'd much rather > keep it simple and have the flow label immutable. > To me "immutable" means the bits are "read-only". Let's work on the language, that would be satisfactory to everyone. It would look like a silly, technical weakness, to have a field as read-only, but with no mechanism for the final recipient to detect whether it was changed or not. > jarno.rajahalme@nokia.com wrote: > ... > > > That's an interesting thought, but I think it doesn't work. > > > The egress router > > > has to *know* that the flow label is in diffserv format, and > > > I think that > > > requires some magic. > > > > > > > Wouldn't the absence of intserv state for the flow at the domain egress be > > the magic for this determination? > > That's an interesting thought. > if flow label != 0 > and there is no intserv state > then try diffserv classification > > This needs a little thought but it looks hopeful to me. > These are indeed good ideas. We can iron out the details, to make the flow label space allocation dynamic, and the flow label format transparent. This way the space is used according to the users needs (customers/providers), and the hardware/software classifier can be easily shared. > > > > > > The set of packets identified as a > > > > flow will be the same with either QoS mechansim, so why is there > > > > a need to have distinct semantics unless someone in the middle wants > > > > to interpret them? > > > > > > Diffserv is blind to microflows; there is no flow identification. > > > However, diffserv classifiers in the middle *do* need to (re)interpret > > > packet headers. That is how diffserv works. > > > > I'm afraid that this makes no sense at all. > > The point is that the diffserv low level scheduling mechanisms are > driven entirely by the 6-bit DSCP field and that is the only > thing that core routers look at. That's what we mean when we > say diffserv is blind to microflows. The edge classifiers are > also very unlikely to be microflow based; although they use 5-tuple > classifiers, we expect the addresses and ports to be ranges or wild > cards in most cases. In fact it would be quite unusual for a > diffserv classifier to look for a specific microflow rather > than a large class of microflows. > Even though it may be the case, I would not prohibit a classification on all fields. That gives a lot of flexibility to the users (custmers/providers) in particular since the guts of the classifer mechanism allow for both Intserv, and Diffserv M-F classification. > > > I hope that if we'll have the flow label support for what Brian is asking > > (standard, non-mappable behavior aggregates), he'll promise to remove the > > MF-classifiers peeking into transport headers from the diffserv specs :-) > > (also from the non-ESP case). > > That's not going to happen. > But it is likely that practically, as IPv6 would use flow label classifiers, the need to use, and with that the practice of snooping at the transport headers would desappear. > > > Brian > --part1_133.e41129.28c0251d_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit In a message dated 8/30/01 4:28:13 PM Eastern Daylight Time,
brian@hursley.ibm.com writes:


I am traveling and cooling off, a little bit is not bad. Apologies for bad
formatted text.

> I gave myself 24 hours off from this thread to draw breath. Here are

comments on a bunch of points from various people.

> Speak to your co-author who keeps insisting that they are
> mutable.

Yes, and I think I disagree with him :-)


We cannot change checksum and authentication calculation anyway.
I would be happy with an adequate language.

> In any case, the point is that for diffserv to work there
> has to be a visible set of bits that are immutable end-to-end
> with well-known semantics. Currently that is the protocol/port,
> simply because ESP wasn't in widespread use. In IPv6 we assume
> it will be, so diffserv needs another set of bits that have an
> immutable well-known end-to-end semantic.

Well, Alex is correct to the extent that "immutable" is not an
absolute requirement; "globally defined" is necessary and sufficient.
But as just stated, I prefer immutable.

Let's not make the language and the rules stronger that they need be.
We can write in a language that it does the job for everyone.

Alex Conta wrote:
> .
> [...]
> The flow label bits were mutable, the meaning was immutable.

Yes, it *could* work that way but I would argue against it - I'd much rather
keep it simple and have the flow label immutable.

To me "immutable" means the bits are "read-only". Let's work on the
language, that would be satisfactory to everyone. It would look like a
silly, technical weakness,  to have a field as read-only,
but with no mechanism for the final recipient to detect whether
it was changed or not.

jarno.rajahalme@nokia.com wrote:
...
> > That's an interesting thought, but I think it doesn't work.
> > The egress router
> > has to *know* that the flow label is in diffserv format, and
> > I think that
> > requires some magic.
> >
>
> Wouldn't the absence of intserv state for the flow at the domain egress be
> the magic for this determination?

That's an interesting thought.
 if flow label != 0
    and there is no intserv state
 then try diffserv classification

This needs a little thought but it looks hopeful to me.


These are indeed good ideas.
We can iron out the details, to make the flow label space
allocation dynamic, and the flow label format transparent.
This way the space is used  according to the users needs
(customers/providers),
and the hardware/software classifier can be easily shared.



>  > > The set of packets identified as a
>  > > flow will be the same with either QoS mechansim, so why is there
>  > > a need to have distinct semantics unless someone in the middle wants
>  > > to interpret them?
>  >
>  > Diffserv is blind to microflows; there is no flow identification.
>  > However, diffserv classifiers in the middle *do* need to (re)interpret
>  > packet headers. That is how diffserv works.
>
>    I'm afraid that this makes no sense at all.

The point is that the diffserv low level scheduling mechanisms are
driven entirely by the 6-bit DSCP field and that is the only
thing that core routers look at. That's what we mean when we
say diffserv is blind to microflows. The edge classifiers are
also very unlikely to be microflow based; although they use 5-tuple
classifiers, we expect the addresses and ports to be ranges or wild
cards in most cases. In fact it would be quite unusual for a
diffserv classifier to look for a specific microflow rather
than a large class of microflows.


Even though it may be the case, I would not prohibit a classification
on all fields. That gives a lot of flexibility to the users
(custmers/providers)
in particular since the guts of the classifer mechanism allow for both
Intserv, and Diffserv M-F classification.


> I hope that if we'll have the flow label support for what Brian is asking
> (standard, non-mappable behavior aggregates), he'll promise to remove the
> MF-classifiers peeking into transport headers from the diffserv specs :-)
> (also from the non-ESP case).

That's not going to happen.


But it is likely that practically, as IPv6 would use flow label classifiers,
the need
to use, and with that the practice of snooping at the transport headers would
desappear.



  Brian


--part1_133.e41129.28c0251d_boundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 30 17:16:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V0Gn40011314 for ; Thu, 30 Aug 2001 17:16:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7V0GnCL011313 for ipng-dist; Thu, 30 Aug 2001 17:16:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V0GU40011306 for ; Thu, 30 Aug 2001 17:16:30 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05778 for ; Thu, 30 Aug 2001 17:15:45 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22134 for ; Thu, 30 Aug 2001 17:15:44 -0700 (PDT) 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 RAA23160; Thu, 30 Aug 2001 17:15:44 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f7V0FhK02845; Thu, 30 Aug 2001 17:15:43 -0700 X-mProtect: Thu, 30 Aug 2001 17:15:43 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdkZg5dk; Thu, 30 Aug 2001 17:15:40 PDT Message-Id: <4.3.2.7.2.20010830171421.022546b8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Aug 2001 17:15:09 -0700 To: jarno.rajahalme@nokia.com From: Bob Hinden Subject: RE: a), b), c), d), or e) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <009CA59D1752DD448E07F8EB2F91175715D4CB@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, that was my intent. Thanks for catching this. Bob At 11:31 PM 8/29/2001 +0300, jarno.rajahalme@nokia.com wrote: >Brian, > >Maybe Bob meant just IPv6 tunneled over IPv4, not protocol translation? > > Jarno > >Brian E Carpenter wrote: > > Bob Hinden wrote: > > > > > .. > > > I think you are going a bit far to suggest that the fate of Diffserv > > > depends on what the IPv6 w.g. does with the flow label > > field. I suspect > > > that Diffserv will live or die based on IPv4 usage. Also, > > as IPv6 is > > > deployed much of it will be initially carried over IPv4. > > Any QoS solution > > > that is going to be end-to-end will have to deal with a mix > > of native IPv6 > > > and IPv4/IPv6 headers. > > > > Indeed, and since I don't quite see how IPSEC and NAT-PT are going to > > work together, the need that triggered this discussion (the need to > > classify ESP packets in the middle of the Internet) really > > doesn't arise > > in the case of translated packets. The concern is for a > > native IPv6 environment. > > > > 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 Aug 30 19:42:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V2gt40011420 for ; Thu, 30 Aug 2001 19:42:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7V2gtvZ011419 for ipng-dist; Thu, 30 Aug 2001 19: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V2gp40011412 for ; Thu, 30 Aug 2001 19:42:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12666 for ; Thu, 30 Aug 2001 19:42:59 -0700 (PDT) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.247.6.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24826 for ; Thu, 30 Aug 2001 20:42:54 -0600 (MDT) Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id f7V2gpo20197 for ; Fri, 31 Aug 2001 11:42:52 +0900 (JST) Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.3/3.7W-MAILGATE-NEC) with ESMTP id f7V2gpl14742 for ; Fri, 31 Aug 2001 11:42:51 +0900 (JST) Received: from saigo.jp.nec.com (saigo.jp.nec.com [10.26.220.6]) by mailsv.nec.co.jp (8.11.3/3.7W-MAILSV-NEC) with ESMTP id f7V2go807837 for ; Fri, 31 Aug 2001 11:42:50 +0900 (JST) Received: from [10.42.72.128] by mail.jp.nec.com with ESMTP; Fri, 31 Aug 2001 11:42:50 +0900 From: "HIROKI ISHIBASHI" To: Subject: Neighbor Solicitation over IPv6-overIPv4 Tunnel Date: Fri, 31 Aug 2001 11:42:49 +0900 Message-Id: <003701c131c6$9fd02af0$80482a0a@ABKIPNIPNC128> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, On IPv6-over-IPv4 (IPv6-over-IPv6) Tunnels, is it required to send Neighbor Advertisement Messages in response to Neighbor Solicitation Messages sent by the other end? I am a little confused about this. Thank you Hiroki Ishibashi bashi@ipv6.nec.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 Aug 30 20:32:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V3Wk40011503 for ; Thu, 30 Aug 2001 20:32:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7V3Wjw1011502 for ipng-dist; Thu, 30 Aug 2001 20:32:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V3Wg40011493 for ; Thu, 30 Aug 2001 20:32:42 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA16935 for ; Thu, 30 Aug 2001 20:32:50 -0700 (PDT) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20571 for ; Thu, 30 Aug 2001 20:32:50 -0700 (PDT) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 30 Aug 2001 21:32:48 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Thu, 30 Aug 2001 21:32:28 -0600 From: "Bhuvaneshwar hn" To: , Subject: Re: Neighbor Solicitation over IPv6-overIPv4 Tunnel Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_A9F31070.6D0C9811" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_A9F31070.6D0C9811 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable No.=20 If an implementation provides bidirectional tunneling the only requirement = is that it MUST at least eccept and respond to the probe packets used by = Neighbor Unreachability detection. =20 Ref section 3.8 of RFC2893. >>> "HIROKI ISHIBASHI" 08/31/01 08:12AM >>> Hi, On IPv6-over-IPv4 (IPv6-over-IPv6) Tunnels, is it required to=20 send Neighbor Advertisement Messages in response to=20 Neighbor Solicitation Messages sent by the other end? =20 I am a little confused about this.=20 Thank you Hiroki Ishibashi bashi@ipv6.nec.co.jp=20 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng=20 FTP archive: ftp://playground.sun.com/pub/ipng=20 Direct all administrative requests to majordomo@sunroof.eng.sun.com=20 -------------------------------------------------------------------- --=_A9F31070.6D0C9811 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
No.
If an implementation provides bidirectional tunneling = the only=20 requirement is that it MUST at least eccept and respond to  the = probe=20 packets used by Neighbor Unreachability detection.
 
Ref section 3.8 of RFC2893.

>>> = "HIROKI=20 ISHIBASHI" <bashi@ipv6.nec.co.jp> 08/31/01 08:12AM=20 >>>
Hi,

On  IPv6-over-IPv4 (IPv6-over-IPv6) = Tunnels, is=20 it required to
send Neighbor Advertisement Messages in response to=20
Neighbor Solicitation Messages sent by the other end? 
I am = a=20 little confused about this.

Thank you

Hiroki=20 Ishibashi
bashi@ipv6.nec.co.jp

----------------------------------= ----------------------------------
IETF=20 IPng Working Group Mailing List
IPng Home=20 Page:           &nbs= p;         =20 http://playground.sun.com/ipng<= BR>FTP=20 archive:           &= nbsp;         =20 ftp://playground.sun.com/pub/ipn= g
Direct=20 all administrative requests to=20 majordomo@sunroof.eng.sun.com
------------------------------------------= --------------------------
--=_A9F31070.6D0C9811-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 30 21:56:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V4um40011539 for ; Thu, 30 Aug 2001 21:56:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7V4um3n011538 for ipng-dist; Thu, 30 Aug 2001 21:56:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V4uh40011531 for ; Thu, 30 Aug 2001 21:56:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10376 for ; Thu, 30 Aug 2001 21:56:52 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24605 for ; Thu, 30 Aug 2001 21:56:51 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id NAA20972; Fri, 31 Aug 2001 13:56:32 +0900 (JST) Date: Fri, 31 Aug 2001 13:56:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: Wrap up and last call: sin6_scope_id semantics In-Reply-To: <200108301329.f7UDTBl87428@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200108301329.f7UDTBl87428@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 30 Aug 2001 15:29:11 +0200, >>>>> Francis Dupont said: > => what we need is a more general (than "site1") notion of names > and the way to translate names to zone IDs and the reverse. > The actual syntax and semantics of names are not very important if > some simple rules (no % in names for instance) are given. > Regards > Francis.Dupont@enst-bretagne.fr > PS: I am waiting for a concrete proposal (i.e. a draft) Yes, I guess we have reached (a sort of) consensus, and it's time to revise the draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 30 23:47:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V6lg40011621 for ; Thu, 30 Aug 2001 23:47:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7V6lgTg011620 for ipng-dist; Thu, 30 Aug 2001 23:47:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V6lc40011613 for ; Thu, 30 Aug 2001 23:47:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA19266 for ; Thu, 30 Aug 2001 23:47:46 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA12249 for ; Fri, 31 Aug 2001 00:48:11 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7V6m6302852 for ; Fri, 31 Aug 2001 09:48:06 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Aug 2001 09:47:37 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWA42X>; Fri, 31 Aug 2001 09:47:32 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198005@esebe004.NOE.Nokia.com> To: mat@cisco.com Cc: brian@hursley.ibm.com, alh-ietf@tndh.net, kgk@igs.net, huitema@windows.microsoft.com, hinden@iprg.nokia.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: RE: a), b), c), d), or e) Date: Fri, 31 Aug 2001 09:47:27 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, I believe you misunderstood what I meant. To rephrase: The currently defined RFC 2460 App.A semantics allows the IPv6 flow label field to be used for intserv MF-classification, instead of any of the transport headers. In this case the multi-field (MF) classifier would look only at the IP addresses and the flow label. Intserv does not need to care about any of the headers above the IP header, if the flow label is used and signaled end-to-end. With the current flow label definition there are no additional privacy implications raised by the use of the flow label in intserv signaling and classification. Brian has repeatedly mentioned that intserv would have a problem with ESP. With reference to RFC 2207 this is clearly not true (uses SPI instead of the ports). Additionally, using the IPv6 Flow Label to label the flows for intserv allows the intserv signaling implementation to be independent of the IPsec policy in place (e.g. signaling would be the same regardless the IPsec policy, don't need to refresh the intserv state when re-keying, etc.). Jarno Michael Thomas wrote: > > jarno.rajahalme@nokia.com writes: > > Just some comments for clarifying some stuff that keeps coming up > > repeatedly: > > > > Brian E Carpenter wrote: > > > > > > This is a very unfair comment. Diffserv is just fine in the > > > case of unencrypted traffic. It has a problem (and so does > > > intserv I suspect) with tunnel or transport mode ESP. > > > > > > > IPv4 intserv shares the same difficulty of doing > MF-classification with ESP. > > However, in IPv6 the flow label can be used in > MF-classification for intserv > > semantics, even when ESP is used. > > This is incorrect. RFC 2207 defines a way to classify > ESP traffic for intserv *and* it doesn't compromise > privacy. What's being floated here for diffserv requires > that I compromise privacy in order to work, which I > think is bogus. > > Mike > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 31 02:25:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V9Pq40011903 for ; Fri, 31 Aug 2001 02:25:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7V9Ppcb011902 for ipng-dist; Fri, 31 Aug 2001 02:25:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7V9Pm40011895 for ; Fri, 31 Aug 2001 02:25:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01038 for ; Fri, 31 Aug 2001 02:25:58 -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 DAA09311 for ; Fri, 31 Aug 2001 03:25:53 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7V9PJU08058; Fri, 31 Aug 2001 12:25:19 +0300 Date: Fri, 31 Aug 2001 12:25:18 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Subject: Re: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt In-Reply-To: <3B8E853A.80459556@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 30 Aug 2001, Brian E Carpenter wrote: > I think this is a terrible idea for several reasons. > > 1) MPLS is not a global solution - if it survives at all in the long > term, it will be limited to the core of large networks - and there is > therefore no real reason to drag its complex mechanisms up into the > simple IP layer. In particular we have IP-in-IP tunnel mechanisms, > so the complex extension header replacing the S bit is unnecessary. I agree. The whole draft (and some say, MPLS itself, but let's not start a fight here) appears to be built very heavily on the assumption that MPLS is _the_ answer to IPv4 VPN, TE, etc. needs. Instead of looking into how these could be done better, natively in IPv6 (there's one 20 bits under discussion right now..:), it's assumed that MPLS infrastructure is still the answer, is required for these to be accomplished, and needs to be more tightly integrated with IPv6. MPLS may or may not be useful with IPv6, but I think at this point keeping MPLS transparent wrt IP header is definitely the right way to go. At this point, it's important to have a standard for transporting IPv6 in MPLS networks, nothing else. One particular point: --- Some advantages of IPngLS, i.e. the integration of MPLS and IPv6, are: 1. Descrease of complexity: It eliminates an extra header in the system. In fact, there is no reason to use a new header if the original one can fulfill all the tasks. --- I'm sure there are a lot of ways one can revise IP headers to make MPLS implementation less complex, but that doesn't mean the overall complexity (or IP header complexity, which way more important) is decreased... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 31 03:36:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VAac40011996 for ; Fri, 31 Aug 2001 03:36:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VAabMi011995 for ipng-dist; Fri, 31 Aug 2001 03:36:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VAaY40011988 for ; Fri, 31 Aug 2001 03:36:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05930 for ; Fri, 31 Aug 2001 03:36:42 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20753 for ; Fri, 31 Aug 2001 04:37:09 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f7VAadS08427 for ; Fri, 31 Aug 2001 13:36:39 +0300 Date: Fri, 31 Aug 2001 13:36:39 +0300 (EEST) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-gopinath-host-name-resolution-protocol-ipv6-00.txt In-Reply-To: <200108301114.HAA09888@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 Thu, 30 Aug 2001 Internet-Drafts@ietf.org wrote: As is pointed out in the draft, this is similar to (presented at IETF51): 2.1 Domain Name Auto-Registration for plugged in IPv6 The differences are mentioned along the way in the draft, but I'd like to have certain key points mentioned in the 'Study on existing and similar application' section; at least: - "push" (kitamura) vs. "pull" (this) - hostname/ip collisions handling (cannot overwrite already existing entries trivially) I think this method could actually be made workable, but there are some tough issues with duplicate host/ip issues to resolve. A few notes: - I find the name really cheesy. Is this really a _protocol_ as such? Resolution is often associated with the opposite kind of action, by client hosts. - I'm not sure whether there should be a moral requirement not to require changes to clients; as it is, I doubt all that many implementations (especially those which need this most) even implement / enable by default ICMPv6 NI queries by default... - When talking about ICMPv6, might it make sense to use ICMPv6 NI, at least in a few places? It is not part of official ICMPv6 yet, and IMO text wasn't clear that it is _that_ part of ICMP that's going to be used (especially chapter 2). - Wording in 3.1 appears to make the assumption that this would only be used by nodes that have stateless address autoconfiguration enabled. - 3.2.2, First paragraph, something missing at the end. - 3.3, part 1 Once an IPv6 node issues a DAD packet to a link, the agent will capture it and the packet will be analyzed. Then using ICMPv6 packet, the agent will issue a query to that node for more information (see section 2 of 3.4). ==> you probably mean sec 2 of 3.3 ie. the next section? - what about the scenario where multi-link subnetting is being used, a node moves from one subnet to another -- there are potentially two agents updating the same address/hostname to DNS. Naming algorithm suggests that a new name will be assigned. (or pretty much require that multi-link subnet router provides the functionality always for all the links). - there should be a mechanism for scrubbing the old junk data from the DNS and/or host files. - please be a little more specific with the pseudo-language, e.g.: 3.3.2 Algorithm using unicast address as destination in the ICMPv6 packet Agent sends the ICMPv6 packets request for information for unicast Agent captures the reply from the node If no reply in a time frame Send the request again Else if received the reply Extract the information and update the DNS ==> update DNS via resolver (3.4) ==> if a node's IP address changes (e.g. NIC change), agent accepts the new data, but updating it to resolver fails. There seems to be no procedure in agent<->resolver communication to withdraw ip addresses/hostnames. - the agent probably should check that the hostname is of valid form; ie. contains only 0-9 a-z A-Z - . or whatever. (or else the implementation must be really careful in case the clients send some weird names e.g. with null-chars or whatever). - should hostnames be in FQDN form? If not, this adds some comlexity to agent/resolver side. (from autoconfiguration point of view, the contrary might be better, but IMO hostname is FQDN is the current naming practise, AFAIS). - IPSEC security pixie dust ... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 31 03:55:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VAt740012018 for ; Fri, 31 Aug 2001 03:55:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VAt7xN012017 for ipng-dist; Fri, 31 Aug 2001 03:55:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VAt440012010 for ; Fri, 31 Aug 2001 03:55:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08444 for ; Fri, 31 Aug 2001 03:55:12 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27473 for ; Fri, 31 Aug 2001 04:55:37 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f7VArTC01799; Fri, 31 Aug 2001 17:53:36 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng Subject: Re: Portmanteau reply Re: a), b), c), d), or e) In-Reply-To: <3B8E9EA6.7D7E5CB8@hursley.ibm.com> References: <3B8E9EA6.7D7E5CB8@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 31 Aug 2001 17:53:29 +0700 Message-ID: <1797.999255209@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 30 Aug 2001 15:14:30 -0500 From: Brian E Carpenter Message-ID: <3B8E9EA6.7D7E5CB8@hursley.ibm.com> | I gave myself 24 hours off from this thread to draw breath. Here are | comments on a bunch of points from various people. I have taken longer than that, while trying to figure out what is really going on here. I think I have a better understanding now, so here are some more opinions, this time little less uninformed... | My private opinion is that in the end the | ISPs will need to settle down to using the recommended values across | domain boundaries, but what they do in their bilats or within their | domains is not something the IETF can dictate. You keep saying this, in one form of words or other - and it is obviously true. Nor would we want to. On the other hand, we can certainly constrain the sensible options - we do that all the time with the protocols and mechanisms we create. A lot of that seems invisible, it is just a part of the flora that doesn't stand out, because it has all been there for so long that people just accept it as a natural part of life, and not to be worried about - accept it, and deal with it. But all kinds of things have been invented by the IETF (and other groups - IEEE, ISO, etc) that place all kinds of constraints upon what is sensible to agree, as do politicians and lawyers (though their constraints tend to have different kinds of effects if ignored). To give some semi-relevant examples .. IEEE (and or DIX before them) constrained ethernet frames to 1500(++) bytes: that constrains packet sizes that are passing between ISPs. They may prefer larger ones (less switching), and they might like to write agreements that demand larger ones - but they don't, because that would be stupid, and everyone knows that. Even closer to this discussion, the IPv4 and IPv6 headers have fixed sized fields (different ones) into which this QoS information can be placed. The IETF imposed those limits, there's no natural or legal restriction that forced them. It was just a judgement call on how much space could be afforded, and how best to divide that among competing uses. Again, the ISPs (and in this case, diffserv WG) are just accepting those limits, and dealing with them as best can be done. They might want to be able to have 64K different packet classifications, but they can't - there simply aren't enough bits provided for that, so they make do with less. We can do more of this if the arguments for imposing more constraints are accepted by the relevant WG, and if we do, the ISPs will just need to deal with those constraints in their agreements. This is not specifying what the ISPs can agree with each other, which we can't, and wouldn't anyway, do, just designing the protocols that they happen to be agreeing with each other about... | Yes, except that RFC 2460 does not describe this in normative text. Part of this discussion is to whether or not anything about the flow label should be fixed now for all time, or whether it should remain in its current state (for a while at least). My read on what I have seen here is that there isn't yet enough agreement about what should go there that ipngwg should change the current status of that field - just leave it exactly as it is. I certainly don't consider it unthinkable for IPv6 to continue with a bunch of more or less undefined bits - I don't consider very much at all as unthinkable - doing that tends to bias your options way too much, and lead to missing other viable solutions. | It's the former; if an ISP chooses to disbelieve the upstream ISP, | and re-classify the traffic, the semantics of the transport | header are exactly the information of interest. No they're not. There is nothing at all in any transport header of relevance that contains anything in any way related to QoS. This guessing based upon port numbers is simply absurd - and simply leads to people doing weird machinations on port numbers because they can predict what effects that will have upon the network in the middle. That's not what port numbers were ever for. It also doesn't work - many packet flows that should get special QoS attention are between random port numbers at each end, totally unpredictable until the after the rendezvous and connection has been established. Should DNS SRV records start being used for more services, you'll see even more of that - port number classification is a crock that simply has to be abandoned. What's more, it is absolutely no business of the ISPs what port numbers, or for that matter, what transport protocol, I happen to be using to communicate with my peers. That is entirely between me and them. With ESP, and especially with IPv6, none of that information will be available, and that's a good thing. Making it available again by sticking the same information (even in a reduced form) in some unprotected header is simply wrong. On the other hand, if I want some special forwarding processes (QoS) applied to my packets, I certainly have to be willing to provide that information. Whether I calculate from port numbers, or just because this particular web page is one I want real fast (even though it is the same port number, same server, as that other web page I don't care about nearly as much), is none of the ISPs business. Nor is it of the IETFs. For intserv, as I understand it, I do this using RSVP, I communicate my needs, and indicate how the packets will be labelled so the routers can properly process them (provided they're willing, I'm prepared to pay if required, etc...) For diffserv, there's no out of band signalling, so every packet needs to be labelled so it can get the correct processing. That (as can intserv as I understand it) be done with no mutable header bits at all. The sender could simply provide a standard classification label, the ISP could choose to process it or not (at every router, though one would assume using a common distributed configuration). No need to rewrite anything. But because there are mutable bits, the decision is to use them to speed processing at intermediate nodes - with only the border routers between ISPs (or ISP/client) actually looking at the user's provided classification, and everything between simply trusting the value (DSCP) set by the border routers, and doing its packet processing based upon that value. Had there been no mutable bits that would never have been possible, and things would simply have to have been done the other way - it is of course still possible to pretend the bits are immutable, and process them that way (whatever the IPv6 protocol actually requires). But I see the attraction for using them (one mutable bit "this value is to be trusted, or not" and a value set by the sender would really be enough though). | Indeed, I think this is a basic trade-off: to ask for QOS in the | absence of both signalling and SLAs, you have to reveal something. Yes, I have to reveal the QoS I want. No more, no less. There cannot be an absence of signalling, I suspect you mean an absence of out of band signalling - but that's largely irrelevant. I have to provide the information somewhere, sometime, no question about that. | Or to put it another way, if your level of paranoia prevents you | from revealing a PHB ID, then you have three choices: | a) accept default QOS | b) use IntServ | c) ensure that all ISPs on the path have the right kind of SLA d) Adopt a QOS model that takes in-band defined signalling which carries only the QoS desired. Nothing extra. That is all that is required. There was something Alex said (I think) a couple of times, which I think I agree with ... that is, the IPv6 basic header should contain only data that is necessary to packet forwarding - this is the thing processed by the fast path, and shouldn't be having other stuff thrown in there which isn't related to that process. That I think is what dooms the proposals to add PHB ID values into the flow label - they're not needed for fast path processing, they only get used at ingress/egress routers, where the header is (possibly) going to be changed by rewriting the DSCP, and where it seems that you're willing to poke into transport headers to find values of interest. While it is possible in some cases to process all of this quite quickly - it isn't the basic packet forwarding operations that the IPv6 header should be supporting. On the other hand, the flow identifier (micro-flow if you like), whether it is being used for intserv, or just to allow routers to quickly find the likely forwarding information (quick key to a CAM lookup) is most definitely fast path material. It needs to be there for that, and it needs to be optimised for that. That is, whether or not the packet might also be passing through some diffserv domains, and getting diffserv processing along part of the path. So, if we are going to be moving the flow label definition anywhere into the normative text, the definition I would be happy with at the minute is exactly the one which currently exists. Now, I can imagine you wondering ... "higher up he agreed that we need to have QoS data available to diffserv, but now the only place to put it has just been eliminated as a possibility - contradiction..." Not at all, rather, false premise. The flow label isn't the only place that diffserv QoS signalling can be placed. It is just where you have currently decided is available to dump it. It is already clear that for IPv4 there's no flow label available, so you're willing to go trolling through transport headers to find the (inappropriate anyway, but never mind) information you need. For IPv6 you could do the same, except that ESP gets in the way (it will for IPv4 as well, in time), and the nature of the header chains makes the transport headers harder to locate, so you'd prefer not to have to do that. But IPv6 has another way - you can simply request that the sender add a new header (more on that in a second), require it to appear immediately after the hop-by-hop options (if any, or the IPv6 header otherwise) for it to be effective anyway (ie: you look that far, and assume default processing if the header doesn't appear there). In this header you can stick all the QoS classification information you're ever going to need. That can even look like a transport protocol port number combination if you like - just don't expect the port numbers (or even transport protocol) to have any relationship at all with the ones the transport protocol or its ports that are actually being used. I'll pick values that generate the QoS effects that I desire (which might sometimes be a 1::1 mapping from the value actually being used, but also might not be). What's more, you can also have this header carry an independent QoS request from the receiver (returned to the sender in an earlier reply packet) so that ISPs with a relationship with the recipient of the packet can classify it according to the receiver's view of how the packet ought be processed, instead of the senders. If the receiver starts getting packets with classifications it never authorised, it can just reset the connection, and if that doesn't work to halt it - then it is just another DoS attack to track and kill (since none of this data is authenticated, such attacks will be a fact of life, however the classification is done). Now to the header. The obvious clean way would be to define a new QoS header type, and stick the data in there. That way it contains exactly what is needed, and can be structured so as to be easy for hardware to access the fields (it could even carry authentication information if anyone believed that it would ever be actually used). However, adding a new header requires (at least) the source and destination to be able to handle that header, and requiring it to be in this particular position also means it would need to be understood by every router that might ever process a routing header. If IPv6 were widely deployed, that would be unimplementable - but since it isn't really yet, it is still feasible, though only barely I suspect. The other way is simply to carry this in a destination options header, and require that header to be immediately after hop by hop options (in other contexts we have discussed the possibility of headers appearing in "weird" orders, and I believe, agreed that support for that is needed). Then, a QoS option can be defined (unknown options can be skipped, so this is easier than a new header) to carry the necessary data. The format wouldn't be as flexible, or nice, as a new QoS header, but it is easier to get implemented (still have a possible problem with intermediate routers, and routing headers, but there is much less of that to worry about). The formatting can be made rigid - the QoS option could be required to be the first option in this particular header, etc, so it would still be easy for hardware to check for its presence, and extract the values (the only variable, in either case, is whether a hop by hop options header is present, and hardware needs to deal with that decision already - if it is, probably the packet will be slow path shunted, if it isn't, then the QoS data would be in a fixed position relative to the IPv6 header - or not there at all). Might something along these lines possibly satisfy everyone? 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 Aug 31 03:56:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VAuC40012028 for ; Fri, 31 Aug 2001 03:56:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VAuCTn012027 for ipng-dist; Fri, 31 Aug 2001 03:56:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VAu740012020 for ; Fri, 31 Aug 2001 03:56:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06810 for ; Fri, 31 Aug 2001 03:56:15 -0700 (PDT) Received: from starfruit.itojun.org ([57.72.6.170]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16471 for ; Fri, 31 Aug 2001 04:56:07 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 0C2407BC; Fri, 31 Aug 2001 19:52:15 +0900 (JST) To: "HIROKI ISHIBASHI" Cc: ipng@sunroof.eng.sun.com In-reply-to: bashi's message of Fri, 31 Aug 2001 11:42:49 +0900. <003701c131c6$9fd02af0$80482a0a@ABKIPNIPNC128> 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: Neighbor Solicitation over IPv6-overIPv4 Tunnel From: Jun-ichiro itojun Hagino Date: Fri, 31 Aug 2001 19:52:15 +0900 Message-Id: <20010831105215.0C2407BC@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >On IPv6-over-IPv4 (IPv6-over-IPv6) Tunnels, is it required to >send Neighbor Advertisement Messages in response to >Neighbor Solicitation Messages sent by the other end? >I am a little confused about this. since there's no real link-layer address, and there's only one guy at the other end, there is no need to resolve link-layer address via NS/NA exchange. packet can go out without waiting for link-layer address resolution. however, NS/NA for NUD (neighbor unreachability detection) will be exchanged. need to check RFC for MUST/SHOULD/MAY for this. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 31 08:00:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VF0840012330 for ; Fri, 31 Aug 2001 08:00:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VF088n012329 for ipng-dist; Fri, 31 Aug 2001 08:00:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VF0440012322 for ; Fri, 31 Aug 2001 08:00:04 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11256 for ; Fri, 31 Aug 2001 08:00:12 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15349 for ; Fri, 31 Aug 2001 08:00:05 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA08494; Fri, 31 Aug 2001 16:00:02 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA21496; Fri, 31 Aug 2001 16:00:02 +0100 Message-ID: <3B8FA68B.88990894@hursley.ibm.com> Date: Fri, 31 Aug 2001 10:00:27 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: alh-ietf@tndh.net CC: jarno.rajahalme@nokia.com, slblake@torrentnet.com, ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Brian E Carpenter wrote: > > > Like it or not, there *will* be scenarios > > where an ISP can't rely on the arriving DSCP value. > > Which is my point in calling them random bits. You are > correct that by maintining a chain of integrity in the > interpretation, there is no real need for the bits to > be consistent. The reality is that the only way to > reconstruct a meaning through the inconsistent SLA > chain is to go back to the immutable bits. > > I have no problem with a strongly worded BCP > that says all DSCP values should be reset to a set of > globally agreed values at exit. I understand that does > not force ISPs to abide, but at least it gives them > some clue what to do, and the market will sort out the > ones that comply from the ones that can't deliver the > expected level of service. Believe it or not after all I've said, I agree with you (personally, not speaking for the diffserv WG). But this is an operational issue where we would need at least some ISPs on board. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 31 08:01:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VF1n40012347 for ; Fri, 31 Aug 2001 08:01:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VF1nYi012346 for ipng-dist; Fri, 31 Aug 2001 08:01:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VF1j40012339 for ; Fri, 31 Aug 2001 08:01:46 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10073 for ; Fri, 31 Aug 2001 08:01:54 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10728 for ; Fri, 31 Aug 2001 08:01:53 -0700 (PDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7VF2I314250 for ; Fri, 31 Aug 2001 18:02:18 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 31 Aug 2001 18:01:51 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWBN09>; Fri, 31 Aug 2001 18:01:51 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198008@esebe004.NOE.Nokia.com> To: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: RE: Portmanteau reply Re: a), b), c), d), or e) Date: Fri, 31 Aug 2001 18:01:45 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I totally agree with the notion that for diffserv domains, or multiple ones with SLAs dealing with DSCPs in between, the DSCP field is enough for diffserv aggregation and policing. And I agree with Tony in that a second mutable 'DSCP' field doesn't provide any more additional value, since it seems that a domain egress always could map from an internal DSCP to an equivalent standardized DSCP value. It is the case that Christian brought up for which there could be value for the PHB-ID flow label: regardless of the DSCP value the packet came in (even if there is an SLA with the previous operator, or even if the original source did not pay for any QoS), there might be an SLA with the operator/customer later in the path that wants to pay for the preferential treatment. This treatment could be based on intserv, in which case the ingress would need to rewrite the incoming packet's flow label to use it for intserv for the rest of the path, if the source set it to '00000' or to any other "diffserv value". If it was already set to an intserv value, it doesn't need to be changed. (Maybe the destination would state in the intserv signaling method what flow label value to use?). A second alternative would be to use diffserv to get the preferential treatment for the rest of the path. The SLA would need to state how to classify the packets to get the preferential treatment. Christian's example used "traffic type" indicator (maybe in the flow label field). I believe the "traffic type" should be application independent, i.e. it should indicate the desired per-hop-behavior. This would enable SLAs like "if the source said it's important, I'll pay for the indicated better treatment". Some more comments inline below: Brian E Carpenter wrote: ... > > Speak to your co-author who keeps insisting that they are > > mutable. > > Yes, and I think I disagree with him :-) > I guess Alex's point has been that technically they are mutable, since muting them will not mess AH or any checksums. And I believe there are cases like what Francis mentioned: If the flow label is '00000' it might need be changed to some other value by some domain egress that somehow knows better than the (legacy) source. > > All diffserv classifiers require configuration. This would > mean configuring > a classifier to look for (say) > > Destination IP = Big Customer X > Source IP = * > Flow Label = 12345 > The wildcard in Source IP is dangerous. If there is a wildcard, someone having knowledge of the SLA could send the X some extra packets every now and then, if it will result in monetary flow from X to ISP. > This is a new form of diffserv classifier. Alex has a draft > ready to ship > on this, but we decided to wait. Since "12345" would be a > globally defined, > well known value, it is just built into the QOS policy > repository of any > ISP that wants to support it. (This is what Tony thinks should be done > with the DSCP values.) > There is the case I rephrased on top: Even if the source did not pay enough, and the packet would not get the treatment the destination would want, the packet may need to be re-classified and marked again. > ... > > > > I thought the current definition of the MF-classifier in > intserv would allow > > usage of the flow label field for classification. > > Yes, except that RFC 2460 does not describe this in normative text. > Well, it should, and the RSVP specs should allow MF-classifiers based on the flow label field, if they don't already. > It's the former; if an ISP chooses to disbelieve the upstream ISP, > and re-classify the traffic, the semantics of the transport > header are exactly the information of interest. But due to the end-to-end nature of the transport headers, it would be the eventual destination that needs to specify what values to use for classification. So it is not the ISP who "believes" any bits, but the SLA (where the parameter values originate from the eventual destination?) specifies the transport header values to match against. For the ISP the only semantics these bits have is that in the context of the specific SLA he believes getting paid for providing preferential treatment. > The security question is whether revealing a PHB ID is acceptable. This needs to be stressed in the discussion. It may be that some think that the equivalent of the port numbers would be revealed in the flow label. > The SLAs and local policies are database and human driven. > They need to anticipate > all ports etc to be used in advance. > Unless the classification would not be based on the transport stuff at all, but to the proposed diffserv flow label? Another problem for such SLAs could be IPv6 renumbering. Anybody thought of the implications? 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 Aug 31 08:45:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VFj140012397 for ; Fri, 31 Aug 2001 08:45:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VFj0ff012396 for ipng-dist; Fri, 31 Aug 2001 08:45:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VFiv40012389 for ; Fri, 31 Aug 2001 08:44:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17311 for ; Fri, 31 Aug 2001 08:45:05 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07603 for ; Fri, 31 Aug 2001 08:45:04 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA24064; Fri, 31 Aug 2001 16:45:02 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA14604; Fri, 31 Aug 2001 16:45:00 +0100 Message-ID: <3B8FB0F9.4D941555@hursley.ibm.com> Date: Fri, 31 Aug 2001 10:44:57 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bob Hinden CC: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) References: <4.3.2.7.2.20010830171421.022546b8@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK. The case of unencrypted tunnels is covered by RFC 2983, as well as a mention of protocol translation. But it doesn't analyse the case of reclassifying ESP-protected packets. Brian Bob Hinden wrote: > > Yes, that was my intent. Thanks for catching this. > > Bob > > At 11:31 PM 8/29/2001 +0300, jarno.rajahalme@nokia.com wrote: > >Brian, > > > >Maybe Bob meant just IPv6 tunneled over IPv4, not protocol translation? > > > > Jarno > > > >Brian E Carpenter wrote: > > > Bob Hinden wrote: > > > > > > > .. > > > > I think you are going a bit far to suggest that the fate of Diffserv > > > > depends on what the IPv6 w.g. does with the flow label > > > field. I suspect > > > > that Diffserv will live or die based on IPv4 usage. Also, > > > as IPv6 is > > > > deployed much of it will be initially carried over IPv4. > > > Any QoS solution > > > > that is going to be end-to-end will have to deal with a mix > > > of native IPv6 > > > > and IPv4/IPv6 headers. > > > > > > Indeed, and since I don't quite see how IPSEC and NAT-PT are going to > > > work together, the need that triggered this discussion (the need to > > > classify ESP packets in the middle of the Internet) really > > > doesn't arise > > > in the case of translated packets. The concern is for a > > > native IPv6 environment. > > > > > > Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 31 09:20:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VGK640012493 for ; Fri, 31 Aug 2001 09:20:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VGK6Y0012492 for ipng-dist; Fri, 31 Aug 2001 09:20:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VGK340012485 for ; Fri, 31 Aug 2001 09:20:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25945 for ; Fri, 31 Aug 2001 09:20:12 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA26145 for ; Fri, 31 Aug 2001 09:20:07 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA08608; Fri, 31 Aug 2001 12:19:58 -0400 Date: Fri, 31 Aug 2001 12:19:58 -0400 (EDT) From: Jim Bound To: Brian E Carpenter Cc: ipng Subject: Re: Another idea for the flow label In-Reply-To: <3B8BB2B6.1B35C0C5@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 Brian et al, A lot of mail but lots of it are repeating. The only way my change in vote for "c" will work is if we do this below per Brian. But I presented this case in front of the IETF WG at Minneapolis and folks did not want to go there and Steve presented good counter arguments to doing it. It is a compromise to do the below. A few statements: Immutable field: I agree with Tony 100% if we have a per microflow it should be immutable for that option and I mean in the strongest sense that it is read-only. I will not post my reasons again but they are in line with Tony and also that I am not comfortable saying nodes along the path will return the field to its former value. AT ALL.......Causing bugs with per microflows for apps that depend on it is something I could never support and to trust the edge and core with that without how its to be done is a bit of a stretch for me and I think for any IETF specifications sound protocol effect on networks. Immutable field is the quickest way to standards track I would argue for per micro-flows. In the future after some practical experience that could be re-discussed. MF Classifiers: We should solve this problem so that all classification is done only at the header. The multiple tuple value for classification beyond the header in Diffserv architecture was a huge mistake to put in the model and having boxes look at L4+ values is bordering absurdity IMO. IETF Rants we need to support QOS other standards: This is simply bogus logic. As Bob said the place to change our rules is in POISED not IPng. If Diffserv made a mistake or neglected to deal with cases like IPsec that does not mean IPv6 WG MUST support fixes to make it work. That is the bogus logic. It assumes a rule for us in IPv6 WG which DOES NOT EXIST. Arguing it may be the right thing to do is fair. I don't agree though. Are we getting anywhere? After working on this for many years I feel NO. The bottom line is can the IPv6 WG agree to the attached compromise in some form? That should be the first thing we have to agree on or Thomas is correct we need to just leave it alone for awhile till we can get consensus. We don't have it now IMO. Should we use the flow for other than QOS? I think that is a wise vision. But then we need some kind of compromise for that too. /jim On Tue, 28 Aug 2001, Brian E Carpenter wrote: > How would people feel about this encoding for the flow label > (deemed to be immutable end to end)? > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Per-microflow unique value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1| Non-unique value | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I'm not yet 100% convinced that the second case is sufficient for > diffserv, but at least it would be a more generic approach > than reserving half the space for diffserv. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 31 12:50:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VJo040012695 for ; Fri, 31 Aug 2001 12:50:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VJo0Mt012694 for ipng-dist; Fri, 31 Aug 2001 12:50:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VJnu40012687 for ; Fri, 31 Aug 2001 12:49:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09233 for ; Fri, 31 Aug 2001 12:50:05 -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 NAA25013 for ; Fri, 31 Aug 2001 13:50:32 -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 f7VJnSt14682; Fri, 31 Aug 2001 21:49:33 +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 VAA28955; Fri, 31 Aug 2001 21:49:28 +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.11.3/8.11.3) with ESMTP id f7VJnQl94003; Fri, 31 Aug 2001 21:49:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108311949.f7VJnQl94003@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: alh-ietf@tndh.net cc: "Brian E Carpenter" , "Steve Blake" , ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label In-reply-to: Your message of Tue, 28 Aug 2001 18:48:21 PDT. Date: Fri, 31 Aug 2001 21:49:26 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, I am afraid that you are right. Diffserv seems to need reclassification at some points in the backbone and 20 bits are not enough to do the job... not speaking of the IPsec issue. According to an old thread the extension header mechanism of IPv6 makes (re)classification at very high speed difficult, if we agree flow labels with semantic don't provide a solution, what to do? Regards Francis.Dupont@enst-bretagne.fr PS: some random ideas: - classify the first packet of a flow, use the flow label for next packets in the same flow: does this scale to a large number of flows? Latency of the first packet? - introduce a new destination option with needed infos? Can help for packets with a deep chain of extensions but not efficient for the standard case? (note I'd like to get a good solution for non-standard cases or extensions will suffer from the same problem than IPv4 options) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 31 13:18:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VKHw40012749 for ; Fri, 31 Aug 2001 13:17:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VKHwUw012748 for ipng-dist; Fri, 31 Aug 2001 13:17:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VKH040012736 for ; Fri, 31 Aug 2001 13:17:01 -0700 (PDT) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14113 for ; Fri, 31 Aug 2001 13:16:30 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15990 for ; Fri, 31 Aug 2001 13:16:29 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA20304; Fri, 31 Aug 2001 21:16:25 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA46264; Fri, 31 Aug 2001 21:16:25 +0100 Message-ID: <3B8FEEA3.3F66C5E7@hursley.ibm.com> Date: Fri, 31 Aug 2001 15:08:03 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Francis Dupont CC: alh-ietf@tndh.net, Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <200108311949.f7VJnQl94003@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Unfortunately I think the extension header mechanism is probably too heavy as Francis says, but I want to think a bit longer about that (and re-read kre's last message and some of Jarno's messages). Brian Francis Dupont wrote: > > Tony, I am afraid that you are right. Diffserv seems to need > reclassification at some points in the backbone and 20 bits are > not enough to do the job... not speaking of the IPsec issue. > According to an old thread the extension header mechanism of IPv6 > makes (re)classification at very high speed difficult, if we agree > flow labels with semantic don't provide a solution, what to do? > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: some random ideas: > - classify the first packet of a flow, use the flow label for > next packets in the same flow: does this scale to a large > number of flows? Latency of the first packet? > - introduce a new destination option with needed infos? Can help > for packets with a deep chain of extensions but not efficient > for the standard case? (note I'd like to get a good solution > for non-standard cases or extensions will suffer from the same > problem than IPv4 options) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 31 13:22:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VKMV40012766 for ; Fri, 31 Aug 2001 13:22:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VKMU4T012765 for ipng-dist; Fri, 31 Aug 2001 13: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VKMR40012758 for ; Fri, 31 Aug 2001 13:22:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23633 for ; Fri, 31 Aug 2001 13:22:31 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17677 for ; Fri, 31 Aug 2001 14:22:26 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA14430; Fri, 31 Aug 2001 21:22:27 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA16526; Fri, 31 Aug 2001 21:22:26 +0100 Message-ID: <3B8FEFE8.F1D1711A@hursley.ibm.com> Date: Fri, 31 Aug 2001 15:13:28 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: ipng@sunroof.eng.sun.com Subject: Re: Portmanteau reply Re: a), b), c), d), or e) References: <009CA59D1752DD448E07F8EB2F911757198008@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just to respond to one detail... jarno.rajahalme@nokia.com wrote: > > All diffserv classifiers require configuration. This would > > mean configuring > > a classifier to look for (say) > > > > Destination IP = Big Customer X > > Source IP = * > > Flow Label = 12345 > > > > The wildcard in Source IP is dangerous. If there is a wildcard, someone > having knowledge of the SLA could send the X some extra packets every now > and then, if it will result in monetary flow from X to ISP. Of course; I was just making up a simple example. A more likely example is that the Source IP is the range of addresses of another Big Customer Y, i.e. X is willing to pay more for traffic from Y. (And yes, even that is exposed to spoofing, but we know that ingress filtering is required anyway.) Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 31 13:26:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VKQR40012783 for ; Fri, 31 Aug 2001 13:26:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VKQRKX012782 for ipng-dist; Fri, 31 Aug 2001 13:26:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VKQN40012775 for ; Fri, 31 Aug 2001 13:26:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24072 for ; Fri, 31 Aug 2001 13:26:32 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20316 for ; Fri, 31 Aug 2001 14:26:27 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA14440; Fri, 31 Aug 2001 21:26:29 +0100 Received: from hursley.ibm.com (gsine01.us.sine.ibm.com [9.14.6.41]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA30994; Fri, 31 Aug 2001 21:26:29 +0100 Message-ID: <3B8FF0B5.3569FA0C@hursley.ibm.com> Date: Fri, 31 Aug 2001 15:16:53 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: ipng@sunroof.eng.sun.com Subject: Renumbering and SLAs [was: Portmanteau reply Re: a), b), c), d), or e)] References: <009CA59D1752DD448E07F8EB2F911757198008@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: ... > > The SLAs and local policies are database and human driven. > > They need to anticipate > > all ports etc to be used in advance. > > > > Unless the classification would not be based on the transport stuff at all, > but to the proposed diffserv flow label? > > Another problem for such SLAs could be IPv6 renumbering. Anybody thought of > the implications? What a great question. It is wider than just QOS of course, addresses can pop up anywhere in configs unfortunately. This is why instant renumbering is a dream; the procedures will have to involve notifying remote management systems of the update. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 31 13:47:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VKlm40012814 for ; Fri, 31 Aug 2001 13:47:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f7VKlmKD012813 for ipng-dist; Fri, 31 Aug 2001 13:47:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f7VKli40012806 for ; Fri, 31 Aug 2001 13:47:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06113 for ; Fri, 31 Aug 2001 13:47:53 -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 OAA01969 for ; Fri, 31 Aug 2001 14:48:20 -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 f7VKlZt16671; Fri, 31 Aug 2001 22:47:35 +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 WAA29231; Fri, 31 Aug 2001 22:47:35 +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.11.3/8.11.3) with ESMTP id f7VKlXl94332; Fri, 31 Aug 2001 22:47:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200108312047.f7VKlXl94332@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: alh-ietf@tndh.net, Steve Blake , ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label In-reply-to: Your message of Fri, 31 Aug 2001 15:08:03 CDT. <3B8FEEA3.3F66C5E7@hursley.ibm.com> Date: Fri, 31 Aug 2001 22:47:33 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Unfortunately I think the extension header mechanism is probably too heavy as Francis says, but I want to think a bit longer about that (and re-read kre's last message and some of Jarno's messages). => this is heavy but we can do more with this than with 20 bits, in fact we can do more with this than with protocol/ports (*)... The basic idea is to make (still unknown) avantages greater than (already known) drawbacks. Regards Francis.Dupont@enst-bretagne.fr (*) I have two different kinds of ideas about this: - first I don't fully understand what ISPs will do with protocol/ports because SLAs are not signaling: rules will be very coarse like "remark TCP port 80 to lower than best effort"... Perhaps protocol/ports are not designed for classification (:-). Of course, to pack them into 20 bits (or less!) won't make these field more useful! - if we use available bits with a better semantics both we need less (even less than 20 bits because we deal with macro flows in Diffserv but look at the last point) and we can do more with them, for instance code a stack of DSCPs (a good solution for the rewrite/restore issue). - a destination option (in a header just after the IPv6 header or the hop-by-hop/please-use-the-slow-path header) provides a lot of bits and is expandable, in fact it can (i.e. should) be expandable on the fly: a stack of annotations for classification? MTU is not a real issue because backbones have already larger MTUs than edge networks for other reasons, the last edge router just needs to cleanup the stack. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 31 17:14:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f810Ee40013041 for ; Fri, 31 Aug 2001 17:14:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f810EeZq013040 for ipng-dist; Fri, 31 Aug 2001 17: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f810Ea40013033 for ; Fri, 31 Aug 2001 17:14:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02279 for ; Fri, 31 Aug 2001 17:14:45 -0700 (PDT) Received: from k2.watercove.com ([12.104.0.98]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA17982 for ; Fri, 31 Aug 2001 18:15:14 -0600 (MDT) Received: by k2 with Internet Mail Service (5.5.2650.21) id ; Fri, 31 Aug 2001 20:17:06 -0400 Message-ID: <8D9C6ADAD0DBD4119F8D00508BF7CBD105247F@APO> From: Rajesh Ramankutty To: "'Internet-Drafts@ietf.org'" , ipng@sunroof.eng.sun.com Cc: "'satish_amara@3com.com'" , Ying Xu , Shaji Radhakrishnan , Ellis Wong Subject: RE: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt Date: Fri, 31 Aug 2001 20:13:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1327B.6E8A2D00" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1327B.6E8A2D00 Content-Type: text/plain; charset="iso-8859-1" Hi, The idea of carrying MPLS labels in IPv6 packet destination options is already patented by us in 3Com. We also compiled a ietf-draft in June, but delayed to send out. Attached below is the draft. Thanks, -rajesh -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, August 30, 2001 6:14 AM Cc: ipng@sunroof.eng.sun.com Subject: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPNGLS - IP Next Generation Label Switching Author(s) : V. Roesler et al. Filename : draft-roesler-ipngwg-ipngls-00.txt Pages : 17 Date : 29-Aug-01 This document proposes the forwarding of IPv6 packets using label switching techniques, with the same advantages of the Multiprotocol Label Switching (MPLS) architecture. The document proposes the mapping of all MPLS header fields into the IPv6 header, raising several advantages like the simplicity of the model, the decrease of overhead, and others. This mapping was called IP Next Generation Label Switching, or just IPngLS, and can work concurrently with MPLS, i.e. IPv6 packets are forwarded with IPngLS and IPv4 packets are forwarded with MPLS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-roesler-ipngwg-ipngls-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-roesler-ipngwg-ipngls-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-roesler-ipngwg-ipngls-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_000_01C1327B.6E8A2D00 Content-Type: text/plain; name="draft-mpls-label-encaps-ipv6-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-mpls-label-encaps-ipv6-00.txt" Network Working Group Shaji Radhakrishnan=20 Internet Draft Watercove Networks=20 June, 2001 Satish Amara=20 3COM corporation = =20 Rajesh Ramankutty=20 YingChun Xu=20 Ellis Wong=20 WaterCove Networks=20 =20 =20 =20 MPLS label stack encapsulation in Ipv6=20 =20 =20 =20 =20 Status of this Memo=20 =20 This document is an Internet Draft and is in full conformance with=20 all provisions of Section 10 of RFC2026. Internet Drafts are working = documents of the Internet Engineering Task Force (IETF), its areas,=20 and working groups. Note that other groups may also distribute=20 working documents as Internet Drafts.=20 =20 Internet Drafts are draft documents valid for a maximum of six=20 months and may be updated, replaced, or obsolete by other documents=20 at anytime. It is inappropriate to use Internet Drafts as reference=20 material or to cite them other than as "work in progress."=20 =20 The list of current Internet-Drafts can be accessed at=20 http://www.ietf.org/ietf/1id-abstracts.txt.=20 =20 The list of Internet-Draft Shadow Directories can be accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 In certain cases it may be useful to encapsulate MPLS packets in=20 IPV6 packets. This document describes a method to encapsulate MPLS=20 in IPV6 networks. =20 =20 1. Encapsulation in IPv6=20 =20 The IPv6 destination option or Flow-field will be used to=20 encapsulate the MPLS label. The LDP on the Egress router and LDP on=20 the ingress router will agree on what label to use and this label is = encapsulated in the IPV6 flow label. Presently, there are two=20 mechanisms for LDP peers discovery namely basic discovery and=20 extended discovery. Basic discovery is used to discover LDP peers,=20 which are directly connected. Extended discovery is used to discover = LDP peers, which are not directly connected. This mechanism will be=20 used to establish peering relationship between the LDP running on=20 Egress and Ingress routers. A new option in the LDP message is=20 =20 Radhakrishnan, Amara et.al &Expires Nov. 2001 1 = =0A= =0C < draft-mpls-label-encaps-ipv6-00.txt> November 2001=20 =20 =20 introduced to convey that extended label is encapsulated in IPV6=20 destination option or flow-field. Once the label is distributed by=20 the LDP on egress router to the LDP on Ingress router, then the=20 egress router will label the packet. The forwarding decision at=20 Ingress router will be based on destination option or flow-field in=20 IPV6 packet. If the egress node sets the flow-id field to zero=20 (i.e., the flow-id is not used for anything else like QoS), then the = flow-id can be used to encapsulate the top field in label stack. If=20 the flow-id is used to set QoS fields, then the destination=20 extension header options are used to carry the label or label stack. = =20 If only one label is present in the label stack, the best way is to=20 use the flow-id for carrying the label, if the flow-id is not used=20 for any other purpose. But another argument to simplify the = processing at both egress as well as ingress nodes, the extension=20 header is only used to specify the label stack. With this, the=20 egress node always use Ipv6 extension header to place the label=20 stack (whether label stack contains single or multiple labels) and=20 the ingress node always looks for label extension header to check=20 label stack.=20 =20 2. MPLS label stack transport in Ipv6 Extension header=20 =20 =20 The format of destination option header is the following.=20 =20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 | Next Header | Hdr Ext Len | |=20 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +=20 | |=20 . .=20 . Options .=20 . .=20 | |=20 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 The options are in TLV format as follows.=20 =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - =20 | Option Type | Opt Data Len | Option Data =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - =20 =20 Option Type :: 8-bit identifier of the type of option. The proposed=20 value is 2 for the MPLS label stack.=20 =20 Opt Data Len :: 8-bit unsigned integer. Length of the Option Data=20 field of this option, in octets. The length of each label is 32 bits = which 4 bytes, i.e. 20bit label, 1 bit for label stack, 3 bits for=20 experimental bits and 8 bit for TTL. I.e. if the label stack=20 contains 3 labels, the size will be 12 bytes.=20 =20 =20 =20 Radhakrishnan & Amara et. Al, Expires Nov. 2001 2 = =0A= =0C < draft-mpls-label-encaps-ipv6-00.txt> November 2001=20 =20 =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label = | Label | Exp |S| TTL = | =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 Label: Label Value, 20 bits=20 Exp: Experimental Use, 3 bits=20 S: Bottom of Stack, 1 bit=20 TTL: Time To Live field, 8bits=20 =20 =20 Option Data :: Variable-length field. Option-Type-specific data. The = data contains the encoded MPLS label stack. When placing the label=20 stack, the label in the top of the stack as the first label, the=20 next one in the stack will be the second label etc..=20 =20 =20 +----+ +----+ +----+ +----+ Cloud>=20 Egress |<------------IPV6Cloud------------>|Ingress=20 LSR LSR=20 =20 =20 =20 3. Label processing at egress node=20 =20 The outgoing packet will be a normal Ipv6 packet. If the flow-id is=20 set to zero, then the outgoing label is placed in the flow-id of the = Ipv6 packet. If there is a label stack, each label is placed in the=20 destination header options in order as described above. The=20 destination of this Ipv6 packet will be the ingress MPLS router,=20 which support Ipv6 on the ingress interface. A field in destination=20 option specifies that the top label (in label stack) is encapsulated = in flow-id.=20 =20 The TTL field from the label is copied to the Hop Limit field in the = Ipv6 header of the tunneled packet. In the ingress node, the Hop=20 Limit filed value is copied back to the TTL field of the label.=20 =20 4. Label processing at ingress node=20 =20 The ingress node looks for incoming Ipv6 packet and gets the=20 incoming flow label from the flow-Id of the Ipv6 packets for the=20 NHFLE entry. The ingress node also looks for any destination header=20 options for MPLS label stack. If any label stack is present, each=20 label from the destination option is taken in the order. The first=20 label should be the top of the stack, the second label will be the=20 second one from the top etc.. The label and stack processing are=20 done as described in the MPLS architecture.=20 =20 In certain cases (i.e., when security is not applied to the original = packet end-to-end) instead of tunneling MPLS packet in IPV6 packets=20 by the egress node, the packets can be transported in IPV6 packets=20 =20 Radhakrishnan & Amara et. Al, Expires Nov. 2001 3 = =0A= =0C < draft-mpls-label-encaps-ipv6-00.txt> November 2001=20 =20 =20 using routing header option. In that case the routing header would=20 specify the route. Routing header will contain two entries. The=20 first hop in the routing header will be Ingress router and the final = hop will be destination IP address of the packet. =20 =20 5. Security Considerations=20 =20 Security issues are not discussed in this document. =20 =20 6. References=20 =20 =20 [1] E. Rosen et.al =93MPLS Label Stack Encoding=94. =20 RFC3032, January 2001.=20 =20 [2] E. Rosen et.al =93Multiprotocol Label Switching Architecture=94. = RFC3031=20 [3] L. Andersson et al, "LDP Specification," =20 Internet-RFC 3036, Jan 2001.=20 =20 [4] Internet Protocol, Version 6 (IPv6) Internet-RFC 2460=20 =20 [5] J. Reynolds and J. Postel. "ASSIGNED NUMBERS". RFC1700, October = 1994.=20 =20 =20 Author's Addresses=20 =20 Shaji Radhakrishnan=20 WaterCove Networks =20 1750 East Golf Road, Suite 550=20 Schaumburg, IL 60173 =20 Phone: (847) 621-8913 =20 Email: sradhakrishnan@watercove.com=20 =20 Satish Amara=20 3Com Corporation =20 3800, Golf Road,=20 Rolling Meadows, IL 60008=20 Phone: 847-262-2563=20 Email: satish_amara@3com.com=20 =20 =20 Rajesh Ramankutty=20 3Com Corporation=20 3800, Golf Road,=20 Rolling Meadows, IL 60008=20 Phone: 847-262-2580=20 Email: rajesh_ramankutty@3com.com=20 =20 Yingchun Xu=20 WaterCove Networks =20 =20 Radhakrishnan & Amara et. Al, Expires Nov. 2001 4 = =0A= =0C < draft-mpls-label-encaps-ipv6-00.txt> November 2001=20 =20 =20 1750 East Golf Road, Suite 550=20 Schaumburg, IL - 60173 =20 Phone: (847) 477-9280 =20 Email: yxu@watercove.com=20 =20 =20 Ellis Wong=20 WaterCove Networks =20 285 Billerica Road=20 Chelmsford, MA - 01824 =20 Phone: (978) 608-2089 =20 Email: ewong@watercove.com=20 =20 =20 =20 Radhakrishnan & Amara et. Al, Expires Nov. 2001 5 = =0A= =0C ------_=_NextPart_000_01C1327B.6E8A2D00-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Aug 31 23:21:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f816L340013411 for ; Fri, 31 Aug 2001 23:21:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f816L3nn013410 for ipng-dist; Fri, 31 Aug 2001 23:21:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f816Kx40013403 for ; Fri, 31 Aug 2001 23:20:59 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14753 for ; Fri, 31 Aug 2001 23:21:10 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA11200 for ; Fri, 31 Aug 2001 23:21:09 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f816L6N14785; Sat, 1 Sep 2001 09:21:06 +0300 Date: Sat, 1 Sep 2001 09:21:06 +0300 (EEST) From: Pekka Savola To: Rajesh Ramankutty cc: Subject: RE: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt In-Reply-To: <8D9C6ADAD0DBD4119F8D00508BF7CBD105247F@APO> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 31 Aug 2001, Rajesh Ramankutty wrote: > Hi, > > The idea of carrying MPLS labels in IPv6 packet destination options is > already patented by us in 3Com. Thanks! Now we have two main reasons not to standardize this. :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------