From owner-ipng@sunroof.eng.sun.com Sun Jul 1 06:36:59 2001 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 f61DavdP021909 for ; Sun, 1 Jul 2001 06:36:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61DavM6021908 for ipng-dist; Sun, 1 Jul 2001 06:36:57 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61DardP021901 for ; Sun, 1 Jul 2001 06:36:54 -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 GAA09169 for ; Sun, 1 Jul 2001 06:37:04 -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 HAA12916 for ; Sun, 1 Jul 2001 07:37:01 -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 f61DaHT24163; Sun, 1 Jul 2001 15:36:18 +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 PAA10986; Sun, 1 Jul 2001 15:36:17 +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 f61DaGO07027; Sun, 1 Jul 2001 15:36:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107011336.f61DaGO07027@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Tue, 26 Jun 2001 19:40:29 +0200. Date: Sun, 01 Jul 2001 15:36:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: we have only to keep the discussion within boundaries (i don't like flame wars). => this discussion already occured without any result (no flame war too but only because we kept it within boundaries). It is just too late and to get a RFC 2553 bis published is more important than to try again to get a consensus on a subject we know it is near impossible. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 1 06:40:58 2001 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 f61DevdP021929 for ; Sun, 1 Jul 2001 06:40:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61Dev19021928 for ipng-dist; Sun, 1 Jul 2001 06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61DesdP021921 for ; Sun, 1 Jul 2001 06:40:54 -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 GAA09319 for ; Sun, 1 Jul 2001 06:41:03 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05945 for ; Sun, 1 Jul 2001 07:41:58 -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 f61DeiT22387; Sun, 1 Jul 2001 15:40:45 +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 PAA11019; Sun, 1 Jul 2001 15:40:44 +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 f61DegO07043; Sun, 1 Jul 2001 15:40:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107011340.f61DegO07043@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: itojun@iijlab.net, horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Tue, 26 Jun 2001 18:58:48 +0200. Date: Sun, 01 Jul 2001 15:40:42 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => you can use it with the V6ONLY stuff. yes, but on rfc2553-compliant system you cannot have both an AF_INET and an AF_INET6 socket listening on the same port. => you can do it with the V6ONLY stuff. (again) > => this is the standard way but with the V6ONLY way you can use the > single socket (my favorite) or the socket per IP version (Itojun's > favorite). The user shall choice his own favorite or the one which > matches the application constraints. the user can't choose anything! if he wants to listen both ipv4 and ipv6 traffic, he has to use an AF_INET6 socket with V6ONLY turned off. no other choice. => no, he can use one socket for both versions or two sockets, one per version, with V6ONLY turned on. The V6ONLY stuff was specified in order to enable that (because BIND 9 needs that for its filtering). Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 1 06:49:21 2001 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 f61DnLdP021948 for ; Sun, 1 Jul 2001 06:49:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61DnLDY021947 for ipng-dist; Sun, 1 Jul 2001 06:49:21 -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 f61DnHdP021940 for ; Sun, 1 Jul 2001 06:49:17 -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 GAA18065 for ; Sun, 1 Jul 2001 06:49:27 -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 HAA15097 for ; Sun, 1 Jul 2001 07:49:25 -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 f61DnOT05552; Sun, 1 Jul 2001 15:49:24 +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 PAA11055; Sun, 1 Jul 2001 15:47:46 +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 f61DljO07083; Sun, 1 Jul 2001 15:47:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107011347.f61DljO07083@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Tue, 26 Jun 2001 19:28:54 +0200. Date: Sun, 01 Jul 2001 15:47:45 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: it seems that there are many people in favor of changing the behaviour of AF_INET6 sockets: itojun, pekka, me, horape, brian, erik. => but there are more people in favor of keeping the behaviour of AF_INET6 sockets, they are only too bored by this discussion... only jim and francis do not agree. => don't answer in the list is not an agreement and don't forget this discussion already happened and the current 2553 bis only reflects the opinion of the majority at the last poll. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 1 07:32:49 2001 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 f61EWndP021992 for ; Sun, 1 Jul 2001 07:32:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61EWm55021991 for ipng-dist; Sun, 1 Jul 2001 07:32: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61EWjdP021984 for ; Sun, 1 Jul 2001 07:32:45 -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 HAA11205 for ; Sun, 1 Jul 2001 07:32:50 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21835 for ; Sun, 1 Jul 2001 08:32:48 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.141.79) by smtp3.libero.it (5.5.025) id 3AE9822800E9231C; Sun, 1 Jul 2001 16:32:30 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id CAA4428A40; Sun, 1 Jul 2001 16:31:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id B0DEC28A35; Sun, 1 Jul 2001 16:31:28 +0200 (CEST) Date: Sun, 1 Jul 2001 16:31:28 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200107011340.f61DegO07043@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 Sun, 1 Jul 2001, Francis Dupont wrote: > In your previous mail you wrote: > > > => you can use it with the V6ONLY stuff. > > yes, but on rfc2553-compliant system you cannot have both an AF_INET > and an AF_INET6 socket listening on the same port. > > => you can do it with the V6ONLY stuff. (again) only if your implementation allows you to do so. > > => this is the standard way but with the V6ONLY way you can use the > > single socket (my favorite) or the socket per IP version (Itojun's > > favorite). The user shall choice his own favorite or the one which > > matches the application constraints. > > the user can't choose anything! if he wants to listen both ipv4 and ipv6 > traffic, he has to use an AF_INET6 socket with V6ONLY turned off. > no other choice. > > => no, he can use one socket for both versions or two sockets, one per > version, with V6ONLY turned on. The V6ONLY stuff was specified in order > to enable that (because BIND 9 needs that for its filtering). only if your implementation allows you to do so. -- 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 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 1 08:36:56 2001 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 f61FaudP022067 for ; Sun, 1 Jul 2001 08:36:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61FaueQ022066 for ipng-dist; Sun, 1 Jul 2001 08:36:56 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61FapdP022059 for ; Sun, 1 Jul 2001 08:36: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 IAA19059 for ; Sun, 1 Jul 2001 08:37:01 -0700 (PDT) Received: from starfruit.itojun.org (ny-ppp016.iij-us.net [216.98.99.16]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25936 for ; Sun, 1 Jul 2001 09:37:58 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B9C677C3; Mon, 2 Jul 2001 00:31:44 +0900 (JST) To: Francis Dupont Cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Sun, 01 Jul 2001 15:40:42 +0200. <200107011340.f61DegO07043@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: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Mon, 02 Jul 2001 00:31:44 +0900 Message-Id: <20010701153144.B9C677C3@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => you can use it with the V6ONLY stuff. > yes, but on rfc2553-compliant system you cannot have both an AF_INET > and an AF_INET6 socket listening on the same port. >=> you can do it with the V6ONLY stuff. (again) again, there's no explicit text about this issue. i believe you are assuming a couple of things beyond documented, like when bind(2) should fail (it is also not documented). 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 Sun Jul 1 08:51:05 2001 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 f61Fp4dP022089 for ; Sun, 1 Jul 2001 08:51:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61Fp4vv022088 for ipng-dist; Sun, 1 Jul 2001 08:51: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61Fp1dP022081 for ; Sun, 1 Jul 2001 08:51: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 IAA02705 for ; Sun, 1 Jul 2001 08:51:10 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28678 for ; Sun, 1 Jul 2001 09:52:08 -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 f61FoTT24271; Sun, 1 Jul 2001 17:50: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 RAA11563; Sun, 1 Jul 2001 17:50: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 f61FoRO07646; Sun, 1 Jul 2001 17:50:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107011550.f61FoRO07646@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Roy Brabson" cc: Jim Bound , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com, itojun@iijlab.net, Mauro Tortonesi Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Wed, 27 Jun 2001 09:22:26 EDT. Date: Sun, 01 Jul 2001 17:50:27 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >From my reading of 2553bis, there seem to be at least two ways this can be implemented (not counting the semantic changes being proposed): => yes, you can have merged or split port space. Both are commonly implemented and the 2553 bis document accepts both. 2553 doesn't seem to specify which is the correct behavior. => of course: none is incorrect. it sounds like several others have as well (implemented separate space). => I implemented a shared space (before to adopt the "IPv6 is a new version, not a new protocol") and some others too. I don't believe one solution is definitely better than the other, in fact it is hard to see the difference. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 1 09:35:40 2001 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 f61GZedP022121 for ; Sun, 1 Jul 2001 09:35:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61GZe5D022120 for ipng-dist; Sun, 1 Jul 2001 09:35: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61GZadP022113 for ; Sun, 1 Jul 2001 09:35: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 JAA04230 for ; Sun, 1 Jul 2001 09:35:46 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07713 for ; Sun, 1 Jul 2001 10:36:46 -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 f61GY4T09103; Sun, 1 Jul 2001 18:34: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 SAA11716; Sun, 1 Jul 2001 18:34:04 +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 f61GY2O08107; Sun, 1 Jul 2001 18:34:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107011634.f61GY2O08107@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: Jim Bound , itojun@iijlab.net, horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Thu, 28 Jun 2001 11:35:53 +0200. Date: Sun, 01 Jul 2001 18:34:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one > using AF_INET and the other AF_INET6. RFC2553 does not state this behaviour. => I disagree. in fact many implementations do not allow to do this. => fix them! can you explain better? let's take two sockets, an AF_INET and an AF_INET6+V6ONLY one. can i bind them on the same port only if i bind first to 0.0.0.0 and then to ::? or is it also correct to bind first to :: and then to 0.0.0.0? => both, V6ONLY removes possible interferences between IPv6 and IPv4 spaces. RFC2553 is silent about this. => 2553 bis is not, reread the V6ONLY spec. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 1 09:41:37 2001 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 f61GfbdP022141 for ; Sun, 1 Jul 2001 09:41:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f61Gfb5g022140 for ipng-dist; Sun, 1 Jul 2001 09:41: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f61GfXdP022133 for ; Sun, 1 Jul 2001 09:41: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 JAA04408 for ; Sun, 1 Jul 2001 09:41:43 -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 KAA12349 for ; Sun, 1 Jul 2001 10:41:41 -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 f61GfaT16050; Sun, 1 Jul 2001 18:41:36 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA11752; Sun, 1 Jul 2001 18:41: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 f61GfZO08126; Sun, 1 Jul 2001 18:41:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107011641.f61GfZO08126@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Thu, 28 Jun 2001 11:22:40 +0200. Date: Sun, 01 Jul 2001 18:41:35 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > >> => you can use it with the V6ONLY stuff. > >yes, but on rfc2553-compliant system you cannot have both an AF_INET > >and an AF_INET6 socket listening on the same port. > > (just a picky comment) RFC2553 does not talk about the behavior > when try to bind(2) to both :: and 0.0.0.0 on the same port. some > systems reject bind(2) to 0.0.0.0, some does not. ok. i will try to explain better my thoughts. => OK because I don't understand what you want. i don't want to change RFC2553. i think that V6ONLY is a very good feature and may be sufficient to achieve a good af-indipendence. however, this moves the focus on the behaviour of bind and getaddrinfo (which is not described in detail in RFC2553 - i suppose because there is no consensus). some implementations of bind(2) allow binding of 0.0.0.0 and :: address on the same port, and some do not. i think that this may be a problem for the developers which are working in multi-platform environments. => the V6ONLY stuff is just here in order to give a way to enforce the same behavior on any compliant platform. i'd really like to minimize the negative effect of this behaviour, but i understand that there is not much that can be done about this. => one thing we can not do is to pick up an implementation and to make all others non-compliant. When there is no way to get a portable code for every compliant implementation we update the 2553 document. This was done for BIND 9 filtering and gave V6ONLY stuff. We should not go further without very good reasons, we should not break old codes too. i hope that we will come to a *BSD-like de-facto standard for the behaviour of bind and getaddrinfo, but i wonder if having no standard is even worse than having a bad standard (linux-like). => we have a specification (not a standard for the IETF, APIs are never on the standard track) and many years of experiments with it. Use it and close this discussion. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 1 22:59:38 2001 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 f625xcdP022728 for ; Sun, 1 Jul 2001 22:59:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f625xcOo022727 for ipng-dist; Sun, 1 Jul 2001 22:59:38 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f625xadP022720 for ; Sun, 1 Jul 2001 22:59:36 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f625wWU29911 for ipng@sunroof.eng.sun.com; Sun, 1 Jul 2001 22:58:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6238VdP022561 for ; Sun, 1 Jul 2001 20:08:31 -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 UAA06814 for ; Sun, 1 Jul 2001 20:08:41 -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 UAA23779 for ; Sun, 1 Jul 2001 20:08:40 -0700 (PDT) Received: from edi-view1.cisco.com (edi-view1.cisco.com [144.254.112.74]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6238mx21991; Sun, 1 Jul 2001 20:08:48 -0700 (PDT) Received: (dfawcus@localhost) by edi-view1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA18112; Mon, 2 Jul 2001 04:08:39 +0100 (BST) Date: Mon, 2 Jul 2001 04:08:39 +0100 From: Derek Fawcus To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) Message-ID: <20010702040838.A17740@edi-view1.cisco.com> Mail-Followup-To: Tim Hartrick , ipng@sunroof.eng.sun.com References: <200106291642.JAA03836@garcia.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200106291642.JAA03836@garcia.mentat.com>; from tim@mentat.com on Fri, Jun 29, 2001 at 09:42:59AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Jun 29, 2001 at 09:42:59AM -0700, Tim Hartrick wrote: > > As I understand the issues, applications may want to be able to specify > where the non-fragmentable part of the datagram ends and where the fragmentable Hmm - shouldn't the stack be able to determine this for itself? See if there's a routing header, if so shove the fragment header after it, if not shove after the HBH header (if present) or IPv6 header. > part begins. They also need to be able to specify where in a chain of > extension headers the stack should insert AUTH or ESP headers. I can accept that. > Similarly we need a mechanism which allows an application to determine > when receiving a datagram where the fragmentable part of the datagram begins That I can't see a need for. Why'd the receiver even care - it's the complete reassembled packet he's interested in. > and where in the chain of extension headers an AUTH or ESP header had > been located. Agreed. That could be handled simply be allowing the header to pass through in some fashion simply as a marker. They'd then be seen by the CMSG_ macros as any other type of header. Say convert AH inline to the following: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Payload Len | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ With the payload len set to zero, or even just leave the complete AH header in place. For ESP convert to the following inline: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding (2 bytes) | Pad Length | Next Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ with pad length == 2, and the decrypted payload following it. 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 Mon Jul 2 00:05:14 2001 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 f6275DdP022804 for ; Mon, 2 Jul 2001 00:05:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6275DxX022803 for ipng-dist; Mon, 2 Jul 2001 00:05:13 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62758dP022796 for ; Mon, 2 Jul 2001 00:05: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 AAA01925 for ; Mon, 2 Jul 2001 00:05:19 -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 AAA07621 for ; Mon, 2 Jul 2001 00:05:13 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA13196; Mon, 2 Jul 2001 16:06:21 +0900 (JST) Date: Mon, 02 Jul 2001 16:05:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy Brabson" Cc: ipng@sunroof.eng.sun.com Subject: Re: Duplicate Address Detection on a link-local address 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: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 29 Jun 2001 15:31:06 -0400, >>>>> "Roy Brabson" said: > I've got a question on Duplicate Address Detection for link-local > addresses. DAD states that a node must join the solicited-node > multicast group for the tentative address before beginning DAD. > Multicast Listener Discovery states that as part of joining a link-scope > multicast groups, other than the all-nodes group, a MLD Report message > must be sent. MLD also states that the source IP address in the MLD > message must be a link-local address. > So, what should be put in the source address for the MLD Report when the > a link-local address is being assigned and no other addresses exist for > the link? This has already been discussed, and the consensus was this: > There are some other alternatives which might make sense if bridges are > keying off MLD Reports to determine whether to forward multicast > packets: > - When assigning a tentative link-local address and no other address > exists for the router, send an MLD Report with the source address set > to the unspecified address. This is currently not allowed by MLD and > might result in the packet failing verification by a bridge/router and > therefore being discarded. See also the following discussion: http://www.wcug.wwu.edu/lists/ipng/200007/msg00193.html 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 Jul 2 01:05:42 2001 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 f6285gdP022910 for ; Mon, 2 Jul 2001 01:05:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6285gld022909 for ipng-dist; Mon, 2 Jul 2001 01:05:42 -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 f6285TdP022902 for ; Mon, 2 Jul 2001 01:05: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 BAA13341 for ; Mon, 2 Jul 2001 01:05:40 -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 BAA22470 for ; Mon, 2 Jul 2001 01:05:39 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6285be15838 for ; Mon, 2 Jul 2001 11:05:37 +0300 Date: Mon, 2 Jul 2001 11:05:37 +0300 (EEST) From: Pekka Savola To: Subject: Re: Duplicate Address Detection on a link-local address 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 Mon, 2 Jul 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > This has already been discussed, and the consensus was this: > > > There are some other alternatives which might make sense if bridges are > > keying off MLD Reports to determine whether to forward multicast > > packets: > > - When assigning a tentative link-local address and no other address > > exists for the router, send an MLD Report with the source address set > > to the unspecified address. This is currently not allowed by MLD and > > might result in the packet failing verification by a bridge/router and > > therefore being discarded. > > See also the following discussion: > http://www.wcug.wwu.edu/lists/ipng/200007/msg00193.html Speaking of which, I'm not sure whether there exists IETF practise for this.. Should there be notes kept on upcoming changes/caveats of different RFC's published by ipngwg? I mean, issues like these are pretty difficult to find in the mailing list archives if you weren't there (and even if you were, you might not remember them). Having these written down somewhere per RFC would make sure that they'll be checked when the RFC is being revised, and read by those interested in the issues. A draft version of the "updated" RFC if you may; of if not that, links to relevant discussions on the list. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 01:12:26 2001 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 f628CQdP022953 for ; Mon, 2 Jul 2001 01:12:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f628CQT9022952 for ipng-dist; Mon, 2 Jul 2001 01:12: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f628CMdP022945 for ; Mon, 2 Jul 2001 01:12:22 -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 BAA13933 for ; Mon, 2 Jul 2001 01:12:33 -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 CAA17121 for ; Mon, 2 Jul 2001 02:12:30 -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 f628BqT08525; Mon, 2 Jul 2001 10:11:52 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA01994; Mon, 2 Jul 2001 10:11:51 +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 f628BoO10141; Mon, 2 Jul 2001 10:11:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107020811.f628BoO10141@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-reply-to: Your message of Fri, 29 Jun 2001 14:19:14 PDT. <200106292119.OAA01216@feller.mentat.com> Date: Mon, 02 Jul 2001 10:11:50 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I believe that the core of the last discussion on this topic began with a message by Francis Dupont on December 15, 2000. The subject of that message was "destination option update". => in fact the discussion began some days before at the IETF meeting when Steve Deering said the problem I wanted to be solved was in the (advanced) API... In the discussion that followed there was the beginnings of a design to solve the problem, I hope. If so we can just jump right into the middle of that six month old discussion and finish off this issue. => I don't know if we can quickly reach a consensus. There is only one rough proposal... and the time is not very good (holidays, 4th July power down, etc). Do you believe we can do it before the cut-off? 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 Mon Jul 2 04:02:58 2001 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 f62B2wdP023108 for ; Mon, 2 Jul 2001 04:02:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62B2v5x023107 for ipng-dist; Mon, 2 Jul 2001 04:02:57 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62B2rdP023100 for ; Mon, 2 Jul 2001 04:02:53 -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 EAA14879 for ; Mon, 2 Jul 2001 04:03:00 -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 EAA09877 for ; Mon, 2 Jul 2001 04:02:56 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id UAA14645 for ; Mon, 2 Jul 2001 20:04:11 +0900 (JST) Date: Mon, 02 Jul 2001 20:02:49 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <200107020811.f628BoO10141@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: <200107020811.f628BoO10141@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: 60 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 02 Jul 2001 10:11:50 +0200, >>>>> Francis Dupont said: > I believe that the core of the last discussion on this topic began with > a message by Francis Dupont on December 15, 2000. The subject of that > message was "destination option update". > => in fact the discussion began some days before at the IETF meeting > when Steve Deering said the problem I wanted to be solved was in > the (advanced) API... > In the discussion that followed > there was the beginnings of a design to solve the problem, I hope. > If so we can just jump right into the middle of that six month old > discussion and finish off this issue. > => I don't know if we can quickly reach a consensus. There is only one > rough proposal... and the time is not very good (holidays, 4th July > power down, etc). Do you believe we can do it before the cut-off? 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. 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. If we're aiming at the 1st goal, I'm quite sure that we'll need much time to discuss it and reach a consensus. So, in this case, I'd like to separate this part from the "basic" part of the advanced API (as a separate draft). If we take the second approach, it might be possible to get a consensus in a relatively short period. So, it would be worth trying to keep the whole spec in a single document. As for no.1 vs no.2, I'm inclined to support no.2. Due to less flexibility, of course, we may see another ordering issue in the future. However, at least at this moment, I don't see a possibility to use an extension header (except destination options headers) in a different way than the recommended way specified in RFC 2460. And, with this approach, we might be able to avoid rewriting existing applications that already use rfc2292bis for some extension headers (except destination options ones). Comments? 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 Jul 2 04:09:05 2001 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 f62B95dP023128 for ; Mon, 2 Jul 2001 04:09:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62B95U5023127 for ipng-dist; Mon, 2 Jul 2001 04:09: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62B90dP023120 for ; Mon, 2 Jul 2001 04:09: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 EAA26422 for ; Mon, 2 Jul 2001 04:09:07 -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 FAA00408 for ; Mon, 2 Jul 2001 05:09:04 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id UAA14704 for ; Mon, 2 Jul 2001 20:10:23 +0900 (JST) Date: Mon, 02 Jul 2001 20:09:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: summary of discussions about the semantics of sin6_scope_id 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: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 27 Jun 2001 03:07:38 +0900, >>>>> JINMEI Tatuya said: > 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. Hmm, only a few people have stated preference on this issue. I don't think I've seen enough votes to make a decision, but we have to fix this soon. I'm still waiting for opinions for a while, so please speak up if anyone of you is interested in this topic. 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 Mon Jul 2 05:10:28 2001 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 f62CARdP023217 for ; Mon, 2 Jul 2001 05:10:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62CARqU023216 for ipng-dist; Mon, 2 Jul 2001 05:10: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62CANdP023209 for ; Mon, 2 Jul 2001 05:10:24 -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 FAA05252 for ; Mon, 2 Jul 2001 05:10:31 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01056 for ; Mon, 2 Jul 2001 05:10:30 -0700 (PDT) Received: from cisco.com (lon-sto4-lan-vlan133-dhcp47.cisco.com [144.254.108.114]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA21941; Mon, 2 Jul 2001 13:10:24 +0100 (BST) Message-ID: <3B406481.FD510B72@cisco.com> Date: Mon, 02 Jul 2001 13:09:37 +0100 From: Dario Accornero Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en, it MIME-Version: 1.0 To: Bill Fenner CC: roland.meyer@nokia.com, ipng@sunroof.eng.sun.com, mibs@ops.ietf.org Subject: Re: IPv6MIB Design References: <200106301516.IAA26450@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, I sent some comments and questions to the list a few weeks ago but never got a reply... Thanks, Dario Bill Fenner wrote: > > >What is the current state of the IPv6MIB design? > > It's more or less waiting for comments from implementors. > > >Where can one find (preliminary) results of the design work? > > http://www.aciri.org/fenner/mibs/v6/ > > or > > draft-ops-rfc{2011,2012,2013,2096}-update-00.txt > > 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 > -------------------------------------------------------------------- -- Dario Accornero - IOS Europe Development - IPv6 Team Stockley Park, Uxbridge, UK - voice +44 20 8756 6268 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 05:24:54 2001 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 f62COsdP023266 for ; Mon, 2 Jul 2001 05:24:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62COrUi023265 for ipng-dist; Mon, 2 Jul 2001 05:24:53 -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 f62COodP023258 for ; Mon, 2 Jul 2001 05:24: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 FAA27862 for ; Mon, 2 Jul 2001 05:24:57 -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 FAA05554 for ; Mon, 2 Jul 2001 05:24:56 -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 f62COGT08567; Mon, 2 Jul 2001 14:24:17 +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 OAA05426; Mon, 2 Jul 2001 14:24: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 f62COFO10918; Mon, 2 Jul 2001 14:24:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107021224.f62COFO10918@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-reply-to: Your message of Mon, 02 Jul 2001 20:02:49 +0900. Date: Mon, 02 Jul 2001 14:24:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 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. => we still need a format to do that (easy but this is missing). 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). => this is the only reasonnable option in the long term. 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 believe the issue has to be solved, a quick & dirty hack shan't be enough next time. If we're aiming at the 1st goal, I'm quite sure that we'll need much time to discuss it and reach a consensus. So, in this case, I'd like to separate this part from the "basic" part of the advanced API (as a separate draft). => I agree. And of course we'll need time to implement and experiment proposals. If we take the second approach, it might be possible to get a consensus in a relatively short period. So, it would be worth trying to keep the whole spec in a single document. => the discussion about header order showed clearly that we need some freedom. Only a major change in the API can give this. As for no.1 vs no.2, I'm inclined to support no.2. Due to less flexibility, of course, we may see another ordering issue in the future. => I think this will happen so I don't believe in the no.2. However, at least at this moment, I don't see a possibility to use an extension header (except destination options headers) in a different way than the recommended way specified in RFC 2460. => security headers... And, with this approach, we might be able to avoid rewriting existing applications that already use rfc2292bis for some extension headers => I know only telnet (routing header) and some specialized applications (MLD, traceroute6, ...). This doesn't seem to be a real problem (less than to keep the current advanced API). 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 Jul 2 07:23:06 2001 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 f62EN6dP023345 for ; Mon, 2 Jul 2001 07:23:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62EN64n023344 for ipng-dist; Mon, 2 Jul 2001 07:23: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62EN1dP023337 for ; Mon, 2 Jul 2001 07:23: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 HAA13152 for ; Mon, 2 Jul 2001 07:23:08 -0700 (PDT) Received: from starfruit.itojun.org (dial-108-D01.QXO1.equant.net [57.72.131.108]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24027 for ; Mon, 2 Jul 2001 08:22:54 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id AB8E27C4; Mon, 2 Jul 2001 19:16:22 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Mon, 02 Jul 2001 11:05:37 +0300. 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: Duplicate Address Detection on a link-local address From: Jun-ichiro itojun Hagino Date: Mon, 02 Jul 2001 19:16:22 +0900 Message-Id: <20010702101622.AB8E27C4@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Speaking of which, I'm not sure whether there exists IETF practise for >this.. >Should there be notes kept on upcoming changes/caveats of different RFC's >published by ipngwg? maybe this is time to compile "host requirement". Hi Marc ;-) 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 Jul 2 07:24:21 2001 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 f62EOKdP023362 for ; Mon, 2 Jul 2001 07:24:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62EOKb5023361 for ipng-dist; Mon, 2 Jul 2001 07:24: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62EOGdP023354 for ; Mon, 2 Jul 2001 07:24: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 HAA13888 for ; Mon, 2 Jul 2001 07:24:19 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29419 for ; Mon, 2 Jul 2001 08:25:18 -0600 (MDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id XAA25028; Mon, 2 Jul 2001 23:24:16 +0900 (JST) Received: from keiichi00.osaka.iij.ad.jp (keiichi00.osaka.iij.ad.jp [192.168.65.65]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id XAA01492; Mon, 2 Jul 2001 23:24:15 +0900 (JST) Date: Mon, 02 Jul 2001 23:24:23 +0900 Message-ID: <87ae2ns92g.wl@keiichi00.osaka.iij.ad.jp> From: Keiichi SHIMA To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <200107021224.f62COFO10918@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. References: <200107021224.f62COFO10918@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") 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 f62EOGdP023355 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Francis Dupont wrote: > 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 believe the issue has to be solved, a quick & dirty hack shan't be > enough next time. >From the MIP's point of view, I think this approach will solve the exthdr order problem related to MIP. Although, with respect to MIP, I guess the advapi is not important part for implementers because MIP is highly related to IPv6 stack, many MIP implemnters will make it in the kernel (and I am one of them). So few of them consider using advapi to realize MIP stack. Beside MIP, to make the insertion logic of destopt exthdrs more flexible sounds good for me. Destopt is a generic exthdr than other exthdrs, the flexibility will solve some future exthdr problems. I think most of us are thinking that the 1st approach that jinmei proposed is the ideal way. But we are worry about we must consume a lot of time to achive the real goal, a very flexible advapi, while we don't have much time... --- Keiichi SHIMA Internet Initiative Japan Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 07:29:44 2001 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 f62EThdP023408 for ; Mon, 2 Jul 2001 07:29:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62EThTp023407 for ipng-dist; Mon, 2 Jul 2001 07:29:43 -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 f62ETddP023400 for ; Mon, 2 Jul 2001 07:29:39 -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 HAA14729 for ; Mon, 2 Jul 2001 07:29:46 -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 IAA01770 for ; Mon, 2 Jul 2001 08:30:44 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GFU00D6YO9I08@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Mon, 02 Jul 2001 09:29:43 -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 f62ETgr20386; Mon, 02 Jul 2001 09:29:42 -0500 (CDT) Date: Mon, 02 Jul 2001 09:29:42 -0500 From: Matt Crawford Subject: Re: Duplicate Address Detection on a link-local address In-reply-to: "02 Jul 2001 19:16:22 +0900." <20010702101622.AB8E27C4@starfruit.itojun.org> To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Message-id: <200107021429.f62ETgr20386@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > maybe this is time to compile "host requirement". Hi Marc ;-) We have resisted that on several occasions before, but maybe now it IS time. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 07:49:36 2001 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 f62EnadP023527 for ; Mon, 2 Jul 2001 07:49:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62Ena8U023526 for ipng-dist; Mon, 2 Jul 2001 07:49: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62EnWdP023519 for ; Mon, 2 Jul 2001 07:49:33 -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 HAA16000 for ; Mon, 2 Jul 2001 07:49:40 -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 HAA16084 for ; Mon, 2 Jul 2001 07:49:39 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f62EnUk17667; Mon, 2 Jul 2001 17:49:30 +0300 Date: Mon, 2 Jul 2001 17:49:30 +0300 (EEST) From: Pekka Savola To: Jun-ichiro itojun Hagino cc: Subject: Re: Duplicate Address Detection on a link-local address In-Reply-To: <20010702101622.AB8E27C4@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 Mon, 2 Jul 2001, Jun-ichiro itojun Hagino wrote: > >Speaking of which, I'm not sure whether there exists IETF practise for > >this.. > >Should there be notes kept on upcoming changes/caveats of different RFC's > >published by ipngwg? > > maybe this is time to compile "host requirement". Hi Marc ;-) Can "problems" like these be addresses by writing a completely new RFC? Sure, if it were decided to never advance current RFC's, then writing new ones would help. ;-) But would it make sense to record some bits against current RFC's, so that nothing gets lost/forgotten when revising them? This way the information would be available in "raw" (I'd say draft, but that might have strong connotations) form? For example, once upon a time I was reading through KAME nd6_rtr.c, and saw: #if 0 /* RFC 2462 5.5.3 (e) */ [...] #else /* update from Jim Bound, (ipng 6712) */ [...] #endif Now try to figure out _which_ of the dozens of possible mail archivers that could be on.. ;-) Is this against IETF methodology? Would doing this mean that new "revisional" I-D's would have to be started on the subject? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 08:35:10 2001 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 f62FZAdP023702 for ; Mon, 2 Jul 2001 08:35:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62FZ9R8023701 for ipng-dist; Mon, 2 Jul 2001 08:35: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62FZ5dP023694 for ; Mon, 2 Jul 2001 08:35: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 IAA07718 for ; Mon, 2 Jul 2001 08:35:13 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06074 for ; Mon, 2 Jul 2001 09:35:11 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id IAA29636; Mon, 2 Jul 2001 08:35:03 -0700 (PDT) Received: from garcia.mentat.com (garcia [192.88.122.235]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id IAA26896; Mon, 2 Jul 2001 08:35:02 -0700 (PDT) Received: (from tim@localhost) by garcia.mentat.com (8.9.3+Sun/8.9.3) id IAA04888; Mon, 2 Jul 2001 08:38:33 -0700 (PDT) Date: Mon, 2 Jul 2001 08:38:33 -0700 (PDT) From: Tim Hartrick Message-Id: <200107021538.IAA04888@garcia.mentat.com> To: Francis.Dupont@enst-bretagne.fr Subject: Re: complete the advanced API (rfc2292bis) Cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, > > In your previous mail you wrote: > > I believe that the core of the last discussion on this topic began with > a message by Francis Dupont on December 15, 2000. The subject of that > message was "destination option update". > > => in fact the discussion began some days before at the IETF meeting > when Steve Deering said the problem I wanted to be solved was in > the (advanced) API... > > In the discussion that followed > there was the beginnings of a design to solve the problem, I hope. > If so we can just jump right into the middle of that six month old > discussion and finish off this issue. > > => I don't know if we can quickly reach a consensus. There is only one > rough proposal... and the time is not very good (holidays, 4th July > power down, etc). Do you believe we can do it before the cut-off? > Since I don't have any idea when the cut-off is since I won't be in London I don't know if we can make it or not. If we don't try then will be right back here again six months from now dredging up old discussions that should have been concluded the last time. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 09:05:28 2001 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 f62G5RdP023775 for ; Mon, 2 Jul 2001 09:05:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62G5RAW023774 for ipng-dist; Mon, 2 Jul 2001 09:05:27 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62G5OdP023767 for ; Mon, 2 Jul 2001 09:05: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 JAA11062 for ; Mon, 2 Jul 2001 09:05:28 -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 JAA17433 for ; Mon, 2 Jul 2001 09:05:27 -0700 (PDT) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f62GOf113467; Mon, 2 Jul 2001 12:24:41 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010702115736.02cae528@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jul 2001 12:02:28 -0400 To: Jun-ichiro itojun Hagino From: Marc Blanchet Subject: Re: Duplicate Address Detection on a link-local address Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20010702101622.AB8E27C4@starfruit.itojun.org> References: 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 At/À 19:16 2001-07-02 +0900, Jun-ichiro itojun Hagino you wrote/vous écriviez: > >Speaking of which, I'm not sure whether there exists IETF practise for > >this.. > >Should there be notes kept on upcoming changes/caveats of different RFC's > >published by ipngwg? > > maybe this is time to compile "host requirement". Hi Marc ;-) I know. Been working on that sloowly: did a lot of reading and note writing: this is a lot of work: so many documents: not only in the ipngwg, but also ngtrans, and other wg (mobileip, dhcp, ...)! A colleague started a parser to parse every document to find all the occurences of MUST/MAY/SHOULD and make a listing of it: was useful but a lot of noise to clear. Maybe I should wrap what I did up to now and then send it to you, so you will send me updates and this process will give me more pressure to finish the work... ;-))) Marc. >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 09:59:36 2001 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 f62GxZdP023810 for ; Mon, 2 Jul 2001 09:59:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62GxZn3023809 for ipng-dist; Mon, 2 Jul 2001 09:59: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62GxVdP023802 for ; Mon, 2 Jul 2001 09:59:31 -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 JAA06422 for ; Mon, 2 Jul 2001 09:59:40 -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 KAA28374 for ; Mon, 2 Jul 2001 10:59:37 -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 f62Gx7T33661; Mon, 2 Jul 2001 18:59:07 +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 SAA00341; Mon, 2 Jul 2001 18:59:07 +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 f62Gx2O11591; Mon, 2 Jul 2001 18:59:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107021659.f62Gx2O11591@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-reply-to: Your message of Mon, 02 Jul 2001 08:38:33 PDT. <200107021538.IAA04888@garcia.mentat.com> Date: Mon, 02 Jul 2001 18:59:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I don't know if we can quickly reach a consensus. There is only one > rough proposal... and the time is not very good (holidays, 4th July > power down, etc). Do you believe we can do it before the cut-off? > Since I don't have any idea when the cut-off is since I won't be in London => 13 and 20th July. I don't know if we can make it or not. => this is tactics: if now we should split the document in order to have the easy part ready ASAP. If we don't try then will be right back here again six months from now dredging up old discussions that should have been concluded the last time. => I agree we are not in a hurry for the header 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 Mon Jul 2 10:15:35 2001 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 f62HFZdP023847 for ; Mon, 2 Jul 2001 10:15:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62HFZlT023846 for ipng-dist; Mon, 2 Jul 2001 10:15: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62HFVdP023839 for ; Mon, 2 Jul 2001 10:15:31 -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 KAA09245 for ; Mon, 2 Jul 2001 10:15:38 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA19198 for ; Mon, 2 Jul 2001 11:16:37 -0600 (MDT) Received: from 157.54.7.67 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Jul 2001 09:45:35 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 09:44:55 -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, 2 Jul 2001 09:44:54 -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, 2 Jul 2001 09:44:09 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 2553 bind semantics harms the way to AF independence X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Mon, 2 Jul 2001 09:44:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2553 bind semantics harms the way to AF independence thread-index: AcECTDVPw2qrmmbfR3OhMe/F22NjWQAxzWRg From: "Christian Huitema" To: "Francis Dupont" , "Mauro Tortonesi" Cc: "Jim Bound" , , , X-OriginalArrivalTime: 02 Jul 2001 16:44:09.0276 (UTC) FILETIME=[372A2FC0:01C10316] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f62HFWdP023840 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, I believe that your comments are based on a host model that does not entirely cover reality. An IP address, v4 or v6, designates an interface, not a host. A host can have many IP addresses; it can be multi-homes to several interfaces, and it can be "artificially divided" into several "sub-host", e.g. when the host is the platform for several "sites", each with its own servers for HTTP, FTP, telnet and SMTP. In a multi-homed host, processes must obviously be able to bind to a specific address. For example, if a host supports www.example1.com and www.example2.com, you definitely expect that two different mail server processes will bind to www.example1.com:25 and www.example2.com:25. Another reason to do so may be to insist that a specific service is only reachable through a specific interface. You expect to achieve the address or interface selection by binding the socket to a specific address+port combination, not just a port number. Indeed, you want to be able to support this function for IPv4 and IPv6 addresses. In a multi-homed host that uses IPv4 and IPv6, you get quite a number of combinations. I may want a socket to all interfaces and all protocols, to a specific interface and a specific protocol. I could also imagine to "all protocols on a specific interface, but there is a slippery slope here. As we start taking advantage of the large IPv6 address space, we introduce new concepts such as privacy addresses, so we loose the restriction of "one address per interface", and the correspondence between "the IPv4 address of the interface" and "the IPv6 address of the interface" becomes fuzzy. Then, there are interfaces such as 6to4 that are IPv6 only. Pretty soon, you realize that the easiest way to select an interface is to bind to a port on a fully specified address, and that such sockets will by definition be single protocol. -- Christian Huitema > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Sunday, July 01, 2001 9:34 AM > To: Mauro Tortonesi > Cc: Jim Bound; itojun@iijlab.net; horape@tinuviel.compendium.net.ar; > ipng@sunroof.eng.sun.com > Subject: Re: RFC 2553 bind semantics harms the way to AF independence > > In your previous mail you wrote: > > > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one > > using AF_INET and the other AF_INET6. > > RFC2553 does not state this behaviour. > > => I disagree. > > in fact many implementations do not allow to do this. > > => fix them! > > can you explain better? let's take two sockets, an AF_INET and an > AF_INET6+V6ONLY one. can i bind them on the same port only if i > bind first to 0.0.0.0 and then to ::? or is it also correct to bind > first to :: and then to 0.0.0.0? > > => both, V6ONLY removes possible interferences between IPv6 and IPv4 > spaces. > > RFC2553 is silent about this. > > => 2553 bis is not, reread the V6ONLY spec. > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 10:30:08 2001 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 f62HU7dP023887 for ; Mon, 2 Jul 2001 10:30:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62HU6js023886 for ipng-dist; Mon, 2 Jul 2001 10:30: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62HTwdP023879 for ; Mon, 2 Jul 2001 10:29: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 KAA08126 for ; Mon, 2 Jul 2001 10:29:53 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA25826 for ; Mon, 2 Jul 2001 11:30:53 -0600 (MDT) Received: from 157.54.1.52 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 02 Jul 2001 10:21:50 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 2 Jul 2001 10:21:38 -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.2883); Mon, 2 Jul 2001 10:21:37 -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, 2 Jul 2001 10:21:03 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: RE: IPv6MIB Design Date: Mon, 2 Jul 2001 10:21:04 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC101671E94@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6MIB Design thread-index: AcEC8EblZZrdqpPRQTmhPiR94Chq1wAKvcQQ From: "Dave Thaler" To: "Dario Accornero" , "Bill Fenner" Cc: , , X-OriginalArrivalTime: 02 Jul 2001 17:21:03.0745 (UTC) FILETIME=[5F175710:01C1031B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f62HTxdP023880 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, thanks Dario. The mib team still needs to discuss your comments. We're hoping for some comments from others as well. -Dave > -----Original Message----- > From: Dario Accornero [mailto:daccorne@cisco.com] > Sent: Monday, July 02, 2001 5:10 AM > To: Bill Fenner > Cc: roland.meyer@nokia.com; ipng@sunroof.eng.sun.com; mibs@ops.ietf.org > Subject: Re: IPv6MIB Design > > Bill, > > I sent some comments and questions to the list a few weeks ago but > never got a reply... > > Thanks, > Dario -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 11:56:41 2001 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 f62IufdP024049 for ; Mon, 2 Jul 2001 11:56:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62IufD1024048 for ipng-dist; Mon, 2 Jul 2001 11:56: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62IuadP024041 for ; Mon, 2 Jul 2001 11:56: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 LAA19471 for ; Mon, 2 Jul 2001 11:56:44 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05105 for ; Mon, 2 Jul 2001 11:56:42 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA00564; Mon, 2 Jul 2001 11:56:29 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA02519; Mon, 2 Jul 2001 11:56:29 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA02092; Mon, 2 Jul 2001 11:58:17 -0700 (PDT) Date: Mon, 2 Jul 2001 11:58:17 -0700 (PDT) From: Tim Hartrick Message-Id: <200107021858.LAA02092@feller.mentat.com> To: Francis.Dupont@enst-bretagne.fr Subject: Re: complete the advanced API (rfc2292bis) Cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, > > In your previous mail you wrote: > > > => I don't know if we can quickly reach a consensus. There is only one > > rough proposal... and the time is not very good (holidays, 4th July > > power down, etc). Do you believe we can do it before the cut-off? > > > > Since I don't have any idea when the cut-off is since I won't be in London > > => 13 and 20th July. > > I don't know if we can make it or not. > > => this is tactics: if now we should split the document in order to have > the easy part ready ASAP. > > If we don't try then will be right back here again six months from > now dredging up old discussions that should have been concluded the > last time. > > => I agree we are not in a hurry for the header stuff. > Making to these deadlines seems like a bad idea if the consequence will be that we split off content that will then be completely and unnecessarily redesigned thus rendering piles of existing code obsolete. The draft has languished for two plus years I think. Another four months won't make a difference. We should keep the document together in one piece and address the existing problems, not speculative problems. Rather than continuing with this meta discussion, why don't we move on to the meat of getting the issues addressed. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 12:00:34 2001 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 f62J0XdP024069 for ; Mon, 2 Jul 2001 12:00:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62J0XBl024068 for ipng-dist; Mon, 2 Jul 2001 12: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62J0UdP024061 for ; Mon, 2 Jul 2001 12:00: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 MAA19964 for ; Mon, 2 Jul 2001 12:00:37 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06752 for ; Mon, 2 Jul 2001 12:00:35 -0700 (PDT) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f62JJp115379 for ; Mon, 2 Jul 2001 15:19:51 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010702150145.02efb3e0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 02 Jul 2001 15:03:22 -0400 To: ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: use of :: as source address in RS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk - probably something very obvious. sorry if it is the case. - RFC2461 says for Router solicitation: Source Address An IP address assigned to the sending interface, or the unspecified address if no address is assigned to the sending interface. I'm trying to find the case where the unspecified address would be used as source address in RS. If you are going to use RS, it is because you are using autoconfig mode. Then the link-local would be available, since you would be DADing it before using it and then use the link-local as source address of the RS. If the link-local is not usable because you receive a response to the dad on the link-local, then you would have to construct some unique interface id that need to be checked again with dad, which may end up not having a link-local. question is then: in which case the RS could have the unspecified address as the source address. Any idea? sorry if it is obvious. Thanks, 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 Mon Jul 2 12:14:56 2001 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 f62JEudP024105 for ; Mon, 2 Jul 2001 12:14:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62JEukQ024104 for ipng-dist; Mon, 2 Jul 2001 12:14:56 -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 f62JEqdP024097 for ; Mon, 2 Jul 2001 12:14: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 MAA24382 for ; Mon, 2 Jul 2001 12:15:00 -0700 (PDT) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03313 for ; Mon, 2 Jul 2001 13:14:57 -0600 (MDT) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id WAA02620; Mon, 2 Jul 2001 22:14:56 +0300 Date: Mon, 2 Jul 2001 22:14:56 +0300 Message-Id: <200107021914.WAA02620@burp> From: Markku Savela To: Marc.Blanchet@viagenie.qc.ca CC: ipng@sunroof.eng.sun.com In-reply-to: <5.1.0.14.1.20010702150145.02efb3e0@mail.viagenie.qc.ca> (message from Marc Blanchet on Mon, 02 Jul 2001 15:03:22 -0400) Subject: Re: use of :: as source address in RS Reply-to: Markku.Savela@iki.fi References: <5.1.0.14.1.20010702150145.02efb3e0@mail.viagenie.qc.ca> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > question is then: in which case the RS could have the unspecified > address as the source address. After the interface has come up, I do the duplicate address test and sending RS in parallel, thus usually, for the first RS, there is no valid address available (it is still tentative) and it goes out with src=::. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 12:24:51 2001 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 f62JOpdP024135 for ; Mon, 2 Jul 2001 12:24:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62JOo7a024134 for ipng-dist; Mon, 2 Jul 2001 12:24: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62JOkdP024127 for ; Mon, 2 Jul 2001 12:24:46 -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 MAA25428 for ; Mon, 2 Jul 2001 12:24:54 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07345 for ; Mon, 2 Jul 2001 13:24:52 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA00649; Mon, 2 Jul 2001 12:25:29 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA03284; Mon, 2 Jul 2001 12:25:30 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA02123; Mon, 2 Jul 2001 12:27:17 -0700 (PDT) Date: Mon, 2 Jul 2001 12:27:17 -0700 (PDT) From: Tim Hartrick Message-Id: <200107021927.MAA02123@feller.mentat.com> To: ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: complete the advanced API (rfc2292bis) X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > 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. > > If we're aiming at the 1st goal, I'm quite sure that we'll need much > time to discuss it and reach a consensus. So, in this case, I'd like > to separate this part from the "basic" part of the advanced API (as a > separate draft). > > If we take the second approach, it might be possible to get a > consensus in a relatively short period. So, it would be worth trying > to keep the whole spec in a single document. > > As for no.1 vs no.2, I'm inclined to support no.2. Due to less > flexibility, of course, we may see another ordering issue in the > future. However, at least at this moment, I don't see a possibility > to use an extension header (except destination options headers) in a > different way than the recommended way specified in RFC 2460. And, > with this approach, we might be able to avoid rewriting existing > applications that already use rfc2292bis for some extension headers > (except destination options ones). > > Comments? > I agree with approach no.2 not only because it is the most expedient but I don't see what other flexibility is required. If we allow the application, via ancillary data, to specify multiple destination options headers and place the fragmentation header (and possible AH and ESP) as the application sees fit within the datagram then the only piece of flexability that is missing is the ability to add as yet unspecified extension header types. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 12:40:15 2001 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 f62JeEdP024174 for ; Mon, 2 Jul 2001 12:40:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62JeElC024173 for ipng-dist; Mon, 2 Jul 2001 12:40: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62JeAdP024166 for ; Mon, 2 Jul 2001 12:40: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 MAA08072 for ; Mon, 2 Jul 2001 12:40:08 -0700 (PDT) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13736 for ; Mon, 2 Jul 2001 13:40:05 -0600 (MDT) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id WAA02651; Mon, 2 Jul 2001 22:40:06 +0300 Date: Mon, 2 Jul 2001 22:40:06 +0300 Message-Id: <200107021940.WAA02651@burp> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: Subject: Re: complete the advanced API (rfc2292bis) References: <200107020811.f628BoO10141@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-2022-JP Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: JINMEI Tatuya / $B?@L@C#:H(B > > 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 like 1. It's simpler, easier to implement and document. Nice generic and dumb API. To me it seems to be more work, if you have to define, implement and document every possible extension header separately in the API (as 2 will require). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 15:02:42 2001 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 f62M2gdP024270 for ; Mon, 2 Jul 2001 15:02:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62M2fUq024269 for ipng-dist; Mon, 2 Jul 2001 15:02:41 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62M2bdP024262 for ; Mon, 2 Jul 2001 15:02:37 -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 PAA11058 for ; Mon, 2 Jul 2001 15:02:43 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15102 for ; Mon, 2 Jul 2001 16:03:44 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA01335; Mon, 2 Jul 2001 15:03:18 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA08142; Mon, 2 Jul 2001 15:03:17 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id PAA02212; Mon, 2 Jul 2001 15:05:05 -0700 (PDT) Date: Mon, 2 Jul 2001 15:05:05 -0700 (PDT) From: Tim Hartrick Message-Id: <200107022205.PAA02212@feller.mentat.com> To: ipng@sunroof.eng.sun.com, msa@burp.tkv.asdf.org Subject: Re: complete the advanced API (rfc2292bis) X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku > > > From: JINMEI Tatuya / $B?@L@C#:H(B > > > > 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 like 1. It's simpler, easier to implement and document. Nice generic > and dumb API. > Easier only if one doesn't have existing software which implements and uses the current API along with documentation that documents the current API. If one does have existing code and documentation then 1. just looks like double the work and headaches for one's customers. Note that the current Advanced API is not less than the second major revision of this API. For those of us that had the pleasure of implementing the last major revision four or so years ago and then throwing it out, 1. seems like complete insanity. > To me it seems to be more work, if you have to define, implement and > document every possible extension header separately in the API (as 2 > will require). > This would be true if it were possible to add a new extension header type without modifying the kernel. It isn't really possible in the implementations I have seen so there really isn't any flexibility gained by throwing out the existing extension header API. New extension headers will require kernel modifications. Once kernel modifications are required, adding API hooks to deal with the new extension header is straight forward. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 15:16:17 2001 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 f62MGHdP024340 for ; Mon, 2 Jul 2001 15:16:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62MGHS9024339 for ipng-dist; Mon, 2 Jul 2001 15:16:17 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62MG8dP024323; Mon, 2 Jul 2001 15:16: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 PAA12812; Mon, 2 Jul 2001 15:16:11 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net [4.60.68.77]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20770; Mon, 2 Jul 2001 16:16:09 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 02 Jul 2001 15:15:00 -0700 Received: from eagleswings [192.168.123.14] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id C6F4AE4DD24943898D29A270D68A7147 for plus 5 more; Mon, 02 Jul 2001 15:15:00 -0700 Reply-To: From: "Tony Hain" To: Cc: , , , , Subject: Provider-Independent IPv6 address format & usage drafts Date: Mon, 2 Jul 2001 15:14:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: ADA5AF46-2C3341AA-A6D16692-57CC9371 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are pointers to the current -00 versions of the Provider-Independent address format and usage drafts I have been working on. http://www.tndh.net/~tony/ietf/draft-hain-ipv6-PI-addr-fmt-00.txt http://www.tndh.net/~tony/ietf/draft-hain-ipv6-PI-addr-use-00.txt I would expect the first to be a document for the IPv6 wg, while the second would be for the Muti6 wg. I do not expect these to be wg documents before any discussion at London, so please list them as draft-hain for now, and we will rename when appropriate. Thanks, 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 Jul 2 15:26:16 2001 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 f62MQFdP024380 for ; Mon, 2 Jul 2001 15:26:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62MQFer024379 for ipng-dist; Mon, 2 Jul 2001 15: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 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 f62MQCdP024372 for ; Mon, 2 Jul 2001 15:26:12 -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 PAA15295 for ; Mon, 2 Jul 2001 15:26:19 -0700 (PDT) Received: from burp (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24499 for ; Mon, 2 Jul 2001 16:26:17 -0600 (MDT) Received: (from msa@localhost) by burp (8.9.3/8.9.3/Debian 8.9.3-21) id BAA02830; Tue, 3 Jul 2001 01:26:14 +0300 Date: Tue, 3 Jul 2001 01:26:14 +0300 Message-Id: <200107022226.BAA02830@burp> From: Markku Savela To: tim@mentat.com CC: ipng@sunroof.eng.sun.com In-reply-to: <200107022205.PAA02212@feller.mentat.com> (message from Tim Hartrick on Mon, 2 Jul 2001 15:05:05 -0700 (PDT)) Subject: Re: complete the advanced API (rfc2292bis) References: <200107022205.PAA02212@feller.mentat.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Tim Hartrick > This would be true if it were possible to add a new extension header type > without modifying the kernel. It isn't really possible in the implementations > I have seen so there really isn't any flexibility gained by throwing out > the existing extension header API. New extension headers will require > kernel modifications. Once kernel modifications are required, adding API > hooks to deal with the new extension header is straight forward. If you consider dynamically loadable modules (DLL's) kernel extensions, then you are right. It should be possible to add support for a totally new extension header to an existing stack by a loadable module, which attaches to the stack, without touching the stack and API code itself. This requirement does have some effect on API, and this is why I have some concern that the current "hardcoded known headers approach" will differ too much from what I have to put in. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 2 15:36:30 2001 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 f62MaUdP024402 for ; Mon, 2 Jul 2001 15:36:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62MaUjV024401 for ipng-dist; Mon, 2 Jul 2001 15:36:30 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62MaPdP024394 for ; Mon, 2 Jul 2001 15:36: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 PAA14921 for ; Mon, 2 Jul 2001 15:36:33 -0700 (PDT) Received: from starfruit.itojun.org (dial-108-D01.QXO1.equant.net [57.72.131.108]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28300 for ; Mon, 2 Jul 2001 16:36:30 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 58B477BC; Tue, 3 Jul 2001 07:36:24 +0900 (JST) To: Markku Savela Cc: tim@mentat.com, ipng@sunroof.eng.sun.com In-reply-to: msa's message of Tue, 03 Jul 2001 01:26:14 +0300. <200107022226.BAA02830@burp> 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: complete the advanced API (rfc2292bis) From: Jun-ichiro itojun Hagino Date: Tue, 03 Jul 2001 07:36:24 +0900 Message-Id: <20010702223624.58B477BC@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm finding hard time trying to find a good balance between BPF, and basic API. advanced API (ancillary data) should fit somewhere inbetween. RFC2292 had a good balance by limiting the ordering of headers to what is documented in RFC2460, and limiting itself from handling non-IPv6 headers like AH/ESP (i believe users do not want to manipulate AH/ESP from normal socket API. also, how do you plan to handle IPsec-tunnelled packets?). by removing more limitations, we get closer and closer to BPF... i guess, if we follow the spirit of RFC2292, we first need to evaluate RFC2460, to see if we need to remove some of suggested header ordering constraints - MIP6 seem to conflict with it, with some reasons (i have trouble chasing recent MIP6 discussions, so i may be wrong). then, we design 2292bis to follow the new header ordering constraint. just a meta-thought. 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 Jul 2 15:45:29 2001 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 f62MjTdP024422 for ; Mon, 2 Jul 2001 15:45:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62MjTWG024421 for ipng-dist; Mon, 2 Jul 2001 15:45: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62MjPdP024414 for ; Mon, 2 Jul 2001 15:45: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 PAA29449 for ; Mon, 2 Jul 2001 15:45:32 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04062 for ; Mon, 2 Jul 2001 15:45:31 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA01580; Mon, 2 Jul 2001 15:46:05 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA09708; Mon, 2 Jul 2001 15:46:05 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id PAA02238; Mon, 2 Jul 2001 15:47:52 -0700 (PDT) Date: Mon, 2 Jul 2001 15:47:52 -0700 (PDT) From: Tim Hartrick Message-Id: <200107022247.PAA02238@feller.mentat.com> To: msa@burp.tkv.asdf.org Subject: Re: complete the advanced API (rfc2292bis) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku, > > If you consider dynamically loadable modules (DLL's) kernel > extensions, then you are right. It should be possible to add support > for a totally new extension header to an existing stack by a loadable > module, which attaches to the stack, without touching the stack and > API code itself. > > This requirement does have some effect on API, and this is why I have > some concern that the current "hardcoded known headers approach" will > differ too much from what I have to put in. > If dynamic loaded modules are available to extend the stack then it is straight forward to use them to extend the existing API. This is largely an academic discussion, however. To my knowledge there are no current proposals for adding new extension headers and as far as I remember there have never been any such proposals. If an implementor wants to code their implementation for an event that isn't likely to ever come that is certainly the implementors choice. However, I would object to existing code of other implementors being discarded wholesale to make it easier for an implementor to make that choice. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 15:47:22 2001 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 f62MlMdP024442 for ; Mon, 2 Jul 2001 15:47:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f62MlL6V024441 for ipng-dist; Mon, 2 Jul 2001 15:47:21 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62MlHdP024434 for ; Mon, 2 Jul 2001 15:47:17 -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 PAA16432 for ; Mon, 2 Jul 2001 15:47:24 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06268 for ; Mon, 2 Jul 2001 15:47:24 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA01591; Mon, 2 Jul 2001 15:47:54 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA09741; Mon, 2 Jul 2001 15:47:55 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id PAA02241; Mon, 2 Jul 2001 15:49:42 -0700 (PDT) Date: Mon, 2 Jul 2001 15:49:42 -0700 (PDT) From: Tim Hartrick Message-Id: <200107022249.PAA02241@feller.mentat.com> To: itojun@iijlab.net Subject: Re: complete the advanced API (rfc2292bis) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > just a meta-thought. > And a well reasoned meta-thought it is.:-) Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 2 20:53:44 2001 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 f633ridP024638 for ; Mon, 2 Jul 2001 20:53:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f633riHU024637 for ipng-dist; Mon, 2 Jul 2001 20:53: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f633redP024630 for ; Mon, 2 Jul 2001 20:53:41 -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 UAA09518 for ; Mon, 2 Jul 2001 20:53:49 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA03326 for ; Mon, 2 Jul 2001 21:54:46 -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 f633qnV00570; Tue, 3 Jul 2001 10:52:51 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: References: <200107020811.f628BoO10141@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Jul 2001 10:52:49 +0700 Message-ID: <568.994132369@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 02 Jul 2001 20:02:49 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | If we take the second approach, it might be possible to get a | consensus in a relatively short period. So, it would be worth trying | to keep the whole spec in a single document. This is not the right way, though I found myself tempted to agree with it for a while. As long as the read interface is set, so any random application can deal (if it wants to) with anything that is handed to it over the net, we could perhaps defer on maying a "standard" on how to send arbitrary sequences for some time - allow various implementors to dream up their own ways to handle this, and try them, and just wait and see which of those is best liked by application writers. Since relatively few apps need the flexibility, the costs in having to deal with multiple different methods in the shortish term shouldn't be too great. Or that's the way I was thinking. But I always knew that wasn't really a good approach, and Francis' message convinced me that it wouldn't be the right thing to do. So, I'd prefer to complete & document the receive case, and just leave the send case for a later doc to define. That is, not have any method at all defined for inserting headers in the new doc for now (implementors can keep implementing the current spec). 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 Jul 3 00:51:01 2001 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 f637p1dP024855 for ; Tue, 3 Jul 2001 00:51:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f637p1uW024854 for ipng-dist; Tue, 3 Jul 2001 00:51: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f637ovdP024847 for ; Tue, 3 Jul 2001 00:50: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 AAA25597 for ; Tue, 3 Jul 2001 00:51:05 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25464 for ; Tue, 3 Jul 2001 01:52:04 -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 f637o5T06940; Tue, 3 Jul 2001 09:50:05 +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 JAA06337; Tue, 3 Jul 2001 09:50:04 +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 f637o0O13720; Tue, 3 Jul 2001 09:50:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107030750.f637o0O13720@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Christian Huitema" cc: "Mauro Tortonesi" , "Jim Bound" , itojun@iijlab.net, horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Mon, 02 Jul 2001 09:44:08 PDT. Date: Tue, 03 Jul 2001 09:50:00 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I believe that your comments are based on a host model that does not entirely cover reality. => but this model has many implementations, including routers or multi-homed hosts. An IP address, v4 or v6, designates an interface, not a host. A host can have many IP addresses; it can be multi-homes to several interfaces, and it can be "artificially divided" into several "sub-host", e.g. when the host is the platform for several "sites", each with its own servers for HTTP, FTP, telnet and SMTP. In a multi-homed host, processes must obviously be able to bind to a specific address. For example, if a host supports www.example1.com and www.example2.com, you definitely expect that two different mail server processes will bind to www.example1.com:25 and www.example2.com:25. Another reason to do so may be to insist that a specific service is only reachable through a specific interface. You expect to achieve the address or interface selection by binding the socket to a specific address+port combination, not just a port number. Indeed, you want to be able to support this function for IPv4 and IPv6 addresses. => I agree but problems are not there: - some implementations have a non-BSD SO_REUSEADDR option - some implementations have bad interference between :: and 0.0.0.0 The second point was solved by V6ONLY, the first point is more political but SO_REUSEADDR has a clear behavior for every BSD systems (the documentation is *poor* but to fix it is not the job of the IPv6 WG). In a multi-homed host that uses IPv4 and IPv6, you get quite a number of combinations. I may want a socket to all interfaces and all protocols, to a specific interface and a specific protocol. I could also imagine to "all protocols on a specific interface, but there is a slippery slope here. As we start taking advantage of the large IPv6 address space, we introduce new concepts such as privacy addresses, so we loose the restriction of "one address per interface", and the correspondence between "the IPv4 address of the interface" and "the IPv6 address of the interface" becomes fuzzy. Then, there are interfaces such as 6to4 that are IPv6 only. Pretty soon, you realize that the easiest way to select an interface is to bind to a port on a fully specified address, and that such sockets will by definition be single protocol. => I disagree (about the bind on fully specified addresses). This makes the code more complex (several sockets when one can be enough) and more important this relies on good routines to get and track all addresses. The SIOCGIFCONF is a nightmare, everybody fixed it but in different ways. And to follow emergence of new addresses is even more difficult. What you need is a *standard* way to get the destination address of incoming queries over UDP and to bind a socket per possible address is not a good solution, cf. sendmail, bind, etc. Regards Francis.Dupont@enst-bretagne.fr PS: security filtering is different. The common close TCP connection when one doesn't like the peer is a very bad way to do it but the issue is more in a lack of denial in the application protocol (more polite) or a denial (TCP RST) in the kernel like it is done for TP4. To summarize this issue is simply that "accept" is a wrong name for the accept system call. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 01:06:12 2001 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 f6386CdP024927 for ; Tue, 3 Jul 2001 01:06:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6386CtC024926 for ipng-dist; Tue, 3 Jul 2001 01:06: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63868dP024919 for ; Tue, 3 Jul 2001 01:06: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 BAA28269 for ; Tue, 3 Jul 2001 01:06:12 -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 CAA08223 for ; Tue, 3 Jul 2001 02:06:09 -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 f6385QT33598; Tue, 3 Jul 2001 10:05:26 +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 KAA06641; Tue, 3 Jul 2001 10:05:26 +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 f6385OO13840; Tue, 3 Jul 2001 10:05:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107030805.f6385OO13840@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-reply-to: Your message of Mon, 02 Jul 2001 11:58:17 PDT. <200107021858.LAA02092@feller.mentat.com> Date: Tue, 03 Jul 2001 10:05:24 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Making to these deadlines seems like a bad idea if the consequence will be that we split off content that will then be completely and unnecessarily redesigned thus rendering piles of existing code obsolete. => unfortunately the redesign is *not* unnecessary: the header order specified in RFC 2460 was misinterpreted as mandatory and the advanced API has not the needed flexibility. I believed the flaw was in RFC 2460 but Steve Deering proved it is in the advanced API: (from proceedings of San Diego 49th IETF meeting) > Deering asked why speaker said the destination option was a "nightmare". > Dupont: because that the destination header can occur at different places. > Deering answered that this is the way that IPv6 was designed. Dupont > doesn't think that this freedom is useful. > > Zill: We should design the API around the protocol, not the protocol around > the API. > > Deering: Important to keep flexibility to allow new uses as new applications > are conceived/developed. Deering does not understand the need for this > approach. Dupont want there to be more structure in destination header > placement. > > Bound: Also doesn't think we should change the protocol to match the API. > > [Editor: ran out of time, stopped presentation/discussion, but there didn't > see to be much support for this proposal] The draft has languished for two plus years I think. => this is a real problem we'd like to fix ASAP. Rather than continuing with this meta discussion, why don't we move on to the meat of getting the issues addressed. => I agree we have to put more into the real thing than into the way to do it. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 01:18:28 2001 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 f638ISdP024954 for ; Tue, 3 Jul 2001 01:18:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f638IS8x024953 for ipng-dist; Tue, 3 Jul 2001 01:18:28 -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 f638IOdP024946 for ; Tue, 3 Jul 2001 01:18:24 -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 BAA00157 for ; Tue, 3 Jul 2001 01:18:29 -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 CAA13945 for ; Tue, 3 Jul 2001 02:18:27 -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 f638IOT26196; Tue, 3 Jul 2001 10:18:24 +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 KAA06976; Tue, 3 Jul 2001 10:18:24 +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 f638INO13900; Tue, 3 Jul 2001 10:18:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107030818.f638INO13900@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: complete the advanced API (rfc2292bis) In-reply-to: Your message of Mon, 02 Jul 2001 12:27:17 PDT. <200107021927.MAA02123@feller.mentat.com> Date: Tue, 03 Jul 2001 10:18:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I agree with approach no.2 not only because it is the most expedient but I don't see what other flexibility is required. => explain how you can get the position of an extension header in the current advanced API. There is a setsockopt per header/position defined in RFC 2460 which gives a lot of different setsockopt (not a real problem but this is unnecessarily rigid) and of course gives no way to code something not described in RFC 2460. If we allow the application, via ancillary data, to specify multiple destination options headers and place the fragmentation header (and possible AH and ESP) as the application => how? sees fit within the datagram then the only piece of flexability that is missing is the ability to add as yet unspecified extension header types. => or an extension header forgotten in RFC 2460 like IPCOMP? I believe we need concrete proposals now. The only two proposals I remember are: - manage the whole array of headers (easy to implement but not to use) - manage headers as a stack with placeholders for some headers like fragmentations (the user should not give their contents, only their possible positions). The second seems the best (not third proposal :-) but details have to be written down. This gives enough flexibility too and is closed to the conceptual model of extension headers. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 04:17:13 2001 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 f63BHDdP025257 for ; Tue, 3 Jul 2001 04:17:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63BHDC9025256 for ipng-dist; Tue, 3 Jul 2001 04:17:13 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63BH9dP025249 for ; Tue, 3 Jul 2001 04:17:10 -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 EAA10073 for ; Tue, 3 Jul 2001 04:17:17 -0700 (PDT) Received: from web13702.mail.yahoo.com (web13702.mail.yahoo.com [216.136.175.135]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA00639 for ; Tue, 3 Jul 2001 04:17:17 -0700 (PDT) Message-ID: <20010703111717.95427.qmail@web13702.mail.yahoo.com> Received: from [192.122.173.135] by web13702.mail.yahoo.com; Tue, 03 Jul 2001 04:17:17 PDT Date: Tue, 3 Jul 2001 04:17:17 -0700 (PDT) From: Thiyaga rajan Subject: Unicast - Doubt 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, Rightnow I am studing about IPv6. I would like to know the purpose of introducing unicast in IPv6. What is the significance of unicast ? Please send the detailed answer. Thanks & Regards, Rajan. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 04:20:03 2001 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 f63BK2dP025279 for ; Tue, 3 Jul 2001 04:20:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63BK2BK025278 for ipng-dist; Tue, 3 Jul 2001 04:20:02 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63BJwdP025271 for ; Tue, 3 Jul 2001 04:19:58 -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 EAA09374 for ; Tue, 3 Jul 2001 04:20:05 -0700 (PDT) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA15437 for ; Tue, 3 Jul 2001 05:21:07 -0600 (MDT) Received: (qmail 30609 invoked from network); 3 Jul 2001 11:20:04 -0000 Received: from ninelives.chek.com (208.197.227.14) by mailrelay1.chek.com with SMTP; 3 Jul 2001 11:20:04 -0000 Received: (qmail 13528 invoked by uid 99); 3 Jul 2001 11:16:23 -0000 Date: 3 Jul 2001 11:16:23 -0000 Message-ID: <20010703111623.13527.qmail@ninelives.chek.com> From: "Emanuel Moreira" To: ipng@sunroof.eng.sun.com, useripv6@av.it.pt, msripv6-users@list.research.microsoft.com X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: Group Membership Report Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can anyone tell me where can I find something about the "Group Membership Report" message? Thanks Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 04:40:00 2001 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 f63Be0dP025376 for ; Tue, 3 Jul 2001 04:40:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63Be0cY025375 for ipng-dist; Tue, 3 Jul 2001 04:40:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63BdudP025368 for ; Tue, 3 Jul 2001 04:39: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 EAA10436 for ; Tue, 3 Jul 2001 04:40:04 -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 EAA19483 for ; Tue, 3 Jul 2001 04:40:03 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f63BduZ23999; Tue, 3 Jul 2001 14:39:56 +0300 Date: Tue, 3 Jul 2001 14:39:56 +0300 (EEST) From: Pekka Savola To: Thiyaga rajan cc: Subject: Re: Unicast - Doubt In-Reply-To: <20010703111717.95427.qmail@web13702.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 On Tue, 3 Jul 2001, Thiyaga rajan wrote: > Rightnow I am studing about IPv6. I would like to > know the purpose of introducing unicast in IPv6. > > What is the significance of unicast ? > Please send the detailed answer. ... right. You probably mean Anycast. People are usually supposed to do their homework themselves. Anyway, I'd start by checking out: http://www.ietf.org/internet-drafts/draft-lutchann-ipv6-intro-00.txt In short, anycast can be used to send to the nearest destination. It's described in more length in other documents. -- 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 Jul 3 04:57:04 2001 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 f63Bv3dP025412 for ; Tue, 3 Jul 2001 04:57:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63Bv3IK025411 for ipng-dist; Tue, 3 Jul 2001 04:57:03 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63Bv0dP025404 for ; Tue, 3 Jul 2001 04:57:00 -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 EAA11428 for ; Tue, 3 Jul 2001 04:57:08 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17130 for ; Tue, 3 Jul 2001 05:57:06 -0600 (MDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.11.0/jtpda-5.3.2+victor) with ESMTP id f63BUj830143 ; Tue, 3 Jul 2001 13:30:45 +0200 X-pt: isis.lip6.fr Received: from lip6.fr (otos.lip6.fr [132.227.61.47]) by tibre.lip6.fr (8.11.3/8.11.3) with ESMTP id f63BUCs17031; Tue, 3 Jul 2001 13:30:12 +0200 (CEST) Message-ID: <3B41ACE4.28A5F79A@lip6.fr> Date: Tue, 03 Jul 2001 13:30:44 +0200 From: Rolland Vida Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: Emanuel Moreira CC: ipng@sunroof.eng.sun.com, useripv6@av.it.pt, msripv6-users@list.research.microsoft.com Subject: Re: Group Membership Report References: <20010703111623.13527.qmail@ninelives.chek.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is part of the IGMP protocol. You can find details in: RFC 2236 (IGMPv2) - http://sunsite.cnlab-switch.ch/ftp/doc/standard/rfc/22xx/2236 Draft IGMPv3 - http://sunsite.cnlab-switch.ch/ftp/mirror/internet-drafts/draft-ietf-idmr-igmp-v3-07.txt In the IPv6 version of IGMP, called the MLD protocol, the message is called Multicast Listener Report message. Cheers, Rolland Vida Emanuel Moreira a écrit : > Can anyone tell me where can I find something about the "Group Membership Report" message? > Thanks > Emanuel Moreira > > _____________________________________________________________ > O e-mail preferido dos portugueses http://www.portugalmail.pt > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ______________________________________________________ Make everything as simple as possible, but not simpler - Albert Einstein Rolland VIDA - Ph.D. student Universite Pierre et Marie Curie Laboratoire LIP6-CNRS, 8, rue du Capitaine Scott Tel: +33 (0) 1 44 27 71 26 Fax: +33 (0) 1 44 27 74 95 E-mail: Rolland.Vida@lip6.fr Web: http://www-rp.lip6.fr/~vida ______________________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 04:57:41 2001 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 f63BvedP025429 for ; Tue, 3 Jul 2001 04:57:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63BvexO025428 for ipng-dist; Tue, 3 Jul 2001 04:57: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63BvadP025414 for ; Tue, 3 Jul 2001 04:57:36 -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 EAA12012 for ; Tue, 3 Jul 2001 04:57:44 -0700 (PDT) Received: from web13701.mail.yahoo.com (web13701.mail.yahoo.com [216.136.175.134]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA23746 for ; Tue, 3 Jul 2001 04:57:44 -0700 (PDT) Message-ID: <20010703115744.71989.qmail@web13701.mail.yahoo.com> Received: from [192.122.173.135] by web13701.mail.yahoo.com; Tue, 03 Jul 2001 04:57:44 PDT Date: Tue, 3 Jul 2001 04:57:44 -0700 (PDT) From: Thiyaga rajan Subject: Re: Unicast - Doubt To: pekkas@netcore.fi Cc: IPng MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka you are right Instead of Anycast I have written as unicast. Tanks for correcting me and sorry for the inconvenience. Regards, Thiyagu. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 05:20:27 2001 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 f63CKQdP025490 for ; Tue, 3 Jul 2001 05:20:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63CKQrN025489 for ipng-dist; Tue, 3 Jul 2001 05: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63CKMdP025482 for ; Tue, 3 Jul 2001 05:20:23 -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 FAA26317 for ; Tue, 3 Jul 2001 05:20:26 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06723 for ; Tue, 3 Jul 2001 06:21:27 -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 f63CKAT02966; Tue, 3 Jul 2001 14:20:10 +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 OAA10599; Tue, 3 Jul 2001 14:20:10 +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 f63CK4O14505; Tue, 3 Jul 2001 14:20:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107031220.f63CK4O14505@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tim Hartrick cc: ipng@sunroof.eng.sun.com, msa@burp.tkv.asdf.org Subject: Re: complete the advanced API (rfc2292bis) In-reply-to: Your message of Mon, 02 Jul 2001 15:05:05 PDT. <200107022205.PAA02212@feller.mentat.com> Date: Tue, 03 Jul 2001 14:20:04 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > To me it seems to be more work, if you have to define, implement and > document every possible extension header separately in the API (as 2 > will require). This would be true if it were possible to add a new extension header type without modifying the kernel. It isn't really possible in the implementations I have seen => I disagree: I use a table for header management with some free slots so it is possible to add an option or an extension header without modifying the current kernel, you just need to add some code (eventually) via a dynamic kernel module. So I can't agree with your conclusions... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 05:36:08 2001 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 f63Ca8dP025518 for ; Tue, 3 Jul 2001 05:36:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63Ca7lf025517 for ipng-dist; Tue, 3 Jul 2001 05:36: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63Ca4dP025510 for ; Tue, 3 Jul 2001 05:36:04 -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 FAA14678 for ; Tue, 3 Jul 2001 05:36:12 -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 FAA27228 for ; Tue, 3 Jul 2001 05:36:11 -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 f63CZVT27409; Tue, 3 Jul 2001 14:35:31 +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 OAA10909; Tue, 3 Jul 2001 14:35:30 +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 f63CZSO14576; Tue, 3 Jul 2001 14:35:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200107031235.f63CZSO14576@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: Markku Savela , tim@mentat.com, ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-reply-to: Your message of Tue, 03 Jul 2001 07:36:24 +0900. <20010702223624.58B477BC@starfruit.itojun.org> Date: Tue, 03 Jul 2001 14:35:28 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm finding hard time trying to find a good balance between BPF, and basic API. advanced API (ancillary data) should fit somewhere in between. RFC2292 had a good balance by limiting the ordering of headers to what is documented in RFC2460, => this is a concern because RFC 2460 doesn't document all useful cases (IPCOMP was forgotten, MIP6 needs destination option at a new position, ...). and limiting itself from handling non-IPv6 headers like AH/ESP (i believe users do not want to manipulate AH/ESP from normal socket API. also, how do you plan to handle IPsec-tunnelled packets?). => manipulation of AH/ESP themselves no, but manipulation of the position yes. by removing more limitations, we get closer and closer to BPF... i guess, if we follow the spirit of RFC2292, we first need to evaluate RFC2460, to see if we need to remove some of suggested header ordering constraints - MIP6 seem to conflict with it, with some reasons (i have trouble chasing recent MIP6 discussions, so i may be wrong). => MIP6 conflicts with it, I tried at the San Diego IETF to solve it: - me: 3 different documented positions (2 in RFC, 1 in MIP6 I-D) for destination option headers are a real mess. Give different numbers (i.e. make different headers), ... - Steve Deering (chair): don't change RFC 2460, it is near perfect (:-). - me: how to solve the conflict? - Steve: an application can decide to use an order not documented in RFC 2460 (i.e. the ordering is recommended, not mandatory, and can be updated (change the order, add new headers) if needed). - me: but how to code it, the (advanced) API doesn't give the needed flexibility. - Steve: fix the API! - Eric Nordmark (from another room): heu... What's happened? then, we design 2292bis to follow the new header ordering constraint. => I agree: with a clear description of RFC 2460 flexibility we'll know what we need for the API. just a meta-thought. => can you summarize what happened at San Diego (I am likely a bit biased)? 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 Tue Jul 3 06:44:19 2001 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 f63DiJdP025691 for ; Tue, 3 Jul 2001 06:44:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63DiINM025690 for ipng-dist; Tue, 3 Jul 2001 06:44:18 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63DiFdP025683 for ; Tue, 3 Jul 2001 06:44:15 -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 GAA20767 for ; Tue, 3 Jul 2001 06:44:24 -0700 (PDT) Received: from camelia.wanadoo.fr (smtp-rt-10.wanadoo.fr [193.252.19.59]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24647 for ; Tue, 3 Jul 2001 06:44:23 -0700 (PDT) Received: from antholoma.wanadoo.fr (193.252.19.153) by camelia.wanadoo.fr; 3 Jul 2001 15:44:18 +0200 Received: from remi (193.248.209.96) by antholoma.wanadoo.fr; 3 Jul 2001 15:44:08 +0200 Message-ID: <00fd01c103c6$cb12cf20$60d1f8c1@remi> From: "Remi" To: Subject: IPv6 Event Date: Tue, 3 Jul 2001 15:48:07 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FA_01C103D7.8DEC2540" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_00FA_01C103D7.8DEC2540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 "Deploying IPv6 Networks" international conference, Paris, November = 20-23rd. A call for proposals is on-line at: http://www.upperside.fr/ipv6/deployipv6intro.htm ------=_NextPart_000_00FA_01C103D7.8DEC2540 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
"Deploying IPv6 Networks" international conference, = Paris,=20 November 20-23rd.
A call for proposals is on-line at:
http://www.uppe= rside.fr/ipv6/deployipv6intro.htm
------=_NextPart_000_00FA_01C103D7.8DEC2540-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 10:15:08 2001 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 f63HF8dP025902 for ; Tue, 3 Jul 2001 10:15:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63HF7V7025901 for ipng-dist; Tue, 3 Jul 2001 10:15: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63HF3dP025894 for ; Tue, 3 Jul 2001 10:15: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 KAA14710 for ; Tue, 3 Jul 2001 10:15:12 -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 KAA19112 for ; Tue, 3 Jul 2001 10:15:06 -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 CAA27579 for ; Wed, 4 Jul 2001 02:16:26 +0900 (JST) Date: Wed, 04 Jul 2001 02:14:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <568.994132369@brandenburg.cs.mu.OZ.AU> References: <200107020811.f628BoO10141@givry.rennes.enst-bretagne.fr> <568.994132369@brandenburg.cs.mu.OZ.AU> 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 Tue, 03 Jul 2001 10:52:49 +0700, >>>>> Robert Elz said: > So, I'd prefer to complete & document the receive case, and just leave the > send case for a later doc to define. That is, not have any method at all > defined for inserting headers in the new doc for now (implementors can keep > implementing the current spec). Hmm, I'm still not convinced the idea of the full flexibility, but at least we need to separate the header issue from the rest of the API spec for now. As for the I-D cutoff issue, I personally do not think the deadline itself is so important (because I don't think we can reach a full consensus on the API spec by the meeting even without the header issue.) However, it would be a good excuse to accelerate the job, so I'd like to propose to separate the header issue from the spec, concentrate the rest of the issues, and try to get the next revision published by the cut-off date. (sorry for continuing the meta-discussion. I'll then go to the technical ones.) 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 Jul 3 10:35:50 2001 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 f63HZodP025937 for ; Tue, 3 Jul 2001 10:35:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63HZnIm025936 for ipng-dist; Tue, 3 Jul 2001 10:35: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63HZkdP025929 for ; Tue, 3 Jul 2001 10:35:46 -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 KAA24684 for ; Tue, 3 Jul 2001 10:35:55 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA26992 for ; Tue, 3 Jul 2001 10:35:55 -0700 (PDT) Received: from 157.54.1.52 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 03 Jul 2001 10:35:54 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 3 Jul 2001 10:35:33 -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); Tue, 3 Jul 2001 10:35:33 -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); Tue, 3 Jul 2001 10:34:46 -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: test Date: Tue, 3 Jul 2001 10:34:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: test thread-index: AcED5GDD7lPrXsQvQQGQ1wv/xM5+SAAAh4Hg From: "Christian Huitema" To: X-OriginalArrivalTime: 03 Jul 2001 17:34:47.0104 (UTC) FILETIME=[7443B400:01C103E6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f63HZkdP025930 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 12:17:53 2001 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 f63JHqdP026267 for ; Tue, 3 Jul 2001 12:17:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63JHqab026266 for ipng-dist; Tue, 3 Jul 2001 12:17: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63JHmdP026259 for ; Tue, 3 Jul 2001 12:17: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 MAA06984 for ; Tue, 3 Jul 2001 12:17:56 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15272 for ; Tue, 3 Jul 2001 13:18:55 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA05858; Tue, 3 Jul 2001 12:18:19 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA19735; Tue, 3 Jul 2001 12:18:19 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA02712; Tue, 3 Jul 2001 12:20:06 -0700 (PDT) Date: Tue, 3 Jul 2001 12:20:06 -0700 (PDT) From: Tim Hartrick Message-Id: <200107031920.MAA02712@feller.mentat.com> To: Francis.Dupont@enst-bretagne.fr Subject: Re: complete the advanced API (rfc2292bis) Cc: ipng@sunroof.eng.sun.com, jinmei@isl.rdc.toshiba.co.jp X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => explain how you can get the position of an extension header in > the current advanced API. There is a setsockopt per header/position > defined in RFC 2460 which gives a lot of different setsockopt (not > a real problem but this is unnecessarily rigid) and of course gives > no way to code something not described in RFC 2460. > The sticky options are quite restrictive at the moment. Making them more flexible is a little difficult. Ancillary data can be made more flexible fairly easily. > If we allow the application, > via ancillary data, to specify multiple destination options headers and > place the fragmentation header (and possible AH and ESP) as the application > > => how? > Please see the archives. We began defining position markers six months ago and folks lost interest. > sees fit within the datagram then the only piece of flexability that is > missing is the ability to add as yet unspecified extension header types. > > => or an extension header forgotten in RFC 2460 like IPCOMP? > I believe that all that is required is the ability to designate where the fragmentable part the the datagram begins and where the "terminal" header should be placed. This would accomodate placement of ESP, AH, IPCOMP or any other terminal header type. > - manage headers as a stack with placeholders for some headers like > fragmentations (the user should not give their contents, only their > possible positions). > The second seems the best (not third proposal :-) but details have to be > written down. This gives enough flexibility too and is closed to the > conceptual model of extension headers. > This can be done within the existing model. So why is a complete redesign essential except as a full employment program for kernel programmers? Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 13:35:37 2001 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 f63KZadP026303 for ; Tue, 3 Jul 2001 13:35:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f63KZa6P026302 for ipng-dist; Tue, 3 Jul 2001 13:35: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f63KZWdP026295 for ; Tue, 3 Jul 2001 13:35:32 -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 NAA13178 for ; Tue, 3 Jul 2001 13:35:40 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23214 for ; Tue, 3 Jul 2001 13:35:40 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA06202; Tue, 3 Jul 2001 13:31:55 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id NAA22001; Tue, 3 Jul 2001 13:31:55 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id NAA02728; Tue, 3 Jul 2001 13:33:43 -0700 (PDT) Date: Tue, 3 Jul 2001 13:33:43 -0700 (PDT) From: Tim Hartrick Message-Id: <200107032033.NAA02728@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp, kre@munnari.oz.au Subject: Re: complete the advanced API (rfc2292bis) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > So, I'd prefer to complete & document the receive case, and just leave the > send case for a later doc to define. That is, not have any method at all > defined for inserting headers in the new doc for now (implementors can keep > implementing the current spec). > Only someone that has no running code for the existing API or customers using it could reach this conclusion. Throwing out half of the existing mechanism is worse than throwing out the entire thing. Real implementors have implemented the existing mechanism and real customers are using it. This is not an academic discussion. What we have here in this discussion is a clear indication that the IETF shouldn't be doing APIs. People are free to propose and argue for courses of action for which they won't have to bare any of the cost. I would wish, but have little hope, that this document be tranferred to POSIX or X/Open for completion immediately. Given that such good fortune is not likely. I would argue that the existing document should be finished as is and published as an RFC. If after that a group of contributors wants to create a new extension header API that is completely distinct from the existing mechanism and DOES NOT obsolete it that would be great. In this way we have at least a hope that implementors and customers that have a investment in the existing mechanism don't get orphaned but this in- sane process. This document has been in its current form for something on order of three years without making forward progress. Implementors have had no choice but to write code to this API and customers have had little choice but to use it. Making substantial changes to this API at this point is just plain wrong. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 21:47:12 2001 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 f644lBdP026731 for ; Tue, 3 Jul 2001 21:47:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f644lBP1026730 for ipng-dist; Tue, 3 Jul 2001 21:47: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f644l7dP026723 for ; Tue, 3 Jul 2001 21:47: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 VAA08613 for ; Tue, 3 Jul 2001 21:47: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 WAA17997 for ; Tue, 3 Jul 2001 22:48: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 VAA19417; Tue, 3 Jul 2001 21:47:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f644lGR22706; Tue, 3 Jul 2001 21:47:16 -0700 X-mProtect: Tue, 3 Jul 2001 21:47:16 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.44.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd3rMkFv; Tue, 03 Jul 2001 21:47:14 PDT Message-Id: <4.3.2.7.2.20010703213235.0214eda0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Jul 2001 21:46:38 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Update to IPv6 web pages Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I installed an update to the ipv6 web pages at http://playground.sun.com/ipv6 It should be available for both IPv4 and IPv6 access. Changes include new implementations, updated specifications, and some minor cleanup. Changes and corrections to me. 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 Jul 3 22:19:32 2001 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 f645JWdP026760 for ; Tue, 3 Jul 2001 22:19:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f645JWlL026759 for ipng-dist; Tue, 3 Jul 2001 22:19:32 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f645JSdP026752 for ; Tue, 3 Jul 2001 22:19:28 -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 WAA22426 for ; Tue, 3 Jul 2001 22:19:38 -0700 (PDT) Received: from pan.ch.intel.com (chfdns01.ch.intel.com [143.182.246.24]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA27201 for ; Tue, 3 Jul 2001 22:19:38 -0700 (PDT) Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.233.18]) by pan.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id FAA07375 for ; Wed, 4 Jul 2001 05:19:31 GMT Received: from pgsmsx17.PNG.INTEL.COM ([172.30.233.17]) by pgsmsxvs01.png.intel.com (NAVIEG 2.1 bld 68) with SMTP id M2001070413193026552 for ; Wed, 04 Jul 2001 13:19:30 +0800 Received: by pgsmsx17.png.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jul 2001 13:19:30 +0800 Message-ID: <92AC01AFC296D411AC6800A0C9E00CF4033A9EF2@pgsmsx35.png.intel.com> From: "Karuppiah, Ettikan Kandasamy" To: ipng@sunroof.eng.sun.com Subject: IPv6 hierarchical routing: RFC 2374 Date: Wed, 4 Jul 2001 13:19:29 +0800 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, Referring to the above RFC(2374); The aim of Aggregatable addressing is to simplify routing compared to current CIDR, at each level. Does it dictates, that routers at each level will have entries only for the specified prefixes? For example, long-haul providers backbone router has entries of only /16 prefix route entries and NLA1 router's will have /48 prefix entry, etc. Or mix of different prefix sizes are allowed to be added at the routing table regardless of it's level! What about 'host-route' advertisement? thank you. -ettikan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 3 22:56:17 2001 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 f645uHdP026805 for ; Tue, 3 Jul 2001 22:56:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f645uHbX026804 for ipng-dist; Tue, 3 Jul 2001 22: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f645uDdP026797 for ; Tue, 3 Jul 2001 22:56:13 -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 WAA24488 for ; Tue, 3 Jul 2001 22:56:21 -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 WAA00577 for ; Tue, 3 Jul 2001 22:56:20 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C9F844B20; Wed, 4 Jul 2001 14:56:15 +0900 (JST) To: "Karuppiah, Ettikan Kandasamy" Cc: ipng@sunroof.eng.sun.com In-reply-to: ettikan.kandasamy.karuppiah's message of Wed, 04 Jul 2001 13:19:29 +0800. <92AC01AFC296D411AC6800A0C9E00CF4033A9EF2@pgsmsx35.png.intel.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: IPv6 hierarchical routing: RFC 2374 From: itojun@iijlab.net Date: Wed, 04 Jul 2001 14:56:15 +0900 Message-ID: <10684.994226175@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Referring to the above RFC(2374); you may want to check RFC2772 for current 6bone operation guidelines. >What about 'host-route' advertisement? are you suggesting to have 2^128 routing entries worldwide? 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 Jul 3 23:00:05 2001 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 f64605dP026825 for ; Tue, 3 Jul 2001 23:00:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f64605XI026824 for ipng-dist; Tue, 3 Jul 2001 23:00: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f64601dP026817 for ; Tue, 3 Jul 2001 23:00: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 XAA20900 for ; Tue, 3 Jul 2001 23:00: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 XAA01368 for ; Tue, 3 Jul 2001 23:00:09 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f645xuM30070; Wed, 4 Jul 2001 08:59:56 +0300 Date: Wed, 4 Jul 2001 08:59:56 +0300 (EEST) From: Pekka Savola To: "Karuppiah, Ettikan Kandasamy" cc: Subject: Re: IPv6 hierarchical routing: RFC 2374 In-Reply-To: <92AC01AFC296D411AC6800A0C9E00CF4033A9EF2@pgsmsx35.png.intel.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, 4 Jul 2001, Karuppiah, Ettikan Kandasamy wrote: > Hi, > Referring to the above RFC(2374); > The aim of Aggregatable addressing is to simplify routing compared to > current CIDR, at each level. Does it dictates, that routers at each level > will have entries only for the specified prefixes? For example, long-haul > providers backbone router has entries of only /16 prefix route entries and > NLA1 router's will have /48 prefix entry, etc. Or mix of different prefix > sizes are allowed to be added at the routing table regardless of it's level! > > What about 'host-route' advertisement? The prefixes can be of variable length, at least internally. I'd filter out all routes more specific than /35. -- 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 Jul 4 00:02:29 2001 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 f6472SdP026863 for ; Wed, 4 Jul 2001 00:02:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6472SNq026862 for ipng-dist; Wed, 4 Jul 2001 00:02:28 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6472OdP026855 for ; Wed, 4 Jul 2001 00:02:24 -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 AAA28265 for ; Wed, 4 Jul 2001 00:02:33 -0700 (PDT) Received: from pan.ch.intel.com (chfdns01.ch.intel.com [143.182.246.24]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25342 for ; Wed, 4 Jul 2001 01:03:35 -0600 (MDT) Received: from pgsmsxvs01.png.intel.com (pgsmsxvs01.png.intel.com [172.30.233.18]) by pan.ch.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id HAA07319 for ; Wed, 4 Jul 2001 07:02:30 GMT Received: from pgsmsx17.PNG.INTEL.COM ([172.30.233.17]) by pgsmsxvs01.png.intel.com (NAVIEG 2.1 bld 68) with SMTP id M2001070415022518828 ; Wed, 04 Jul 2001 15:02:25 +0800 Received: by pgsmsx17.png.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jul 2001 15:02:26 +0800 Message-ID: <92AC01AFC296D411AC6800A0C9E00CF4033A9EF6@pgsmsx35.png.intel.com> From: "Karuppiah, Ettikan Kandasamy" To: "'itojun@iijlab.net'" , "Karuppiah, Ettikan Kandasamy" Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 hierarchical routing: RFC 2374 Date: Wed, 4 Jul 2001 15:02:24 +0800 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 off course not. At least we 'should' say (make it a rule , if applicable) that this should not be supported at certain level of hierarchies, since there is no documents say's it not permitted currently. (correct me if I'm wrong) -ettikan > are you suggesting to have 2^128 routing entries worldwide? > > 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 Jul 4 00:30:35 2001 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 f647UZdP026981 for ; Wed, 4 Jul 2001 00:30:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f647UZab026980 for ipng-dist; Wed, 4 Jul 2001 00:30: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f647UUdP026973 for ; Wed, 4 Jul 2001 00:30: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 AAA00354 for ; Wed, 4 Jul 2001 00:30:39 -0700 (PDT) From: john.loughney@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 BAA04129 for ; Wed, 4 Jul 2001 01:31:40 -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 f647Us325790 for ; Wed, 4 Jul 2001 10:30:54 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 4 Jul 2001 10:30:37 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 4 Jul 2001 10:30:37 +0300 Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B268@eseis04nok> To: ipng@sunroof.eng.sun.com Subject: FW: I-D ACTION:draft-stewart-tsvwg-sctpipv6-00.txt Date: Wed, 4 Jul 2001 10:30:34 +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 all, For those of you not aware, there is a new transport level protocol, SCTP. This protocol supports transport level multihoming, by allowing endpoints to exchanging IP addresses in the association intitialization messages. This can cause some problems by allowing IP addresses to escape their scope, thus introducing the possibilities for some black holes. I'm not sure if Randy Stewart is subscribed or not (primary author of SCTP), but if he isn't, I can field some questions about SCTP (if they aren't too tough!) ... Just a small deployment note - SCTP should start seeing some deployment later this year in 3G networks, as a signaling bearer for some radio access protocols, so it would be a good idea to try make sure that this issue is nailed down. thanks, John > Title : IPv6 addressing and Stream Control > Transmission Protocol > Author(s) : R. Stewart, S. Deering > Filename : draft-stewart-tsvwg-sctpipv6-00.txt > Pages : > Date : 02-Jul-01 > > Stream Control Transmission Protocol [RFC2960] provides transparent > multi-homing to its upper layer users. This multi-homing is > accomplished through the passing of address parameters in the > initial setup message used by SCTP. In an IPv4 network all addresses > are passed with no consideration for their scope and routeablility. > In a IPv6 network special considerations MUST be made to properly > bring up associations between SCTP endpoints that have IPv6 > [RFC2460] addresses bound within their association. This document > defines those considerations and enumerates general rules > that an SCTP endpoint MUST use in formulating both the INIT and > INIT-ACK chunks. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-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 Wed Jul 4 00:43:26 2001 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 f647hQdP027048 for ; Wed, 4 Jul 2001 00:43:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f647hQRq027047 for ipng-dist; Wed, 4 Jul 2001 00:43:26 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f647hMdP027040 for ; Wed, 4 Jul 2001 00:43:22 -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 AAA21312 for ; Wed, 4 Jul 2001 00:43:32 -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 AAA09957 for ; Wed, 4 Jul 2001 00:43:29 -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 f647h7x02590; Wed, 4 Jul 2001 14:43:08 +0700 (ICT) From: Robert Elz To: Tim Hartrick cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <200107031920.MAA02712@feller.mentat.com> References: <200107031920.MAA02712@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jul 2001 14:43:07 +0700 Message-ID: <2588.994232587@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 3 Jul 2001 12:20:06 -0700 (PDT) From: Tim Hartrick Message-ID: <200107031920.MAA02712@feller.mentat.com> | I believe that all that is required is the ability to designate where the | fragmentable part the the datagram begins Hang on a minute ... you think there is a "fragmentable part" and another part? Just one? Why? IPv6 has fixed vast numbers of limitations in IPv4, we should not be re-imposing IPv4 back on it again, just because no-one has yet noticed the beauty and flexibility o what IPv6 actually allows. Eg; if I'm stuck at the end of a link with a low MTU (a gif tunnel someone has configured with an MTU of 1280 - just enough to survive with IPv6 or something like that), which then terminates at a more reasonable link (GigaE or FDDI or something) with a 4K or bigger MTU, and that gets most of the way to the destination, where the final hop is a HIPPI (or whatever that thing is for which jumbograms were invented, which has a very high per packet cost), then I might be tempted to do ... IPv6 FH RH FH RH That is, I have a 32K (or whatever) packet, which I have split into 4K fragments, and then each of those fragments has been split into 1280 fragments for the first hop. When the router gets my tiny fragments, it reassembles them (it has to, it can't progress beyond the frag header until all the frags are ressembled, and because of the IPv6 design of having the "next hop" address in the IPv6 header, it knows that all the frags will arrive). It builds a 4K packet out of that. That Frag header is then deleted (it doesn't actually matter if it is retained, it now shows one frag, ie: offset==0, MF==0). Then the routing header is examined, and the router adjusts the IPv6 header, and forwards the packet to the next node from it - which is the one which has the HIPPI link. This happens to each of the 8 (or 9 or whatever it is) 4K fragments of the original big packet. When the packets arrive at the HIPPI interface the first routing header is found to be exhausted, and and so the fragments of the 2nd fragmentation header are collected. Once that has been done, the 2nd routing header is uncovered, and the (now) 32K packet is forwarded in one go to the destination over the very high MTU link at the end. I know this is something of a far fetched example - but there are all kinds of potentials in the IPv6 architecture just waiting to be discovered by someone with a need for them - all that's required then is for the implementations to stay out of the way - allow the headers to be built the way that the source node builds them, and then process them in a strictly left to right order at the recipient, doing whatever is needed for each header before going on to the next. In a later message you said ... | I would argue that the existing document should be finished as is and | published as an RFC. If after that a group of contributors wants to | create a new extension header API that is completely distinct from the | existing mechanism and DOES NOT obsolete it that would be great. I don't mind that as an approach - except there's no need for the existing mechanisms to be retained. That they're obsoleted from the doc doesn't mean they will be yanked from implementations. Implementations carry around baggage from obsoleted interface all the time, there's nothing new here. Whether the old interfaces is obsoleted or not should depend upon whether there's still a good reason for requiring it, after the new one is defined. Obviously, until the new one is defined, we won't know that. Then, when that is complete, and some of the existing interfaces are (perhaps) obsoleted, the stack implementors will look and see how much demand there is for them to retain the old interface - if it is used by lots of code in the wild, then it will be retained. If there's one, or even no, applications using the thing, it is almost certainly simpler all around to fix the application to use the new interface. 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 Jul 4 02:44:28 2001 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 f649iSdP027217 for ; Wed, 4 Jul 2001 02:44:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f649iStp027216 for ipng-dist; Wed, 4 Jul 2001 02:44:28 -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 f649iOdP027209 for ; Wed, 4 Jul 2001 02:44:24 -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 CAA09123 for ; Wed, 4 Jul 2001 02:44:34 -0700 (PDT) Received: from raksha.wipro.com ([203.197.141.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05760 for ; Wed, 4 Jul 2001 03:44:25 -0600 (MDT) Received: from cdc2vwalltest (cdc2vwall.wipro.com [10.145.0.23]) by raksha.wipro.com (8.9.3/8.9.3) with SMTP id PAA00832 for ; Wed, 4 Jul 2001 15:14:56 +0530 (IST) Received: from wipuni32 ([10.145.3.85]) by arabhi.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GFY0F000.588 for ; Wed, 4 Jul 2001 15:15:00 +0530 Message-ID: <021201c1046d$431e7360$5503910a@wipro.com> From: "Avinash natarajan" To: References: <200107031920.MAA02712@feller.mentat.com> <2588.994232587@brandenburg.cs.mu.OZ.AU> Subject: rgding UDP checksum... Date: Wed, 4 Jul 2001 15:09:46 +0530 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_020F_01C1049B.5CB51DA0" ------=_NextPart_000_020F_01C1049B.5CB51DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi... siit is required to keep a count of the number of udp checksums it = generated(on receving udp ipv4 pkts with checksum zero)... cud anybody tell it's significance?? sorry if it is elementary... thanx.. rgds avinash ------=_NextPart_000_020F_01C1049B.5CB51DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi...
    siit is required to = keep a count=20 of the number of udp checksums it generated(on receving udp ipv4 pkts = with=20 checksum zero)...
cud anybody tell it's = significance??
sorry if it is = elementary...
thanx..
rgds
avinash
------=_NextPart_000_020F_01C1049B.5CB51DA0-- --------------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 Jul 4 06:56:23 2001 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 f64DuNdP027462 for ; Wed, 4 Jul 2001 06:56:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f64DuN6s027461 for ipng-dist; Wed, 4 Jul 2001 06: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f64DuIdP027454 for ; Wed, 4 Jul 2001 06:56: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 GAA18410 for ; Wed, 4 Jul 2001 06:56:27 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10257 for ; Wed, 4 Jul 2001 07:57:30 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f64DuON17912 for ; Wed, 4 Jul 2001 15:56:24 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jul 04 15:56:23 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jul 2001 15:56:21 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AB0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: ipng@sunroof.eng.sun.com Subject: Proxy announcement ! Date: Wed, 4 Jul 2001 15:56:16 +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 All, A new draft on IPv6 Cellular hosts requirements was submitted today. Until it's announced, you can view it here: http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt I'm doing this for Jari (one of the author) as he's away. Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 00:58:44 2001 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 f657widP028030 for ; Thu, 5 Jul 2001 00:58:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f657whTD028029 for ipng-dist; Thu, 5 Jul 2001 00:58:43 -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 f657wddP028022 for ; Thu, 5 Jul 2001 00:58:39 -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 AAA14419 for ; Thu, 5 Jul 2001 00:58:49 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08219 for ; Thu, 5 Jul 2001 01:59:51 -0600 (MDT) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f657uUs18162; Thu, 5 Jul 2001 09:56:30 +0200 (MEST) Message-ID: <3B441E21.F2069983@inrialpes.fr> Date: Thu, 05 Jul 2001 09:58:25 +0200 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: ipng@sunroof.eng.sun.com Subject: Re: Proxy announcement ! References: <034BEFD03799D411A59F00508BDF754603008AB0@esealnt448.al.sw.ericsson.se> Content-Type: multipart/alternative; boundary="------------EB4845C5260DA06A7C0F6C34" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------EB4845C5260DA06A7C0F6C34 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello , This is a very interesting draft but I would suggest to change the title. Something like "Minimum IPv6 Functionality for a 3GPP Host" would be more accurate... Some of the sections are very specific to the 3GPP architecture and can not be generalized to Cellular hosts (that could used IEEE802.11, Bluetooth, blabla types of networks..) Regards, Claude. "Hesham Soliman (ERA)" wrote: > All, > > A new draft on IPv6 Cellular hosts requirements was submitted today. > Until it's announced, you can view it here: > > http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt > > I'm doing this for Jari (one of the author) as he's away. > > Cheers, > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------EB4845C5260DA06A7C0F6C34 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello ,

This is a very interesting draft but I would suggest to change the title.
Something like "Minimum IPv6 Functionality for a 3GPP Host" would
be more accurate...
Some of the sections are very specific to the 3GPP architecture and can not
be generalized to Cellular hosts (that could used IEEE802.11, Bluetooth, blabla types
of networks..)

Regards,
Claude.

"Hesham Soliman (ERA)" wrote:

All,

A new draft on IPv6 Cellular hosts requirements was submitted today.
Until it's announced, you can view it here:

http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt

I'm doing this for Jari (one of the author) as he's away.

Cheers,
Hesham
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                     http://playground.sun.com/ipng
FTP archive:                     ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------EB4845C5260DA06A7C0F6C34-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 01:42:50 2001 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 f658godP028094 for ; Thu, 5 Jul 2001 01:42:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f658goKC028093 for ipng-dist; Thu, 5 Jul 2001 01:42:50 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f658gidP028086 for ; Thu, 5 Jul 2001 01:42:45 -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 BAA11650 for ; Thu, 5 Jul 2001 01:42:53 -0700 (PDT) Received: from starfruit.itojun.org (kame202.kame.net [203.178.141.202]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20611 for ; Thu, 5 Jul 2001 01:42:50 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 8962B7BB; Thu, 5 Jul 2001 17:41:07 +0900 (JST) To: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com In-reply-to: claude.castelluccia's message of Thu, 05 Jul 2001 09:58:25 +0200. <3B441E21.F2069983@inrialpes.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: Proxy announcement ! From: Jun-ichiro itojun Hagino Date: Thu, 05 Jul 2001 17:41:07 +0900 Message-Id: <20010705084107.8962B7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> A new draft on IPv6 Cellular hosts requirements was submitted today. >> Until it's announced, you can view it here: >> http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt >> I'm doing this for Jari (one of the author) as he's away. here are a couple of comments. itojun 2.1 RFC1981 - Path MTU Discovery for IP Version 6 > If Path MTU Discovery is not implemented, then the uplink packet > size MUST be limited to 1280 octets (standard limit in [IPv6]). > However, the cellular host MUST be able to receive packets with size > up to the link MTU. The text (3rd and 4th line) is unclear (is it after the reassembly or before? or am I badly confused?), and may conflict with RFC2460 depending on the link MTU for the cellular host. ??? RFC2460 page 25 > A node must be able to accept a fragmented packet that, after > reassembly, is as large as 1500 octets. A node is permitted to > accept fragmented packets that reassemble to more than 1500 octets. > An upper-layer protocol or application that depends on IPv6 > fragmentation to send packets larger than the MTU of a path should > not send packets larger than 1500 octets unless it has assurance that > the destination is capable of reassembling packets of that larger > size. 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 (MLD6 is SHOULD) what happens if a cellular node doesn't emit MLD? will the upstream router always flood multicast datagrams to cellular hosts? 2.11 RFC2711 - IPv6 Router Alert Option in 2.4, it is specified that a cellular host will not be come a router. therefore, there should be no need to implement the receiver side of the router alert option, 2.17 DNS what do you mean by "DNS proxy" service? if you still use DNS- formatted traffic from the cellular hosts, you would need to support DNS protocol anyways. do you mean an HTTP proxy? if so, how would you support name resolution for other protocols? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 01:52:40 2001 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 f658qedP028136 for ; Thu, 5 Jul 2001 01:52:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f658qdKS028135 for ipng-dist; Thu, 5 Jul 2001 01:52:39 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f658qadP028128 for ; Thu, 5 Jul 2001 01:52: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 BAA11952 for ; Thu, 5 Jul 2001 01:52:45 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA14450 for ; Thu, 5 Jul 2001 01:52:44 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f658qhN26043 for ; Thu, 5 Jul 2001 10:52:43 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Jul 05 10:52:42 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Jul 2001 10:46:53 +0200 Message-ID: From: "Peter Hedman N (ECS)" To: "'Claude Castelluccia'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Thu, 5 Jul 2001 10:53:04 +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 Hi, Perhaps we haven't been defining the context "cellular" clear enough, but the intention was to start of without technologies such as WLAN and Bluetooth, and only handle those with larger cell sizes and coverage. This almost always implies some type of billing mechanisms to it as the architecture and bandwidth is considered to be more expensive. Regards, Peter -----Original Message----- From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr] Sent: den 5 juli 2001 09:58 To: Hesham Soliman (ERA) Cc: ipng@sunroof.eng.sun.com Subject: Re: Proxy announcement ! Hello , This is a very interesting draft but I would suggest to change the title. Something like "Minimum IPv6 Functionality for a 3GPP Host" would be more accurate... Some of the sections are very specific to the 3GPP architecture and can not be generalized to Cellular hosts (that could used IEEE802.11, Bluetooth, blabla types of networks..) Regards, Claude. "Hesham Soliman (ERA)" wrote: All, A new draft on IPv6 Cellular hosts requirements was submitted today. Until it's announced, you can view it here: http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt I'm doing this for Jari (one of the author) as he's away. Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 02:03:25 2001 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 f6593OdP028162 for ; Thu, 5 Jul 2001 02:03:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6593OsL028161 for ipng-dist; Thu, 5 Jul 2001 02:03: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6593KdP028153 for ; Thu, 5 Jul 2001 02:03: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 CAA12564 for ; Thu, 5 Jul 2001 02:03:30 -0700 (PDT) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26091 for ; Thu, 5 Jul 2001 02:03:29 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <317T3QV9>; Thu, 5 Jul 2001 05:03:28 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46054629@ftmail> From: George Tsirtsis To: "'Peter Hedman N (ECS)'" , "'Claude Castelluccia'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Thu, 5 Jul 2001 05:03:26 -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 share Claude's point..."cellular" is too generic..you really mean "3G cellular". Other than that, I think the draft is useful as an Informational document. George -----Original Message----- From: Peter Hedman N (ECS) [mailto:Peter.N.Hedman@ecs.ericsson.se] Sent: Thursday, July 05, 2001 9:53 AM To: 'Claude Castelluccia' Cc: ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Hi, Perhaps we haven't been defining the context "cellular" clear enough, but the intention was to start of without technologies such as WLAN and Bluetooth, and only handle those with larger cell sizes and coverage. This almost always implies some type of billing mechanisms to it as the architecture and bandwidth is considered to be more expensive. Regards, Peter -----Original Message----- From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr] Sent: den 5 juli 2001 09:58 To: Hesham Soliman (ERA) Cc: ipng@sunroof.eng.sun.com Subject: Re: Proxy announcement ! Hello , This is a very interesting draft but I would suggest to change the title. Something like "Minimum IPv6 Functionality for a 3GPP Host" would be more accurate... Some of the sections are very specific to the 3GPP architecture and can not be generalized to Cellular hosts (that could used IEEE802.11, Bluetooth, blabla types of networks..) Regards, Claude. "Hesham Soliman (ERA)" wrote: All, A new draft on IPv6 Cellular hosts requirements was submitted today. Until it's announced, you can view it here: http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.t xt I'm doing this for Jari (one of the author) as he's away. Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jul 5 02:32:55 2001 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 f659WrdP028212 for ; Thu, 5 Jul 2001 02:32:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f659WrsP028211 for ipng-dist; Thu, 5 Jul 2001 02:32:53 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f659WkdP028204 for ; Thu, 5 Jul 2001 02:32:50 -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 CAA14129 for ; Thu, 5 Jul 2001 02:32:56 -0700 (PDT) Received: from dns1.catt.ac.cn ([202.106.106.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04369 for ; Thu, 5 Jul 2001 03:32:52 -0600 (MDT) Received: from liangxg (202.106.106.126 [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3J07PCC0; Thu, 5 Jul 2001 17:27:17 +0800 Message-ID: <001e01c10535$2f947ab0$75ce12ac@MCSD.local> From: "Xingang Liang" To: Subject: IPv4,IPv6,IPv8,...??? Date: Thu, 5 Jul 2001 17:30:47 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C10578.3A448CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C10578.3A448CF0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksZHVyaW5nIHRoZXNlIGRheXMsSSBzdXJmZWQgaW4gdGhlIGludGVybmV0IGFuZCBsb29rZWQg Zm9yIHNvbWUgcmVzZWFyY2ggcGFwZXJzLGJ1dCBJIGZvdW5kIHRoaXMgd2Vic2l0ZTpodHRwOi8v aXB2OC52cngubmV0IEkgd29uZGVyIHdoYXQgdGhpcyBJUHY4IHJlZmVycyB0bz9XaGF0IGlzIHRo ZSBkaWZmZXJlbmNlIGJldHdlZW4gSVB2NCBhbmQgSVB2NixhbmQgY2FuIElQdjggbGl2ZSBsb25n ZXIgdGhhbiBJUHY2IGluIHRoZSB3b3JsZD9JIGhvcGUgYW55b25lIGNhbiB0aHJvdyBzb21lIGxp Z2h0IG9uIG1lISEhDQpUbmFuayB5b3UhISENCg0KQlINCg0KWGluZ2FuZyBMaWFuZw0KU3RhbmRh cmRpemF0aW9uIERlcGFydG1lbnQNCk1vYmlsZSBDb21tdW5pY2F0aW9uIFImRCBDZW50ZXINCkNo aW5hIEFjYWRlbXkgb2YgVGVsZWNvbW11bmljYXRpb24gVGVjaG5vbG9neShDQVRUKQ0KTm8uNDAs WHVleXVhbiBSb2FkDQpCZWlqaW5nLENoaW5hDQoxMDAwODMNClRlbDorODYxMCA2MjMwNDQyMkVY VDIyNQ0KRmF4Ois4NjEwIDYyMzAzMTI3DQpNYWlsdG86bGlhbmd4Z0BjYXR0LmFjLmNuDQogDQog DQo= ------=_NextPart_000_001B_01C10578.3A448CF0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PEJBU0UgDQpocmVmPSJmaWxlOi8vQzpcUHJv Z3JhbSBGaWxlc1xDb21tb24gRmlsZXNcTWljcm9zb2Z0IFNoYXJlZFxTdGF0aW9uZXJ5XCI+DQo8 U1RZTEU+Qk9EWSB7DQoJQkFDS0dST1VORC1QT1NJVElPTjogbGVmdCB0b3A7IEJBQ0tHUk9VTkQt UkVQRUFUOiBuby1yZXBlYXQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQ291cmllciBO ZXc7IEZPTlQtU0laRTogMTBwdA0KfQ0KPC9TVFlMRT4NCg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMzEwMy4xMDAwIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNm ZmZmZmY+DQo8RElWPkhpLGR1cmluZyB0aGVzZSBkYXlzLEkgc3VyZmVkIGluIHRoZSBpbnRlcm5l dCBhbmQgbG9va2VkIGZvciBzb21lIHJlc2VhcmNoIA0KcGFwZXJzLGJ1dCBJIGZvdW5kIHRoaXMg d2Vic2l0ZTo8QSANCmhyZWY9Imh0dHA6Ly9pcHY4LnZyeC5uZXQiPmh0dHA6Ly9pcHY4LnZyeC5u ZXQ8L0E+IEkgd29uZGVyIHdoYXQgdGhpcyBJUHY4IA0KcmVmZXJzIHRvP1doYXQgaXMgdGhlIGRp ZmZlcmVuY2UgYmV0d2VlbiBJUHY0IGFuZCBJUHY2LGFuZCBjYW4gSVB2OCBsaXZlIGxvbmdlciAN CnRoYW4gSVB2NiBpbiB0aGUgd29ybGQ/SSBob3BlIGFueW9uZSBjYW4gdGhyb3cgc29tZSBsaWdo dCBvbiBtZSEhITwvRElWPg0KPERJVj5UbmFuayB5b3UhISE8L0RJVj4NCjxESVY+Jm5ic3A7PC9E SVY+DQo8RElWPkJSPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5YaW5nYW5nIExpYW5n PEJSPlN0YW5kYXJkaXphdGlvbiBEZXBhcnRtZW50PEJSPk1vYmlsZSBDb21tdW5pY2F0aW9uIFIm YW1wO0QgDQpDZW50ZXI8QlI+Q2hpbmEgQWNhZGVteSBvZiBUZWxlY29tbXVuaWNhdGlvbiBUZWNo bm9sb2d5KENBVFQpPEJSPk5vLjQwLFh1ZXl1YW4gDQpSb2FkPEJSPkJlaWppbmcsQ2hpbmE8QlI+ MTAwMDgzPEJSPlRlbDorODYxMCA2MjMwNDQyMkVYVDIyNTxCUj5GYXg6Kzg2MTAgDQo2MjMwMzEy NzxCUj48QSANCmhyZWY9Im1haWx0bzpsaWFuZ3hnQGNhdHQuYWMuY24iPk1haWx0bzpsaWFuZ3hn QGNhdHQuYWMuY248L0E+PEJSPiZuYnNwOzxCUj4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_001B_01C10578.3A448CF0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 02:40:00 2001 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 f659dxdP028234 for ; Thu, 5 Jul 2001 02:40:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f659dx3i028233 for ipng-dist; Thu, 5 Jul 2001 02:39: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f659dudP028226 for ; Thu, 5 Jul 2001 02:39: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 CAA14406 for ; Thu, 5 Jul 2001 02:40:06 -0700 (PDT) Received: from ew.mimos.my (ew.mimos.my [192.228.129.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05684 for ; Thu, 5 Jul 2001 02:40:05 -0700 (PDT) Received: from localhost (ina@localhost) by ew.mimos.my (8.9.3/8.9.3) with ESMTP id RAA05997 for ; Thu, 5 Jul 2001 17:40:03 +0800 (MYT) Date: Thu, 5 Jul 2001 17:40:03 +0800 (MYT) From: Raja Azlina Raja Mahmood X-Sender: ina@ew To: ipng@sunroof.eng.sun.com Subject: IPv6 chronology Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I'm interested in IPv6 chronology but could only find from 92 to 95(during standardization etc), from books etc. As activities is concerned, need to find a bit here and there. And I'm not sure if some of these IPv6 projects ever get finished or not(i.e. no updates on their achievements). If in ISOC's website, they have the Internet chronology by those who made it history, i.e. Vin Cerf, the late Jon Postel etc, can we have similar one in IPv6? Or there is already one which I'm not aware of? Appreciate any feedback or comment. -ina -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 02:44:30 2001 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 f659iTdP028257 for ; Thu, 5 Jul 2001 02:44:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f659iT2F028256 for ipng-dist; Thu, 5 Jul 2001 02: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 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 f659iQdP028249 for ; Thu, 5 Jul 2001 02:44: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 CAA20441 for ; Thu, 5 Jul 2001 02:44:36 -0700 (PDT) Received: from dns1.catt.ac.cn ([202.106.106.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09351 for ; Thu, 5 Jul 2001 03:44:32 -0600 (MDT) Received: from liangxg (202.106.106.126 [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3J07PC14; Thu, 5 Jul 2001 17:38:57 +0800 Message-ID: <001201c10536$d0bbb560$75ce12ac@MCSD.local> From: "Xingang Liang" To: Subject: IPv4,IPv6,IPv8,...???---text version Date: Thu, 5 Jul 2001 17:42:27 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f659iQdP028250 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi,during these days,I surfed in the internet and looked for some research papers,but I found this website:http://ipv8.vrx.net I wonder what this IPv8 refers to?What is the difference between IPv4 and IPv6,and can IPv8 live longer than IPv6 in the world?I hope anyone can throw some light on me!!! Tnank you!!! BR Xingang Liang Standardization Department Mobile Communication R&D Center China Academy of Telecommunication Technology(CATT) No.40,Xueyuan Road Beijing,China 100083 Tel:+8610 62304422EXT225 Fax:+8610 62303127 Mailto:liangxg@catt.ac.cn -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 03:30:25 2001 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 f65AUPdP028294 for ; Thu, 5 Jul 2001 03:30:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65AUPXx028293 for ipng-dist; Thu, 5 Jul 2001 03:30: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65AULdP028286 for ; Thu, 5 Jul 2001 03:30:21 -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 DAA23275 for ; Thu, 5 Jul 2001 03:30:29 -0700 (PDT) From: john.loughney@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 DAA17362 for ; Thu, 5 Jul 2001 03:30:28 -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 f65AUi316249 for ; Thu, 5 Jul 2001 13:30:44 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 5 Jul 2001 13:30:27 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 5 Jul 2001 13:30:27 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAE5@esebe004.NOE.Nokia.com> To: claude.castelluccia@inrialpes.fr Cc: ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Thu, 5 Jul 2001 13:30:23 +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 Claude, > This is a very interesting draft but I would suggest to > change the title. Something like "Minimum IPv6 Functionality > for a 3GPP Host" would be more accurate... > > Some of the sections are very specific to the 3GPP architecture > and can not be generalized to Cellular hosts (that could used > IEEE802.11, Bluetooth, blabla types of networks..) We had some discussion between the authors on this topic. Our first title was "Min IPv6 Functionality for a Wireless Host" but we realized that this would be misleading because of the reason you mention above. Cellular was chosen to denote wireless hosts using licensed bands, like 2.5G and 3G. We do try to define what we mean by cellular host in the introduction: For the purposes of this draft, a cellular host is considered to be a terminal which uses an air interface to connect to a cellular access network (i.e. - GPRS, UMTS, CDMA2000) in order to provide IPv6 connectivity to an IP network. The functionality to provide IPv6 connectivity is outlined in this draft. A side note: we needed to specify quite a few exceptions for hosts connecting to 3GPP networks because those specifications are the most specified. Since some of those specs are already completed, and are already being implemented for deployment later this year (in some cases), we felt that we needed to point them out for implementors. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 03:33:52 2001 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 f65AXqdP028316 for ; Thu, 5 Jul 2001 03:33:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65AXp9k028315 for ipng-dist; Thu, 5 Jul 2001 03:33: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65AXmdP028308 for ; Thu, 5 Jul 2001 03:33:48 -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 DAA01362 for ; Thu, 5 Jul 2001 03:33:56 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA29722 for ; Thu, 5 Jul 2001 04:34:53 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f65AYDI19610 for ; Thu, 5 Jul 2001 13:34:14 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 5 Jul 2001 13:33:48 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 5 Jul 2001 13:33:49 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF093FEC@esebe004.NOE.Nokia.com> To: G.Tsirtsis@flarion.com, Peter.N.Hedman@ecs.ericsson.se, claude.castelluccia@inrialpes.fr Cc: ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Thu, 5 Jul 2001 13:33:48 +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 George, > I share Claude's point..."cellular" is too generic..you > really mean "3G cellular". Other than that, I think the > draft is useful as an Informational document. There is consideration for 2.5G hosts as well (GSM terminals connecting to GPRS [2nd generation] networks. For me, cellular is TDMA, CDMA, GSM, PCS, WCDMA, CDMA2000, etc. Wireless is Bluetooth, WLAN, etc. Should we define this better? 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 Thu Jul 5 03:53:31 2001 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 f65ArVdP028358 for ; Thu, 5 Jul 2001 03:53:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65ArV9G028357 for ipng-dist; Thu, 5 Jul 2001 03:53: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65ArRdP028350 for ; Thu, 5 Jul 2001 03:53:27 -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 DAA17716 for ; Thu, 5 Jul 2001 03:53: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 EAA05621 for ; Thu, 5 Jul 2001 04:54:33 -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 GAA06401; Thu, 5 Jul 2001 06:52:44 -0400 (EDT) Message-Id: <200107051052.GAA06401@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-hain-ipv6-pi-addr-00.txt Date: Thu, 05 Jul 2001 06:52:44 -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 : An IPv6 Provider-Independent Global Unicast Address Format Author(s) : T. Hain Filename : draft-hain-ipv6-pi-addr-00.txt Pages : 11 Date : 03-Jul-01 This document defines an IPv6 Provider-Independent global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [2] and the 'IPv6 Addressing Architecture' [3]. It is designed to facilitate scalable Internet routing when sites attach to multiple service providers, by using a prefix based on a geographic reference to the site. A natural byproduct of this address allocation mechanism is that all addresses are fixed allowing sites to change providers at will without requiring their network to renumber. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-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-hain-ipv6-pi-addr-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-hain-ipv6-pi-addr-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: <20010703124533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-hain-ipv6-pi-addr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-hain-ipv6-pi-addr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124533.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 Jul 5 04:13:39 2001 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 f65BDddP028498 for ; Thu, 5 Jul 2001 04:13:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65BDdFN028497 for ipng-dist; Thu, 5 Jul 2001 04:13: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65BDZdP028490 for ; Thu, 5 Jul 2001 04:13: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 EAA03356 for ; Thu, 5 Jul 2001 04:13:43 -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 FAA13614 for ; Thu, 5 Jul 2001 05:13:41 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id <317T3QXB>; Thu, 5 Jul 2001 07:13:42 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE4605462C@ftmail> From: George Tsirtsis To: "'john.loughney@nokia.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Thu, 5 Jul 2001 07:13:35 -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 -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Thursday, July 05, 2001 11:34 AM To: G.Tsirtsis@flarion.com; Peter.N.Hedman@ecs.ericsson.se; claude.castelluccia@inrialpes.fr Cc: ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Hi George, > I share Claude's point..."cellular" is too generic..you > really mean "3G cellular". Other than that, I think the > draft is useful as an Informational document. There is consideration for 2.5G hosts as well (GSM terminals connecting to GPRS [2nd generation] networks. For me, cellular is TDMA, CDMA, GSM, PCS, WCDMA, CDMA2000, etc. GT> But John, surely you do not mean that a 2G GSM/PCS phone is now expected to support the protocols in this draft.... In fact the draft has nothing to do with the access technologies listed above...it only makes sense in the context of 2.5/3G *architecture*, don't you think? George -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 04:46:13 2001 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 f65BkDdP028605 for ; Thu, 5 Jul 2001 04:46:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65BkDhO028604 for ipng-dist; Thu, 5 Jul 2001 04:46:13 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65Bk9dP028597 for ; Thu, 5 Jul 2001 04: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 EAA20684 for ; Thu, 5 Jul 2001 04:46:18 -0700 (PDT) Received: from cisco.com (megha.cisco.com [192.122.173.140]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06011 for ; Thu, 5 Jul 2001 04:46:17 -0700 (PDT) Received: from cisco.com (codc1-xdm5.cisco.com [192.122.173.24]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA12830 for ; Thu, 5 Jul 2001 17:16:02 +0530 (IST) Message-ID: <3B445391.4890635F@cisco.com> Date: Thu, 05 Jul 2001 17:16:25 +0530 From: Sardar Maansingh Organization: HCL-Cisco ODC X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ipng Subject: need some info..., Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, What is the best email group to get clarify the doubts on IPv6 ? Can someone please point me to the best? Or Can I ask the doubts relating to IPv6 on this group? Thanks, MaanSingh. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 04:51:23 2001 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 f65BpNdP028641 for ; Thu, 5 Jul 2001 04:51:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65BpNw6028640 for ipng-dist; Thu, 5 Jul 2001 04:51: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65BpJdP028633 for ; Thu, 5 Jul 2001 04:51:19 -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 EAA05136 for ; Thu, 5 Jul 2001 04:51:27 -0700 (PDT) From: john.loughney@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 EAA07247 for ; Thu, 5 Jul 2001 04:51:26 -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 f65Bpg318238 for ; Thu, 5 Jul 2001 14:51:42 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 5 Jul 2001 14:51:24 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 5 Jul 2001 14:51:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAE6@esebe004.NOE.Nokia.com> To: G.Tsirtsis@flarion.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Thu, 5 Jul 2001 14:51:05 +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 George, > GT> But John, surely you do not mean that a 2G GSM/PCS phone > is now expected to support the protocols in this draft.... > In fact the draft has nothing to do with the access technologies > listed above...it only makes sense in the context of 2.5/3G > *architecture*, don't you think? Exactly. The air interface is not the important point - it is the cellular access network that places certain considerations to what the cellular host needs to support (if it wants to use IPv6). With respect to this draft, our intention was to aid implementors who are adding IPv6 stacks to cellular hosts. Not all cell phones will connect to the Internet, so they don't need this. As there will be many IPv6-enabled cellular hosts (phones with data connections, for example), we want to make sure that they use IPv6 correctly and want to insure interoperability. br, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 05:52:37 2001 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 f65CqbdP028754 for ; Thu, 5 Jul 2001 05:52:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65CqbfM028753 for ipng-dist; Thu, 5 Jul 2001 05:52: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65CqXdP028746 for ; Thu, 5 Jul 2001 05:52:33 -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 FAA24779 for ; Thu, 5 Jul 2001 05:52:41 -0700 (PDT) Received: from iproxy2.ericsson.dk (iproxy2.ericsson.dk [130.228.248.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14351 for ; Thu, 5 Jul 2001 06:53:45 -0600 (MDT) Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246]) by iproxy2.ericsson.dk (8.10.1/8.10.1) with ESMTP id f65Cqbn19472; Thu, 5 Jul 2001 14:52:37 +0200 (MET DST) Received: from ted.ericsson.dk (geku.ted.dk.eu.ericsson.se [192.66.4.82]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id f65CqVD24938; Thu, 5 Jul 2001 14:52:32 +0200 (MEST) Message-ID: <3B446361.9DEB97C2@ted.ericsson.dk> Date: Thu, 05 Jul 2001 14:53:53 +0200 From: "Gerben Kuijpers (TED)" Organization: Ericsson Telebit A/S X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: ipng@sunroof.eng.sun.com Subject: Re: Proxy announcement ! References: <20010705084107.8962B7BB@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your comments, response inline. Jun-ichiro itojun Hagino wrote: > > >> A new draft on IPv6 Cellular hosts requirements was submitted today. > >> Until it's announced, you can view it here: > >> http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt > >> I'm doing this for Jari (one of the author) as he's away. > > here are a couple of comments. > > itojun > > 2.1 RFC1981 - Path MTU Discovery for IP Version 6 > > > If Path MTU Discovery is not implemented, then the uplink packet > > size MUST be limited to 1280 octets (standard limit in [IPv6]). > > However, the cellular host MUST be able to receive packets with size > > up to the link MTU. > > The text (3rd and 4th line) is unclear (is it after the reassembly > or before? or am I badly confused?), and may conflict with RFC2460 > depending on the link MTU for the cellular host. ??? > > RFC2460 page 25 > > A node must be able to accept a fragmented packet that, after > > reassembly, is as large as 1500 octets. A node is permitted to > > accept fragmented packets that reassemble to more than 1500 octets. > > An upper-layer protocol or application that depends on IPv6 > > fragmentation to send packets larger than the MTU of a path should > > not send packets larger than 1500 octets unless it has assurance that > > the destination is capable of reassembling packets of that larger > > size. This is before reassembly. Let's try to clarify this with an example. Consider the following situation: link MTU=1500 path MTU=1500 cellular host A <--------------> router <--- ... network ... ---> host B The cellular host A communicates with host B. Host A does not do Path MTU discovery, but host B does. Host A will have to limit its packet size to 1280 bytes, while host B finds a path MTU of 1500 and will send packets up to that size. Maybe its a bit unclear, since we're stating the obvious that a host must be able to receive packets with size up to its link MTU. > > 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 > > (MLD6 is SHOULD) what happens if a cellular node doesn't emit MLD? > will the upstream router always flood multicast datagrams to cellular > hosts? > A cellular host that wants to join multicast groups with a scope larger than link-scope will have to notify the upstream router in some way. Probably MLD is the best way to do this. When no notification is sent to the upstream router, you're right, flooding is the only option, but not preferable. The typical topology at IP layer for a cellular network (such as 3GPP) is as follows: Internet | | | ___________|__________ | | | Upstream router | |______________________| | | ....... | | | | | | | host 1 host 2 host n A large number of cellular hosts each have a point-to-point link to an IP router that is part of the cellular network and acts as a gateway to the Internet for the cellular system. The point-to-point link between the router and a cellular host typically consist of multiple links at link-layer, including a wireless link closest to the cellular host. Flooding will be a very inefficient for multicast datagrams (in fact it will be a broadcast then), since a single subscribed host could cause broadcasting of datagrams to 1000s of hosts. For such a topology, the advantages of using multicasting (including MLD) might be limited. A multicast datagram arriving at the router will have to be sent on each individual point-to-point link to each cellular host subscribed to that particular multicast group. Only the load on the link from the router to the Internet can be reduced by multicasting. This at cost of extra load on the (bandwidth limited) wireless links in the form of MLD signaling. > 2.11 RFC2711 - IPv6 Router Alert Option > > in 2.4, it is specified that a cellular host will not be come a router. > therefore, there should be no need to implement the receiver side > of the router alert option, Good point, we'll note that. Gerben Kuijpers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 05:59:50 2001 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 f65CxndP028774 for ; Thu, 5 Jul 2001 05:59:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65Cxnq0028773 for ipng-dist; Thu, 5 Jul 2001 05:59: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65CxkdP028766 for ; Thu, 5 Jul 2001 05:59: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 FAA25168 for ; Thu, 5 Jul 2001 05:59:55 -0700 (PDT) Received: from cisco.com (megha.cisco.com [192.122.173.140]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17014 for ; Thu, 5 Jul 2001 07:00:57 -0600 (MDT) Received: from cisco.com (codc1-xdm5.cisco.com [192.122.173.24]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA28733 for ; Thu, 5 Jul 2001 18:29:38 +0530 (IST) Message-ID: <3B4464D0.710F741C@cisco.com> Date: Thu, 05 Jul 2001 18:30:00 +0530 From: Sardar Maansingh Organization: HCL-Cisco ODC X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Ipng Subject: IPv6 stateless address autoconfiguration...., Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am new to IPv6 and have few doubts regarding "IPv6 stateless address autoconfiguration". RFC 2462 not clear my doubts. Any help from you people is greatly appreciated. what do "stateless" and "stateful" means in this context?? 1) What is stateless autoconfiguration? 2) What is stateful autoconfiguration? and Why two methodes? 3) What is the difference between them? 4) Will this feature is equivalent to any features of IPv4? 5) Where can I find the examples to stateless address auto configurations? Thanks in advance, MaanSingh. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 06:39:23 2001 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 f65DdNdP028874 for ; Thu, 5 Jul 2001 06:39:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65DdMnO028873 for ipng-dist; Thu, 5 Jul 2001 06:39:22 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65DdHdP028866 for ; Thu, 5 Jul 2001 06:39:18 -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 GAA28274 for ; Thu, 5 Jul 2001 06:39:26 -0700 (PDT) Received: from starfruit.itojun.org (dial-47-D01.QXO1.equant.net [57.72.131.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA02788 for ; Thu, 5 Jul 2001 07:40:26 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 2E3267BB; Thu, 5 Jul 2001 22:39:15 +0900 (JST) To: "Gerben Kuijpers (TED)" Cc: ipng@sunroof.eng.sun.com In-reply-to: Gerben.A.Kuijpers's message of Thu, 05 Jul 2001 14:53:53 +0200. <3B446361.9DEB97C2@ted.ericsson.dk> 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: Proxy announcement ! From: Jun-ichiro itojun Hagino Date: Thu, 05 Jul 2001 22:39:15 +0900 Message-Id: <20010705133915.2E3267BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> 2.1 RFC1981 - Path MTU Discovery for IP Version 6 >> >> > If Path MTU Discovery is not implemented, then the uplink packet >> > size MUST be limited to 1280 octets (standard limit in [IPv6]). >> > However, the cellular host MUST be able to receive packets with size >> > up to the link MTU. >> >> The text (3rd and 4th line) is unclear (is it after the reassembly >> or before? or am I badly confused?), and may conflict with RFC2460 >> depending on the link MTU for the cellular host. ??? > >This is before reassembly. Let's try to clarify this with an example. Consider >the following situation: > > link MTU=1500 path MTU=1500 >cellular host A <--------------> router <--- ... network ... ---> host B > > >The cellular host A communicates with host B. Host A does not do Path MTU >discovery, but host B does. Host A will have to limit its packet size to 1280 >bytes, while host B finds a path MTU of 1500 and will send packets up to that >size. Maybe its a bit unclear, since we're stating the obvious that a host must >be able to receive packets with size up to its link MTU. yes, i fully understand the situation. how about adding "(before reassembly)" at the end of the paragraph, just for clarity? >> 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 >> >> (MLD6 is SHOULD) what happens if a cellular node doesn't emit MLD? >> will the upstream router always flood multicast datagrams to cellular >> hosts? > Internet > | > | > | > ___________|__________ > | | > | Upstream router | > |______________________| > | | ....... | > | | | > | | | > host 1 host 2 host n (snip) >For such a topology, the advantages of using multicasting (including MLD) might >be limited. A multicast datagram arriving at the router will have to be sent on >each individual point-to-point link to each cellular host subscribed to that >particular multicast group. Only the load on the link from the router to the >Internet can be reduced by multicasting. This at cost of extra load on the >(bandwidth limited) wireless links in the form of MLD signaling. assuming that we do need to do multicasts (not just link-local): if you use MLD between "upstream router" and cellular hosts, you may be able to cut down multicast groups the upstream router would need to forward (if none of cellular host[1-n] is listening to the group). if you don't use MLD, the "upstream router" needs to forward multicast packets for every groups host[1-n] potentially join in the future. am i confused? 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 Jul 5 07:04:11 2001 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 f65E4AdP028916 for ; Thu, 5 Jul 2001 07:04:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65E4ARM028915 for ipng-dist; Thu, 5 Jul 2001 07:04:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65E47dP028908 for ; Thu, 5 Jul 2001 07:04:07 -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 HAA00312 for ; Thu, 5 Jul 2001 07:04:14 -0700 (PDT) From: pete@loshin.com Received: from chmls06.mediaone.net (chmls06.mediaone.net [24.147.1.144]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16120 for ; Thu, 5 Jul 2001 07:04:14 -0700 (PDT) Received: from gateway.loshin (h00a0c5e1478f.ne.mediaone.net [24.147.211.223]) by chmls06.mediaone.net (8.11.1/8.11.1) with ESMTP id f65E49804230 for ; Thu, 5 Jul 2001 10:04:09 -0400 (EDT) Received: from gateway.loshin (IDENT:pete@localhost.localdomain [127.0.0.1]) by gateway.loshin (8.9.3/8.9.3) with ESMTP id JAA01235 for ; Thu, 5 Jul 2001 09:58:50 -0400 Message-Id: <200107051358.JAA01235@gateway.loshin> X-Mailer: exmh version 2.1.1 10/15/1999 To: ipng@sunroof.eng.sun.com Subject: questions for article about IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Jul 2001 09:58:50 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all. I'm working on a short article for the August issue of Information Security Magazine about IPv6 and security issues, and have some questions: - What, if any, are the security implications of delaying adoption of IPv6? - How will NAT affect network security going forward? That includes both active malicious attacks of all sorts as well as failures attributable to NAT itself. What about trends to writing NAT-friendly apps? (i.e., draft-ietf-nat-app-guide-06.txt) - How (if at all) have perceived security issues in IPv6 security affected its acceptance? (e.g., use of IEEE link layer addresses in stateless autoconfiguration, binding updates in mobile IPv6, the RFC 2553 issues raised recently, etc.) - Are there any other security issues that people need to be aware of when considering IPv6? Comments on IPv6 and IPsec are also welcome. Replies to the list are fine, as are direct replies to me--if anyone wants, I can summarize direct responses. Thanks! regards, -pl -- +-------------------------------------------------------------+ | Pete Loshin http://www.loshin.com | | pete@loshin.com +1 781/646-6318 | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 07:19:05 2001 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 f65EJ5dP028938 for ; Thu, 5 Jul 2001 07:19:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65EJ5Zg028937 for ipng-dist; Thu, 5 Jul 2001 07:19: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65EJ1dP028930 for ; Thu, 5 Jul 2001 07:19:01 -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 HAA01511 for ; Thu, 5 Jul 2001 07:19:05 -0700 (PDT) Received: from iproxy1.ericsson.dk (iproxy1.ericsson.dk [130.228.248.98]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA19155 for ; Thu, 5 Jul 2001 08:20:08 -0600 (MDT) Received: from unixmail.ted.dk.eu.ericsson.se (knud.ted.dk.eu.ericsson.se [192.66.4.246]) by iproxy1.ericsson.dk (8.10.1/8.10.1) with ESMTP id f65EJ1628718; Thu, 5 Jul 2001 16:19:01 +0200 (MET DST) Received: from ted.ericsson.dk (geku.ted.dk.eu.ericsson.se [192.66.4.82]) by unixmail.ted.dk.eu.ericsson.se (8.10.1/8.10.1/TEDmain-1.0) with ESMTP id f65EIuD26694; Thu, 5 Jul 2001 16:18:56 +0200 (MEST) Message-ID: <3B4477A5.3179DAC2@ted.ericsson.dk> Date: Thu, 05 Jul 2001 16:20:21 +0200 From: "Gerben Kuijpers (TED)" Organization: Ericsson Telebit A/S X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.17-21mdk i686) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: ipng@sunroof.eng.sun.com Subject: Re: Proxy announcement ! References: <20010705133915.2E3267BB@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: > > >> 2.1 RFC1981 - Path MTU Discovery for IP Version 6 > >> > >> > If Path MTU Discovery is not implemented, then the uplink packet > >> > size MUST be limited to 1280 octets (standard limit in [IPv6]). > >> > However, the cellular host MUST be able to receive packets with size > >> > up to the link MTU. > >> > >> The text (3rd and 4th line) is unclear (is it after the reassembly > >> or before? or am I badly confused?), and may conflict with RFC2460 > >> depending on the link MTU for the cellular host. ??? > > > >This is before reassembly. Let's try to clarify this with an example. Consider > >the following situation: > > > > link MTU=1500 path MTU=1500 > >cellular host A <--------------> router <--- ... network ... ---> host B > > > > > >The cellular host A communicates with host B. Host A does not do Path MTU > >discovery, but host B does. Host A will have to limit its packet size to 1280 > >bytes, while host B finds a path MTU of 1500 and will send packets up to that > >size. Maybe its a bit unclear, since we're stating the obvious that a host must > >be able to receive packets with size up to its link MTU. > > yes, i fully understand the situation. > how about adding "(before reassembly)" at the end of the paragraph, > just for clarity? Agree, that will be more clear, we'll add that. > > >> 2.10 RFC2710 - Multicast Listener Discovery (MLD) for IPv6 > >> > >> (MLD6 is SHOULD) what happens if a cellular node doesn't emit MLD? > >> will the upstream router always flood multicast datagrams to cellular > >> hosts? > > Internet > > | > > | > > | > > ___________|__________ > > | | > > | Upstream router | > > |______________________| > > | | ....... | > > | | | > > | | | > > host 1 host 2 host n > (snip) > >For such a topology, the advantages of using multicasting (including MLD) might > >be limited. A multicast datagram arriving at the router will have to be sent on > >each individual point-to-point link to each cellular host subscribed to that > >particular multicast group. Only the load on the link from the router to the > >Internet can be reduced by multicasting. This at cost of extra load on the > >(bandwidth limited) wireless links in the form of MLD signaling. > > assuming that we do need to do multicasts (not just link-local): > > if you use MLD between "upstream router" and cellular hosts, you > may be able to cut down multicast groups the upstream router would > need to forward (if none of cellular host[1-n] is listening to the > group). > > if you don't use MLD, the "upstream router" needs to forward multicast > packets for every groups host[1-n] potentially join in the future. > > am i confused? You're right, if we do need non-link-local multicast, then the upstream router needs to be notified in some way about which multicast groups each cellular host is listening to- Otherwise the upstream router doesn't know to which host it has to forward specific multicast datagrams and the only option that remains is to send each multicast datagram to each host, wasting a lot of bandwidth. MLD between the hosts and the upstream router is a possible mechanism for notifying the router about the multicast groups the different hosts are interested in. > > itojun Gerben Kuijpers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 09:37:21 2001 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 f65GbJdP029270 for ; Thu, 5 Jul 2001 09:37:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65GbJfH029269 for ipng-dist; Thu, 5 Jul 2001 09:37:19 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65GbFdP029262 for ; Thu, 5 Jul 2001 09: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 JAA24395 for ; Thu, 5 Jul 2001 09:37:24 -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 KAA19690 for ; Thu, 5 Jul 2001 10:38:26 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f65GZOm01569; Thu, 5 Jul 2001 12:35:25 -0400 Message-Id: <200107051635.f65GZOm01569@hygro.adsl.duke.edu> To: "Karuppiah, Ettikan Kandasamy" cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 hierarchical routing: RFC 2374 In-Reply-To: Message from "Karuppiah, Ettikan Kandasamy" of "Wed, 04 Jul 2001 13:19:29 +0800." <92AC01AFC296D411AC6800A0C9E00CF4033A9EF2@pgsmsx35.png.intel.com> Date: Thu, 05 Jul 2001 12:35:24 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Referring to the above RFC(2374); > The aim of Aggregatable addressing is to simplify routing compared to > current CIDR, at each level. Does it dictates, that routers at each level > will have entries only for the specified prefixes? For example, long-haul > providers backbone router has entries of only /16 prefix route entries and > NLA1 router's will have /48 prefix entry, etc. Or mix of different prefix > sizes are allowed to be added at the routing table regardless of > it's level! There will be a mix of prefixes supported at most levels. The idea that there could be a strict heirarchy (with say, some routers needing only /16 routes and none with longer prefixes) is an attractive idea, but is not in line with reality in IPv4 today, or how traditional IPv6 operators expect IPv6 to be done. This general topic may better be discussed in the multi6 WG. 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 Jul 5 09:53:22 2001 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 f65GrMdP029389 for ; Thu, 5 Jul 2001 09:53:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65GrLn2029388 for ipng-dist; Thu, 5 Jul 2001 09:53: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65GrIdP029381 for ; Thu, 5 Jul 2001 09:53:18 -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 JAA14842 for ; Thu, 5 Jul 2001 09:53:27 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net [4.60.68.77]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06620 for ; Thu, 5 Jul 2001 09:53:26 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 05 Jul 2001 09:53:17 -0700 Received: from eagleswings [192.168.123.14] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 1A57D618C8F542339FC438EC04DE73BA for plus 2 more; Thu, 05 Jul 2001 09:53:16 -0700 Reply-To: From: "Tony Hain" To: "Karuppiah, Ettikan Kandasamy" , Cc: Subject: RE: IPv6 hierarchical routing: RFC 2374 Date: Thu, 5 Jul 2001 09:53:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <92AC01AFC296D411AC6800A0C9E00CF4033A9EF6@pgsmsx35.png.intel.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 2B689E6F-DF19456D-8B66A968-34D3BC58 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karuppiah, Ettikan Kandasamy wrote: > ... At least we 'should' say (make it a rule , if applicable) > that this should not be supported at certain level of > hierarchies, since there is no documents say's it not > permitted currently. (correct me if I'm wrong) Routing policy is outside the scope of the IETF. We can point out the technical consequences of specific actions, and document current practice, but can't dictate rules to operators. 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 Jul 5 10:08:42 2001 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 f65H8gdP029423 for ; Thu, 5 Jul 2001 10:08:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65H8gAX029422 for ipng-dist; Thu, 5 Jul 2001 10:08: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65H8cdP029415 for ; Thu, 5 Jul 2001 10:08: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 KAA16822 for ; Thu, 5 Jul 2001 10:08:46 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net [4.60.68.77]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12598 for ; Thu, 5 Jul 2001 10:08:45 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 05 Jul 2001 10:08:37 -0700 Received: from eagleswings [192.168.123.14] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id E4597C99B31241D2B8DEC09E39456825 for plus 1 more; Thu, 05 Jul 2001 10:08:36 -0700 Reply-To: From: "Tony Hain" To: "Xingang Liang" , Subject: RE: IPv4,IPv6,IPv8,...???---text version Date: Thu, 5 Jul 2001 10:08:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <001201c10536$d0bbb560$75ce12ac@MCSD.local> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 3FA72D1A-35ED420E-B257EA08-2899D7E2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Xingang Liang wrote: > ...What is the difference between IPv4 and IPv6,and can IPv8 > live longer than IPv6 in the world?I hope anyone can throw > some light on me!!! The IPv8 effort exists simply to confuse people and delay adoption of IPv6. IPv4 is the version of the Internet protocol currently in wide use. IPv6 is the replacement version designed to extend the address space and streamline the processing rules. There are many debates about when IPv4 address space will run out, but there are currently places where the rules for getting addresses are so restricting that IPv4 effectively is already exhausted. The actual IPv4 allocation history was: 1981 - IPv4 protocol published 1985 ~ 1/16 total space 1990 ~ 1/8 total space 1995 ~ 1/4 total space 2000 ~ 1/2 total space 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 Jul 5 10:39:17 2001 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 f65HdHdP029474 for ; Thu, 5 Jul 2001 10:39:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65HdHPl029473 for ipng-dist; Thu, 5 Jul 2001 10:39: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65HdDdP029466 for ; Thu, 5 Jul 2001 10:39:13 -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 KAA10382 for ; Thu, 5 Jul 2001 10:39:22 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net [4.60.68.77]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24594 for ; Thu, 5 Jul 2001 10:39:20 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 05 Jul 2001 10:39:15 -0700 Received: from eagleswings [192.168.123.14] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id D429C93BA98340378F4A45F53C7E2F3F for plus 1 more; Thu, 05 Jul 2001 10:39:14 -0700 Reply-To: From: "Tony Hain" To: "Sardar Maansingh" , "Ipng" Subject: RE: IPv6 stateless address autoconfiguration...., Date: Thu, 5 Jul 2001 10:39:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B4464D0.710F741C@cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: A54D1FCD-314347D5-A5A9E41A-02D57ADB Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sardar Maansingh wrote: > what do "stateless" and "stateful" means in this context?? > Stateful means that the address is managed through a preconfigured database, where stateless means the address is constructed by the node. > 1) What is stateless autoconfiguration? Each node constructs its own address using an established set of rules, and some information from the local router (if one exists). > 2) What is stateful autoconfiguration? Each node asks the service (like DHCP) for the address it should be using. > and Why two methodes? Different operational environments will choose between them to achieve the desired policies. It is an operational cost vs. control trade-off. > 3) What is the difference between them? Stateful allows for strict central control of the entire 128-bits, while stateless has the central control only managing the upper 64-bits with each node responsible for the lower. > 4) Will this feature is equivalent to any features of IPv4? There is no equivalent IPv4 feature to stateless autoconfiguration. > 5) Where can I find the examples to stateless address > auto configurations? http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp http://www.compaq.com/ipv6/ http://www.sun.com/solaris/ipv6/ http://www.kame.net/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 11:12:48 2001 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 f65ICldP029530 for ; Thu, 5 Jul 2001 11:12:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65IClco029529 for ipng-dist; Thu, 5 Jul 2001 11:12:47 -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 f65IChdP029522 for ; Thu, 5 Jul 2001 11:12:43 -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 LAA03714 for ; Thu, 5 Jul 2001 11:12:51 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA24411 for ; Thu, 5 Jul 2001 12:12:49 -0600 (MDT) Received: from 157.54.9.101 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Jul 2001 09:38:33 -0700 (Pacific Daylight Time) 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); Thu, 5 Jul 2001 09:40:48 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 5 Jul 2001 09:40:47 -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); Thu, 5 Jul 2001 09:39:58 -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: I-D ACTION:draft-hain-ipv6-pi-addr-00.txt Date: Thu, 5 Jul 2001 09:39:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-hain-ipv6-pi-addr-00.txt thread-index: AcEFQYPkVP4/yAqNQXOwp+Bu9zCLZQALiIIA From: "Christian Huitema" To: Cc: X-OriginalArrivalTime: 05 Jul 2001 16:39:58.0684 (UTC) FILETIME=[210A21C0:01C10571] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f65ICidP029523 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, You allocate prefixes by combining latitude and longitude. The scheme you propose is reasonably efficient, using 44 bits to pave the earth with "squares" (in fact, trapezes) whose sides are at most 10 meter wide. This is about OK, except for the fact that an awful lot of the space is dedicated to deserts and oceans. But what happens in the rather common case of office buildings in which different organizations share different floors? -- 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 Jul 5 11:13:29 2001 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 f65IDSdP029547 for ; Thu, 5 Jul 2001 11:13:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f65IDSiq029546 for ipng-dist; Thu, 5 Jul 2001 11:13:28 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65IDOdP029539 for ; Thu, 5 Jul 2001 11:13: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 LAA13254 for ; Thu, 5 Jul 2001 11:13:32 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14463 for ; Thu, 5 Jul 2001 11:13:32 -0700 (PDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Jul 2001 14:12:48 -0400 Message-ID: From: Phil Roberts To: "'Hesham Soliman (ERA)'" , ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Thu, 5 Jul 2001 14:12:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have a bunch of comments on the document inline which I'll send to the authors offlist to avoid clutter. But I have some general comments for the list. Something like this is definitely needed and for multiple purposes so good job for making a start of it. 1. What is the intention of this document? If it is purely guidelines for implementors it should probably be redone as guidelines for implementors of IP v6 nodes in 3gpp networks. If it's input to SDOs there needs to be some rework identifying recommendations that are different from what has already been done or is being considered. The document doesn't seem to work well for either as written. This document has a lot of good material for both but seemed to go back and forth between the two goals. 2. For each of the above is the intention to educate the SDOs or the IETF? 3. A decision probably needs to be made about what kind of host is being considered. Again sometimes it seems the text is for hosts that will operate only in a cellular network and sometimes for hosts that will operate between a cellular network and another kind of network. The requirements for these two kinds of hosts could be quite different. 4. I think there was some concern at the interim meeting about the apparent 3gpp intent to limit cellular devices 1) to a single global address and 2) to being a host and having no possibility for a router function. Phil > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: Wednesday, July 04, 2001 9:56 AM > To: ipng@sunroof.eng.sun.com > Subject: Proxy announcement ! > > > All, > > A new draft on IPv6 Cellular hosts requirements was submitted today. > Until it's announced, you can view it here: > > http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cell > ular-host-00.txt > > I'm doing this for Jari (one of the author) as he's away. > > Cheers, > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 5 23:30:09 2001 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 f666U9dP000504 for ; Thu, 5 Jul 2001 23:30:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f666U9EJ000503 for ipng-dist; Thu, 5 Jul 2001 23:30:09 -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 f666U5dP000496 for ; Thu, 5 Jul 2001 23:30: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 XAA00653 for ; Thu, 5 Jul 2001 23:30:14 -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 XAA11275 for ; Thu, 5 Jul 2001 23:30: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 f666WrG25074 for ; Fri, 6 Jul 2001 09:32:53 +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, 6 Jul 2001 09:30:11 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Fri, 6 Jul 2001 09:30:11 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAE9@esebe004.NOE.Nokia.com> To: PRoberts@MEGISTO.com, ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Fri, 6 Jul 2001 09:30:10 +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 Phil, > I have a bunch of comments on the document inline which I'll > send to the authors offlist to avoid clutter. But I have some > general comments for the list. Something like this is definitely > needed and for multiple purposes so good job for making a start of it. Thanks. I'll respond to your points - my remarks are my own thoughts - I'm not trying to speak for the other authors. > 1. What is the intention of this document? If it is purely > guidelines for implementors it should probably be redone as > guidelines for implementors of IP v6 nodes in 3gpp networks. If > it's input to SDOs there needs to be some rework identifying > recommendations that are different from what has already been > done or is being considered. The document doesn't seem > to work well for either as written. This document has a lot of good > material for both but seemed to go back and forth between the two > goals. I'd first suggest that some of the folks who will be implementing IPv6 in in 3G phones (for example) may not be familiar with the IETF, so that it might be helpful to have this kind of document. Additionally, we want to insure that as mass produced devices (some with limited upgradability) hit the market, these devices work & interoperate with each other and the Internet. Secondly, I think this should be an IETF document. Other SDOs have their own way of handling contributions, so I think that clarifications on requirement language, etc. should be handled in specific contributions to those SDOs, not in an Internet draft. > 2. For each of the above is the intention to educate the > SDOs or the IETF? Yes to both. At the recent IPNGWG interim meeting in Seattle, there were lots of questions related to what with the handsets implement and support - so hopefully this addresses some of those issues. As far as other educating other SDOs, the best way forward (IMO) is to ensure that this is an IETF-style document, and make clarifications in contributions to the other SDOs > > 3. A decision probably needs to be made about what kind of > host is being considered. Again sometimes it seems the text > is for hosts that will operate only in a cellular network and > sometimes for hosts that will operate between a cellular > network and another kind of network. The requirements for > these two kinds of hosts could be quite different. Definately. We are trying to scope this document so that the minimum set is related to what will only operate via a cellular network. However, we felt that we should discuss when certain functionality might be needed, even if not directly supported by the cellular network. This is one part of the document that we know needs more work. > 4. I think there was some concern at the interim meeting > about the apparent 3gpp intent to limit cellular devices 1) > to a single global address and 2) to being a host > and having no possibility for a router function. First, cellular terminals can have more than one global address, at least in 3GPP. Additional addresses can be assigned, as a terminal opens additional PDP-contexts. However, it is not currently the ability to assign a prefix to a device. This was identified as an issue in Seattle, and I think there is some process to bring this issue up with 3GPP. Anyhow, I think that router functionality in a cellular terminal should be documented in a seperate document. Thanks for the comments - probably it would be good to address some of these issues face-to-face in London. cheers, 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 Fri Jul 6 01:01:46 2001 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 f6681jdP000605 for ; Fri, 6 Jul 2001 01:01:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6681jUO000604 for ipng-dist; Fri, 6 Jul 2001 01:01:45 -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 f6681edP000597 for ; Fri, 6 Jul 2001 01:01: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 BAA06928 for ; Fri, 6 Jul 2001 01:01:49 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA04369 for ; Fri, 6 Jul 2001 02:02:52 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id BAA05858 for ; Fri, 6 Jul 2001 01:01:47 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id BAA19950 for ; Fri, 6 Jul 2001 01:01:46 -0700 (MST)] Received: from beast.arc.corp.mot.com (beast.arc.corp.mot.com [10.238.80.11]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f6681i205004 for ; Fri, 6 Jul 2001 18:01:44 +1000 (EST) Received: (from kwchin@localhost) by beast.arc.corp.mot.com (8.11.2/8.10.2) id f6681gG14080 for ipng@sunroof.eng.sun.com; Fri, 6 Jul 2001 18:01:42 +1000 From: Kwan-Wu Chin Message-Id: <200107060801.f6681gG14080@beast.arc.corp.mot.com> Subject: CFP, IPDPS-2002 Workshop on PDC Issues in Wireless Networks and Mobile Computing To: ipng@sunroof.eng.sun.com Date: Fri, 6 Jul 2001 18:01:42 +1000 (EST) 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 Dear Colleague, My sincere apologies if you received multiple copies of this CFP. Regards, Kwan-Wu ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FIRST CALL FOR PAPERS 2nd International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2002 WORKSHOPS Ft. Lauderdale Marina Marriott April 15-19, 2002 **************************************************************************** Program Co-Chairs Mohan Kumar, The University of Texas at Arlington, USA C S Raghavandra, University of Southern California, Los Angeles, USA ********************************************************* GENERAL CHAIR Sajal K Das, The University of Texas at Arlington, USA ----------------------------------------------------------- Publicity Co-Chairs Kwan-Wu Chin, Motorola, Sydney, Australia Sotiris Nikoletseas, Computer Technology Institute, Patras, Greece =================================================== Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing: routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Authors are invited to submit original unpublished manuscripts for this workshop. Accepted papers will be published in the proceedings (by IEEE CS Press) of the IPDPS workshops. Topics of interest include (but are not limited to): * Processor Architectures for Mobile and Wearable Computers * Wireless networks in grid computing applications * Algorithms * Routing in ad hoc networks * Parallel and distributed techniques for solving problems in mobile computing * Distributed techniques for QoS Provisioning in wireless networks * Distributed caches in mobile computing environments * Caching, prefetching, pushcaching and replication to enhance information access in wireless networks * Distributed wireless sensor networks * Routing and location independent information access * Scheduling issues in mobile computing * Parallel/distributed algorithms for mobile computing systems * Distributed wireless multimedia systems * Active Networks SUBMISSION GUIDELINES: Authors are invited to submit summaries of original unpublished research to one of the Workshop Chairs. All submissions will be reviewed by referees. Summaries should not exceed ten (10) single-spaced pages of text using 12-point size type on 8.5 x 11 inch pages. References, figures, tables, etc., may be included in addition to the ten pages of text. The summary should include an abstract of approximately 100 words. The corresponding author is requested to include in a cover letter: (1) complete postal address; (2) email address; and (3) Phone/fax numbers. Submissions may be by hard copy or by email. Electronic submissions are preferred and should be sent to kumar@cse.uta.edu or raghu@usc.edu. Authors should submit the cover page in ASCII form followed by a PostScript (level 2) file and make sure that it will print on a PostScript printer that uses 8.5x11 inch (US letter size) paper. IMPORTANT DATES: October 30, 2001 Workshop Paper Due December 10, 2001 Notification of Acceptance/Rejection January 15, 2002 Camera-Ready Paper Due URLs: http://www.ipdps.org http://ranger.uta.edu/~kumar/ipdpswpim.html ********************************************************* For hard copy submissions, authors should submit seven (7) hard copies of their paper along with the cover letter to Mohan Kumar or C S Raghavendra All manuscripts will be reviewed. Manuscripts must be received by October 30, 2001. Submissions received after the due date or exceeding the length limit may not be considered. Notification of review decisions will be e-mailed by December 10, 2001. Camera-ready papers are due January 15, 2002. Proceedings will be available at the Conference. Workshop Program Co-Chairs Mohan Kumar Department of Computer Science and Engineering The University of Texas at Arlington Box 19015 Arlington, TX 76019-0015 Tel: 817-272-3610; Fax: 817-272-3784 E-mail: kumar@cse.uta.edu and C S Raghavendra Department of Electrical Engineering-Systems University of Southern California Los Angeles, CA 90089-2562 Tel: (213) 740-9133 Fax: (213) 740-4418 Email: raghu@usc.edu ++++++++++++++++++++++++++++++++++++++++ Technical Program Committee (Under Creation) ============================ Stefano Basagni, The University of Texas at Dallas, USA Maurizio Bonuccelli, University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA John Heidemann, USC/ISI, USA Ahmed Helmy, University of Southern California, USA Cristina Pinotti, University of Trento, Italy Paul Spirakis, Computer Technology Institute, Patras, Greece Mani Srivastava, University of California, Los Angeles, USA Martha Steenstrup, BBN Technologies, USA Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Albert Zomaya, University of Western Australia, Perth, Australia ================================================= Steering Committee (Under Creation) -------------------------------------- Victor Bahl, Microsoft, Seattle, USA Kalyan Basu, Nortel Networks, Richardson, USA Andrew Campbell, Columbia University, USA Imrich Chlamtac, The University of Texas at Dallas Sajal Das, The University of Texas at Arlington, USA ----------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 6 03:52:01 2001 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 f66Aq1dP000877 for ; Fri, 6 Jul 2001 03:52:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f66Aq1DB000876 for ipng-dist; Fri, 6 Jul 2001 03:52:01 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f66ApvdP000869 for ; Fri, 6 Jul 2001 03:51:57 -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 DAA15581 for ; Fri, 6 Jul 2001 03:52:05 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17380 for ; Fri, 6 Jul 2001 04:52: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 GAA26037; Fri, 6 Jul 2001 06:51:18 -0400 (EDT) Message-Id: <200107061051.GAA26037@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-manyfolks-ipv6-cellular-host-00.txt Date: Fri, 06 Jul 2001 06:51:17 -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 : Minimum IPv6 Functionality for a Cellular Host Author(s) : J. Arkko Filename : draft-manyfolks-ipv6-cellular-host-00.txt Pages : 22 Date : 05-Jul-01 As an increasing number of cellular hosts are being connected to the Internet, IPv6 becomes necessary. Examples of such hosts are GPRS, UMTS and CDMA2000 terminals. Standardization organizations are also making IPv6 mandatory in their newest specifications, such as IP multimedia terminals specified for UMTS. However, the concept of IPv6 covers many aspects, numerous RFCs, a number of different situations and is also still evolving. A rapid adoption of IPv6 is desired for cellular hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manyfolks-ipv6-cellular-host-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-manyfolks-ipv6-cellular-host-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-manyfolks-ipv6-cellular-host-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: <20010705114002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-manyfolks-ipv6-cellular-host-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-manyfolks-ipv6-cellular-host-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010705114002.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 Jul 9 10:52:36 2001 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 f69HqadP005327 for ; Mon, 9 Jul 2001 10:52:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f69HqZ2p005326 for ipng-dist; Mon, 9 Jul 2001 10:52: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69HqWdP005319 for ; Mon, 9 Jul 2001 10:52:32 -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 KAA28028 for ; Mon, 9 Jul 2001 10:52:43 -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 KAA04910 for ; Mon, 9 Jul 2001 10:52:42 -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 KAA03313; Mon, 9 Jul 2001 10:52:13 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f69HqDS17047; Mon, 9 Jul 2001 10:52:13 -0700 X-mProtect: Mon, 9 Jul 2001 10:52:13 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdTdoOrS; Mon, 09 Jul 2001 10:52:11 PDT Message-Id: <4.3.2.7.2.20010709104652.02176ef8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Jul 2001 10:51:06 -0700 To: IPng List From: Bob Hinden Subject: Request for Agenda Items for London IPng Sessions 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 The IPng working group has been scheduled for two sessions at the London IETF. They are: Monday, August 6 at 0900-1130 AM Wednesday, August 8 at 1300-1500 PM. Please send us requests for agenda items. When we put together the agenda we plan to give priority to current working group activities and documents, new individual submissions, and last to status reports. Thanks, Bob Hinden / Steve Deering IPng Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 9 15:19:13 2001 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 f69MJCdP005632 for ; Mon, 9 Jul 2001 15:19:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f69MJC6K005631 for ipng-dist; Mon, 9 Jul 2001 15:19:12 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69MJ9dP005624 for ; Mon, 9 Jul 2001 15:19:09 -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 PAA07562; Mon, 9 Jul 2001 15:19:18 -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 QAA04026; Mon, 9 Jul 2001 16:20:26 -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 PAA25093; Mon, 9 Jul 2001 15:19:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f69MJGi28728; Mon, 9 Jul 2001 15:19:16 -0700 X-mProtect: Mon, 9 Jul 2001 15:19:16 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdt7Cl6h; Mon, 09 Jul 2001 15:19:13 PDT Message-Id: <4.3.2.7.2.20010709151441.02181c68@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Jul 2001 15:18:34 -0700 To: Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com From: Bob Hinden Subject: Request to Advance "Unicast-Prefix-based IPv6 Multicast Addresses" Cc: scoya@ietf.org, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Proposed Standard: Title : Unicast-Prefix-based IPv6 Multicast Addresses Author(s) : B. Haberman, D. Thaler Filename : draft-ietf-ipngwg-uni-based-mcast-02.txt Pages : 5 Date : 27-Jun-01 A working group last call for this document was completed on March 13, 2001. The current draft resolves issues raised during and subsequent to the last call. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 9 15:33:27 2001 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 f69MXRdP005679 for ; Mon, 9 Jul 2001 15:33:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f69MXRYx005678 for ipng-dist; Mon, 9 Jul 2001 15: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 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 f69MXNdP005671 for ; Mon, 9 Jul 2001 15:33:23 -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 PAA25297; Mon, 9 Jul 2001 15:33:32 -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 PAA03461; Mon, 9 Jul 2001 15:33: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 PAA26189; Mon, 9 Jul 2001 15:33:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f69MXUB16110; Mon, 9 Jul 2001 15:33:30 -0700 X-mProtect: Mon, 9 Jul 2001 15:33:30 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpd6NTKKU; Mon, 09 Jul 2001 15:33:28 PDT Message-Id: <4.3.2.7.2.20010709152344.02176ef8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 09 Jul 2001 15:32:49 -0700 To: Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com From: Bob Hinden Subject: Request to Advance "A flexible method for managing the assignment of bits of an IPv6 address block" Cc: scoya@ietf.org, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : A flexible method for managing the assignment of bits of an IPv6 address block Author(s) : M. Blanchet Filename : draft-ietf-ipngwg-ipaddressassign-02.txt Pages : 13 Date : 07-Mar-01 A working group last call for this document was completed on January 30, 2001. The current draft resolves issues raised during the last call. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 9 16:13:01 2001 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 f69ND1dP005800 for ; Mon, 9 Jul 2001 16:13:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f69ND1ve005799 for ipng-dist; Mon, 9 Jul 2001 16:13:01 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69NCxdP005792 for ; Mon, 9 Jul 2001 16:12:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f69NBmI01193 for ipng@sunroof.eng.sun.com; Mon, 9 Jul 2001 16:11:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f62BR6dP023160 for ; Mon, 2 Jul 2001 04:27:06 -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 EAA27360 for ; Mon, 2 Jul 2001 04:27:13 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.140.186]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15529 for ; Mon, 2 Jul 2001 04:27:12 -0700 (PDT) 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 UAA30920; Mon, 2 Jul 2001 20:28:34 +0900 To: jinmei@isl.rdc.toshiba.co.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: summary of discussions about the semantics of sin6_scope_id In-Reply-To: References: X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Capitol Reef) 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=iso-2022-jp Content-Transfer-Encoding: 7bit Message-Id: <20010702202834X.yoshfuji@wide.ad.jp> Date: Mon, 02 Jul 2001 20:28:34 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article (at Mon, 02 Jul 2001 20:09:01 +0900), JINMEI Tatuya / $B?@L@C#:H(B says: > > 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. > > Hmm, only a few people have stated preference on this issue. I don't > think I've seen enough votes to make a decision, but we have to fix > this soon. I'm still waiting for opinions for a while, so please > speak up if anyone of you is interested in this topic. I prefer 32bit scope, not 4+28. I do not want to have two "scope-fields." in a single sockaddr{}. --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 Mon Jul 9 16:13:42 2001 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 f69NDgdP005817 for ; Mon, 9 Jul 2001 16:13:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f69NDf6M005809 for ipng-dist; Mon, 9 Jul 2001 16:13:41 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69NDddP005802 for ; Mon, 9 Jul 2001 16:13:39 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f69NCSk01223 for ipng@sunroof.eng.sun.com; Mon, 9 Jul 2001 16:12:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f64IxjdP027682 for ; Wed, 4 Jul 2001 11:59: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 LAA06371 for ; Wed, 4 Jul 2001 11:59:53 -0700 (PDT) Received: from hetnet.nl (net088s.hetnet.nl [194.151.104.184] (may be forged)) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10201 for ; Wed, 4 Jul 2001 11:59:52 -0700 (PDT) Received: from alias ([63.206.90.78]) by hetnet.nl with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 4 Jul 2001 20:56:34 +0200 Message-ID: <012601c104b9$f3c465c0$6401a8c0@alias> From: "Wilbert de Graaf" To: "Emanuel Moreira" Cc: , , References: Subject: Re: Group Membership Report Date: Wed, 4 Jul 2001 11:48:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The ipv6 equivalent of IGMP is called MLD, rfc2710. Wilbert ----- Original Message ----- From: "Emanuel Moreira" To: ; ; Sent: Tuesday, July 03, 2001 4:16 AM Subject: Group Membership Report > Can anyone tell me where can I find something about the "Group Membership Report" message? > > Thanks > > Emanuel Moreira > > _____________________________________________________________ > > O e-mail preferido dos portugueses http://www.portugalmail.pt > > --- > You are currently subscribed to msripv6-users as: w.degraaf@HETNET.NL > To unsubscribe send a blank email to leave-msripv6-users-442G@list.research.microsoft.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 Jul 9 16:14:19 2001 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 f69NEIdP005834 for ; Mon, 9 Jul 2001 16:14:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f69NEIV0005833 for ipng-dist; Mon, 9 Jul 2001 16:14:18 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f69NEFdP005826 for ; Mon, 9 Jul 2001 16:14:16 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f69ND4s01253 for ipng@sunroof.eng.sun.com; Mon, 9 Jul 2001 16:13:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f65InndP029817 for ; Thu, 5 Jul 2001 11:49: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 LAA26640 for ; Thu, 5 Jul 2001 11:49:57 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25478 for ; Thu, 5 Jul 2001 11:49:57 -0700 (PDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA11106 for ; Thu, 5 Jul 2001 11:49:56 -0700 (MST)] Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA07785 for ; Thu, 5 Jul 2001 11:49:55 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for ipng@sunroof.eng.sun.com; Thu, 5 Jul 2001 13:49:52 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id UAA21806 for ipng@sunroof.eng.sun.com.DELIVER; Thu, 5 Jul 2001 20:49:50 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id UAA21776 for ; Thu, 5 Jul 2001 20:49:49 +0200 (METDST) Cc: ipng@sunroof.eng.sun.com Subject: Re: Proxy announcement ! References: <034BEFD03799D411A59F00508BDF754603008AB0@esealnt448.al.sw.ericsson.se> From: Alexandru Petrescu Date: 05 Jul 2001 20:49:48 +0200 In-Reply-To: <034BEFD03799D411A59F00508BDF754603008AB0@esealnt448.al.sw.ericsson.se> Message-Id: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" writes: > http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt IPv6 Jumbograms rfc2675? Default Address selection? I'm struck there's nothing about QoS. You state MLD SHOULD be supported and Router Alert Option MAY be supported. Well, the former requires the latter I don't know where else is the latter needed. 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 Jul 9 23:14:01 2001 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 f6A6E1dP006226 for ; Mon, 9 Jul 2001 23:14:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6A6E1SK006225 for ipng-dist; Mon, 9 Jul 2001 23:14: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6A6DvdP006218 for ; Mon, 9 Jul 2001 23:13: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 XAA00567 for ; Mon, 9 Jul 2001 23:14:07 -0700 (PDT) From: john.loughney@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 XAA06555 for ; Mon, 9 Jul 2001 23:14: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 f6A6GpG25067 for ; Tue, 10 Jul 2001 09:16:51 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 10 Jul 2001 09:14:01 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MS471Z4>; Tue, 10 Jul 2001 09:13:51 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAED@esebe004.NOE.Nokia.com> To: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com, deering@cisco.com Cc: Jari.Arkko@ericsson.com, peter.n.hedman@ecs.ericsson.se, gerben.a.kuijpers@ted.ericsson.dk, pertti.suomela@nokia.com, juha.wiljakka@nokia.com Subject: RE: Request for Agenda Items for London IPng Sessions Date: Tue, 10 Jul 2001 09:13:48 +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 Bob, > The IPng working group has been scheduled for two sessions at > the London IETF. They are: > > Monday, August 6 at 0900-1130 AM > Wednesday, August 8 at 1300-1500 PM. > > Please send us requests for agenda items. > > When we put together the agenda we plan to give priority to > current working group activities and documents, new individual > submissions, and last to status reports. We would like time to present "Minimum IPv6 Functionality for a Cellular Host." Enclosed is the abstract & link to the draft. Abstract As an increasing number of cellular hosts are being connected to the Internet, IPv6 becomes necessary. Examples of such hosts are GPRS, UMTS and CDMA2000 terminals. Standardization organizations are also making IPv6 mandatory in their newest specifications, such as IP multimedia terminals specified for UMTS. However, the concept of IPv6 covers many aspects, numerous RFCs, a number of different situations and is also still evolving. A rapid adoption of IPv6 is desired for cellular hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manyfolks-ipv6-cellular-host-00.tx t 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 Jul 10 00:00:37 2001 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 f6A70bdP006321 for ; Tue, 10 Jul 2001 00:00:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6A70bKB006320 for ipng-dist; Tue, 10 Jul 2001 00:00: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6A70XdP006313 for ; Tue, 10 Jul 2001 00:00: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 AAA22461 for ; Tue, 10 Jul 2001 00:00:43 -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 AAA19275 for ; Tue, 10 Jul 2001 00:00:42 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6A70fu13251 for ; Tue, 10 Jul 2001 10:00:41 +0300 Date: Tue, 10 Jul 2001 10:00:41 +0300 (EEST) From: Pekka Savola To: Subject: flexible nibble assignments ["A flexible method for managing the assignment of bits of an IPv6 address block"] In-Reply-To: <4.3.2.7.2.20010709152344.02176ef8@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 Hi, This is proposed for informational, so it won't matter but I'd like to mention one consideration about address allocations that wasn't mentioned (perhaps on purpose). IPv6 address could be summarized by being like 2001:ABCD:OPQR:XYZW::/64. ABCD is something you can't change (usually). OPQR is /32 - /48, the range you most often really have to think about. XYZW is the site internal structure, also subject to some considerations (a ministrucure of all three, probably). For _clarity_ (for us hunams :), avoiding overlaps and enabling effective reverse DNS delations, I personally feel that address allocations/reservations should be done on the nibble boundary, ie. not "break a character". If this nibbles aren't broken (or even if they are), the effective area of addresses you have is actually rather limited, like CD:OPQR or just OPQR (or with current RIR scheme, PQR). -- 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 Jul 10 07:25:37 2001 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 f6AEPadP006845 for ; Tue, 10 Jul 2001 07:25:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6AEPaYj006844 for ipng-dist; Tue, 10 Jul 2001 07:25: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AEPWdP006837 for ; Tue, 10 Jul 2001 07:25:32 -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 HAA10442 for ; Tue, 10 Jul 2001 07:25:41 -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 HAA26345 for ; Tue, 10 Jul 2001 07:25: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 KAA00260; Tue, 10 Jul 2001 10:24:37 -0400 (EDT) Message-Id: <200107101424.KAA00260@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-ipv6-2260-02.txt Date: Tue, 10 Jul 2001 10:24:37 -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 multihoming support at site exit routers Author(s) : J. Hagino, H. Snyder Filename : draft-ietf-ipngwg-ipv6-2260-02.txt Pages : 11 Date : 09-Jul-01 The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently-practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-2260-02.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-ipv6-2260-02.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-ipv6-2260-02.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: <20010709103427.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-2260-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-2260-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010709103427.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 10 09:31:19 2001 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 f6AGVJdP007050 for ; Tue, 10 Jul 2001 09:31:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6AGVJ3F007049 for ipng-dist; Tue, 10 Jul 2001 09:31:19 -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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6AGVEdP007042 for ; Tue, 10 Jul 2001 09:31:14 -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 JAA07769 for ; Tue, 10 Jul 2001 09:31:24 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03718 for ; Tue, 10 Jul 2001 09:31:21 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6AGVJN01504 for ; Tue, 10 Jul 2001 18:31:19 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jul 10 18:31:12 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 10 Jul 2001 18:31:12 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008AB1@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Phil Roberts'" , ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Tue, 10 Jul 2001 18:31:08 +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 Hi Phil, I'm not an "official" author of the draft but let me address a couple of your points below in addition to John's comments. > 1. What is the intention of this document? If it is purely guidelines for > implementors it > should probably be redone as guidelines for implementors of IP v6 nodes in > 3gpp networks. If > it's input to SDOs there needs to be some rework identifying recommendations > that are > different from what has already been done or is being considered. The > document doesn't seem > to work well for either as written. This document has a lot of good > material for both but > seemed to go back and forth between the two goals. > => The intention was to address the implementation requirements for IP cellular hosts, so that excludes GSM terminals for example. The intention was not to make it specific to 3GPP since most of the reasons behind the requirements are not 3GPP specific. These are the ones mentioned in the introduction (limited power, BW, memory ...etc). However, since 3GPP is the only system currently mandating IPv6 in the architecture, in some cases exception were made for such architecture. By exception I mean evaluating whether a certain function is needed i such architecture. Of course the same can be done in future for other architectures mandating IPv6. > 2. For each of the above is the intention to educate the SDOs or the IETF? > => Cellular hosts implementors mainly ;) Interoperability is necessary and we wanted to make sure there is some kind of agreement on the implementation requirements as well as make sure nothing new will break the existing IPv6 standards. > 3. A decision probably needs to be made about what kind of host is being > considered. Again > sometimes it seems the text is for hosts that will operate only in a > cellular network and > sometimes for hosts that will operate between a cellular network and another > kind of network. > The requirements for these two kinds of hosts could be quite different. > => The functionality requirement is scenario-based. For example a host with more than one interface (in a 3GPP network) will need to implement more of the MIPv6 spec than a host with a certain interface. Rather than limiting that host architectures, the intention was to go through each function and mention when it is a MUST, SHOULD or MAY depending on the use case. But maybe that should be clarified a bit more in the doc. ? > 4. I think there was some concern at the interim meeting about the apparent > 3gpp intent to > limit cellular devices 1) to a single global address and 2) to being a host > and having no > possibility for a router function. > => I'm not sure if the draft has anything related to this particular point. The 3GPP architecture may of course change to fix these limitaitons above (I certainly hope so), but I don't see that these particular cases will impact the draft. Thanks, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 10 10:03:59 2001 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 f6AH3xdP007151 for ; Tue, 10 Jul 2001 10:03:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6AH3x3T007150 for ipng-dist; Tue, 10 Jul 2001 10:03:59 -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 f6AH3tdP007143 for ; Tue, 10 Jul 2001 10:03:55 -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 KAA26286 for ; Tue, 10 Jul 2001 10:04:06 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20938 for ; Tue, 10 Jul 2001 11:05:14 -0600 (MDT) Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 10 Jul 2001 13:03:11 -0400 Message-ID: From: Phil Roberts To: "'Hesham Soliman (ERA)'" , ipng@sunroof.eng.sun.com Subject: RE: Proxy announcement ! Date: Tue, 10 Jul 2001 13:03:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, thanks for the comments. I think this document is trying to do too much. It seems like a document focussed on recommendations for implementors of IP v6 in devices for 3gpp networks could useful right away (or at least one hopes). It could be split into sections for devices that would only operate in a 3gpp network and devices that would operate in a 3gpp network and other networks. This would assume some knowledge of the standards as they exist today. I think there is room for another document that provides recommendations for the use of IP v6 in 3g networks. The 3gpp standards will continue to evolve and the more IPv6 that is present in them, the more guidance about how to make the best use of it might be appreciated. 3gpp2 is still very nascent from my understanding and would also be a customer for such a document. There is good material for both of these kinds of customers in the existing document and material that would go in both, but I think focussing a little more would be helpful to the readers and also in moving the documents forward quickly. Phil > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:Hesham.Soliman@era.ericsson.se] > Sent: Tuesday, July 10, 2001 12:31 PM > To: 'Phil Roberts'; ipng@sunroof.eng.sun.com > Subject: RE: Proxy announcement ! > > > Hi Phil, > > I'm not an "official" author of the draft but let me > address a couple of your points below in addition to > John's comments. > > > 1. What is the intention of this document? If it is > purely guidelines for > > implementors it > > should probably be redone as guidelines for implementors of > IP v6 nodes in > > 3gpp networks. If > > it's input to SDOs there needs to be some rework > identifying recommendations > > that are > > different from what has already been done or is being > considered. The > > document doesn't seem > > to work well for either as written. This document has a lot of good > > material for both but > > seemed to go back and forth between the two goals. > > > => The intention was to address the implementation requirements > for IP cellular hosts, so that excludes GSM terminals > for example. > The intention was not to make it specific to 3GPP since > most of the > reasons behind the requirements are not 3GPP specific. These are > the ones mentioned in the introduction (limited power, > BW, memory ...etc). > However, since 3GPP is the only system currently mandating > IPv6 in the architecture, in some cases exception were made > for such architecture. By exception I mean evaluating whether > a certain function is needed i such architecture. Of course > the same can be done in future for other architectures > mandating > IPv6. > > > 2. For each of the above is the intention to educate the > SDOs or the IETF? > > > => Cellular hosts implementors mainly ;) > Interoperability is necessary and we wanted to make > sure there is > some kind of agreement on the implementation requirements > as well as make sure nothing new will break the existing IPv6 > standards. > > > 3. A decision probably needs to be made about what kind of > host is being > > considered. Again > > sometimes it seems the text is for hosts that will operate only in a > > cellular network and > > sometimes for hosts that will operate between a cellular > network and another > > kind of network. > > The requirements for these two kinds of hosts could be > quite different. > > > => The functionality requirement is scenario-based. For > example a host > with more than one interface (in a 3GPP network) will need to > implement more of the MIPv6 spec than a host with a > certain interface. > Rather than limiting that host architectures, the > intention was to go > through each function and mention when it is a MUST, > SHOULD or MAY > depending on the use case. > But maybe that should be clarified a bit more in the doc. ? > > > 4. I think there was some concern at the interim meeting > about the apparent > > 3gpp intent to > > limit cellular devices 1) to a single global address and 2) > to being a host > > and having no > > possibility for a router function. > > > => I'm not sure if the draft has anything related to > this particular > point. The 3GPP architecture may of course change to fix > these limitaitons above (I certainly hope so), but I don't see > that these particular cases will impact the draft. > > Thanks, > Hesham > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 11 07:23:17 2001 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 f6BENHdP008283 for ; Wed, 11 Jul 2001 07:23:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f6BENHY3008282 for ipng-dist; Wed, 11 Jul 2001 07:23: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.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6BEN9dP008267; Wed, 11 Jul 2001 07:23:09 -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 HAA14121; Wed, 11 Jul 2001 07:23:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23133; Wed, 11 Jul 2001 08:23:14 -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 KAA04522; Wed, 11 Jul 2001 10:22:19 -0400 (EDT) Message-Id: <200107111422.KAA04522@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, dnsop@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt Date: Wed, 11 Jul 2001 10:22: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 DNS Extensions Working Group of the IETF. Title : Tradeoffs in DNS support for IPv6 Author(s) : R. Austein Filename : draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt Pages : 10 Date : 10-Jul-01 The IETF has two different proposals on the table for how to do DNS support for IPv6, and has thus far failed to reach a clear consensus on which approach is better. This note attempts to examine the pros and cons of each approach, in the hope of clarifying the debate so that we can reach closure and move on. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-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-ietf-dnsext-ipv6-dns-tradeoffs-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-ietf-dnsext-ipv6-dns-tradeoffs-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: <20010710153838.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010710153838.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 Jul 12 11:38:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CIbxr12124 for ipng-dist; Thu, 12 Jul 2001 11:37:59 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CIbvN12117 for ; Thu, 12 Jul 2001 11:37:57 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6CIai512365 for ipng@sunroof.eng.sun.com; Thu, 12 Jul 2001 11:36:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6B6EhdP007964 for ; Tue, 10 Jul 2001 23:14: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 XAA13877 for ; Tue, 10 Jul 2001 23:14:53 -0700 (PDT) Received: from indiainfo.com ([203.199.75.248]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00167 for ; Wed, 11 Jul 2001 00:14:50 -0600 (MDT) Received: from [203.197.138.194] (account ) by indiainfo.com (CommuniGate Pro WebUser 3.4.7) with HTTP id 27119499; Wed, 11 Jul 2001 11:40:10 +0530 From: "Niveda Monyvannan" Subject: To: users@ipv6.org Cc: ipng@sunroof.eng.sun.com X-Mailer: CommuniGate Pro Web Mailer v.3.4.7 Date: Wed, 11 Jul 2001 11:40:10 +0530 Message-ID: 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 Hello, From the old IPV6 mailing list thread, i feel that except Zebra, nobody has the support for OSPFv3. Is it still holds? Regards, Niveda. ---------------------------------------- http://mail.indiainfo.com First you had 10MB of free mail space. Now you can send mails in your own language !!! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 12 11:39:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CIcUh12149 for ipng-dist; Thu, 12 Jul 2001 11:38:30 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CIcQN12141 for ; Thu, 12 Jul 2001 11:38:27 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6CIbE412396 for ipng@sunroof.eng.sun.com; Thu, 12 Jul 2001 11:37:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f6B968dP008086 for ; Wed, 11 Jul 2001 02:06:08 -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 CAA19169 for ; Wed, 11 Jul 2001 02:06:20 -0700 (PDT) Received: from zaz.kom.auc.dk (zaz.kom.auc.dk [130.225.51.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12460 for ; Wed, 11 Jul 2001 03:06:18 -0600 (MDT) Received: from lada.kom.auc.dk ([130.225.51.69] ident=gk) by zaz.kom.auc.dk with esmtp (Exim 2.05 #3) id 15KFwm-0005p6-00; Wed, 11 Jul 2001 11:06:16 +0200 Date: Wed, 11 Jul 2001 11:06:16 +0200 (MET DST) From: Gerben Kuijpers To: Alexandru Petrescu cc: ipng@sunroof.eng.sun.com Subject: Re: Proxy announcement ! 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 Thanks for your comments, response inline. ------------------------------------- On 5 Jul 2001, Alexandru Petrescu wrote: > "Hesham Soliman (ERA)" writes: > > > http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt > > IPv6 Jumbograms rfc2675? We left this RFC out, because jumbograms should not be used by cellular hosts. Maybe we should have added a section on this RFC and state there that it should not be used by cellular hosts for the following reasons: -typical cellular link MTUs are much smaller than 64k -packets larger than 64k take too long to send on the relatively slow cellular links (e.g. 64k packet on 144 kpbs link takes 3.6 seconds to send) > Default Address selection? This is discussed in section 2.16. Do you miss anything there? > I'm struck there's nothing about QoS. What did you expect to see about QoS? Is there anything IPv6 specific here? > You state MLD SHOULD be supported and Router Alert Option MAY be > supported. Well, the former requires the latter I don't know where > else is the latter needed. We state that MLD is a 'SHOULD' in case the cellular host supports multicast functionality. In that case some mechanism is needed to inform the upstream router about which multicast groups the cellular host is listening to. This mechanism would preferably be MLD, that's why: 'SHOULD'. We could add a clause that the Router Alert Option MUST be supported in case MLD is supported. The Router Alert Option is also used by RSVP. /Gerben Kuijpers -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 12 11:39:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CIcsk12171 for ipng-dist; Thu, 12 Jul 2001 11:38:54 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CIcpN12157 for ; Thu, 12 Jul 2001 11:38:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6CIbdd12426 for ipng@sunroof.eng.sun.com; Thu, 12 Jul 2001 11:37:39 -0700 (PDT) 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 f6BDPxdP008221 for ; Wed, 11 Jul 2001 06:25:59 -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 GAA03603 for ; Wed, 11 Jul 2001 06:26:06 -0700 (PDT) Received: from hotmail.com (f110.law3.hotmail.com [209.185.241.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17847 for ; Wed, 11 Jul 2001 07:27:14 -0600 (MDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Jul 2001 06:26:05 -0700 Received: from 130.225.51.45 by lw3fd.law3.hotmail.msn.com with HTTP; Wed, 11 Jul 2001 13:26:05 GMT X-Originating-IP: [130.225.51.45] From: "Gerben Kuijpers" To: Alexandru_Petrescu-AAP021@email.mot.com Cc: ipng@sunroof.eng.sun.com Subject: Fwd: RE: [Fwd: Re: Proxy announcement !] Date: Wed, 11 Jul 2001 15:26:05 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jul 2001 13:26:05.0494 (UTC) FILETIME=[0998B560:01C10A0D] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your comments, response inline. > -------- Original Message -------- > Subject: Re: Proxy announcement ! > Date: 05 Jul 2001 20:49:48 +0200 > From: Alexandru Petrescu > >>"Hesham Soliman (ERA)" writes: > > >> http://standards.ericsson.net/Hesham/draft-manyfolks-ipv6-cellular-host-00.txt > > IPv6 Jumbograms rfc2675? We left this RFC out, because jumbograms should not be used by cellular hosts. Maybe we should have added a section on this RFC and state there that it should not be used by cellular hosts for the following reasons: -typical cellular link MTUs are much smaller than 64k -packets large than 64k take too long to send on relatively slow cellular links (e.g. 64k packet on 144 kbps link takes 3.6 seconds to send) >Default Address selection? This is discussed in section 2.16. Do you miss anything there? > >I'm struck there's nothing about QoS. What did you expect to see about QoS? Is there anything specific to IPv6? > >You state MLD SHOULD be supported and Router Alert Option MAY be > >supported. Well, the former requires the latter I don't know >where > >else is the latter needed. We state that MLD is a 'SHOULD' in case the cellular host supports multicast functionality. In that case some mechanism is needed to inform the upstream router about which multicast groups the cellular host is listening to. This mechanism would preferably be MLD, that's why : 'SHOULD'. We could add a clause that the Router Alert Option MUST be supported in case MLD is supported. The Router Alert Option is also used by RSVP. /Gerben Kuijpers _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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 Jul 12 15:54:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CMs1W12869 for ipng-dist; Thu, 12 Jul 2001 15:54:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CMrvN12862 for ; Thu, 12 Jul 2001 15:53: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 PAA29755 for ; Thu, 12 Jul 2001 15:54:03 -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 QAA06347 for ; Thu, 12 Jul 2001 16:55:13 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A13AA4B20; Fri, 13 Jul 2001 07:53:50 +0900 (JST) To: "Niveda Monyvannan" Cc: users@ipv6.org, ipng@sunroof.eng.sun.com In-reply-to: niveda's message of Wed, 11 Jul 2001 11:40:10 +0530. 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: From: itojun@iijlab.net Date: Fri, 13 Jul 2001 07:53:50 +0900 Message-ID: <2783.994978430@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From the old IPV6 mailing list thread, i feel that except >Zebra, nobody has the support for OSPFv3. Is it still holds? I know of at least four implementations (demonstrated at Tokyo N+I): Ericsson/Telebit, NEC, Hitachi and Zebra. some of them may still be in beta stage (may not be available for public yet). 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 Jul 12 16:03:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6CN3KR12890 for ipng-dist; Thu, 12 Jul 2001 16:03:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6CN3HN12883 for ; Thu, 12 Jul 2001 16:03: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 QAA11532 for ; Thu, 12 Jul 2001 16:03:27 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16274 for ; Thu, 12 Jul 2001 17:03:25 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 0A72A4DD16; Thu, 12 Jul 2001 19:03:23 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA02341; Thu, 12 Jul 2001 19:03:22 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id QAA12401; Thu, 12 Jul 2001 16:03:22 -0700 (PDT) Message-Id: <200107122303.QAA12401@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: daccorne@cisco.com Subject: Re: IPv6 MIBs comments/questions Cc: ipng@sunroof.eng.sun.com Date: Thu, 12 Jul 2001 16:03:22 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dario, I'm very sorry for taking so long to reply to your questions. >Document: >http://www.aciri.org/fenner/mibs/v6/draft-ops-rfc2011-update-00.txt > >Section 4 Page 7 >ipv6InterfaceEffectiveMtu: I assume the MTU is related to the whole >packet, and not just the payload, but I would like to make sure. Honestly, I'd rather just delete this object. It's from RFC 2465, and I don't know why it would ever be different than ifMtu of the underlying interface. >Section 4 Page 9 >ipv6InterfaceIdentifierLength: The reason for the existence of this >field should be clearly stated, e.g. in what case could we have an >interface identifier length different from 64 bits? >I suggest that we get rid of this object as it doesn't seem useful. This is another "inherited object" from RFC 2465 that I don't understand either. >Section 4 Page 16 >ipAddressPrefixEntry: The purpose of this object and the related >table is not clear. Assuming that we still wish to include it in >the new MIBs, please consider the comment below. The intent is to be able to determine the source of an IP address or a set of IP addresses. e.g., if you have a unicast and an anycast address configured for each prefix, having the prefix table allows not repeating the prefix information for each address but instead allows ipAddressPrefix to point to the row in the ipAddressPrefixTable that the prefix came from. >Section 4 Page 17 >ipAddressPrefixOrigin: Besides DHCP and router advertisements, >are there any plans to include other possible sources? >An example would be AAA: should we include this in "other(1)"? Can you give an example of assigning a prefix using AAA? >Could anyone provide another example of the wellknown origin for >IPv6 prefixes? The only available example is for IPv4 autoconfig. The Link-Local prefix is well-known for IPv6. >Section 4 Page 20 >ipAddressType: The lack of a multicast type should be clarified. >I suggest that we include multicast in this object: interfaces are >likely to have multicast addresses configured and we could include >them in the table, therefore creating the need for a multicast type. > >Section 4 Page 20 >ipAddressOrigin: The lack of an origin identifier for multicast >is unclear. Could anyone please elaborate on this issue? MLD handles multicast, including statically joined groups. e.g. RFC 3019's mldCacheSelf.ff.02.00.00.00.00.00.00.00.00.00.00.00.00.00.02.1 = True to join ff02::2 on interface 1. >Section 4 Page 22 >inetNetToMediaTable: I would like to make sure that our own >interfaces, besides Neighbor Discovery information, should be >included in this table. This seems to be the case. Yes, that's the intent, with inetNetToMediaType = local(5). >Document: >http://www.aciri.org/fenner/mibs/v6/draft-ops-rfc2096-update-00.txt > >Section 4 Page 4 >inetCidrRouteEntry: It is unclear why there is no scope information >in this object. It would be useful to include scope information in >this table, besides what is already available in ipv6ScopeIdTable. >I suggest that we include scopes in this object. The idea is that the inetCidrRouteInstance handle all reasons to have multiple routes with the same prefix, including scopes. The question is how to associate meanings with values of inetCidrRouteInstance, and we haven't answered that question yet. 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 Jul 13 03:55:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DAsMc13719 for ipng-dist; Fri, 13 Jul 2001 03:54:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DAsHN13712; Fri, 13 Jul 2001 03:54:17 -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 DAA12030; Fri, 13 Jul 2001 03:54:27 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06552; Fri, 13 Jul 2001 03:54:26 -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 GAA16750; Fri, 13 Jul 2001 06:53:35 -0400 (EDT) Message-Id: <200107131053.GAA16750@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ngtrans@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com, ipng@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-00.txt Date: Fri, 13 Jul 2001 06:53:34 -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-00.txt Pages : 11 Date : 12-Jul-01 This draft outlines how Mobile IPv4 and Mobile IPv6 can work in conjunction to provide transparent L3 mobility to a dual stack mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-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-engelstad-ngtrans-mipv4-over-mipv6-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-engelstad-ngtrans-mipv4-over-mipv6-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: <20010712143753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-engelstad-ngtrans-mipv4-over-mipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-engelstad-ngtrans-mipv4-over-mipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010712143753.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 Jul 13 10:20:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6DHJMd14845 for ipng-dist; Fri, 13 Jul 2001 10:19:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6DHJFN14822 for ; Fri, 13 Jul 2001 10:19:15 -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 KAA28655 for ; Fri, 13 Jul 2001 10:19:26 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29627 for ; Fri, 13 Jul 2001 11:20:37 -0600 (MDT) 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 NAA06520 for ; Fri, 13 Jul 2001 13:19:23 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA31316 for ; Fri, 13 Jul 2001 13:19:22 -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 MAA22355 for ; Fri, 13 Jul 2001 12:27:45 -0400 Message-Id: <200107131627.MAA22355@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-temp-addresses-v2-00.txt Date: Fri, 13 Jul 2001 12:27:45 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While implementing RFC 3041 (Privacy Extensions for Stateless Address Autoconfiguration in IPv6) Rich Draves came up with a few items that we thought should be addressed in this document. So, I've just submitted an revised version of the document. From the change log: 8. Significant Changes from RFC 3041 This section summarizes the changes in this document relative to RFC 3041 that an implementer of RFC 3041 should be aware of. 1) Added wording to exclude certain interface indentifiers from the range of acceptable interface identifiers. Interface IDs such as 0, those for reserved anycast addresses [RFC 2526], etc. 2) Added a configuration nob that provides the end user with a way to enable or disable the use of temporary addresses. 3) Under RFC 3041, RAs with short lifetimes (e.g., 1 hour) that always send the same lifetime for long periods of time (e.g., days to weeks) resulted in temporary addresses being created with lifetimes of only 1 hour. Additional rules were added to increase the Lifetime of temporary addresses when the advertised lifetimes were short. 4) DAD is now run on all temporary addresses, not just the first one generated from an interface identifier. 5) Changed the default setting for usage of temporary addresses to be disabled. A copy of the ID can be found at: ftp://ftp.cs.duke.edu/pub/narten/ietf/draft-ietf-ipngwg-temp-addresses-v2-00.txt Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 15 23:03:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6G62dr19477 for ipng-dist; Sun, 15 Jul 2001 23:02:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6G62ZN19470 for ; Sun, 15 Jul 2001 23:02:35 -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 XAA00636 for ; Sun, 15 Jul 2001 23:02:46 -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 XAA25737 for ; Sun, 15 Jul 2001 23:02:45 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3F7C54B22; Mon, 16 Jul 2001 15:02:40 +0900 (JST) To: Ville Nummela Cc: users@ipv6.org, ipng@sunroof.eng.sun.com In-reply-to: ville.nummela's message of 16 Jul 2001 08:59:41 +0300. <7an165wh0y.fsf@necsom.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: From: itojun@iijlab.net Date: Mon, 16 Jul 2001 15:02:40 +0900 Message-ID: <7986.995263360@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > From the old IPV6 mailing list thread, i feel that except >> >Zebra, nobody has the support for OSPFv3. Is it still holds? >> I know of at least four implementations (demonstrated at Tokyo N+I): >> Ericsson/Telebit, NEC, Hitachi and Zebra. some of them may still >> be in beta stage (may not be available for public yet). >I believe cisco supports OSPFv3 too. I have never heard of that. if so, I'd really love to test that :-) 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 Jul 16 04:00:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GAxcr19883 for ipng-dist; Mon, 16 Jul 2001 03:59:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GAxXN19876 for ; Mon, 16 Jul 2001 03:59: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 DAA17824 for ; Mon, 16 Jul 2001 03:59:44 -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 FAA11306 for ; Mon, 16 Jul 2001 05:00:58 -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 GAA09815; Mon, 16 Jul 2001 06:58:46 -0400 (EDT) Message-Id: <200107161058.GAA09815@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-kitamura-ipv6-name-auto-reg-00.txt Date: Mon, 16 Jul 2001 06:58:45 -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 : Domain Name Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename : draft-kitamura-ipv6-name-auto-reg-00.txt Pages : 16 Date : 13-Jul-01 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-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-kitamura-ipv6-name-auto-reg-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-kitamura-ipv6-name-auto-reg-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: <20010713123934.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kitamura-ipv6-name-auto-reg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713123934.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 Jul 16 04:00:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GAxxa19901 for ipng-dist; Mon, 16 Jul 2001 03:59:59 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GAxrN19894 for ; Mon, 16 Jul 2001 03:59: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 EAA22744 for ; Mon, 16 Jul 2001 04:00:05 -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 FAA11407 for ; Mon, 16 Jul 2001 05:01:19 -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 GAA09912; Mon, 16 Jul 2001 06:59:09 -0400 (EDT) Message-Id: <200107161059.GAA09912@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-huitema-ipv6-renumber-00.txt Date: Mon, 16 Jul 2001 06:59:09 -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 : IPv6 Site Renumbering Author(s) : C. Huitema Filename : draft-huitema-ipv6-renumber-00.txt Pages : 7 Date : 13-Jul-01 There has been recently a lot of the discussion in the IPNG, NGTRANS and DNSEXT working group about the level at which IPv6 shall support renumbering. A specific question is whether we need special support in the DNS to enable renumbering, as specified in [RFC2874], or if the simpler mechanisms specified in [RFC1886] are sufficient. In order to organize the discussion, this memo presents a set of realistic renumbering scenarios, discusses the possible frequency at which such scenarios can be repeated, presents some tools that can be used to organize the renumbering, and summarizes the operational requirements that have to be met by any renumbering solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huitema-ipv6-renumber-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-huitema-ipv6-renumber-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-huitema-ipv6-renumber-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: <20010713124015.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-huitema-ipv6-renumber-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-huitema-ipv6-renumber-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010713124015.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 Jul 16 09:14:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GGDlF20779 for ipng-dist; Mon, 16 Jul 2001 09:13:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GGDiN20772 for ; Mon, 16 Jul 2001 09:13:44 -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 JAA03709 for ; Mon, 16 Jul 2001 09:13:56 -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 JAA13670 for ; Mon, 16 Jul 2001 09:13:55 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6GGDsk21180 for ; Mon, 16 Jul 2001 19:13:54 +0300 Date: Mon, 16 Jul 2001 19:13:53 +0300 (EEST) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-kitamura-ipv6-name-auto-reg-00.txt In-Reply-To: <200107161058.GAA09815@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 Mon, 16 Jul 2001 Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > Title : Domain Name Auto-Registration for Plugged-in IPv6 Some thoughts, The text has, in 3.5: --- All candidate information (detected addresses) for registration is checked by using inverse DNS resolving queries of them. If there is FQDN information that matches the detected address, such registration candidates are not registered. --- There are problems with similar to "file locking" with this approach. They could be minimized a little if the inverse query MUST be authorative, ie. the response MUST not be cached, perhaps? I'm also worried about possible DoS considerations of the auto-reg method, as it assumes DAD packets always signify a new address; nothing prevents a malicious node from generating thousands of them. This is addressed to some extent in the draft. Another issue DAD as a method of detecting new node in itself. There have been some discussions that you might not need to perform DAD for EUI64-based addresses. This would change the detector balance (and working methods) considerably. In addition, it's not necessary to perform DAD (at the moment) but for just the addresses with different host-id. Multihoming or multiaddressing considerations could change how this works a bit. Detectors and Registrars should have (an optional) ability to decide whether the address has been spoofed. For example: registrar 1 has detectors A and B, from networks (separate links) 3ffe:ffff:0:A::/64 and 3ffe:ffff:0:B::/64, respectively. HostA registers an address from network B, and registrar 1, being allowed to make the changes dor both network blocks, happily complies. Detectors or Registrars have no way of knowing whether 1) DAD produced a collision, or 2) "autoconfiguration worked fine and the system is globally available". I'm not sure if this is actually a really big problem, but one more straw to the "disallow source spoofing" hat. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 16 09:31:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GGUZJ20834 for ipng-dist; Mon, 16 Jul 2001 09:30:35 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GGUXN20825 for ; Mon, 16 Jul 2001 09:30:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6GGTJD14204 for ipng@sunroof.eng.sun.com; Mon, 16 Jul 2001 09:29:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6G600N19455 for ; Sun, 15 Jul 2001 23:00:00 -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 XAA00287 for ; Sun, 15 Jul 2001 23:00:09 -0700 (PDT) Received: from mail.services.necsom.com (mail.necsom.com [195.197.180.67]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25201 for ; Sun, 15 Jul 2001 23:00:08 -0700 (PDT) Received: from tina.necsom.com (root@[192.168.2.34]) by mail.services.necsom.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id IAA09569; Mon, 16 Jul 2001 08:59:34 +0300 X-Authentication-Warning: mail.services.necsom.com: Host root@[192.168.2.34] claimed to be tina.necsom.com Received: (from vnummela@localhost) by tina.necsom.com (8.9.3/8.9.3/Debian 8.9.3-21) id IAA01617; Mon, 16 Jul 2001 08:59:41 +0300 To: itojun@iijlab.net Cc: "Niveda Monyvannan" , users@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: References: <2783.994978430@itojun.org> X-Face: "Df%ff/A[8\G2b3+^!5to-ud=~>-GK'R3S00Csb"a2XD}:"E8Y(ZS4|d#5d!]Y];+I+8(L;jzZM`?M5$QkA>C@"?Y5@&^):)@<_S|q_*v$dgZYh%-Kw<_g,9pmme24Zr|d;dvwK}}.1,K!uP)/mX\=1IhOn7Lvr=k$">br]sxlslZ8m%g,v'y/l`X5oObnS)C^q<:DTgvV^|&`QuPHF]YZJ8`q|z^mkeP,.['pv1eMZzflI4RE|1}t&{Pp'c-M;t~@T2L$$YtuFzM$`P~aN48_ohw:KbSYPvx]:IBS`\g From: Ville Nummela Date: 16 Jul 2001 08:59:41 +0300 In-Reply-To: <2783.994978430@itojun.org> (itojun@iijlab.net's message of "Fri, 13 Jul 2001 07:53:50 +0900") Message-ID: <7an165wh0y.fsf@necsom.com> Lines: 14 User-Agent: Gnus/5.090002 (Oort Gnus v0.02) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > > From the old IPV6 mailing list thread, i feel that except > >Zebra, nobody has the support for OSPFv3. Is it still holds? > I know of at least four implementations (demonstrated at Tokyo N+I): > Ericsson/Telebit, NEC, Hitachi and Zebra. some of them may still > be in beta stage (may not be available for public yet). I believe cisco supports OSPFv3 too. -- | ville.nummela@necsom.com tel: +358-40-8480344 | So Linus, what are we doing tonight? | The same thing we do every night Tux. Try to take over the 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 Mon Jul 16 09:31:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GGVGg20843 for ipng-dist; Mon, 16 Jul 2001 09:31:16 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GGVEN20836 for ; Mon, 16 Jul 2001 09:31:14 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6GGU0114235 for ipng@sunroof.eng.sun.com; Mon, 16 Jul 2001 09:30:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6G7CBN19636 for ; Mon, 16 Jul 2001 00:12:11 -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 AAA27683 for ; Mon, 16 Jul 2001 00:12:22 -0700 (PDT) Received: from mail.services.necsom.com (mail.necsom.com [195.197.180.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08697 for ; Mon, 16 Jul 2001 00:12:21 -0700 (PDT) Received: from tina.necsom.com (root@[192.168.2.34]) by mail.services.necsom.com (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA10087; Mon, 16 Jul 2001 10:12:08 +0300 X-Authentication-Warning: mail.services.necsom.com: Host root@[192.168.2.34] claimed to be tina.necsom.com Received: (from vnummela@localhost) by tina.necsom.com (8.9.3/8.9.3/Debian 8.9.3-21) id KAA03303; Mon, 16 Jul 2001 10:12:15 +0300 To: itojun@iijlab.net Cc: Ville Nummela , users@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: References: <7986.995263360@itojun.org> X-Face: "Df%ff/A[8\G2b3+^!5to-ud=~>-GK'R3S00Csb"a2XD}:"E8Y(ZS4|d#5d!]Y];+I+8(L;jzZM`?M5$QkA>C@"?Y5@&^):)@<_S|q_*v$dgZYh%-Kw<_g,9pmme24Zr|d;dvwK}}.1,K!uP)/mX\=1IhOn7Lvr=k$">br]sxlslZ8m%g,v'y/l`X5oObnS)C^q<:DTgvV^|&`QuPHF]YZJ8`q|z^mkeP,.['pv1eMZzflI4RE|1}t&{Pp'c-M;t~@T2L$$YtuFzM$`P~aN48_ohw:KbSYPvx]:IBS`\g From: Ville Nummela Date: 16 Jul 2001 10:12:14 +0300 In-Reply-To: <7986.995263360@itojun.org> (itojun@iijlab.net's message of "Mon, 16 Jul 2001 15:02:40 +0900") Message-ID: <7aelrhwdo1.fsf@necsom.com> Lines: 18 User-Agent: Gnus/5.090002 (Oort Gnus v0.02) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > >> > From the old IPV6 mailing list thread, i feel that except > >> >Zebra, nobody has the support for OSPFv3. Is it still holds? > >> I know of at least four implementations (demonstrated at Tokyo N+I): > >> Ericsson/Telebit, NEC, Hitachi and Zebra. some of them may still > >> be in beta stage (may not be available for public yet). > >I believe cisco supports OSPFv3 too. > I have never heard of that. if so, I'd really love to test that :-) Well, I should've checked before writing.. I thought they had support as I've seen some slides talking about it; however checking ciscos website revealed that it isn't ready yet :-/ -- | ville.nummela@necsom.com tel: +358-40-8480344 | So Linus, what are we doing tonight? | The same thing we do every night Tux. Try to take over the 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 Mon Jul 16 09:32:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GGVkV20864 for ipng-dist; Mon, 16 Jul 2001 09:31:46 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GGVhN20857 for ; Mon, 16 Jul 2001 09:31:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6GGUTu14265 for ipng@sunroof.eng.sun.com; Mon, 16 Jul 2001 09:30:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6G7ffN19680 for ; Mon, 16 Jul 2001 00:41: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 AAA05416 for ; Mon, 16 Jul 2001 00:41:53 -0700 (PDT) Received: from www0a.netaddress.usa.net (www0a.netaddress.usa.net [204.68.24.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA19341 for ; Mon, 16 Jul 2001 00:41:52 -0700 (PDT) Received: (qmail 3582 invoked by uid 60001); 16 Jul 2001 07:41:49 -0000 Message-ID: <20010716074149.3579.qmail@www0a.netaddress.usa.net> Received: from 204.68.24.30 by www0a for [203.200.15.20] via web-mailer(34FM.0700.18.03B) on Mon Jul 16 07:41:48 GMT 2001 Date: 16 Jul 2001 13:11:48 IST From: Prema M P To: ipng@sunroof.eng.sun.com Subject: MTU issue X-Mailer: USANET web-mailer (34FM.0700.18.03B) 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 f6G7ffN19681 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, can anybody answer me...?? If MTU value is set for a node/host in a (ethernet)network, Is it applicable to both Incoming and outgoing packets.. Thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 16 13:42:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6GKfw521734 for ipng-dist; Mon, 16 Jul 2001 13:41:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6GKfsN21727 for ; Mon, 16 Jul 2001 13:41: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 NAA08024 for ; Mon, 16 Jul 2001 13:42:06 -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 OAA06810 for ; Mon, 16 Jul 2001 14:43:21 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6GKg0222559; Mon, 16 Jul 2001 23:42:00 +0300 Date: Mon, 16 Jul 2001 23:42:00 +0300 (EEST) From: Pekka Savola To: Prema M P cc: Subject: Re: MTU issue In-Reply-To: <20010716074149.3579.qmail@www0a.netaddress.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 16 Jul 2001, Prema M P wrote: > can anybody answer me...?? If MTU value is set for a node/host in a > (ethernet)network, Is it applicable to both Incoming and outgoing packets.. Only outgoing. -- 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 Jul 17 03:50:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HAnrM23389 for ipng-dist; Tue, 17 Jul 2001 03:49:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HAnnN23382 for ; Tue, 17 Jul 2001 03:49:49 -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 DAA22359 for ; Tue, 17 Jul 2001 03:50:00 -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 EAA23545 for ; Tue, 17 Jul 2001 04:51:15 -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 GAA09241; Tue, 17 Jul 2001 06:49:04 -0400 (EDT) Message-Id: <200107171049.GAA09241@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-ipv6-anycast-analysis-00.txt Date: Tue, 17 Jul 2001 06:49:04 -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 : 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 The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] defined as of today. The goals of the draft are (1) to understand the currently-defined IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-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-ietf-ipngwg-ipv6-anycast-analysis-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-ietf-ipngwg-ipv6-anycast-analysis-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: <20010716153037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153037.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 17 07:22:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HELDh24050 for ipng-dist; Tue, 17 Jul 2001 07:21:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HEL9N24043 for ; Tue, 17 Jul 2001 07:21:09 -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 HAA16251 for ; Tue, 17 Jul 2001 07:21:20 -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 HAA18029 for ; Tue, 17 Jul 2001 07:21:18 -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 KAA14621; Tue, 17 Jul 2001 10:20:22 -0400 (EDT) Message-Id: <200107171420.KAA14621@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-p2p-pingpong-00.txt Date: Tue, 17 Jul 2001 10:20:22 -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 : Avoiding ping-pong packets on point-to-point links Author(s) : J. Hagino et al. Filename : draft-ietf-ipngwg-p2p-pingpong-00.txt Pages : 5 Date : 16-Jul-01 In IPv6 point-to-point link operation, there is a significant possibility of aberrant behavior in that packets may ping-pong between the two ends of the link. The problem can lead to wasted bandwidth and can possibly be abused by malicious parties. This document provides an analysis and solution to the problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-p2p-pingpong-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-ietf-ipngwg-p2p-pingpong-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-ietf-ipngwg-p2p-pingpong-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: <20010716153048.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-p2p-pingpong-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-p2p-pingpong-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010716153048.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 17 08:42:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HFfak24255 for ipng-dist; Tue, 17 Jul 2001 08:41:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HFfWN24248 for ; Tue, 17 Jul 2001 08:41:33 -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 IAA03831 for ; Tue, 17 Jul 2001 08:41:44 -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 JAA18922 for ; Tue, 17 Jul 2001 09:42:58 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6HFfen28036 for ; Tue, 17 Jul 2001 18:41:41 +0300 Date: Tue, 17 Jul 2001 18:41:40 +0300 (EEST) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-ietf-ipngwg-p2p-pingpong-00.txt In-Reply-To: <200107171420.KAA14621@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 Tue, 17 Jul 2001 Internet-Drafts@ietf.org wrote: > Title : Avoiding ping-pong packets on point-to-point links Assuming the scenario in the above: Router B |P::b | | Point-to-point link, P::/64 | |P::a Router A If some nastie sent a packet with source= P::c, destination P::d, you might end up in an endless ping-pong loop of ICMP error messages, or...? (does the "no icmp error sent due to received icmp error" prevent this?) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 17 12:08:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6HJ7fL25103 for ipng-dist; Tue, 17 Jul 2001 12:07:41 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HJ7YN25096 for ; Tue, 17 Jul 2001 12:07:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6HJ6I316397 for ipng@sunroof.eng.sun.com; Tue, 17 Jul 2001 12:06:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HHNpN24527; Tue, 17 Jul 2001 10:23: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 KAA23464; Tue, 17 Jul 2001 10:22:32 -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 KAA13214; Tue, 17 Jul 2001 10:22:26 -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 NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Subject: Note Well Date: Tue, 17 Jul 2001 13:16:53 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 17 18:16:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I1Ed925675 for ipng-dist; Tue, 17 Jul 2001 18:14:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I1EXN25668; Tue, 17 Jul 2001 18:14: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 SAA10465; Tue, 17 Jul 2001 18:14:46 -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 TAA02021; Tue, 17 Jul 2001 19:14:44 -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 SAA02041; Tue, 17 Jul 2001 18:14:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6I1Eiq02453; Tue, 17 Jul 2001 18:14:44 -0700 X-mProtect: Tue, 17 Jul 2001 18:14:44 -0700 Nokia Silicon Valley Messaging Protection Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd0PyQlU; Tue, 17 Jul 2001 18:14:43 PDT Message-ID: <3B54E304.30467CD6@iprg.nokia.com> Date: Tue, 17 Jul 2001 18:14:44 -0700 From: Theo Pagtzis Reply-To: tpagtzis@iprg.nokia.com Organization: UCL/NOKIA X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: mobile-ip@sunroof.eng.sun.com Subject: Neighbour discovery proactive state and routing neighbourhood References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, we would appreciate people's feedback on the discovery process and mapping of the mobility neighbourhood onto the correct routing neighbourhood for the purpose of establishing IP state in a forward manner. On the particular, issue we would like to hear the views of people on introducing a new state in the Neighbour Discovery process, the one of PROACTIVELY REACHABLE, in the light of extending Neighbour Discovery to tackle proactive mobility. The two issues are discussed in detail in draft-pagtzis-mobileip-proactivev6-00.txt/.ps (the .ps file can be found in (http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html)) Thanks Theo UCL/ Mobile Systems -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 17 18:19:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I1JBP25719 for ipng-dist; Tue, 17 Jul 2001 18:19:11 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I1J6N25712 for ; Tue, 17 Jul 2001 18:19:06 -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 SAA06977 for ; Tue, 17 Jul 2001 18:19:19 -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 SAA07257 for ; Tue, 17 Jul 2001 18:19:17 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:9918:3b71:81c:625]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA28498; Wed, 18 Jul 2001 10:21:04 +0900 (JST) Date: Wed, 18 Jul 2001 10:19:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Subject: Re: I-D ACTION:draft-ietf-ipngwg-p2p-pingpong-00.txt In-Reply-To: References: <200107171420.KAA14621@ietf.org> 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: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 17 Jul 2001 18:41:40 +0300 (EEST), >>>>> Pekka Savola said: > Assuming the scenario in the above: > Router B > |P::b > | > | Point-to-point link, P::/64 > | > |P::a > Router A > If some nastie sent a packet with source= P::c, destination P::d, you > might end up in an endless ping-pong loop of ICMP error messages, or...? > (does the "no icmp error sent due to received icmp error" prevent this?) Yes, it is. Additionally, even if we did not have the rule, we would not see such infinite iteration of icmp6 errors, because the source address of the error packet from Router B would P::b, which is a perfectly legal address. We would only see one more error. 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 Jul 18 00:25:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I7P5026095 for ipng-dist; Wed, 18 Jul 2001 00:25:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I7P1N26088 for ; Wed, 18 Jul 2001 00:25:01 -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 AAA11371 for ; Wed, 18 Jul 2001 00:25:14 -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 BAA20742 for ; Wed, 18 Jul 2001 01:26:28 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6I7P8s19914; Wed, 18 Jul 2001 10:25:08 +0300 Date: Wed, 18 Jul 2001 10:25:07 +0300 (EEST) From: Pekka Savola To: Prema M P cc: Subject: Re: Thank you.. In-Reply-To: <20010718071105.26459.qmail@nwcst292.netaddress.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 18 Jul 2001, Prema M P wrote: > Scenario 1: > Node 2 > | 1480 > 1300 | > --- Router ------------------------- > | > | 1480 > Node 1 > > Is Node1 be able to send pkts of size 1480 to Node2 or Router ?? Yes. Traffic back from Router is at most 1300 bytes long, though. > Scenario 2: > Node 3 Node 2 > 1500 | | 1480 > | 1500 1500 | > ------------------------------Router ------------------------- > | > | 1300 > Node 1 > > If node3 needs to send pkts to node 1, will Node 1 (IP layer) be able to > receive pkts of size 1500 ?? > or If there is fragmentation, what will be the fragmented packets size?? Node1 can receive the packets unfragmented. Additional scenario 3: Node 3 Node 2 1500 | | 1480 | 1500 1300 | ------------------------------Router ------------------------- | | 1500 Node 1 Now, if Node3 tries to send to Node1, Path MTU discovery happens and Node3 will only send with MTU of 1300. Or if there is fragmentation, it is done by end nodes with fragmentation header. If Node2 wanted to communicate with Node3 or Node1, MTU of 1480 would be used to that direction, and 1300 or 1500 back, respectively. -- 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 Jul 18 00:35:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6I7Ygk26116 for ipng-dist; Wed, 18 Jul 2001 00:34:42 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I7YcN26109 for ; Wed, 18 Jul 2001 00:34:38 -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 AAA20615 for ; Wed, 18 Jul 2001 00:34:50 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29939 for ; Wed, 18 Jul 2001 01:34:48 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 55A464B21; Wed, 18 Jul 2001 16:34:45 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Pekka Savola , ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Wed, 18 Jul 2001 10:19:08 +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: I-D ACTION:draft-ietf-ipngwg-p2p-pingpong-00.txt From: itojun@iijlab.net Date: Wed, 18 Jul 2001 16:34:45 +0900 Message-ID: <5996.995441685@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> If some nastie sent a packet with source= P::c, destination P::d, you >> might end up in an endless ping-pong loop of ICMP error messages, or...? >> (does the "no icmp error sent due to received icmp error" prevent this?) > >Yes, it is. Additionally, even if we did not have the rule, we would >not see such infinite iteration of icmp6 errors, because the source >address of the error packet from Router B would P::b, which is >a perfectly legal address. We would only see one more error. to illustrate the situation better, it should be like this. (correct me if I'm wrong) itojun without the behavior change on the draft: router A -> router B src=P::c, dst=P::d, TTL=x (original packet) router B -> router A src=P::c, dst=P::d, TTL=x - 1 (original packet) .... (forward until TTL reaches 0) with the behavior change on the draft: router A -> router B src=P::c, dst=P::d (original packet) (router B detects the anomaly on forwarding, and suppress the packet forwarding and raise address unreachable) router B -> router A src=P::b, dst=P::c, icmp6 address unreachable (there'll be no response, 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 Wed Jul 18 03:59:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IAwKP26667 for ipng-dist; Wed, 18 Jul 2001 03:58:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IAwCN26646 for ; Wed, 18 Jul 2001 03:58:12 -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 DAA27783 for ; Wed, 18 Jul 2001 03:58:23 -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 EAA20369 for ; Wed, 18 Jul 2001 04:59:32 -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 GAA24777; Wed, 18 Jul 2001 06:57:19 -0400 (EDT) Message-Id: <200107181057.GAA24777@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-dns-discovery-analysis-00.txt Date: Wed, 18 Jul 2001 06:57:19 -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 : Analysis of DNS Server Discovery Mechanisms for IPv6 Author(s) : D. Thaler Filename : draft-ietf-ipngwg-dns-discovery-analysis-00.txt Pages : 42 Date : 17-Jul-01 There are any number of ways that IPv6 hosts can discover information required to enable name resolution, in the absence of a DHCP server. This document discusses the issues and provides a taxonomy of possible solutions, and evaluates them against various design criteria. Finally, it provides recommendations as input to the standards process. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-analysis-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-ietf-ipngwg-dns-discovery-analysis-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-ietf-ipngwg-dns-discovery-analysis-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: <20010717132855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-discovery-analysis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-discovery-analysis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132855.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 18 03:59:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IAwO026675 for ipng-dist; Wed, 18 Jul 2001 03:58:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IAwEN26655 for ; Wed, 18 Jul 2001 03:58: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 DAA26181 for ; Wed, 18 Jul 2001 03:58:26 -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 EAA20445 for ; Wed, 18 Jul 2001 04:59:43 -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 GAA24838; Wed, 18 Jul 2001 06:57:29 -0400 (EDT) Message-Id: <200107181057.GAA24838@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-rfc2011-update-00.txt Date: Wed, 18 Jul 2001 06:57:29 -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 : Management Information Base for the Internet Protocol (IP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipngwg-rfc2011-update-00.txt Pages : 62 Date : 17-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2011-update-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-ietf-ipngwg-rfc2011-update-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-ietf-ipngwg-rfc2011-update-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: <20010717132913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2011-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2011-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132913.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 18 03:59:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IAwRc26676 for ipng-dist; Wed, 18 Jul 2001 03:58:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IAwJN26668 for ; Wed, 18 Jul 2001 03:58: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 DAA27796 for ; Wed, 18 Jul 2001 03:58:31 -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 DAA15059 for ; Wed, 18 Jul 2001 03:58:29 -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 GAA24855; Wed, 18 Jul 2001 06:57:34 -0400 (EDT) Message-Id: <200107181057.GAA24855@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-rfc2012-update-00.txt Date: Wed, 18 Jul 2001 06:57:34 -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 : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipngwg-rfc2012-update-00.txt Pages : 21 Date : 17-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) [5] in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2012-update-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-ietf-ipngwg-rfc2012-update-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-ietf-ipngwg-rfc2012-update-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: <20010717132922.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2012-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2012-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132922.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 18 03:59:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IAwDm26652 for ipng-dist; Wed, 18 Jul 2001 03:58:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IAw9N26638 for ; Wed, 18 Jul 2001 03:58: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 DAA09756 for ; Wed, 18 Jul 2001 03:58:20 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14446 for ; Wed, 18 Jul 2001 03:58:19 -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 GAA24808; Wed, 18 Jul 2001 06:57:24 -0400 (EDT) Message-Id: <200107181057.GAA24808@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-rfc2096-update-00.txt Date: Wed, 18 Jul 2001 06:57:24 -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 : IP Forwarding Table MIB Author(s) : B. Fenner et al. Filename : draft-ietf-ipngwg-rfc2096-update-00.txt Pages : 31 Date : 17-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2096-update-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-ietf-ipngwg-rfc2096-update-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-ietf-ipngwg-rfc2096-update-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: <20010717132904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2096-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2096-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132904.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 18 03:59:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IAwdS26693 for ipng-dist; Wed, 18 Jul 2001 03:58:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IAwVN26678 for ; Wed, 18 Jul 2001 03:58: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 DAA26199 for ; Wed, 18 Jul 2001 03:58:42 -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 DAA15159 for ; Wed, 18 Jul 2001 03:58:41 -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 GAA24900; Wed, 18 Jul 2001 06:57:46 -0400 (EDT) Message-Id: <200107181057.GAA24900@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-rfc2013-update-00.txt Date: Wed, 18 Jul 2001 06:57:46 -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 : Management Information Base for the User Datagram Protocol (UDP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipngwg-rfc2013-update-00.txt Pages : 14 Date : 17-Jul-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) [4] in an IP version independent manner A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2013-update-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-ietf-ipngwg-rfc2013-update-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-ietf-ipngwg-rfc2013-update-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: <20010717132932.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2013-update-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2013-update-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132932.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 18 03:59:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IAwiV26694 for ipng-dist; Wed, 18 Jul 2001 03:58:44 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IAwaN26686 for ; Wed, 18 Jul 2001 03:58:36 -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 DAA26217 for ; Wed, 18 Jul 2001 03:58:48 -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 FAA20635 for ; Wed, 18 Jul 2001 05:00:05 -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 GAA24916; Wed, 18 Jul 2001 06:57:51 -0400 (EDT) Message-Id: <200107181057.GAA24916@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-temp-addresses-v2-00.txt Date: Wed, 18 Jul 2001 06:57:51 -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 : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, R. Draves Filename : draft-ietf-ipngwg-temp-addresses-v2-00.txt Pages : 19 Date : 17-Jul-01 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a Dynamic Host Configuration Protocol (DHCP) server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-temp-addresses-v2-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-ietf-ipngwg-temp-addresses-v2-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-ietf-ipngwg-temp-addresses-v2-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: <20010717132941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-temp-addresses-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-temp-addresses-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132941.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 18 12:18:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6IJHpn28404 for ipng-dist; Wed, 18 Jul 2001 12:17:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6IJHlN28397 for ; Wed, 18 Jul 2001 12:17:47 -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 MAA26788 for ; Wed, 18 Jul 2001 12:17:55 -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 MAA24332 for ; Wed, 18 Jul 2001 12:17:55 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11397; Wed, 18 Jul 2001 15:17:54 -0400 Date: Wed, 18 Jul 2001 15:17:54 -0400 (EDT) From: Jim Bound To: ipng@sunroof.eng.sun.com Subject: IEEE Base Spec out for Review Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Folks, See attached pointer and please review. This is it folks. This will be the base api. I was at U.S. Navy and other Department of Defense IPv6 seminar last week as IPv6 Forum Chair of the Technical Directorate (wearing that hat) and other talks by IPv6 vendors shipping IPv6 products (e.g. Compaq, Cisco, IBM, Sun, HP). One of the talks was by Sendmail.Inc they complained big time about us changing the base API and were totally correct. I have gotten this complaint from others too doing public domain software that is used in the market. Also several ISVs have voiced concerns. We must take this work attached and move it forward. Future or other extensions can be developed but the base API is now done and the authors will start editing once this mail thread has some time on the list. But lets wrap this up before the London IETF meeting. We all owe Jack McCann a big thanks for working the IEEE efforts. This was a lot of work. Thanks /jim ------------------------------- Web Page URL: Jim http://www.opengroup.org/austin/login.html Login Name: ieee.balloter (note: this is case sensitive) Password: ieeedraft4 (note: this is case sensitive) regards Andrew > -----Original Message----- > From: Andrew Josey [mailto:ajosey@rdg.opengroup.org] > Sent: Wednesday, July 18, 2001 3:09 AM > To: Bound, Jim > Cc: a.gollan@opengroup.org; McCann, John > Subject: Austin Group Status > > > Hello Jim > > Jack McCann asked me to touch base with you regarding the > Austin Group specifications. Draft 7 is now available > on the web site since June 15, and is the proposed final > text draft. We will not be making any further normative > changes and will be submitting this draft to the standards > approval boards , targeting approval in September. > Any further issues beyond this point will go into the bucket > for consideration for Technical Corrigendum number 1. > best regards > Andrew > > > ----- > Andrew Josey The Open Group > Director, Server Platforms Apex Plaza,Forbury Road, > Email: a.josey@opengroup.org Reading,Berks.RG1 > 1AX,England > Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 > Mobile: +44 774 015 5794 > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 18 16:17:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6INH3f28972 for ipng-dist; Wed, 18 Jul 2001 16:17:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6INGwN28964 for ; Wed, 18 Jul 2001 16:16: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 QAA09901 for ; Wed, 18 Jul 2001 16:17:09 -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 RAA19454 for ; Wed, 18 Jul 2001 17:18:24 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 5F18E4B22; Thu, 19 Jul 2001 08:16:59 +0900 (JST) To: Jim Bound Cc: ipng@sunroof.eng.sun.com In-reply-to: seamus's message of Wed, 18 Jul 2001 15:17:54 -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: IEEE Base Spec out for Review From: itojun@iijlab.net Date: Thu, 19 Jul 2001 08:16:59 +0900 Message-ID: <14788.995498219@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I was at U.S. Navy and other Department of Defense IPv6 seminar last week >as IPv6 Forum Chair of the Technical Directorate (wearing that hat) and >other talks by IPv6 vendors shipping IPv6 products (e.g. Compaq, Cisco, >IBM, Sun, HP). One of the talks was by Sendmail.Inc they complained big >time about us changing the base API and were totally correct. I have >gotten this complaint from others too doing public domain software that is >used in the market. Also several ISVs have voiced concerns. We must take sorry, just to clarify - what part of change do you mean by "got complaint about *changing* the base API"? there were a couple of changes since RFC2553... 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 Jul 18 21:51:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J4pJe00779 for ipng-dist; Wed, 18 Jul 2001 21:51:19 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J4pF000772 for ; Wed, 18 Jul 2001 21:51:15 -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 VAA20957 for ; Wed, 18 Jul 2001 21:51:28 -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 VAA10540 for ; Wed, 18 Jul 2001 21:51:27 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA20961; Thu, 19 Jul 2001 00:51:23 -0400 Date: Thu, 19 Jul 2001 00:51:23 -0400 (EDT) From: Jim Bound To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: IEEE Base Spec out for Review In-Reply-To: <14788.995498219@itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk they were talking all the way back to rfc2133....not just 2553. mostly the get* stuff we kept changing. /jim On Thu, 19 Jul 2001 itojun@iijlab.net wrote: > > >I was at U.S. Navy and other Department of Defense IPv6 seminar last week > >as IPv6 Forum Chair of the Technical Directorate (wearing that hat) and > >other talks by IPv6 vendors shipping IPv6 products (e.g. Compaq, Cisco, > >IBM, Sun, HP). One of the talks was by Sendmail.Inc they complained big > >time about us changing the base API and were totally correct. I have > >gotten this complaint from others too doing public domain software that is > >used in the market. Also several ISVs have voiced concerns. We must take > > sorry, just to clarify - what part of change do you mean by > "got complaint about *changing* the base API"? there were a couple > of changes since RFC2553... > > 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 Jul 18 21:52:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J4q3r00797 for ipng-dist; Wed, 18 Jul 2001 21:52:03 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J4px000788 for ; Wed, 18 Jul 2001 21:51: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 VAA21018 for ; Wed, 18 Jul 2001 21:52:12 -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 WAA21925 for ; Wed, 18 Jul 2001 22:52:10 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26902; Thu, 19 Jul 2001 00:52:09 -0400 Date: Thu, 19 Jul 2001 00:52:09 -0400 (EDT) From: Jim Bound To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: IEEE Base Spec out for Review In-Reply-To: <14788.995498219@itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk also they implemented the model where AF_INET6 is used to for both v6 and v4mapped. /jim On Thu, 19 Jul 2001 itojun@iijlab.net wrote: > > >I was at U.S. Navy and other Department of Defense IPv6 seminar last week > >as IPv6 Forum Chair of the Technical Directorate (wearing that hat) and > >other talks by IPv6 vendors shipping IPv6 products (e.g. Compaq, Cisco, > >IBM, Sun, HP). One of the talks was by Sendmail.Inc they complained big > >time about us changing the base API and were totally correct. I have > >gotten this complaint from others too doing public domain software that is > >used in the market. Also several ISVs have voiced concerns. We must take > > sorry, just to clarify - what part of change do you mean by > "got complaint about *changing* the base API"? there were a couple > of changes since RFC2553... > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 18 23:36:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J6aL800936 for ipng-dist; Wed, 18 Jul 2001 23:36:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J6aH000929 for ; Wed, 18 Jul 2001 23:36:17 -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 XAA01629 for ; Wed, 18 Jul 2001 23:36:30 -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 AAA15194 for ; Thu, 19 Jul 2001 00:37:48 -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 f6J6dQG22756 for ; Thu, 19 Jul 2001 09:39:26 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 09:36:27 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVBT78>; Thu, 19 Jul 2001 09:36:04 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BB0B@esebe004.NOE.Nokia.com> To: ipng@sunroof.eng.sun.com Cc: itojun@iijlab.net Subject: RE: I-D ACTION:draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt Date: Thu, 19 Jul 2001 09:35:56 +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 Itojun, A quick comment on this draft - as somewhat of a ANYCAST novice, I found this informative. However, I was wondering if a section on SCTP might be useful. I would be willing to contribute some text on this - but probably not until after the London meeting. SCTP has some very interesting features that, on one hand may complicate the use of ANYCAST, but also make the use of ANYCAST very attractive. I have been thinking quite much about some uses for this. Since SCTP allows each endpoint to use multiple IP addresses, this might make it easier to send to an ANYCAST address, while allowing a reply from a UNICAST address. If you are willing, we could discuss this in London. 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 Wed Jul 18 23:39:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J6d8i00962 for ipng-dist; Wed, 18 Jul 2001 23:39:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J6d4000955 for ; Wed, 18 Jul 2001 23:39: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 XAA01778 for ; Wed, 18 Jul 2001 23:39:18 -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 AAA15835 for ; Thu, 19 Jul 2001 00:40:35 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 245A14B25; Thu, 19 Jul 2001 15:39:14 +0900 (JST) To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com In-reply-to: john.loughney's message of Thu, 19 Jul 2001 09:35:56 +0300. <0C1353ABB1DEB74DB067ADFF749C4EEF09BB0B@esebe004.NOE.Nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: I-D ACTION:draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt From: itojun@iijlab.net Date: Thu, 19 Jul 2001 15:39:14 +0900 Message-ID: <20459.995524754@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >A quick comment on this draft - as somewhat of a ANYCAST novice, >I found this informative. However, I was wondering if a section >on SCTP might be useful. I would be willing to contribute >some text on this - but probably not until after the London >meeting. > >SCTP has some very interesting features that, on one hand >may complicate the use of ANYCAST, but also make the use >of ANYCAST very attractive. I have been thinking quite much >about some uses for this. > >Since SCTP allows each endpoint to use multiple IP addresses, >this might make it easier to send to an ANYCAST address, >while allowing a reply from a UNICAST address. yes, SCTP section would be nice to have. or, should i generalize L4 sections? not sure. anyway, i agree we should say something about it. >If you are willing, we could discuss this in London. of course, i'll be in all of the IPv6 meetings, and i'll be in term room all night:-) so it should be quite easy for us to meet up. 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 Jul 18 23:43:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6J6gmd00992 for ipng-dist; Wed, 18 Jul 2001 23:42:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6J6gj000985 for ; Wed, 18 Jul 2001 23:42:45 -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 XAA03695 for ; Wed, 18 Jul 2001 23:42:58 -0700 (PDT) From: john.loughney@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 AAA04041 for ; Thu, 19 Jul 2001 00:42:56 -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 f6J6jtG24342 for ; Thu, 19 Jul 2001 09:45:55 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 09:42:52 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSVB413>; Thu, 19 Jul 2001 09:42:42 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0940AE@esebe004.NOE.Nokia.com> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: RE: I-D ACTION:draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt Date: Thu, 19 Jul 2001 09:42: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 Hi Itojun, > yes, SCTP section would be nice to have. or, should i > generalize L4 sections? not sure. anyway, i agree we should say > something about it. As I mentioned, SCTP has a few 'interesting' features - so maybe I could draft a short section and give it to you to review. I am trying to finish a few draft updatess for Friday & then have a short vacation, so I doubt I can give you anything before the meeting. > > >If you are willing, we could discuss this in London. > > of course, i'll be in all of the IPv6 meetings, and i'll be in > term room all night:-) so it should be quite easy for > us to meet up. That sounds like a plan. Also, I think that a stop in Helsinki after the London meeting is on your agenda - so we could talk further there. 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 Thu Jul 19 22:12:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K5CE504516 for ipng-dist; Thu, 19 Jul 2001 22:12:14 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K5CA004509; Thu, 19 Jul 2001 22:12:10 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-106.EBay.Sun.COM [129.150.4.106]) by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K5CMX125095; Thu, 19 Jul 2001 22:12:22 -0700 (PDT) Message-Id: <5.1.0.14.0.20010719220418.03084d78@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 19 Jul 2001 22:18:49 -0700 To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Alain Durand Subject: NGtrans - DNSext joint meeting, call for participation Cc: randy@psg.com, tony@tndh.net, fink@es.net, Olafur Gudmundsson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The NGtrans/DNSext chairs would like to make a call for participation in the upcoming joint meeting. The goal of the meeting is to facilitate consensus on how IPv6 addresses are represented in DNS and related issues. This meeting requires extensive homework by participants and the chairs would like to request submission of documents for a reading list for this meeting. The output from the meeting will be draft consensus proposal. Here is non exclusive a list of relevant topics: 1 - Design tradeoffs in DNS and IPv6 (AAAA, A6, DNAME, bit string) - DNS operational considerations including DNSSEC costs in regard of address record format - DNS implementation complications due to address record format - IPv6 Remembering requirements and impact on address record format - Case for A6 - Case for AAAA - transition from ip6.int to ip6.arpa - transition from AAAA to A6 2 - tools/protocols/strategies to bridge IPv6 and IPv4 DNS resolution Anybody wishing to make a presentation should send a draft to the chairs of this meeting before July 26th 2001, 21:00 UTC (that is, 2pm PDT, 5pm EDT, 11pm MEST) - Alain Durand - Olafur Gudmundsson Drafts not yet published by the ID editor are acceptable contributions (please include an URL). The chairs will review the list of submission, derived the actual agenda of the meeting from it and send all reading materials to the DNSext and NGtrans mailing list no later than July 27th, 21:00 UTC. - Alain & Olafur. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 19 23:45:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K6iQj04709 for ipng-dist; Thu, 19 Jul 2001 23:44:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K6iJ004698 for ; Thu, 19 Jul 2001 23:44: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 XAA17706 for ; Thu, 19 Jul 2001 23:44:31 -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 AAA25717 for ; Fri, 20 Jul 2001 00:45:51 -0600 (MDT) Received: (qmail 2621 invoked by uid 1001); 20 Jul 2001 06:44:50 -0000 Date: 20 Jul 2001 06:44:50 -0000 Message-ID: <20010720064450.30241.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 - DNSext joint meeting, call for participation References: <5.1.0.14.0.20010719220418.03084d78@jurassic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1. I won't be at the meeting. However, I strongly support elimination of A6/DNAME: http://cr.yp.to/djbdns/killa6.html 2. There's a common error in the evaluation of DNSSEC signing costs. I'd like to draw attention to a new section that I've added to my web page to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts 3. I don't understand why this is an ngtrans issue rather than an ipngwg issue. The question is not how to move smoothly to A6/DNAME; the question is whether we want A6/DNAME at all. ---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 Jul 20 01:13:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K8CUw05014 for ipng-dist; Fri, 20 Jul 2001 01:12:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K8CQ005007 for ; Fri, 20 Jul 2001 01:12: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 BAA00539 for ; Fri, 20 Jul 2001 01:12:38 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05321 for ; Fri, 20 Jul 2001 02:12:36 -0600 (MDT) Received: from PGROSSET-W2K.cisco.com (pgrosset-isdn-home.cisco.com [10.49.89.26]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA21307; Fri, 20 Jul 2001 10:12:19 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010720101159.017edf00@europe.cisco.com> X-Sender: pgrosset@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jul 2001 10:12:18 +0200 To: itojun@iijlab.net From: Patrick Grossetete Subject: Re: Cc: Ville Nummela , users@ipv6.org, ipng@sunroof.eng.sun.com In-Reply-To: <7986.995263360@itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Under development. Patrick At 03:02 PM 16-07-01 +0900, itojun@iijlab.net wrote: > >> > From the old IPV6 mailing list thread, i feel that except > >> >Zebra, nobody has the support for OSPFv3. Is it still holds? > >> I know of at least four implementations (demonstrated at Tokyo N+I): > >> Ericsson/Telebit, NEC, Hitachi and Zebra. some of them may still > >> be in beta stage (may not be available for public yet). > >I believe cisco supports OSPFv3 too. > > I have never heard of that. if so, I'd really love to test that :-) > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 02:30:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K9UDm05150 for ipng-dist; Fri, 20 Jul 2001 02:30:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K9Tg005128; Fri, 20 Jul 2001 02:29:43 -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 CAA21985; Fri, 20 Jul 2001 02:29:56 -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 DAA10244; Fri, 20 Jul 2001 03:29:53 -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 f6K9TgL24695; Fri, 20 Jul 2001 02:29:42 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f6K9Tgu08192; Fri, 20 Jul 2001 02:29:42 -0700 Message-Id: <200107200929.f6K9Tgu08192@zed.isi.edu> Subject: Re: draft-ietf-ngtrans-dns-ops-req-00.txt To: Alain.Durand@sun.com (Alain Durand) Date: Fri, 20 Jul 2001 02:29:42 -0700 (PDT) Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, randy@psg.com, tony@tndh.net, fink@es.net, ogud@ogud.com (Olafur Gudmundsson) In-Reply-To: <5.1.0.14.0.20010719220418.03084d78@jurassic> from "Alain Durand" at Jul 19, 2001 10:18:49 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 NOTE WELL: this e-mail is not in accordance with the all requirements of section 10 of RFC2026 ... in particular, I haven't given due credit to those who taught me to read and write (frankly, I don't remember who they were), and vast numbers of other people, all of whom contributed to my getting to where I am today... However, I make no copyright claims to it, use it how you will. I also have no patents, pending or issued, on any of the technology (or ever ideas) discussed herein. "IETF" might be a trade mark, so might "RFC", but they don't belong to me. ------------------------------------------------------ In section seven, you call out for the desire to have native IPv6 transport aware DNS servers for the inverse mapping of the IPv6 address tree. While I can't speak to the IP6.ARPA proposal, the IP6.INT domain has had native IPv6 servers for nearly a year and the INT domain has had a native IPv6 server for 6 months. An informal sub-group of the RSSAC has had working, test root servers, that are native IPv6 aware for a little over a year. So there is a community with some emperical experience with these issues. -- --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 Jul 20 02:36:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6K9Zfr05206 for ipng-dist; Fri, 20 Jul 2001 02:35:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6K9ZY005192 for ; Fri, 20 Jul 2001 02:35: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 CAA22766 for ; Fri, 20 Jul 2001 02:35:48 -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 DAA03343 for ; Fri, 20 Jul 2001 03:37:08 -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 FAA05197; Fri, 20 Jul 2001 05:34:49 -0400 (EDT) Message-Id: <200107200934.FAA05197@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-06.txt Date: Fri, 20 Jul 2001 05:34:49 -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 : 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 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-06.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-addr-arch-v3-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719145658.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145658.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 Jul 20 04:37:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KBb0405697 for ipng-dist; Fri, 20 Jul 2001 04:37:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KBaJ005675; Fri, 20 Jul 2001 04:36:19 -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 EAA01773; Fri, 20 Jul 2001 04:36:31 -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 EAA05914; Fri, 20 Jul 2001 04:36:21 -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 f6KBZdL05515; Fri, 20 Jul 2001 04:35:39 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f6KBZdf08571; Fri, 20 Jul 2001 04:35:39 -0700 Message-Id: <200107201135.f6KBZdf08571@zed.isi.edu> Subject: Re: "test root servers" To: JimFleming@prodigy.net (Jim Fleming) Date: Fri, 20 Jul 2001 04:35:39 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), Alain.Durand@sun.com (Alain Durand), ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, randy@psg.com, tony@tndh.net, fink@es.net, ogud@ogud.com (Olafur Gudmundsson), karl@cavebear.com (karl@cavebear. com), simon@higgs.com (Simon Higgs), richard@vrx.net, lynn@icann.org (Lynn), mueller@syr.edu (mueller@syr. edu), mcade@att.com, krose@ntia.doc.gov (krose@ntia. doc. gov), froomkin@law.miami.edu (froomkin@law. miami. edu), joppenheimer@icbtollfree.com (joppenheimer@icbtollfree. com), cgomes@VERISIGN.COM (Chuck Gomes) In-Reply-To: <001101c1110a$4b150b20$cc931440@pc> from "Jim Fleming" at Jul 20, 2001 05:53:58 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 NOTE WELL: this e-mail is not in accordance with the all requirements of section 10 of RFC2026 ... in particular, I haven't given due credit to those who taught me to read and write (frankly, I don't remember who they were), and vast numbers of other people, all of whom contributed to my getting to where I am today... However, I make no copyright claims to it, use it how you will. I also have no patents, pending or issued, on any of the technology (or ever ideas) discussed herein. "IETF" might be a trade mark, so might "RFC", but they don't belong to me. -------------------------------------------------------------- % Are the "test root servers" using 2002::0000 style addressing ? No. They are test machines and use testing addresses. Mapped IPv4 is not a test but a transition technique. % Has the ICANN Board approved these alternative root servers ? Not to my knowledge. They are not production services, they are used to experiment and test. That said, several ICANN staff and Board members have informally been made aware of this testbed. % Are there native IPv6 .COM servers? I would not know. % Jim Fleming --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 Jul 20 05:43:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KCh5W05869 for ipng-dist; Fri, 20 Jul 2001 05:43:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KCgd005847; Fri, 20 Jul 2001 05:42: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 FAA22057; Fri, 20 Jul 2001 05:42:52 -0700 (PDT) Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19365; Fri, 20 Jul 2001 06:44:11 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15NZcB-0000bP-00; Fri, 20 Jul 2001 08:42:43 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alain Durand Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se, tony@tndh.net, fink@es.net, Olafur Gudmundsson Subject: Re: NGtrans - DNSext joint meeting, call for participation References: <5.1.0.14.0.20010719220418.03084d78@jurassic> Message-Id: Date: Fri, 20 Jul 2001 08:42:43 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk alain, you have a bug in your mail system. somehow the line which said that rob austien's draft will be used as the agenda driver got dropped. you may want to try to send the agreed message again. 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 Jul 20 09:42:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KGfWf06968 for ipng-dist; Fri, 20 Jul 2001 09:41:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KGfS006961 for ; Fri, 20 Jul 2001 09:41:28 -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 JAA18890 for ; Fri, 20 Jul 2001 09:41:41 -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 KAA26171 for ; Fri, 20 Jul 2001 10:43:00 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GGS00KC76DEVS@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Fri, 20 Jul 2001 11:41:38 -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 f6KGf6F10488 for ; Fri, 20 Jul 2001 11:41:06 -0500 (CDT) Date: Fri, 20 Jul 2001 11:41:05 -0500 From: Matt Crawford Subject: Responses to comments on draft-ietf-ipngwg-icmp-name-lookups-08.txt To: ipng@sunroof.eng.sun.com Message-id: <200107201641.f6KGf6F10488@gungnir.fnal.gov> MIME-version: 1.0 Content-type: multipart/mixed; boundary=mimeprimaryboundary Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain Enclosed are the comments Bob collected and my response. A revised draft has been submitted to the i-d editor. --mimeprimaryboundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Dec 2000 10:49:39 -0800 From: Bob Hinden Subject: Comments on "IPv6 Node Information Queries" To: Matt Crawford Cc: hinden@iprg.nokia.com, deering@cisco.com Message-id: <4.3.2.7.2.20001211104841.0229ae28@mailhost.iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=3Dflowed; charset=3Dus-ascii Matt, I will forward you the comments I found on the "IPv6 Node Information = Queries" IETF last call. Let me know what you think. Bob ------- =3D_aaaaaaaaaa0 Date: Mon, 11 Dec 2000 10:50:28 -0800 From: Bob Hinden Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed St= andard X-Sender: hinden@mailhost.iprg.nokia.com To: Matt Crawford Message-id: <4.3.2.7.2.20001211104952.02327d80@mailhost.iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=3Dflowed; charset=3Dus-ascii From: Keith Moore To: iesg@ietf.org cc: ipng@sunroof.eng.sun.com Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standar= d X-SUBJECT-MSG-FROM: The IESG Date: Thu, 31 Aug 2000 14:48:45 -0400 Sender: owner-ipng@sunroof.eng.sun.com This proposal opens up a huge can of worms which might be better left clo= sed. A host can have multiple interfaces, mutiple addresses on an interface, multiple interfaces with the same address, multiple domain names for an address, and there can also be multiple addresses for a domain. A single domain can apply to multiple hosts, either via multiple addresse= s or via a single address and an IP fanout device. A host inherently knows about its interfaces and the addresses assigned to them, but the relationship between DNS names and addresses is maintained elsewhere. So the whole notion of "a node's domain name[s]" gets pretty sticky, even if you restrict that query to the names corresponding to a single IP address. My biggest concern about this proposal is that it doesn't specify the purposes for which this service can be used. To put it another way, what services can rely on this information, and what services are allowed to break if the result from the ICMPv6 query doesn't correspond to what can be obtained from DNS (or to what applications running on that host believe)? For instance, might an application assume that if it obtains multiple addresses for a host using this service that it can communicate with an application on that host using any of those addresses ? (which would fail given the quite common practice of virtual hosting) or if it obtains multiple domain names for an address, can an application= assume that the domain names are equivalent? (they're not, because eithe= r of those domain names could also reach other hosts, and the two sets of hosts might not be the same) There should be only one authoritative source of the binding betweeen a DNS name and any addresses associated with that name, and it should probably be DNS. The notion that "sometimes DNS is right, and sometimes= the host is right" makes it hard to write code that behaves reliably. Another concern I have is that this proposal seems to push DNS names into a lower layer of the protocol stack and thereby embeds them more deeply in the Internet architecture. I believe it is highly desirable to keep these as completely separate layers. The separation of function between IP and DNS allows us to evolve each of them separately, even to the point of replacing IP (which we are doing) or providing alternate lookup services to DNS (which is necessary if we want those lookup services to work efficiently) The separation also allows problems with IP networks and/or applications to be diagnosed separately from DNS - it allows us to debug such problems with the DNS layer out of the picture. On a different level this proposal exposes a conflict between various autoconfiguration architectures which has been brewing for some time - does the host assert its name and/or address to the network or does the network tell the host its name and/or address? It does this by creating an alternate way to find a name-to-address bindings when in the past the only publically available source of such information (and hence, the assumed authority for such information) was DNS. It would be good to sort out this conflict, because sorting this out is needed before autoconfiguration can really work effectively on a large= scale. But sorting this out is probably needed before people start building things which depend on this ICMPv6 service. And sorting this issue out probably also means answering the question of what is a reasonable lifetime for the binding between a host and an IP address. These will not be easy questions to answer, particularly because people's= assumptions about what is reasonable (and where to distribute the pain of changing these things) vary widely. But IMHO we need to answer them before we start embedding DNS names more deeply into network stacks, and especially before we start relying on this service. There's also a security problem with defining a means by which hosts can be expected to expose information about their DNS names, the addresses they use, the networks they are on, etc. This is yet another source of information that would need to be filtered by networks that didn't want to expose such information to external sites. In a nutshell, my recommendations are: - document the intended use (diagnostics?) and clearly specify that the authoritative source of these mappings is in DNS - make this Experimental rather than Proposed - document the security issues wrt inappropriate exposure - require that implementations be able to turn off this feature, and that it be disabled by default. actually hosts should probably require explicit configuration regarding which domain names and which addresses to advertise by this method. Keith ------- =3D_aaaaaaaaaa0 Date: Mon, 11 Dec 2000 10:54:46 -0800 From: Bob Hinden Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed St= andard X-Sender: hinden@mailhost.iprg.nokia.com To: Matt Crawford Message-id: <4.3.2.7.2.20001211105109.0205e850@mailhost.iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=3Dflowed; charset=3Dus-ascii Date: Mon, 11 Sep 2000 02:19:31 +0900 From: JINMEI Tatuya / =3D?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=3D?=3D To: iesg@ietf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standar= d User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Jap= an. X-Dispatcher: imput version 980905(IM100) Lines: 55 >>>>> On Thu, 31 Aug 2000 12:36:10 -0400, >>>>> The IESG said: > The IESG has received a request from the IPNG Working Group to conside= r > IPv6 Node Information Queries > 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 September 13, 2000. I admit that I should've made comments on the draft earlier, but please let me add a final (I hope this is final) comment. The 07 draft defines TTL of an address used in the node information messages as follows: The Responder must fill in the TTL field of the Reply with a meaningful value if possible. That value should be one of the following. The remaining lifetime of a DHCP lease on the Subject Address; The remaining Valid Lifetime of a prefix from which the Subject Address was derived through Stateless Autoconfiguration [2461, 2462]; The TTL of an existing AAAA or A6 record which associates the Subject Address with the DNS Name being returned. (page 8, Section 4.3) Possible range of those TTLs are different: According to draft-ietf-dhc-v6exts-12.txt defines, the Valid (lease) lifetime of an IPv6 address configured by DHCPv6 is a 32bits integer (in seconds). (I'm not sure if the value is signed or not, and if it has some range only by the draft). According to RFC 2461, the Valid lifetime of an IPv6 address through stateless autoconfiguration is an unsigned 32bits integer (in seconds), and the "all-1 value (0xffffffff)" has a special meaning, i.e. infinity. According to RFC 2181, the TTL value for a DNS record is an unsigned integer from 0 to 2^31 - 1. The easiest way to solve the ambiguity would be introduding an additional field for the TTL field to specify the type of TTL. However, this would break backward compatibility (again!)... Currently, I'm not sure the best way, but we'll surely need some clarification here. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Co= rp. jinmei@isl.rdc.toshiba.co.jp ------- =3D_aaaaaaaaaa0 Date: Mon, 11 Dec 2000 10:51:52 -0800 From: Bob Hinden Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed St= andard X-Sender: hinden@mailhost.iprg.nokia.com To: Matt Crawford Message-id: <4.3.2.7.2.20001211105149.0205d938@mailhost.iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=3Dflowed; charset=3Dus-ascii From: Robert Elz To: JINMEI Tatuya / =3D?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=3D?=3D = Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standar= d Date: Mon, 11 Sep 2000 17:40:28 +1100 Sender: owner-ipng@sunroof.eng.sun.com Date: Mon, 11 Sep 2000 02:19:31 +0900 From: JINMEI Tatuya / =3D?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=3D= ?=3D Message-ID: | The easiest way to solve the ambiguity would be introduding an | additional field for the TTL field to specify the type of | TTL. However, this would break backward compatibility (again!)... | Currently, I'm not sure the best way, but we'll surely need some | clarification here. Actually, the easiest way is just to define it as an unsigned integer (values 0 .. 2^32 - 1) - with 0xffffffff defined specially if needed. A negative TTL has no useful meaning, so even if the dhcpv6exts (the vers= ion with the '-' instead of the 'p' in the draft name expired ages ago) draft= is intending to allow a negative value for the valid lease lifetime for some= reason, sending 0 in the node information query would be reasonable if gi= ven negative input (though what a negative value would mean I have no idea ..= "you should have returned this address I am just giving you 30 minutes = ago" ?). That draft needs a better definition of this field. Then all rational TTL values can be included - the DNS can only handle ha= lf of what can be in the node information reply, but that's OK, what matters= is that the DNS response can be loaded into the node info field, not the oth= er way. kre ------- =3D_aaaaaaaaaa0 Date: Mon, 11 Dec 2000 10:50:40 -0800 From: Bob Hinden Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed St= andard X-Sender: hinden@mailhost.iprg.nokia.com To: Matt Crawford Message-id: <4.3.2.7.2.20001211105035.02062b30@mailhost.iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=3Dflowed; charset=3Dus-ascii To: Keith Moore cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standar= d From: itojun@iijlab.net Date: Tue, 05 Sep 2000 18:17:52 +0900 >My biggest concern about this proposal is that it doesn't specify the >purposes for which this service can be used. To put it another way, >what services can rely on this information, and what services are >allowed to break if the result from the ICMPv6 query doesn't correspond= >to what can be obtained from DNS (or to what applications running on >that host believe)? at IETF48 zeroconf WG and dnsext WG, I heard some comment on mak= ing distinction between full qualified domain name (which is on the = DNS database), and hostname (which is configured onto each of the ho= st, and do not necessarily the same as FQDN). Not sure if it has wi= de concensus, but it made some sense to me. - we look up FQDN through DNS database - we look up hostname through /etc/hosts (i'm not sure if it is really correct) - gethostname(3) returns hostname, not FQDN it is kind of confusing, but this gave me a way to understand th= e current situation. if we are okay with the distinction, we may be able to state the following: - if we are to lookup some name via ICMPv6 name lookup, it would= be hostname, not FQDN. we need to update name-lookup draft again, though. of course, the above distinction could be very wrong. but then,= how should we understand the current situation with gethostname(= 3)? itojun ------- =3D_aaaaaaaaaa0 Date: Mon, 11 Dec 2000 10:54:41 -0800 From: Bob Hinden Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed St= andard X-Sender: hinden@mailhost.iprg.nokia.com To: Matt Crawford Message-id: <4.3.2.7.2.20001211105052.0202dd50@mailhost.iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=3Dflowed; charset=3Dus-ascii From: Keith Moore To: itojun@iijlab.net cc: Keith Moore , iesg@ietf.org, ipng@sunroof.eng.sun.c= om Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standar= d Date: Tue, 05 Sep 2000 06:54:46 -0400 Sender: owner-ipng@sunroof.eng.sun.com > >My biggest concern about this proposal is that it doesn't specify the= > >purposes for which this service can be used. To put it another way, > >what services can rely on this information, and what services are > >allowed to break if the result from the ICMPv6 query doesn't correspo= nd > >to what can be obtained from DNS (or to what applications running on > >that host believe)? > > at IETF48 zeroconf WG and dnsext WG, I heard some comment on m= aking > distinction between full qualified domain name (which is on th= e DNS > database), and hostname (which is configured onto each of the = host, > and do not necessarily the same as FQDN). Not sure if it has = wide > concensus, but it made some sense to me. > - we look up FQDN through DNS database > - we look up hostname through /etc/hosts > (i'm not sure if it is really correct) > - gethostname(3) returns hostname, not FQDN my experience is more like: - hostname is set as part of system configuration (during boot) (you can't look it up in /etc/hosts because you need to know what to look for) - hostname can either be an alias (usually just a label) or an F= QDN - you can sometimes look up hostname in local DNS and get back a= n = FQDN - the mapping from hostname to FQDN might or might not involve adding a domain suffix to the hostname. > it is kind of confusing, but this gave me a way to understand = the > current situation. if we are okay with the distinction, > we may be able to state the following: > - if we are to lookup some name via ICMPv6 name lookup, it wou= ld > be hostname, not FQDN. > we need to update name-lookup draft again, though. okay, but this still doesn't answer the question. what is the purpose of= this service, and what things are allowed to depend on it? Keith ------- =3D_aaaaaaaaaa0 Date: Mon, 11 Dec 2000 10:54:46 -0800 From: Bob Hinden Subject: Fwd: Re: Last Call: IPv6 Node Information Queries to Proposed St= andard X-Sender: hinden@mailhost.iprg.nokia.com To: Matt Crawford Message-id: <4.3.2.7.2.20001211105141.01d25488@mailhost.iprg.nokia.com> MIME-version: 1.0 Content-type: text/plain; format=3Dflowed; charset=3Dus-ascii To: Keith Moore cc: iesg@ietf.org, 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: Re: Last Call: IPv6 Node Information Queries to Proposed Standar= d From: itojun@iijlab.net Date: Tue, 05 Sep 2000 23:29:53 +0900 >> it is kind of confusing, but this gave me a way to understand= the >> current situation. if we are okay with the distinction, >> we may be able to state the following: >> - if we are to lookup some name via ICMPv6 name lookup, it wo= uld >> be hostname, not FQDN. >> we need to update name-lookup draft again, though. >okay, but this still doesn't answer the question. what is the purpose = of >this service, and what things are allowed to depend on it? under zeroconf situation, you may want to lookup: - an address from a hostname, using ICMPv6 name lookup (query ty= pe =3D node addresses) toward ff02::1 (or NI group address) - an address to a hostname, using ICMPv6 name lookup (query type= =3D DNS name/hostname) toward the address the message type can be used just like mDNS proposals (see draft-aboba-dnsext-mdns-01.txt). also, it has been really useful for debugging. not 100% sure if the use of icmp6 is a good idea or not. also, = as you noted, icmp6 may seem like a layer violation. if you have bette= r suggestion, please let me know. (NOTE: I understand the security issues by giving away more information to bad guys) itojun ------- =3D_aaaaaaaaaa0-- --mimeprimaryboundary Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Response to comments on "IPv6 Node Information Queries" In response to Keith's comments I am expanding the abstract to say more about the environments in which this is expected to be used, and to disclaim any intent to override DNS authority when DNS is available. I'm also referring to the names which may be the subjects or results of NI queries as simply "names" rather than "domain names", and when necessary for clarity, adding the words "either fully-qualified or single-component". His comment For instance, might an application assume that if it obtains multiple addresses for a host using this service that it can communicate with an application on that host using any of those addresses ? (which would fail given the quite common practice of virtual hosting) resolves itself if one notes that the subject of a query is never "a host" but only "a name" or "an address". If you find multiple addresses for a name then, yes, you may reasonably expect to find the same service instance at as many of those addresses as the routing system lets you reach. I think we're all in agreement there. There should be only one authoritative source of the binding betweeen a DNS name and any addresses associated with that name, and it should probably be DNS. The notion that "sometimes DNS is right, and sometimes the host is right" makes it hard to write code that behaves reliably. In a perfect world this would be so. But we already left that world some time ago when ISPs stopped (or failed to start) registering the names preferred by the end users. We also have operating systems which let the user assign a name which may never be registered in DNS. Another concern I have is that this proposal seems to push DNS names into a lower layer of the protocol stack and thereby embeds them more deeply in the Internet architecture. I believe it is highly desirable to keep these as completely separate layers. The separation of function between IP and DNS allows us to evolve each of them separately, even to the point of replacing IP (which we are doing) or providing alternate lookup services to DNS (which is necessary if we want those lookup services to work efficiently) The separation also allows problems with IP networks and/or applications to be diagnosed separately from DNS - it allows us to debug such problems with the DNS layer out of the picture. This is exaggeration. This new mechanism doesn't route any packets or provide a new way to fill in the IP header. It's a new name and address information scheme, yes, but it doesn't mix naming up with packet delivery in any way. On a different level this proposal exposes a conflict between various autoconfiguration architectures which has been brewing for some time - does the host assert its name and/or address to the network or does the network tell the host its name and/or address? That conflict is not new with this protocol. The DHCP hostname extension flows in either direction, and some servers register the name you choose, and others pick you one. Still others stay out of the naming game altogether. There's also a security problem with defining a means by which hosts can be expected to expose information about their DNS names, the addresses they use, the networks they are on, etc. This is yet another source of information that would need to be filtered by networks that didn't want to expose such information to external sites. It's easy for the FNAFH (fascist network admin from hell) to block this all at the border, or at each link. But it certainly is worth adding some guidance about configuring each node's "refuse to answer" option which is already there (ICMPv6 Code=3D1 in a reply). A SHOULD-level default setting of "refuse queries from global addresses" sounds about right. (And change the "MUST send a Reply with TTL=3D0 and no names"" in section 4.3 to allow the refusal.) I'm also adding that responders SHOULD rate limit replies. Tatuya's point is a good one and I will simply add text saying that the TTL field is limited to 2^31-1, even if the node's idea of the lifetime is longer. That also cover's kre's comment. Itojun's comment, which brings input from zeroconf and dnsext, is accepted through the change of making a clear distinction between the names in Node Information and "DNS Names". The last pair of messages between Keith and Itojun are addressed by the expanded introduction added in response to Keith's first comment. I include that intruction here: Introduction This docment specifies a mechanism for discovering information about names and addresses (and is extensible to deal with other information). In the global internet, the Domain Name System [1034, 1035] is the authoritative source of such information and this specifcation is not intended to supplant or supersede it. And in fact, in a well-supported network the names and addresses dealt with by this mechanism will be the same ones, and with the same relationships, as those listed in the DNS. This new Node Information protocol does provide facilities which are not found in the DNS - for example discovering relationships between addresses without reference to names. And the functions that do overlap with the DNS may be useful in serverless environments, for debugging, or in regard to link-local and site-local addresses [2373] which often will not be listed in the DNS. --mimeprimaryboundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 10:01:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KH0Pp07103 for ipng-dist; Fri, 20 Jul 2001 10:00:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KH0J007096; Fri, 20 Jul 2001 10:00:19 -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 KAA13957; Fri, 20 Jul 2001 10:00:32 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11465; Fri, 20 Jul 2001 10:00:24 -0700 (PDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GGS00HS278MOC@smtp.fnal.gov>; Fri, 20 Jul 2001 12:00:22 -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 f6KGxmF10588; Fri, 20 Jul 2001 11:59:48 -0500 (CDT) Date: Fri, 20 Jul 2001 11:59:48 -0500 From: Matt Crawford Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "20 Jul 2001 05:46:49 PDT." To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Message-id: <200107201659.f6KGxmF10588@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 2. There's a common error in the evaluation of DNSSEC signing costs. I'd > like to draw attention to a new section that I've added to my web page > to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts Your reasoning is markedly incorrect if applied to A6. If we take site renumbering to be the dominant factor controlling signature-validity times, then the signatures on the A6 records covering interface identifiers and subnets can be valid for a long time, and only one or a small number of A6 rrsets covering the global prefixes needs to be re-signed frequently. > 3. I don't understand why this is an ngtrans issue rather than an ipngwg > issue. The question is not how to move smoothly to A6/DNAME; the > question is whether we want A6/DNAME at all. On this we agree. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 10:06:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KH62a07155 for ipng-dist; Fri, 20 Jul 2001 10:06:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KH5w007148 for ; Fri, 20 Jul 2001 10:05:58 -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 KAA15355 for ; Fri, 20 Jul 2001 10:06:12 -0700 (PDT) Received: from stewart.chicago.il.us (user196.64.37.247.dsli.com [64.37.247.196] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11062 for ; Fri, 20 Jul 2001 11:07:31 -0600 (MDT) Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id f6KHFQB15623; Fri, 20 Jul 2001 12:15:42 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us) Message-ID: <3B58642D.7F24D0FA@stewart.chicago.il.us> Date: Fri, 20 Jul 2001 12:02:37 -0500 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: IPNG CC: TSV WG list Subject: ipv6 scoping in SCTP Content-Type: multipart/mixed; boundary="------------5B63D7F6D371DB96C559E8E2" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------5B63D7F6D371DB96C559E8E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all: The following draft: http://search.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-00.txt Steve and I put together (I believe Steve still may have changes yet to add :/) to try to get down a set of rules for scoping included IPv6 addresses in SCTP initial setup messages... Your advice and comments would be greatly appreciated. R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) --------------5B63D7F6D371DB96C559E8E2 Content-Type: text/plain; charset=us-ascii; name="draft-stewart-tsvwg-sctpipv6-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-stewart-tsvwg-sctpipv6-00.txt" Network Working Group R. R. Stewart INTERNET-DRA S. Deering Cisco expires in six months June 1,2001 IPv6 addressing and Stream Control Transmission Protocol Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Stream Control Transmission Protocol [RFC2960] provides transparent multi-homing to its upper layer users. This multi-homing is accomplished through the passing of address parameters in the initial setup message used by SCTP. In an IPv4 network all addresses are passed with no consideration for their scope and routeablility. In a IPv6 network special considerations MUST be made to properly bring up associations between SCTP endpoints that have IPv6 [RFC2460] addresses bound within their association. This document defines those considerations and enumerates general rules that an SCTP endpoint MUST use in formulating both the INIT and INIT-ACK chunks. Table Of Contents 1. Introduction Stream Control Transmission Protocol [RFC2960] provides transparent multi-homing to its upper layer users. This multi-homing is accomplished through the passing of address parameters in the initial setup message used by SCTP. In an IPv4 network all addresses are passed with no consideration for their scope and routeablility. In a IPv6 network special considerations MUST be made to properly bring up associations between SCTP endpoints that have IPv6 [RFC2460] addresses bound within their association. This document defines those considerations and enumerates general rules that an SCTP endpoint MUST use in formulating both the INIT and INIT-ACK chunks. The emphasis in the rules laid out in this document are to prevent an SCTP endpoint from listing an IPv6 address that is outside of its routeable scope to a peer endpoint. This will prevent black-hole conditions that may cause the unexpected failure of SCTP associations. 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Special rules for IPv6 address scoping When selecting IPv6 addresses to include as parameters in the INIT chunk the following rules MUST be applied: A1) The INIT chunk SHOULD NOT include any IPv6 Link Local address parameters unless the source or destination address in the IPv6 header is a Link Local address. A2) If IPv6 Link Local address parameters are included in the INIT chunk, Link Local addresses that are NOT on the same physical Link as that of the destination or source IPv6 address (found in the IPv6 header) MUST NOT be included. A3) The INIT chunk SHOULD NOT include any IPv6 Site Local address parameters unless the source or destination address in the IPv6 header is a Site Local address. A4) If IPv6 Site Local addresses are included in the INIT chunk, Site Local address that are NOT on the same site MUST NOT be included. A5) If the destination and source address of the INIT is an IPv6 Global address then the sender SHOULD NOT include any Site Local or Link Local IPv6 address parameters in the INIT chunk. When responding to an INIT chunk and selecting IPv6 address parameters to be included in the INIT-ACK chunk, the following rules MUST be applied: B1) The INIT-ACK chunk SHOULD NOT include any IPv6 Link Local address parameters unless the source or destination address in the IPv6 header of the INIT chunk is a Link Local address. B2) If IPv6 Link Local address parameters are included in the INIT-ACK chunk, Link Local addresses that are NOT on the same physical Link as the source or destination address in the IPv6 header of the INIT chunk MUST NOT be included. B3) The INIT-ACK chunk SHOULD NOT include any IPv6 Site Local address parameters unless the source or destination address in the IPv6 header of the INIT chunk is a Site Local address. B4) If IPv6 Site Local addresses are included in the INIT-ACK chunk, Site Local address that are NOT on the same site as the received INIT chunk MUST NOT be included. B5) If the destination and source address of the INIT is an IPv6 Global address then the sender SHOULD NOT include any Site Local or Link Local IPv6 address parameters in the INIT-ACK chunk. 4. Authors addresses Randall R. Stewart 24 Burning Bush Trail. Crystal Lake, IL 60012 USA Phone: +1 815 477 2127 EMail: rrs@cisco.com Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527 8213 Fax: +1 408 527 8254 EMail: deering@cisco.com 5. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification." December 1998. [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, "Stream Control Transmission Protocol," RFC 2960, October 2000. --------------5B63D7F6D371DB96C559E8E2-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 10:19:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KHIjA07192 for ipng-dist; Fri, 20 Jul 2001 10:18:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KHIe007185; Fri, 20 Jul 2001 10: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 KAA18310; Fri, 20 Jul 2001 10:18:53 -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 KAA23011; Fri, 20 Jul 2001 10:18:48 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0F9744B25; Sat, 21 Jul 2001 02:18:45 +0900 (JST) To: Matt Crawford Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se In-reply-to: crawdad's message of Fri, 20 Jul 2001 11:59:48 EST. <200107201659.f6KGxmF10588@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 - DNSext joint meeting, call for participation From: itojun@iijlab.net Date: Sat, 21 Jul 2001 02:18:45 +0900 Message-ID: <8982.995649525@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> 2. There's a common error in the evaluation of DNSSEC signing costs. I'd >> like to draw attention to a new section that I've added to my web page >> to analyze this error: http://cr.yp.to/djbdns/killa6.html#signingcosts >Your reasoning is markedly incorrect if applied to A6. If we take >site renumbering to be the dominant factor controlling >signature-validity times, then the signatures on the A6 records from what I got from reading djb's webpage, djb's point is that the dominant factor controlling signature-validity time is security, and for that reason he claims it needs to be very short (so there's no real difference in signing overhead for AAAA or A6). so the assumption for the "dominant factor" is totally different between you two. i'm still not sure if djb's claim is right or not, but anyway that's what i got from his note. 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 Jul 20 11:35:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KIYw007512 for ipng-dist; Fri, 20 Jul 2001 11:34:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KIYt007505 for ; Fri, 20 Jul 2001 11:34:55 -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 LAA19366 for ; Fri, 20 Jul 2001 11:35:07 -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 MAA26567 for ; Fri, 20 Jul 2001 12:36:26 -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 LAA00706; Fri, 20 Jul 2001 11:35:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6KIZ3c17637; Fri, 20 Jul 2001 11:35:03 -0700 X-mProtect: Fri, 20 Jul 2001 11:35:03 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.44.22, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdtkg0UD; Fri, 20 Jul 2001 11:33:58 PDT Message-Id: <4.3.2.7.2.20010720104547.0231c268@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jul 2001 11:33:41 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft 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 draft 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. Also note that the two IPng sessions are now Wednesday afternoon and Friday morning. This is a change from the earlier email requesting agenda items. Please send us comments, additions, and deletions. Thanks, Bob Hinden Steve Deering ------------------------------------------------------------------------- WEDNESDAY, August 8, 2001 1300-1500 (120) ------------------------------------------- Introduction / Steve Deering (5 min) Review Agenda / Steve Deering (5 min) Document Status / Bob Hinden (10 min) 3GPP-IETF Design team status / Bob Hinden (15 min) DNS Discovery / Dave Thaler (20 min) Multilink Subnets / Dave Thaler (20 min) DHCPv6 Status and Last Call / Ralph Droms (10 min) Source/Destination Address Selection / Rich Draves (30 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) Minimum IPv6 Functionality for a Cellular Host / John Loughney (30 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) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 12:10:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KJAEv07710 for ipng-dist; Fri, 20 Jul 2001 12:10:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KJAA007703 for ; Fri, 20 Jul 2001 12:10: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 MAA25754 for ; Fri, 20 Jul 2001 12:10:22 -0700 (PDT) Received: from starfruit.itojun.org (kame202.kame.net [203.178.141.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20850 for ; Fri, 20 Jul 2001 12:10:20 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id B60467BB; Sat, 21 Jul 2001 04:09:42 +0900 (JST) To: Bob Hinden , deering@cisco.com Cc: ipng@sunroof.eng.sun.com In-reply-to: hinden's message of Fri, 20 Jul 2001 11:33:41 MST. <4.3.2.7.2.20010720104547.0231c268@mailhost.iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Draft IPng Agenda for London IETF From: Jun-ichiro itojun Hagino Date: Sat, 21 Jul 2001 04:09:42 +0900 Message-Id: <20010720190942.B60467BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Attached is the draft 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. please add the following items into the agenda. thanks. the items on the top has higher priority for my POV. itojun - Avoiding ping-pong packets on point-to-point links draft-ietf-ipngwg-p2p-pingpong-00.txt 10min to 15min - Requirements for IPv6 dialup operation draft-itojun-ipv6-dialup-requirement-01.txt 10min to 15min (changes only) - An analysis of IPv6 anycast draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt - Disconnecting TCP connection toward IPv6 anycast address draft-itojun-ipv6-tcp-to-anycast-01.txt 5min to 10min in total (changes only) - Socket API for IPv6 traffic class field draft-itojun-ipv6-tclass-api-03.txt 3min to 5min (changes only) - IPv6 SMTP operational requirements draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt 3min to 5min (changes only) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 13:07:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KK5Vl07931 for ipng-dist; Fri, 20 Jul 2001 13:05:31 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KK5Q007924; Fri, 20 Jul 2001 13:05: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 NAA06497; Fri, 20 Jul 2001 13:05: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 OAA07739; Fri, 20 Jul 2001 14:06:56 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GGS006Y5FTB9Z@smtp.fnal.gov>; Fri, 20 Jul 2001 15:05:36 -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 f6KK50F11379; Fri, 20 Jul 2001 15:05:01 -0500 (CDT) Date: Fri, 20 Jul 2001 15:05:00 -0500 From: Matt Crawford Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "20 Jul 2001 11:31:35 PDT." To: itojun@iijlab.net Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Message-id: <200107202005.f6KK50F11379@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Your reasoning is markedly incorrect if applied to A6. If we take > >site renumbering to be the dominant factor controlling > >signature-validity times, then the signatures on the A6 records > > from what I got from reading djb's webpage, djb's point is that > the dominant factor controlling signature-validity time is security, > and for that reason he claims it needs to be very short (so there's The reason is security, in that you can't make the record go away until the signature becomes invalid. So if it's all right for your interface ID and/or subnet information to persist for a month, but you want to be able to change your global prefix(es) on a day's notice, you get a 30-to-1 work savings on almost all of your RRsets. (Yes, a day is awfully short for a non-mobile site, but awfully long for a mobile one.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 13:08:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KK75807940 for ipng-dist; Fri, 20 Jul 2001 13:07:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KK71007933 for ; Fri, 20 Jul 2001 13:07: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 NAA24127 for ; Fri, 20 Jul 2001 13:07:03 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05981 for ; Fri, 20 Jul 2001 13:07:03 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f6KK5Ii12828; Fri, 20 Jul 2001 13:05:18 -0700 (PDT) Received: from [171.70.84.51] (deering-office-pb.cisco.com [171.70.84.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAZ04395; Fri, 20 Jul 2001 13:07:00 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20010720190942.B60467BB@starfruit.itojun.org> References: <20010720190942.B60467BB@starfruit.itojun.org> Date: Fri, 20 Jul 2001 13:06:57 -0700 To: Jun-ichiro itojun Hagino From: Steve Deering Subject: Re: Draft IPng Agenda for London IETF Cc: Bob Hinden , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks, Itojun. Does draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt belong on the ipngwg agenda or the ngtrans agenda? Steve At 4:09 AM +0900 7/21/01, Jun-ichiro itojun Hagino wrote: > >Attached is the draft 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. > > please add the following items into the agenda. thanks. > the items on the top has higher priority for my POV. > >itojun > > >- Avoiding ping-pong packets on point-to-point links > draft-ietf-ipngwg-p2p-pingpong-00.txt > 10min to 15min > >- Requirements for IPv6 dialup operation > draft-itojun-ipv6-dialup-requirement-01.txt > 10min to 15min (changes only) > >- An analysis of IPv6 anycast > draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt >- Disconnecting TCP connection toward IPv6 anycast address > draft-itojun-ipv6-tcp-to-anycast-01.txt > 5min to 10min in total (changes only) > >- Socket API for IPv6 traffic class field > draft-itojun-ipv6-tclass-api-03.txt > 3min to 5min (changes only) > >- IPv6 SMTP operational requirements > draft-ietf-ngtrans-ipv6-smtp-requirement-02.txt > 3min to 5min (changes only) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 13:18:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KKHRr08013 for ipng-dist; Fri, 20 Jul 2001 13:17:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KKHN008006; Fri, 20 Jul 2001 13:17:23 -0700 (PDT) Received: from rouget.sun.com ([129.146.99.78]) by jurassic.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KKHYX334970; Fri, 20 Jul 2001 13:17:34 -0700 (PDT) Message-Id: <5.1.0.14.0.20010720131552.035c7660@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 20 Jul 2001 13:24:01 -0700 To: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Alain Durand Subject: Update, NGtrans - DNSext joint meeting, call for participation Cc: randy@psg.com, tony@tndh.net, fink@es.net, Olafur Gudmundsson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Correction on the previous announcement: The NGtrans/DNSext chairs would like to make a call for participation in the upcoming joint meeting. The goal of the meeting is to facilitate consensus on how IPv6 addresses are represented in DNS and related issues. This meeting requires extensive homework by participants and the chairs would like to request submission of documents for a reading list for this meeting. The output from the meeting will be draft consensus proposal. Here is non exclusive a list of relevant topics: 1 - Design tradeoffs in DNS and IPv6 (AAAA, A6, DNAME, bit string) - DNS operational considerations including DNSSEC costs in regard of address record format - DNS implementation complications due to address record format - IPv6 Remembering requirements and impact on address record format - Case for A6 - Case for AAAA - transition from ip6.int to ip6.arpa - transition from AAAA to A6 2 - tools/protocols/strategies to bridge IPv6 and IPv4 DNS resolution Anybody wishing to make a presentation should send a draft to the chairs of this meeting before July 26th 2001, 21:00 UTC (that is, 2pm PDT, 5pm EDT, 11pm MEST) - Randy Bush - Alain Durand - Bob Fink - Olafur Gudmundsson - Tony Hain Drafts not yet published by the ID editor are acceptable contributions (please include an URL). The chairs will review the list of submission, derived the actual agenda of the meeting from it and send all reading materials to the DNSext and NGtrans mailing list no later than July 27th, 21:00 UTC. The format of the meeting is going to be: - Short summary of the discussion points from the documents - Technical discussion on the relevance of the points - Technical discussion on the points from documents as measured by Rob Austein's document draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt - Brainstorming on the best way to go forward - Straw polls leading to consensus building on a plan of action - the chairs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 20 13:36:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KKZgZ08087 for ipng-dist; Fri, 20 Jul 2001 13:35:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KKZd008080 for ; Fri, 20 Jul 2001 13:35: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 NAA29245 for ; Fri, 20 Jul 2001 13:35:52 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16603 for ; Fri, 20 Jul 2001 13:35:51 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.140.145) by smtp2.libero.it (5.5.031) id 3B3A1872004FA045 for ipng@sunroof.eng.sun.com; Fri, 20 Jul 2001 22:35:50 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 1E86728A42; Fri, 20 Jul 2001 19:07:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 17C0028A36 for ; Fri, 20 Jul 2001 19:07:29 +0200 (CEST) Date: Fri, 20 Jul 2001 19:07:29 +0200 (CEST) From: Mauro Tortonesi To: Subject: draft-ietf-default-addr-select-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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"? 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? 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. 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. 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. 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? -- 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 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 15:26:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KMPEj08303 for ipng-dist; Fri, 20 Jul 2001 15:25:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KMP8008289 for ; Fri, 20 Jul 2001 15:25:08 -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 PAA02918 for ; Fri, 20 Jul 2001 15:25: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 QAA06162 for ; Fri, 20 Jul 2001 16:26:39 -0600 (MDT) Received: (qmail 23146 invoked by uid 1001); 20 Jul 2001 22:13:22 -0000 Date: 20 Jul 2001 22:13:22 -0000 Message-ID: <20010720221322.4452.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 - DNSext joint meeting, call for participation References: <200107201659.f6KGxmF10588@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ``Administrators normally insist on being able to change their records with at most a few days notice,'' my web page says, as a starting point for analyzing the expiration-date security issues. This applies to _all_ records. Existing DNS software assumes, correctly, that long TTLs are a mistake. I elaborated on these points in an ``Extremely long TTLs'' message on ipng in January: Everything changes. Machines acquire extra IP addresses. Machines disappear. Even MAC addresses change: network cards die. (It isn't always possible, never mind easy, to reprogram the MAC address on the new card.) Those of us who write caches don't want to deal with users asking ``why am I getting the old address?'' when a novice administrator starts with a silly 6-week TTL and then suddenly realizes that he has to change the address. My cache never saves data for more than a week. Yes, the average address stays unchanged for a very long time. Yes, it might stay unchanged for even longer with A6. But that's not what TTLs measure! When an address _does_ have to be changed, there's often not much warning. _That_ is what TTLs are for. Matt Crawford writes: > then the signatures on the A6 records covering interface identifiers > and subnets can be valid for a long time, No, they cannot, because that would allow an attacker to interfere with updates. This is the security issue analyzed 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 Fri Jul 20 16:08:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KN7Ze08596 for ipng-dist; Fri, 20 Jul 2001 16:07:35 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KN7X008589 for ; Fri, 20 Jul 2001 16:07:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6KN6F526816 for ipng@sunroof.eng.sun.com; Fri, 20 Jul 2001 16:06:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6HIOYN24848; Tue, 17 Jul 2001 11:24:34 -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 LAA07123; Tue, 17 Jul 2001 11:24:19 -0700 (PDT) Received: from sea-av1.zama.net (smtp1.zama.net [203.142.132.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19486; Tue, 17 Jul 2001 12:23:08 -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 LAA04606; Tue, 17 Jul 2001 11:21:47 -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 LAA04589; Tue, 17 Jul 2001 11:21:46 -0700 (PDT) Received: from twhipple.zama.net ([203.142.132.5]) by postoff1.zama.net (Netscape Messaging Server 4.15) with ESMTP id GGMR0A00.71P; Tue, 17 Jul 2001 11:21:46 -0700 Message-Id: <5.1.0.14.2.20010717111535.02d92b98@postoff1.zama.net> X-Sender: whipple@postoff1.zama.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 17 Jul 2001 11:21:45 -0700 To: users@ipv6.org, usagi-users@linux-ipv6.org, 6bone@ISI.EDU, users@ipv6.org, ipng@sunroof.eng.sun.com, IPv6-AU@e-Secure.com.au, ngtrans@sunroof.eng.sun.com, multi6@ops.ietf.org From: "Todd Whipple" Subject: New Services at Zama Networks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Zama is pleased to announce 2 new services, IPv6 Tunnel Broker and a 6to4 relay. Please visit our web site at www.zamanetworks.com to find out more information about these two services. For those with an OS capable to handle 6to4, point your 6to4 configuration to 6to4.zama6.com. We have also added an IPv6 FAQ to our site to answer the basic questions about IPv6. Hope you all find this information useful. Enjoy Todd Whipple VP of IPv6 Technologies Zama Networks, Inc. Seattle, Wa -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 16:08:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KN84f08617 for ipng-dist; Fri, 20 Jul 2001 16:08:04 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KN82008610 for ; Fri, 20 Jul 2001 16:08:02 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6KN6iY26846 for ipng@sunroof.eng.sun.com; Fri, 20 Jul 2001 16:06:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I1ehN25791 for ; Tue, 17 Jul 2001 18:40: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 SAA10146 for ; Tue, 17 Jul 2001 18:40:56 -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 TAA14261 for ; Tue, 17 Jul 2001 19:40:54 -0600 (MDT) Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6I1f7k09935 for ; Tue, 17 Jul 2001 18:41:07 -0700 (PDT) Received: from cisco.com (sreeramv-u10.cisco.com [171.69.42.43]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id AIS20012 (AUTH sreeramv); Tue, 17 Jul 2001 18:40:55 -0700 (PDT) Message-ID: <3B54E927.C554BFCA@cisco.com> Date: Tue, 17 Jul 2001 18:40:55 -0700 From: Sreeram Vankadari Organization: cisco Systems Inc. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Anycast address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a question on anycast address. Suppose the ipv6 prefix assigned to an interface is 2000::1234:5678/96. now 2000::0/128 becomes the anycast address assigned to that interface. Suppose if there are multiple routers attached to that ethernet interface, and a packet comes with a destination address of 2000::/128 which router will respond to that packet. (2000::/128 is an automatic anycast address assigned to all the ipv6 routers attached to that ethernet) Thanks, Sreeram. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 20 16:09:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KN8Rg08651 for ipng-dist; Fri, 20 Jul 2001 16:08:27 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KN8P008643 for ; Fri, 20 Jul 2001 16:08:25 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6KN77826876 for ipng@sunroof.eng.sun.com; Fri, 20 Jul 2001 16:07:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6I7ArN26073 for ; Wed, 18 Jul 2001 00:10:53 -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 AAA05614 for ; Wed, 18 Jul 2001 00:11:06 -0700 (PDT) Received: from nwcst292.netaddress.usa.net (nwcst292.netaddress.usa.net [204.68.23.37]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA08253 for ; Wed, 18 Jul 2001 00:11:05 -0700 (PDT) Received: (qmail 26460 invoked by uid 60001); 18 Jul 2001 07:11:05 -0000 Message-ID: <20010718071105.26459.qmail@nwcst292.netaddress.usa.net> Received: from 204.68.23.37 by nwcst292 for [203.200.15.20] via web-mailer(34FM.0700.18.03B) on Wed Jul 18 07:11:04 GMT 2001 Date: 18 Jul 2001 12:41:04 IST From: Prema M P To: ipng@sunroof.eng.sun.com Subject: Thank you.. X-Mailer: USANET web-mailer (34FM.0700.18.03B) 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 f6I7AsN26074 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Thanks for the info, I would appreciate if the following scenario's are explained : Scenario 1: Node 2 | 1480 1300 | --- Router ------------------------- | | 1480 Node 1 Node 1 MTU - 1480 Node 2 MTU - 1480 Router (i/f) - 1300 Is Node1 be able to send pkts of size 1480 to Node2 or Router ?? Scenario 2: Node 3 Node 2 1500 | | 1480 | 1500 1500 | ------------------------------Router ------------------------- | | 1300 Node 1 Node 1 MTU - 1300 Node 2 MTU - 1480 Node 3 MTU - 1500  Router(i/f - node 3 side ) - 1500 Router(i/f - node 1 & 2 side ) - 1500 If node3 needs to send pkts to node 1, will Node 1 (IP layer) be able to receive pkts of size 1500 ?? or If there is fragmentation, what will be the fragmented packets size?? Thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 20 16:09:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KN91i08669 for ipng-dist; Fri, 20 Jul 2001 16:09:01 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KN8w008662 for ; Fri, 20 Jul 2001 16:08:58 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6KN7eI26906 for ipng@sunroof.eng.sun.com; Fri, 20 Jul 2001 16:07:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KAqs005508; Fri, 20 Jul 2001 03:52:54 -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 DAA28209; Fri, 20 Jul 2001 03:52:50 -0700 (PDT) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15938; Fri, 20 Jul 2001 04:52:47 -0600 (MDT) Received: from pc (nas-147-204.chicago-n.navipath.net [64.20.147.204]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id f6KAqbq190446; Fri, 20 Jul 2001 06:52:37 -0400 Message-ID: <001101c1110a$4b150b20$cc931440@pc> From: "Jim Fleming" To: "Bill Manning" , "Alain Durand" Cc: , , , , , , "Olafur Gudmundsson" , "karl@cavebear. com" , "Simon Higgs" , , "Lynn" , "mueller@syr. edu" , , "krose@ntia. doc. gov" , "froomkin@law. miami. edu" , "joppenheimer@icbtollfree. com" , "Chuck Gomes" References: <200107200929.f6K9Tgu08192@zed.isi.edu> Subject: "test root servers" Date: Fri, 20 Jul 2001 05:53:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.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: "Alain Durand" Cc: ; ; ; ; ; ; "Olafur Gudmundsson" Sent: Friday, July 20, 2001 4:29 AM Subject: Re: draft-ietf-ngtrans-dns-ops-req-00.txt > > NOTE WELL: > this e-mail is not in accordance with the all requirements of section 10 > of RFC2026 ... in particular, I haven't given due credit to those who taught > me to read and write (frankly, I don't remember who they were), and vast > numbers of other people, all of whom contributed to my getting to where I > am today... However, I make no copyright claims to it, use it how you will. > I also have no patents, pending or issued, on any of the technology (or ever > ideas) discussed herein. "IETF" might be a trade mark, so might "RFC", but > they don't belong to me. > ------------------------------------------------------ > > In section seven, you call out for the desire to have native IPv6 transport > aware DNS servers for the inverse mapping of the IPv6 address tree. While > I can't speak to the IP6.ARPA proposal, the IP6.INT domain has had native > IPv6 servers for nearly a year and the INT domain has had a native IPv6 > server for 6 months. An informal sub-group of the RSSAC has had working, > test root servers, that are native IPv6 aware for a little over a year. > > So there is a community with some emperical experience with these issues. > > > -- > --bill Are the "test root servers" using 2002::0000 style addressing ? Has the ICANN Board approved these alternative root servers ? Are there native IPv6 .COM servers? http://www1.ietf.org/mail-archive/ietf/Current/msg12524.html RFC-2001-06-27-001 - Obtaining IPv8 Address Allocations Jim Fleming 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 Fri Jul 20 16:10:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KN9QY08687 for ipng-dist; Fri, 20 Jul 2001 16:09:26 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KN9O008680 for ; Fri, 20 Jul 2001 16:09:24 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6KN86b26936 for ipng@sunroof.eng.sun.com; Fri, 20 Jul 2001 16:08:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KBrd005719 for ; Fri, 20 Jul 2001 04:53: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 EAA12252 for ; Fri, 20 Jul 2001 04:53:52 -0700 (PDT) Received: from nwcst338.netaddress.usa.net (nwcst338.netaddress.usa.net [204.68.23.83]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA11260 for ; Fri, 20 Jul 2001 04:53:51 -0700 (PDT) Received: (qmail 19758 invoked by uid 60001); 20 Jul 2001 11:53:50 -0000 Message-ID: <20010720115350.19757.qmail@nwcst338.netaddress.usa.net> Received: from 204.68.23.83 by nwcst338 for [203.200.15.20] via web-mailer(34FM.0700.18.03B) on Fri Jul 20 11:53:50 GMT 2001 Date: 20 Jul 2001 17:23:50 IST From: Prema M P To: ipng@sunroof.eng.sun.com Subject: X-Mailer: USANET web-mailer (34FM.0700.18.03B) 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 f6KBre005720 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hope I get answer for this.. Is it possible to disable IPV6 PMTU discovery for a node or is it for particular path? & Is it implemenation dependent? Thanks PREMA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 16:10:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6KNA2I08705 for ipng-dist; Fri, 20 Jul 2001 16:10:02 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KN9w008698 for ; Fri, 20 Jul 2001 16:09:58 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6KN8e926967 for ipng@sunroof.eng.sun.com; Fri, 20 Jul 2001 16:08:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6KDLc005929; Fri, 20 Jul 2001 06:21: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 GAA03192; Fri, 20 Jul 2001 06:21:52 -0700 (PDT) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12944; Fri, 20 Jul 2001 06:21:30 -0700 (PDT) Received: from pc (nas-147-204.chicago-n.navipath.net [64.20.147.204]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id f6KDHAq49114; Fri, 20 Jul 2001 09:17:10 -0400 Message-ID: <00c801c1111e$7309d5c0$cc931440@pc> From: "Jim Fleming" To: "Bill Manning" Cc: , , , , "mouhamet@sonatel. sn" , "junsec@wide. ad. jp" , "jplano@quorum. com. ar" , , "hph@online. no" , "gvaldez@nic. mx" , "cjw@remarque. org" , , , "ant@hivemind. net" , , "Chuck Gomes" , "joppenheimer@icbtollfree. com" , "froomkin@law. miami. edu" , "krose@ntia. doc. gov" , , "mueller@syr. edu" , "Lynn" , , "Simon Higgs" , "karl@cavebear. com" , "Olafur Gudmundsson" , , , , , , , "Alain Durand" , "Bill Manning" , "ietf@ietf. org" References: <200107201135.f6KBZdf08571@zed.isi.edu> Subject: Experimental vs. Production Re: "test root servers" Date: Fri, 20 Jul 2001 08:18:12 -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" > > % Are the "test root servers" using 2002::0000 style addressing ? > > No. They are test machines and use testing addresses. > Mapped IPv4 is not a test but a transition technique. > > % Has the ICANN Board approved these alternative root servers ? > > Not to my knowledge. They are not production services, they > are used to experiment and test. That said, several ICANN > staff and Board members have informally been made aware of > this testbed. > The terms "experimental" and "Proof-of-Concept" appear to be the same with respect to ICANN. It is unclear how many years it will be before "production services" are considered for the new TLDs, including .BIZ. The IPv4/IPv8 swamp or sand-box of course was designed to allow as much of this sort of "play" as people desire, before "production services" are considered. It also satisfies the need for "walled-garden" configurations. http://www.icann.org/tlds/agreements/biz/registry-agmt-appu-11may01.htm U Proof-of-Concept Reports http://www.ietf.org/mail-archive/ietf/Current/msg12574.html RFC-2001-07-01-000 IPv8 Expansion of Proof of Concept TLD Development 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) 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 Fri Jul 20 17:10:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6L0A9A08909 for ipng-dist; Fri, 20 Jul 2001 17:10:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6L0A4008902 for ; Fri, 20 Jul 2001 17:10:05 -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 RAA22598 for ; Fri, 20 Jul 2001 17:10:17 -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 SAA11805 for ; Fri, 20 Jul 2001 18:11:36 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 708A14B25; Sat, 21 Jul 2001 09:10:07 +0900 (JST) To: Prema M P Cc: ipng@sunroof.eng.sun.com In-reply-to: premamp's message of 20 Jul 2001 17:23:50 +0700. <20010720115350.19757.qmail@nwcst338.netaddress.usa.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: From: itojun@iijlab.net Date: Sat, 21 Jul 2001 09:10:07 +0900 Message-ID: <12517.995674207@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hope I get answer for this.. >Is it possible to disable IPV6 PMTU discovery for a node >or is it for particular path? & Is it implemenation dependent? highly implementation dependent. for example, as long as you genreate packets < 1280 octets (IPv6 minimum path MTU) you won't need to run path MTU discovery on your node. therefore, some implementation can avoid path MTU discovery altogether. see RFC2460 p24 (2nd paragraph from the bottom). 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 Jul 20 17:31:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6L0UAk08957 for ipng-dist; Fri, 20 Jul 2001 17:30:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6L0U6008950 for ; Fri, 20 Jul 2001 17:30:06 -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 RAA25346 for ; Fri, 20 Jul 2001 17:30:19 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA06274 for ; Fri, 20 Jul 2001 17:30:19 -0700 (PDT) Received: from 157.54.7.67 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 20 Jul 2001 17:12:41 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 20 Jul 2001 17:12:41 -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); Fri, 20 Jul 2001 17:12:41 -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); Fri, 20 Jul 2001 17:11:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Anycast address Date: Fri, 20 Jul 2001 17:11:35 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B580D9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anycast address Thread-Index: AcERcSbqST9ecfYMS9O+KJ34lDQBQgAB3Aag From: "Dave Thaler" To: "Sreeram Vankadari" Cc: X-OriginalArrivalTime: 21 Jul 2001 00:11:36.0068 (UTC) FILETIME=[B4890C40:01C11179] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6L0U6008951 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sreeram Vankadari [mailto:sreeram.vankadari@cisco.com] writes: > Suppose the ipv6 prefix assigned to an interface is 2000::1234:5678/96. First of all, RFC 2373 mandates that all 2000 addreses (and most others) are required to have 64-bit interface identifiers, so the prefix in question would have to be 2000::/64 (a /96 is illegal). (Also keep in mind that you can assign many prefixes to the same interface.) So I'll assume it's a typo and you meant: "Suppose the IPv6 prefix 2000::/64 is assigned to an interface." > now 2000::0/128 becomes the anycast address assigned to that interface. > Suppose if there are multiple routers attached to that ethernet interface, > and a packet comes with a destination address of 2000::/128 which > router will respond to that packet. (2000::/128 is an automatic anycast > address assigned to all the ipv6 routers attached to that ethernet) Technically "any" one of them would be legal, but the answer that makes the most sense is "the first one that the packet reaches" (i.e. the one closest to the source). -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 Jul 20 21:14:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6L4E0D09368 for ipng-dist; Fri, 20 Jul 2001 21:14:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6L4Dt009361 for ; Fri, 20 Jul 2001 21:13: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 VAA13180 for ; Fri, 20 Jul 2001 21:14:08 -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 VAA18210 for ; Fri, 20 Jul 2001 21:14:07 -0700 (PDT) Received: (qmail 23409 invoked by uid 1001); 21 Jul 2001 04:14:22 -0000 Date: 21 Jul 2001 04:14:22 -0000 Message-ID: <20010721041422.31726.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 - DNSext joint meeting, call for participation References: <200107202005.f6KK50F11379@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: > So if it's all right for your > interface ID and/or subnet information to persist for a month, but > you want to be able to change your global prefix(es) on a day's > notice, you get a 30-to-1 work savings on almost all of your RRsets. No. Under your one-month assumption, all records will be signed at least once a month, to eliminate the expiration-date security problem. The extra signings for renumbering happen only when renumbering happens. If we have 10000 30-day-notice MAC addresses with a 1-day-notice prefix, for example, and we have three renumberings over the next twenty years, the difference between AAAA and A6 is the difference between 2465000 signings and 2442305 signings. Where's the 30-to-1 savings? Put differently: You've been saying that it's painfully expensive to sign every record. But now you're admitting that this has to be done at least a dozen times every year! Of course, the other serious problem with your argument is that your one-month assumption is wrong. It is _not_ acceptable for information to persist for a month. I addressed this in my previous message, and in my ``Extremely long TTLs'' message six months ago. I'm not sure why you've waited six months to state your disagreement. ---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 Jul 20 23:38:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6L6brg09510 for ipng-dist; Fri, 20 Jul 2001 23:37:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6L6bn009503 for ; Fri, 20 Jul 2001 23:37: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 XAA08130 for ; Fri, 20 Jul 2001 23:38:02 -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 XAA01791 for ; Fri, 20 Jul 2001 23:38:01 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6L6brD08929; Sat, 21 Jul 2001 09:37:53 +0300 Date: Sat, 21 Jul 2001 09:37:53 +0300 (EEST) From: Pekka Savola To: Prema M P cc: Subject: Re: Thank you.. In-Reply-To: <20010718071105.26459.qmail@nwcst292.netaddress.usa.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 18 Jul 2001, Prema M P wrote: > I would appreciate if the following scenario's are explained : You already asked the same question less than week ago and it was answered; I guess it was lost.. > Scenario 1: > > > > Node 2 > | 1480 > 1300 | > --- Router ------------------------- > | > | 1480 > Node 1 > > > > Node 1 MTU - 1480 > Node 2 MTU - 1480 > Router (i/f) - 1300 > > > Is Node1 be able to send pkts of size 1480 to Node2 or Router ?? Yes. Yes. > Scenario 2: > > > Node 3 Node 2 > 1500 | | 1480 > | 1500 1500 | > ------------------------------Router ------------------------- > | > | 1300 > Node 1 > > > > Node 1 MTU - 1300 > Node 2 MTU - 1480 > Node 3 MTU - 1500 >  Router(i/f - node 3 side ) - 1500 > Router(i/f - node 1 & 2 side ) - 1500 > > > > If node3 needs to send pkts to node 1, will Node 1 (IP layer) be able to > receive pkts of size 1500 ?? > or If there is fragmentation, what will be the fragmented packets size?? Yes, is able to send and receive. -- 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 Jul 21 04:42:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6LBfVX09820 for ipng-dist; Sat, 21 Jul 2001 04:41:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6LBfR009813 for ; Sat, 21 Jul 2001 04:41:27 -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 EAA10903 for ; Sat, 21 Jul 2001 04:41: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 FAA26325 for ; Sat, 21 Jul 2001 05:42:58 -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 f6LBewf02145; Sat, 21 Jul 2001 18:40:58 +0700 (ICT) From: Robert Elz To: "Dave Thaler" cc: "Sreeram Vankadari" , ipng@sunroof.eng.sun.com Subject: Re: Anycast address In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1B580D9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> References: <2E33960095B58E40A4D3345AB9F65EC1B580D9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jul 2001 18:40:58 +0700 Message-ID: <2143.995715658@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 20 Jul 2001 17:11:35 -0700 From: "Dave Thaler" Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B580D9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> | First of all, RFC 2373 mandates that all 2000 addreses (and most others) | are required to have 64-bit interface identifiers, Not quite, I think what it mandates is that 64 bit interface identifiers be used for all nets in that space. It is perfectly OK to redefine smaller ID spaces if you know what you're doing (and know that this disables autoconf). Eg: it is quite common to use /127 or /128 prefixes on p2p links. | so the prefix in question would have to be 2000::/64 (a /96 is illegal). It makes no difference to the question asked, but I wouldn't say illegal, just unlikely. In particular, we do want to make sure that implementations make no assumptions about prefix length, other than what is strictly required for correct operation - you need a /64 (or wider) for autoconf, but if autoconf isn't being used, there should be no limits. | > Suppose if there are multiple routers attached to that ethernet interface, | > and a packet comes with a destination address of 2000::/128 which | > router will respond to that packet. | | Technically "any" one of them would be legal, but the answer that makes | the most sense is "the first one that the packet reaches" (i.e. the one | closest to the source). If the source is off the net, that is the way it is. I kind of suspect though that the question more assumed that the source was on the 2000::/96 (or 2000::/64 ...) ethernet. In that case the answer is "probably all of them". And typically the first response that arrives will be used, and the others will be discarded. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 21 05:35:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) id f6LCYQM09890 for ipng-dist; Sat, 21 Jul 2001 05:34:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6LCYM009883 for ; Sat, 21 Jul 2001 05:34:22 -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 FAA28594 for ; Sat, 21 Jul 2001 05:34: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 GAA05361 for ; Sat, 21 Jul 2001 06:35:53 -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 f6LCVgf02352; Sat, 21 Jul 2001 19:31:42 +0700 (ICT) From: Robert Elz cc: "Dave Thaler" , "Sreeram Vankadari" , ipng@sunroof.eng.sun.com Subject: Re: Anycast address In-Reply-To: <2143.995715658@brandenburg.cs.mu.OZ.AU> References: <2143.995715658@brandenburg.cs.mu.OZ.AU> <2E33960095B58E40A4D3345AB9F65EC1B580D9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 21 Jul 2001 19:31:42 +0700 Message-ID: <2350.995718702@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 21 Jul 2001 18:40:58 +0700 From: Robert Elz Message-ID: <2143.995715658@brandenburg.cs.mu.OZ.AU> | In that case the answer is "probably all of them". And typically the | first response that arrives will be used, and the others will be discarded. Actually, I ought to correct, or qualify, that. What will really happen, is that you'll do ND for for the anycast addr, there all of the routers will reply to the (multicast) NS packet. You will typically pick the first of those (since NA for an Anycast address is supposed to not have the O bit set). So, at that point, you'll take the first response. When you actually send the packet to the anycast address though, you'll be sending it to a unicast MAC address (from the NA response) so whichever router responded to the NS quickest will typically be the one which receives the anycast packet, and hence be the one which responds. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 21 21:50:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6M4nRh11004 for ipng-dist; Sat, 21 Jul 2001 21:49:27 -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 f6M4nNY10997 for ; Sat, 21 Jul 2001 21:49: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 VAA00086 for ; Sat, 21 Jul 2001 21:49:36 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA22741 for ; Sat, 21 Jul 2001 22:50:57 -0600 (MDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 21 Jul 2001 21:31:10 -0700 (Pacific Daylight Time) 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); Sat, 21 Jul 2001 21:31:02 -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); Sat, 21 Jul 2001 21:31:02 -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); Sat, 21 Jul 2001 21:29:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Anycast address Date: Sat, 21 Jul 2001 21:29:55 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC101671FD9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Anycast address Thread-Index: AcERg0N5cljk4yj4SZ+dPihFUyMWiwA44Ltw From: "Dave Thaler" To: "Sreeram Vankadari" Cc: X-OriginalArrivalTime: 22 Jul 2001 04:29:56.0151 (UTC) FILETIME=[F5B7C470:01C11266] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6M4nNY10998 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sreeram Vankadari writes: > > > now 2000::0/128 becomes the anycast address assigned to that > interface. > > > Suppose if there are multiple routers attached to that ethernet > interface, > > > and a packet comes with a destination address of 2000::/128 which > > > router will respond to that packet. (2000::/128 is an automatic > anycast > > > address assigned to all the ipv6 routers attached to that ethernet) > > > > Technically "any" one of them would be legal, but the answer that makes > the most sense is "the first one that the packet reaches" (i.e. the one > closest to the source). > > That is correct. But how does the receiving router know that it is the > closest > router to the source. It doesn't. The first router that sees the packet will respond. The others won't see it. -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 Sun Jul 22 12:19:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6MJI9h11900 for ipng-dist; Sun, 22 Jul 2001 12:18:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6MJI4Y11893; Sun, 22 Jul 2001 12:18:04 -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 MAA12793; Sun, 22 Jul 2001 12:18:16 -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 NAA21116; Sun, 22 Jul 2001 13:18:14 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GGW009OR2YEO3@smtp.fnal.gov>; Sun, 22 Jul 2001 14:18:14 -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 f6MJHZF17547; Sun, 22 Jul 2001 14:17:35 -0500 (CDT) Date: Sun, 22 Jul 2001 14:17:35 -0500 From: Matt Crawford Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "20 Jul 2001 22:13:22 -0000." <20010720221322.4452.qmail@cr.yp.to> To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Message-id: <200107221917.f6MJHZF17547@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ``Administrators normally insist on being able to change their records > with at most a few days notice,'' my web page says, as a starting point > for analyzing the expiration-date security issues. Yes, it does indeed say that. It has to say it, because imposing that ad-hoc restriction is necessary in order to drive to the conclusion you want. Bu tthat doesn't make it so, especially when different records record information with clearly different volatility. > Matt Crawford writes: > > then the signatures on the A6 records covering interface identifiers > > and subnets can be valid for a long time, > > No, they cannot, because that would allow an attacker to interfere with > updates. This is the security issue analyzed on my web page. No, it is not analyzed. What you assert is true, but you have not explored the ramifications. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 22 12:34:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6MJW5m12000 for ipng-dist; Sun, 22 Jul 2001 12:32:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6MJW0Y11993; Sun, 22 Jul 2001 12:32:00 -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 MAA13454; Sun, 22 Jul 2001 12:32:12 -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 NAA16727; Sun, 22 Jul 2001 13:33:33 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GGW00EBB3LMQC@smtp.fnal.gov>; Sun, 22 Jul 2001 14:32:10 -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 f6MJVVF17614; Sun, 22 Jul 2001 14:31:31 -0500 (CDT) Date: Sun, 22 Jul 2001 14:31:31 -0500 From: Matt Crawford Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "21 Jul 2001 04:14:22 -0000." <20010721041422.31726.qmail@cr.yp.to> To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se Message-id: <200107221931.f6MJVVF17614@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Matt Crawford writes: > > So if it's all right for your > > interface ID and/or subnet information to persist for a month, but > > you want to be able to change your global prefix(es) on a day's > > notice, you get a 30-to-1 work savings on almost all of your RRsets. > > No. Under your one-month assumption, all records will be signed at least > once a month, to eliminate the expiration-date security problem. The > extra signings for renumbering happen only when renumbering happens. > > If we have 10000 30-day-notice MAC addresses with a 1-day-notice prefix, > for example, and we have three renumberings over the next twenty years, > the difference between AAAA and A6 is the difference between 2465000 > signings and 2442305 signings. Where's the 30-to-1 savings? It's in the arithmetic, which I will do for you. If you'll permit, I'll round off to 360 days per year to make everything transparent. Scenario AAAA: sign every RRset every day for 20 years. 10,000 x 360 x 20 = 72,000,000 Scenario A6: sign the suffix RRsets 12 times a year for 20 years, sign the one prefix RRset every day for 20 years. ( 10,000 x 12 x 20 ) + ( 1 x 360 x 20 ) = 2,407,200 Ratio: 29.91 to 1. This reminds me of a previous argument. > Put differently: You've been saying that it's painfully expensive to > sign every record. Some may have said that, but I didn't. > But now you're admitting that this has to be done at least a dozen > times every year! You seem surprised. > Of course, the other serious problem with your argument is that your > one-month assumption is wrong. It is _not_ acceptable for information to > persist for a month. Sometimes yes, sometimes no. With A6 you get to treat parts differently, according to their needs. (And to whoever it was, not Dan, I think, who said you can't override the MAC address on some hardware: that's utterly irrelevant. You don't need to autoconfigure your address and even if you do, you don't need to use only that address.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 00:46:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6N7jo712907 for ipng-dist; Mon, 23 Jul 2001 00:45:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6N7jlY12900 for ; Mon, 23 Jul 2001 00:45: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 AAA06286 for ; Mon, 23 Jul 2001 00:45:59 -0700 (PDT) Received: from atlrel6.hp.com (atlrel6.hp.com [192.151.27.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18995 for ; Mon, 23 Jul 2001 00:45:42 -0700 (PDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel6.hp.com (Postfix) with ESMTP id C8F871F63B for ; Mon, 23 Jul 2001 03:45:39 -0400 (EDT) Received: from india.hp.com (sakreddy@deer.india.hp.com [15.10.44.44]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id NAA05265 for ; Mon, 23 Jul 2001 13:12:37 +0530 (IST) Message-ID: <3B5BD724.63910D7@india.hp.com> Date: Mon, 23 Jul 2001 13:19:57 +0530 From: "Anil Kumar Reddy. S" Reply-To: sakreddy@india.hp.com Organization: Hewlett-Packard X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Regarding IPV6_RECVPKTINFO. References: <3B54E927.C554BFCA@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi , 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 : char buf[256] ; ssize_t n; int len; struct msghdr msg; struct iovec iov[1]; struct sockaddr_in6 sa; struct cmsghdr *cmptr, *cmsgptr; union { struct cmsghdr cm; char control[CMSG_SPACE(sizeof(struct in6_addr)) + CMSG_SPACE(sizeof(struct in6_pktinfo))]; } control_un; memset (pktp, 0, sizeof(struct in6_pktinfo)); len = sizeof(sa); msg.msg_control = control_un.control; msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; msg.msg_name = &sa; msg.msg_namelen = len; iov[0].iov_base = buf; iov[0].iov_len = 256; msg.msg_iov = iov; msg.msg_iovlen = 1; if ((n = recvmsg(sfd, &msg, flags) < 0)) { printf ("recvmsg : %m "); return -1; } if (msg.msg_controllen < sizeof(struct cmsghdr) || (msg.msg_flags & MSG_CTRUNC)) { return -1; } for (cmptr = CMSG_FIRSTHDR(&msg); cmptr != NULL; cmptr = CMSG_NXTHDR(&msg, cmptr)) { printf (" ancillary data, len=%d, level=%d, type=%d ", cmptr->cmsg_len, cmptr->cmsg_level, cmptr->cmsg_type); if (cmptr->cmsg_level == IPPROTO_IPV6 && cmptr->cmsg_type == IPV6_RECVPKTINFO) { memcpy(pktp, CMSG_DATA(cmptr), sizeof(struct in6_pktinfo )); continue; } } Please let me know, if I am wrong in any place. Thanks in advance. Best regards, Anil. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 01:32:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6N8VXC13094 for ipng-dist; Mon, 23 Jul 2001 01:31:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6N8VUY13087 for ; Mon, 23 Jul 2001 01:31: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 BAA26888 for ; Mon, 23 Jul 2001 01:31:43 -0700 (PDT) Received: from atlrel7.hp.com (atlrel7.hp.com [192.151.27.9]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10152 for ; Mon, 23 Jul 2001 01:31:43 -0700 (PDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel7.hp.com (Postfix) with ESMTP id 2D16F1F621 for ; Mon, 23 Jul 2001 04:30:46 -0400 (EDT) Received: from india.hp.com (sakreddy@deer.india.hp.com [15.10.44.44]) by hpuxsrv.india.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id NAA09860 for ; Mon, 23 Jul 2001 13:58:26 +0530 (IST) Message-ID: <3B5BE1E1.CC9986A5@india.hp.com> Date: Mon, 23 Jul 2001 14:05:45 +0530 From: "Anil Kumar Reddy. S" Reply-To: sakreddy@india.hp.com Organization: Hewlett-Packard X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: IPng Subject: Regarding IPV6_RECVPKTINFO. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi , 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 : char buf[256] ; ssize_t n; int len; struct msghdr msg; struct iovec iov[1]; struct sockaddr_in6 sa; struct cmsghdr *cmptr, *cmsgptr; union { struct cmsghdr cm; char control[CMSG_SPACE(sizeof(struct in6_addr)) + CMSG_SPACE(sizeof(struct in6_pktinfo))]; } control_un; memset (pktp, 0, sizeof(struct in6_pktinfo)); len = sizeof(sa); msg.msg_control = control_un.control; msg.msg_controllen = sizeof(control_un.control); msg.msg_flags = 0; msg.msg_name = &sa; msg.msg_namelen = len; iov[0].iov_base = buf; iov[0].iov_len = 256; msg.msg_iov = iov; msg.msg_iovlen = 1; if ((n = recvmsg(sfd, &msg, flags) < 0)) { printf ("recvmsg : %m "); return -1; } if (msg.msg_controllen < sizeof(struct cmsghdr) || (msg.msg_flags & MSG_CTRUNC)) { return -1; } for (cmptr = CMSG_FIRSTHDR(&msg); cmptr != NULL; cmptr = CMSG_NXTHDR(&msg, cmptr)) { printf (" ancillary data, len=%d, level=%d, type=%d ", cmptr->cmsg_len, cmptr->cmsg_level, cmptr->cmsg_type); if (cmptr->cmsg_level == IPPROTO_IPV6 && cmptr->cmsg_type == IPV6_RECVPKTINFO) { memcpy(pktp, CMSG_DATA(cmptr), sizeof(struct in6_pktinfo )); continue; } } Please let me know, if I am wrong in any place. Thanks in advance. Best regards, Anil. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 03:43:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NAe2g13608 for ipng-dist; Mon, 23 Jul 2001 03:40:02 -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 f6NAdvY13601 for ; Mon, 23 Jul 2001 03:39: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 DAA11736 for ; Mon, 23 Jul 2001 03:40:09 -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 DAA21736 for ; Mon, 23 Jul 2001 03:40:06 -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 GAA09181; Mon, 23 Jul 2001 06:39:08 -0400 (EDT) Message-Id: <200107231039.GAA09181@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-1394-02.txt Date: Mon, 23 Jul 2001 06:39:07 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Transmission of IPv6 Packets over IEEE 1394 Networks Author(s) : K. Fujisawa, A. Onoe Filename : draft-ietf-ipngwg-1394-02.txt Pages : 8 Date : 20-Jul-01 IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. This document describes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-1394-02.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-1394-02.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-1394-02.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: <20010720082804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-1394-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-1394-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010720082804.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 Jul 23 07:42:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NEfbK14538 for ipng-dist; Mon, 23 Jul 2001 07:41:37 -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 f6NEfXY14531 for ; Mon, 23 Jul 2001 07:41: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 HAA00621 for ; Mon, 23 Jul 2001 07:41:45 -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 IAA26200 for ; Mon, 23 Jul 2001 08:43:07 -0600 (MDT) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6NEfmg14128; Mon, 23 Jul 2001 07:41:48 -0700 (PDT) Received: from stewart.chicago.il.us (dhcp-64-102-95-112.cisco.com [64.102.95.112]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id APW02952 (AUTH rrs); Mon, 23 Jul 2001 07:41:42 -0700 (PDT) Message-ID: <3B5C37A5.863E34C@stewart.chicago.il.us> Date: Mon, 23 Jul 2001 09:41:41 -0500 From: Randall Stewart X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: ipng@sunroof.eng.sun.com Subject: Re: FW: I-D ACTION:draft-stewart-tsvwg-sctpipv6-00.txt References: <01D91AFB08B6D211BFD00008C7EABAE10680B268@eseis04nok> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John: to answer a question.. john.loughney@nokia.com wrote: > > Hi all, > > For those of you not aware, there is a new transport level > protocol, SCTP. This protocol supports transport level > multihoming, by allowing endpoints to exchanging IP addresses > in the association intitialization messages. > > This can cause some problems by allowing IP addresses to > escape their scope, thus introducing the possibilities for > some black holes. > > I'm not sure if Randy Stewart is subscribed or not (primary > author of SCTP), but if he isn't, I can field some questions > about SCTP (if they aren't too tough!) ... Yes, I do subscribe but I am currently in a email burial (I am at least 6 feet under :-0) and I don't think I will be able to work my way out until next week... sigh.. I will try to catch up but your help is always appreciated :) R > > Just a small deployment note - SCTP should start seeing some > deployment later this year in 3G networks, as a signaling > bearer for some radio access protocols, so it would be a > good idea to try make sure that this issue is nailed down. > > thanks, > John > > > Title : IPv6 addressing and Stream Control > > Transmission Protocol > > Author(s) : R. Stewart, S. Deering > > Filename : draft-stewart-tsvwg-sctpipv6-00.txt > > Pages : > > Date : 02-Jul-01 > > > > Stream Control Transmission Protocol [RFC2960] provides transparent > > multi-homing to its upper layer users. This multi-homing is > > accomplished through the passing of address parameters in the > > initial setup message used by SCTP. In an IPv4 network all addresses > > are passed with no consideration for their scope and routeablility. > > In a IPv6 network special considerations MUST be made to properly > > bring up associations between SCTP endpoints that have IPv6 > > [RFC2460] addresses bound within their association. This document > > defines those considerations and enumerates general rules > > that an SCTP endpoint MUST use in formulating both the INIT and > > INIT-ACK chunks. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-stewart-tsvwg-sctpipv6-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 > -------------------------------------------------------------------- -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 07:53:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NEr8214595 for ipng-dist; Mon, 23 Jul 2001 07:53:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NEr5Y14588 for ; Mon, 23 Jul 2001 07:53:05 -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 HAA10342 for ; Mon, 23 Jul 2001 07:53:17 -0700 (PDT) From: pete@loshin.com Received: from chmls05.mediaone.net (chmls05.mediaone.net [24.147.1.143]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00205 for ; Mon, 23 Jul 2001 07:53:15 -0700 (PDT) Received: from gateway.loshin (h00a0c5e1478f.ne.mediaone.net [24.147.211.223]) by chmls05.mediaone.net (8.11.1/8.11.1) with ESMTP id f6NErCa06551 for ; Mon, 23 Jul 2001 10:53:13 -0400 (EDT) Received: from gateway.loshin (IDENT:pete@localhost.localdomain [127.0.0.1]) by gateway.loshin (8.9.3/8.9.3) with ESMTP id KAA02865 for ; Mon, 23 Jul 2001 10:46:50 -0400 Message-Id: <200107231446.KAA02865@gateway.loshin> X-Mailer: exmh version 2.1.1 10/15/1999 To: ipng@sunroof.eng.sun.com Subject: Re: questions for article about IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Jul 2001 10:46:50 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A while back (July 5), I wrote: > if anyone wants, I can summarize direct responses. I've received a number of requests for the summary, so here it is: I received one response to the original request, basically saying that NAT breaks end-to-endness and therefore breaks IPsec, but NATs can be useful for protecting against DoS. Using other sources, the article has been turned in and should be in the August issue of Information Security Magazine. -pl -- +-------------------------------------------------------------+ | Pete Loshin http://www.loshin.com | | pete@loshin.com +1 781/646-6318 | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 07:59:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NEwkA14629 for ipng-dist; Mon, 23 Jul 2001 07:58:46 -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 f6NEwgY14622 for ; Mon, 23 Jul 2001 07:58:42 -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 HAA02606 for ; Mon, 23 Jul 2001 07:58:50 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05456 for ; Mon, 23 Jul 2001 09:00:13 -0600 (MDT) Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15OhAV-000CQs-00; Mon, 23 Jul 2001 07:58:47 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: pete@loshin.com Cc: ipng@sunroof.eng.sun.com Subject: Re: questions for article about IPv6 References: <200107231446.KAA02865@gateway.loshin> Message-Id: Date: Mon, 23 Jul 2001 07:58:47 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > NATs can be useful for protecting against DoS. an oft repeated fantasy. complete and utter bs, of course. randy, channeling keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 23 08:23:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NFMW514790 for ipng-dist; Mon, 23 Jul 2001 08:22:32 -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 f6NFMSY14783 for ; Mon, 23 Jul 2001 08:22:28 -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 IAA08970 for ; Mon, 23 Jul 2001 08:22:40 -0700 (PDT) From: pete@loshin.com Received: from chmls20.mediaone.net (chmls20.mediaone.net [24.147.1.156]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17865 for ; Mon, 23 Jul 2001 08:22:40 -0700 (PDT) Received: from gateway.loshin (h00a0c5e1478f.ne.mediaone.net [24.147.211.223]) by chmls20.mediaone.net (8.11.1/8.11.1) with ESMTP id f6NFMdc20066; Mon, 23 Jul 2001 11:22:39 -0400 (EDT) Received: from gateway.loshin (IDENT:pete@localhost.localdomain [127.0.0.1]) by gateway.loshin (8.9.3/8.9.3) with ESMTP id LAA02966; Mon, 23 Jul 2001 11:16:15 -0400 Message-Id: <200107231516.LAA02966@gateway.loshin> X-Mailer: exmh version 2.1.1 10/15/1999 To: Randy Bush Cc: ipng@sunroof.eng.sun.com Subject: Re: questions for article about IPv6 In-Reply-To: Your message of "Mon, 23 Jul 2001 07:58:47 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Jul 2001 11:16:15 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > NATs can be useful for protecting against DoS. > > an oft repeated fantasy. complete and utter bs, of course. Whatever. I was asked to summarize responses; that was _the_ response I got, so I summarized it. That several people requested the summary indicates the original topic (security implications of IPv6--not NATs) might be worth discussing on the list. -pl -- +-------------------------------------------------------------+ | Pete Loshin http://www.loshin.com | | pete@loshin.com +1 781/646-6318 | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 11:43:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NIh9s16149 for ipng-dist; Mon, 23 Jul 2001 11:43:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NIh5Y16142 for ; Mon, 23 Jul 2001 11:43:06 -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 LAA00608 for ; Mon, 23 Jul 2001 11:43:17 -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 LAA28044 for ; Mon, 23 Jul 2001 11:43:12 -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 OAA63646 for ; Mon, 23 Jul 2001 14:35: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 f6NIglu16042 for ; Mon, 23 Jul 2001 14:42:47 -0400 Importance: Normal Subject: IPv6MIBs IPv4-mapped address questions To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kristine Adamson" Date: Mon, 23 Jul 2001 14:43:09 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/23/2001 02:43:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I posted the following questions to this mailing list on 6/22 but I have not received any response yet. Now that the proposed MIBs are IETF internet drafts should I still expect an answer to my questions on this mailing list or should I repost my questions somewhere else? > I am an SNMP developer and have just subscribed to this mailing list, so I > apologize if there has already been a discussion on this subject. I > noticed that the IPv6 MIB Design Team internet drafts for the revised TCP > and UDP MIBs, define version neutral MIB tables. For a server application > that opens an AF_INET6 socket and binds to the unspecified address (without > setting the IPv6_V6ONLY socket option), should there be two entries in > these MIB tables, one with the local address as IPv4/INADDR_ANY and one > with the local address as IPv6/unspecified? Or should there be one entry > with the local address as IPv6/unspecified? What if the server application > opened an AF_INET6 socket and bound to an IPv4-mapped address? Would there > be one entry in the tables with the local address as IPv4/address or as > IPv6/IPv4-mapped address? I think my real question is, are the table > entries supposed to reflect the IP address type from the view of the flow > of the packets on the network, or from the viewpoint of the address family > of the socket with which the connection/listener is associated? Thanks! Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 23 13:52:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NKpt616552 for ipng-dist; Mon, 23 Jul 2001 13:51:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NKpoY16545; Mon, 23 Jul 2001 13:51:50 -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 NAA06829; Mon, 23 Jul 2001 13:52:03 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16847; Mon, 23 Jul 2001 13:52:01 -0700 (PDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GGY003DN1YM22@smtp.fnal.gov>; Mon, 23 Jul 2001 15:51:58 -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 f6NKoAm04601; Mon, 23 Jul 2001 15:50:10 -0500 (CDT) Date: Mon, 23 Jul 2001 15:50:10 -0500 From: Matt Crawford Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: "20 Jul 2001 05:43:07 PDT." To: Alain Durand , Olafur Gudmundsson Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Message-id: <200107232050.f6NKoAm04601@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The NGtrans/DNSext chairs would like to make a call for participation > in the upcoming joint meeting. > ... > Anybody wishing to make a presentation should send a draft > to the chairs of this meeting before July 26th 2001, 21:00 UTC > (that is, 2pm PDT, 5pm EDT, 11pm MEST) > - Alain Durand > - Olafur Gudmundsson > > Drafts not yet published by the ID editor are acceptable > contributions (please include an URL). I offer http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 13:56:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NKu1V16619 for ipng-dist; Mon, 23 Jul 2001 13:56:01 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6NKtwY16612 for ; Mon, 23 Jul 2001 13:55:58 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6NKsdR01378 for ipng@sunroof.eng.sun.com; Mon, 23 Jul 2001 13:54:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.5.Beta0+Sun/8.11.5.Beta0) with ESMTP id f6L1Kk009078 for ; Fri, 20 Jul 2001 18:20:46 -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 SAA00929 for ; Fri, 20 Jul 2001 18:21:00 -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 SAA16728 for ; Fri, 20 Jul 2001 18:21:00 -0700 (PDT) Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f6L1L9319485; Fri, 20 Jul 2001 18:21:09 -0700 (PDT) Received: from cisco.com (sreeramv-u10.cisco.com [171.69.42.43]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id AJL00840 (AUTH sreeramv); Fri, 20 Jul 2001 18:20:59 -0700 (PDT) Message-ID: <3B58D8FB.75BD9BFA@cisco.com> Date: Fri, 20 Jul 2001 18:20:59 -0700 From: Sreeram Vankadari Organization: cisco Systems Inc. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: ipng@sunroof.eng.sun.com Subject: Re: Anycast address References: <2E33960095B58E40A4D3345AB9F65EC1B580D9.3497@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Thaler wrote: > > Sreeram Vankadari [mailto:sreeram.vankadari@cisco.com] writes: > > Suppose the ipv6 prefix assigned to an interface is 2000::1234:5678/96. > > First of all, RFC 2373 mandates that all 2000 addreses (and most others) are required to have 64-bit interface identifiers, so the prefix in question would have to be 2000::/64 (a /96 is illegal). (Also keep in mind that you can assign many prefixes to the same interface.) > > So I'll assume it's a typo and you meant: > "Suppose the IPv6 prefix 2000::/64 is assigned to an interface." Okay. > > > now 2000::0/128 becomes the anycast address assigned to that interface. > > Suppose if there are multiple routers attached to that ethernet interface, > > and a packet comes with a destination address of 2000::/128 which > > router will respond to that packet. (2000::/128 is an automatic anycast > > address assigned to all the ipv6 routers attached to that ethernet) > > Technically "any" one of them would be legal, but the answer that makes the most sense is "the first one that the packet reaches" (i.e. the one closest to the source). That is correct. But how does the receiving router know that it is the closest router to the source. Sreeram. > > -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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 14:01:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6NL0nc16664 for ipng-dist; Mon, 23 Jul 2001 14:00:49 -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 f6NL0hY16655; Mon, 23 Jul 2001 14:00: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 OAA20423; Mon, 23 Jul 2001 14:00:47 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26473; Mon, 23 Jul 2001 15:02:08 -0600 (MDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id C062D177A; Mon, 23 Jul 2001 14:00:44 -0700 (PDT) Date: Mon, 23 Jul 2001 14:00:44 -0700 From: David Terrell 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 - DNSext joint meeting, call for participation Message-ID: <20010723140044.A17822@pianosa.catch22.org> Reply-To: David Terrell References: <200107202005.f6KK50F11379@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from djb@cr.yp.to on Sat, Jul 21, 2001 at 12:41:13AM -0700 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 1:59PM up 2 days, 16:41, 35 users, load averages: 0.26, 0.23, 0.26 X-Baby: Theodore Marvin Wolpinsky Terrell born 145 days, 23 hours, 13 minutes, 48 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, Jul 21, 2001 at 12:41:13AM -0700, D. J. Bernstein wrote: > Of course, the other serious problem with your argument is that your > one-month assumption is wrong. It is _not_ acceptable for information to > persist for a month. I addressed this in my previous message, and in my > ``Extremely long TTLs'' message six months ago. I'm not sure why you've > waited six months to state your disagreement. Did I miss somewhere where the expiration of the cryptographic signature was defined to replace the normal DNS TTL on the record? -- 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 Mon Jul 23 17:28:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6O0RZD17579 for ipng-dist; Mon, 23 Jul 2001 17:27:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6O0RWY17572 for ; Mon, 23 Jul 2001 17:27:32 -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 RAA19275 for ; Mon, 23 Jul 2001 17:27:45 -0700 (PDT) Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA24680 for ; Mon, 23 Jul 2001 18:27:43 -0600 (MDT) Received: from rm-114b6.ee.calpoly.edu (HELO pebbles) (129.65.132.187) by smtp.mail.vip.sc5.yahoo.com with SMTP; 24 Jul 2001 00:27:44 -0000 X-Apparently-From: Message-ID: <00df01c113d7$45a62fa0$bb844181@bedrock.calpoly.edu> From: "Jose Melara" To: Subject: Bad file descriptor error during CONNECT...what to do? Date: Mon, 23 Jul 2001 17:26:24 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DC_01C1139C.990D5BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00DC_01C1139C.990D5BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I am learning how to use IPv6 and I am working on a simple Ipv6 = client/server application. My problem is that after I do a connect on = the client side I am getting a Bad File Descriptor error. =20 Here's how the application works: 1) the server decides on the port. 2) = The client takes the name of the server and the port number assigned by = the server as arguments (argv[s]) and should stablish a connection. Here is my code for the client, I'd appreciate your help on telling me = what could be going wrong. Thank you very much for your time, I greatly appreciate it. Jose Melara (student) /* -------------------------------------------------------------- * * tcp6_send_setup() function *=20 * --------------------------------------------------------------*/ int32_t tcp6_send_setup(char * host_name, char * port) { int32_t server_socket=3D -1; int32_t i_connect =3D -1; /* for testing purposes */ =20 char *int_port; struct sockaddr_in6 server6; /* socket address for the server */ struct hostent *hostinfo; /* address of server */=20 char *addr_pptr; /* create the socket */ server_socket =3D socket(PF_INET6, SOCK_STREAM,0); cout << "server_socket: " << server_socket << endl; /* designate the addressing family */ server6.sin6_family =3D AF_INET6; server6.sin6_addr =3D in6addr_any; //wildcard=20 server6.sin6_flowinfo =3D 0; // ALLOCATE MEMORY -- I took this out to save you time... /* Get server info */ hostinfo =3D gethostbyname2(host_name, AF_INET6); /* copy to server6 structure */ memcpy((char *)server6.sin6_addr.s6_addr,(char = *)hostinfo->h_addr_list[0], INET6_ADDRLEN); /* get the port used on the remote side and store */ server6.sin6_port =3D atoi(port); if (i_connect =3D connect(server_socket, (struct sockaddr *)&server6, = sizeof(INET6_ADDRLEN)) < 0) { close (server_socket); cout << "ERROR connecting stream socket ERROR#" << i_connect << endl; = perror(""); exit(1); } return (server_socket); }//end function ------=_NextPart_000_00DC_01C1139C.990D5BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi! I am learning how to use IPv6 and I = am working=20 on a simple Ipv6 client/server application. My problem is that after I = do a=20 connect on the client side I am getting a Bad File Descriptor = error. =20
 
Here's how the application works: 1) = the server=20 decides on the port. 2) The client takes the name of the server and the = port=20 number assigned by the server as arguments (argv[s]) and should stablish = a=20 connection.
 
Here is my code for the client, I'd = appreciate your=20 help on telling me what could be going wrong.
 
Thank you very much for your time, I = greatly=20 appreciate it.
 
Jose Melara (student)
 
/* = --------------------------------------------------------------
*
* tcp6_send_setup() function
*
* = --------------------------------------------------------------*/
int32_t tcp6_send_setup(char * host_name, char * port)
{
  int32_t server_socket=3D -1;
  int32_t i_connect =3D -1; /* for testing purposes */  =
  char *int_port;
  struct sockaddr_in6 server6; /* socket address for the = server=20 */
  struct hostent *hostinfo; /* address of server */
  char *addr_pptr;
 
/* create the socket */
server_socket =3D socket(PF_INET6, SOCK_STREAM,0);
cout << "server_socket: " << server_socket << = endl;
 
/* designate the addressing family */
server6.sin6_family =3D AF_INET6;
server6.sin6_addr =3D in6addr_any; //wildcard
server6.sin6_flowinfo =3D 0;
 
// ALLOCATE MEMORY -- I took this out to save you time...
 
/* Get server info */
hostinfo =3D gethostbyname2(host_name, AF_INET6);
 
/* copy to server6 structure */
 
memcpy((char *)server6.sin6_addr.s6_addr,(char=20 *)hostinfo->h_addr_list[0], INET6_ADDRLEN);
 
/* get the port used on the remote side and store */
 
server6.sin6_port =3D atoi(port);
 
if (i_connect =3D connect(server_socket, (struct sockaddr = *)&server6,=20 sizeof(INET6_ADDRLEN)) < 0)
{
  close (server_socket);
  cout << "ERROR connecting stream socket ERROR#" = <<=20 i_connect << endl; 
  perror("");
  exit(1);
}
  return (server_socket);
 
}//end function
 ------=_NextPart_000_00DC_01C1139C.990D5BE0-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.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 Jul 23 21:38:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6O4bZ617886 for ipng-dist; Mon, 23 Jul 2001 21:37:35 -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 f6O4bVY17879 for ; Mon, 23 Jul 2001 21:37: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 VAA04286 for ; Mon, 23 Jul 2001 21:37:44 -0700 (PDT) Received: from smtp4.ihug.co.nz (smtp4.ihug.co.nz [203.109.252.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25959 for ; Mon, 23 Jul 2001 22:37:42 -0600 (MDT) Received: from mt (203-173-229-118.chc.ihugultra.co.nz [203.173.229.118]) by smtp4.ihug.co.nz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id QAA08747 for ; Tue, 24 Jul 2001 16:37:41 +1200 X-Authentication-Warning: smtp4.ihug.co.nz: Host 203-173-229-118.chc.ihugultra.co.nz [203.173.229.118] claimed to be mt Message-ID: <001501c113fb$1134da40$010a0a0a@mt> From: "Sean Lin" To: Subject: ipv6 header checksum Date: Tue, 24 Jul 2001 16:42:37 +1200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C1145F.A57CC230" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C1145F.A57CC230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As we all know, there's no ipv6 header checksum field. Therefore, = for routers forwarding packets, the checksum of ipv6 packets cannot be = calculated? Which means that ipv6 routers will generally have a faster = throughput compared to a similar ipv4 router (assuming there's no = extension headers and option headers)? Regards, Sean ------=_NextPart_000_0012_01C1145F.A57CC230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
    As we all know, = there's no ipv6=20 header checksum field. Therefore, for routers forwarding packets, the = checksum=20 of ipv6 packets cannot be calculated? Which means that ipv6 routers will = generally have a faster throughput compared to a similar ipv4 router = (assuming=20 there's no extension headers and option headers)?
 
 
Regards,
Sean
------=_NextPart_000_0012_01C1145F.A57CC230-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 24 00:49:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6O7mPL18116 for ipng-dist; Tue, 24 Jul 2001 00:48:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6O7mMY18109 for ; Tue, 24 Jul 2001 00:48:22 -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 AAA21718 for ; Tue, 24 Jul 2001 00:48:35 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA05646 for ; Tue, 24 Jul 2001 01:49:58 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 8E8A31ECD3; Tue, 24 Jul 2001 03:48:33 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id DAA17569; Tue, 24 Jul 2001 03:48:29 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id AAA29985; Tue, 24 Jul 2001 00:48:29 -0700 (PDT) Message-Id: <200107240748.AAA29985@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: adamson@us.ibm.com Subject: Re: IPv6MIBs IPv4-mapped address questions Cc: ipng@sunroof.eng.sun.com Date: Tue, 24 Jul 2001 00:48:29 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kristine, I'm sorry I missed your email the first time you sent it. > For a server application > that opens an AF_INET6 socket and binds to the unspecified address (without > setting the IPv6_V6ONLY socket option), should there be two entries in > these MIB tables, one with the local address as IPv4/INADDR_ANY and one > with the local address as IPv6/unspecified? Or should there be one entry > with the local address as IPv6/unspecified? This is one of the open issues. I think we've been leaning towards InetAddressType == Unknown, and a zero-length InetAddress. > What if the server application > opened an AF_INET6 socket and bound to an IPv4-mapped address? Would there > be one entry in the tables with the local address as IPv4/address or as > IPv6/IPv4-mapped address? This is a good question, and one which I hadn't thought of. There should be a canonical answer, since otherwise managers will have to check both IPv4 and IPv6-mapped addresses if they're looking for a specific row. That implies that the answer should represent the AF on the wire, not necessarily the socket, and perhaps the MIBs should prohibit using InetAddressType=ipv6 and IN6_IS_ADDR_V4MAPPED(InetAddress). 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 Jul 24 01:27:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6O8R0118218 for ipng-dist; Tue, 24 Jul 2001 01:27:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6O8QuY18211 for ; Tue, 24 Jul 2001 01:26:56 -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 BAA24977 for ; Tue, 24 Jul 2001 01:27:10 -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 CAA25560 for ; Tue, 24 Jul 2001 02:27:03 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA22888; Tue, 24 Jul 2001 10:27:00 +0200 (MET DST) Date: Tue, 24 Jul 2001 10:27:00 +0200 From: Ignatios Souvatzis To: Sean Lin Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum Message-ID: <20010724102700.A22834@theory.cs.uni-bonn.de> References: <001501c113fb$1134da40$010a0a0a@mt> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <001501c113fb$1134da40$010a0a0a@mt>; from mtl23@student.canterbury.ac.nz on Tue, Jul 24, 2001 at 04:42:37PM +1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jul 24, 2001 at 04:42:37PM +1200, Sean Lin wrote: > As we all know, there's no ipv6 header checksum field. Therefore, > for routers forwarding packets, the checksum of ipv6 packets cannot be > calculated? Which means that ipv6 routers will generally have a faster > throughput compared to a similar ipv4 router (assuming there's no > extension headers and option headers)? Yes. That's the reason it was designed that way. -is --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO10xUDCn4om+4LhpAQF6Lwf/Ur2jGmKOLcQcbzk2DdBf2hv1KvjpdXu0 jxIdI7ibAv87UrJ//Zsj5cGbN8pajXiYG/7RUpbg/f69OLUc1VaDoAA/HRcTtw0x QOaA/NX9IExx9bnA1cohrXhGNJ9PnRs054YNUMMetDm+MOqYo+Q71lCG8jkgYCUU 1utKTe1UApOj03XQngfC43EVBVIM96BXZHjZJ+VEOFZ/nIT7Wz/kjfePzY4BGCro Kv60wud6mJN71KbWBNajrvY+nL25Np0dsbxWK63JoFDgVcoCa71nzku5tFtlJWn2 NHYIfBN1i4E5J1h5omZFayL/om+J9b50ax/6ExDgsJBqJO/nfBX58Q== =jUoG -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 24 03:30:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OAU9g18351 for ipng-dist; Tue, 24 Jul 2001 03:30:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OAU5Y18344 for ; Tue, 24 Jul 2001 03:30: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 DAA12255 for ; Tue, 24 Jul 2001 03:30:17 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23231 for ; Tue, 24 Jul 2001 04:30:15 -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 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 Tue Jul 24 05:08:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OC7Cf18437 for ipng-dist; Tue, 24 Jul 2001 05:07:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OC79Y18430 for ; Tue, 24 Jul 2001 05:07: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 FAA18722 for ; Tue, 24 Jul 2001 05:07:22 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04389 for ; Tue, 24 Jul 2001 06:07:19 -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 HAA97918 for ; Tue, 24 Jul 2001 07:59:43 -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 f6OC6uu20572 for ; Tue, 24 Jul 2001 08:06:56 -0400 Importance: Normal Subject: Re: IPv6MIBs IPv4-mapped address questions To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kristine Adamson" Date: Tue, 24 Jul 2001 08:07:19 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/24/2001 08:07:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, Thanks for your responses. Do you think some of these open issues will be discussed during the upcoming IETF meeting in London? I see you are on the agenda to present the MIBs. Thanks! Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 24 07:47:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OEkoE18717 for ipng-dist; Tue, 24 Jul 2001 07:46:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OEkkY18710 for ; Tue, 24 Jul 2001 07:46: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 HAA26511 for ; Tue, 24 Jul 2001 07:46:59 -0700 (PDT) Received: from cisco.com (jaws.cisco.com [198.135.0.150]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10082 for ; Tue, 24 Jul 2001 07:46:58 -0700 (PDT) Received: from cisco.com (lon-sto4-lan-vlan133-dhcp47.cisco.com [144.254.108.114]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA27411; Tue, 24 Jul 2001 15:46:57 +0100 (BST) Message-ID: <3B5D8A2F.ECBF243F@cisco.com> Date: Tue, 24 Jul 2001 15:46:07 +0100 From: Dario Accornero Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en, it MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: fenner@research.att.com Subject: Latest IPv6 MIBs revision Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I have a couple of questions about the latest revision (12th July) of draft-ietf-ipngwg-rfc2011-update-00.txt : 1. ipIfStatsTable: Why {In,Out}Octets and {In,Out}McastOctets are declared as Counter32 instead of as Counter64 ? 2. ipIfStatsTable: Why there are no accurate descriptions of the new counters, besides {In,Out}Octets ? Thank you, -- Dario Accornero - IOS Europe Development - IPv6 Team Stockley Park, Uxbridge, UK - voice +44 20 8756 6268 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 24 11:40:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OId0c20597 for ipng-dist; Tue, 24 Jul 2001 11:39:00 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OIcwY20590 for ; Tue, 24 Jul 2001 11:38:58 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6OIbbN01850 for ipng@sunroof.eng.sun.com; Tue, 24 Jul 2001 11:37:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OF7iY18782 for ; Tue, 24 Jul 2001 08:07:44 -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 IAA10156 for ; Tue, 24 Jul 2001 08:07:57 -0700 (PDT) Received: from uniwest2.it.west.unispheremetworks.com ([65.194.140.146]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07329 for ; Tue, 24 Jul 2001 09:09:21 -0600 (MDT) Received: by UNIWEST2 with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 11:06:26 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-187.dhcp.west.unispherenetworks.com [10.10.120.187]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3VN5G611; Tue, 24 Jul 2001 11:07:41 -0400 From: "Kastenholz, Frank" To: Ignatios Souvatzis , Sean Lin Cc: ipng@sunroof.eng.sun.com Message-Id: <5.0.2.1.2.20010724105657.00b05910@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 24 Jul 2001 11:09:23 -0400 Subject: Re: ipv6 header checksum In-Reply-To: <20010724102700.A22834@theory.cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:27 AM 7/24/01 -0400, Ignatios Souvatzis wrote: >On Tue, Jul 24, 2001 at 04:42:37PM +1200, Sean Lin wrote: > >> As we all know, there's no ipv6 header checksum field. Therefore, >> for routers forwarding packets, the checksum of ipv6 packets cannot be >> calculated? Which means that ipv6 routers will generally have a faster >> throughput compared to a similar ipv4 router (assuming there's no >> extension headers and option headers)? > >Yes. That's the reason it was designed that way. For software based forwarding engines, you are correct. However, most if not all high-speed routers one encounters today use silicon-based (ASICs and/or FPGAs) forwarders. The nice thing about silicon is that lots of stuff can be done in parallel. The IPv4 header checksum can be, and is, calculated in parallel with the other header checks, etc, that are going on. Thus, it takes 0.000000.... additional time. If IPv6 had a header checksum, it too would be calculated in 0.00000... additional time. 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 Jul 24 11:40:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OIdOR20606 for ipng-dist; Tue, 24 Jul 2001 11:39:24 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OIdMY20599 for ; Tue, 24 Jul 2001 11:39:22 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6OIc1701880 for ipng@sunroof.eng.sun.com; Tue, 24 Jul 2001 11:38:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OGj5Y19608; Tue, 24 Jul 2001 09:45:05 -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 JAA05215; Tue, 24 Jul 2001 09:45:14 -0700 (PDT) Received: from sea-av1.zama.net (smtp1.zama.net [203.142.132.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19520; Tue, 24 Jul 2001 09:45:12 -0700 (PDT) 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 JAA11372; Tue, 24 Jul 2001 09:45:10 -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 JAA11364; Tue, 24 Jul 2001 09:45:10 -0700 (PDT) Received: from twhipple.zama.net ([203.142.132.5]) by postoff1.zama.net (Netscape Messaging Server 4.15) with ESMTP id GGZL7900.I12; Tue, 24 Jul 2001 09:45:09 -0700 Message-Id: <5.1.0.14.2.20010724093711.02cf04a0@postoff1.zama.net> X-Sender: whipple@postoff1.zama.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 24 Jul 2001 09:45:08 -0700 To: users@ipv6.org, usagi-users@linux-ipv6.org, 6bone@ISI.EDU, users@ipv6.org, ipng@sunroof.eng.sun.com, IPv6-AU@e-Secure.com.au, ngtrans@sunroof.eng.sun.com, multi6@ops.ietf.org From: "Todd Whipple" Subject: News server Cc: staff@zama.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Zama Networks is pleased to announced our IPv6 news group service. The news server is open only over IPv6. To read news, point your IPv6 capable news client to news.zamanetworks.com. The server currently has the big eight group hierarchies except for alt.* Currrently, Netscape 6 and TIN 1.5.8 are IPv6 capable news clients. Enjoy. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 24 15:48:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6OMm4F21691 for ipng-dist; Tue, 24 Jul 2001 15:48:04 -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 f6OMm0Y21684 for ; Tue, 24 Jul 2001 15:48: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 PAA20072 for ; Tue, 24 Jul 2001 15:48:13 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21104 for ; Tue, 24 Jul 2001 16:48:11 -0600 (MDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA13850 for ; Tue, 24 Jul 2001 15:48:12 -0700 (MST)] Received: [from il06exi01.CORP.MOT.COM (il06exi01.corp.mot.com [199.5.78.78]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA01509 for ; Tue, 24 Jul 2001 15:40:44 -0700 (MST)] Received: by il06exi01.corp.mot.com with Internet Mail Service (5.5.2654.52) id <36Y274QL>; Tue, 24 Jul 2001 17:48:11 -0500 Message-ID: From: Jung Cyndi-ACJ099 To: "'Kastenholz, Frank'" , Ignatios Souvatzis , Sean Lin Cc: ipng@sunroof.eng.sun.com Subject: RE: ipv6 header checksum Date: Tue, 24 Jul 2001 17:48:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Another reason for eliminating the IPv6 header checksum was that since IPSEC was required, that the AH would protect the IPv6 header from corruption, and that a checksum would be redundant. Also perhaps some naive idea that the data links were be error-free, or could detect their own errors - leaving only the more frequent problem of packets corrupted while sitting in the memory of some intermediate node. Cyndi -----Original Message----- From: Kastenholz, Frank [mailto:FKastenholz@unispherenetworks.com] Sent: Tuesday, July 24, 2001 8:09 AM To: Ignatios Souvatzis; Sean Lin Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum At 04:27 AM 7/24/01 -0400, Ignatios Souvatzis wrote: >On Tue, Jul 24, 2001 at 04:42:37PM +1200, Sean Lin wrote: > >> As we all know, there's no ipv6 header checksum field. Therefore, >> for routers forwarding packets, the checksum of ipv6 packets cannot be >> calculated? Which means that ipv6 routers will generally have a faster >> throughput compared to a similar ipv4 router (assuming there's no >> extension headers and option headers)? > >Yes. That's the reason it was designed that way. For software based forwarding engines, you are correct. However, most if not all high-speed routers one encounters today use silicon-based (ASICs and/or FPGAs) forwarders. The nice thing about silicon is that lots of stuff can be done in parallel. The IPv4 header checksum can be, and is, calculated in parallel with the other header checks, etc, that are going on. Thus, it takes 0.000000.... additional time. If IPv6 had a header checksum, it too would be calculated in 0.00000... additional time. 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 Tue Jul 24 17:26:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P0PGV21921 for ipng-dist; Tue, 24 Jul 2001 17:25:16 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P0PEY21914 for ; Tue, 24 Jul 2001 17:25:14 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6P0Nsf05753 for ipng@sunroof.eng.sun.com; Tue, 24 Jul 2001 17:23:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OKLjY21084; Tue, 24 Jul 2001 13:21:45 -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 NAA12139; Tue, 24 Jul 2001 13:21:59 -0700 (PDT) Received: from madli.ut.ee (madli.ut.ee [193.40.5.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01498; Tue, 24 Jul 2001 14:23:22 -0600 (MDT) Received: from localhost (tsoome@localhost) by madli.ut.ee (8.10.1/8.10.1/madli-1.12) with ESMTP id f6OKLXO20971; Tue, 24 Jul 2001 22:21:33 +0200 (EET) Date: Tue, 24 Jul 2001 22:21:33 +0200 (EET) From: Toomas Soome To: Todd Whipple cc: , , <6bone@ISI.EDU>, , , , , , Subject: Re: News server In-Reply-To: <5.1.0.14.2.20010724093711.02cf04a0@postoff1.zama.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk unfortunately: [196] root@madli:root/kadri> traceroute news.zamanetworks.com traceroute: Warning: Multiple interfaces found; using 3ffe:200:25:500:a00:20ff:fe83:b3ae @ hme0:2 traceroute to news.zamanetworks.com (2001:2d0:2:1::3007), 30 hops max, 60 byte packets 1 kadri.ut.ee (3ffe:200:25:500:a00:20ff:fec4:93e3) 1.057 ms 0.630 ms 0.445 ms 2 ut-gw-v6.ut.ee (3ffe:200:25:f000::c128:167f) 1.599 ms 1.418 ms 1.091 ms 3 ut-cisco.ut.ee (3ffe:200:25:0:2d0:97ff:fe91:a001) 1.547 ms 2.310 ms 2.549 ms 4 2001:6c0:1fff:ffd0::4 19.557 ms 22.475 ms 22.048 ms 5 spacenet-if.6r1.doc.london.ip6.pipex.net (3ffe:1100:0:c11::1) 175.020 ms 120.682 ms * 6 * * * 7 * * * 8 * * * 9 *^C On Tue, 24 Jul 2001, Todd Whipple wrote: > Zama Networks is pleased to announced our IPv6 news group service. The > news server is open only over IPv6. To read news, point your IPv6 capable > news client to news.zamanetworks.com. The server currently has the big > eight group hierarchies except for alt.* > > Currrently, Netscape 6 and TIN 1.5.8 are IPv6 capable news clients. > > Enjoy. > toomas -- Old musicians never die, they just decompose. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 24 17:26:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P0PeR21930 for ipng-dist; Tue, 24 Jul 2001 17:25:40 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P0PcY21923 for ; Tue, 24 Jul 2001 17:25:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6P0OIT05784 for ipng@sunroof.eng.sun.com; Tue, 24 Jul 2001 17:24:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6OMosY21713 for ; Tue, 24 Jul 2001 15:50: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 PAA01670 for ; Tue, 24 Jul 2001 15:51:07 -0700 (PDT) Received: from hnssysa.hns.com (hnssysa.hns.com [139.85.76.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA00860 for ; Tue, 24 Jul 2001 15:51:06 -0700 (PDT) Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id SAA06923; Tue, 24 Jul 2001 18:50:29 -0400 (EDT) Message-ID: <3B5DFBB4.70AA9DC3@hns.com> Date: Tue, 24 Jul 2001 18:50:28 -0400 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: deering@cisco.com, aconta@txc.com CC: ipng@sunroof.eng.sun.com Subject: Re ICMPv6 Time Exceeded Message Code 1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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? 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 Jul 24 17:26:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P0Q8D21939 for ipng-dist; Tue, 24 Jul 2001 17:26:08 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P0Q5Y21932 for ; Tue, 24 Jul 2001 17:26:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6P0OkJ05814 for ipng@sunroof.eng.sun.com; Tue, 24 Jul 2001 17:24:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6ONXjY21776; Tue, 24 Jul 2001 16:33: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 QAA10260; Tue, 24 Jul 2001 16:33:59 -0700 (PDT) Received: from gulag.araneus.fi (adsl-63-197-0-204.dsl.snfc21.pacbell.net [63.197.0.204]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18698; Tue, 24 Jul 2001 17:33:55 -0600 (MDT) Received: (from gson@localhost) by gulag.araneus.fi (8.9.3/8.6.12) id QAA04863; Tue, 24 Jul 2001 16:33:40 -0700 (PDT) Date: Tue, 24 Jul 2001 16:33:40 -0700 (PDT) Message-Id: <200107242333.QAA04863@gulag.araneus.fi> To: Matt Crawford Cc: Alain Durand , Olafur Gudmundsson , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: References: From: gson@nominum.com (Andreas Gustafsson) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: > I offer > http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt I would like to comment on section 1.3: > 1.3. DNSSEC - Aggravation or Amelioration? > > An extreme case of A6 deployment (some might say a nightmare case), > in the A6 record for each portion of an address is in a zone > belonging to the party by whom that set of bits has been assigned. > This is a situation which is improved by ubiquitous use of DNSSEC > [DNSSEC] since the leaf site can cache authenticated data for its > entire prefix chain and a DNS client can confidently accept that > data without having to make extra queries. You seem to be suggesting that if or when DNSSEC is deployed, authoritative servers should start actively caching data related to the data they are authoritative for, and resolvers (aka caching servers) should start making use of response data outside the domain for which the authoritative server is being queried, rather than discarding it like current resolvers do. I disagree. Having authoritative servers send such cached data, and having resolvers accept it, is a bad idea whether or not DNSSEC is being used. If a DNSSEC aware resolver accepts data from a poisoned cache, DNSSEC will detect the poisoning, but this does not in any way guarantee that the resolution will succeed - in practice, a much more likely outcome is that a security error is returned to the client. This could be exploited for denial of service attacks. -- 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 Tue Jul 24 17:27:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P0QXK21959 for ipng-dist; Tue, 24 Jul 2001 17:26:34 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P0QUY21952 for ; Tue, 24 Jul 2001 17:26:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6P0PAN05844 for ipng@sunroof.eng.sun.com; Tue, 24 Jul 2001 17:25:10 -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 f6ONguY21808 for ; Tue, 24 Jul 2001 16:42: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 QAA02549 for ; Tue, 24 Jul 2001 16:43:09 -0700 (PDT) Received: from hnssysa.hns.com (hnssysa.hns.com [139.85.76.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21354 for ; Tue, 24 Jul 2001 16:43:09 -0700 (PDT) Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id TAA13901; Tue, 24 Jul 2001 19:42:33 -0400 (EDT) Message-ID: <3B5E07E8.E5082E81@hns.com> Date: Tue, 24 Jul 2001 19:42:32 -0400 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: deering@cisco.com, aconta@txc.com CC: ipng@sunroof.eng.sun.com Subject: Followup question re ICMPv6 Time Exceeded Message Code 1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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? (Will this be covered in a future version of the draft-ietf-ipngwg-icmp-v3 document?) 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 Jul 24 21:32:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P4VSi24537 for ipng-dist; Tue, 24 Jul 2001 21:31:28 -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 f6P4VPY24530 for ; Tue, 24 Jul 2001 21:31:25 -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 VAA01109 for ; Tue, 24 Jul 2001 21:31:36 -0700 (PDT) Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA07231 for ; Tue, 24 Jul 2001 21:31:35 -0700 (PDT) Received: from rm-114b6.ee.calpoly.edu (HELO pebbles) (129.65.132.187) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jul 2001 04:31:35 -0000 X-Apparently-From: Message-ID: <023001c114c2$6d02de40$bb844181@bedrock.calpoly.edu> From: "Jose Melara" To: , "Francis Dupont" References: <200107240841.f6O8flO07847@givry.rennes.enst-bretagne.fr> Subject: Re: Bad file descriptor error during CONNECT...what to do? Date: Tue, 24 Jul 2001 21:29:22 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_022D_01C11487.B4CA93C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_022D_01C11487.B4CA93C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thank you for your prompt response and also for helping me on my coding. I am using: RedHat 7.1 with a kernel version 2.4.3 I have tar'ed the whole directory so that you can just run the program. If you're using Windows let me know so that I can zip it. You'll find that there's a lot of debug output because I'm still working with it. Thank you ... seriously... your help is greatly appreciated. Jose Melara ----- Original Message ----- From: "Francis Dupont" To: "Jose Melara" Sent: Tuesday, July 24, 2001 1:41 AM Subject: Re: Bad file descriptor error during CONNECT...what to do? > Give the OS/etc and *please* put the close after perror! > > Francis.Dupont@enst-bretagne.fr > > PS: I am afraid that the server6 structure is *not* fully initialized > (use bzero/memset). ------=_NextPart_000_022D_01C11487.B4CA93C0 Content-Type: application/x-gzip; name="ipv6_tcp.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipv6_tcp.tar.gz" H4sIAN9KXjsAA+0ca3PbOK5fpV/BS/e2durEjzhO1246502d1nNpknHcm51rex5FpmNNbcknyUlz O/3vB4APUQ+n7Tbb3u6J0yYSCYIgCIIACMVbXXcmsbuqP/j9SqPRbhwc7MPvBvxupH7L8qBxsNc6 aLf3m02Aa7bazc4Dtv870qTLOoqdkLEHzpIvnNDZCPep9j9o8dT6uwuP+3Fn13XvfYxGE9a73d6w /s291n5Lrf/efgeem214fsAa905JQfk/X//6ts22WX/JQ88N2CuaI9YckTiw4fl1B1+P+eVus7nb guWC1zqz7Yee7y7WU8625tyZ8rCzO9+C2imfeT5nF8PTzuRkcPpi/JK12rr659fHx4PR5GL4zwFr NoyGl5PT/quBamjYtu358V5rEjOQzc4k4v4UfsTrVcWdw3Jts3kQxRMfFqXGZM0qCONqT/fjH7x4 MnP9iqogHAvuqw70frmeQR976XgEyJzwytUY4eX6zbuq/avNRBVA9yzLqtfxacZDNgtCFvJoFfgR Z7MwWMLbMoi56qAH6UGNIgQoCa95OIkC9z2Pa9BiMYYYI+8/nLFD1qhBVb0+dWJHDYRNNoKpWRAY UuK48dpZMGcZrIH+YMaoG4DFBB/C4ij4HsJjBYOKq3hu0hTz5YpgzEp3/n6CfGSHoq875+575s3Y v9dQOXcidskB9U3oxTH3beha35ZAbrBcOj6MhKsLjFwvgaLIsrbrOMCMVZDT7C+HbK8KFYz9Sj9h yGAds6dP2dY6cq54l23hCy1E4x3V08rv4MrTiu/46+UlD9/6Wz2JAQmuNKvi9SP8RLLqwJGYrVcs nnMmGE+LNz46Z3Ho+NHSiyIv8O3M6gBLsgJIxDTf1QRVrXc0khhj6Hux5yxwGc3Fw4Fw3JWDKG25 iNAI2H1+I0TljbE33iHKm7m34DARG5lj0RA0yBVQhdhoBGQxYmNebKfYN/BjHiZwcUBgwE/BF9fz dwERrk5FUVNjT0DyHr31H0nmGbIWxSE8aNAqe8yaPSLHB3HvssdNHMJxXZJCNeHT1ycntiAcl1zj e6akfcPaHzk+oBUTi+dOzJZrd04TkQKhMcEzPC7U2oewQqHPKjvJ+iu2nQY3CqHkCbVIuaemSnpj soQxWnc0JF6cjuh6yGAwVjyPQRgCJzyf+nv+lTkF6p0hn0Q3oV1g5YuIF6Pv5/c886Ii/FJ6PgIf SFhmsKAOQKCWYHKFks2e6E7N54QZ1UQT4IyoR+Rd+c4iLYAKnSRHY09NWUPvfGHZSuPB5UjoBzVW ZZeg6N7LrQnzxmkvgmAFb1O+4DFniWqG5sHpc/aqPzy1bdBgX0pMusD5iCdmVm1U2WztuzHpmG2G /79uGFCkv+2IhOPMQh0Uh2s3Jl3oTKfhxPM7UvV14IwDLkgFiI08ivSeFjCM9LjEgQOh7G3jg+fP AoFA9QT5NDttPAlxJ6WOH2/iBr7PXRRJaCKkRAbHYa7Yah2ugohHiFefuNB7gvPs6Rqa3moVh7pK UvZmeDoYdyb9589HYKq8O9ya8SeNbrfT6D75adadOlMHtKU81ECaQGaM00MwIHNWiIfK+fGEUNfY xdnR3ycX49Gg/0rqDi3yqb5ar5n4tIgLGqac9pkkQ84B+TBzlt7iVlC05EsQgsqPcilraEygpg1m Urt1qlVCKN92AUNnIjEcsr6kvJeFwOEYGifwQgx1/FvUBDfeYuo64dTKoVwENygLwqiQU4Cf22x4 OhwP+ydo6p2fDU/Hg9EFScU2/q+bLHr6FAQdjk0QogZul2fPUvvemK6SPGO+rCLlskp8VxBATyUt t9vVpbNYBG5F9Us3V9PLZtDUzNFkjLPzbE5Mmyy8CEVD7srcYKJ68yCt4okXDoM2kh5JDZQS8o3D 7H3GMAvPwd322+fS/hTDyKzLzUChN5wEGINtGGT/7pkAejB88O3yFodrVQw9qcR/4ww6RTNQgg3a CuQ/Fo7AKY9vgvA9u7yFDRuEU7TGAnYOexZkysFzgCl5ByMMCIiDVSW7qvHtCqjatNY1pQT0Fk+v 9cZZHBSwiJi0CkF9zipbb+NkTDnG27j71wjM7M3k0HCFGFBwGCvGgIzf2HM+EZ4Kdp1i13xTpq86 dN7GyXCybiM7nmzULe7qtqKEMacOdyPxu6YgNq9Tfg8mFG/E22WS/o0Q1V5Kevr62NlMa1ZkWJHM 1Otfx9CfCnYJbBLlueDxzNYRnzLYBFghnGagaMqFRxMHITdPWDkT6njInDjwKtLd38hJbAcOktTk Gjar9Pw5Y0v70rRG5FPWYahkjCqQieQgLt6i7CkYq3ah8zAanY3USHjMA3LuLJX9Qc0Pic6Esow/ seLogFS2tqqqxl2AwZRMJVOfmo5uyzjU+GsWcp5TVik9kAfRG72gtzhZNrUq3MJwUT5enlhb+Tfa 0r43a157RFUd9SB3C1Q6+NlLT5tlGPdY+57r3Kulj6Z+KqK1OZpF0SoVVjs+ez1ibW0cA8wbtBC2 MH6zJW1tlnj5bbToKLYTO+85ntd4ekUKDscXrp7UkEYNmnkfjrE/2GNCXEU9cKgJZXIJPApvGXDv KZ6B8TPSMyJYtAoQv23fl0OosVDIg6k2BUJNIhjTTcIJGI8xcORiH1AhBDA9a2j13eVKHxMAVkuO DBVAkNgEAmPmoFhQapagTZ0rjq5SEihiN8CsfQJ2pNMe1FiqH1gYU/YIV+xRPhyHHamT2jIN6dqD ygyuQmdJEBheQC0Da7YGTbz2fVw8CtJVEv8ffOqKfH7cBK3144/wbvIBfe5qKkao4lZqcGQqhuNo wEwj+X0fiRya6Q4BJTEK0Dr2946U/zmLvv95BTt+5i347zDG3fc/jeZeU9z/tJoH7b12E+9/Gu1W ef/zLcrD8dyLGPxDdaJkIAn2eMsVvIJ8kI6sh9y9ZvbD1CEHlhxqDLopenga0DnoxOw2WLNoHqwX U9BM1xzfQzwdV2sMTFOgCs4G+yHYgbIvHDbZi6iH4uKpQxdPoB0uYK1iPrXto/Nz8OMeP7Z/Hp4e n/RfXByynSu249q/qLcAzpOLwegfg9HkZHgxRk0trcBAmIxwRuwG9tHJcHA6ViDqEjQFYr8c9J8P RtCsb7rswS8E7trMBpKuMIBDVhR1VyOB0pI1XfZDxRipalvwfn5eRTJVpzQEUC+xYF9jItBidJYw ORA98m7QZcnVLgNAMZuEhB8qiodVE1KPjxjUI9TfjcCEBBQJF7ssYamBhBViSSBxHtzxu7YVLtnO jG3DesjHLLO/9076Yxat/7Vs3/8Yn9L/zb090v+d5kFnv7WH+r/ZKPX/Nymb7v/NY0GIBlMnQxfa LbnrUHR2UQ1uW3I/GjXJNsZX8GKSpIGnXiDc2d35M6M2iqdekKtaeJeZutuojqGxKF+NNmO+dp3D ihi8JU/XwpkGw6XrwOGKF1mSYGJX6TrwtH0aw6gDPydYXBfQSC5rut7nMQZy6p6frnfClVPHlhz4 9FIMJ109jCuosAJjzU6qQQccWBtOpevAm2odW8le4qCPgsyF7vKCByx19M9UKCLwe7KCVly+CIHo 2R/xymMw7pUG+x+iaP2fHNz3PsYn8r9arbbO/2vtt9qo//ea+6X+/xblTv0v4wTy9jNiDnkCiR4w TX9S8IVJYRsVkWp41f8FlQa2WM3Wk0y2mGWlMsUu+tmr61zSWYKgf/T3ycnZC8CAsQUKOccBu+Rs Hw6jel3FCdmUuzhxfI4o1kZX6hhz5CLcJlSdDvRi1aXjvl8EVyLlTHRA90hd9/cKYnZxKC8tVNRO BHpQ49brlH/AzkdnL0b9V8UZaUlCmr7cFhhkVpqMG1FkkjLTXO5dg7sk4nciG2kisszAexHs7Zkd MctMAMuIFAV/mE4eE9SrMJXCr4BlV8Al6YEnP7hZ8OmVyDRRzYhVgshbCKiUzQmTmDEwZrMEoRPe Siid7MFMKBF7QudVxsRkdIou5MQSUpRRHFEykk5X3eJENiRboZTR9imP3NBbxUGSzWUACyADDw1l EY5PIBFEZRHIfInPQCAhNQL4JxmMHq9mLuVrySXB503ZWuzsnG4063rPS9EQwoPXLY7MdUgy1wzB etdLdc+TuInbBftHIFoEgVhSRzErlm5vlt8Ki9y2uVFqWh8I5KkEO5klBuKaTrCTN1Sp/U/AxgY5 xJ1wXUkRU5OMqpnbrsZU/pgh5TrAnCiD1D3QKxkbVrutJnehTBkxN2pxbpVAj0NV9ls/7u9XVbJJ QkNxx+dJtppc9dSlWHHGWIJUseB/LmPskyljKmmMLg1gAz0SolJ9RBlktr4uMzeruFI064Ug4Hoq VKTh7znFzNwz+uILXTTGrB2VkFRV75eeP61U7y39LE8CXT/BdMl+0OcrNEZ5XbDL2DAGaVZtt7Bv xaUEaDpxrcaTC2OR6At9xlCjMYsLBBO5QCA1puxkq8Mlk68ldPy1s1jru5esQt2UJ2eeDmaO3CJw 4cShq2x1SAOKTKoZdUazCXzrD0z4k/pI3/YnScoaqX+YBdpnttR4sL8myDdftCaHshhbUpOYCLAl r+aXTo9ZySH5SCfBIDiIdoHelrLD7GyiXjbNLZvlZtkq4TeVzgZ7zJJrCxzlIjl2BjpXLhPGG65A xfl0Hy5zVvOX2HfcVZtX1R/ljFDkzcQ9PPlIolCRxobkoRWIy4Y1kiA7nVCXyi7DiiroNpX5ZmbS WUYmHTHdw3RsH5POqT3VBRfAyiTWYR+VWpcCRsIBeB6DpVppyOFponqelERVUTkayXzFnR5pgGze AhySUZwVdZW9wGpGAmG1ikn7lLLwq1wgrZKJAkzc5v9ei5vf//AwYJk0I3XnN/hlOJ4c94cnr0cD dTcoZpLKE6HZ4P0nBSwYKGscDuAACinF9s/Nw8AWvX+gTtzIylGn3mrh3DLMOgiX4mYjuIzBDAcD lwxIY8DkjnlLpk6yrk7gTKVU5m+lt2haLN+D6i2zR72u+igNk+1DszMPtk3ZER/v+diRRlb6yLnf Y8VwvzLrq9yvCfpfwhvKHTk3jhdHOcPRiYQxiQg9l0fiCFKHiMBj6AqpBqTFCR1Moz3w9bmSMg9l xivtNmWLpunXtIu9RLfhRtICKcYbD3S66M7e+ltMbJ6Ne8dmOSLAvuerz8lRQq2W2hjCSiULKYVT 5ir9mrbEDHrFkJkNf8d+1wKbHkjIK0rs18gSWTlHyuyUGRPSI8zmTOSTeUjSixJ6vk66vyAq8DWZ PA1dlU/aMRNb5MiUt4NxATjYoP1PlNqTdVw2JvbkHCaq72J2oO5iYvnsJCDlB6ZSgP4o+T+Gm3rI 2t8h7+d7x0f/7EXH/5PLunsfA+P/nc7G+1+8+E3uf+n7f/xDAGX8/1uU+vY9FWn+nY+Gp2N29nrM ZMX9YK9v+N787qvMqR9NpPmDZn0qcL5t+tgUAw888c1skPWgUQtet9+YN6zveqnGTs6/p+gA+fWU +GzJ45itPDD9wDcwM9effuGB+AzsQfH9S5L7vgNnx8xzPdDJOH0cM8nXzzFCdJakwKmQaTc/P+ll hkla5CcBlGF/FwZx4ml2f9ZHSujzgkXpzllFkWlYng4cEsrBZl3bQks1mY32vatgVZukC5eMqJYQ gpEfbcu2NH1AHEbCe+mqDfMjJ4VuwNVHGHcwomaDpLE7UUkQIXHqRXrfVFeV4RWZ4G/MTn+nk6y7 7NKD6aVjm5KHKkZxBw87n2ZiR3ORsH8VJ9H/4h/i0IFtjOByM9oWOm0V1jO+5kTfia4seolsPX5c tS0yMChWcAjGh2V+IfOJxUH6kwEk/5JPN8QrrUBuT4gvGN781XtnLIBXKxpQgtKHEkjd48e9L1pQ /DrNIpmVi0q9wU9w1osYVlLhWPt4++ZLPAwnSStl9vtY3ybzWW42+uSmgAaWfIblISEF0yr4Guu3 6TUki74BMTWG/L6jTAO/76Ltv9i5in6nMT5l/0GrtP/29w72DgB+D+pK++9blL9Mxv0Xk+PhyWBy fDZ61R9bLasOGhiUAsY9KRTaYzs74umwiVHpBQV5ndUKNUdvC5U0/iGRqG4b2C7ORuPBc6tp1RuH az8KMG+7xpqH4kmBynSHSf/1+OXZyHruhCF4sC89fsnD2KpP6f1vc/G+6wbLbEf8ItgafFhDuwMq /wjFGGyvDNTr0Yk1j+NVF/xuhNiNgnXocpjUFd+F08Gqa+sp8mKe7f6PwehieHZqtXcbu3uIXSeW 7Bp5U1az1duyphbmSXZtmbySAvgp104fMwNQknhtNRsGFIZ9Ms17e/l2k4iO2T+xqy7GaFqlYQ8K IRWgtrOtFhFuawO4AOIJQZiZPKmRnhgjXfQzFJsEqxyeDEizAOTF+GWaNSZ7RYpHisb6v1Ru4g91 gIxlinwGxsxsJLilJdyKrp2kEhT2SdIjM/1UuC9Nbf1fn/9RHyGcmYgM5hQh2hRTlIgwuyhLzZ1/ AyvdL4kVyMHvylZKd03R/Rnd1FDZUb/M8ZPIRFXR4sns1czCGdcQRSz/klsKSUHmvnwjVvNK3eya /JWXAmH6DX8MRuL+3qdQWcpSlrKUpSxlKUtZylKWspSlLGUpS1nKUpaylKUsZSlLWcpSlrKUpSxl KUtZylKWspTlS8t/Ae4qNCgAeAAA ------=_NextPart_000_022D_01C11487.B4CA93C0-- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 24 22:31:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P5Ujh24678 for ipng-dist; Tue, 24 Jul 2001 22:30:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P5UgY24671 for ; Tue, 24 Jul 2001 22:30: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 WAA06496 for ; Tue, 24 Jul 2001 22:30:57 -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 XAA06775 for ; Tue, 24 Jul 2001 23:30:54 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6P5Ucx01780; Wed, 25 Jul 2001 08:30:39 +0300 Date: Wed, 25 Jul 2001 08:30:38 +0300 (EEST) From: Pekka Savola To: cc: Subject: Re: draft-ietf-ipngwg-ipaddressassign-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, I have an additional comment regarding flexible IP address assignments. Whether or not it's worth considering for inclusion, and to what extent, is up to you. The method described in the I-D does not discuss the merits and downsides of strictly bit-wise allocations; I'm of an opinion that if there are strong grounds to do otherwise (e.g. want to assignly densely, or expect a big number of assignments), it would make sense to do assignments on nibble boundaries. The reasons should be obvious. The most important is that they're lot easier for humans to understand, and make no mistakes about. Consider: 2001:pTLA:ABCD:0::/64 When allocated a /32 (or /35) you would effectively have 3-4 different "aggregation" levels if you did this at the nibble boundary, ie. want to avoid "breaking characters (A-D) if it can be avoided. Another plus is the ability of reverse delegations (now you must do up to 15 of them per zone depending on how you allocate). This might change though, and is not the prime motivator here. So, this would make the addresses easier to understand by customers, operators etc. -- sure, you can use a nice script to compute the bit-boundaries, but that doesn't make them much easier to {understand,verify their correctness in your head, etc.} for us hunams. With this scheme, depending on the pTLA size and growth views, possible assignments could be (as we've done): A = 0 (for now) B = Big PoP's (max 16) C = Organization within a PoP (max 16) D = 0 (for now) -- room for expansion in the foreseeable future. 16 organizations/PoP (in our case, we're talking about _big_ organizations, ones currently with IPv4 /16's and the like) is a rather small value and it is expected to have to expand this to D, but I doubt that has to be decided until after a few years at least. Note that this (or the original) I-D does not address the problems with RIR policy vs. IESG "/48 for everybody" recommendation (nor they should), as with current policies there is no way there would be enough /48's for home users etc. 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 Jul 24 22:34:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P5XcK24714 for ipng-dist; Tue, 24 Jul 2001 22:33:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P5XYY24704 for ; Tue, 24 Jul 2001 22:33:34 -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 WAA06763 for ; Tue, 24 Jul 2001 22:33:49 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA01286 for ; Tue, 24 Jul 2001 22:33:47 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id OAA18335; Wed, 25 Jul 2001 14:28:18 +0900 (KST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08954; Tue, 24 Jul 2001 22:33:22 -0700 (PDT) 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 WAA06703; Tue, 24 Jul 2001 22:33:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P5Ujh24678 for ipng-dist; Tue, 24 Jul 2001 22:30:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P5UgY24671 for ; Tue, 24 Jul 2001 22:30: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 WAA06496 for ; Tue, 24 Jul 2001 22:30:57 -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 XAA06775 for ; Tue, 24 Jul 2001 23:30:54 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6P5Ucx01780; Wed, 25 Jul 2001 08:30:39 +0300 Date: Wed, 25 Jul 2001 08:30:38 +0300 (EEST) From: Pekka Savola To: cc: Subject: Re: draft-ietf-ipngwg-ipaddressassign-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, I have an additional comment regarding flexible IP address assignments. Whether or not it's worth considering for inclusion, and to what extent, is up to you. The method described in the I-D does not discuss the merits and downsides of strictly bit-wise allocations; I'm of an opinion that if there are strong grounds to do otherwise (e.g. want to assignly densely, or expect a big number of assignments), it would make sense to do assignments on nibble boundaries. The reasons should be obvious. The most important is that they're lot easier for humans to understand, and make no mistakes about. Consider: 2001:pTLA:ABCD:0::/64 When allocated a /32 (or /35) you would effectively have 3-4 different "aggregation" levels if you did this at the nibble boundary, ie. want to avoid "breaking characters (A-D) if it can be avoided. Another plus is the ability of reverse delegations (now you must do up to 15 of them per zone depending on how you allocate). This might change though, and is not the prime motivator here. So, this would make the addresses easier to understand by customers, operators etc. -- sure, you can use a nice script to compute the bit-boundaries, but that doesn't make them much easier to {understand,verify their correctness in your head, etc.} for us hunams. With this scheme, depending on the pTLA size and growth views, possible assignments could be (as we've done): A = 0 (for now) B = Big PoP's (max 16) C = Organization within a PoP (max 16) D = 0 (for now) -- room for expansion in the foreseeable future. 16 organizations/PoP (in our case, we're talking about _big_ organizations, ones currently with IPv4 /16's and the like) is a rather small value and it is expected to have to expand this to D, but I doubt that has to be decided until after a few years at least. Note that this (or the original) I-D does not address the problems with RIR policy vs. IESG "/48 for everybody" recommendation (nor they should), as with current policies there is no way there would be enough /48's for home users etc. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 24 22:36:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P5a0X24817 for ipng-dist; Tue, 24 Jul 2001 22:36:00 -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 f6P5ZsY24792 for ; Tue, 24 Jul 2001 22:35: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 WAA06535 for ; Tue, 24 Jul 2001 22:36:09 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21760 for ; Tue, 24 Jul 2001 22:36:07 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id OAA18512; Wed, 25 Jul 2001 14:30:40 +0900 (KST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08455; Tue, 24 Jul 2001 23:35:33 -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 WAA06900; Tue, 24 Jul 2001 22:35:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P5XcK24714 for ipng-dist; Tue, 24 Jul 2001 22:33:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P5XYY24704 for ; Tue, 24 Jul 2001 22:33:34 -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 WAA06763 for ; Tue, 24 Jul 2001 22:33:49 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA01286 for ; Tue, 24 Jul 2001 22:33:47 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id OAA18335; Wed, 25 Jul 2001 14:28:18 +0900 (KST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08954; Tue, 24 Jul 2001 22:33:22 -0700 (PDT) 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 WAA06703; Tue, 24 Jul 2001 22:33:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P5Ujh24678 for ipng-dist; Tue, 24 Jul 2001 22:30:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P5UgY24671 for ; Tue, 24 Jul 2001 22:30: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 WAA06496 for ; Tue, 24 Jul 2001 22:30:57 -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 XAA06775 for ; Tue, 24 Jul 2001 23:30:54 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6P5Ucx01780; Wed, 25 Jul 2001 08:30:39 +0300 Date: Wed, 25 Jul 2001 08:30:38 +0300 (EEST) From: Pekka Savola To: cc: Subject: Re: draft-ietf-ipngwg-ipaddressassign-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, I have an additional comment regarding flexible IP address assignments. Whether or not it's worth considering for inclusion, and to what extent, is up to you. The method described in the I-D does not discuss the merits and downsides of strictly bit-wise allocations; I'm of an opinion that if there are strong grounds to do otherwise (e.g. want to assignly densely, or expect a big number of assignments), it would make sense to do assignments on nibble boundaries. The reasons should be obvious. The most important is that they're lot easier for humans to understand, and make no mistakes about. Consider: 2001:pTLA:ABCD:0::/64 When allocated a /32 (or /35) you would effectively have 3-4 different "aggregation" levels if you did this at the nibble boundary, ie. want to avoid "breaking characters (A-D) if it can be avoided. Another plus is the ability of reverse delegations (now you must do up to 15 of them per zone depending on how you allocate). This might change though, and is not the prime motivator here. So, this would make the addresses easier to understand by customers, operators etc. -- sure, you can use a nice script to compute the bit-boundaries, but that doesn't make them much easier to {understand,verify their correctness in your head, etc.} for us hunams. With this scheme, depending on the pTLA size and growth views, possible assignments could be (as we've done): A = 0 (for now) B = Big PoP's (max 16) C = Organization within a PoP (max 16) D = 0 (for now) -- room for expansion in the foreseeable future. 16 organizations/PoP (in our case, we're talking about _big_ organizations, ones currently with IPv4 /16's and the like) is a rather small value and it is expected to have to expand this to D, but I doubt that has to be decided until after a few years at least. Note that this (or the original) I-D does not address the problems with RIR policy vs. IESG "/48 for everybody" recommendation (nor they should), as with current policies there is no way there would be enough /48's for home users etc. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jul 25 01:01:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P7xMT29339 for ipng-dist; Wed, 25 Jul 2001 00:59:22 -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 f6P7xGY29291 for ; Wed, 25 Jul 2001 00:59:16 -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 AAA20314 for ; Wed, 25 Jul 2001 00:59:11 -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 BAA17146 for ; Wed, 25 Jul 2001 01:59:08 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6P7x8P02457 for ; Wed, 25 Jul 2001 10:59:08 +0300 Date: Wed, 25 Jul 2001 10:59:08 +0300 (EEST) From: Pekka Savola To: Subject: list amplifier? [Re: draft-ietf-ipngwg-ipaddressassign-02.txt] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 25 Jul 2001, Pekka Savola wrote: Is there something acting as an amplifier right now? I've received three copies of this mail I sent to the list now.. -- 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 Jul 25 02:24:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9Nk701891 for ipng-dist; Wed, 25 Jul 2001 02:23:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P9NhY01884 for ; Wed, 25 Jul 2001 02:23: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 CAA17169 for ; Wed, 25 Jul 2001 02:23:58 -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 DAA22924 for ; Wed, 25 Jul 2001 03:25:23 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA01770 for ipng@sunroof.eng.sun.com; Wed, 25 Jul 2001 11:23:55 +0200 (MET DST) Date: Wed, 25 Jul 2001 11:23:55 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum Message-ID: <20010725112354.A1700@theory.cs.uni-bonn.de> References: <20010724102700.A22834@theory.cs.uni-bonn.de> <5.0.2.1.2.20010724105657.00b05910@uniwest1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.2.20010724105657.00b05910@uniwest1>; from FKastenholz@unispherenetworks.com on Tue, Jul 24, 2001 at 11:09:23AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 24, 2001 at 11:09:23AM -0400, Kastenholz, Frank wrote: > At 04:27 AM 7/24/01 -0400, Ignatios Souvatzis wrote: >=20 > >On Tue, Jul 24, 2001 at 04:42:37PM +1200, Sean Lin wrote:=20 > > > >> As we all know, there's no ipv6 header checksum field. Therefore,= =20 > >> for routers forwarding packets, the checksum of ipv6 packets cannot be= =20 > >> calculated? Which means that ipv6 routers will generally have a faster= =20 > >> throughput compared to a similar ipv4 router (assuming there's no=20 > >> extension headers and option headers)?=20 > > > >Yes. That's the reason it was designed that way.=20 >=20 > For software based forwarding engines, you are correct. >=20 > However, most if not all high-speed routers one encounters > today use silicon-based (ASICs and/or FPGAs) forwarders. > The nice thing about silicon is that lots of stuff can be > done in parallel. The IPv4 header checksum can be, and is, > calculated in parallel with the other header checks, etc, > that are going on. Thus, it takes 0.000000.... additional > time. If IPv6 had a header checksum, it too would be=20 > calculated in 0.00000... additional time. you're aware that IPv6 has bigger headers, and additionally more likely to be variable length, than IPv4? But even if hardware checksummers could checksum most v6 headers easily - a) you'd need new hardware, b) you'd=20 penalize most software routers and endnodes, and c) needlessly, as most links used today are CRCing hop-by-hop anyway (all sorts of Ethernet, FDDI,= =20 ARCnet, Token Ring, PPP, to name a few), so what's really needed is=20 end-to-end checking, not hop-by-hop. Anyway - it was designed to be that way when I was much younger (you could read about it in, err, was it Huitemas book 5 years ago?) and before I joined the business, so you discussing with me about this point today see= ms to be completely useless to me, as I can't and won't change it. Regards Ignatios --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO16QJzCn4om+4LhpAQEkagf+KLHd3LXm/Q23xbOzgy+51rOmhOtzu3ib PD7TP5CzKzJTKJFHWZJbS4O/ZVBchJ+PCasnzU9PruwM3wMVe94ud3fsz7ekgYzP ZQwrqm+vxZsRsvSIHb7FWCC1z89ZkOqARjggv+UdA2DxuePuTskDJ0IH2les3eLK OyV2bpvOyfbXCqcqMdyTMqJZQOZ2flLohutagB4Klnc3BRBMPt9i3mpEW+7JoQvX 2wVtLv+VIUjhBcsCzqVwbe65CyFZahcbuQxTluqxG5am4uWD24DgCGRgmQdEQeue b8LPGJTHUQ4PodG1Wrwugtop90qIWAM1GXDU7Y92fLgV3lZzAHgPbA== =gBxH -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 02:27:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9REC01929 for ipng-dist; Wed, 25 Jul 2001 02:27:14 -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 f6P9RAY01918 for ; Wed, 25 Jul 2001 02:27:10 -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 CAA03892 for ; Wed, 25 Jul 2001 02:27:25 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26063 for ; Wed, 25 Jul 2001 02:27:24 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id SAA05295; Wed, 25 Jul 2001 18:21:56 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11685; Wed, 25 Jul 2001 02:26:49 -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 CAA27018; Wed, 25 Jul 2001 02:26:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9Nk701891 for ipng-dist; Wed, 25 Jul 2001 02:23:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P9NhY01884 for ; Wed, 25 Jul 2001 02:23: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 CAA17169 for ; Wed, 25 Jul 2001 02:23:58 -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 DAA22924 for ; Wed, 25 Jul 2001 03:25:23 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA01770 for ipng@sunroof.eng.sun.com; Wed, 25 Jul 2001 11:23:55 +0200 (MET DST) Date: Wed, 25 Jul 2001 11:23:55 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum Message-ID: <20010725112354.A1700@theory.cs.uni-bonn.de> References: <20010724102700.A22834@theory.cs.uni-bonn.de> <5.0.2.1.2.20010724105657.00b05910@uniwest1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.2.20010724105657.00b05910@uniwest1>; from FKastenholz@unispherenetworks.com on Tue, Jul 24, 2001 at 11:09:23AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 24, 2001 at 11:09:23AM -0400, Kastenholz, Frank wrote: > At 04:27 AM 7/24/01 -0400, Ignatios Souvatzis wrote: >=20 > >On Tue, Jul 24, 2001 at 04:42:37PM +1200, Sean Lin wrote:=20 > > > >> As we all know, there's no ipv6 header checksum field. Therefore,= =20 > >> for routers forwarding packets, the checksum of ipv6 packets cannot be= =20 > >> calculated? Which means that ipv6 routers will generally have a faster= =20 > >> throughput compared to a similar ipv4 router (assuming there's no=20 > >> extension headers and option headers)?=20 > > > >Yes. That's the reason it was designed that way.=20 >=20 > For software based forwarding engines, you are correct. >=20 > However, most if not all high-speed routers one encounters > today use silicon-based (ASICs and/or FPGAs) forwarders. > The nice thing about silicon is that lots of stuff can be > done in parallel. The IPv4 header checksum can be, and is, > calculated in parallel with the other header checks, etc, > that are going on. Thus, it takes 0.000000.... additional > time. If IPv6 had a header checksum, it too would be=20 > calculated in 0.00000... additional time. you're aware that IPv6 has bigger headers, and additionally more likely to be variable length, than IPv4? But even if hardware checksummers could checksum most v6 headers easily - a) you'd need new hardware, b) you'd=20 penalize most software routers and endnodes, and c) needlessly, as most links used today are CRCing hop-by-hop anyway (all sorts of Ethernet, FDDI,= =20 ARCnet, Token Ring, PPP, to name a few), so what's really needed is=20 end-to-end checking, not hop-by-hop. Anyway - it was designed to be that way when I was much younger (you could read about it in, err, was it Huitemas book 5 years ago?) and before I joined the business, so you discussing with me about this point today see= ms to be completely useless to me, as I can't and won't change it. Regards Ignatios --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO16QJzCn4om+4LhpAQEkagf+KLHd3LXm/Q23xbOzgy+51rOmhOtzu3ib PD7TP5CzKzJTKJFHWZJbS4O/ZVBchJ+PCasnzU9PruwM3wMVe94ud3fsz7ekgYzP ZQwrqm+vxZsRsvSIHb7FWCC1z89ZkOqARjggv+UdA2DxuePuTskDJ0IH2les3eLK OyV2bpvOyfbXCqcqMdyTMqJZQOZ2flLohutagB4Klnc3BRBMPt9i3mpEW+7JoQvX 2wVtLv+VIUjhBcsCzqVwbe65CyFZahcbuQxTluqxG5am4uWD24DgCGRgmQdEQeue b8LPGJTHUQ4PodG1Wrwugtop90qIWAM1GXDU7Y92fLgV3lZzAHgPbA== =gBxH -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jul 25 02:30:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9TgQ02067 for ipng-dist; Wed, 25 Jul 2001 02:29:42 -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 f6P9TbY02056 for ; Wed, 25 Jul 2001 02:29:37 -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 CAA27270 for ; Wed, 25 Jul 2001 02:29:52 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA25356 for ; Wed, 25 Jul 2001 03:31:15 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id SAA05509; Wed, 25 Jul 2001 18:24:12 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01738; Wed, 25 Jul 2001 03:29:06 -0600 (MDT) 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 CAA27149; Wed, 25 Jul 2001 02:28:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9REC01929 for ipng-dist; Wed, 25 Jul 2001 02:27:14 -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 f6P9RAY01918 for ; Wed, 25 Jul 2001 02:27:10 -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 CAA03892 for ; Wed, 25 Jul 2001 02:27:25 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26063 for ; Wed, 25 Jul 2001 02:27:24 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id SAA05295; Wed, 25 Jul 2001 18:21:56 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11685; Wed, 25 Jul 2001 02:26:49 -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 CAA27018; Wed, 25 Jul 2001 02:26:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9Nk701891 for ipng-dist; Wed, 25 Jul 2001 02:23:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P9NhY01884 for ; Wed, 25 Jul 2001 02:23: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 CAA17169 for ; Wed, 25 Jul 2001 02:23:58 -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 DAA22924 for ; Wed, 25 Jul 2001 03:25:23 -0600 (MDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA01770 for ipng@sunroof.eng.sun.com; Wed, 25 Jul 2001 11:23:55 +0200 (MET DST) Date: Wed, 25 Jul 2001 11:23:55 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum Message-ID: <20010725112354.A1700@theory.cs.uni-bonn.de> References: <20010724102700.A22834@theory.cs.uni-bonn.de> <5.0.2.1.2.20010724105657.00b05910@uniwest1> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.2.20010724105657.00b05910@uniwest1>; from FKastenholz@unispherenetworks.com on Tue, Jul 24, 2001 at 11:09:23AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 24, 2001 at 11:09:23AM -0400, Kastenholz, Frank wrote: > At 04:27 AM 7/24/01 -0400, Ignatios Souvatzis wrote: >=20 > >On Tue, Jul 24, 2001 at 04:42:37PM +1200, Sean Lin wrote:=20 > > > >> As we all know, there's no ipv6 header checksum field. Therefore,= =20 > >> for routers forwarding packets, the checksum of ipv6 packets cannot be= =20 > >> calculated? Which means that ipv6 routers will generally have a faster= =20 > >> throughput compared to a similar ipv4 router (assuming there's no=20 > >> extension headers and option headers)?=20 > > > >Yes. That's the reason it was designed that way.=20 >=20 > For software based forwarding engines, you are correct. >=20 > However, most if not all high-speed routers one encounters > today use silicon-based (ASICs and/or FPGAs) forwarders. > The nice thing about silicon is that lots of stuff can be > done in parallel. The IPv4 header checksum can be, and is, > calculated in parallel with the other header checks, etc, > that are going on. Thus, it takes 0.000000.... additional > time. If IPv6 had a header checksum, it too would be=20 > calculated in 0.00000... additional time. you're aware that IPv6 has bigger headers, and additionally more likely to be variable length, than IPv4? But even if hardware checksummers could checksum most v6 headers easily - a) you'd need new hardware, b) you'd=20 penalize most software routers and endnodes, and c) needlessly, as most links used today are CRCing hop-by-hop anyway (all sorts of Ethernet, FDDI,= =20 ARCnet, Token Ring, PPP, to name a few), so what's really needed is=20 end-to-end checking, not hop-by-hop. Anyway - it was designed to be that way when I was much younger (you could read about it in, err, was it Huitemas book 5 years ago?) and before I joined the business, so you discussing with me about this point today see= ms to be completely useless to me, as I can't and won't change it. Regards Ignatios --YZ5djTAD1cGYuMQK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO16QJzCn4om+4LhpAQEkagf+KLHd3LXm/Q23xbOzgy+51rOmhOtzu3ib PD7TP5CzKzJTKJFHWZJbS4O/ZVBchJ+PCasnzU9PruwM3wMVe94ud3fsz7ekgYzP ZQwrqm+vxZsRsvSIHb7FWCC1z89ZkOqARjggv+UdA2DxuePuTskDJ0IH2les3eLK OyV2bpvOyfbXCqcqMdyTMqJZQOZ2flLohutagB4Klnc3BRBMPt9i3mpEW+7JoQvX 2wVtLv+VIUjhBcsCzqVwbe65CyFZahcbuQxTluqxG5am4uWD24DgCGRgmQdEQeue b8LPGJTHUQ4PodG1Wrwugtop90qIWAM1GXDU7Y92fLgV3lZzAHgPbA== =gBxH -----END PGP SIGNATURE----- --YZ5djTAD1cGYuMQK-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 02:56:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9tTB03513 for ipng-dist; Wed, 25 Jul 2001 02:55:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P9tQY03506 for ; Wed, 25 Jul 2001 02:55:26 -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 CAA29372 for ; Wed, 25 Jul 2001 02:55:41 -0700 (PDT) From: matthew.ford@bt.com Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07236 for ; Wed, 25 Jul 2001 03:57:04 -0600 (MDT) Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 25 Jul 2001 10:55:45 +0100 Message-ID: To: ignatios@theory.cs.uni-bonn.de Cc: ipng@sunroof.eng.sun.com Subject: RE: ipv6 header checksum Date: Wed, 25 Jul 2001 10:55:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > you're aware that IPv6 has bigger headers, and additionally > more likely > to be variable length, than IPv4? I'm aware that IPv6 has a *fixed-length*, streamlined header. Cheers, Mat. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 02:59:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9wqZ03547 for ipng-dist; Wed, 25 Jul 2001 02:58:52 -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 f6P9wmY03540 for ; Wed, 25 Jul 2001 02:58: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 CAA06059 for ; Wed, 25 Jul 2001 02:59:03 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16496 for ; Wed, 25 Jul 2001 03:59:00 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id SAA07235; Wed, 25 Jul 2001 18:53:33 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16149; Wed, 25 Jul 2001 03:58:20 -0600 (MDT) 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 CAA29625; Wed, 25 Jul 2001 02:57:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9tTB03513 for ipng-dist; Wed, 25 Jul 2001 02:55:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P9tQY03506 for ; Wed, 25 Jul 2001 02:55:26 -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 CAA29372 for ; Wed, 25 Jul 2001 02:55:41 -0700 (PDT) From: matthew.ford@bt.com Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07236 for ; Wed, 25 Jul 2001 03:57:04 -0600 (MDT) Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 25 Jul 2001 10:55:45 +0100 Message-ID: To: ignatios@theory.cs.uni-bonn.de Cc: ipng@sunroof.eng.sun.com Subject: RE: ipv6 header checksum Date: Wed, 25 Jul 2001 10:55:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > you're aware that IPv6 has bigger headers, and additionally > more likely > to be variable length, than IPv4? I'm aware that IPv6 has a *fixed-length*, streamlined header. Cheers, Mat. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 03:01:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PA1SV03702 for ipng-dist; Wed, 25 Jul 2001 03:01:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PA1NY03680 for ; Wed, 25 Jul 2001 03:01: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 DAA20089 for ; Wed, 25 Jul 2001 03:01:35 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08800 for ; Wed, 25 Jul 2001 03:01:05 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id SAA07375; Wed, 25 Jul 2001 18:55:38 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA20857; Wed, 25 Jul 2001 03:00:45 -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 DAA29822; Wed, 25 Jul 2001 03:00:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9wqZ03547 for ipng-dist; Wed, 25 Jul 2001 02:58:52 -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 f6P9wmY03540 for ; Wed, 25 Jul 2001 02:58: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 CAA06059 for ; Wed, 25 Jul 2001 02:59:03 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16496 for ; Wed, 25 Jul 2001 03:59:00 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id SAA07235; Wed, 25 Jul 2001 18:53:33 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA16149; Wed, 25 Jul 2001 03:58:20 -0600 (MDT) 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 CAA29625; Wed, 25 Jul 2001 02:57:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6P9tTB03513 for ipng-dist; Wed, 25 Jul 2001 02:55:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6P9tQY03506 for ; Wed, 25 Jul 2001 02:55:26 -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 CAA29372 for ; Wed, 25 Jul 2001 02:55:41 -0700 (PDT) From: matthew.ford@bt.com Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07236 for ; Wed, 25 Jul 2001 03:57:04 -0600 (MDT) Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35) id ; Wed, 25 Jul 2001 10:55:45 +0100 Message-ID: To: ignatios@theory.cs.uni-bonn.de Cc: ipng@sunroof.eng.sun.com Subject: RE: ipv6 header checksum Date: Wed, 25 Jul 2001 10:55:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > you're aware that IPv6 has bigger headers, and additionally > more likely > to be variable length, than IPv4? I'm aware that IPv6 has a *fixed-length*, streamlined header. Cheers, Mat. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jul 25 03:33:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAWop05217 for ipng-dist; Wed, 25 Jul 2001 03:32:50 -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 f6PAWkY05210 for ; Wed, 25 Jul 2001 03:32:46 -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 DAA08838 for ; Wed, 25 Jul 2001 03:32:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01045 for ; Wed, 25 Jul 2001 04:32:56 -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 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 Wed Jul 25 03:35:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZRb05298 for ipng-dist; Wed, 25 Jul 2001 03:35:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZNY05291 for ; Wed, 25 Jul 2001 03:35:23 -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 DAA22741 for ; Wed, 25 Jul 2001 03:35:35 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02583 for ; Wed, 25 Jul 2001 04:35:31 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09607; Wed, 25 Jul 2001 19:30:05 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29260; Wed, 25 Jul 2001 03:35:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22612; Wed, 25 Jul 2001 03:34:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAWop05217 for ipng-dist; Wed, 25 Jul 2001 03:32:50 -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 f6PAWkY05210 for ; Wed, 25 Jul 2001 03:32:46 -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 DAA08838 for ; Wed, 25 Jul 2001 03:32:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01045 for ; Wed, 25 Jul 2001 04:32:56 -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 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 03:38:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAbs505462 for ipng-dist; Wed, 25 Jul 2001 03:37:54 -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 f6PAbmY05445 for ; Wed, 25 Jul 2001 03:37:48 -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 DAA02787 for ; Wed, 25 Jul 2001 03:38:00 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03648 for ; Wed, 25 Jul 2001 04:37:53 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09751; Wed, 25 Jul 2001 19:32:27 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00104; Wed, 25 Jul 2001 03:37:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22826; Wed, 25 Jul 2001 03:37:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAZRb05298 for ipng-dist; Wed, 25 Jul 2001 03:35:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PAZNY05291 for ; Wed, 25 Jul 2001 03:35:23 -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 DAA22741 for ; Wed, 25 Jul 2001 03:35:35 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02583 for ; Wed, 25 Jul 2001 04:35:31 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA09607; Wed, 25 Jul 2001 19:30:05 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29260; Wed, 25 Jul 2001 03:35:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22612; Wed, 25 Jul 2001 03:34:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PAWop05217 for ipng-dist; Wed, 25 Jul 2001 03:32:50 -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 f6PAWkY05210 for ; Wed, 25 Jul 2001 03:32:46 -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 DAA08838 for ; Wed, 25 Jul 2001 03:32:58 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01045 for ; Wed, 25 Jul 2001 04:32:56 -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 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jul 25 07:31:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PEUJt20119 for ipng-dist; Wed, 25 Jul 2001 07:30:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PEUFY20112 for ; Wed, 25 Jul 2001 07:30: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 HAA24876 for ; Wed, 25 Jul 2001 07:30:27 -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 HAA06074 for ; Wed, 25 Jul 2001 07:30: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 f6PETLr02988; Wed, 25 Jul 2001 21:29:23 +0700 (ICT) From: Robert Elz To: Ignatios Souvatzis cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum In-Reply-To: <20010725112354.A1700@theory.cs.uni-bonn.de> References: <20010725112354.A1700@theory.cs.uni-bonn.de> <20010724102700.A22834@theory.cs.uni-bonn.de> <5.0.2.1.2.20010724105657.00b05910@uniwest1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jul 2001 21:29:21 +0700 Message-ID: <2986.996071361@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | On Tue, Jul 24, 2001 at 11:09:23AM -0400, Kastenholz, Frank wrote: | > Thus, it takes 0.000000.... additional | > time. If IPv6 had a header checksum, it too would be | > calculated in 0.00000... additional time. It could be done in 0 extra time, but not for 0 extra cost. Reducing the required complexity of ASIC type forwarders reduces their cost (development cost, and usually parts cost as well), and hence increases the chances that people will actually be able to afford a router that can forward packets that fast - while simultaneously allowing the older, dumber, router types to route faster. | From: Ignatios Souvatzis | you're aware that IPv6 has bigger headers, and additionally more likely | to be variable length, than IPv4? Since IPv6 never had a header checksum, what it would have included was never defined. I had always assumed that if it existed, it would include just the IPv6 header, not all the subsequent headers (if it did that it would really be a whole packet checksum, as there isn't really a difference between a "next header == TCP" and "next header == destination options" in the design, they're both just next headers.) If that was correct, then the IPv6 header is certainly bigger than the minimal IPv4 header, but not at all likely to be variable length. As I recall the discussions, the prime motivation for deleting the header checksum was that nothing it protected actually matters. That is, even if the packet gets corrupted in a way that the header checksum would detect, the cost of not detecting it is close to 0 (when the packet is actually delivered, the transport level checksum, including the pseudo-header, will detect anything broken in transit that matters). The only real concern was the possibility that something out there may be inadvertently increasing the TTL, leading to the possibility of packets that loop forever. Two things could do that - random packet corruption not detected by a link level checksum, which can be ignored, as the chances of it happening repeatedly are about 0, or broken software, in which case trusting the software generated checksum to rescue us seems like wishful thinking. Nothing else in the header matters - the packet will either be detected as bad en route in other ways (say if the next header field gets cleared, and what follows doesn't look at all like options) or when the packet arrives. Doing validation at every hop either adds cost or delay, for no benefit worth having. For people used to the mantra of a checksum being necessary for protection, deleting it certainly seems rash, but when analysed, it is the right thing to do. kre ps: if other headers (than the IPv6 header) actually need checksums to protect data in them from modification, those headers should have checksums. Stuff like AH, ESP already has better methods. Transport already has checksums. The routing header doesn't need anything, nor does the frag header. If there are ever any options data that need to be protected, then a checksum option could be invented. (Right now I forget what other headers exist). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 07:34:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PEY8F20145 for ipng-dist; Wed, 25 Jul 2001 07:34:08 -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 f6PEY4Y20138 for ; Wed, 25 Jul 2001 07:34:04 -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 HAA14644 for ; Wed, 25 Jul 2001 07:34:16 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17506 for ; Wed, 25 Jul 2001 08:34:09 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id XAA10072; Wed, 25 Jul 2001 23:28:42 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13276; Wed, 25 Jul 2001 07:33:44 -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 HAA14356; Wed, 25 Jul 2001 07:33:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PEUJt20119 for ipng-dist; Wed, 25 Jul 2001 07:30:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PEUFY20112 for ; Wed, 25 Jul 2001 07:30: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 HAA24876 for ; Wed, 25 Jul 2001 07:30:27 -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 HAA06074 for ; Wed, 25 Jul 2001 07:30: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 f6PETLr02988; Wed, 25 Jul 2001 21:29:23 +0700 (ICT) From: Robert Elz To: Ignatios Souvatzis cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum In-Reply-To: <20010725112354.A1700@theory.cs.uni-bonn.de> References: <20010725112354.A1700@theory.cs.uni-bonn.de> <20010724102700.A22834@theory.cs.uni-bonn.de> <5.0.2.1.2.20010724105657.00b05910@uniwest1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jul 2001 21:29:21 +0700 Message-ID: <2986.996071361@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | On Tue, Jul 24, 2001 at 11:09:23AM -0400, Kastenholz, Frank wrote: | > Thus, it takes 0.000000.... additional | > time. If IPv6 had a header checksum, it too would be | > calculated in 0.00000... additional time. It could be done in 0 extra time, but not for 0 extra cost. Reducing the required complexity of ASIC type forwarders reduces their cost (development cost, and usually parts cost as well), and hence increases the chances that people will actually be able to afford a router that can forward packets that fast - while simultaneously allowing the older, dumber, router types to route faster. | From: Ignatios Souvatzis | you're aware that IPv6 has bigger headers, and additionally more likely | to be variable length, than IPv4? Since IPv6 never had a header checksum, what it would have included was never defined. I had always assumed that if it existed, it would include just the IPv6 header, not all the subsequent headers (if it did that it would really be a whole packet checksum, as there isn't really a difference between a "next header == TCP" and "next header == destination options" in the design, they're both just next headers.) If that was correct, then the IPv6 header is certainly bigger than the minimal IPv4 header, but not at all likely to be variable length. As I recall the discussions, the prime motivation for deleting the header checksum was that nothing it protected actually matters. That is, even if the packet gets corrupted in a way that the header checksum would detect, the cost of not detecting it is close to 0 (when the packet is actually delivered, the transport level checksum, including the pseudo-header, will detect anything broken in transit that matters). The only real concern was the possibility that something out there may be inadvertently increasing the TTL, leading to the possibility of packets that loop forever. Two things could do that - random packet corruption not detected by a link level checksum, which can be ignored, as the chances of it happening repeatedly are about 0, or broken software, in which case trusting the software generated checksum to rescue us seems like wishful thinking. Nothing else in the header matters - the packet will either be detected as bad en route in other ways (say if the next header field gets cleared, and what follows doesn't look at all like options) or when the packet arrives. Doing validation at every hop either adds cost or delay, for no benefit worth having. For people used to the mantra of a checksum being necessary for protection, deleting it certainly seems rash, but when analysed, it is the right thing to do. kre ps: if other headers (than the IPv6 header) actually need checksums to protect data in them from modification, those headers should have checksums. Stuff like AH, ESP already has better methods. Transport already has checksums. The routing header doesn't need anything, nor does the frag header. If there are ever any options data that need to be protected, then a checksum option could be invented. (Right now I forget what other headers exist). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jul 25 07:37:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PEaZk20237 for ipng-dist; Wed, 25 Jul 2001 07:36:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PEaUY20226 for ; Wed, 25 Jul 2001 07:36: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 HAA29598 for ; Wed, 25 Jul 2001 07:36:42 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14544 for ; Wed, 25 Jul 2001 07:36:41 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id XAA10204; Wed, 25 Jul 2001 23:31:13 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAB19126; Wed, 25 Jul 2001 08:36:03 -0600 (MDT) 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 HAA15046; Wed, 25 Jul 2001 07:35:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PEY8F20145 for ipng-dist; Wed, 25 Jul 2001 07:34:08 -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 f6PEY4Y20138 for ; Wed, 25 Jul 2001 07:34:04 -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 HAA14644 for ; Wed, 25 Jul 2001 07:34:16 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17506 for ; Wed, 25 Jul 2001 08:34:09 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id XAA10072; Wed, 25 Jul 2001 23:28:42 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13276; Wed, 25 Jul 2001 07:33:44 -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 HAA14356; Wed, 25 Jul 2001 07:33:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PEUJt20119 for ipng-dist; Wed, 25 Jul 2001 07:30:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PEUFY20112 for ; Wed, 25 Jul 2001 07:30: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 HAA24876 for ; Wed, 25 Jul 2001 07:30:27 -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 HAA06074 for ; Wed, 25 Jul 2001 07:30: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 f6PETLr02988; Wed, 25 Jul 2001 21:29:23 +0700 (ICT) From: Robert Elz To: Ignatios Souvatzis cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum In-Reply-To: <20010725112354.A1700@theory.cs.uni-bonn.de> References: <20010725112354.A1700@theory.cs.uni-bonn.de> <20010724102700.A22834@theory.cs.uni-bonn.de> <5.0.2.1.2.20010724105657.00b05910@uniwest1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jul 2001 21:29:21 +0700 Message-ID: <2986.996071361@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk | On Tue, Jul 24, 2001 at 11:09:23AM -0400, Kastenholz, Frank wrote: | > Thus, it takes 0.000000.... additional | > time. If IPv6 had a header checksum, it too would be | > calculated in 0.00000... additional time. It could be done in 0 extra time, but not for 0 extra cost. Reducing the required complexity of ASIC type forwarders reduces their cost (development cost, and usually parts cost as well), and hence increases the chances that people will actually be able to afford a router that can forward packets that fast - while simultaneously allowing the older, dumber, router types to route faster. | From: Ignatios Souvatzis | you're aware that IPv6 has bigger headers, and additionally more likely | to be variable length, than IPv4? Since IPv6 never had a header checksum, what it would have included was never defined. I had always assumed that if it existed, it would include just the IPv6 header, not all the subsequent headers (if it did that it would really be a whole packet checksum, as there isn't really a difference between a "next header == TCP" and "next header == destination options" in the design, they're both just next headers.) If that was correct, then the IPv6 header is certainly bigger than the minimal IPv4 header, but not at all likely to be variable length. As I recall the discussions, the prime motivation for deleting the header checksum was that nothing it protected actually matters. That is, even if the packet gets corrupted in a way that the header checksum would detect, the cost of not detecting it is close to 0 (when the packet is actually delivered, the transport level checksum, including the pseudo-header, will detect anything broken in transit that matters). The only real concern was the possibility that something out there may be inadvertently increasing the TTL, leading to the possibility of packets that loop forever. Two things could do that - random packet corruption not detected by a link level checksum, which can be ignored, as the chances of it happening repeatedly are about 0, or broken software, in which case trusting the software generated checksum to rescue us seems like wishful thinking. Nothing else in the header matters - the packet will either be detected as bad en route in other ways (say if the next header field gets cleared, and what follows doesn't look at all like options) or when the packet arrives. Doing validation at every hop either adds cost or delay, for no benefit worth having. For people used to the mantra of a checksum being necessary for protection, deleting it certainly seems rash, but when analysed, it is the right thing to do. kre ps: if other headers (than the IPv6 header) actually need checksums to protect data in them from modification, those headers should have checksums. Stuff like AH, ESP already has better methods. Transport already has checksums. The routing header doesn't need anything, nor does the frag header. If there are ever any options data that need to be protected, then a checksum option could be invented. (Right now I forget what other headers exist). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 08:51:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFoGb22203 for ipng-dist; Wed, 25 Jul 2001 08:50:16 -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 f6PFoDY22196 for ; Wed, 25 Jul 2001 08:50:13 -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 IAA27999 for ; Wed, 25 Jul 2001 08:50:25 -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 IAA25241; Wed, 25 Jul 2001 08:50:22 -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 f6PFoJr03654; Wed, 25 Jul 2001 22:50:20 +0700 (ICT) From: Robert Elz To: Radia Perlman - Boston Center for Networking cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum In-Reply-To: <200107251522.LAA23509@bcn.East.Sun.COM> References: <200107251522.LAA23509@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jul 2001 22:50:19 +0700 Message-ID: <3652.996076219@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 25 Jul 2001 11:22:15 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Message-ID: <200107251522.LAA23509@bcn.East.Sun.COM> | 2) The argument in favor of a hop-by-hop checksum is that you can | pinpoint the router that has the flaky memory that corrupts packets | in memory. Does anyone actually do that? Implementations I have seen just count'em and ditch'em. That is, if they check at all, I have heard rumours of some that don't bother checking (just do the incremental update for the TTL decrement). | 3) If, as Robert Elz says (and I'm not disagreeing), nothing in the layer 3 | header needs to be protected, That's not quite what I said - or not quite what I meant anyway. What I meant was that it doesn't need to be protected along the path. That is, if the dest IP address goes bad, the packet will be delivered to some random node (or for IPv6 most likely not delivered at all). In the first case the pseudo-header checksum will catch it, in the latter the packet is discarded anyway. AH is end to end - detecting that the packet delivered to you is what was sent can be valuable. What isn't really needed is for that to happen at every hop along the path - the number of header checksum errors (which if undetected will cause some extra packet forwarding) is so small that avoiding the extra stray forwarding isn't worth it. The fields that AH doesn't cover are those that are only there to support getting the packet to the destination, once it has safely arrived, they're trash anyway (TTL, flow label, ...) By no coincidence they're also the mutable ones. However, AH does assure us that the packet did come from who it claims to be from, etc. | 4) Anyone know why I seem to be receiving 3 copies of every packet sent | to IPng? There's some host in Korea forwarding everything sent to the list back to it again. It is most likely only the hop count eventually being exceeded (fortunately the Received headers remain intact throughout) that is preventing there being hundreds of copies of every message... 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 Jul 25 08:54:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFrqI22249 for ipng-dist; Wed, 25 Jul 2001 08:53:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PFrmY22242 for ; Wed, 25 Jul 2001 08:53: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 IAA14880 for ; Wed, 25 Jul 2001 08:54:01 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18429 for ; Wed, 25 Jul 2001 09:55:17 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id AAA14489; Thu, 26 Jul 2001 00:48:27 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24791; Wed, 25 Jul 2001 09:52:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09849; Wed, 25 Jul 2001 08:52:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFoGb22203 for ipng-dist; Wed, 25 Jul 2001 08:50:16 -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 f6PFoDY22196 for ; Wed, 25 Jul 2001 08:50:13 -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 IAA27999 for ; Wed, 25 Jul 2001 08:50:25 -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 IAA25241; Wed, 25 Jul 2001 08:50:22 -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 f6PFoJr03654; Wed, 25 Jul 2001 22:50:20 +0700 (ICT) From: Robert Elz To: Radia Perlman - Boston Center for Networking cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum In-Reply-To: <200107251522.LAA23509@bcn.East.Sun.COM> References: <200107251522.LAA23509@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jul 2001 22:50:19 +0700 Message-ID: <3652.996076219@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 25 Jul 2001 11:22:15 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Message-ID: <200107251522.LAA23509@bcn.East.Sun.COM> | 2) The argument in favor of a hop-by-hop checksum is that you can | pinpoint the router that has the flaky memory that corrupts packets | in memory. Does anyone actually do that? Implementations I have seen just count'em and ditch'em. That is, if they check at all, I have heard rumours of some that don't bother checking (just do the incremental update for the TTL decrement). | 3) If, as Robert Elz says (and I'm not disagreeing), nothing in the layer 3 | header needs to be protected, That's not quite what I said - or not quite what I meant anyway. What I meant was that it doesn't need to be protected along the path. That is, if the dest IP address goes bad, the packet will be delivered to some random node (or for IPv6 most likely not delivered at all). In the first case the pseudo-header checksum will catch it, in the latter the packet is discarded anyway. AH is end to end - detecting that the packet delivered to you is what was sent can be valuable. What isn't really needed is for that to happen at every hop along the path - the number of header checksum errors (which if undetected will cause some extra packet forwarding) is so small that avoiding the extra stray forwarding isn't worth it. The fields that AH doesn't cover are those that are only there to support getting the packet to the destination, once it has safely arrived, they're trash anyway (TTL, flow label, ...) By no coincidence they're also the mutable ones. However, AH does assure us that the packet did come from who it claims to be from, etc. | 4) Anyone know why I seem to be receiving 3 copies of every packet sent | to IPng? There's some host in Korea forwarding everything sent to the list back to it again. It is most likely only the hop count eventually being exceeded (fortunately the Received headers remain intact throughout) that is preventing there being hundreds of copies of every message... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 08:57:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFurr22398 for ipng-dist; Wed, 25 Jul 2001 08:56:53 -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 f6PFulY22381 for ; Wed, 25 Jul 2001 08:56: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 IAA27735 for ; Wed, 25 Jul 2001 08:56:59 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29197 for ; Wed, 25 Jul 2001 08:56:47 -0700 (PDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id AAA14673; Thu, 26 Jul 2001 00:51:18 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28075; Wed, 25 Jul 2001 09:56:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10605; Wed, 25 Jul 2001 08:56:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFrqI22249 for ipng-dist; Wed, 25 Jul 2001 08:53:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PFrmY22242 for ; Wed, 25 Jul 2001 08:53: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 IAA14880 for ; Wed, 25 Jul 2001 08:54:01 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18429 for ; Wed, 25 Jul 2001 09:55:17 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id AAA14489; Thu, 26 Jul 2001 00:48:27 +0900 (KST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24791; Wed, 25 Jul 2001 09:52:57 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09849; Wed, 25 Jul 2001 08:52:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PFoGb22203 for ipng-dist; Wed, 25 Jul 2001 08:50:16 -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 f6PFoDY22196 for ; Wed, 25 Jul 2001 08:50:13 -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 IAA27999 for ; Wed, 25 Jul 2001 08:50:25 -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 IAA25241; Wed, 25 Jul 2001 08:50:22 -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 f6PFoJr03654; Wed, 25 Jul 2001 22:50:20 +0700 (ICT) From: Robert Elz To: Radia Perlman - Boston Center for Networking cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum In-Reply-To: <200107251522.LAA23509@bcn.East.Sun.COM> References: <200107251522.LAA23509@bcn.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 Jul 2001 22:50:19 +0700 Message-ID: <3652.996076219@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 25 Jul 2001 11:22:15 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Message-ID: <200107251522.LAA23509@bcn.East.Sun.COM> | 2) The argument in favor of a hop-by-hop checksum is that you can | pinpoint the router that has the flaky memory that corrupts packets | in memory. Does anyone actually do that? Implementations I have seen just count'em and ditch'em. That is, if they check at all, I have heard rumours of some that don't bother checking (just do the incremental update for the TTL decrement). | 3) If, as Robert Elz says (and I'm not disagreeing), nothing in the layer 3 | header needs to be protected, That's not quite what I said - or not quite what I meant anyway. What I meant was that it doesn't need to be protected along the path. That is, if the dest IP address goes bad, the packet will be delivered to some random node (or for IPv6 most likely not delivered at all). In the first case the pseudo-header checksum will catch it, in the latter the packet is discarded anyway. AH is end to end - detecting that the packet delivered to you is what was sent can be valuable. What isn't really needed is for that to happen at every hop along the path - the number of header checksum errors (which if undetected will cause some extra packet forwarding) is so small that avoiding the extra stray forwarding isn't worth it. The fields that AH doesn't cover are those that are only there to support getting the packet to the destination, once it has safely arrived, they're trash anyway (TTL, flow label, ...) By no coincidence they're also the mutable ones. However, AH does assure us that the packet did come from who it claims to be from, etc. | 4) Anyone know why I seem to be receiving 3 copies of every packet sent | to IPng? There's some host in Korea forwarding everything sent to the list back to it again. It is most likely only the hop count eventually being exceeded (fortunately the Received headers remain intact throughout) that is preventing there being hundreds of copies of every message... 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 11:05:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PI4Lu25394 for ipng-dist; Wed, 25 Jul 2001 11:04:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PI4HY25387 for ; Wed, 25 Jul 2001 11:04: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 LAA17015 for ; Wed, 25 Jul 2001 11:04:31 -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 MAA11588; Wed, 25 Jul 2001 12:05:55 -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 OAA28150; Wed, 25 Jul 2001 14:05:02 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA02023; Wed, 25 Jul 2001 14:05:01 -0400 Message-ID: <3B5F0A4B.663E5EA1@txc.com> Date: Wed, 25 Jul 2001 14:04:59 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: Radia Perlman - Boston Center for Networking , ipng@sunroof.eng.sun.com Subject: Re: ipv6 header checksum References: <200107251522.LAA23509@bcn.East.Sun.COM> <3652.996076219@brandenburg.cs.mu.OZ.AU> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms77FBE8BF0CABEAEE613C3839" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms77FBE8BF0CABEAEE613C3839 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > | 4) Anyone know why I seem to be receiving 3 copies of every packet sent > | to IPng? > > There's some host in Korea forwarding everything sent to the list back to > it again. It is most likely only the hop count eventually being > exceeded (fortunately the Received headers remain intact throughout) > that is preventing there being hundreds of copies of every message... > > kre > Or is just a bad destination address, which checksum calculation detects, but "optimized" forwarding engine ignores? (-: 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 > -------------------------------------------------------------------- --------------ms77FBE8BF0CABEAEE613C3839 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 SIb3DQEJBTEPFw0wMTA3MjUxODA1MDBaMCMGCSqGSIb3DQEJBDEWBBQAaAx5w4vPObX+aXyW /yDLPZ++WjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gLAvecGJtSq08Ev+SvI6hDy3ak8sevgCzNzG351A8oWloKDLLnM5957GXfDnUsLmyQ5U+A02 3jJQJBgi/M+jJli7t2RZiWym6LVuB96PtRrHxMMZOPRGyAXMRr/5klvrhI3MxJ5HQPMN//vL udbENVrcicZGcElx7hkwB7yi/Ock --------------ms77FBE8BF0CABEAEE613C3839-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 25 11:13:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PID6F25540 for ipng-dist; Wed, 25 Jul 2001 11:13:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PID0Y25533 for ; Wed, 25 Jul 2001 11:13:00 -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 LAA19577 for ; Wed, 25 Jul 2001 11:13:14 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10954 for ; Wed, 25 Jul 2001 11:13:13 -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 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/; Wed, 25 Jul 2001 15:38:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6PMbAf08091 for ipng@sunroof.eng.sun.com; Wed, 25 Jul 2001 15:37:10 -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 f6PCRQY16114 for ; Wed, 25 Jul 2001 05:27:27 -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 FAA20135 for ; Wed, 25 Jul 2001 05:27:39 -0700 (PDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18672 for ; Wed, 25 Jul 2001 06:29:03 -0600 (MDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 08:26:08 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-187.dhcp.west.unispherenetworks.com [10.10.120.187]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PSK9QPHR; Wed, 25 Jul 2001 08:27:25 -0400 From: "Kastenholz, Frank" To: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Message-Id: <5.0.2.1.2.20010725074011.026d30f0@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 25 Jul 2001 08:28:06 -0400 Subject: Re: ipv6 header checksum In-Reply-To: <20010725112354.A1700@theory.cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:23 AM 7/25/01 -0400, Ignatios Souvatzis wrote: >> However, most if not all high-speed routers one encounters >> today use silicon-based (ASICs and/or FPGAs) forwarders. >> The nice thing about silicon is that lots of stuff can be >> done in parallel. The IPv4 header checksum can be, and is, >> calculated in parallel with the other header checks, etc, >> that are going on. Thus, it takes 0.000000.... additional >> time. If IPv6 had a header checksum, it too would be >> calculated in 0.00000... additional time. > >you're aware that IPv6 has bigger headers, and additionally more likely >to be variable length, than IPv4? The basic forwarding decisions are all made in from the first, basic, header. You know, the one with the addresses in it. For basic forwarding, none of the other headers matter. The Routing header is of interest, but if the routing header sees as much use as IPv4's source routes, the hardware can ignore it. >But even if hardware checksummers could >checksum most v6 headers easily - a) you'd need new hardware, But we need to develop new ASICs and FPGA images to support IPv6 anyway, so adding hypothetical header checksumming would be almost-0-added-cost for development and truly 0 added cost for deployment. Of course, if the IPv6 development community were to decide to add header checksums after IPv6-capable ASICs and FPGAs were fielded, it would cost a lot. >b) you'd penalize most software routers and endnodes, That depends on how over-built the software systems are, doesn't it? I mean, if the processor and data path and memory can handle the load of checksumming without degrading overall system performance, then there is no operational penalty, is there? As to the cost on end-nodes, everything is relative. The cost of a hypothetical IPv6 header checksum would be rather trivial compared to the cost, say, of doing the TCP data checksum, which can be over much, much, much, larger piles of bits. >and c) needlessly, as most >links used today are CRCing hop-by-hop anyway (all sorts of Ethernet, FDDI, >ARCnet, Token Ring, PPP, to name a few), so what's really needed is >end-to-end checking, not hop-by-hop. For the most part I agree. However, the link CRC does not protect the packet while it is in a router's buffers or crosses the various links within the router. So any error that might be introduced there would be undetected. Some parts of the hardware are pretty good -- for instance, error rates within chips (i.e. when the packet is in the flipflops inside a chip) are astronomically low. But at other places the rates can be high -- in particular - the high-speed (2+ghz) inter-chip links - drams for buffers and stores of various kinds, and - inter-board fabrics and backplanes and those places do need protection. Good vendors will put in parity and CRC and whatever to protect things, but that costs added RAM, links, and so on, which means that costs are higher. Vendors who are "cost sensitive", careless, or poorly educated, might omit these protections. Thus, undetected errors can creep in. Then the questions are - what are the error rates? - how bad is it if one hits? The answer to the first question is that the rates are fairly bad. Any individual link, memory, etc, has a lowish rate, but due to the quantity of them, the total rate for the box can be distressingly high (the numbers depend on the box/design in question, of course). The answer to the second question is less bad if the errors are transient. Technically, if an occasional packet goes off to some random place, it's no problem. But now we have data going to the wrong place. That is generally frowned upon (for the sake of argument, suppose that the packet has your ATM card number and PIN in it ...). A bigger technical problem is if the error is not transient, that it's a 'stuck bit' someplace. Now, every packet goes wrong, but the box does not know it, and can not report the failure. You might wonder whether this protection is really relevant. But I've met with enough customers and potential customers to know that they ask very very detailed questions about a router's internal data paths and EDAC and so on. They care. >Anyway - it was designed to be that way when I was much younger (you could >read about it in, err, was it Huitemas book 5 years ago?) and before >I joined the business, so you discussing with me about this point today seems >to be completely useless to me, as I can't and won't change it. I am not trying to change the IPv6 design decision. The lack of a header checksum is the least of the things I would consider changing in V6. However, understanding some of the engineering issues surrounding the implementation of a critical part of the Internet infrastructure seems, to me anyway, to be A Good Thing. Frank Kastenholz 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 Wed Jul 25 15:40:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6PMdag28114 for ipng-dist; Wed, 25 Jul 2001 15:39:36 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PMdXY28106 for ; Wed, 25 Jul 2001 15:39:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f6PMcAj08121 for ipng@sunroof.eng.sun.com; Wed, 25 Jul 2001 15:38:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6PCapY17667 for ; Wed, 25 Jul 2001 05:36:51 -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 FAA10139 for ; Wed, 25 Jul 2001 05:37:03 -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 FAA27763 for ; Wed, 25 Jul 2001 05:37:03 -0700 (PDT) Received: (qmail 21153 invoked by uid 1001); 25 Jul 2001 12:35:28 -0000 Date: 25 Jul 2001 12:35:28 -0000 Message-ID: <20010725123528.8453.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 - DNSext joint meeting, call for participation References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Crawford wants your signatures today to last for a month. What happens if you decide tomorrow to change a machine's address list---for example, adding or removing a second address? Answer: An attacker can interfere with this change for 29 agonizing days. All he has to do is replay the old data under the old signature. The whole point of an expiration date is to stop this attack. Expiration dates far in the future don't do that. Are you willing to have your old data persist for a month after you make a change? Of course not. This is why typical TTLs are at most 1 day, and it's why typical expiration dates will be at most 1 day in the future. Example: My cr.yp.to address is extremely stable. But I want the ability to set up a second cr.yp.to web server with at most one day's notice. That's why my TTL is 1 day, and it's why any signatures that I create will expire within 1 day. The question is not, as Crawford would have you believe, whether the old data lasted for a month. The question is how much _warning_ you have before the old data is replaced with the new data. That's what TTLs measure, and it's what expiration dates measure. Conclusion: The computer will sign every record every day. Renumbering every day, with AAAA or A6, adds _nothing_ to this signing cost. David Terrell writes: > Did I miss somewhere where the expiration of the cryptographic > signature was defined to replace the normal DNS TTL on the record? In DNSSEC, the lifetime of a record is limited by the relative TTL _and_ by the absolute expiration date. See RFC 2535, section 4.4. As for ``replace'': It's true that a better-designed protocol would simply use absolute dates, not relative times. However, DNSSEC servers are still supposed to manage TTLs for compatibility with non-DNSSEC servers. See RFC 2535, section 2.3.3. ---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 Jul 26 09:26:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QGPQT02885 for ipng-dist; Thu, 26 Jul 2001 09:25:26 -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 f6QGPLY02869 for ; Thu, 26 Jul 2001 09:25:21 -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 JAA14115 for ; Thu, 26 Jul 2001 09:25:35 -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 JAA07917 for ; Thu, 26 Jul 2001 09:25:30 -0700 (PDT) Received: from cbin2-mira-01.cisco.com (cbin2-mira-01.cisco.com [192.135.246.89]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6QGPPg24700; Thu, 26 Jul 2001 09:25:25 -0700 (PDT) Received: from cisco.com ([64.104.134.246]) by cbin2-mira-01.cisco.com (Mirapoint) with ESMTP id AHB02558 (AUTH raraghun); Thu, 26 Jul 2001 21:55:21 +0530 (IST) Message-ID: <3B604506.BDA9AAB6@cisco.com> Date: Thu, 26 Jul 2001 21:57:50 +0530 From: Rajiv Raghunarayan Organization: Cisco Systems X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dario Accornero CC: ipng@sunroof.eng.sun.com, fenner@research.att.com Subject: Re: Latest IPv6 MIBs revision References: <3B5D8A2F.ECBF243F@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Dario, I think these questions haven't been answered yet.. so I'll take my stab at it.. Dario Accornero wrote: > > Hello, > > I have a couple of questions about the latest revision (12th July) > of draft-ietf-ipngwg-rfc2011-update-00.txt : > > 1. ipIfStatsTable: > Why {In,Out}Octets and {In,Out}McastOctets are declared as > Counter32 instead of as Counter64 ? 64 bit equivalents of all these objects exist i.e. ipIfStatsInOctets (32 bit) <===> ipIfStatsHCInOctets (64 bit) ipIfStatsOutOctets <===> ipIfStatsHCOutOctets ipIfStatsInMcastOctets <===> ipIfStatsHCInMcastOctets ipIfStatsOutMcastOctets <===> ipIfStatsHCOutMcastOctets > 2. ipIfStatsTable: > Why there are no accurate descriptions of the new counters, > besides {In,Out}Octets ? The description of all the 64 bit objects are same as the 32 bit version.. the only change is that they maintain 64-bit values instead of 32-bit. HTH.. -Rajiv. > > Thank you, > -- > Dario Accornero - IOS Europe Development - IPv6 Team > Stockley Park, Uxbridge, UK - voice +44 20 8756 6268 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jul 26 09:40:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QGdmj02998 for ipng-dist; Thu, 26 Jul 2001 09:39:48 -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 f6QGdjY02991 for ; Thu, 26 Jul 2001 09:39:45 -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 JAA10520 for ; Thu, 26 Jul 2001 09:39:59 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA17017 for ; Thu, 26 Jul 2001 09:39:54 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 8D3924CEC8; Thu, 26 Jul 2001 12:39:49 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA21691; Thu, 26 Jul 2001 12:39:49 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA12131; Thu, 26 Jul 2001 09:39:48 -0700 (PDT) Message-Id: <200107261639.JAA12131@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: daccorne@cisco.com Subject: Re: Latest IPv6 MIBs revision Cc: ipng@sunroof.eng.sun.com Date: Thu, 26 Jul 2001 09:39:47 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >1. ipIfStatsTable: > Why {In,Out}Octets and {In,Out}McastOctets are declared as > Counter32 instead of as Counter64 ? For parallelism with the IF-MIB counters. There are Counter64 versions as well. >2. ipIfStatsTable: > Why there are no accurate descriptions of the new counters, > besides {In,Out}Octets ? I did this revision just at the I-D submission deadline and didn't have time to finish the DESCRIPTIONs of the new objects. Not a particularly good reason, I know. Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 26 13:38:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QKbnN05272 for ipng-dist; Thu, 26 Jul 2001 13:37:49 -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 f6QKbjY05265 for ; Thu, 26 Jul 2001 13:37: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 NAA12015 for ; Thu, 26 Jul 2001 13:37:59 -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 OAA16401 for ; Thu, 26 Jul 2001 14:39:23 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6QKbeF14323; Thu, 26 Jul 2001 23:37:43 +0300 Date: Thu, 26 Jul 2001 23:37:39 +0300 (EEST) From: Pekka Savola To: cc: Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-08.txt In-Reply-To: <200107251031.GAA07337@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 25 Jul 2001 Internet-Drafts@ietf.org wrote: Some comments: --8<-- 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. --8<-- Some reference to an usefulness report (if one exists) would be nice; I don't think that many implementations implement, or enable, NI queries by default, and we've survived.. I'm not saying NI queries would be useless, but I'm asking whether they're really _all_ that useful, other than as a nifty trick or in heavy debugging.. (In any case I think this is probably experimental track material) --8<-- 4. Message Processing If true communication security is required, IPsec [2401] must be used. --8<-- I'd probably say "IPsec [2401] or a similar mechanism must be used." (unless it's viewed that IPsec will always be the one and the only method to gain security like this) Further in the same chapter: --8<-- Next, if Qtype is unknown to the Responder, it must return a NI Reply with ICMPv6 Code = 2 and no Reply Data. The Responder should rate-limit such replies as it would ICMPv6 error replies [2463, 2.4(f)]. Next, the Responder should decide whether to refuse an answer, based on local policy. (See "Security Considerations" for recommended default behavior.) If an answer is refused, the Responder may send a NI Reply with ICMPv6 Code = 1 and no Reply Data. Again, the Responder should rate-limit such replies as it would ICMPv6 error replies [2463, 2.4(f)]. --8<-- There are reasons for these to be in this order; however, depending on how strict security policies are assumed to be, this order might expose too much of the local implementation (which query types are understood etc.) with no real way of stopping it (as security checks are only done for packets for which the reply is valid). Is this an issue worth considering at this "layer", or something to be done by filtering particular ICMP6 types? --8<-- 5.3. Node Name TTL The number of seconds that the name may be cached. For compatibility with DNS [1035], this is a 32-bit signed, 2's-complement number, which must not be negative. --8<-- If the number _is_ negative, the behaviour of the recipient at so TTL'ed message appears to be unspecified? This is one thing that might create some hassle if the value was just blindly copied without checking. Is this the intent? --8<-- 7. Security Considerations In a large Internet with relatively frequent renumbering, the maintenance of of KEY and SIG records [2535] in the zones used for address-to-name translations will be no easier [....] --8<-- will -> would (same for the other instances); real needs for "relatively frequent renumbering" are still under some dispute I think. -- 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 Jul 26 14:55:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6QLscJ06131 for ipng-dist; Thu, 26 Jul 2001 14:54:38 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6QLsXY06124 for ; Thu, 26 Jul 2001 14:54:33 -0700 (PDT) Received: from lillen (gbl-rem-36 [129.157.174.36]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f6QLsg229143; Thu, 26 Jul 2001 23:54:43 +0200 (MET DST) Date: Thu, 26 Jul 2001 23:52:42 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: complete the advanced API (rfc2292bis) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Catching up on email after some vacation... > 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). > 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.) 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 Jul 27 04:01:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB0iE09510 for ipng-dist; Fri, 27 Jul 2001 04:00:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RB0eY09503; Fri, 27 Jul 2001 04:00:41 -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 EAA12742; Fri, 27 Jul 2001 04:00:53 -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 FAA05993; Fri, 27 Jul 2001 05:00:48 -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 f6RB03n02263; Fri, 27 Jul 2001 18:00:04 +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 - DNSext joint meeting, call for participation In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jul 2001 18:00:03 +0700 Message-ID: <2261.996231603@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 25 Jul 2001 06:28:32 -0700 From: "D. J. Bernstein" Message-ID: | Crawford wants your signatures today to last for a month. I doubt that Matt cares how long anyone's, but his own, signatures last. | What happens | if you decide tomorrow to change a machine's address list---for example, | adding or removing a second address? I wait until the previous signed record is ready to be resigned, and then I sign new ones, with different data, different TTLs, or anything else that I want. | Answer: An attacker can interfere with this change for 29 agonizing | days. All he has to do is replay the old data under the old signature. This has nothing whatever to do with attackers - the only way an attacker can interfere with this is if you're attempting to bypass the protocols. What you're really saying here is that people shouldn't use long expiration dates. What you should be doing, is explaining the pros and cons of different signing policies. I know that for most of my systems, nothing ever changes - and if something is to change, I can wait several weeks for it to happen (generally it takes that long to build up the energy to make the change anyway). Trivial stuff like ethernet cards dying, etc, can be handled by just configuring the (IPv6) address of the system to what it used to autoconfig to, until it is time to update the DNS (if ever). Adding new interfaces, addresses, etc - all takes planning. That all takes time. Now certainly when designing my signing policy I should be taking into account all of these factors. But when I do that I know that I am not going to come up with any simple number as the answer for everyone. | Are you willing to have your old data persist for a month after you make | a change? Of course not. No, but if I define things that way, I'm prepared to wait a month before making the change, so I can do it properly. If I didn't want to wait that long I'd use a smaller expiration time. | This is why typical TTLs are at most 1 day, and Yes, and because they're cheap (the cost of a 1 day, compared to 7 day expiration is negligible). | it's why typical expiration dates will be at most 1 day in the future. But that's not cheap. And it almost certainly simply won't work in general. Signing, and retaining security, is a time consuming business (the CPU time consumed is not what I am measuring here, but the human time). The data needs to be somehow carried to the key (which cannot be exposed anywhere near any network), the signing done, and then the data carried back again. Doing that once a month for most people just might be tolerable - once a day and all that will ever exist are expired signatures. After all, how many sites are going to have people (people with authority to get at the keys) available every day of the year (no holidays permitted) to resign the zone file? | Example: My cr.yp.to address is extremely stable. But I want the ability | to set up a second cr.yp.to web server with at most one day's notice. | That's why my TTL is 1 day, and it's why any signatures that I create | will expire within 1 day. You can do that with your private zone file - and hope that you're available to resign every day (or you can blow security and stick your key on the server and have it all automated). Don't expect almost anyone else to follow your example. | The question is not, as Crawford would have you believe, whether the old | data lasted for a month. The question is how much _warning_ you have | before the old data is replaced with the new data. That's what TTLs | measure, and it's what expiration dates measure. That's absolutely true, except I doubt that Matt expects anyone to believe what you claim he does. It certainly isn't what he said. | Conclusion: The computer will sign every record every day. And that's not a conclusion at all, but a speculation, and most likely, for most sites, an obviously bogus one. | Renumbering | every day, with AAAA or A6, adds _nothing_ to this signing cost. That would be true, if you were resigning everything every day, but almost no-one is going to be doing that. For A6/AAAA records, which is where this discussion started, the average system will retain the same set of interface identifiers for long periods (very long periods), and on the odd occasions when those are to change, a delay before making the change is entirely acceptable. It doesn't have to happen right now. Nothing is going to require that. Hence a long expiration time is just fine (how long will depend upon individual site requirements, for me, I think 3 months would be about right). On the other hand, someone else can command me to change the upper parts of the address (my ISP just changed its ISP for whatever reason, all their addresses are now from a different block, they're keeping the old ones for a week...) In that situation I have to be able to change the upper bits quickly, those can be out of my control. So that part I need to be able to update quickly, that one I will have to resign fairly frequently (I'd probably make it once or twice a week though, not once a day). | As for ``replace'': It's true that a better-designed protocol would | simply use absolute dates, That would be nice, if we could mandate that any two systems use the same idea of the time. Until that happens (like never) relative times are what works (well enough). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 27 04:05:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB5Mv09592 for ipng-dist; Fri, 27 Jul 2001 04:05:22 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RB5HY09578; Fri, 27 Jul 2001 04:05: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 EAA14239; Fri, 27 Jul 2001 04:05:30 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07793; Fri, 27 Jul 2001 05:05:26 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA17571; Fri, 27 Jul 2001 19:59:58 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07472; Fri, 27 Jul 2001 05:04:34 -0600 (MDT) 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 EAA27409; Fri, 27 Jul 2001 04:02:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB1L009522 for ngtrans-dist; Fri, 27 Jul 2001 04:01:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RB0eY09503; Fri, 27 Jul 2001 04:00:41 -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 EAA12742; Fri, 27 Jul 2001 04:00:53 -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 FAA05993; Fri, 27 Jul 2001 05:00:48 -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 f6RB03n02263; Fri, 27 Jul 2001 18:00:04 +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: (ngtrans) Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jul 2001 18:00:03 +0700 Message-ID: <2261.996231603@brandenburg.cs.mu.OZ.AU> Reply-To: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 25 Jul 2001 06:28:32 -0700 From: "D. J. Bernstein" Message-ID: | Crawford wants your signatures today to last for a month. I doubt that Matt cares how long anyone's, but his own, signatures last. | What happens | if you decide tomorrow to change a machine's address list---for example, | adding or removing a second address? I wait until the previous signed record is ready to be resigned, and then I sign new ones, with different data, different TTLs, or anything else that I want. | Answer: An attacker can interfere with this change for 29 agonizing | days. All he has to do is replay the old data under the old signature. This has nothing whatever to do with attackers - the only way an attacker can interfere with this is if you're attempting to bypass the protocols. What you're really saying here is that people shouldn't use long expiration dates. What you should be doing, is explaining the pros and cons of different signing policies. I know that for most of my systems, nothing ever changes - and if something is to change, I can wait several weeks for it to happen (generally it takes that long to build up the energy to make the change anyway). Trivial stuff like ethernet cards dying, etc, can be handled by just configuring the (IPv6) address of the system to what it used to autoconfig to, until it is time to update the DNS (if ever). Adding new interfaces, addresses, etc - all takes planning. That all takes time. Now certainly when designing my signing policy I should be taking into account all of these factors. But when I do that I know that I am not going to come up with any simple number as the answer for everyone. | Are you willing to have your old data persist for a month after you make | a change? Of course not. No, but if I define things that way, I'm prepared to wait a month before making the change, so I can do it properly. If I didn't want to wait that long I'd use a smaller expiration time. | This is why typical TTLs are at most 1 day, and Yes, and because they're cheap (the cost of a 1 day, compared to 7 day expiration is negligible). | it's why typical expiration dates will be at most 1 day in the future. But that's not cheap. And it almost certainly simply won't work in general. Signing, and retaining security, is a time consuming business (the CPU time consumed is not what I am measuring here, but the human time). The data needs to be somehow carried to the key (which cannot be exposed anywhere near any network), the signing done, and then the data carried back again. Doing that once a month for most people just might be tolerable - once a day and all that will ever exist are expired signatures. After all, how many sites are going to have people (people with authority to get at the keys) available every day of the year (no holidays permitted) to resign the zone file? | Example: My cr.yp.to address is extremely stable. But I want the ability | to set up a second cr.yp.to web server with at most one day's notice. | That's why my TTL is 1 day, and it's why any signatures that I create | will expire within 1 day. You can do that with your private zone file - and hope that you're available to resign every day (or you can blow security and stick your key on the server and have it all automated). Don't expect almost anyone else to follow your example. | The question is not, as Crawford would have you believe, whether the old | data lasted for a month. The question is how much _warning_ you have | before the old data is replaced with the new data. That's what TTLs | measure, and it's what expiration dates measure. That's absolutely true, except I doubt that Matt expects anyone to believe what you claim he does. It certainly isn't what he said. | Conclusion: The computer will sign every record every day. And that's not a conclusion at all, but a speculation, and most likely, for most sites, an obviously bogus one. | Renumbering | every day, with AAAA or A6, adds _nothing_ to this signing cost. That would be true, if you were resigning everything every day, but almost no-one is going to be doing that. For A6/AAAA records, which is where this discussion started, the average system will retain the same set of interface identifiers for long periods (very long periods), and on the odd occasions when those are to change, a delay before making the change is entirely acceptable. It doesn't have to happen right now. Nothing is going to require that. Hence a long expiration time is just fine (how long will depend upon individual site requirements, for me, I think 3 months would be about right). On the other hand, someone else can command me to change the upper parts of the address (my ISP just changed its ISP for whatever reason, all their addresses are now from a different block, they're keeping the old ones for a week...) In that situation I have to be able to change the upper bits quickly, those can be out of my control. So that part I need to be able to update quickly, that one I will have to resign fairly frequently (I'd probably make it once or twice a week though, not once a day). | As for ``replace'': It's true that a better-designed protocol would | simply use absolute dates, That would be nice, if we could mandate that any two systems use the same idea of the time. Until that happens (like never) relative times are what works (well enough). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 27 04:09:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB9VE09712 for ipng-dist; Fri, 27 Jul 2001 04:09:31 -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 f6RB9NY09694 for ; Fri, 27 Jul 2001 04:09: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 EAA28062 for ; Fri, 27 Jul 2001 04:09:33 -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 FAA16753 for ; Fri, 27 Jul 2001 05:10:34 -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 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 Jul 27 04:13:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RBCWU10035 for ipng-dist; Fri, 27 Jul 2001 04:12:32 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RBCRY10017; Fri, 27 Jul 2001 04:12:27 -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 EAA13452; Fri, 27 Jul 2001 04:12:40 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11122; Fri, 27 Jul 2001 05:12:36 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id UAA18110; Fri, 27 Jul 2001 20:07:10 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13798; Fri, 27 Jul 2001 04:12:07 -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 EAA28200; Fri, 27 Jul 2001 04:09:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB5mA09600 for ngtrans-dist; Fri, 27 Jul 2001 04:05:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RB5HY09578; Fri, 27 Jul 2001 04:05: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 EAA14239; Fri, 27 Jul 2001 04:05:30 -0700 (PDT) Received: from explore.kwangwoon.ac.kr ([128.134.70.30]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07793; Fri, 27 Jul 2001 05:05:26 -0600 (MDT) Received: from ics-svr3 (ics-svr3.kwangwoon.ac.kr [128.134.70.20]) by explore.kwangwoon.ac.kr (8.9.3/8.9.3) with SMTP id TAA17571; Fri, 27 Jul 2001 19:59:58 +0900 (KST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07472; Fri, 27 Jul 2001 05:04:34 -0600 (MDT) 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 EAA27409; Fri, 27 Jul 2001 04:02:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RB1L009522 for ngtrans-dist; Fri, 27 Jul 2001 04:01:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RB0eY09503; Fri, 27 Jul 2001 04:00:41 -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 EAA12742; Fri, 27 Jul 2001 04:00:53 -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 FAA05993; Fri, 27 Jul 2001 05:00:48 -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 f6RB03n02263; Fri, 27 Jul 2001 18:00:04 +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: (ngtrans) Re: NGtrans - DNSext joint meeting, call for participation In-Reply-To: References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jul 2001 18:00:03 +0700 Message-ID: <2261.996231603@brandenburg.cs.mu.OZ.AU> Reply-To: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 25 Jul 2001 06:28:32 -0700 From: "D. J. Bernstein" Message-ID: | Crawford wants your signatures today to last for a month. I doubt that Matt cares how long anyone's, but his own, signatures last. | What happens | if you decide tomorrow to change a machine's address list---for example, | adding or removing a second address? I wait until the previous signed record is ready to be resigned, and then I sign new ones, with different data, different TTLs, or anything else that I want. | Answer: An attacker can interfere with this change for 29 agonizing | days. All he has to do is replay the old data under the old signature. This has nothing whatever to do with attackers - the only way an attacker can interfere with this is if you're attempting to bypass the protocols. What you're really saying here is that people shouldn't use long expiration dates. What you should be doing, is explaining the pros and cons of different signing policies. I know that for most of my systems, nothing ever changes - and if something is to change, I can wait several weeks for it to happen (generally it takes that long to build up the energy to make the change anyway). Trivial stuff like ethernet cards dying, etc, can be handled by just configuring the (IPv6) address of the system to what it used to autoconfig to, until it is time to update the DNS (if ever). Adding new interfaces, addresses, etc - all takes planning. That all takes time. Now certainly when designing my signing policy I should be taking into account all of these factors. But when I do that I know that I am not going to come up with any simple number as the answer for everyone. | Are you willing to have your old data persist for a month after you make | a change? Of course not. No, but if I define things that way, I'm prepared to wait a month before making the change, so I can do it properly. If I didn't want to wait that long I'd use a smaller expiration time. | This is why typical TTLs are at most 1 day, and Yes, and because they're cheap (the cost of a 1 day, compared to 7 day expiration is negligible). | it's why typical expiration dates will be at most 1 day in the future. But that's not cheap. And it almost certainly simply won't work in general. Signing, and retaining security, is a time consuming business (the CPU time consumed is not what I am measuring here, but the human time). The data needs to be somehow carried to the key (which cannot be exposed anywhere near any network), the signing done, and then the data carried back again. Doing that once a month for most people just might be tolerable - once a day and all that will ever exist are expired signatures. After all, how many sites are going to have people (people with authority to get at the keys) available every day of the year (no holidays permitted) to resign the zone file? | Example: My cr.yp.to address is extremely stable. But I want the ability | to set up a second cr.yp.to web server with at most one day's notice. | That's why my TTL is 1 day, and it's why any signatures that I create | will expire within 1 day. You can do that with your private zone file - and hope that you're available to resign every day (or you can blow security and stick your key on the server and have it all automated). Don't expect almost anyone else to follow your example. | The question is not, as Crawford would have you believe, whether the old | data lasted for a month. The question is how much _warning_ you have | before the old data is replaced with the new data. That's what TTLs | measure, and it's what expiration dates measure. That's absolutely true, except I doubt that Matt expects anyone to believe what you claim he does. It certainly isn't what he said. | Conclusion: The computer will sign every record every day. And that's not a conclusion at all, but a speculation, and most likely, for most sites, an obviously bogus one. | Renumbering | every day, with AAAA or A6, adds _nothing_ to this signing cost. That would be true, if you were resigning everything every day, but almost no-one is going to be doing that. For A6/AAAA records, which is where this discussion started, the average system will retain the same set of interface identifiers for long periods (very long periods), and on the odd occasions when those are to change, a delay before making the change is entirely acceptable. It doesn't have to happen right now. Nothing is going to require that. Hence a long expiration time is just fine (how long will depend upon individual site requirements, for me, I think 3 months would be about right). On the other hand, someone else can command me to change the upper parts of the address (my ISP just changed its ISP for whatever reason, all their addresses are now from a different block, they're keeping the old ones for a week...) In that situation I have to be able to change the upper bits quickly, those can be out of my control. So that part I need to be able to update quickly, that one I will have to resign fairly frequently (I'd probably make it once or twice a week though, not once a day). | As for ``replace'': It's true that a better-designed protocol would | simply use absolute dates, That would be nice, if we could mandate that any two systems use the same idea of the time. Until that happens (like never) relative times are what works (well enough). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 27 11:17:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RIH9V15448 for ipng-dist; Fri, 27 Jul 2001 11:17:09 -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 f6RIH5Y15441 for ; Fri, 27 Jul 2001 11:17: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 LAA18642 for ; Fri, 27 Jul 2001 11:17:17 -0700 (PDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21636 for ; Fri, 27 Jul 2001 12:17:15 -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 NAA66270 for ; Fri, 27 Jul 2001 13:15:15 -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 f6RIHGL39486 for ; Fri, 27 Jul 2001 14:17:16 -0400 Importance: Normal Subject: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kristine Adamson" Date: Fri, 27 Jul 2001 14:17:13 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/27/2001 02:17:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, Can you tell me what the intended relationship is between the IPv6 MIBs in RFC2452, RFC2454, RFC2465, and RFC2466 and the new MIBs the IPv6 MIB Design team is working on? Is it intended that the new MIBs will replace the previous MIBs? Or does the team expect some platforms to implement the previous MIBs and some platforms to implement the new MIBs? Is the team aware of any platforms that have implemented the previous MIBs and any Network Management applications that are using them? Thanks! Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 27 12:39:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RJYdK15981 for ipng-dist; Fri, 27 Jul 2001 12:34:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RJYZY15974 for ; Fri, 27 Jul 2001 12:34:35 -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 MAA16455 for ; Fri, 27 Jul 2001 12:34:38 -0700 (PDT) Received: from zcars0m9.ca.nortel.com ([47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26430 for ; Fri, 27 Jul 2001 13:36:06 -0600 (MDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6RJYF907266 for ; Fri, 27 Jul 2001 15:34:15 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.ca.nortel.com; Fri, 27 Jul 2001 15:34:16 -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 PL4DXDJJ; Fri, 27 Jul 2001 15:34:16 -0400 Received: from americasm06.nt.com (DEATHVALLEY [47.16.4.152]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id PMH5MZRV; Fri, 27 Jul 2001 15:34:16 -0400 Message-ID: <3B61C226.63A3D88D@americasm06.nt.com> Date: Fri, 27 Jul 2001 15:33:59 -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: Kristine Adamson CC: ipng@sunroof.eng.sun.com Subject: Re: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kristine, The new mibs are intended to replace the existing IPv6 mibs. I am not aware of any platforms that have implemented the old mibs, but I am sure someone will point some out. Regards, Brian Kristine Adamson wrote: > > Bill, > Can you tell me what the intended relationship is between the IPv6 MIBs > in RFC2452, RFC2454, RFC2465, and RFC2466 and the new MIBs the IPv6 MIB > Design team is working on? Is it intended that the new MIBs will replace > the previous MIBs? Or does the team expect some platforms to implement the > previous MIBs and some platforms to implement the new MIBs? Is the team > aware of any platforms that have implemented the previous MIBs and any > Network Management applications that are using them? > > Thanks! > > Kristine Adamson > IBM Communications Server for MVS: TCP/IP Development > Internet e-mail:adamson@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 Fri Jul 27 12:48:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RJlvT16113 for ipng-dist; Fri, 27 Jul 2001 12:47:57 -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 f6RJloY16106 for ; Fri, 27 Jul 2001 12:47:50 -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 MAA07606 for ; Fri, 27 Jul 2001 12:48:03 -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 MAA29881 for ; Fri, 27 Jul 2001 12:48:02 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4546A4B20; Sat, 28 Jul 2001 04:47:16 +0900 (JST) To: "Brian Haberman" Cc: Kristine Adamson , ipng@sunroof.eng.sun.com In-reply-to: haberman's message of Fri, 27 Jul 2001 15:33:59 -0400. <3B61C226.63A3D88D@americasm06.nt.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: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 From: itojun@iijlab.net Date: Sat, 28 Jul 2001 04:47:14 +0900 Message-ID: <23563.996263234@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Kristine, > The new mibs are intended to replace the existing IPv6 mibs. I >am not aware of any platforms that have implemented the old mibs, but >I am sure someone will point some out. free software: ucd-snmp (now net-snmp?) implements most of the older RFCs. vendor routers: I know of multiple products which implements older RFCs. therefore, you can't just make the old ones obsolete (you cannot reuse codepoints). 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 Jul 27 13:31:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RKUr316321 for ipng-dist; Fri, 27 Jul 2001 13:30:53 -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 f6RKUnY16314 for ; Fri, 27 Jul 2001 13:30:49 -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 NAA13510 for ; Fri, 27 Jul 2001 13:31:02 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21317 for ; Fri, 27 Jul 2001 14:32:28 -0600 (MDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id E06241E3AC; Fri, 27 Jul 2001 16:31:00 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA18778; Fri, 27 Jul 2001 16:30:59 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA06020; Fri, 27 Jul 2001 13:30:59 -0700 (PDT) Message-Id: <200107272030.NAA06020@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: itojun@iijlab.net Subject: Re: New IPv6 MIBs and RFC2452, RFC2454, RFC2465, and RFC2466 Cc: adamson@us.ibm.com, ipng@sunroof.eng.sun.com Date: Fri, 27 Jul 2001 13:30:59 -0700 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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.). The intent is definitely not to suddenly cause existing implementations to be non-standard, but to encourage evolution. 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 Jul 27 13:55:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RKsfn16467 for ipng-dist; Fri, 27 Jul 2001 13:54:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RKsbY16460 for ; Fri, 27 Jul 2001 13:54:38 -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 NAA29132 for ; Fri, 27 Jul 2001 13:54:52 -0700 (PDT) Received: from nukeserv.atinucleus.com (atimail.atinucleus.com [208.239.168.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA00973 for ; Fri, 27 Jul 2001 14:56:18 -0600 (MDT) Message-ID: <008f01c116ef$43d6a5e0$26a8efd0@atinucleus.com> Reply-To: "Tammy Leino" From: "Tammy Leino" To: Subject: Processing Neighbor Advertisements Date: Fri, 27 Jul 2001 15:55:42 -0700 Organization: ati MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01C116B4.96C82CF0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_008C_01C116B4.96C82CF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello All - According to RFC 2461 section 7.2.5 - Receipt of Neighbor = Advertisements, a host is to set the isRouter flag in the Neighbor Cache = entry based on the Router flag in the received advertisement. So, if the flag changes, should the host make the necessary = modifications to the Default Router list also? Thank you in advance, TL ------=_NextPart_000_008C_01C116B4.96C82CF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello All -
 
According to RFC 2461 section 7.2.5 - = Receipt of=20 Neighbor Advertisements, a host is to set the isRouter flag in the = Neighbor=20 Cache entry based on the Router flag in the received = advertisement.
 
So, if the flag changes, should the = host make the=20 necessary modifications to the Default Router list also?
 
Thank you in advance,
TL
------=_NextPart_000_008C_01C116B4.96C82CF0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 27 14:52:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6RLpLq16999 for ipng-dist; Fri, 27 Jul 2001 14:51:21 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RLpGY16992; Fri, 27 Jul 2001 14:51:16 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-194.EBay.Sun.COM [129.150.4.194]) by jurassic.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6RLpPS532540; Fri, 27 Jul 2001 14:51:25 -0700 (PDT) Message-Id: <5.1.0.14.0.20010727144036.0368da40@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 27 Jul 2001 14:57:58 -0700 To: ngtrans List , dnsop@cafax.se, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: Alain Durand Subject: Reading materials for the joint NGtrans-DNSext meeting in London Cc: olafur Gudmundsson , randy Bush , tony@tndh.net, fink@es.net, erik Nordmark , Thomas Narten , bwijnen@lucent.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The goal of the joint meeting is to facilitate consensus on how IPv6 addresses are represented in DNS and related issues. This meeting requires extensive homework by participants. Here is the list of material that have been submitted to the wg chairs and will be used during the discussion in London. Knowledge of those documents will be assumed in London, so we strongly encourage reading them all prior to the meeting! 1 Rob Austein: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt 2 Christian Huitema: http://www.ietf.org/internet-drafts/draft-huitema-ipv6-renumber-00.txt 3 Matt Crawford: http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt 4 Jun-ichiro itojun Hagino : http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aaaa-a6-01.txt 5 Dan Bernstein: http://cr.yp.to/djbdns/killa6.html For those who need it, a short introduction to DNSSEC can be found at: http://www.pgp.com/research/nailabs/network-security/an-introduction.asp Good reading! - the chairs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 27 17:37:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S0bLl18010 for ipng-dist; Fri, 27 Jul 2001 17:37:21 -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 f6S0bHY18003; Fri, 27 Jul 2001 17:37:17 -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 RAA01230; Fri, 27 Jul 2001 17:37:31 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24449; Fri, 27 Jul 2001 18:37:27 -0600 (MDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f6S0acu60948; Sat, 28 Jul 2001 10:36:39 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200107280036.f6S0acu60948@drugs.dv.isc.org> To: Robert Elz Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Mark.Andrews@nominum.com Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "Fri, 27 Jul 2001 18:00:03 +0700." <2261.996231603@brandenburg.cs.mu.OZ.AU> Date: Sat, 28 Jul 2001 10:36:38 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, there is no requirement to re-sign every record to achieve your 1 day expiry. Just change the zone key whenever you change zone data and have a 1 day expiry on the zone key's signature. So daily you re-sign two RRsets. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Fri Jul 27 23:09:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S68jK19605 for ipng-dist; Fri, 27 Jul 2001 23:08:45 -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 f6S68cY19589 for ; Fri, 27 Jul 2001 23:08:38 -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 XAA07406 for ; Fri, 27 Jul 2001 23:08:52 -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 AAA01901 for ; Sat, 28 Jul 2001 00:10:18 -0600 (MDT) Received: (qmail 5495 invoked by uid 1001); 28 Jul 2001 06:08:23 -0000 Date: 28 Jul 2001 06:08:23 -0000 Message-ID: <20010728060823.20080.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 - DNSext joint meeting, call for participation References: <2261.996231603@brandenburg.cs.mu.OZ.AU> <200107280036.f6S0acu60948@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark.Andrews@nominum.com writes: > there is no requirement to re-sign every record to achieve > your 1 day expiry. Just change the zone key whenever you change > zone data and have a 1 day expiry on the zone key's signature. No. If you maintain the validity of signatures on old records, you're allowing the attack to succeed. If you don't maintain the validity of those signatures, you have to immediately sign those records again. Please withdraw your claim. ---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 Sat Jul 28 00:32:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S7VPI19784 for ipng-dist; Sat, 28 Jul 2001 00:31:25 -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 f6S7VKY19777; Sat, 28 Jul 2001 00:31:20 -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 AAA03601; Sat, 28 Jul 2001 00:31:33 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20715; Sat, 28 Jul 2001 01:31:30 -0600 (MDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f6S7VKu63249; Sat, 28 Jul 2001 17:31:20 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200107280731.f6S7VKu63249@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Mark.Andrews@nominum.com Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "28 Jul 2001 06:08:23 GMT." <20010728060823.20080.qmail@cr.yp.to> Date: Sat, 28 Jul 2001 17:31:20 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mark.Andrews@nominum.com writes: > > there is no requirement to re-sign every record to achieve > > your 1 day expiry. Just change the zone key whenever you change > > zone data and have a 1 day expiry on the zone key's signature. > > No. If you maintain the validity of signatures on old records, you're > allowing the attack to succeed. If you don't maintain the validity of > those signatures, you have to immediately sign those records again. > > Please withdraw your claim. Dan, your claim is that you have to re-sign every record in a zone daily to achieve a 1 day replay window. I'm stating that you can achieve the same protection without re-signing every record daily. Pre change: example.com KEY alpha example.com SIG KEY expire=200107292257 (1 day) host.example.com A 1.2.3.4 host.example.com SIG A expire=200108272257 (30 days) Post change: example.com KEY beta example.com SIG KEY expire=200107072258 (1 day) host.example.com A 1.2.3.5 host.example.com SIG A expire=200108272258 (30 days) Please explain how you can verify host.example.com A 1.2.3.4 host.example.com SIG A expire=200108272257 after 200107292257. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Sat Jul 28 00:40:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S7cAi19836 for ipng-dist; Sat, 28 Jul 2001 00:38:10 -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 f6S7c4Y19829; Sat, 28 Jul 2001 00:38: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 AAA03877; Sat, 28 Jul 2001 00:38:18 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21909; Sat, 28 Jul 2001 01:38:14 -0600 (MDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f6S7c8u63269; Sat, 28 Jul 2001 17:38:08 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200107280738.f6S7c8u63269@drugs.dv.isc.org> To: Mark.Andrews@nominum.com Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Mark.Andrews@nominum.com Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "Sat, 28 Jul 2001 17:31:20 +1000." Date: Sat, 28 Jul 2001 17:38:08 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Mark.Andrews@nominum.com writes: > > > there is no requirement to re-sign every record to achieve > > > your 1 day expiry. Just change the zone key whenever you change > > > zone data and have a 1 day expiry on the zone key's signature. > > > > No. If you maintain the validity of signatures on old records, you're > > allowing the attack to succeed. If you don't maintain the validity of > > those signatures, you have to immediately sign those records again. > > > > Please withdraw your claim. > > Dan, > your claim is that you have to re-sign every record in > a zone daily to achieve a 1 day replay window. I'm stating > that you can achieve the same protection without re-signing > every record daily. > > Pre change: > example.com KEY alpha > example.com SIG KEY expire=200107292257 (1 day) > host.example.com A 1.2.3.4 > host.example.com SIG A expire=200108272257 (30 days) > > Post change: > example.com KEY beta > example.com SIG KEY expire=200107072258 (1 day) This should have been example.com SIG KEY expire=200107272258 (1 day) > host.example.com A 1.2.3.5 > host.example.com SIG A expire=200108272258 (30 days) > > Please explain how you can verify > host.example.com A 1.2.3.4 > host.example.com SIG A expire=200108272257 > after 200107292257. > > Mark > -- > Mark Andrews, Nominum Inc. > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Sat Jul 28 00:48:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6S7kx219904 for ipng-dist; Sat, 28 Jul 2001 00:46:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6S7ksY19897; Sat, 28 Jul 2001 00:46:54 -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 AAA13285; Sat, 28 Jul 2001 00:46:58 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA21662; Sat, 28 Jul 2001 01:46:39 -0600 (MDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f6S7j3u63311; Sat, 28 Jul 2001 17:45:03 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200107280745.f6S7j3u63311@drugs.dv.isc.org> To: Mark.Andrews@nominum.com Cc: "D. J. Bernstein" , ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Mark.Andrews@nominum.com Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "Sat, 28 Jul 2001 17:38:08 +1000." <200107280738.f6S7c8u63269@drugs.dv.isc.org> Date: Sat, 28 Jul 2001 17:45:03 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Third time lucky ... > Dan, > your claim is that you have to re-sign every record in > a zone daily to achieve a 1 day replay window. I'm stating > that you can achieve the same protection without re-signing > every record daily. > > Pre change: > example.com KEY alpha > example.com SIG KEY expire=200107292257 (1 day) > host.example.com A 1.2.3.4 > host.example.com SIG A expire=200108272257 (30 days) > > Post change: > example.com KEY beta > example.com SIG KEY expire=200107072258 (1 day) This should have been example.com SIG KEY expire=200107292258 (1 day) > host.example.com A 1.2.3.5 > host.example.com SIG A expire=200108272258 (30 days) > > Please explain how you can verify > host.example.com A 1.2.3.4 > host.example.com SIG A expire=200108272257 > after 200107292257. > > Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Sun Jul 29 05:14:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6TCDxm23476 for ipng-dist; Sun, 29 Jul 2001 05:13:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6TCDqY23468 for ; Sun, 29 Jul 2001 05:13:53 -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 FAA26292 for ; Sun, 29 Jul 2001 05:14:06 -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 FAA15015 for ; Sun, 29 Jul 2001 05:14:04 -0700 (PDT) Received: (qmail 86 invoked by uid 1001); 29 Jul 2001 12:14:24 -0000 Date: 29 Jul 2001 12:14:24 -0000 Message-ID: <20010729121424.4964.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 - DNSext joint meeting, call for participation References: <20010728060823.20080.qmail@cr.yp.to> <200107280731.f6S7VKu63249@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark.Andrews@nominum.com writes: > Pre change: > example.com SIG KEY expire=200107292257 (1 day) > host.example.com SIG A expire=200108272257 (30 days) > Post change: > example.com SIG KEY expire=200107072258 (1 day) > host.example.com SIG A expire=200108272258 (30 days) You are, as I said, signing the host record again. You have to sign all your other records too, never mind the costs of generating and distributing the new key. If you change at least one of your records every day---certainly a reasonable assumption for the big organizations we're talking about--- then you are signing all your records every day. The key change isn't accomplishing anything. The bottom line remains the same. Even without renumbering, you are signing every record every day. If that isn't a problem, then occasional renumbering certainly isn't a problem. If you have one day warning, you can renumber for free. ---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 Jul 29 06:27:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6TDQXg23972 for ipng-dist; Sun, 29 Jul 2001 06:26:33 -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 f6TDQTY23965; Sun, 29 Jul 2001 06:26:29 -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 GAA22937; Sun, 29 Jul 2001 06:26:43 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18704; Sun, 29 Jul 2001 07:28:09 -0600 (MDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f6TDQ7u84010; Sun, 29 Jul 2001 23:26:10 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200107291326.f6TDQ7u84010@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se From: Mark.Andrews@nominum.com Subject: Re: NGtrans - DNSext joint meeting, call for participation In-reply-to: Your message of "29 Jul 2001 12:14:24 GMT." <20010729121424.4964.qmail@cr.yp.to> Date: Sun, 29 Jul 2001 23:26:07 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mark.Andrews@nominum.com writes: > > Pre change: > > example.com SIG KEY expire=200107292257 (1 day) > > host.example.com SIG A expire=200108272257 (30 days) > > Post change: > > example.com SIG KEY expire=200107072258 (1 day) > > host.example.com SIG A expire=200108272258 (30 days) > > You are, as I said, signing the host record again. You have to sign all > your other records too, never mind the costs of generating and > distributing the new key. Is the cost of generating a new key occasionally more or less than that of signing all the zone daily. As for the cost of distributing the new key, it is no different to continue to distribute the old key apart from the cost in getting it signed (which is the same in both your and my cases). > > If you change at least one of your records every day---certainly a > reasonable assumption for the big organizations we're talking about--- > then you are signing all your records every day. The key change isn't > accomplishing anything. You are making ungrounded assumptions here. Not all large organizations keep everything in one flat namespace. If you use the DNS as it was designed to be used you don't see every zone in a organization changing daily or even monthly (or even a large pecentage of them). > > The bottom line remains the same. Even without renumbering, you are > signing every record every day. Really. Real life has plenty of examples where existing zones are not changed daily. To get 1 day replay protection something needs to be signed daily, however it doesn't have to be everything. > If that isn't a problem, then occasional > renumbering certainly isn't a problem. If you have one day warning, you > can renumber for free. Iff your assumptions hold true. In the real world there are plenty of case they don't. > > ---Dan Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@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 Sun Jul 29 07:01:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6TE0NY24196 for ipng-dist; Sun, 29 Jul 2001 07:00: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 f6TE0IY24187 for ; Sun, 29 Jul 2001 07:00: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 HAA09200 for ; Sun, 29 Jul 2001 07:00:33 -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 IAA21684 for ; Sun, 29 Jul 2001 08:00:31 -0600 (MDT) Received: (qmail 3202 invoked by uid 1001); 29 Jul 2001 13:57:07 -0000 Date: 29 Jul 2001 13:57:07 -0000 Message-ID: <20010729135707.10649.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) Re: NGtrans - DNSext joint meeting, call for participation References: <200107202005.f6KK50F11379@gungnir.fnal.gov> <20010723140044.A17822@pianosa.catch22.org> <2261.996231603@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: > The data needs to be somehow carried to the key (which cannot be > exposed anywhere near any network), the signing done, and then the > data carried back again. Doing that once a month for most people > just might be tolerable - once a day and all that will ever exist are > expired signatures. How, pray tell, do you expect a large site to sign its DNS records, if it has access to its signing key only twelve times a year? This is even worse than ``wait a month for old records to go away.'' It also means ``wait a month for new records to appear.'' Do you seriously believe that administrators and users will tolerate this? ---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 Mon Jul 30 05:50:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UCnQo27968 for ipng-dist; Mon, 30 Jul 2001 05:49:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UCnLY27961 for ; Mon, 30 Jul 2001 05:49:21 -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 FAA03902 for ; Mon, 30 Jul 2001 05:49:36 -0700 (PDT) Received: from solan.itea.ntnu.no (solan.itea.ntnu.no [129.241.190.100]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18811 for ; Mon, 30 Jul 2001 05:49:34 -0700 (PDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by solan.itea.ntnu.no (8.11.1/8.11.1) with ESMTP id f6UCm8012756; Mon, 30 Jul 2001 14:49:28 +0200 (MET DST) Received: (from venaas@localhost) by alfa.itea.ntnu.no (8.11.1/8.11.1) id f6UCkmC12560; Mon, 30 Jul 2001 14:46:48 +0200 (MET DST) Date: Mon, 30 Jul 2001 14:46:47 +0200 From: Stig Venaas To: ipng@sunroof.eng.sun.com Cc: richdr@microsoft.com Subject: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt Message-ID: <20010730144647.A13982@itea.ntnu.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i 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? 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. 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). Stig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 30 06:20:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UDJg828040 for ipng-dist; Mon, 30 Jul 2001 06:19:42 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UDJbY28033 for ; Mon, 30 Jul 2001 06:19:37 -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 f6UDJm213127; Mon, 30 Jul 2001 15:19:48 +0200 (MET DST) Date: Mon, 30 Jul 2001 15:17:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Processing Neighbor Advertisements To: Tammy Leino Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <008f01c116ef$43d6a5e0$26a8efd0@atinucleus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > According to RFC 2461 section 7.2.5 - Receipt of Neighbor Advertisements, a > host is to set the isRouter flag in the Neighbor Cache entry based on the > Router flag in the received advertisement. > > So, if the flag changes, should the host make the necessary modifications to > the Default Router list also? See section 7.2.5 which says - The IsRouter flag in the cache entry MUST be set based on the Router flag in the received advertisement. In those cases where the IsRouter flag changes from TRUE to FALSE as a result of this update, the node MUST remove that router from the Default Router List and update the Destination Cache entries for all destinations using that neighbor as a router as specified in Section 7.3.3. This is needed to detect when a node that is used as a router stops forwarding packets due to being configured as a host. 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 Jul 30 11:39:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6UIcli00949 for ipng-dist; Mon, 30 Jul 2001 11:38:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6UIcgY00942 for ; Mon, 30 Jul 2001 11:38:42 -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 LAA15802 for ; Mon, 30 Jul 2001 11:38:56 -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 LAA27046 for ; Mon, 30 Jul 2001 11:38:51 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Mon, 30 Jul 2001 11:38:39 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id F795D5F1045D49738F90AEF3D0197340 for plus 2 more; Mon, 30 Jul 2001 11:38:39 -0700 Reply-To: From: "Tony Hain" To: "Stig Venaas" , Cc: Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt Date: Mon, 30 Jul 2001 11:38: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: <20010730144647.A13982@itea.ntnu.no> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 51D014F6-8E4B4C7B-949D7425-FCE06374 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f6UIchY00943 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stig Venaas wrote: > 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. Consider that an IPv4 network is nothing more than an NBMA link to an IPv6 node that implements 6to4 and/or ISATAP and your perception of address sorting for nodes in an IPv4-only net may change. > 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. Your use of the terms on-link & default route together could be part of the confusion. For one, the concept of a default route applies to the next hop used when there is no obvious path for this destination, and for all on-link nodes there is an obvious path. For the other, the next hop for the default route is by definition on-link. I can't say without a picture what that last line means, but if an implementation believes that all addresses exist on its link, that implementation would appear to be broken. In an IPv4 world it might have made sense to try an arp for an off-link prefix since most nodes only have one useful address, but in an IPv6 world it makes little sense to try ND for an off-link prefix when the link-local address should work and is the appropriate scope. > Or does anyone think that we actually should use this > algorithm then as well; preferring RFC 1918 destination > for 1918 source etc? The intent in the draft is that 1918's get treated as site local, while draft-ietf-zeroconf-ipv4-linklocal-03.txt are treated as link-local. This sets up the IPv4 space with the same scopes so the addr-select rules apply equally. If the IPv6 scopes don't match but the IPv4 ones do then IPv4 should be used. 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 Jul 31 05:00:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VC0CO04885 for ipng-dist; Tue, 31 Jul 2001 05:00:12 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VC07Y04878 for ; Tue, 31 Jul 2001 05:00:07 -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 f6VC0G227982; Tue, 31 Jul 2001 14:00:16 +0200 (MET DST) Date: Tue, 31 Jul 2001 13:58:05 +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: Stig Venaas , ipng@sunroof.eng.sun.com, richdr@microsoft.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 > Your use of the terms on-link & default route together could be part of the > confusion. For one, the concept of a default route applies to the next hop > used when there is no obvious path for this destination, and for all on-link > nodes there is an obvious path. For the other, the next hop for the default > route is by definition on-link. I can't say without a picture what that last > line means, but if an implementation believes that all addresses exist on > its link, that implementation would appear to be broken. A node that conforms to RFC 2461 should treat all addresses as being on its link in one case - so I don't think the implementation is broken but correct. 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. 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. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 31 05:09:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VC9HD04922 for ipng-dist; Tue, 31 Jul 2001 05:09: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 f6VC9EY04915 for ; Tue, 31 Jul 2001 05:09: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 FAA08786; Tue, 31 Jul 2001 05:09:26 -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 GAA09255; Tue, 31 Jul 2001 06:09:22 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f6VC9Lg18180; Tue, 31 Jul 2001 15:09:21 +0300 Date: Tue, 31 Jul 2001 15:09:21 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: , Stig Venaas , , Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 31 Jul 2001, Erik Nordmark wrote: > > Your use of the terms on-link & default route together could be part of the > > confusion. For one, the concept of a default route applies to the next hop > > used when there is no obvious path for this destination, and for all on-link > > nodes there is an obvious path. For the other, the next hop for the default > > route is by definition on-link. I can't say without a picture what that last > > line means, but if an implementation believes that all addresses exist on > > its link, that implementation would appear to be broken. > > A node that conforms to RFC 2461 should treat all addresses as being on > its link in one case - so I don't think the implementation is broken but > correct. > > 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. > > 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. One other source of confusion might be that some implementations, when setting routes manually (ie. not autoconfed), instead of setting _default_ route, prefer something like 2000::/3 so "illegal addresses" won't be forwarded. This is an effective default route AFAIS, but might not be one if you go by the definition 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 Jul 31 05:22:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VCMON04958 for ipng-dist; Tue, 31 Jul 2001 05:22:24 -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 f6VCMKY04951; Tue, 31 Jul 2001 05:22:20 -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 FAA23944; Tue, 31 Jul 2001 05:22:33 -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 GAA17053; Tue, 31 Jul 2001 06:22: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 f6VCLQo02916; Tue, 31 Jul 2001 19:21:33 +0700 (ICT) From: Robert Elz To: Olafur Gudmundsson/DNSEXT co-chair , namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, Alain Durand , ipng@sunroof.eng.sun.com Subject: Re: Joint DNSEXT & NGTRANS agenda In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Jul 2001 19:21:26 +0700 Message-ID: <2914.996582086@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 30 Jul 2001 11:55:29 -0700 From: Olafur Gudmundsson/DNSEXT co-chair Message-ID: | 51 IETF DNSEXT NGTRANS Joint Meeting on | IPv6 Addresses in DNS | | Monday 2001/Aug/6 15:30-17:30 | Room: King's Suite/Balmoral 2 I'm not going to be there, and thus didn't write a draft to speak about at the meeting (which the earlier request seemed to be about). I will make some comments about the 5 drafts (well, 4 drafts and a web page) that are to be considered though. Before I begin, I'd like to point out again that this issue really has nothing whatever to do with ngtrans - it should be being considered in the ipngwg rather than ngtrans. This issue has nothing specifically to do with transition arrangements (other than that a solution is needed so the transition can happen - but that is or was true of everything else related to IPv6 - the basic protocol doc might just as well have been done in ngtrans if that was the criteria). ngtrans should be concerning itself with those short term issues needed to allow the v4 internet to turn itself into the v6 internet. The result when that has finished should be what has been defined by the ipngwg, all the ngtrans issues should eventually simply vanish (eventually may be a long time away, that's OK). Nor is this really a dnsext issue - when the RR types were being defined that made sense, but it doesn't really any more. The question is just which RR type (which exists in the DNS definitions already) IPv6 should actually be using (not for the transition period, but forever). Once that decision is made, if ngtrans wants to map a path to get from where we are now, to the eventual end point, that's fine. But it really is a bit hard for ngtrans to plan a transition when the end point isn't yet fixed. | 1 Rob Austein: | This is an excellent analysis of the issues. (It also makes the point that this is really an ipv6 issue - ipngwg that is). About the only issue I have with it is the assumption that whether to use AAAA or A6 should be decided merely by the relative frequency of renumberings expected for IPv6 systems. One reason for not simply going that way, is that it is an issue upon which no-one really agrees. There are hopes, expectations, and dooms day scenarios, which all produce different expectations. Personally I have no idea how frequently IPv6 nets will renumber. What I am sure of however, is that I want to do everything possible to allow for renumberings to happen with the greatest possible ease, with the smallest possible notice, and the greatest possible frequency. Planning that way maximises the chances that we will actually end up with something which will work in the environment that develops - whether that means permanent addresses, and no renumbering at all for anything (ie: we manage to make the routing system deal with routing to arbitrary /128's), or if we end up in a state where major sites are expected to renumber four times a day as traffic patterns shift going to and from the work user and home user peak periods. | 2 Christian Huitema: | This is just a summary of what's involved in renumbering in some interesting cases. The draft is fine, but I'm not sure it adds a whole lot to the A6 vs AAAA debate. | 3 Matt Crawford: | I have nothing much to say about this one, other than that I essentially agree with all of it. | 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. | 5 Dan Bernstein: | And this one points out that with A6 it will be possible for sites to create ludicrous setups that won't work. Without A6 sites can create ludicrous setups that won't work, so there is nothing really new here. Just one extra way to shoot yourself in the foot. Big deal. What is missing in all of this is any real data upon which anyone could really base a decision. There's no comparisons of how many queries it will take to resolve names in various common cases, what the cache effectiveness can be expected to be, how much cache churn renumbering will cause, how big the DNS packets for various scenarios will actually be - nothing like this at all. The effect of that is that any decision on which way to go cannot be based upon any more than either guesswork or fear. I had hoped to have collected some data on all of this by now, but for various reasons it hasn't happened yet (even if it had, there wouldn't have been very much yet, so it probably still would have been premature to use it for much). I am still planning to (ie: actually doing the setup for now) collect some data, initially on A6 vs AAAA - that is, so see whether any extra round trips that are needed actually make a difference to name resolution for rationally configured setups (I'll also look at some irrational configurations of course). 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 Jul 31 05:46:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VCkLo05022 for ipng-dist; Tue, 31 Jul 2001 05:46:21 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f6VCkGY05015 for ; Tue, 31 Jul 2001 05:46:16 -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 f6VCkF205031; Tue, 31 Jul 2001 14:46:15 +0200 (MET DST) Date: Tue, 31 Jul 2001 14:44:04 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt To: Pekka Savola Cc: Erik Nordmark , alh-ietf@tndh.net, Stig Venaas , ipng@sunroof.eng.sun.com, richdr@microsoft.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 > One other source of confusion might be that some implementations, when > setting routes manually (ie. not autoconfed), instead of setting _default_ > route, prefer something like 2000::/3 so "illegal addresses" won't be > forwarded. They are not illegal by any means - see below. > This is an effective default route AFAIS, but might not be one if you go > by the definition above. That would be a very bad idea. What if IANA and the regional registries start handing out addresses outside of this range tomorrow? Then that implementation would not be able to talk to nodes that get addresses from the new range. For this reason the text in has been clarified to state Future specifications may redefine one or more sub-ranges of the global unicast space for other purposes, but unless and until that happens, implementations must treat all addresses that do not start with any of the above-listed prefixes as global unicast addresses. Basically implementations shouldn't have any rules about any prefixes other than ::0/128 ::1/128 0::/3 (and longer prefixes for ipv4-mapped etc) ff80::/10 fec0::/10 ff00::/8 Do we need to make this more clear? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 31 09:16:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VGFv106311 for ipng-dist; Tue, 31 Jul 2001 09:15:57 -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 f6VGFqY06297 for ; Tue, 31 Jul 2001 09:15:53 -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 JAA16036 for ; Tue, 31 Jul 2001 09:15:49 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13737 for ; Tue, 31 Jul 2001 10:15:47 -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 LAA81498 for ; Tue, 31 Jul 2001 11:13:36 -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 f6VGFc449114 for ; Tue, 31 Jul 2001 12:15:38 -0400 Importance: Normal Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt 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 12:15:33 -0400 X-MIMETrack: Serialize by Router on D04MC300/04/M/IBM(Release 5.0.6 |December 14, 2000) at 07/31/2001 12:15:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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. Thanks Lori z/OS Communications Server Development - TCP/IP Stack 919-254-6146 T/L 8-444-6146 E-mail: lanapoli@us.ibm.com Pekka Savola @sunroof.eng.sun.com on 07/31/2001 08:09:21 AM Sent by: owner-ipng@sunroof.eng.sun.com To: Erik Nordmark cc: , Stig Venaas , , Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt On Tue, 31 Jul 2001, Erik Nordmark wrote: > > Your use of the terms on-link & default route together could be part of the > > confusion. For one, the concept of a default route applies to the next hop > > used when there is no obvious path for this destination, and for all on-link > > nodes there is an obvious path. For the other, the next hop for the default > > route is by definition on-link. I can't say without a picture what that last > > line means, but if an implementation believes that all addresses exist on > > its link, that implementation would appear to be broken. > > A node that conforms to RFC 2461 should treat all addresses as being on > its link in one case - so I don't think the implementation is broken but > correct. > > 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. > > 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. One other source of confusion might be that some implementations, when setting routes manually (ie. not autoconfed), instead of setting _default_ route, prefer something like 2000::/3 so "illegal addresses" won't be forwarded. This is an effective default route AFAIS, but might not be one if you go by the definition 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 31 12:33:59 2001 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 31 13:17:03 2001 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 31 16:16:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VNExI08798 for ipng-dist; Tue, 31 Jul 2001 16:14:59 -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 f6VNEsY08791 for ; Tue, 31 Jul 2001 16:14:54 -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 QAA20075 for ; Tue, 31 Jul 2001 16:15:07 -0700 (PDT) Received: from muncher.math.uic.edu (koobera.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA10865 for ; Tue, 31 Jul 2001 16:15:07 -0700 (PDT) Received: (qmail 31740 invoked by uid 1001); 31 Jul 2001 23:15:27 -0000 Date: 31 Jul 2001 23:15:27 -0000 Message-ID: <20010731231527.29955.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: <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 Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > And this one points out that with A6 it will be possible for sites to > create ludicrous setups that won't work. 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. But it destroys connectivity to AOL. All the efficiency issues are minor. The reliability issues are crucial. 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. How is the DNS administrator supposed to tell the difference between ``ludicrous'' A6 records and normal A6 records? > Without A6 sites can create ludicrous setups that won't work, so there > is nothing really new here. My web page explains three ways that A6 and DNAME lead to problems. ``These problems are not new,'' it says. But it then explains why the problems are under control now, and why they will spiral out of control with A6 and DNAME. My web page also analyzes the alleged benefits of A6 and DNAME. ---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 Jul 31 16:52:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f6VNpTG09006 for ipng-dist; Tue, 31 Jul 2001 16:51:29 -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 f6VNpOY08999 for ; Tue, 31 Jul 2001 16:51: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 QAA28161 for ; Tue, 31 Jul 2001 16:51:38 -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 RAA18246 for ; Tue, 31 Jul 2001 17:53:08 -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 TAA05653; Tue, 31 Jul 2001 19:50:26 -0400 (EDT) Message-Id: <200107312350.TAA05653@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , IANA Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Transmission of IPv6 Packets over IEEE 1394 Networks to Proposed Standard Date: Tue, 31 Jul 2001 19:50:26 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Transmission of IPv6 Packets over IEEE 1394 Networks' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery to perform address resolution when the messages are transmitted on an IEEE1394 network. Working Group Summary This document is based heavily on the IPv4 over 1394 specification [RFC 2734] and defers to that specification for the definition of some of its functions. During the Last Call, comments were made that there may be performance problems with the existing IPv4 over 1394 specification and that it may need to be reexamined. Consequently, requests to delay advancement of this document were made. However, at this time, it remains unclear whether and when the IPv4 over 1394 standard will be updated and to what extent such an update will obsolete the current design. Thus, the IESG has approved this document as a Proposed Standard. Like all Proposed Standards, it can be updated at anytime as needed. Protocol Quality This specification has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 31 19:05:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) id f7124LL09269 for ipng-dist; Tue, 31 Jul 2001 19:04:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.5.Beta1+Sun/8.11.5.Beta1) with ESMTP id f7124HY09259 for ; Tue, 31 Jul 2001 19:04:17 -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 TAA25971 for ; Tue, 31 Jul 2001 19:04:32 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA04479 for ; Tue, 31 Jul 2001 19:04:31 -0700 (PDT) Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 31 Jul 2001 18:48:10 -0700 (Pacific Daylight Time) Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 31 Jul 2001 18:48:04 -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 Date: Tue, 31 Jul 2001 18:48:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ad-hoc IPv6 inter-op session at London IETF Thread-Index: AcEaLAST/gXE9GZlSVKHcD4JP1yeFg== From: "Brian Zill" To: Cc: X-OriginalArrivalTime: 01 Aug 2001 01:48:04.0287 (UTC) FILETIME=[01206CF0:01C11A2C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f7124HY09262 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 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 --------------------------------------------------------------------