From owner-ipng@sunroof.eng.sun.com Mon Jan 1 07:01:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id f01F0Bl27488 for ipng-dist; Mon, 1 Jan 2001 07:00:11 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id f01F00H27481 for ; Mon, 1 Jan 2001 07:00:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA22147 for ; Mon, 1 Jan 2001 06:59:47 -0800 (PST) Received: from rubellite.lion-access.net (rubellite.lion-access.net [212.19.217.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28783 for ; Mon, 1 Jan 2001 06:59:46 -0800 (PST) Received: from xtreme (1Cust8.tnt26.rtm1.nl.uu.net [213.116.146.8]) by rubellite.lion-access.net (I-Lab) with SMTP id 56A0C28B1; Mon, 1 Jan 2001 14:58:46 +0000 (GMT) From: "Joris Dobbelsteen" To: "6Bone (E-mail)" <6Bone@isi.edu>, "Enum WG (E-mail)" , "FTPEXT WG (E-mail)" , "IDR WG (E-mail)" , "IPng WG (E-mail)" , "IPTel WG (E-mail)" , "Kerberos WG (E-mail)" , "Lynx-Dev (E-mail)" , "NAT WG (E-mail)" , "OSPF WG (E-mail)" , "WebDAV WG (E-mail)" , "WREC WG (E-mail)" , "WWW WG (E-mail)" Subject: Happy new year Date: Mon, 1 Jan 2001 16:01:04 +0100 Message-ID: <000701c07403$aa00d8c0$01ff1fac@Joris2K.local> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To all WGs I'm subscribed to, nobody does it, so I'll just send it: Happy new year and a good start of the new millennium Hope I can say this for all members of the WGs... - Joris -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 2 02:16:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) id f02AErg27819 for ipng-dist; Tue, 2 Jan 2001 02:14:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2.Beta2+Sun/8.11.2.Beta2) with ESMTP id f02AEhH27812 for ; Tue, 2 Jan 2001 02:14:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA10425 for ; Tue, 2 Jan 2001 02:14:42 -0800 (PST) Received: from warp.seabridge.co.il (warp.seabridgenetworks.com [212.25.127.242]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19057 for ; Tue, 2 Jan 2001 03:14:34 -0700 (MST) Received: from tiger.seabridge.co.il (tiger.seabridge.co.il [172.30.10.101]) by warp.seabridge.co.il (8.9.3/8.9.3) with ESMTP id NAA25401 for ; Tue, 2 Jan 2001 13:34:34 +0200 Received: by tiger.seabridge.co.il with Internet Mail Service (5.5.2650.21) id <45GL30B7>; Tue, 2 Jan 2001 12:11:16 +0200 Message-ID: From: Doron Hirsch To: "'ipng@sunroof.eng.sun.com'" Subject: Forwarding Issues Date: Tue, 2 Jan 2001 12:11:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C074A4.575C4FE0" 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_01C074A4.575C4FE0 Content-Type: text/plain; charset="windows-1255" Greetings, I would very much appreciate your kind help regarding Forwarding issues: RFC 2374: "IPv6 Global Unicast Address Format", states the following: "IPv6 unicast addresses are designed assuming that the Internet routing system makes forwarding decisions based on a "longest prefix match" algorithm on arbitrary bit boundaries ..." 1) Does this mean that Forwarding in IPv6 is performed in the exact same way that it is done in IPv4? 2) If not, How is it done? 3) Where can i find information about IPv6 Forwarding? Kind regards, Hirsch Doron. ------_=_NextPart_001_01C074A4.575C4FE0 Content-Type: text/html; charset="windows-1255" Forwarding Issues

Greetings,

I would very much appreciate your kind help regarding Forwarding issues:

RFC 2374: "IPv6 Global Unicast Address Format", states the following:

   "IPv6 unicast addresses are designed assuming that the Internet
   routing system makes forwarding decisions based on a "longest prefix
   match" algorithm on arbitrary bit boundaries ..."

1) Does this mean that Forwarding in IPv6 is performed in the exact same way that it is done in IPv4?

2) If not, How is it done?

3) Where can i find information about IPv6 Forwarding?


Kind regards,
Hirsch Doron.

------_=_NextPart_001_01C074A4.575C4FE0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jan 5 09:20:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f05HIUq00269 for ipng-dist; Fri, 5 Jan 2001 09:18:30 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f05HIL600257 for ; Fri, 5 Jan 2001 09:18:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA15211 for ; Fri, 5 Jan 2001 09:18:21 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20382 for ; Fri, 5 Jan 2001 09:18:20 -0800 (PST) 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 CAA14033 for ; Sat, 6 Jan 2001 02:01:08 +0900 (JST) Date: Sat, 06 Jan 2001 02:17:48 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: [rfc2553bis] EAI_NODATA User-Agent: Wanderlust/2.3.0 (Roam) 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 20000414(IM141) Lines: 11 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (This may have already been discussed. if so, I'd apologize in advance.) I noticed that description about EAI_NODATA had disappeared since draft-ietf-ipngwg-rfc2553bis-00.txt. However, the macro is still in the summary list in the latest draft (01). Has the value been obsoleted, or should it be described again? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jan 7 14:20:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f07MJ8301292 for ipng-dist; Sun, 7 Jan 2001 14:19:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f07MIw601285 for ; Sun, 7 Jan 2001 14:18:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA01186 for ; Sun, 7 Jan 2001 14:18:59 -0800 (PST) Received: from smtp2.kolumbus.fi (smtp2.kolumbus.fi [193.229.0.37]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06718 for ; Sun, 7 Jan 2001 14:18:58 -0800 (PST) Received: from jariws1 (ab16d3hel.dial.kolumbus.fi [212.54.18.16]) by smtp2.kolumbus.fi (8.9.0/8.9.0) with SMTP id AAA29366; Mon, 8 Jan 2001 00:18:39 +0200 (EET) Message-ID: <003c01c078f7$cd4cedc0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Stephen Kent" Cc: , , References: <008e01c0610c$16237c20$8a1b6e0a@arenanet.fi> <20001211082557.A2125@orca.informatik.uni-ulm.de> <3A362BA2.D7EF1481@piuha.net> <3A3F276E.D84D9839@piuha.net> Subject: Re: IPv6 Neighbour Solicitation messages and IPsec Date: Mon, 8 Jan 2001 00:18:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen writes: >I'm not an IPv6 expert, but it seems that the issue here is who emits the message, not just what ICMP >message is being emitted. >An IPsec implementation (gateway or host) has an ability to bypass control traffic that it emits, >irrespective of SPD contents. So, I would expect that ICMP messages used for neighbor solicitation, >advertisement, and autoconfig, etc. would fall into this category. True.Though I'm worried that we don't specify anywhere how to bypass and what, possibly leading to interoperability problems. >Today we provide port-level controls, for UDP and TCP traffic, so adding ICMP-specific controls >represents a significant change. We'll have to evaluate the requirement for this sort of change very > >carefully. Yes, I agree. ICMP-specific controls aren't the only option, by the way. We could also have IPsec implementations hard code the handling of certain messages. I've got a feeling that this is what implementors are doing. (True?) Please note also that it seems like we need to do *something*, i.e. the requested functionality isn't optional nice-to-have features. If we don't either specify the rules regarding some of these ICMPs and we don't give fine-grained control to the user, the chances are that implementation A isn't going to work with implementation B. For instance, in view of the the problems with Neighbour Advertisement messages, implementation A bypasses these messages alltogether (or at least for dynamic policies). Implementation B however chooses to bypass the messages when there is no SA yet, and to require the use of the SA when one has been negotiated. You can get A to talk to B, but if reachability detection kicks in (uses the NA messages too), packets stop flowing! >>Finally, I would propose that everywhere in the ICMPv6 specifications >>where it says "AH", tunnel mode ESP would suffice as well. > >This last suggestion is a topic for a different debate, and I would suggest >not including it in this discussion Yeah. You're right. Jari ---- http://www.arkko.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 8 18:28:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f092QB702254 for ipng-dist; Mon, 8 Jan 2001 18:26:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f092Pw602247 for ; Mon, 8 Jan 2001 18:25:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA23434 for ; Mon, 8 Jan 2001 18:25:58 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA20243 for ; Mon, 8 Jan 2001 18:25:57 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 8 Jan 2001 18:24:37 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Jan 2001 18:25:22 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Mon, 8 Jan 2001 18:25:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Denial of Service attacks and ICMPv6 Packet Too Big Date: Mon, 8 Jan 2001 18:25:20 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657420FCE3@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Denial of Service attacks and ICMPv6 Packet Too Big Thread-Index: AcBrYifOabJB8ULlQNOPyT3/vB+mQwOf4elA From: "Dave Thaler" To: "Jari Arkko" , Cc: , X-OriginalArrivalTime: 09 Jan 2001 02:25:21.0931 (UTC) FILETIME=[6A98CDB0:01C079E3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f092Px602248 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I just got back from 3 weeks of vacation so apologies for not replying to this earlier :) Jari Arkko writes: [...] > A multicast group X contains the receivers R1, R2, ... RN. > The victim node is V - not necessarily anything to do with > X. The attacker is A. All nodes are different. Now, attacker A > sends a multicast packet with source = V and destination = X. > As the receivers R1 to RN or routers close to them receive the > messages, they complain about the message and ALL respond using > ICMPv6 Packet Too Big or Parameter Problem, causing V to be > flooded with messages. [...] > I'm not sure if I've missed something that prevents an > attacker from doing this. But if they can do this, > it is very hard to prevent the consequences since (a) > there is amplification involved, (b) each ICMPv6 sender > sends just one packet so rate limitation won't help, and > (c) the victim's pipe may be full because of the messages > and therefore any policies the victim may have on throwing > out them won't help. > > What isn't clear to me though is for instance, which > nodes can send such multicast traffic like this. I > would assume at least those who are on the same network > with the real sender of the group, and at least when > the V is the same as the real sender. But how far beyond > this you can take the attack? All currently deployed (that I know of) multicast routing protocols employ RPF checks in some form. Roughly, this means that A has to be either on the same subnet as V (in which case all receivers will respond), or else somewhere on the multicast distribution tree used by V (in which case only those receivers down the subtree past that point will respond). If A is not on the distribution tree, then the attack generally won't work. There are a few exceptions, though, such as sending the Packet Too Big in a register message to the victim's RP in PIMSM. If V is not actually sourcing traffic to the group, and receivers are in V's domain, then a large volume could be continuously generated. (If V is sourcing traffic, then typically registers would fail, as the RP will be getting data natively and drop registers.) If the receivers are external to V's domain, then typically MSDP will only let the first Packet Too Big message reach the receivers. There may be ways to configure filters at the RPs to prevent these things, I don't know about current implementations. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 8 23:41:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f097e8V02360 for ipng-dist; Mon, 8 Jan 2001 23:40:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f097dx602353 for ; Mon, 8 Jan 2001 23:39:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA16944 for ; Mon, 8 Jan 2001 23:39:59 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27346 for ; Mon, 8 Jan 2001 23:39:59 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f097ZNK29753; Tue, 9 Jan 2001 08:35:23 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569CF.0029AC6C; Tue, 9 Jan 2001 08:35:11 +0100 Message-ID: <3A5ABF2F.B179FE0B@alcatel.be> Date: Tue, 09 Jan 2001 08:35:11 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: Jari Arkko , itojun@iijlab.net, jarkko@piuha.net, ipng@sunroof.eng.sun.com Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big References: <5B90AD65A9E8934987DB0C8C0762657420FCE3@DF-BOWWOW.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Thaler wrote: > > (I just got back from 3 weeks of vacation so apologies > for not replying to this earlier :) > > Jari Arkko writes: > [...] > > A multicast group X contains the receivers R1, R2, ... RN. > > The victim node is V - not necessarily anything to do with > > X. The attacker is A. All nodes are different. Now, attacker A > > sends a multicast packet with source = V and destination = X. > > As the receivers R1 to RN or routers close to them receive the > > messages, they complain about the message and ALL respond using > > ICMPv6 Packet Too Big or Parameter Problem, causing V to be > > flooded with messages. > [...] > > I'm not sure if I've missed something that prevents an > > attacker from doing this. But if they can do this, > > it is very hard to prevent the consequences since (a) > > there is amplification involved, (b) each ICMPv6 sender > > sends just one packet so rate limitation won't help, and > > (c) the victim's pipe may be full because of the messages > > and therefore any policies the victim may have on throwing > > out them won't help. > > > > What isn't clear to me though is for instance, which > > nodes can send such multicast traffic like this. I > > would assume at least those who are on the same network > > with the real sender of the group, and at least when > > the V is the same as the real sender. But how far beyond > > this you can take the attack? > > All currently deployed (that I know of) multicast routing protocols > employ RPF checks in some form. Roughly, this means that A > has to be either on the same subnet as V (in which case all > receivers will respond), or else somewhere on the multicast > distribution tree used by V (in which case only those > receivers down the subtree past that point will respond). > If A is not on the distribution tree, then the attack > generally won't work. There are a few exceptions, though, > such as sending the Packet Too Big in a register message > to the victim's RP in PIMSM. If V is not actually sourcing traffic > to the group, and receivers are in V's domain, then a large > volume could be continuously generated. (If V is sourcing Unless the RP immediately switches to the source tree when it receives the first 'Packet Too Big' packet (which is a typical configuration). In this case there will only be a burst towards V. Correct? dirk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 9 12:20:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f09KIwS02842 for ipng-dist; Tue, 9 Jan 2001 12:18:58 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f09KIm602835 for ; Tue, 9 Jan 2001 12:18:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA22557 for ; Tue, 9 Jan 2001 12:18:37 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27025 for ; Tue, 9 Jan 2001 12:18:36 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 9 Jan 2001 12:15:13 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Jan 2001 12:15:04 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.100]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Tue, 9 Jan 2001 12:15:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message Subject: RE: Denial of Service attacks and ICMPv6 Packet Too Big MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 9 Jan 2001 12:15:48 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657401D42F2B@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Denial of Service attacks and ICMPv6 Packet Too Big Thread-Index: AcB6HnZXFRg7yR3TRTCyPjQuqi4y9QAWkFVg From: "Dave Thaler" To: "Dirk Ooms" Cc: "Jari Arkko" , , , X-OriginalArrivalTime: 09 Jan 2001 20:15:49.0248 (UTC) FILETIME=[F50FA000:01C07A78] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f09KIo602836 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dirk Ooms writes: [...] > > All currently deployed (that I know of) multicast routing protocols > > employ RPF checks in some form. Roughly, this means that A > > has to be either on the same subnet as V (in which case all > > receivers will respond), or else somewhere on the multicast > > distribution tree used by V (in which case only those > > receivers down the subtree past that point will respond). > > If A is not on the distribution tree, then the attack > > generally won't work. There are a few exceptions, though, > > such as sending the Packet Too Big in a register message > > to the victim's RP in PIMSM. If V is not actually sourcing traffic > > to the group, and receivers are in V's domain, then a large > > volume could be continuously generated. (If V is sourcing > > Unless the RP immediately switches to the source tree when it receives > the first 'Packet Too Big' packet (which is a typical > configuration). In > this case there will only be a burst towards V. Correct? No. If V is not sourcing traffic, the SPT bit will never get set on the RP's state and it will continue accepting registers even though an (S,G) branch has been created. As a result, every register will continue to be forwarded down the (*,G) tree to all the receivers. -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 Jan 10 00:05:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0A83qV03211 for ipng-dist; Wed, 10 Jan 2001 00:03:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0A83g603204 for ; Wed, 10 Jan 2001 00:03:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA17398 for ; Wed, 10 Jan 2001 00:03:42 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11342 for ; Wed, 10 Jan 2001 00:03:41 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id f0A7x9c06919; Wed, 10 Jan 2001 08:59:09 +0100 (MET) Received: from alcatel.be ([138.203.65.20]) by Bemail06.net.alcatel.be (Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) with SMTP id C12569D0.002BDA03; Wed, 10 Jan 2001 08:58:58 +0100 Message-ID: <3A5C1642.7615EF23@alcatel.be> Date: Wed, 10 Jan 2001 08:58:58 +0100 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: Jari Arkko , itojun@iijlab.net, jarkko@piuha.net, ipng@sunroof.eng.sun.com Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big References: <5B90AD65A9E8934987DB0C8C0762657401D42F2B@DF-BOWWOW.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, you are right (of course :)). Dave Thaler wrote: > > Dirk Ooms writes: > [...] > > > All currently deployed (that I know of) multicast routing protocols > > > employ RPF checks in some form. Roughly, this means that A > > > has to be either on the same subnet as V (in which case all > > > receivers will respond), or else somewhere on the multicast > > > distribution tree used by V (in which case only those > > > receivers down the subtree past that point will respond). > > > If A is not on the distribution tree, then the attack > > > generally won't work. There are a few exceptions, though, > > > such as sending the Packet Too Big in a register message > > > to the victim's RP in PIMSM. If V is not actually sourcing traffic > > > to the group, and receivers are in V's domain, then a large > > > volume could be continuously generated. (If V is sourcing > > > > Unless the RP immediately switches to the source tree when it receives > > the first 'Packet Too Big' packet (which is a typical > > configuration). In > > this case there will only be a burst towards V. Correct? > > No. If V is not sourcing traffic, the SPT bit will never get > set on the RP's state and it will continue accepting registers > even though an (S,G) branch has been created. > As a result, every register will continue to be forwarded > down the (*,G) tree to all the receivers. > > -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 Jan 10 19:21:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0B3J8R04573 for ipng-dist; Wed, 10 Jan 2001 19:19:08 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0B3It604566 for ; Wed, 10 Jan 2001 19:18:55 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f0B3Irv973732; Wed, 10 Jan 2001 19:18:53 -0800 (PST) Date: Wed, 10 Jan 2001 19:18:13 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: destination option update To: Jun-ichiro itojun Hagino Cc: Francis Dupont , Erik Nordmark , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Back from vacation and travel ... > one question - maybe i have lost some context. > we are talking about socket API. is it really necessary > for user applications to be able to transmit arbitrary AH/ESP/fragment > header? I don't see a need to allow this on the transmit side. But the discussion started off with the need on the receive side to identify what headers was covered by IPsec i.e. somehow be able to indentify what was before and after an ESP header. I don't know if any application cares whether received destination options appear before or after a fragmentation header. Is there such a need? Erik > even for raw IP socket, i think it reasonable to forbid users > from attaching arbitrary AH/ESP/fragment header (i.e. to say that > they are "kernel" thingie). > > 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 Jan 10 20:20:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0B4JBs04604 for ipng-dist; Wed, 10 Jan 2001 20:19:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0B4J0604597 for ; Wed, 10 Jan 2001 20:19:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA13257 for ; Wed, 10 Jan 2001 20:18:59 -0800 (PST) Received: from starfruit.itojun.org (dhcp108.iijlab.net [202.232.15.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA25138 for ; Wed, 10 Jan 2001 21:18:57 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 98EE17E68; Thu, 11 Jan 2001 13:18:50 +0900 (JST) To: Erik Nordmark Cc: Francis Dupont , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 10 Jan 2001 19:18:13 PST. 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: destination option update From: Jun-ichiro itojun Hagino Date: Thu, 11 Jan 2001 13:18:50 +0900 Message-Id: <20010111041850.98EE17E68@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> one question - maybe i have lost some context. >> we are talking about socket API. is it really necessary >> for user applications to be able to transmit arbitrary AH/ESP/fragment >> header? >I don't see a need to allow this on the transmit side. But the discussion >started off with the need on the receive side to identify what headers was >covered by IPsec i.e. somehow be able to indentify what was before and >after an ESP header. I don't know if any application cares whether received >destination options appear before or after a fragmentation header. >Is there such a need? i believe there's such a need, but i'm not sure about granurality. this is not really about 2292, but about ipsec API in general. i came up with comple of scenarios: - i have a udp-based server running. i'd respond to incoming packet if it comes with AH/ESP, and i'd reject it if it is not IPsec'ed. (what granurality? do we need to if extension headers were protected?) - i am implementing some of mobile-ip6 portion in the userland. i would like to know which intermediate header was protected and which was not, by ESP. this is in 2292 domain. (AH protects the whole packet so there should be problem) - i have a telnetd running on my server. i'd like to allow plaintext password if the tcp session is IPsec-encrypted, and i'd like to require s/key otherwise. how can we do this? with draft-mcdonald-simple-ipsec-api-01, we'd need to listen to two separate ports, for separate protection policy. (again, for tcp, "which packet was protected and which was not" complicates story) are there any ipsec socket API (not key management API) proposal other than draft-mcdonald-simple-ipsec-api-01? if there's any standard/ whatever i would like to know that. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 10 23:18:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0B7HGp04687 for ipng-dist; Wed, 10 Jan 2001 23:17:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0B7H7604679 for ; Wed, 10 Jan 2001 23:17:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA07253 for ; Wed, 10 Jan 2001 23:17:08 -0800 (PST) Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA13030 for ; Thu, 11 Jan 2001 00:17:06 -0700 (MST) Received: from mobinet (mobinet.u-strasbg.fr [130.79.90.159]) by clarinet.u-strasbg.fr (8.9.3/8.9.3) with SMTP id IAA30400 for ; Thu, 11 Jan 2001 08:17:05 +0100 From: "Thomas Noel" To: Subject: CFP : RSRCP Journal - Mobility and Internet Date: Thu, 11 Jan 2001 08:11:08 +0100 Message-ID: <000001c07b9d$ab6615d0$9f5a4f82@ustrasbg.fr> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Apologies if you receive multiple copies.] CALL for PAPERS SPECIAL ISSUE MOBILITY AND INTERNET of RSRCP Journal http://www-r2.u-strasbg.fr/rsrcp/mintcfp.html The RSRCP journal, which is now specialized on thematic issues on Network and Distributed System is pleased to announce a special issue on "Mobility and Internet". This special issue is sponsored by IEEE Distributed Systems and the French IEEE Computer Chapter. Wireless mobile access to the Internet will add new dimensions to the way we access information and communicate. Currently, several network protocols are being studied to maintain communication between a mobile host and its correspondents during the mobile host's movements. This special issue is devoted to the presentation of recent research on network protocols and services for mobile hosts and wireless communication on the Internet. We solicit high quality papers reporting original work in theoretical or experimental research. Topics of interest include, but are not limited to the following : - Ad hoc networks - Cellular IP networks - Distributed system aspects of mobile systems - Handoffs in IP networks - Header compression in wireless networks - Hierarchical mobility - IP-based third generation mobile and wireless networks - Micro-mobility architectures and protocols - Multicast communications for mobile hosts - Mobility and IPv6 - Mobile management - Network protocols for mobile nodes - QoS in a wireless/mobile environment - Security and authentication - Service location in wireless environnement - Wireless LAN Important dates: 1. Submission deadline: June 30, 2001; 2. Notifications to the authors: September, 30, 2001; 3. Publication : December 2001; Submissions: Contributions should follow the instructions and the format of the journal edited by Hermes. (see http://www-r2.u-strasbg.fr/rsrcp/authorsguidelines.pdf) Contributions should be original ones and should not be longer than 25 pages. Submissions should be forwarded to the Guest Editors (rsrcp@clarinet.u-strasbg.fr - PS or PDF format, compressed). Guest Editors : Thomas Noel Andras Valko Universite Louis Pasteur - LSIIT Ericsson Research Pole API - Boulevard S閎astien Brant Traffic Laboratory F- 67400 - Illkirch H-1037 Budapest, Laborc u 1. France Hungary Editorial Board : Scott Corson Francis Dupont Flarion Technologies ENST - Bretagne USA France Philip Eardley Andras Farago British Telecom University of Texas - Dallas UK USA Phil Neumiller Thomas Noel 3Com LSIIT USA France Hesham Soliman Tapio Suihko Ericsson VTT Technical Research Center Australia Finland C.K. Toh Michel Trehel Georgia Institute of Technology Universite de Franche-Comte USA France Andras Valko Ericsson Hungary -- NOEL Thomas - ULP/LSIIT Thomas.Noel@dpt-info.u-strasbg.fr http://www-r2.u-strasbg.fr/~noel tel: (33) 03 88 65 55 03 - fax: 03.88.65 55 01 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 11 03:29:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0BBRiv04807 for ipng-dist; Thu, 11 Jan 2001 03:27:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0BBRZ604800 for ; Thu, 11 Jan 2001 03:27:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA17296; Thu, 11 Jan 2001 03:26:39 -0800 (PST) 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 EAA14920; Thu, 11 Jan 2001 04:26:38 -0700 (MST) 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 f0BBQW428790; Thu, 11 Jan 2001 12:26:32 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA13516; Thu, 11 Jan 2001 12:26:31 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f0BBQUO78671; Thu, 11 Jan 2001 12:26:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200101111126.f0BBQUO78671@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: destination option update In-reply-to: Your message of Wed, 10 Jan 2001 19:18:13 PST. Date: Thu, 11 Jan 2001 12:26:30 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I don't know if any application cares whether received destination options appear before or after a fragmentation header. Is there such a need? => I can see both, symmetry (stronger than one can believe at the first view because of the send what is received coding style) and security issues with ESP (after ESP is protected, before ESP is *not*). I think we should have this. Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 11 04:48:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0BCkpL04882 for ipng-dist; Thu, 11 Jan 2001 04:46:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0BCkg604875 for ; Thu, 11 Jan 2001 04:46:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA04154 for ; Thu, 11 Jan 2001 04:46:36 -0800 (PST) Received: from web3406.mail.yahoo.com (web3406.mail.yahoo.com [204.71.203.60]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA24292 for ; Thu, 11 Jan 2001 04:46:35 -0800 (PST) Message-ID: <20010111124635.25921.qmail@web3406.mail.yahoo.com> Received: from [202.173.146.173] by web3406.mail.yahoo.com; Thu, 11 Jan 2001 04:46:35 PST Date: Thu, 11 Jan 2001 04:46:35 -0800 (PST) From: nilesh modi Subject: very new to list To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello to all, I m a new joiner of this list. Hope i will have good time here. I wish to make a project of ipv4 to ipv6 converter, for that please guide me for some resources. Hoping for favourable reply, thanx in advance, nilesh. __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 11 05:10:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0BD94J04913 for ipng-dist; Thu, 11 Jan 2001 05:09:04 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0BD8t604906 for ; Thu, 11 Jan 2001 05:08:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA25135 for ; Thu, 11 Jan 2001 05:08:53 -0800 (PST) Received: from web3402.mail.yahoo.com (web3402.mail.yahoo.com [204.71.203.56]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA25730 for ; Thu, 11 Jan 2001 05:08:53 -0800 (PST) Message-ID: <20010111130852.8560.qmail@web3402.mail.yahoo.com> Received: from [202.173.146.173] by web3402.mail.yahoo.com; Thu, 11 Jan 2001 05:08:52 PST Date: Thu, 11 Jan 2001 05:08:52 -0800 (PST) From: nilesh modi Subject: is it feasible? To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hello sir, First of all i want to know that is ipv4 to ipv6 translator possible ? I and my partners will work hard, but as i m a student , i have to check its feasibility that is it possible to implement such converter within 6 months? Nilesh. __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 11 10:39:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0BIbRe05251 for ipng-dist; Thu, 11 Jan 2001 10:37:27 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0BIbN605244 for ; Thu, 11 Jan 2001 10:37:23 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0BIZYE28425 for ipng@sunroof.eng.sun.com; Thu, 11 Jan 2001 10:35:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0BDVV604942 for ; Thu, 11 Jan 2001 05:31:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA15025 for ; Thu, 11 Jan 2001 05:31:31 -0800 (PST) Received: from em.njupt.edu.cn (dns.njupt.edu.cn [202.119.230.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25963 for ; Thu, 11 Jan 2001 06:31:29 -0700 (MST) Received: from bigbug ([10.10.1.99]) by em.njupt.edu.cn (Post.Office MTA v3.5.3 release 223 ID# 0-60998U8000L20S100V35) with SMTP id cn; Thu, 11 Jan 2001 21:33:11 +0800 Message-ID: <00dd01c07bd2$bb181480$63010a0a@comp.njupt.edu.cn> From: "LingXiaoFeng" To: "nilesh modi" , References: <20010111130852.8560.qmail@web3402.mail.yahoo.com> Subject: Re: is it feasible? Date: Thu, 11 Jan 2001 21:30:57 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Disposition-Notification-To: "LingXiaoFeng" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f0BDVV604943 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't know what you mean exactly. I Have implemented an gateway on WinNT that can translate IPv6 to IPv4, through it, the V6 machine can communicator with V4 machine include TCP,UDP and ICMP Echo. ----- Original Message ----- Time: 2001?1?11? 21:08 Title: is it feasible? hello sir, First of all i want to know that is ipv4 to ipv6 translator possible ? I and my partners will work hard, but as i m a student , i have to check its feasibility that is it possible to implement such converter within 6 months? Nilesh. __________________________________________________ Do You Yahoo!? Yahoo! Photos - Share your holiday photos online! http://photos.yahoo.com/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ________________________________________________ e龙超级88兆！免费电子信箱 http://mail.elong.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 11 22:46:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0C6gts05715 for ipng-dist; Thu, 11 Jan 2001 22:42:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0C6gi605708 for ; Thu, 11 Jan 2001 22:42:44 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f0C6ger307518; Thu, 11 Jan 2001 22:42:40 -0800 (PST) Date: Thu, 11 Jan 2001 22:41:56 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Denial of Service attacks and ICMPv6 Packet Too Big To: Jari Arkko Cc: itojun@iijlab.net, jarkko@piuha.net, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3A421FA5.6701A92D@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Catching up on email ... > A multicast group X contains the receivers R1, R2, ... RN. > The victim node is V - not necessarily anything to do with > X. The attacker is A. All nodes are different. Now, attacker A > sends a multicast packet with source = V and destination = X. > As the receivers R1 to RN or routers close to them receive the > messages, they complain about the message and ALL respond using > ICMPv6 Packet Too Big or Parameter Problem, causing V to be > flooded with messages. IP multicast routing is in many cases based on reverse path forwarding. This implies that the forwarding is determined by the source address of the packet. If a packet is received by a router on an interface and that interface is not an incoming interface in the reverse path tree for the IP source address in the packet, the packet will be dropped. This means that, when RPF based multicast routing is used, a multicast packet with an invalid source must in inject topologically close to the real location of that source address i.e. A must be topologically close to V, to see signficant forwarding of the multicast packet. Of course, with non-RPF based schemes we are not so lucky. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 16 14:17:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0GMGVv08332 for ipng-dist; Tue, 16 Jan 2001 14:16:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0GMGM608325 for ; Tue, 16 Jan 2001 14:16:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA25705; Tue, 16 Jan 2001 14:16:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05399; Tue, 16 Jan 2001 14:16:22 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA15581; Tue, 16 Jan 2001 14:16:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f0GMGGl28137; Tue, 16 Jan 2001 14:16:16 -0800 X-Virus-Scanned: Tue, 16 Jan 2001 14:16:16 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdhIqywb; Tue, 16 Jan 2001 14:16:10 PST Message-Id: <4.3.2.7.2.20010116141010.027238a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jan 2001 14:13:04 -0800 To: Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com From: Bob Hinden Subject: Request to Advance "Transmission of IPv6 Packets over IEEE 1394 Networks" Cc: scoya@ietf.org, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Proposed Standard: Title : Transmission of IPv6 Packets over IEEE 1394 Networks Author(s) : K. Fujisawa, A. Onoe Filename : draft-ietf-ipngwg-1394-00.txt Pages : 7 Date : 14-Nov-00 A working group last call for this document was completed on December 12, 2000. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 16 14:24:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0GMNVK08370 for ipng-dist; Tue, 16 Jan 2001 14:23:31 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0GMNM608363 for ; Tue, 16 Jan 2001 14:23:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA21663; Tue, 16 Jan 2001 14:23:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23633; Tue, 16 Jan 2001 15:23:21 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA16388; Tue, 16 Jan 2001 14:23:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f0GMNIq10411; Tue, 16 Jan 2001 14:23:18 -0800 X-Virus-Scanned: Tue, 16 Jan 2001 14:23:18 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdYL9jM8; Tue, 16 Jan 2001 14:21:58 PST Message-Id: <4.3.2.7.2.20010116141737.027238a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jan 2001 14:19:00 -0800 To: Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com From: Bob Hinden Subject: Request to Advance "IPv6 multihoming support at site exit routers" Cc: scoya@ietf.org, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : IPv6 multihoming support at site exit routers Author(s) : J. Hagino Filename : draft-ietf-ipngwg-ipv6-2260-00.txt Pages : 9 Date : 26-Jun-00 A working group last call for this document was completed on August 17, 2000. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 16 14:34:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0GMWo808422 for ipng-dist; Tue, 16 Jan 2001 14:32:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0GMWe608415 for ; Tue, 16 Jan 2001 14:32:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA04728 for ; Tue, 16 Jan 2001 14:32:40 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03214 for ; Tue, 16 Jan 2001 14:32:37 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA17511; Tue, 16 Jan 2001 14:32:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f0GMWYP00340; Tue, 16 Jan 2001 14:32:34 -0800 X-Virus-Scanned: Tue, 16 Jan 2001 14:32:34 -0800 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdSc5K3V; Tue, 16 Jan 2001 14:32:27 PST Message-Id: <4.3.2.7.2.20010116142137.02708ec0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Jan 2001 14:29:19 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "A flexible method for an IPv6 addressing plan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as an Informational RFC: Title : A flexible method for an IPv6 addressing plan Author(s) : M. Blanchet Filename : draft-ietf-ipngwg-ipaddressassign-01.txt Pages : 13 Date : 30-Nov-00 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 January 30, 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 Wed Jan 17 01:34:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0H9WcD08897 for ipng-dist; Wed, 17 Jan 2001 01:32:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0H9WS608890 for ; Wed, 17 Jan 2001 01:32:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA02002 for ; Wed, 17 Jan 2001 01:32:20 -0800 (PST) Received: from smail2.dmz1.icn.siemens.it ([194.185.160.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA02695 for ; Wed, 17 Jan 2001 01:32:18 -0800 (PST) Received: FROM imail.icn.siemens.it BY smail2.dmz1.icn.siemens.it ; Wed Jan 17 10:32:25 2001 +0100 Received: from ilt9h01.settimo.italtel.it (ilt9h01.settimo.italtel.it [138.132.3.41]) by imail.icn.siemens.it (8.9.3/8.9.3) with SMTP id KAA27712 for ; Wed, 17 Jan 2001 10:29:37 +0100 (MET) Received: from iltcw051.settimo.italtel.it by ilt9h01.settimo.italtel.it with SMTP (1.38.193.5/16.2) id AA07911; Wed, 17 Jan 2001 10:13:06 +0100 Message-Id: <3A657568.C026A588@icn.siemens.it> Date: Wed, 17 Jan 2001 10:35:20 +0000 From: Emanuel Monticelli X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: ipv4 over ipv6? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all Is there any stack that can incapsulate ipv4 in ipv6 packet, making ipv4 connection over an ipv6 network ? Thanks Emanuel Monticelli -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 17 01:52:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0H9oqW08936 for ipng-dist; Wed, 17 Jan 2001 01:50:52 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0H9og608929 for ; Wed, 17 Jan 2001 01:50:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA08931 for ; Wed, 17 Jan 2001 01:50:42 -0800 (PST) Received: from lost-frequencies.de ([212.169.150.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA17224 for ; Wed, 17 Jan 2001 01:50:40 -0800 (PST) Received: from pop.lost-frequencies.de (account p4864718-drop) by lost-frequencies.de (CommuniGate Pro RPOP 3.3.2) with RPOP id 320516; Wed, 17 Jan 2001 10:52:27 +0100 X-Delivered-To: X-Envelope-To: Received: from mx1.zid.nextra.de (ns2.nextra.de [62.204.1.34]) by zid-sec1.nextra.de (8.9.3/8.9.3) with ESMTP id KAA89237 for ; Wed, 17 Jan 2001 10:44:17 +0100 (CET) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mx1.zid.nextra.de (8.9.3/8.9.3) with ESMTP id KAA27475 for ; Wed, 17 Jan 2001 10:44:15 +0100 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04090; Wed, 17 Jan 2001 01:35:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA07919; Wed, 17 Jan 2001 01:35:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0H9WcD08897 for ipng-dist; Wed, 17 Jan 2001 01:32:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0H9WS608890 for ; Wed, 17 Jan 2001 01:32:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA02002 for ; Wed, 17 Jan 2001 01:32:20 -0800 (PST) Received: from smail2.dmz1.icn.siemens.it ([194.185.160.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA02695 for ; Wed, 17 Jan 2001 01:32:18 -0800 (PST) Received: FROM imail.icn.siemens.it BY smail2.dmz1.icn.siemens.it ; Wed Jan 17 10:32:25 2001 +0100 Received: from ilt9h01.settimo.italtel.it (ilt9h01.settimo.italtel.it [138.132.3.41]) by imail.icn.siemens.it (8.9.3/8.9.3) with SMTP id KAA27712 for ; Wed, 17 Jan 2001 10:29:37 +0100 (MET) Received: from iltcw051.settimo.italtel.it by ilt9h01.settimo.italtel.it with SMTP (1.38.193.5/16.2) id AA07911; Wed, 17 Jan 2001 10:13:06 +0100 Message-Id: <3A657568.C026A588@icn.siemens.it> Date: Wed, 17 Jan 2001 10:35:20 +0000 From: Emanuel Monticelli X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: ipv4 over ipv6? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk *This message was transferred with a trial version of CommuniGate(tm) Pro* Hi all Is there any stack that can incapsulate ipv4 in ipv6 packet, making ipv4 connection over an ipv6 network ? Thanks Emanuel Monticelli -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jan 17 02:06:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HA5Iw09568 for ipng-dist; Wed, 17 Jan 2001 02:05:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HA57609561 for ; Wed, 17 Jan 2001 02:05:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA28094 for ; Wed, 17 Jan 2001 02:05:06 -0800 (PST) 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 CAA16832 for ; Wed, 17 Jan 2001 02:05:05 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA18567; Wed, 17 Jan 2001 11:05:02 +0100 (MET) Date: Wed, 17 Jan 2001 11:05:02 +0100 From: Ignatios Souvatzis To: Emanuel Monticelli Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv4 over ipv6? Message-ID: <20010117110502.A18376@theory.cs.uni-bonn.de> References: <3A657568.C026A588@icn.siemens.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A657568.C026A588@icn.siemens.it>; from Emanuel.Monticelli@icn.siemens.it on Wed, Jan 17, 2001 at 10:35:20AM +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 17, 2001 at 10:35:20AM +0000, Emanuel Monticelli wrote: > Is there any stack that can incapsulate ipv4 in ipv6 packet, making ipv4 > connection over an ipv6 network ? The KAME stack (e.g., as distributed with NetBSD 1.5 or later or FreeBSD) can do this... the "gif" virtual network device can encapsulate anythin in anything. Regards, -is --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOmVuSjCn4om+4LhpAQGNdQf+OxVtGhmvnEeN4NPskkw5DHwhYGlESUTh m/5/TeyUSakL1a7ZKEdCUzHXFrSW18ICvpJ88C6UNUPlUHI3rCsz4lijDTWOOQJ4 0e8TA2pHlYCJy4Wb9yo5kDgVVFqnMD4Puk+jK+t/mzLzkd7kQo9KEZUXRhWZhE++ GnYAvpQGFHzUWYo3PxKQXvw2a157fWTDA6nCn2yXrfsXa8lD3UgB1zSXFPCzeNFq EAQq3mdnOUyGid700ncOITMCevrcaMCLd/17cJxr8BNBr3E6pU2MiWU9B7ITv/tz /SONQJofzjGheWRI5ZRshqVlgDJKiKEdYKoCLrYmGx1cXI/Qiw2/mA== =nGO8 -----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 Jan 17 02:22:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HAKqT09618 for ipng-dist; Wed, 17 Jan 2001 02:20:52 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HAKg609611 for ; Wed, 17 Jan 2001 02:20:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA11374 for ; Wed, 17 Jan 2001 02:20:42 -0800 (PST) Received: from lost-frequencies.de ([212.169.150.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28772 for ; Wed, 17 Jan 2001 02:20:40 -0800 (PST) Received: from pop.lost-frequencies.de (account p4864718-drop) by lost-frequencies.de (CommuniGate Pro RPOP 3.3.2) with RPOP id 320523; Wed, 17 Jan 2001 11:22:27 +0100 X-Delivered-To: X-Envelope-To: Received: from mx1.zid.nextra.de (ns2.nextra.de [62.204.1.34]) by zid-sec1.nextra.de (8.9.3/8.9.3) with ESMTP id LAA92208 for ; Wed, 17 Jan 2001 11:14:58 +0100 (CET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mx1.zid.nextra.de (8.9.3/8.9.3) with ESMTP id LAA28890 for ; Wed, 17 Jan 2001 11:14:56 +0100 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08902; Wed, 17 Jan 2001 02:07:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA28269; Wed, 17 Jan 2001 02:07:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HA5Iw09568 for ipng-dist; Wed, 17 Jan 2001 02:05:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HA57609561 for ; Wed, 17 Jan 2001 02:05:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA28094 for ; Wed, 17 Jan 2001 02:05:06 -0800 (PST) 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 CAA16832 for ; Wed, 17 Jan 2001 02:05:05 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA18567; Wed, 17 Jan 2001 11:05:02 +0100 (MET) Date: Wed, 17 Jan 2001 11:05:02 +0100 From: Ignatios Souvatzis To: Emanuel Monticelli Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv4 over ipv6? Message-ID: <20010117110502.A18376@theory.cs.uni-bonn.de> References: <3A657568.C026A588@icn.siemens.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A657568.C026A588@icn.siemens.it>; from Emanuel.Monticelli@icn.siemens.it on Wed, Jan 17, 2001 at 10:35:20AM +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk *This message was transferred with a trial version of CommuniGate(tm) Pro* --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 17, 2001 at 10:35:20AM +0000, Emanuel Monticelli wrote: > Is there any stack that can incapsulate ipv4 in ipv6 packet, making ipv4 > connection over an ipv6 network ? The KAME stack (e.g., as distributed with NetBSD 1.5 or later or FreeBSD) can do this... the "gif" virtual network device can encapsulate anythin in anything. Regards, -is --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOmVuSjCn4om+4LhpAQGNdQf+OxVtGhmvnEeN4NPskkw5DHwhYGlESUTh m/5/TeyUSakL1a7ZKEdCUzHXFrSW18ICvpJ88C6UNUPlUHI3rCsz4lijDTWOOQJ4 0e8TA2pHlYCJy4Wb9yo5kDgVVFqnMD4Puk+jK+t/mzLzkd7kQo9KEZUXRhWZhE++ GnYAvpQGFHzUWYo3PxKQXvw2a157fWTDA6nCn2yXrfsXa8lD3UgB1zSXFPCzeNFq EAQq3mdnOUyGid700ncOITMCevrcaMCLd/17cJxr8BNBr3E6pU2MiWU9B7ITv/tz /SONQJofzjGheWRI5ZRshqVlgDJKiKEdYKoCLrYmGx1cXI/Qiw2/mA== =nGO8 -----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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 17 02:26:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HAPGI09636 for ipng-dist; Wed, 17 Jan 2001 02:25:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HAP3609629 for ; Wed, 17 Jan 2001 02:25:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA05793 for ; Wed, 17 Jan 2001 02:24:52 -0800 (PST) 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 DAA13534 for ; Wed, 17 Jan 2001 03:24:49 -0700 (MST) 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 f0HAOjk32144; Wed, 17 Jan 2001 11:24:45 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA27765; Wed, 17 Jan 2001 11:24:44 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f0HAOiO03272; Wed, 17 Jan 2001 11:24:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200101171024.f0HAOiO03272@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Emanuel Monticelli cc: ipng@sunroof.eng.sun.com Subject: Re: ipv4 over ipv6? In-reply-to: Your message of Wed, 17 Jan 2001 10:35:20 GMT. <3A657568.C026A588@icn.siemens.it> Date: Wed, 17 Jan 2001 11:24:44 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Is there any stack that can incapsulate ipv4 in ipv6 packet, making ipv4 connection over an ipv6 network ? => all BSD stacks have this (which is very simple). This is called gif (which is ipvX over ipvY for any X,Y) on KAME (derived) stacks. I use a dynamic version for DTSM (the code is available only on "INRIA" stack today as far as I know). For instance for a point-to-point tunnel: gifconfig gif0 inet6 ifconfig gif0 inet netmask 255.255.255.255 up route change default (from a real config, there are other examples in the KAME snap mailing list). 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 Jan 17 02:42:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HAeps09733 for ipng-dist; Wed, 17 Jan 2001 02:40:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HAef609726 for ; Wed, 17 Jan 2001 02:40:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA12709 for ; Wed, 17 Jan 2001 02:40:41 -0800 (PST) Received: from lost-frequencies.de ([212.169.150.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10375 for ; Wed, 17 Jan 2001 02:40:40 -0800 (PST) Received: from pop.lost-frequencies.de (account p4864718-drop) by lost-frequencies.de (CommuniGate Pro RPOP 3.3.2) with RPOP id 320517; Wed, 17 Jan 2001 11:42:27 +0100 X-Delivered-To: X-Envelope-To: Received: from mx1.zid.nextra.de (ns2.nextra.de [62.204.1.34]) by zid-sec1.nextra.de (8.9.3/8.9.3) with ESMTP id LAA93755 for ; Wed, 17 Jan 2001 11:31:27 +0100 (CET) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mx1.zid.nextra.de (8.9.3/8.9.3) with ESMTP id LAA29540 for ; Wed, 17 Jan 2001 11:31:21 +0100 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27110; Wed, 17 Jan 2001 02:27:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA11840; Wed, 17 Jan 2001 02:27:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HAPGI09636 for ipng-dist; Wed, 17 Jan 2001 02:25:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HAP3609629 for ; Wed, 17 Jan 2001 02:25:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA05793 for ; Wed, 17 Jan 2001 02:24:52 -0800 (PST) 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 DAA13534 for ; Wed, 17 Jan 2001 03:24:49 -0700 (MST) 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 f0HAOjk32144; Wed, 17 Jan 2001 11:24:45 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA27765; Wed, 17 Jan 2001 11:24:44 +0100 (MET) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f0HAOiO03272; Wed, 17 Jan 2001 11:24:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200101171024.f0HAOiO03272@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Emanuel Monticelli cc: ipng@sunroof.eng.sun.com Subject: Re: ipv4 over ipv6? In-reply-to: Your message of Wed, 17 Jan 2001 10:35:20 GMT. <3A657568.C026A588@icn.siemens.it> Date: Wed, 17 Jan 2001 11:24:44 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk *This message was transferred with a trial version of CommuniGate(tm) Pro* In your previous mail you wrote: Is there any stack that can incapsulate ipv4 in ipv6 packet, making ipv4 connection over an ipv6 network ? => all BSD stacks have this (which is very simple). This is called gif (which is ipvX over ipvY for any X,Y) on KAME (derived) stacks. I use a dynamic version for DTSM (the code is available only on "INRIA" stack today as far as I know). For instance for a point-to-point tunnel: gifconfig gif0 inet6 ifconfig gif0 inet netmask 255.255.255.255 up route change default (from a real config, there are other examples in the KAME snap mailing list). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 17 03:42:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HBfIR10658 for ipng-dist; Wed, 17 Jan 2001 03:41:18 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HBer610651 for ; Wed, 17 Jan 2001 03:40:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA10881 for ; Wed, 17 Jan 2001 03:40:46 -0800 (PST) Received: from lost-frequencies.de ([212.169.150.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26949 for ; Wed, 17 Jan 2001 03:40:41 -0800 (PST) Received: from pop.lost-frequencies.de (account p4864718-drop) by lost-frequencies.de (CommuniGate Pro RPOP 3.3.2) with RPOP id 320528; Wed, 17 Jan 2001 12:42:29 +0100 Received: from mx0.zid.nextra.de (ns1.nextra.de [212.255.127.225]) by zid-sec1.nextra.de (8.9.3/8.9.3) with ESMTP id MAA03326 for ; Wed, 17 Jan 2001 12:31:46 +0100 (CET) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mx0.zid.nextra.de (8.9.3/8.9.3) with ESMTP id MAA11952 for ; Wed, 17 Jan 2001 12:31:41 +0100 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20030; Wed, 17 Jan 2001 03:24:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA25745; Wed, 17 Jan 2001 03:24:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HAKqT09618 for ipng-dist; Wed, 17 Jan 2001 02:20:52 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HAKg609611 for ; Wed, 17 Jan 2001 02:20:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA11374 for ; Wed, 17 Jan 2001 02:20:42 -0800 (PST) Received: from lost-frequencies.de ([212.169.150.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28772 for ; Wed, 17 Jan 2001 02:20:40 -0800 (PST) Received: from pop.lost-frequencies.de (account p4864718-drop) by lost-frequencies.de (CommuniGate Pro RPOP 3.3.2) with RPOP id 320523; Wed, 17 Jan 2001 11:22:27 +0100 X-Delivered-To: X-Envelope-To: Received: from mx1.zid.nextra.de (ns2.nextra.de [62.204.1.34]) by zid-sec1.nextra.de (8.9.3/8.9.3) with ESMTP id LAA92208 for ; Wed, 17 Jan 2001 11:14:58 +0100 (CET) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mx1.zid.nextra.de (8.9.3/8.9.3) with ESMTP id LAA28890 for ; Wed, 17 Jan 2001 11:14:56 +0100 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08902; Wed, 17 Jan 2001 02:07:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA28269; Wed, 17 Jan 2001 02:07:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0HA5Iw09568 for ipng-dist; Wed, 17 Jan 2001 02:05:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0HA57609561 for ; Wed, 17 Jan 2001 02:05:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA28094 for ; Wed, 17 Jan 2001 02:05:06 -0800 (PST) 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 CAA16832 for ; Wed, 17 Jan 2001 02:05:05 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA18567; Wed, 17 Jan 2001 11:05:02 +0100 (MET) Date: Wed, 17 Jan 2001 11:05:02 +0100 From: Ignatios Souvatzis To: Emanuel Monticelli Cc: ipng@sunroof.eng.sun.com Subject: Re: ipv4 over ipv6? Message-ID: <20010117110502.A18376@theory.cs.uni-bonn.de> References: <3A657568.C026A588@icn.siemens.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A657568.C026A588@icn.siemens.it>; from Emanuel.Monticelli@icn.siemens.it on Wed, Jan 17, 2001 at 10:35:20AM +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk *This message was transferred with a trial version of CommuniGate(tm) Pro* *This message was transferred with a trial version of CommuniGate(tm) Pro* --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jan 17, 2001 at 10:35:20AM +0000, Emanuel Monticelli wrote: > Is there any stack that can incapsulate ipv4 in ipv6 packet, making ipv4 > connection over an ipv6 network ? The KAME stack (e.g., as distributed with NetBSD 1.5 or later or FreeBSD) can do this... the "gif" virtual network device can encapsulate anythin in anything. Regards, -is --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOmVuSjCn4om+4LhpAQGNdQf+OxVtGhmvnEeN4NPskkw5DHwhYGlESUTh m/5/TeyUSakL1a7ZKEdCUzHXFrSW18ICvpJ88C6UNUPlUHI3rCsz4lijDTWOOQJ4 0e8TA2pHlYCJy4Wb9yo5kDgVVFqnMD4Puk+jK+t/mzLzkd7kQo9KEZUXRhWZhE++ GnYAvpQGFHzUWYo3PxKQXvw2a157fWTDA6nCn2yXrfsXa8lD3UgB1zSXFPCzeNFq EAQq3mdnOUyGid700ncOITMCevrcaMCLd/17cJxr8BNBr3E6pU2MiWU9B7ITv/tz /SONQJofzjGheWRI5ZRshqVlgDJKiKEdYKoCLrYmGx1cXI/Qiw2/mA== =nGO8 -----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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Jan 18 06:16:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0IEE9A20203 for ipng-dist; Thu, 18 Jan 2001 06:14:09 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0IEDv620196 for ; Thu, 18 Jan 2001 06:13:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA24592 for ; Thu, 18 Jan 2001 06:13:58 -0800 (PST) Received: from marduk.litech.org (gale.cs.cornell.edu [128.84.154.54]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05479 for ; Thu, 18 Jan 2001 06:13:58 -0800 (PST) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.20 #3) id 14JFp7-0006j7-00 for ipng@sunroof.eng.sun.com; Thu, 18 Jan 2001 09:13:57 -0500 Date: Thu, 18 Jan 2001 09:13:57 -0500 (EST) From: Nathan Lutchansky To: ipng mailing list Subject: Question about multihoming Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I posed this question a few days ago on the IPv6 users list and didn't get a reply, so perhaps this mailing list is a more appropriate place to ask. I'm still very interested in the answer, and even just a pointer to a website or reference book would be great. Thanks. -Nathan ---------- Forwarded message ---------- Date: Tue, 16 Jan 2001 11:15:17 -0500 (EST) From: Nathan Lutchansky To: "users@ipv6.org" Subject: Question about multihoming Hi, I've just started learning about IPv6 over the past month, and I have a question regarding multihoming that's not clearly answered in the RFCs. What is intended to be the standard method of assigning IP blocks to sites with service from multiple providers? Since portable address blocks will not be used in IPv6 in favor of provider-based assignments, there are apparently two approaches that can be used. One of the design goals for IPv6 is to allow easy renumbering of entire networks, as well as promoting the use of multiple prefixes concurrently to give each device one global IP address per prefix. This would suggest that a multihomed site would obtain a prefix from each provider. In fact, draft-ietf-ipngwg-default-addr-select-02 ("Default Address Selection for IPv6") states, "In addition, multi-homing situations will result in more addresses per node. For example, [...] a site may have multiple ISP attachments with a global prefix per ISP." However, draft-ietf-ipngwg-ipv6multihome-with-aggr-01 ("IPv6 Multihoming with Route Aggregation") suggests that a multihomed site would only use a prefix assigned by one ISP, then set up weaker routing entries in that ISP to route through the second ISP for load-balancing and redundancy. This would be similar to multihomed situations in IPv4 in which a site is not using portable addresses. I can see advantages and disadvantages to both techniques. Are there guidelines for determining which method to use? In what situations might each solution be necessary? I can even envision cases in which both methods could be used, i.e. a site uses two prefixes, and both ISPs can route both of them. Any comments would be appreciated. I'm working on an introductory transitional guide for IPv6, so I'd like to get this point right. Thanks. -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 Thu Jan 18 06:24:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0IENka20290 for ipng-dist; Thu, 18 Jan 2001 06:23:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0IENZ620283 for ; Thu, 18 Jan 2001 06:23:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA09467 for ; Thu, 18 Jan 2001 06:23:36 -0800 (PST) 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 GAA14775 for ; Thu, 18 Jan 2001 06:23:33 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA21140; Thu, 18 Jan 2001 23:23:20 +0900 (JST) To: Nathan Lutchansky cc: ipng mailing list In-reply-to: lutchann's message of Thu, 18 Jan 2001 09:13:57 EST. 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: Question about multihoming From: itojun@iijlab.net Date: Thu, 18 Jan 2001 23:23:20 +0900 Message-ID: <21138.979827800@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I posed this question a few days ago on the IPv6 users list and didn't get >a reply, so perhaps this mailing list is a more appropriate place to ask. >I'm still very interested in the answer, and even just a pointer to a >website or reference book would be great. Thanks. -Nathan I believe the best reference (to date) is http://playground.sun.com/ipv6/meetings.html, near "September/October 1999". We had two-day meeting just for multihoming in IPv6. you will find meeting minutes there. Also, there are couple of other internet drafts about the topic. 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 Jan 18 14:19:41 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0IMHR000299 for ipng-dist; Thu, 18 Jan 2001 14:17:27 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0IMGqN00267 for ; Thu, 18 Jan 2001 14:16:53 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.2+Sun/8.11.2) with SMTP id f0ILhD3101723; Thu, 18 Jan 2001 13:43:13 -0800 (PST) Date: Thu, 18 Jan 2001 13:42:17 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Question about multihoming To: Nathan Lutchansky Cc: ipng mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is more than one way to do multihoming starting with the techniques that are currently used for IPv4. I doubt we will ever get to a single way - different sites and different ISPs are likely to make different tradeoffs in different cases. There was a multihoming for IPv6 BoF in San Diego (multi6) and the IESG and IAB are looking at chartering a WG in this area. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 18 17:02:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0J10op01390 for ipng-dist; Thu, 18 Jan 2001 17:00:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0J10fN01383 for ; Thu, 18 Jan 2001 17:00:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA14482 for ; Thu, 18 Jan 2001 17:58:54 -0800 (PST) Received: from mailweb21.rediffmail.com ([203.199.83.145]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA25414 for ; Thu, 18 Jan 2001 17:58:53 -0800 (PST) Received: (qmail 1316 invoked by uid 510); 19 Jan 2001 01:54:04 -0000 Date: 19 Jan 2001 01:54:04 -0000 Message-ID: <20010119015404.1315.qmail@mailweb21.rediffmail.com> Received: from unknown (216.252.163.5) by rediffmail.com via HTTP; 19 Jan 2001 01:54:04 -0000 MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com." Subject: Feasibililty & Resources From: "Vishal Shah" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am a student doing engineering in Information Technology. I wanted to ask about making a ip4 to ipv6 converter and that is it possible to make it in 2 months. If it is please give me some information on how to start and the necessary resources that i will need and from where will they be available. Thanking you _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 18 19:03:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0J31f302361 for ipng-dist; Thu, 18 Jan 2001 19:01:41 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0J31XN02348 for ; Thu, 18 Jan 2001 19:01:34 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0J3vqV01341 for ipng@sunroof.eng.sun.com; Thu, 18 Jan 2001 19:57:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0I920618831 for ; Thu, 18 Jan 2001 01:02:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA29777 for ; Thu, 18 Jan 2001 01:02:00 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA19740 for ; Thu, 18 Jan 2001 02:01:59 -0700 (MST) Received: (qmail 1816 invoked by uid 1001); 18 Jan 2001 09:01:14 -0000 Date: 18 Jan 2001 09:01:14 -0000 Message-ID: <20010118090114.3487.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: A6 benefits? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Background: Why do NS and MX records use names, rather than addresses? RFC 1035 responds: If you copy a machine's address into an NS record, then you have to watch for changes in the address, and echo them. Indirection ``avoids the opportunity for inconsistency.'' I agree: indirection is good. But it didn't have to be handled by the DNS _client_. It could have been handled by the DNS _server_. The server could have periodically checked for changes in the address. This would have reduced latency, and improved reliability; see my next message. Now my question: Why has IPNG proposed A6, rather than AAAA? The answer seems to be the same: If you copy an ISP's address into part of an AAAA record, then you have to watch for changes in the address, and echo them. Indirection avoids the opportunity for inconsistency. I agree: indirection is good. But it doesn't have to be handled by the DNS _client_. It can be handled by the DNS _server_. The server can periodically check for changes in the address. This will reduce latency, and improve reliability. Is there some other claimed benefit of A6? ---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 Jan 18 19:03:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0J32Ax02386 for ipng-dist; Thu, 18 Jan 2001 19:02:10 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0J323N02379 for ; Thu, 18 Jan 2001 19:02:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0J3wM201371 for ipng@sunroof.eng.sun.com; Thu, 18 Jan 2001 19:58:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0I9ET618896 for ; Thu, 18 Jan 2001 01:14:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA18125 for ; Thu, 18 Jan 2001 01:14:29 -0800 (PST) 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 BAA24452 for ; Thu, 18 Jan 2001 01:14:28 -0800 (PST) Received: (qmail 10252 invoked by uid 1001); 18 Jan 2001 09:13:40 -0000 Date: 18 Jan 2001 09:13:40 -0000 Message-ID: <20010118091340.20931.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: A6 unreliability Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A recent bind-users report pointed out that BIND 8 can't find the IPv4 address of www.monty.de, even though the monty.de configuration is valid and the relevant servers are responding quickly. Here's one way to understand what's going wrong. I'd like to write a program that talks to DNS servers to find an address given an FQDN. How much memory do I need? How many servers do I need to contact? Well, I might need 64KB for an incoming DNS message, during the brief moment before I parse it. There's not much persistent data: * The name I'm looking up. * The name of the closest zone found so far. * The addresses of servers for that zone. 16 is more than enough. A response from a server will give me the answer, or refer me to a closer zone. The number of queries is at most 4 for www.blah.com. Simple, isn't it? Oops, that's not quite right. I might receive a CNAME. In that case I'll have to change the name and start over. This may happen several times. RFC 1034 says that the first CNAME ``should always'' get me to the canonical name, to avoid ``extra indirections,'' but it also says that I should follow chains if they do happen. Suddenly there's no limit to the number of queries. I have to set my own artificial limits to catch loops, and pray that they're not too small. But wait. The algorithm still doesn't work. The referral can include some glueless server names---names without addresses. I need to put the query on hold while I look up _those_ addresses. So here's what I actually have to store: * The name I'm looking up. * The name of the closest known zone. * The known addresses of servers for that zone. * The names of servers whose addresses I still have to look up. * The name of a server whose address I'm looking up. * The name of the closest known zone to _that_. * The known addresses of servers for that zone. * The names of servers whose addresses I still have to look up. It doesn't end there. If there are names in the last list, I'll have to put the second lookup on hold while I look for the addresses of _those_ names. And so on. The servers for monty.de, for example, are {ns,ns2}.norplex.net. The servers for norplex.net are vserver.neptun11.de and ns1.mars11.de. The servers for neptun11.de are {ns,ns2}.germany.net. The servers for mars11.de are ns1.neptun11.de and www.gilching.de. The servers for gilching.de are ecrc.de and name.muenchen.roses.de. What an amazing display of gluelessness! Suddenly there's no limit to the amount of space I need. I don't have a single small array of addresses; I have an unlimited-length array of small arrays of names and addresses. This isn't so simple any more. The problem with BIND is that it doesn't set aside this space. It uses the naive data structure. The only way it can put a query on hold, and look up a server name, is by dropping the query. It hopes that the server name lookup (``sysquery'') will find the server name before the original client tries again. My DNS cache can handle several levels of gluelessness, so it's able to find www.monty.de---but it has to send _fourteen_ queries. That takes quite a bit of time. Even worse, there are fourteen opportunities for delays. I encourage my users to avoid CNAMEs. I encourage them to avoid glueless domains. My software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default server names for fqdn. My users appreciate the speed and reliability. Now I'm looking at the IPv6 DNS proposals. Here's what I see: * ip6.int is similar to in-addr.arpa. The format is slightly less compact but allows many levels of delegation without CNAMEs. The final names are large but tolerable. Okay. It works. * AAAA requires a fairly clumsy transition; extending the A format would have been much cleaner. But AAAA in a future IPv6-only world will function the same way that A does today. Okay. It works. * DNAME exacerbates all the problems of CNAME. DNAMEs can be wrapped inside DNAMEs---and this is _encouraged_! We'll have people setting up huge CNAME/DNAME chains to match their corporate structures. * A6 exacerbates all the problems of glueless names in NS records. Suddenly there's another reason that a lookup will have to be put on hold---and, again, this is _encouraged_! DNAME and A6 are moving in the wrong direction: more gluelessness, slower lookups, more frequent delays, and more outages like monty.de. A6 creates reliability problems that are not present in AAAA. I object to DNAME and A6. I would object to them even if they were the only way to support easy renumbering. I cannot bring myself to inflict such a rickety system on future Internet users. ---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 Jan 18 20:08:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0J46T902806 for ipng-dist; Thu, 18 Jan 2001 20:06:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0J46KN02799 for ; Thu, 18 Jan 2001 20:06:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA03103 for ; Thu, 18 Jan 2001 21:04:33 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA03894 for ; Thu, 18 Jan 2001 22:04:33 -0700 (MST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0J54ZR22051 for ; Thu, 18 Jan 2001 23:04:35 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 18 Jan 2001 23:04:32 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 18 Jan 2001 23:04:32 -0600 Message-ID: To: djb@cr.yp.to, ipng@sunroof.eng.sun.com Subject: RE: A6 unreliability Date: Thu, 18 Jan 2001 22:55:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with this excellent assessment. I also don't think that any bind implementation will permit more than 3 levels of hiearchy with A6. The renumbering benefits are valid for A6 though. But we need to put a bounds on them in some fashion. I also think this should move to a server process model too not a client. Quite frankly to expect client implementations to do this well is just plain not going to fly. I think you bring up really good points. I also think we need to start deployment with AAAA records which will work and are running back in pre 8.X bind versions too. Until we can bound these A6 beasts and make sure they can perform with implementations AAAA is our only option. regards, /jim -----Original Message----- From: ext D. J. Bernstein [mailto:djb@cr.yp.to] Sent: Thursday, January 18, 2001 4:14 AM To: ipng@sunroof.eng.sun.com Subject: A6 unreliability A recent bind-users report pointed out that BIND 8 can't find the IPv4 address of www.monty.de, even though the monty.de configuration is valid and the relevant servers are responding quickly. Here's one way to understand what's going wrong. I'd like to write a program that talks to DNS servers to find an address given an FQDN. How much memory do I need? How many servers do I need to contact? Well, I might need 64KB for an incoming DNS message, during the brief moment before I parse it. There's not much persistent data: * The name I'm looking up. * The name of the closest zone found so far. * The addresses of servers for that zone. 16 is more than enough. A response from a server will give me the answer, or refer me to a closer zone. The number of queries is at most 4 for www.blah.com. Simple, isn't it? Oops, that's not quite right. I might receive a CNAME. In that case I'll have to change the name and start over. This may happen several times. RFC 1034 says that the first CNAME ``should always'' get me to the canonical name, to avoid ``extra indirections,'' but it also says that I should follow chains if they do happen. Suddenly there's no limit to the number of queries. I have to set my own artificial limits to catch loops, and pray that they're not too small. But wait. The algorithm still doesn't work. The referral can include some glueless server names---names without addresses. I need to put the query on hold while I look up _those_ addresses. So here's what I actually have to store: * The name I'm looking up. * The name of the closest known zone. * The known addresses of servers for that zone. * The names of servers whose addresses I still have to look up. * The name of a server whose address I'm looking up. * The name of the closest known zone to _that_. * The known addresses of servers for that zone. * The names of servers whose addresses I still have to look up. It doesn't end there. If there are names in the last list, I'll have to put the second lookup on hold while I look for the addresses of _those_ names. And so on. The servers for monty.de, for example, are {ns,ns2}.norplex.net. The servers for norplex.net are vserver.neptun11.de and ns1.mars11.de. The servers for neptun11.de are {ns,ns2}.germany.net. The servers for mars11.de are ns1.neptun11.de and www.gilching.de. The servers for gilching.de are ecrc.de and name.muenchen.roses.de. What an amazing display of gluelessness! Suddenly there's no limit to the amount of space I need. I don't have a single small array of addresses; I have an unlimited-length array of small arrays of names and addresses. This isn't so simple any more. The problem with BIND is that it doesn't set aside this space. It uses the naive data structure. The only way it can put a query on hold, and look up a server name, is by dropping the query. It hopes that the server name lookup (``sysquery'') will find the server name before the original client tries again. My DNS cache can handle several levels of gluelessness, so it's able to find www.monty.de---but it has to send _fourteen_ queries. That takes quite a bit of time. Even worse, there are fourteen opportunities for delays. I encourage my users to avoid CNAMEs. I encourage them to avoid glueless domains. My software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default server names for fqdn. My users appreciate the speed and reliability. Now I'm looking at the IPv6 DNS proposals. Here's what I see: * ip6.int is similar to in-addr.arpa. The format is slightly less compact but allows many levels of delegation without CNAMEs. The final names are large but tolerable. Okay. It works. * AAAA requires a fairly clumsy transition; extending the A format would have been much cleaner. But AAAA in a future IPv6-only world will function the same way that A does today. Okay. It works. * DNAME exacerbates all the problems of CNAME. DNAMEs can be wrapped inside DNAMEs---and this is _encouraged_! We'll have people setting up huge CNAME/DNAME chains to match their corporate structures. * A6 exacerbates all the problems of glueless names in NS records. Suddenly there's another reason that a lookup will have to be put on hold---and, again, this is _encouraged_! DNAME and A6 are moving in the wrong direction: more gluelessness, slower lookups, more frequent delays, and more outages like monty.de. A6 creates reliability problems that are not present in AAAA. I object to DNAME and A6. I would object to them even if they were the only way to support easy renumbering. I cannot bring myself to inflict such a rickety system on future Internet users. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 18 20:20:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0J4Imv02869 for ipng-dist; Thu, 18 Jan 2001 20:18:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0J4IdN02862 for ; Thu, 18 Jan 2001 20:18:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA06760 for ; Thu, 18 Jan 2001 21:16:52 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03074 for ; Thu, 18 Jan 2001 21:16:52 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0J5I3606536 for ; Thu, 18 Jan 2001 23:18:03 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 18 Jan 2001 23:16:51 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 18 Jan 2001 23:16:51 -0600 Message-ID: To: djb@cr.yp.to, ipng@sunroof.eng.sun.com Subject: RE: A6 unreliability Date: Thu, 18 Jan 2001 23:07:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Also go look at the source address selection stuff where we now have kernel and user space hacking dns abstract types back and forth. Another case of excessive engineering insanity and architecture without consideration for performance. Its good work as a spec but I have my doubts about what it will do to the performance of end system **production** running code. Or now we use IPv4 anycast in ngtrans which has never been deployed or even well tested in an evironment like the core interoperability events IPv6 has worked on. Or the most ridiculous thing of late is this privacy stuff of temporary and public addresses cause some adhoc group is paranoid about my MAC address. Then people take all this and make some kind of grand computer science cosmos wonder out of it and slow down everything else around IPv6 or put an interrupt in it for real implementors. Oh yeah go look at the scoping. Sooner or later the market will just barf on all this and force the vendors to just deliver basic IPv6 as IPv4 so we can solve the real problem lack of address space and NATism. But I truly hope your mail at least enlightens my colleagues to fix these A6 records. It will not work. Not feeling politically correct and want IPv6 to be deployed with warts if necessary, /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 Fri Jan 19 00:59:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0J8w6Z03802 for ipng-dist; Fri, 19 Jan 2001 00:58:06 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0J8vvN03795 for ; Fri, 19 Jan 2001 00:57:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA02089 for ; Fri, 19 Jan 2001 01:56:10 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19525 for ; Fri, 19 Jan 2001 01:56:08 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0J9tWl03535; Fri, 19 Jan 2001 16:55:33 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? In-reply-to: Your message of "18 Jan 2001 09:01:14 GMT." <20010118090114.3487.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 2001 16:55:32 +0700 Message-ID: <3533.979898132@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 18 Jan 2001 09:01:14 -0000 From: "D. J. Bernstein" Message-ID: <20010118090114.3487.qmail@cr.yp.to> | Is there some other claimed benefit of A6? It is certainly possible to set up some horrid indirections which cause lots of extra work with A6, as it is with NS or MX. However, in all of those cases, the indirection, if used intelligently (and I would admit that there isn't a lot of intelligence in a lot of DNS configuration) allows significant caching benefits - especially when addresses are likely to change, and changing addresses is supposed to be one of the things that IPv6 makes easy (which includes cheaper). That is, with $ORIGIN my.domain host1 604800 IN A6 64 pfx.my.domain. host2 604800 IN A6 64 pfx.my.domain. (etc) pfx 7200 IN A6 0 7200 IN A6 0 The mac addresses of host1 & host2 can stay cached for ages (if I ever change one, I can just retain the old address as an alias long enough for the old A6 record to expire), whereas the prefix needs to be refreshed quite frequently. With A6, any refresh of the prefix will refresh it for all the hosts that use it. The same applies to NS records, MX records, etc - those records typically have values that rarely need to change, but the associated addresses change often. But many hosts can share the same MX, and many domains the same NS, refreshing the A record for any of them in the cache refreshes for all of them. 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 Jan 19 04:32:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JCUvH04334 for ipng-dist; Fri, 19 Jan 2001 04:30:57 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JCUmN04327 for ; Fri, 19 Jan 2001 04:30:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA03523 for ; Fri, 19 Jan 2001 04:30:47 -0800 (PST) Received: from mailweb11.rediffmail.com ([203.199.83.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA22745 for ; Fri, 19 Jan 2001 04:30:32 -0800 (PST) Received: (qmail 27785 invoked by uid 510); 19 Jan 2001 12:21:50 -0000 Date: 19 Jan 2001 12:21:50 -0000 Message-ID: <20010119122150.27784.qmail@mailweb11.rediffmail.com> Received: from unknown (216.252.163.5) by rediffmail.com via HTTP; 19 Jan 2001 12:21:50 -0000 MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" From: "Vishal Shah" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am a student doing engineering in Information Technology. I wanted to ask about making a ip4 to ipv6 converter and that is it possible to make it in 2 months. If it is please give me some information on how to start and the necessary resources that i will need and from where will they be available. Thanking you _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jan 19 06:43:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JEfL604773 for ipng-dist; Fri, 19 Jan 2001 06:41:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JEf9N04764 for ; Fri, 19 Jan 2001 06:41:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA25878 for ; Fri, 19 Jan 2001 06:41:09 -0800 (PST) Received: from marduk.litech.org (gale.cs.cornell.edu [128.84.154.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25180 for ; Fri, 19 Jan 2001 07:41:08 -0700 (MST) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.20 #3) id 14Jcix-0004hl-00 for ipng@sunroof.eng.sun.com; Fri, 19 Jan 2001 09:41:07 -0500 Date: Fri, 19 Jan 2001 09:41:07 -0500 (EST) From: Nathan Lutchansky To: "ipng@sunroof.eng.sun.com" Subject: Re: A6 benefits? In-Reply-To: <3533.979898132@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 Fri, 19 Jan 2001, Robert Elz wrote: > Date: 18 Jan 2001 09:01:14 -0000 > From: "D. J. Bernstein" > Message-ID: <20010118090114.3487.qmail@cr.yp.to> > > | Is there some other claimed benefit of A6? > > It is certainly possible to set up some horrid indirections which > cause lots of extra work with A6, as it is with NS or MX. Yes, but with A6 records, the number of queries is bounded by the length of an IPv6 address, unless you use a lot of 0-length records. And DNAME records aren't that great of an issue; half the reverse-resolution in the current Internet is broken and nobody seems too concerned about fixing it. One other thing to keep in mind is that unlike an endless chain of glueless NS records, A6 records will, in general, chain to other records in the same zone and thus a significant part of the chain will be returned on each query. Thus, NS chains require much more work to resolve and should not be compared to A6 chains. It shouldn't take more than 2 or 3 queries to resolve a full A6 chain. In all likelyhood, prefixes for popular providers and services will remain cached, and resolving the names of virtual hosts and hosts on the same network will only take a single query, just as they do now with A records. -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 Fri Jan 19 06:55:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JEqbT04872 for ipng-dist; Fri, 19 Jan 2001 06:52:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JEqQN04864 for ; Fri, 19 Jan 2001 06:52:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA27984 for ; Fri, 19 Jan 2001 06:52:22 -0800 (PST) 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 GAA09059 for ; Fri, 19 Jan 2001 06:52:22 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA10612; Fri, 19 Jan 2001 23:52:12 +0900 (JST) To: Nathan Lutchansky cc: "ipng@sunroof.eng.sun.com" In-reply-to: lutchann's message of Fri, 19 Jan 2001 09:41:07 EST. 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: A6 benefits? From: itojun@iijlab.net Date: Fri, 19 Jan 2001 23:52:12 +0900 Message-ID: <10610.979915932@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >One other thing to keep in mind is that unlike an endless chain of >glueless NS records, A6 records will, in general, chain to other records >in the same zone and thus a significant part of the chain will be returned >on each query. Thus, NS chains require much more work to resolve and >should not be compared to A6 chains. It shouldn't take more than 2 or 3 >queries to resolve a full A6 chain. In all likelyhood, prefixes for >popular providers and services will remain cached, and resolving the names >of virtual hosts and hosts on the same network will only take a single >query, just as they do now with A records. -Nathan A6 chain will not stay in the same zone. it will go up from leaf site to a small ISP, then to middle ISP, and then to large ISP. this is the purpose of A6. foo.itojun.org. IN A6 64 ::9876:5432:9876:5432 segment0.itojun.org. segment0.itojun.org. IN A6 48 ::1234:0:0:0:0 ispX.net. ispX.net. IN A6 40 0:0:0012:: ispY.net. ispY.net. IN A6 32 0:0:2300:: ispZ.net. ispZ.net. IN A6 16 0:9876:: ispU.net. ispU.net. IN A6 0 1234:: 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 Jan 19 07:00:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JEwwe04926 for ipng-dist; Fri, 19 Jan 2001 06:58:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JEwkN04919 for ; Fri, 19 Jan 2001 06:58:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA29022 for ; Fri, 19 Jan 2001 06:58:45 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03606 for ; Fri, 19 Jan 2001 07:58:45 -0700 (MST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 1844E1E060; Fri, 19 Jan 2001 09:58:45 -0500 (EST) Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id JAA24051; Fri, 19 Jan 2001 09:58:43 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 60D1835C42; Fri, 19 Jan 2001 09:58:43 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "D. J. Bernstein" Cc: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 2001 09:58:43 -0500 Message-Id: <20010119145843.60D1835C42@smb.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <20010118090114.3487.qmail@cr.yp.to>, "D. J. Bernstein" writes: >Background: Why do NS and MX records use names, rather than addresses? > >Now my question: Why has IPNG proposed A6, rather than AAAA? > >The answer seems to be the same: If you copy an ISP's address into part >of an AAAA record, then you have to watch for changes in the address, >and echo them. Indirection avoids the opportunity for inconsistency. > >I agree: indirection is good. But it doesn't have to be handled by the >DNS _client_. It can be handled by the DNS _server_. The server can >periodically check for changes in the address. This will reduce latency, >and improve reliability. > > >Is there some other claimed benefit of A6? Apart from not wanting more polling, the idea is to facilitate rapid renumbering. AAAA is especially problematic if DNSSEC is used, since that would require resigning the entire zone -- and that's expensive. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 19 07:08:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JF4CR04977 for ipng-dist; Fri, 19 Jan 2001 07:04:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JF40N04970 for ; Fri, 19 Jan 2001 07:04:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA16309 for ; Fri, 19 Jan 2001 07:03:57 -0800 (PST) Received: from marduk.litech.org (gale.cs.cornell.edu [128.84.154.54]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25021 for ; Fri, 19 Jan 2001 07:03:55 -0800 (PST) Received: from lutchann (helo=localhost) by marduk.litech.org with local-esmtp (Exim 3.20 #3) id 14Jd4o-0004r5-00; Fri, 19 Jan 2001 10:03:42 -0500 Date: Fri, 19 Jan 2001 10:03:42 -0500 (EST) From: Nathan Lutchansky To: "itojun@iijlab.net" cc: "ipng@sunroof.eng.sun.com" Subject: Re: A6 benefits? In-Reply-To: <10610.979915932@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 19 Jan 2001, itojun@iijlab.net wrote: > >One other thing to keep in mind is that unlike an endless chain of > >glueless NS records, A6 records will, in general, chain to other records > >in the same zone and thus a significant part of the chain will be returned > >on each query. Thus, NS chains require much more work to resolve and > >should not be compared to A6 chains. It shouldn't take more than 2 or 3 > >queries to resolve a full A6 chain. In all likelyhood, prefixes for > >popular providers and services will remain cached, and resolving the names > >of virtual hosts and hosts on the same network will only take a single > >query, just as they do now with A records. -Nathan > > A6 chain will not stay in the same zone. it will go up from leaf site > to a small ISP, then to middle ISP, and then to large ISP. this is > the purpose of A6. > > foo.itojun.org. IN A6 64 ::9876:5432:9876:5432 segment0.itojun.org. > segment0.itojun.org. IN A6 48 ::1234:0:0:0:0 ispX.net. > ispX.net. IN A6 40 0:0:0012:: ispY.net. > ispY.net. IN A6 32 0:0:2300:: ispZ.net. > ispZ.net. IN A6 16 0:9876:: ispU.net. > ispU.net. IN A6 0 1234:: I was envisioning something more along the lines of: foo.itojun.org. A6 64 ::9876:5432:9876:5432 segment0.itojun.org. segment0.itojun.org. A6 48 0:0:0:1234:: itojun-prefix.ispX.net. itojun-prefix.ispX.net. A6 40 0:0:0008:: tokyo8-prefix.ispX.net. tokyo8-prefix.ispX.net. A6 32 0:0:2300:: tokyo-prefix.ispX.net. ispX-prefix.ispY.net. A6 16 0:9876:: japan-prefix.ispY.net. japan-prefix.ispY.net. A6 0 1234:: How many intermediate ISPs/zones are there typically expected to be? Site->ISP->backbone seems like a reasonable configuration, possibly with one additional ISP in the middle. It seems that the first one or two ISP prefixes would stay in caches of most busy servers. -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 Fri Jan 19 07:51:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JFoEF05286 for ipng-dist; Fri, 19 Jan 2001 07:50:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JFo4N05279 for ; Fri, 19 Jan 2001 07:50:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA10103 for ; Fri, 19 Jan 2001 07:50:03 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12351 for ; Fri, 19 Jan 2001 07:49:57 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0JFnWl07451; Fri, 19 Jan 2001 22:49:36 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Nathan Lutchansky , "ipng@sunroof.eng.sun.com" Subject: Re: A6 benefits? In-reply-to: Your message of "Fri, 19 Jan 2001 23:52:12 +0900." <10610.979915932@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 2001 22:49:32 +0700 Message-ID: <7449.979919372@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 19 Jan 2001 23:52:12 +0900 From: itojun@iijlab.net Message-ID: <10610.979915932@coconut.itojun.org> | A6 chain will not stay in the same zone. it will go up from leaf site | to a small ISP, then to middle ISP, and then to large ISP. this is | the purpose of A6. Well, perhaps. This will depend upon how it is configured. The example you showed is most likely taking the thing towards absurdity (and yes, that is certainly possible). On the other hand, I suspect that many sites will not want to place their addresses into the hands of some other zone administrator, and will instead use foo.itojun.org. IN A6 64 ::9876:5432:9876:5432 segment0.itojun.org. segment0.itojun.org. IN A6 48 ::1234:0:0:0:0 ispX.itojun.org. ispX.itojun.org. IN A6 40 0:0:0012:: ispY.itojun.org. ispY.itojun.org. IN A6 32 0:0:2300:: ispZ.itojun.org. ispZ.itojun.org. IN A6 16 0:9876:: ispU.itojun.org. ispU.itojun.org. IN A6 0 1234:: which gives almost all the same benefits (except you need to be involved when one of the prefixes changes), and gives you the added security (peace of mind I mean, not mathematical type security) that your addresses are all under your control. Then, having done that you will probably realise that you could just as easily make the third one be... ispX.itojun.org. IN A6 0 1234:9876:2312:: (assuming I mentally did the correct transformation) and not bother with the long chain. It might mean a few more records to update if/when one of the ISP prefixes changes (not in this example, but in general it would), but not so many more that it becomes unreasonable. Then the chain is just 3 long, and all in the same zone. However, we do need more experimentation with A6 - and to get that we need people to actually use the thing, rather than just looking at the worst possible configuration of it and throwing up their hands and saying "too hard". 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 Jan 19 09:20:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JHJ4Z05808 for ipng-dist; Fri, 19 Jan 2001 09:19:04 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JHIsN05801 for ; Fri, 19 Jan 2001 09:18:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA01879 for ; Fri, 19 Jan 2001 09:18:53 -0800 (PST) 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 JAA09201 for ; Fri, 19 Jan 2001 09:18:54 -0800 (PST) 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 JAA21786; Fri, 19 Jan 2001 09:16:58 -0800 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id JAA19170; Fri, 19 Jan 2001 09:18:50 -0800 Message-ID: <3A68767C.D2A3737B@hursley.ibm.com> Date: Fri, 19 Jan 2001 11:16:44 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Elz CC: itojun@iijlab.net, Nathan Lutchansky , "ipng@sunroof.eng.sun.com" Subject: Re: A6 benefits? References: <7449.979919372@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is all very well in theory. In practice, we obviously need to limit ourselves to very short chains - maximum 2 would be prudent, until we know whether it works at massive scale. Decoupling the host and prefix is the *big* win for renumbering; chaining up the ISP hierarchy is a marginal benefit. Brian Robert Elz wrote: > > Date: Fri, 19 Jan 2001 23:52:12 +0900 > From: itojun@iijlab.net > Message-ID: <10610.979915932@coconut.itojun.org> > > | A6 chain will not stay in the same zone. it will go up from leaf site > | to a small ISP, then to middle ISP, and then to large ISP. this is > | the purpose of A6. > > Well, perhaps. This will depend upon how it is configured. The example > you showed is most likely taking the thing towards absurdity (and yes, > that is certainly possible). > > On the other hand, I suspect that many sites will not want to place their > addresses into the hands of some other zone administrator, and will instead > use > > foo.itojun.org. IN A6 64 ::9876:5432:9876:5432 segment0.itojun.org. > segment0.itojun.org. IN A6 48 ::1234:0:0:0:0 ispX.itojun.org. > ispX.itojun.org. IN A6 40 0:0:0012:: ispY.itojun.org. > ispY.itojun.org. IN A6 32 0:0:2300:: ispZ.itojun.org. > ispZ.itojun.org. IN A6 16 0:9876:: ispU.itojun.org. > ispU.itojun.org. IN A6 0 1234:: > > which gives almost all the same benefits (except you need to be > involved when one of the prefixes changes), and gives you the > added security (peace of mind I mean, not mathematical type security) > that your addresses are all under your control. > > Then, having done that you will probably realise that you could > just as easily make the third one be... > > ispX.itojun.org. IN A6 0 1234:9876:2312:: > > (assuming I mentally did the correct transformation) and not bother > with the long chain. It might mean a few more records to update if/when > one of the ISP prefixes changes (not in this example, but in general > it would), but not so many more that it becomes unreasonable. > > Then the chain is just 3 long, and all in the same zone. > > However, we do need more experimentation with A6 - and to get that > we need people to actually use the thing, rather than just looking > at the worst possible configuration of it and throwing up their hands > and saying "too hard". > > 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 Jan 19 11:21:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JJJaL06685 for ipng-dist; Fri, 19 Jan 2001 11:19:36 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JJJVN06678 for ; Fri, 19 Jan 2001 11:19:32 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0JJHaB01804 for ipng@sunroof.eng.sun.com; Fri, 19 Jan 2001 11:17:36 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JJCNN06593 for ; Fri, 19 Jan 2001 11:12:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA17830 for ; Fri, 19 Jan 2001 11:12:23 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA23227 for ; Fri, 19 Jan 2001 12:12:22 -0700 (MST) Received: (qmail 807 invoked by uid 1001); 19 Jan 2001 19:11:34 -0000 Date: 19 Jan 2001 19:11:34 -0000 Message-ID: <20010119191134.4704.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: <20010119145843.60D1835C42@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin writes: > the idea is to facilitate rapid renumbering. As I said: Why should the indirection be handled by the _client_? Why shouldn't it be handled by the _server_? > not wanting more polling, Server-side indirection means that every server on the Internet will check, maybe twice per TTL, whether its ISP is changing its address. Client-side indirection means that every client will check, slightly less than once per TTL, with every ISP of every server that it uses regularly. The overall effect on Internet traffic is small either way, but it's much smaller with server-side indirection---and the user doesn't have to wait for it. > AAAA is especially problematic if DNSSEC is used, since > that would require resigning the entire zone -- and that's expensive. People change their zones all the time. If DNSSEC can't deal with that, it's in even more trouble than I thought. ---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 Jan 19 11:27:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JJQet06755 for ipng-dist; Fri, 19 Jan 2001 11:26:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JJQTN06748 for ; Fri, 19 Jan 2001 11:26:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA26112 for ; Fri, 19 Jan 2001 11:26:23 -0800 (PST) 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 LAA16034 for ; Fri, 19 Jan 2001 11:26:23 -0800 (PST) Received: (qmail 1078 invoked by uid 1001); 19 Jan 2001 19:25:38 -0000 Date: 19 Jan 2001 19:25:38 -0000 Message-ID: <20010119192538.31638.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 unreliability References: <3533.979898132@brandenburg.cs.mu.OZ.AU> <20010118091340.20931.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nathan Lutchansky writes: > Thus, NS chains require much more work to resolve and > should not be compared to A6 chains. I'm sorry if I didn't make myself clear. This is not a competition between out-of-zone NS records and out-of-zone A6 records. The two types of records are _cooperating_ to hurt service. The success chance drops exponentially with the amount of gluelessness. ---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 Jan 19 11:34:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JJXDZ06851 for ipng-dist; Fri, 19 Jan 2001 11:33:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JJX1N06844 for ; Fri, 19 Jan 2001 11:33:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA28427 for ; Fri, 19 Jan 2001 11:33:01 -0800 (PST) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA03330 for ; Fri, 19 Jan 2001 12:32:56 -0700 (MST) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id 8AD344CE0B; Fri, 19 Jan 2001 14:32:54 -0500 (EST) Received: from smb.research.att.com (sigaba.research.att.com [135.207.23.169]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id OAA29830; Fri, 19 Jan 2001 14:32:54 -0500 (EST) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id CE15835C42; Fri, 19 Jan 2001 14:32:53 -0500 (EST) X-Mailer: exmh version 2.2 06/23/2000 with version: MH 6.8.3 #1[UCI] From: "Steven M. Bellovin" To: "D. J. Bernstein" Cc: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 2001 14:32:53 -0500 Message-Id: <20010119193253.CE15835C42@smb.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <20010119191134.4704.qmail@cr.yp.to>, "D. J. Bernstein" writes: >Steven M. Bellovin writes: > >Client-side indirection means that every client will check, slightly >less than once per TTL, with every ISP of every server that it uses >regularly. Except, of course, for caching. > >The overall effect on Internet traffic is small either way, but it's >much smaller with server-side indirection---and the user doesn't have to >wait for it. > >> AAAA is especially problematic if DNSSEC is used, since >> that would require resigning the entire zone -- and that's expensive. > >People change their zones all the time. If DNSSEC can't deal with that, >it's in even more trouble than I thought. Most people don't change the entire zone that often; only the changed records need to be resigned (plus those on either side of an insertion or deletion). With AAAA, if your ISP renumbers you (possibly because it itself has had to renumber), you have to resign the entire zone. More precisely, you have to resign every record in the zone. --Steve Bellovin, http://www.research.att.com/~smb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 19 14:45:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0JMiPR07821 for ipng-dist; Fri, 19 Jan 2001 14:44:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0JMiBN07805 for ; Fri, 19 Jan 2001 14:44:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA14792 for ; Fri, 19 Jan 2001 14:44:09 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA09469 for ; Fri, 19 Jan 2001 14:44:09 -0800 (PST) Received: (qmail 32262 invoked by uid 1001); 19 Jan 2001 22:39:03 -0000 Date: 19 Jan 2001 22:39:03 -0000 Message-ID: <20010119223903.26236.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: <20010119193253.CE15835C42@smb.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin writes: > Except, of course, for caching. That's not an exception. As I said, the client checks slightly less than once per TTL. How many addresses has your site's DNS cache looked up in the past week? How many different ISPs are involved? One thousand? Ten thousand? Client-side indirection means that you have to check every one of those ISPs for changes. Server-side indirection means that you have to check one ISP, namely yours, for changes. The frequency of checks per ISP is somewhat higher for server-side than for client-side, but client-side involves vastly more ISPs. Bottom line: This is not a benefit for A6. > Most people don't change the entire zone that often; Here at UIC, for example, we have EECS splitting into CS and ECE. All the machines in eecs.uic.edu are going to be given new names. Are you saying that this trivial operation would pose serious CPU-time problems if we were using DNSSEC? Are there any other benefits for A6? ---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 Jan 19 16:11:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0K0A7U08201 for ipng-dist; Fri, 19 Jan 2001 16:10:07 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0K09jN08178 for ; Fri, 19 Jan 2001 16:09:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA05822 for ; Fri, 19 Jan 2001 16:09:44 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA26801 for ; Fri, 19 Jan 2001 16:09:44 -0800 (PST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA23643; Fri, 19 Jan 2001 19:09:36 -0500 Date: Fri, 19 Jan 2001 19:09:36 -0500 (EST) From: Jim Bound To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: [rfc2553bis] EAI_NODATA 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 Jinmei, Sorry for late response. EAI_NODATA was replaced by EAI_AGAIN in XNS 5.2. Also EAI_ADDRFAMILY is now EAI_FAMILY. I will send last update to the id editors tonight and ask for last call. The only changes from -01 to -02 were updates to IEEE references from Andrew Golan at Sun and some edits. Good catch I removed EAI_NODATA and EAI_ADDRFAMILY. thanks /jim On Sat, 6 Jan 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > (This may have already been discussed. if so, I'd apologize in advance.) > > I noticed that description about EAI_NODATA had disappeared since > draft-ietf-ipngwg-rfc2553bis-00.txt. However, the macro is still in > the summary list in the latest draft (01). Has the value been > obsoleted, or should it be described again? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 19 18:23:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0K2Lli08883 for ipng-dist; Fri, 19 Jan 2001 18:21:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0K2LaN08876 for ; Fri, 19 Jan 2001 18:21:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA22228 for ; Fri, 19 Jan 2001 18:21:36 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA27601 for ; Fri, 19 Jan 2001 18:21:36 -0800 (PST) Received: (qmail 11425 invoked by uid 1001); 20 Jan 2001 02:20:46 -0000 Date: 20 Jan 2001 02:20:46 -0000 Message-ID: <20010120022046.15565.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: <20010118090114.3487.qmail@cr.yp.to> <3533.979898132@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > allows significant caching benefits Do you have some numbers to back that up? How many DNS queries does your site generate? How many of them would have been saved by this type of overlap? Assume that networks are marked by in-addr.arpa zones. Ignore the extra cost of following out-of-zone pointers. > The same applies to NS records, MX records, etc I've reviewed the logs on a busy mail server. The overlap is negligible. Yes, there are quite a few high-TTL MX/NS records pointing to low-TTL A records, but only a small fraction of the A owners are shared by other MX/NS records. ---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 Jan 20 00:22:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0K8KUv10129 for ipng-dist; Sat, 20 Jan 2001 00:20:30 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0K8KLN10122 for ; Sat, 20 Jan 2001 00:20:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA00847 for ; Sat, 20 Jan 2001 00:20:20 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03752 for ; Sat, 20 Jan 2001 00:20:15 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0K8KMu01653; Sat, 20 Jan 2001 15:20:22 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? In-reply-to: Your message of "20 Jan 2001 02:20:46 GMT." <20010120022046.15565.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Jan 2001 15:20:22 +0700 Message-ID: <1651.979978822@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 20 Jan 2001 02:20:46 -0000 From: "D. J. Bernstein" Message-ID: <20010120022046.15565.qmail@cr.yp.to> | Do you have some numbers to back that up? No. I thought you were asking what the benefits were supposed to be. I also thought I made it clear that there isn't currently a lot of intelligence in DNS configuration. I guess the question is whether we design protocols so they can be used intelligently by those who care, or whether we design them assuming that all the users are morons, and cannot possibly cope with anything sophisticated. | Yes, there are quite a few high-TTL MX/NS records pointing to low-TTL A | records, but only a small fraction of the A owners are shared by other | MX/NS records. So, way too many DNS admins obviously accept bogus advice that NS records should be nsN.my.domain (or similar) instead of using the well known names of the actual servers? That people can be misled this way doesn't mean that they have to be, or that we should assume it is the only way. 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 Jan 20 01:52:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0K9obX10516 for ipng-dist; Sat, 20 Jan 2001 01:50:37 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0K9oPN10509 for ; Sat, 20 Jan 2001 01:50:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA05587 for ; Sat, 20 Jan 2001 01:50:23 -0800 (PST) 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 BAA23123 for ; Sat, 20 Jan 2001 01:50:24 -0800 (PST) Received: (qmail 20932 invoked by uid 1001); 20 Jan 2001 09:49:36 -0000 Date: 20 Jan 2001 09:49:36 -0000 Message-ID: <20010120094936.24558.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: <20010120022046.15565.qmail@cr.yp.to> <1651.979978822@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 I've analyzed my DNS cache logs in more detail: * The number of different MX targets is 97% of the number of different MX records. Weighting by query doesn't change the figures. * The number of different address sets for those MX targets is 94% of the number of different MX records. Again, weighting by query doesn't change the figures. * 40% of all MX targets are outside the MX server's bailiwick. The cache can't use the A even if the server provides it. In other words: There's very little overlap between mail exchangers. The number of queries wasted by missing addresses is much larger than the number of queries that could possibly be saved by overlap. Elz is wrong when he blames the lack of overlap on the choice of MX names. In fact, almost all of the addresses are different. Elz concludes, from his incorrect efficiency claim, that my advice to avoid gluelessness is ``bogus.'' Apparently he doesn't understand that gluelessness causes _reliability_ problems. I explained this in detail in the A6-unreliability thread. ---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 Jan 20 16:58:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0L0uVx01255 for ipng-dist; Sat, 20 Jan 2001 16:56:31 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0L0uH201245 for ; Sat, 20 Jan 2001 16:56:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA13964 for ; Sat, 20 Jan 2001 11:17:12 -0800 (PST) Received: from smtp4.libero.it (smtp4.libero.it [193.70.192.54]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20546 for ; Sat, 20 Jan 2001 12:17:10 -0700 (MST) Received: from trantor.ferrara.linux.it (151.26.143.98) by smtp4.libero.it (5.5.015.5) id 3A54738F00AC8D4E for ipng@sunroof.eng.sun.com; Sat, 20 Jan 2001 20:17:09 +0100 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 8E8FB97CFF; Sat, 20 Jan 2001 20:14:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 8C66197CFE for ; Sat, 20 Jan 2001 20:14:12 -0500 (EST) Date: Sat, 20 Jan 2001 20:14:12 -0500 (EST) From: Mauro Tortonesi To: ipng@sunroof.eng.sun.com Subject: src addr sel (was: A6 unreliability) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 18 Jan 2001 Jim.Bound@nokia.com wrote: > Also go look at the source address selection stuff where we now have kernel > and user space hacking dns abstract types back and forth. Another case of > excessive engineering insanity and architecture without consideration > for performance. > Its good work as a spec but I have my doubts about what it will do to the > performance of end system **production** running code. i think that you are just right. such a complex stuff like source address selection cannot be implemented in an easy way. this is from draft-ietf-ipngwg-default-addr-select-02: The destination address selection algorithm needs information about potential source addresses. One possible implementation strategy is for getipnodebyname() and getaddrinfo() to call down to the IPv6 network layer with a list of destination addresses, sort the list in the network layer with full current knowledge of available source addresses, and return the sorted list to getipnodebyname() or getaddrinfo(). This is simple and gives the best results but it introduces the overhead of another system call. One way to reduce this overhead is to cache the sorted address list in the resolver, so that subsequent calls for the same name do not need to resort the list. imho this is not so simple to implement. it requires a tight coupling between the network layer (kernel space) and the networking stuff of the C library (user space), and a very careful design of the caching policy (especially if we have to handle temporary, preferred and deprecated addresses). Another implementation strategy is to call down to the network layer to retrieve source address information and then sort the list of addresses directly in the context of getipnodebyname() or getaddrinfo(). To reduce overhead in this approach, the source address information can be cached, amortizing the overhead of retrieving it across multiple calls to getipnodebyname() and getaddrinfo(). this is a simpler solution, as it requires only a minor interaction between kernel- and user-space. but the complexity of the caching algorithm is not reduced, and this implementation introduces another problem: In this approach, the implementation may not have knowledge of the outgoing interface for each destination, so it MAY use a looser definition of the candidate set during destination address ordering. and this is surely a negative point. moreover, there are lots of other problems to be solved. in particular: 1) performance. it cannot be allowed by using cached data, as caching is very difficult to do. and the spec says: In any case, if the implementation uses cached and possibly stale information in its implementation of destination address selection, or if the ordering of a cached list of destination addresses is possibly stale, then it should ensure that the destination address ordering returned to the application is no more than one second out of date. For example, an implementation might make a system call to check if any routing table entries or source address assignments that might affect these algorithms have changed. because cached data is valid for no more than 1 sec., and the implementation of a correct caching algorithm is VERY difficult, caching is more a problem than a solution. 2) handling the policy table. it should be kept in kernel-space, but designing a simple and safe way to edit it is surely not a trivial task. i wonder if there is a working implementation of dest/src address selection that is fully conformant to this spec. i'd really like to know how the implementation issues have been solved. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 22 09:36:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0MHYaB10265 for ipng-dist; Mon, 22 Jan 2001 09:34:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0MHYQ210258 for ; Mon, 22 Jan 2001 09:34:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA29197 for ; Mon, 22 Jan 2001 09:34:24 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23168 for ; Mon, 22 Jan 2001 09:34:26 -0800 (PST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Mon, 22 Jan 2001 12:34:23 -0500 Message-ID: From: George Tsirtsis To: ipng@sunroof.eng.sun.com Cc: "'deering@cisco.com'" , "'aconta@lucent.com'" Subject: Clarification on ICMPv6 Date: Mon, 22 Jan 2001 12:34:16 -0500 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 All, Reading through RFC2463 I have the following question. When a node receives an ICMPv6 message with unknown TYPE (from Information range), the node must silently discard the message. What is not clear is what happens if the TYPE is known but the CODE is not. Should this message also be silently discarded? Thanks for any help Regards George -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 22 11:36:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0MJYWB10890 for ipng-dist; Mon, 22 Jan 2001 11:34:32 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0MJYR210883 for ; Mon, 22 Jan 2001 11:34:28 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0MJWR101593 for ipng@sunroof.eng.sun.com; Mon, 22 Jan 2001 11:32:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0LMcw206254 for ; Sun, 21 Jan 2001 14:38:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA16307 for ; Sun, 21 Jan 2001 14:38:59 -0800 (PST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA02816 for ; Sun, 21 Jan 2001 14:38:58 -0800 (PST) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA13013 for ; Sun, 21 Jan 2001 17:38:58 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA13009 for ; Sun, 21 Jan 2001 17:38:57 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Jan 2001 23:38:57 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0ADA5F6F@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ipng@sunroof.eng.sun.com Subject: MLD MIB Date: Sun, 21 Jan 2001 23:38:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, The MLD MIB is close to being published as RFC. We found a few "editorial" changes that I am proposing to the RFC-Editor. Just so you know. If you have a real issue with it, then speak up very quickly. None of these changes change anything in terms of bytes on the wire or semantics. Bert ------------------------------------------ Editorial changes proposed: > Change all occurences of Ipv6IfIndexOrZero and Ipv6IfIndex (from IPv6-TC) > into the equivalent and better InterfaceIndexOrZero and InterfaceIndex > from IF-MIB. Also change the use of Ipv6Address (from IPv6-TC) to the equivalent and better InetAddressIPv6 (SIZE (16)) from the > INET-ADDRESS-MIB > > So the changes are: > > OLD (page 3) > Ipv6Address, Ipv6IfIndexOrZero, > Ipv6IfIndex FROM IPV6-TC > NEW: > InetAddressIPv6 FROM INET-ADDRESS-MIB > InterfaceIndex, InterfaceIndexOrZero > FROM IF-MIB > > OLD (page 4): > mldInterfaceIfIndex Ipv6IfIndex, > NEW: > mldInterfaceIfIndex InterfaceIndex, > OLD (page 4): mldInterfaceQuerier Ipv6Address, NEW: mldInterfaceQuerier InetAddressIPv6, > OLD (page 4): > mldInterfaceProxyIfIndex Ipv6IfIndexOrZero, > NEW: > mldInterfaceProxyIfIndex InterfaceIndexOrZero, > > OLD (page 4): > SYNTAX Ipv6IfIndex > NEW: > SYNTAX InterfaceIndex > OLD (page 5): SYNTAX Ipv6Address NEW: SYNTAX InetAddressIPv6 (SIZE (16)) > OLD (page 6): > SYNTAX Ipv6IfIndexOrZero > NEW: > SYNTAX InterfaceIndexOrZero > > OLD (page 8): mldCacheAddress Ipv6Address, > mldCacheIfIndex Ipv6IfIndex, mldCacheSelf TruthValue, mldCacheLastReporter Ipv6Address, > NEW: mldCacheAddress InetAddressIPv6, > mldCacheIfIndex InterfaceIndex, mldCacheSelf TruthValue, mldCacheLastReporter InetAddressIPv6, > OLD (page 8): SYNTAX Ipv6Address > NEW: > SYNTAX InetAddressIPv6 (SIZE (16)) > OLD (page 8): > SYNTAX Ipv6IfIndex > NEW: > SYNTAX InterfaceIndex > > OLD (page 9): SYNTAX Ipv6Address > NEW: > SYNTAX InetAddressIPv6 (SIZE (16)) > Bert > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jan 22 13:05:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0MKx7o11121 for ipng-dist; Mon, 22 Jan 2001 12:59:07 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0MKwq211114 for ; Mon, 22 Jan 2001 12:58:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03012 for ; Mon, 22 Jan 2001 12:58:50 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25626 for ; Mon, 22 Jan 2001 12:58:50 -0800 (PST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 22 Jan 2001 12:57:57 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 22 Jan 2001 12:58:41 -0800 (Pacific Standard Time) Received: from DF-BOWWOW.platinum.corp.microsoft.com ([172.30.236.101]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Mon, 22 Jan 2001 12:58:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: MLD MIB Date: Mon, 22 Jan 2001 12:58:39 -0800 Message-ID: <5B90AD65A9E8934987DB0C8C0762657405266A87@DF-BOWWOW.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MLD MIB Thread-Index: AcCErqMjcE+Ea3ChQV+QkH/6eYZq4QABz6sg From: "Dave Thaler" To: "Wijnen, Bert (Bert)" Cc: X-OriginalArrivalTime: 22 Jan 2001 20:58:40.0674 (UTC) FILETIME=[191ED820:01C084B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f0MKwr211115 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For what it's worth, I agree with all of the editorial changes proposed. -Dave > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Sunday, January 21, 2001 2:39 PM > To: ipng@sunroof.eng.sun.com > Subject: MLD MIB > > All, > > The MLD MIB is close to being published as RFC. > We found a few "editorial" changes that I am proposing to > the RFC-Editor. Just so you know. If you have a real > issue with it, then speak up very quickly. None of these > changes change anything in terms of bytes on the wire > or semantics. > > Bert > ------------------------------------------ > Editorial changes proposed: > > > Change all occurences of Ipv6IfIndexOrZero and Ipv6IfIndex > (from IPv6-TC) > > into the equivalent and better InterfaceIndexOrZero and > InterfaceIndex > > from IF-MIB. Also change the use of Ipv6Address (from > IPv6-TC) to the > equivalent and better InetAddressIPv6 (SIZE (16)) from the > > INET-ADDRESS-MIB > > > > So the changes are: > > > > OLD (page 3) > > Ipv6Address, Ipv6IfIndexOrZero, > > Ipv6IfIndex FROM IPV6-TC > > NEW: > > InetAddressIPv6 FROM INET-ADDRESS-MIB > > InterfaceIndex, InterfaceIndexOrZero > > FROM IF-MIB > > > > OLD (page 4): > > mldInterfaceIfIndex Ipv6IfIndex, > > NEW: > > mldInterfaceIfIndex InterfaceIndex, > > > OLD (page 4): > mldInterfaceQuerier Ipv6Address, > NEW: > mldInterfaceQuerier InetAddressIPv6, > > > OLD (page 4): > > mldInterfaceProxyIfIndex Ipv6IfIndexOrZero, > > NEW: > > mldInterfaceProxyIfIndex InterfaceIndexOrZero, > > > > OLD (page 4): > > SYNTAX Ipv6IfIndex > > NEW: > > SYNTAX InterfaceIndex > > > OLD (page 5): > SYNTAX Ipv6Address > NEW: > SYNTAX InetAddressIPv6 (SIZE (16)) > > > OLD (page 6): > > SYNTAX Ipv6IfIndexOrZero > > NEW: > > SYNTAX InterfaceIndexOrZero > > > > OLD (page 8): > mldCacheAddress Ipv6Address, > > mldCacheIfIndex Ipv6IfIndex, > mldCacheSelf TruthValue, > mldCacheLastReporter Ipv6Address, > > NEW: > mldCacheAddress InetAddressIPv6, > > mldCacheIfIndex InterfaceIndex, > mldCacheSelf TruthValue, > mldCacheLastReporter InetAddressIPv6, > > > OLD (page 8): > SYNTAX Ipv6Address > > NEW: > > SYNTAX InetAddressIPv6 (SIZE (16)) > > > OLD (page 8): > > SYNTAX Ipv6IfIndex > > NEW: > > SYNTAX InterfaceIndex > > > > OLD (page 9): > SYNTAX Ipv6Address > > NEW: > > SYNTAX InetAddressIPv6 (SIZE (16)) > > > > Bert > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 23 04:35:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0NCXqt12239 for ipng-dist; Tue, 23 Jan 2001 04:33:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0NCXf212232 for ; Tue, 23 Jan 2001 04:33:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA22394 for ; Tue, 23 Jan 2001 04:33:40 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15712 for ; Tue, 23 Jan 2001 04:33:39 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09258; Tue, 23 Jan 2001 07:33:40 -0500 (EST) Message-Id: <200101231233.HAA09258@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-02.txt Date: Tue, 23 Jan 2001 07:33:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-02.txt Pages : 31 Date : 22-Jan-01 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2553bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010122143338.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010122143338.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 Jan 23 11:03:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0NJ22112685 for ipng-dist; Tue, 23 Jan 2001 11:02:02 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0NJ1u212678 for ; Tue, 23 Jan 2001 11:01:57 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0NIxv802780 for ipng@sunroof.eng.sun.com; Tue, 23 Jan 2001 10:59:57 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0N8EA212053 for ; Tue, 23 Jan 2001 00:14:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA21091 for ; Tue, 23 Jan 2001 00:14:11 -0800 (PST) Received: from iproxy2.ericsson.dk (iproxy2.ericsson.dk [130.228.248.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA19295 for ; Tue, 23 Jan 2001 01:14:09 -0700 (MST) Received: from dan.lmd.ericsson.se (dan.lmd.ericsson.se [192.66.3.254]) by iproxy2.ericsson.dk (8.10.1/8.10.1) with ESMTP id f0N8E6I02049; Tue, 23 Jan 2001 09:14:06 +0100 (MET) Received: from pcnp.ted.dk.eu.ericsson.se (IDENT:root@pcnp.ted.dk.eu.ericsson.se [192.66.4.157]) by dan.lmd.ericsson.se (8.10.1/8.10.1/LMDmain-3.0) with ESMTP id f0N8E0123178; Tue, 23 Jan 2001 09:14:01 +0100 (MET) Received: from localhost (pcn@localhost) by pcnp.ted.dk.eu.ericsson.se (8.10.1/8.10.1) with ESMTP id f0N8FXi28078; Tue, 23 Jan 2001 09:15:34 +0100 Date: Tue, 23 Jan 2001 09:15:33 +0100 (CET) From: =?ISO-8859-1?Q?Peder_Chr=2E_N=F8rgaard?= X-Sender: To: "Wijnen, Bert (Bert)" cc: Subject: Re: MLD MIB In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0ADA5F6F@nl0006exch002u.nl.lucent.com> 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 On Sun, 21 Jan 2001, Wijnen, Bert (Bert) wrote: > Date: Sun, 21 Jan 2001 23:38:56 +0100 > From: "Wijnen, Bert (Bert)" > To: ipng@sunroof.eng.sun.com > Subject: MLD MIB > > All, > > The MLD MIB is close to being published as RFC. > We found a few "editorial" changes that I am proposing to > the RFC-Editor. Just so you know. If you have a real > issue with it, then speak up very quickly. None of these > changes change anything in terms of bytes on the wire > or semantics. I have to disagree with the premises of this statement, if not the conclusion. This change does indeed change the semantics of the implementation, and also the value of the bytes on the wire. The InterfaceIndex and the Ipv6IfIndex are two different numbering schemes, and replacing the latter with the former forces changes in all implementations. Cf discussion on the IPv6 Design Team homepage . Unfortunately that discussion never reached a conclusion, so the MLD-MIB designers do not really have any guidance in the choice between the two schemes. Say, if the design team had concluded to do away with the Ipv6IfIndex in the IPV6-MIB and friends, the MLD-MIB should of course do the same. >From my own position, the proposed change does not hurt, for I have not completed the implementation of the MLD-MIB. But anyone with a working implementation of MLD-MIB will have to modify code to adapt to this change. best regards Peder Chr. N鴕gaard Senior System Developer, M. Sc. Ericsson Telebit A/S tel: +45 89 38 52 53 Skanderborgvej 232 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark mob: +45 21 28 66 58 e-mail: Peder.C.Norgaard@ted.ericsson.dk (old e-mail 1992-2000: pcn@tbit.dk) > > Bert > ------------------------------------------ > Editorial changes proposed: > > > Change all occurences of Ipv6IfIndexOrZero and Ipv6IfIndex (from IPv6-TC) > > into the equivalent and better InterfaceIndexOrZero and InterfaceIndex > > from IF-MIB. Also change the use of Ipv6Address (from IPv6-TC) to the > equivalent and better InetAddressIPv6 (SIZE (16)) from the > > INET-ADDRESS-MIB > > > > So the changes are: > > > > OLD (page 3) > > Ipv6Address, Ipv6IfIndexOrZero, > > Ipv6IfIndex FROM IPV6-TC > > NEW: > > InetAddressIPv6 FROM INET-ADDRESS-MIB > > InterfaceIndex, InterfaceIndexOrZero > > FROM IF-MIB > > > > OLD (page 4): > > mldInterfaceIfIndex Ipv6IfIndex, > > NEW: > > mldInterfaceIfIndex InterfaceIndex, > > > OLD (page 4): > mldInterfaceQuerier Ipv6Address, > NEW: > mldInterfaceQuerier InetAddressIPv6, > > > OLD (page 4): > > mldInterfaceProxyIfIndex Ipv6IfIndexOrZero, > > NEW: > > mldInterfaceProxyIfIndex InterfaceIndexOrZero, > > > > OLD (page 4): > > SYNTAX Ipv6IfIndex > > NEW: > > SYNTAX InterfaceIndex > > > OLD (page 5): > SYNTAX Ipv6Address > NEW: > SYNTAX InetAddressIPv6 (SIZE (16)) > > > OLD (page 6): > > SYNTAX Ipv6IfIndexOrZero > > NEW: > > SYNTAX InterfaceIndexOrZero > > > > OLD (page 8): > mldCacheAddress Ipv6Address, > > mldCacheIfIndex Ipv6IfIndex, > mldCacheSelf TruthValue, > mldCacheLastReporter Ipv6Address, > > NEW: > mldCacheAddress InetAddressIPv6, > > mldCacheIfIndex InterfaceIndex, > mldCacheSelf TruthValue, > mldCacheLastReporter InetAddressIPv6, > > > OLD (page 8): > SYNTAX Ipv6Address > > NEW: > > SYNTAX InetAddressIPv6 (SIZE (16)) > > > OLD (page 8): > > SYNTAX Ipv6IfIndex > > NEW: > > SYNTAX InterfaceIndex > > > > OLD (page 9): > SYNTAX Ipv6Address > > NEW: > > SYNTAX InetAddressIPv6 (SIZE (16)) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 23 11:33:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0NJViv12755 for ipng-dist; Tue, 23 Jan 2001 11:31:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0NJVW212748 for ; Tue, 23 Jan 2001 11:31:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA25732 for ; Tue, 23 Jan 2001 11:31:29 -0800 (PST) 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 LAA25314 for ; Tue, 23 Jan 2001 11:31:31 -0800 (PST) Received: (qmail 3626 invoked by uid 1001); 23 Jan 2001 19:29:23 -0000 Date: 23 Jan 2001 19:29:23 -0000 Message-ID: <20010123192923.17892.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: <2526.980262396@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 Renumbering is an example of the ``every problem can be solved by another level of indirection'' principle. I've been asking why this indirection should be in the _client_ rather than the _server_. So far, all I've heard is that (1) this might save more queries than it wastes, even though the analogous assertion for MX records is not true, and (2) this would occasionally save some DNSSEC CPU time. Robert Elz responds, on three other mailing lists: > If you care to look back over the archives (IPNG, and > perhaps DNSIND) you will see why things are the way they are. I'm sorry, but I don't see server-side indirection discussed anywhere in the IPNG archives. What exactly were the dates of the discussion? What benefits were attributed to client-side indirection? ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 23 12:08:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0NK7Dc12837 for ipng-dist; Tue, 23 Jan 2001 12:07:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0NK72212830 for ; Tue, 23 Jan 2001 12:07:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA05991 for ; Tue, 23 Jan 2001 12:07:01 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA20811 for ; Tue, 23 Jan 2001 13:07:00 -0700 (MST) Received: (qmail 2084 invoked by uid 1001); 23 Jan 2001 20:02:47 -0000 Date: 23 Jan 2001 20:02:47 -0000 Message-ID: <20010123200247.24320.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: An easy example of A6 unreliability References: <200101182320.f0INK8m24657@zed.isi.edu> <3A685A4C.7802A509@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes, on three other mailing lists: > I think it was recognized a long time ago that the initial deployment > of A6 records should be limited to two (or at most 3) levels. The question > is whether that is enough to avoid the horrors described by Dan Bernstein > over on IPNG. The answer is ``of course not.'' Here's an example with just one level of A6 records: aol.com NS dns-01.ns.aol.com aol.com NS dns-02.ns.aol.com aol.net NS dns-01.ns.aol.com aol.net NS dns-02.ns.aol.com dns-01.ns.aol.com A6 ... prefix.aol.net dns-02.ns.aol.com A6 ... prefix.aol.net Now aol.com and aol.net are unreachable. AOL already has these NS records, and it's _encouraged_ to set up these A6 records, right? Details of the failure: Say a cache needs the address of www.aol.com. It contacts the .com servers and learns aol.com NS dns-01.ns.aol.com aol.com NS dns-02.ns.aol.com dns-01.ns.aol.com A6 ... prefix.aol.net dns-02.ns.aol.com A6 ... prefix.aol.net but it won't accept the address of prefix.aol.net from the .com servers even if that address is provided. (Yes, it's theoretically possible for caches to see that this isn't poison because the .com servers are the same as the .net servers, but let's fast forward to a time when the .com servers and the .net servers have been separated.) The cache now puts the www.aol.com query on hold. It needs the address of prefix.aol.net. It contacts the .net servers and learns aol.net NS dns-01.ns.aol.com aol.net NS dns-02.ns.aol.com but it won't accept the addresses of *.aol.com from the .net servers even if those addresses are provided. It puts the prefix.aol.net query on hold; it needs the addresses of dns-*.ns.aol.com. Repeat ad nauseam. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 23 12:28:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0NKRJA12902 for ipng-dist; Tue, 23 Jan 2001 12:27:19 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0NKRA212895 for ; Tue, 23 Jan 2001 12:27:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA22959 for ; Tue, 23 Jan 2001 12:27:09 -0800 (PST) Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24126 for ; Tue, 23 Jan 2001 12:27:08 -0800 (PST) Received: from pc1227 ([62.255.99.195]) by mta02-svc.ntlworld.com (InterMail vM.4.01.02.27 201-229-119-110) with SMTP id <20010123202702.CPMK23225.mta02-svc.ntlworld.com@pc1227>; Tue, 23 Jan 2001 20:27:02 +0000 Message-ID: <005501c0857a$ad058ba0$0100a8c0@mshome.net> Reply-To: "Ian Nice4" From: "Ian Nice4" To: Subject: Questionnaire Date: Tue, 23 Jan 2001 20:25:48 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0050_01C0857A.AC022560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0050_01C0857A.AC022560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable QuestionnaireI am a student from Cheltenham and Gloucester College of HE = and am currently in the last year of my degree with honours in = computing. I am studying when IPV6 will be introduced and some of the = issues surrounding the implementation for my dissertation. This project = will involve 20% of my final year mark, and I am hoping you would spend = 10 minutes filling out the following questionnaire to aid me in my = study. Any replies you give will be gratefully received. I have sent = this questionnaire in HTML format so if you can only see a jumbled mass = of code or you cannot see a submit button at the bottom please navigate = to http://mmprj01.chelt.ac.uk/upload/mainngtrans.htm. Please pass this = e-mail on to all relevant contacts or departments. Please spare a few minutes of your time filling out this questionnaire. Many Thanks, Ian Nice C&GCHE=20 Name: E-mail Address: =20 Organisation: Job Title: =20 Q1, When do you think IPV6 will finally be ratified as a standard?=20 5 years or longer 4 to 5 years=20 3 to 4 years 2 to 3 years=20 up to 2 years=20 Q2, Are you aware of the progress of hardware developments for IPV6 = implementation? Yes No=20 If you answered 'yes' to question 2 please continue to question 3 = otherwise please proceed to question 4=20 Q3, how close are we to being ready?=20 5 years or longer 4 to 5 years=20 3 to 4 years 2 to 3 years=20 up to 2 years=20 Please comment further on the types of technology. =20 Q4, Are you aware of the progress of software developments for IPV6 = implementation? Yes No=20 If you answered 'yes' to question 4 please continue to question 5 = otherwise please proceed to question 6=20 Q5, how close are we to being ready?=20 5 years or longer 4 to 5 years=20 3 to 4 years 2 to 3 years=20 up to 2 years=20 Please comment futher on the types of technology. =20 Q6, Chris Lee in a recent article in IT Week (8th Jan 2001) entitled = 'ITU draws up 3G roadmap' quoted that some 3G [mobile phone service that = will use IPV6] "...should be available in the first half of 2002.". As = members of IPNGWG are you happy that IPV6 infrastructure devices will be = available to support these devices by this time? =20 Q7, In the same article Chris Lee quotes analysis firm 'Analysys' = predicting "...3G services will have 480 million subscribers worldwide = by 2006." Do you think that the introduction of the IPV6 dependant = technology might clear up the issue of motivation to upgrade? As Chris = Lewis put it in 'Cisco TCP/IP Routing Professional Reference' "For most = private networks, the benefits of upgrading are not yet clear" Would you = like to comment on this? =20 Q8, In you view, what will be the motivation for ISP's and organisations = to change fully functional IPV4 implementations? =20 Q9,Are you aware of new technologies that demand features of IPV6 that = IPV4 does not offer? =20 Q10, Are you aware of any new technologies that are IPV6 enabled only? =20 Q11, Do you have any further comments you wish to make? =20 Q12, If I have any question regarding your replies may I contact you = again? Yes=20 No=20 Q13, Would you like to receive a copy of the finished report? Yes=20 No=20 =20 ------=_NextPart_000_0050_01C0857A.AC022560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Questionnaire I am a student from Cheltenham and Gloucester = College of=20 HE and am currently in the last year of my degree with honours in = computing. I=20 am studying when IPV6 will be introduced and some of the issues = surrounding the=20 implementation for my dissertation. This project will involve 20% of my = final=20 year mark, and I am hoping you would spend 10 minutes filling out the = following=20 questionnaire to aid me in my study. Any replies you give will be = gratefully=20 received. I have sent this questionnaire in HTML format so if you can = only see a=20 jumbled mass of code or you cannot see a submit button at the bottom = please=20 navigate to http://mmprj01.chelt.ac.uk/upload/mainngtrans.htm. Please = pass this=20 e-mail on to all relevant contacts or departments.

Please spare a few minutes of your time filling out this=20 questionnaire.


Many Thanks, Ian Nice C&GCHE=20

Name: E-mail Address:
Organisation: Job Title:

Q1, When do you think IPV6 will finally be ratified as a standard? =
5 = years or=20 longer 4 to 5 = years
3 to 4 = years 2 to 3 = years
up to 2=20 years

Q2, Are you aware of the progress of hardware developments for = IPV6=20 implementation?
Yes No

If you=20 answered 'yes' to question 2 please continue to question 3 otherwise = please=20 proceed to question 4=20

Q3, how close are we to being ready?
5 = years or=20 longer 4 to 5 = years
3 to 4 = years 2 to 3 = years
up to 2=20 years

Please comment further on the = types of=20 technology.
=20

Q4, Are you aware of the progress of software developments for = IPV6=20 implementation?
Yes No

If you=20 answered 'yes' to question 4 please continue to question 5 otherwise = please=20 proceed to question 6=20

Q5, how close are we to being ready?
5 = years or=20 longer 4 to 5 = years
3 to 4 = years 2 to 3 = years
up to 2=20 years

Please comment futher on the = types of=20 technology.
=20

Q6, Chris Lee in a recent article in IT Week (8th Jan 2001) = entitled 'ITU=20 draws up 3G roadmap' quoted that some 3G [mobile phone service that will = use=20 IPV6] "...should be available in the first half of 2002.". As members of = IPNGWG=20 are you happy that IPV6 infrastructure devices will be available to = support=20 these devices by this time?
=20

Q7, In the same article Chris Lee quotes analysis firm 'Analysys'=20 predicting "...3G services will have 480 million subscribers worldwide = by 2006."=20 Do you think that the introduction of the IPV6 dependant technology = might clear=20 up the issue of motivation to upgrade? As Chris Lewis put it in 'Cisco = TCP/IP=20 Routing Professional Reference' "For most private networks, the benefits = of=20 upgrading are not yet clear" Would you like to comment on = this?
=20

Q8, In you view, what will be the motivation for ISP's and = organisations=20 to change fully functional IPV4 implementations?
=20

Q9,Are you aware of new technologies that demand features of IPV6 = that=20 IPV4 does not offer?
=20

Q10, Are you aware of any new technologies that are IPV6 enabled=20 only?
=20

Q11, Do you have any further comments you wish to = make?
=20

Q12, If I have any question regarding your replies may I contact = you=20 again?
Yes
No

Q13, Would you like to receive a copy of the finished = report?
Yes
No
=20

------=_NextPart_000_0050_01C0857A.AC022560-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 23 12:41:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0NKabJ12946 for ipng-dist; Tue, 23 Jan 2001 12:36:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0NKZb212939 for ; Tue, 23 Jan 2001 12:35:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA13726 for ; Tue, 23 Jan 2001 12:35:20 -0800 (PST) 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 NAA03529 for ; Tue, 23 Jan 2001 13:35:19 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id OAA11002; Tue, 23 Jan 2001 14:35:17 -0600 (CST) Message-Id: <200101232035.OAA11002@gungnir.fnal.gov> To: "D. J. Bernstein" Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of Tue, 23 Jan 2001 20:02:47 GMT. <20010123200247.24320.qmail@cr.yp.to> Date: Tue, 23 Jan 2001 14:35:17 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan, Your message is incomplete. You failed to include the alternative scheme which would have made it impossible for a careless zone administrator to shoot himself in the foot. Also, note that server synthesis of address records would require a DNSSEC zone-signing key to be kept on-line, which would lead to widespread theft of keys and secured spoofing of DNS records. It's possible to do the synthesis in a somewhat less insecure "outboard" way with A6 just as with AAAA (at the cost of one extra byte per record) if desired. Finally, I point to 2874's text on glue, which includes [...] any of o a minimal set of A6 records duplicated from the X.EXAMPLE zone, o a (possibly smaller) set of records which collapse the structure of that minimal set, o or a set of A6 records with prefix length zero, giving the entire global addresses of the servers. The trade-off is ease of maintenance against robustness. The best and worst of both may be had together by implementing either the first or second option together with the third. Following this suggestion would turn your example into aol.com NS dns-01.ns.aol.com aol.com NS dns-02.ns.aol.com dns-01.ns.aol.com A6 prefix.aol.net A6 0 dns-02.ns.aol.com A6 prefix.aol.net A6 0 The full address is usable with no other data cached, and the broken-up record may save the day in *some* cases if the full-address record becomes incorrect while still "live". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 23 13:50:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0NLmfe13042 for ipng-dist; Tue, 23 Jan 2001 13:48:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0NLmU213035 for ; Tue, 23 Jan 2001 13:48:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA29024 for ; Tue, 23 Jan 2001 13:48:26 -0800 (PST) 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 NAA03575 for ; Tue, 23 Jan 2001 13:48:28 -0800 (PST) Received: (qmail 13882 invoked by uid 1001); 23 Jan 2001 21:47:40 -0000 Date: 23 Jan 2001 21:47:40 -0000 Message-ID: <20010123214740.28484.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010123200247.24320.qmail@cr.yp.to> <200101232035.OAA11002@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: > You failed to include the alternative scheme which would have made it > impossible for a careless zone administrator to shoot himself in the > foot. How can you call it ``careless'' for AOL to set up A6 records from *.aol.com to prefix.aol.net? Your spec encourages people to use A6 records this way. These records simply happen to interact badly with AOL's existing NS records to destroy AOL's reachability. Your ``alternative scheme'' is server-side indirection. The server provides full addresses. That's precisely my point: the reliability problems are an artifact of client-side indirection. You go on to complain about the occasional effort required for the server to sign records after renumbering. This complaint applies to your ``alternative scheme'' too. You haven't proposed any way to avoid this without creating reliability problems. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 23 14:43:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0NMgC013199 for ipng-dist; Tue, 23 Jan 2001 14:42:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0NMg0213192 for ; Tue, 23 Jan 2001 14:42:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA23584 for ; Tue, 23 Jan 2001 14:42:01 -0800 (PST) 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 PAA10707 for ; Tue, 23 Jan 2001 15:42:00 -0700 (MST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA11764; Tue, 23 Jan 2001 16:41:59 -0600 (CST) Message-Id: <200101232241.QAA11764@gungnir.fnal.gov> To: "D. J. Bernstein" Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: A6 benefits? In-reply-to: Your message of Fri, 19 Jan 2001 22:39:03 GMT. <20010119223903.26236.qmail@cr.yp.to> Date: Tue, 23 Jan 2001 16:41:59 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How many addresses has your site's DNS cache looked up in the past week? > How many different ISPs are involved? One thousand? Ten thousand? > > Client-side indirection means that you have to check every one of those > ISPs for changes. Server-side indirection means that you have to check > one ISP, namely yours, for changes. The frequency of checks per ISP is > somewhat higher for server-side than for client-side, but client-side > involves vastly more ISPs. Whoa! I think I detected a bogon. If you're setting TTLs in order to catch a site S renumbering within a time Tr, then compare the two cases Case 1: DNS master for S checks all the upstream prefixes and generates a set of complete address records for hosts in site S (be they AAAA or A6 with prefix len = 0). Case 2: The zone file for S indirects the prefixes at some level to data held by its upstream provider(s) using the A6 prefix name field. In case 1, the zone must bound the TTL of every address record by Tr. In case 2, the provider(s) must bound the TTL of their portion of the address by Tr. (Or, S's zone must provide an indirection with TTL bounded by Tr.) The A6 records owned directly by the host may have TTLs much longer that Tr, depending on what the site knows about its own habits and practices. So in case 1 clients of site S must re-fetch every address record they need at a frequency approximately 1/Tr. In case 2, they only need to fetch the common prefix record at the rate 1/Tr. > Bottom line: This is not a benefit for A6. Bottom line: there is such little experience with A6 that people's thinking is sometimes a bit muddy. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 23 17:53:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0O1qJZ13440 for ipng-dist; Tue, 23 Jan 2001 17:52:19 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0O1q8213433 for ; Tue, 23 Jan 2001 17:52:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1) with ESMTP id RAA01605 for ; Tue, 23 Jan 2001 17:52:08 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA11916 for ; Tue, 23 Jan 2001 17:52:07 -0800 (PST) Received: (qmail 3574 invoked by uid 1001); 24 Jan 2001 01:51:18 -0000 Date: 24 Jan 2001 01:51:18 -0000 Message-ID: <20010124015118.3340.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: <20010119223903.26236.qmail@cr.yp.to> <200101232241.QAA11764@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Crawford writes: > I think I detected a bogon. That's because you're not paying attention. Consider a future world with 10000000 sites, each with one DNS cache and a few DNS servers and a bunch of miscellaneous computers. Let's say each site looks up addresses at 10000 different ISPs every week. Client-side indirection, such as A6, means that those address lookups have to be supplemented by queries to all the ISPs. The cache sends at least one query per ISP every week, even if the TTLs are longer than that; caches don't (and shouldn't) save information for longer than a week. Total work: at least 100000000000 queries per week. Server-side indirection means that each site has to watch for changes at its own ISP. Ten queries per week will be more than enough even if we want to allow a change every day. Total work: at most 100000000 queries per week. Pushing, instead of pulling, would be even less expensive. How can anyone claim that 100000000 queries per week is ``more polling'' than 100000000000 queries per week? This is completely ridiculous. (I'm not saying that the traffic is noticeable either way.) > Bottom line: there is such little experience with A6 that people's > thinking is sometimes a bit muddy. Your thinking, for example. ---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 Jan 24 00:58:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0O8uAl13674 for ipng-dist; Wed, 24 Jan 2001 00:56:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0O8u1213667 for ; Wed, 24 Jan 2001 00:56:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24631 for ; Wed, 24 Jan 2001 00:56:01 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06687 for ; Wed, 24 Jan 2001 00:55:27 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0O8sAg05234; Wed, 24 Jan 2001 15:54:12 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? In-reply-to: Your message of "23 Jan 2001 19:29:23 GMT." <20010123192923.17892.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2001 15:54:10 +0700 Message-ID: <5232.980326450@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 23 Jan 2001 19:29:23 -0000 From: "D. J. Bernstein" Message-ID: <20010123192923.17892.qmail@cr.yp.to> | Renumbering is an example of the ``every problem can be solved by | another level of indirection'' principle. I've been asking why this | indirection should be in the _client_ rather than the _server_. I am aware of that. | So far, all I've heard is that (1) this might save more queries than it | wastes, even though the analogous assertion for MX records is not true, | and (2) this would occasionally save some DNSSEC CPU time. Whether it ends up being true or not depends upon how one configures the various records. And it isn't DNSSEC CPU time that is the issue, but the zone key. | I'm sorry, but I don't see server-side indirection discussed anywhere in | the IPNG archives. What exactly were the dates of the discussion? What | benefits were attributed to client-side indirection? As I said in the message to Jim, I don't even recall which WG it was discussed in. I'm away from home at the minute, and don't have my mailing list archives available - and where I am at the minute general net access is bad enough that the web rarely works (there's an enforced proxy cache which mostly times out before it manages to retrieve web pages...) It is possible it was discussed at a face to face WG meeting, rather than on the list (a list), though I really don't recall (but it was back in the middling days of when A6 was just an internet-draft). 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 Jan 24 01:18:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0O9HHw13713 for ipng-dist; Wed, 24 Jan 2001 01:17:17 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0O9H1213701 for ; Wed, 24 Jan 2001 01:17:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26318 for ; Wed, 24 Jan 2001 01:17:01 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA07277 for ; Wed, 24 Jan 2001 02:16:53 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0O9AUg05260; Wed, 24 Jan 2001 16:10:30 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of "23 Jan 2001 21:47:40 GMT." <20010123214740.28484.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Jan 2001 16:10:30 +0700 Message-ID: <5258.980327430@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 23 Jan 2001 21:47:40 -0000 From: "D. J. Bernstein" Message-ID: <20010123214740.28484.qmail@cr.yp.to> | Your ``alternative scheme'' is server-side indirection. Matt's scheme was server side indirection, but done by humans, not by the server. That solves the worst of the problems (how to sign the data) but introduces all the others that are typical of human maintained data. | You go on to complain about the occasional effort required for the | server to sign records after renumbering. It isn't the effort, it is access to the key that matters. If the server (software) is doing the indirection, the software needs access to the key, or it cannot sign the records. Software access to the key (on an on-line system like a DNS server) makes it available to other software to misappropriate. | This complaint applies to your | ``alternative scheme'' too. You haven't proposed any way to avoid this | without creating reliability problems. Not really - Matt's scheme gave two A6 record chains to the host. One of them might happen to contain an invalid address sometimes, if the server hasn't been updated with the new one yet. That address may turn out to be unreachable on occasion. Nothing different to what we have now really. It didn't have the server reaching out and building its own address. But if we stop postulating servers that are irrational about what glue they accept from where -- they're willing to take an NS, or A6 record, but not the glue necessary to make it work? The glue is less reliable than authoritative data, certainly, but simply refusing it out of hand is irrational - if the querying server (cache, resolver) doesn't have any better data available, it ought start by accepting the glue and using it, not just claiming "that isn't your data to give me" and ignoring it. If it wants, it can go verify the glue with an authoritative server after making use of it the first time. If clients can be expected to use the glue they're given, then the hard cases can mostly be gotten around by supplying appropriate glue from the server. Glue has been a part of the DNS from the beginning, invented precisely to get around the client side indirection in NS records. I wasn't around that far back, but I wouldn't be surprised if the client/server side argument wasn't held back then as well, and we know what the outcome of that obviously was. I have had about enough of this debate for now - we need to get some real experience of using A6 records, rather than theories of why they might not sometimes work. We know that NS and MX records work, despite client side indirection (even if it is possible to find some odd cases where the configuration is bad enough that it causes problems). Let's just find out whether A6 works or not. If it doesn't, we will change it, or drop it. If it does, they arguments based upon the theory of why it cannot possibly work (despite the evidence) can be put where they belong. 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 Jan 24 07:46:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0OFidH13865 for ipng-dist; Wed, 24 Jan 2001 07:44:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0OFiR213858 for ; Wed, 24 Jan 2001 07:44:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21123 for ; Wed, 24 Jan 2001 07:44:28 -0800 (PST) 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 HAA21646 for ; Wed, 24 Jan 2001 07:44:27 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA16177; Wed, 24 Jan 2001 09:44:14 -0600 (CST) Message-Id: <200101241544.JAA16177@gungnir.fnal.gov> To: "D. J. Bernstein" Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: A6 benefits? In-reply-to: Your message of Wed, 24 Jan 2001 01:51:18 GMT. <20010124015118.3340.qmail@cr.yp.to> Date: Wed, 24 Jan 2001 09:44:14 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I think I detected a bogon. > That's because you're not paying attention. Strike "not". > How can anyone claim that 100000000 queries per week is ``more polling'' > than 100000000000 queries per week? This is completely ridiculous. You're comparing apples to worms. In one case, you've counted the queries needed for each site to keep its own address records up to date, and in the other case you've counted the queries needed for each site to keep its cache of correspondent sites' addresses up to date. (Unless you meant that each site is a leaf on a 10000-deep tree of address delegations, which isn't possible with a 128 bit address.) Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 24 09:14:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0OHCxG13934 for ipng-dist; Wed, 24 Jan 2001 09:12:59 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0OHCl213927 for ; Wed, 24 Jan 2001 09:12:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27261 for ; Wed, 24 Jan 2001 09:12:45 -0800 (PST) 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 JAA09195 for ; Wed, 24 Jan 2001 09:12:46 -0800 (PST) Received: (qmail 10024 invoked by uid 1001); 24 Jan 2001 17:11:55 -0000 Date: 24 Jan 2001 17:11:55 -0000 Message-ID: <20010124171155.29022.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010123214740.28484.qmail@cr.yp.to> <5258.980327430@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > We know that NS and MX records work, I'd like to see you explain that to the owner of www.monty.de. As for your insane suggestion that caches should stop rejecting poison: That wouldn't save www.monty.de; servers don't even _try_ to provide out-of-bailiwick glue any more. For example, the .de servers don't know the addresses of the monty.de servers (in .norplex.net), and the .net servers don't know the addresses of the norplex.net servers (in .de). ---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 Jan 24 16:54:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0P0qQ214952 for ipng-dist; Wed, 24 Jan 2001 16:52:26 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0P0qM214945 for ; Wed, 24 Jan 2001 16:52:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0P0oLg03753 for ipng@sunroof.eng.sun.com; Wed, 24 Jan 2001 16:50:21 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0OFlu213876 for ; Wed, 24 Jan 2001 07:47:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21553 for ; Wed, 24 Jan 2001 07:47:57 -0800 (PST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29796 for ; Wed, 24 Jan 2001 07:47:56 -0800 (PST) Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23114 for ; Wed, 24 Jan 2001 10:47:55 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA23093 for ; Wed, 24 Jan 2001 10:47:55 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Jan 2001 16:47:53 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0AE619A5@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: =?iso-8859-1?Q?Peder_Chr=2E_N=F8rgaard?= Cc: ipng@sunroof.eng.sun.com Subject: RE: MLD MIB Date: Wed, 24 Jan 2001 16:47:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f0OFlv213877 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your comments. Comments/answers inline > ---------- > From: Peder Chr. N鴕gaard[SMTP:Peder.C.Norgaard@ted.ericsson.dk] > Sent: Tuesday, January 23, 2001 9:15 AM > To: Wijnen, Bert (Bert) > Cc: ipng@sunroof.eng.sun.com > Subject: Re: MLD MIB > > On Sun, 21 Jan 2001, Wijnen, Bert (Bert) wrote: > > > Date: Sun, 21 Jan 2001 23:38:56 +0100 > > From: "Wijnen, Bert (Bert)" > > To: ipng@sunroof.eng.sun.com > > Subject: MLD MIB > > > > All, > > > > The MLD MIB is close to being published as RFC. > > We found a few "editorial" changes that I am proposing to > > the RFC-Editor. Just so you know. If you have a real > > issue with it, then speak up very quickly. None of these > > changes change anything in terms of bytes on the wire > > or semantics. > > I have to disagree with the premises of this statement, if not the > conclusion. This change does indeed change the semantics of the > implementation, and also the value of the bytes on the wire. The > InterfaceIndex and the Ipv6IfIndex are two different numbering schemes, Oh... are they? Then pls explain the difference between these two definitions: >From IPv6-TC module: Ipv6IfIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique value, greater than zero for each internetwork-layer interface in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each internetwork-layer interface must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." SYNTAX Integer32 (1..2147483647) >From IF-MIB module: InterfaceIndex ::= TEXTUAL-CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "A unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." SYNTAX Integer32 (1..2147483647) They seem very much the same to me. And certainly, the data on the wire keeps to be an Integer32 with the same range!! The same is true for the other editorial changes. > and replacing the latter with the former forces changes in all > implementations. Cf discussion on the IPv6 Design Team homepage I do not see what needs to be changed in implementations. > . > That Design Team has been becoming active again, and they currently believe that it is best to get rid of Ipv6IfIndex. And they are looking at existing MIBs that use this TC to see what changes are needed. And they will soon submit I-Ds (I hope) to be discussed. > Unfortunately that discussion never reached a conclusion, so the MLD-MIB > designers do not really have any guidance in the choice between the two > schemes. Say, if the design team had concluded to do away with the > Ipv6IfIndex in the IPV6-MIB and friends, the MLD-MIB should of course do > the same. > > From my own position, the proposed change does not hurt, for I have not > completed the implementation of the MLD-MIB. But anyone with a working > implementation of MLD-MIB will have to modify code to adapt to this > change. > As I said I doubt they have to change much code (if any). All depends a bit on how an implementation was done. If anyone who implemented the MIB and who sees a big issue with this editorial change... pls scream. Bert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 24 16:54:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0P0rDa14961 for ipng-dist; Wed, 24 Jan 2001 16:53:13 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0P0r7214954 for ; Wed, 24 Jan 2001 16:53:08 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0P0p7L03783 for ipng@sunroof.eng.sun.com; Wed, 24 Jan 2001 16:51:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0OKoR214435 for ; Wed, 24 Jan 2001 12:50:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12172 for ; Wed, 24 Jan 2001 12:50:27 -0800 (PST) Received: from iproxy2.ericsson.dk (iproxy2.ericsson.dk [130.228.248.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01276 for ; Wed, 24 Jan 2001 13:50:25 -0700 (MST) Received: from dan.lmd.ericsson.se (dan.lmd.ericsson.se [192.66.3.254]) by iproxy2.ericsson.dk (8.10.1/8.10.1) with ESMTP id f0OKoGI11834; Wed, 24 Jan 2001 21:50:17 +0100 (MET) Received: from pcnp.ted.dk.eu.ericsson.se (IDENT:root@pcnp.ted.dk.eu.ericsson.se [192.66.4.157]) by dan.lmd.ericsson.se (8.10.1/8.10.1/LMDmain-3.0) with ESMTP id f0OKo9101894; Wed, 24 Jan 2001 21:50:10 +0100 (MET) Received: from localhost (pcn@localhost) by pcnp.ted.dk.eu.ericsson.se (8.10.1/8.10.1) with ESMTP id f0OKpac30822; Wed, 24 Jan 2001 21:51:36 +0100 Date: Wed, 24 Jan 2001 21:51:35 +0100 (CET) From: =?ISO-8859-1?Q?Peder_Chr=2E_N=F8rgaard?= X-Sender: To: "Wijnen, Bert (Bert)" cc: =?iso-8859-1?Q?Peder_Chr=2E_N=F8rgaard?= , Subject: RE: MLD MIB In-Reply-To: <2413FED0DFE6D111B3F90008C7FA61FB0AE619A5@nl0006exch002u.nl.lucent.com> 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 On Wed, 24 Jan 2001, Wijnen, Bert (Bert) wrote: > > > > I have to disagree with the premises of this statement, if not the > > conclusion. This change does indeed change the semantics of the > > implementation, and also the value of the bytes on the wire. The > > InterfaceIndex and the Ipv6IfIndex are two different numbering schemes, > Oh... are they? > Then pls explain the difference between these two definitions: Of course. I cut a bit to emphasize: > Ipv6IfIndex ::= TEXTUAL-CONVENTION : > "A unique value, greater than zero for each > internetwork-layer interface in the managed ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^ > InterfaceIndex ::= TEXTUAL-CONVENTION : > "A unique value, greater than zero, for each interface or ^^^^^^^^^ > interface sub-layer in the managed system. It is ^^^^^^^^^^^^^^^^^^^ I read this as the difference between layer 3 only and all layers. Certainly the InterfaceIndex covers all layers. And I find in the IPV6-MIB a mapping from Ipv6InterfaceIndex to the InterfaceIndex - the MIB object ipv6IfLowerLayer - that mapping is meaningless if the two values are supposed to be identical! This forced me to interpret the two TCs as representing two independent numbering schemes. > They seem very much the same to me. > And certainly, the data on the wire keeps to be an Integer32 with the > same range!! The same is true for the other editorial changes. Oh, yes, the *encoding* is identical. But if you - as I have done - has implemented IPV6-MIB according to abovementioned interpretation - the *values* are different. > > and replacing the latter with the former forces changes in all > > implementations. Cf discussion on the IPv6 Design Team homepage > I do not see what needs to be changed in implementations. > > > . > > > That Design Team has been becoming active again, and they currently > believe that it is best to get rid of Ipv6IfIndex. And they are looking at > existing MIBs that use this TC to see what changes are needed. And > they will soon submit I-Ds (I hope) to be discussed. That would please me - if this is to be done, it must be done soon. 'Cause that change *will* force me to change implementation. (no big deal, of course - actually a simplification.) > > > Unfortunately that discussion never reached a conclusion, so the MLD-MIB > > designers do not really have any guidance in the choice between the two > > schemes. Say, if the design team had concluded to do away with the > > Ipv6IfIndex in the IPV6-MIB and friends, the MLD-MIB should of course do > > the same. > > > > From my own position, the proposed change does not hurt, for I have not > > completed the implementation of the MLD-MIB. But anyone with a working > > implementation of MLD-MIB will have to modify code to adapt to this > > change. > > > As I said I doubt they have to change much code (if any). All depends a bit > on how an implementation was done. If anyone who implemented the MIB > and who sees a big issue with this editorial change... pls scream. Couldn't agree more. I'm not screaming. Just noticing :-) --peder chr. > Bert > -- Peder Chr. N鴕gaard Senior System Developer, M. Sc. Ericsson Telebit A/S tel: +45 89 38 52 53 Skanderborgvej 232 fax: +45 89 38 51 01 DK-8260 Viby J, Denmark mob: +45 21 28 66 58 e-mail: Peder.C.Norgaard@ted.ericsson.dk (old e-mail 1992-2000: pcn@tbit.dk) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 24 16:55:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0P0rpa14970 for ipng-dist; Wed, 24 Jan 2001 16:53:51 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0P0rh214963 for ; Wed, 24 Jan 2001 16:53:43 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0P0phS03813 for ipng@sunroof.eng.sun.com; Wed, 24 Jan 2001 16:51:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0P0kK214915 for ; Wed, 24 Jan 2001 16:46:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15758 for ; Wed, 24 Jan 2001 16:46:20 -0800 (PST) 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 QAA04113 for ; Wed, 24 Jan 2001 16:46:19 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14LaYM-0007xd-00 (Debian); Thu, 25 Jan 2001 00:46:18 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14LaYA-0003Uo-00 (Debian); Thu, 25 Jan 2001 00:46:06 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.30542.2143.389518@davenant.relativity.greenend.org.uk> Date: Thu, 25 Jan 2001 00:46:05 +0000 (GMT) To: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? Newsgroups: chiark.mail.ietf.ipng In-Reply-To: <20010119145843.60D1835C42@smb.research.att.com> References: <20010119145843.60D1835C42@smb.research.att.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven M. Bellovin writes ("Re: A6 benefits? "): > In message <20010118090114.3487.qmail@cr.yp.to>, "D. J. Bernstein" writes: > >Is there some other claimed benefit of A6? > > Apart from not wanting more polling, the idea is to facilitate rapid > renumbering. When I described A6 to someone recently they said they thought it was so that you could renumber entire networks automatically based on core topology changes without the relevant leaf network admins' having to do anything. At the time I dismissed this idea as absurd; we have enough reliability problems as it is without large sites and networks being made unuseable even internally because someone somewhere at a different organisation made a mistake in a configuration and causes the DNS to start giving out wrong addresses. I haven't seen much motivation for A6 in the relevant RFCs and I-Ds, so perhaps I'm barking up the wrong tree - in any case, some explanation of why this is a good thing and how it is expected to be used would be helpful. Alternatively, perhaps I'm wrong and it is indeed the intent of the IPNG working groups that renumbering could happen entirely automatically, and need not involve an action by the administrator of the site being renumbered. If so I have to say I'm rather alarmed, but perhaps I've missed some vital reason why this is a good idea. On the other hand, I can't see another good reason for A6. After all, if renumbering is going to require an administrative action by the people who run the site being renumbered, they might as well use the entirely normal and standard zone changing mechanisms to do it. If an admin feels that doing a search-and-replace on their zone files is too difficult or error-prone, then they can easily use one of any number of tools to help them generate the zone files semiautomatically so that they only have to configure the network number in one place. If renumbering is too frequent to do like that (more than once a month, say) then I'm sure people will develop software to help manage it, and perhaps there would be a role for an IETF protocol for doing so in a secure and reliable way. So the whole thing leaves me very confused: either A6 is part of something that to me at the moment looks like a mad scheme (with all due respect to the people that thought it up), or it's a way to stop it from being difficult to be an IPv6 DNS administrator even if you're too lazy to find a Perl script and too stupid to write one. > AAAA is especially problematic if DNSSEC is used, since that would > require resigning the entire zone -- and that's expensive. It seems to me that renumbering your entire network, which will involve reconfiguring and possibly breaking zillions of machines, adjusting firewalls, etc. etc., is *exactly* the kind of thing that security mechanisms should be controlling. Complaining that the security mechanisms make it too difficult, or hard for third parties to do, seems to be missing the point rather. 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 Wed Jan 24 17:28:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0P1RQ015106 for ipng-dist; Wed, 24 Jan 2001 17:27:26 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0P1RM215099 for ; Wed, 24 Jan 2001 17:27:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0P1PLr03878 for ipng@sunroof.eng.sun.com; Wed, 24 Jan 2001 17:25:21 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0P0sj214983 for ; Wed, 24 Jan 2001 16:54:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18268 for ; Wed, 24 Jan 2001 16:54:45 -0800 (PST) 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 QAA08586 for ; Wed, 24 Jan 2001 16:54:44 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14LagW-0008Ex-00 (Debian); Thu, 25 Jan 2001 00:54:44 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14LagV-0003W2-00 (Debian); Thu, 25 Jan 2001 00:54:43 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14959.31058.968358.725864@davenant.relativity.greenend.org.uk> Date: Thu, 25 Jan 2001 00:54:42 +0000 (GMT) To: ipng@sunroof.eng.sun.com Subject: Re: A6 unreliability Newsgroups: chiark.mail.ietf.ipng In-Reply-To: <20010118091340.20931.qmail@cr.yp.to> References: <20010118091340.20931.qmail@cr.yp.to> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk D. J. Bernstein writes ("A6 unreliability"): > * DNAME exacerbates all the problems of CNAME. DNAMEs can be wrapped > inside DNAMEs---and this is _encouraged_! We'll have people setting > up huge CNAME/DNAME chains to match their corporate structures. Quite. I can't see any excuse for DNAME, frankly. The only positive effect of DNAME I can think of at the moment is that it might produce a bit of extra caching commonality. But, this is only relevant if a DNAME is made of large domain and *many* of the records in the DNAME domain are used. In return for this we get all of the reliability problems Dan mentioned, not to mention the fact that DNAME processing is quite a complex task even under favourable conditions and implementations are bound to be buggy, have security problems, etc. 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 Jan 25 01:44:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0P9gW415575 for ipng-dist; Thu, 25 Jan 2001 01:42:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0P9gN215568 for ; Thu, 25 Jan 2001 01:42:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18779 for ; Thu, 25 Jan 2001 01:42:23 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03970 for ; Thu, 25 Jan 2001 01:42:15 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0P9fH902885; Thu, 25 Jan 2001 16:41:26 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of "24 Jan 2001 17:11:55 GMT." <20010124171155.29022.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 16:41:17 +0700 Message-ID: <2883.980415677@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 24 Jan 2001 17:11:55 -0000 From: "D. J. Bernstein" Message-ID: <20010124171155.29022.qmail@cr.yp.to> | Robert Elz writes: | > We know that NS and MX records work, | I'd like to see you explain that to the owner of www.monty.de. I didn't say it wasn't possible to configure them to not work. I said that they work usually, with any sane configuration. The wild bouncing of delegations between .DE and .NET that exists in that case is just too absurd for belief. To the owner of www.monty.de I'd simply suggest that they go find an ISP who has half a clue how to set up DNS delegations that work in practice. Let those who don't just vanish from the scene. | As for your insane suggestion that caches should stop rejecting poison: | That wouldn't save www.monty.de; servers don't even _try_ to provide | out-of-bailiwick glue any more. For example, the .de servers don't know | the addresses of the monty.de servers (in .norplex.net), and the .net | servers don't know the addresses of the norplex.net servers (in .de). Yes, there does seem to have been rather a "going overboard" on avoiding glue recently. This is an unfortunate effect of the way the IETF and the markets work - anything that is ever seen as having some kind of bad effects (in almost any circumstances) is condemned. Then all traces of that are likely to be burned at the stake, whether good of bad, needed or not. It used to be that servers (caches really) would believe any old glue from anywhere, and treat it as valuable as authoritative data direct from an authoritative server. That was obviously stupid. So, that gets fixed, fine. But because we can't trust people to upgrade their old servers (caches) and we have to save them from themselves, we also "fix" the servers to not send any glue, except when it is obvious from simple inspection that it must be required. It has long been known that delegations each of which name the other's servers breaks with this overly restrictive glue methodology. If a server knows the address records (which includes any case where they have been configured into it) it should be sending them as the DNS specs call for. Then if the recipient of that information decides that it has better information that it would prefer to use (or would prefer to obtain more reliable information from elsewhere) that's its choice. 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 Jan 25 01:52:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0P9pmq15615 for ipng-dist; Thu, 25 Jan 2001 01:51:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0P9pd215608 for ; Thu, 25 Jan 2001 01:51:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19468 for ; Thu, 25 Jan 2001 01:51:38 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11663 for ; Thu, 25 Jan 2001 01:51:31 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0P9oI902909; Thu, 25 Jan 2001 16:50:18 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of "24 Jan 2001 17:11:55 GMT." <20010124171155.29022.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 16:50:18 +0700 Message-ID: <2907.980416218@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 24 Jan 2001 17:11:55 -0000 From: "D. J. Bernstein" Message-ID: <20010124171155.29022.qmail@cr.yp.to> | I'd like to see you explain that to the owner of www.monty.de. ps:... brandenburg$ dig www.monty.de. a ; <<>> DiG 8.2 <<>> www.monty.de. a ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; www.monty.de, type = A, class = IN ;; ANSWER SECTION: www.monty.de. 1D IN CNAME monty.de. monty.de. 1D IN A 151.189.12.194 ;; AUTHORITY SECTION: monty.de. 1D IN NS ns.norplex.net. monty.de. 1D IN NS ns2.norplex.net. ;; ADDITIONAL SECTION: ns.norplex.net. 1D IN A 151.189.12.193 ns2.norplex.net. 1D IN A 151.189.26.234 ;; Total query time: 1850 msec ;; FROM: brandenburg.cs.mu.OZ.AU to SERVER: default -- 192.100.77.5 ;; WHEN: Thu Jan 25 16:44:35 2001 ;; MSG SIZE sent: 30 rcvd: 146 The RTT from where I am at the minute to most of the world is 800ms approx (or more): PING ns.uu.net (137.39.1.3): 56 data bytes 64 bytes from 137.39.1.3: icmp_seq=1 ttl=235 time=791.274 ms 64 bytes from 137.39.1.3: icmp_seq=2 ttl=235 time=771.218 ms 64 bytes from 137.39.1.3: icmp_seq=3 ttl=235 time=828.094 ms so to find that A record, all that could have been needed (in practice) was just 2 round trips... (to get into Germany if that was ever actually needed would take longer per round trip). So, in practice, I suspect that the owner of we.monty.de is probably not too worried, despite the absurd setup of the various nameservers that leads to that domain. Note that the answer had the AA bit set - it didn't just appear out of some local cache. 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 Jan 25 02:34:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PAXPg15665 for ipng-dist; Thu, 25 Jan 2001 02:33:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PAXE215658 for ; Thu, 25 Jan 2001 02:33:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23182 for ; Thu, 25 Jan 2001 02:33:13 -0800 (PST) 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 CAA01681 for ; Thu, 25 Jan 2001 02:33:12 -0800 (PST) Received: (qmail 16499 invoked by uid 1001); 25 Jan 2001 10:32:27 -0000 Date: 25 Jan 2001 10:32:27 -0000 Message-ID: <20010125103227.23223.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010124171155.29022.qmail@cr.yp.to> <2907.980416218@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 Here's what the bind-users report said about www.monty.de: ``I recently had to explain to customers that no it's not our fault that our name servers can't resolve that name. And by the way, no it doesn't work on the second try or the third.'' C'mon, everybody, try it! Ask your cache for the www.monty.de address. I tried several BIND caches; they all failed. I've already explained in detail how much work dnscache has to go through to find the address. Elz seems to understand that the www.monty.de disaster is a powerful argument against the relevant aspects of the DNS design. So now he's denying the facts. He wants you to believe that www.monty.de is okay. Robert Elz writes: > ;; Total query time: 1850 msec That's nice. Try again from an empty cache. > Note that the answer had the AA bit set - it didn't just appear out > of some local cache. Don't be an idiot. That packet is straight from {ns,ns2}.norplex.net. What you had in your cache was the addresses of those servers. > so to find that A record, all that could have been needed (in practice) > was just 2 round trips... Don't be an idiot. In practice, most caches don't have the *.norplex.net addresses lying around when they are asked about www.monty.de. ---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 Jan 25 03:46:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PBiTO15701 for ipng-dist; Thu, 25 Jan 2001 03:44:29 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PBiJ215694 for ; Thu, 25 Jan 2001 03:44:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05382 for ; Thu, 25 Jan 2001 03:44:19 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11597 for ; Thu, 25 Jan 2001 03:44:15 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0PBgm903392; Thu, 25 Jan 2001 18:42:48 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of "25 Jan 2001 10:32:27 GMT." <20010125103227.23223.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Jan 2001 18:42:48 +0700 Message-ID: <3390.980422968@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 25 Jan 2001 10:32:27 -0000 From: "D. J. Bernstein" Message-ID: <20010125103227.23223.qmail@cr.yp.to> | Elz seems to understand that the www.monty.de disaster is a powerful | argument against the relevant aspects of the DNS design. So now he's | denying the facts. He wants you to believe that www.monty.de is okay. No I don't. Read the messages). Their setup is bogus (and probably not directly their fault - other than by choosing an inept ISP). The difference is that you're arguing that because it is possible to abuse the delegation process, the process should be changed. On the other hand I say that most of the time it all works just fine, and that altering the process because of a few hard cases (I'm sure you can find more than just this one if you look) is the wrong attitude. There are millions of delegations that work just fine - they all could work just fine if configured rationally. | Don't be an idiot. That packet is straight from {ns,ns2}.norplex.net. | What you had in your cache was the addresses of those servers. Yes, most likely. As I said, in practice, accesses to that name probably work well enough that the name owner isn't too bothered about it. The setup is still bogus, and should be fixed though. If the owner of the domain were worried, the correct recourse would be to change to an ISP that knows how to setup the DNS properly (or at least has lucked upon something that is adequate). | Don't be an idiot. In practice, most caches don't have the *.norplex.net | addresses lying around when they are asked about www.monty.de. They probably do, if they're asked about the name often enough for it to matter. If you start at a clean cache and ask once, you're probably right, it will fail. The vast majority of the users probably don't even give that a second thought - things failing is somehow treated as "normal". So they try again - and by this time the cache has more info, either enough for it to succeed, or at least get a lot further (and then perhaps third time lucky). And no, this is not good - but it is because the delegation system has been abused. And no, I do not think we need to make the system idiot proof. And I also don't know of any way of doing server side indirection that would both be any better (which means that human maintenance is out of the question) and actually implementable the way the DNS should be working (the difficulty of signing a record the server invents out of other data makes it a non-trivial problem). 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 Jan 25 07:04:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PF0XT15923 for ipng-dist; Thu, 25 Jan 2001 07:00:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PF0L215916 for ; Thu, 25 Jan 2001 07:00:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16212 for ; Thu, 25 Jan 2001 07:00:21 -0800 (PST) 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 HAA27440 for ; Thu, 25 Jan 2001 07:00:20 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA22493 for ; Thu, 25 Jan 2001 09:00:19 -0600 (CST) Message-Id: <200101251500.JAA22493@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" X-Warning-For-Humor-Impaired: implicit Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of Thu, 25 Jan 2001 18:42:48 +0700. <3390.980422968@brandenburg.cs.mu.OZ.AU> Date: Thu, 25 Jan 2001 09:00:19 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So they try again - and by this time the cache has more info, > either enough for it to succeed, or at least get a lot further (and > then perhaps third time lucky). (I got it on the third try, starting from nothing cached.) But let me bring up a related problem ... I've had occasions of users (and servers) here that couldn't communicate because they had screwed up their default route and/or netmask. Obviously setting these parameters is an error-prone procedure that leads to operational instability. Even DHCP is not a reliable solution because the server gets its information from human hands. What I've implemented on all our systems and routers is much more robust and I think it should be added to a new rev of the host & router requirements docs immediately: Every host sending a packet SHALL encapsulate that packet using the appropriate IP-in-IP header and send it to the all-routers multicast address. Routers receiving such a packet SHALL decapsulate and forward it. Sure, this leads to some duplicatation, but that's allowed by the IP spec. It does prevent the occasional configuration error from stopping the communication. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 25 07:48:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PFkvr16018 for ipng-dist; Thu, 25 Jan 2001 07:46:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PFkm216011 for ; Thu, 25 Jan 2001 07:46:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22601 for ; Thu, 25 Jan 2001 07:46:48 -0800 (PST) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13826 for ; Thu, 25 Jan 2001 07:46:37 -0800 (PST) Received: from exchsvr.digi-data.com ([10.1.1.11]) by odin.digi-data.com with ESMTP id <15537>; Fri, 26 Jan 2001 18:48:37 -0400 Received: from digi-data.com (ALEPH2 [10.1.1.23]) by exchsvr.digi-data.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id D1J703VZ; Thu, 25 Jan 2001 11:45:48 -0400 Message-ID: <3A704C3F.6A0D7732@digi-data.com> Date: Thu, 25 Jan 2001 11:54:39 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Matt Crawford , IPng Mailing List Subject: Re:Proposed host and router requirements revision (WAS: An easy example of A6 unreliability) References: <200101251500.JAA22493@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Matt Crawford, You said, > What I've implemented on all our systems and routers is much more > robust and I think it should be added to a new rev of the host & > router requirements docs immediately: > > Every host sending a packet SHALL encapsulate that packet using > the appropriate IP-in-IP header and send it to the all-routers > multicast address. Routers receiving such a packet SHALL > decapsulate and forward it. > > Sure, this leads to some duplicatation, but that's allowed by the IP > spec. It does prevent the occasional configuration error from > stopping the communication. Your wording seems to indicate to me that that SHALL is to be interpreted as MUST. To me that is disagreeable, as it punishes properly configured nodes as badly as incorrectly nodes. Perhaps the behaviour you recommend should be set as a default for hosts and routers and giving the operators some kind of mechanism to change that default behaviour. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 25 10:23:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PILqE16393 for ipng-dist; Thu, 25 Jan 2001 10:21:52 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PILj216378 for ; Thu, 25 Jan 2001 10:21:45 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0PIJhL04011 for ipng@sunroof.eng.sun.com; Thu, 25 Jan 2001 10:19:43 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PE4O215843 for ; Thu, 25 Jan 2001 06:04:25 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15946 for ; Thu, 25 Jan 2001 06:04:25 -0800 (PST) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25723 for ; Thu, 25 Jan 2001 06:04:22 -0800 (PST) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.1/8.11.1) with ESMTP id f0PE4sN00760; Fri, 26 Jan 2001 01:05:00 +1100 (EST) (envelope-from marka@nominum.com) Message-Id: <200101251405.f0PE4sN00760@drugs.dv.isc.org> To: "D. J. Bernstein" Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@nominum.com Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of "25 Jan 2001 10:32:27 -0000." <20010125103227.23223.qmail@cr.yp.to> Date: Fri, 26 Jan 2001 01:04:54 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan stop assuming things about BIND 9's behaviour based on BIND 8's behaviour. We have said many times that there are architectual flaws in BIND 8. BIND 9 was written from scratch to get around those problems. The server in question is running BIND 9.1. The elasped time also includes retries due to EDNS probes. drugs# ps ax | grep named 150 ?? Ss 0:00.77 /usr/local/sbin/named 719 p0 S+ 0:00.00 grep named drugs# kill 150 drugs# /usr/local/sbin/named drugs# dig www.monty.de ; <<>> DiG 8.3 <<>> www.monty.de ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUERY SECTION: ;; www.monty.de, type = A, class = IN ;; ANSWER SECTION: www.monty.de. 1D IN CNAME monty.de. monty.de. 1D IN A 151.189.12.194 ;; AUTHORITY SECTION: monty.de. 1D IN NS ns2.norplex.net. monty.de. 1D IN NS ns.norplex.net. ;; ADDITIONAL SECTION: ns.norplex.net. 23h59m58s IN A 151.189.12.193 ns2.norplex.net. 23h59m58s IN A 151.189.26.234 ;; Total query time: 6887 msec ;; FROM: drugs.dv.isc.org to SERVER: default -- 127.0.0.1 ;; WHEN: Fri Jan 26 00:36:21 2001 ;; MSG SIZE sent: 30 rcvd: 138 drugs# Now with A6 and DNSSEC stub resolvers are being pushed as both potentialy require a deal of work to be performed before a answer is returned. A full service resolver is much better suited to dealing with A6 and DNSSEC. With A6 you *can* follow all the address delegations but you don't *have* to. Personally I expect sites to be too paraniod to have chains that go outside their administrative control and you will, likely as not, get the full chain returned. Mark > Here's what the bind-users report said about www.monty.de: ``I recently > had to explain to customers that no it's not our fault that our name > servers can't resolve that name. And by the way, no it doesn't work on > the second try or the third.'' > > C'mon, everybody, try it! Ask your cache for the www.monty.de address. > I tried several BIND caches; they all failed. I've already explained in > detail how much work dnscache has to go through to find the address. > > Elz seems to understand that the www.monty.de disaster is a powerful > argument against the relevant aspects of the DNS design. So now he's > denying the facts. He wants you to believe that www.monty.de is okay. > > Robert Elz writes: > > ;; Total query time: 1850 msec > > That's nice. Try again from an empty cache. > > > Note that the answer had the AA bit set - it didn't just appear out > > of some local cache. > > Don't be an idiot. That packet is straight from {ns,ns2}.norplex.net. > What you had in your cache was the addresses of those servers. > > > so to find that A record, all that could have been needed (in practice) > > was just 2 round trips... > > Don't be an idiot. In practice, most caches don't have the *.norplex.net > addresses lying around when they are asked about www.monty.de. > > ---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 > -------------------------------------------------------------------- -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 25 11:42:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PJfc516566 for ipng-dist; Thu, 25 Jan 2001 11:41:39 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PJfY216559 for ; Thu, 25 Jan 2001 11:41:34 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0PJdXL04243 for ipng@sunroof.eng.sun.com; Thu, 25 Jan 2001 11:39:33 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PJcp216524 for ; Thu, 25 Jan 2001 11:38:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02085 for ; Thu, 25 Jan 2001 11:38:51 -0800 (PST) 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 LAA15803 for ; Thu, 25 Jan 2001 11:38:48 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14LsEI-0005on-00 (Debian); Thu, 25 Jan 2001 19:38:46 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14LsEH-0000kU-00 (Debian); Thu, 25 Jan 2001 19:38:45 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14960.32965.273622.945296@davenant.relativity.greenend.org.uk> Date: Thu, 25 Jan 2001 19:38:45 +0000 (GMT) To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability Newsgroups: chiark.mail.ietf.ipng In-Reply-To: <200101251405.f0PE4sN00760@drugs.dv.isc.org> References: <20010125103227.23223.qmail@cr.yp.to> <200101251405.f0PE4sN00760@drugs.dv.isc.org> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark.Andrews@nominum.com writes ("Re: An easy example of A6 unreliability "): > With A6 you *can* follow all the address delegations but > you don't *have* to. Personally I expect sites to be too > paraniod to have chains that go outside their administrative > control and you will, likely as not, get the full chain > returned. In which case A6 degenerates into an extremely complicated, special-purpose and generally badly-designed macro substitution feature. Surely that isn't the kind of thing that anyone would want in an IETF protocol. So we must conclude that the people who think A6 is a good idea must have some other reason. What is that reason ? 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 Jan 25 12:55:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PKrE516715 for ipng-dist; Thu, 25 Jan 2001 12:53:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PKr4216708 for ; Thu, 25 Jan 2001 12:53:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24592 for ; Thu, 25 Jan 2001 12:53:03 -0800 (PST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07525 for ; Thu, 25 Jan 2001 13:53:02 -0700 (MST) Received: from df-virus1.platinum.corp.microsoft.com ([172.30.236.36]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 25 Jan 2001 08:36:34 -0800 Received: from 172.30.236.11 by df-virus1.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 25 Jan 2001 08:37:19 -0800 (Pacific Standard Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Thu, 25 Jan 2001 08:37:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 content-class: urn:content-classes:message Subject: RE: A6 benefits? MIME-Version: 1.0 Date: Thu, 25 Jan 2001 08:37:18 -0800 Content-Type: text/plain; charset="us-ascii" Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A6 benefits? Thread-Index: AcCGabgVqWLzTl80ThewWabnE8z2OwAgM+Sg From: "Christian Huitema" To: "Ian Jackson" , X-OriginalArrivalTime: 25 Jan 2001 16:37:18.0883 (UTC) FILETIME=[1548AF30:01C086ED] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f0PKr5216709 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The motivation for A6 is the key database paradigm that atomic information (e.g. a site prefix) should be stored exactly once. This has major consequences on ease of update, as well as caching. The ease of update argument is clear: it is simpler to update one record for a large site than to update all records for all nodes in the site; this is particularly true when the use of DNS security increases wildly the cost of any given update. The caching argument is also a natural consequence of the "atomic information" property: each component of the information can be given an appropriate TTL, which means that information that does not change, such as the lower bits of a node's address, can be stored with a longer TTL than the site's prefix. The DNS is basically a distributed database; database theory applies; storing atomic information exactly once is a basic tenet of database theory; the A6 design is a direct consequence of the theory. Jim, Randy and some other have made the argument that A6 would increase the load on the DNS, by requiring several transaction for any given exchange. This type of argument, however, does not take caching into account. Prefixes are common to several nodes; the probability that a prefix information will be cached increases for prefixes that are closer to the root. If I am looking for the address of "node.example.com", and I am returned an A6 that contains the node identifier and a reference to "site-prefix.example.com", there are some serious chances that the A6 record for "site-prefix" is already present in my local cache. This is specially true if the requesting node is itself a member of the example.com domain. We did in fact have this discussion in depth 2 years ago, when we submitted the draft to the working group. The arguments on each side of the issue have not changed. Usage examples showed that the DNS load would be lessened, not increased, if we did caching right, and that the total amount of information required to encode the addressing data for a site would be lessened, not increased, in the case of multi-homed site. In short, the A6 design trades off some additional design complexity for a lesser management load and a lesser use of DNS resource when either renumbering or multi-homing are frequent. -- Christian Huitema > -----Original Message----- > From: Ian Jackson [mailto:ian@davenant.greenend.org.uk] > Sent: Wednesday, January 24, 2001 4:46 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: A6 benefits? > > > Steven M. Bellovin writes ("Re: A6 benefits? "): > > In message <20010118090114.3487.qmail@cr.yp.to>, "D. J. > Bernstein" writes: > > >Is there some other claimed benefit of A6? > > > > Apart from not wanting more polling, the idea is to > facilitate rapid > > renumbering. > > When I described A6 to someone recently they said they thought it was > so that you could renumber entire networks automatically based on core > topology changes without the relevant leaf network admins' having to > do anything. > > At the time I dismissed this idea as absurd; we have enough > reliability problems as it is without large sites and networks being > made unuseable even internally because someone somewhere at a > different organisation made a mistake in a configuration and causes > the DNS to start giving out wrong addresses. > > I haven't seen much motivation for A6 in the relevant RFCs and I-Ds, > so perhaps I'm barking up the wrong tree - in any case, some > explanation of why this is a good thing and how it is expected to be > used would be helpful. > > Alternatively, perhaps I'm wrong and it is indeed the intent of the > IPNG working groups that renumbering could happen entirely > automatically, and need not involve an action by the administrator of > the site being renumbered. If so I have to say I'm rather alarmed, > but perhaps I've missed some vital reason why this is a good idea. > > On the other hand, I can't see another good reason for A6. After all, > if renumbering is going to require an administrative action by the > people who run the site being renumbered, they might as well use the > entirely normal and standard zone changing mechanisms to do it. > > If an admin feels that doing a search-and-replace on their zone files > is too difficult or error-prone, then they can easily use one of any > number of tools to help them generate the zone files semiautomatically > so that they only have to configure the network number in one place. > If renumbering is too frequent to do like that (more than once a > month, say) then I'm sure people will develop software to help manage > it, and perhaps there would be a role for an IETF protocol for doing > so in a secure and reliable way. > > So the whole thing leaves me very confused: either A6 is part of > something that to me at the moment looks like a mad scheme (with all > due respect to the people that thought it up), or it's a way to stop > it from being difficult to be an IPv6 DNS administrator even if you're > too lazy to find a Perl script and too stupid to write one. > > > AAAA is especially problematic if DNSSEC is used, since that would > > require resigning the entire zone -- and that's expensive. > > It seems to me that renumbering your entire network, which will > involve reconfiguring and possibly breaking zillions of machines, > adjusting firewalls, etc. etc., is *exactly* the kind of thing that > security mechanisms should be controlling. > > Complaining that the security mechanisms make it too difficult, or > hard for third parties to do, seems to be missing the point rather. > > 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 Jan 25 13:03:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PL00n16747 for ipng-dist; Thu, 25 Jan 2001 13:00:00 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PKxk216740 for ; Thu, 25 Jan 2001 12:59:47 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28569 for ; Thu, 25 Jan 2001 12:59:44 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA19923 for ; Thu, 25 Jan 2001 12:59:43 -0800 (PST) Received: (qmail 6098 invoked by uid 1001); 25 Jan 2001 19:12:39 -0000 Date: 25 Jan 2001 19:12:39 -0000 Message-ID: <20010125191239.5792.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010125103227.23223.qmail@cr.yp.to> <3390.980422968@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 Apparently Elz tried again from an empty cache and was unable to resolve the www.monty.de address. Robert Elz writes: > Their setup is bogus Please explain why the www.monty.de configuration is ``bogus.'' Which records should have been set up differently? The A6 examples in RFC 2874 have tons of gluelessness too; are they ``bogus''? ---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 Jan 25 13:14:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PLBvd16802 for ipng-dist; Thu, 25 Jan 2001 13:11:57 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PLBm216795 for ; Thu, 25 Jan 2001 13:11:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22427 for ; Thu, 25 Jan 2001 13:11:47 -0800 (PST) From: Jim.Bound@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26120 for ; Thu, 25 Jan 2001 13:11:46 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0PLD2614009 for ; Thu, 25 Jan 2001 15:13:02 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 25 Jan 2001 15:11:32 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 25 Jan 2001 15:06:31 -0600 Message-ID: To: huitema@exchange.microsoft.com, ian@davenant.greenend.org.uk, ipng@sunroof.eng.sun.com Subject: RE: A6 benefits? Date: Thu, 25 Jan 2001 15:01:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, >From a computer science perspective you are correct and theoretically you are correct. But database technology that has a performance cost greater than its advantage will not be deployed and users will reject it. None of us are completely against all cases of A6 and completely understand the benefits you site (they were true back in the very old days of OLTP for distributed systems so the theory is not new). I am hearing three complaints all I agree with as a note: 1. Client DNS implementations today are not equipped to cache lets say greater than 3 levels of A6 hierarchy. 2. Lets discuss the model of letting servers do the caching of A6 records and leave clients out of this performance pain as the servers also have the ability to process much better this distributed database concept you site. 3. Dan B has provided a model in other mail that the queries for servers with some change to the indirection model for A6 will improve the performance of A6 records and again leave the client out of loop. 4. Several of us deploying IPv6 do not want to hold up the show till we get the A6 method right (ergo deployment) and to perform for our customers adequately and suggest just using AAAA records for now for deployment. We did not have the implementation experience we have now two years ago. I would argue that whats happening is what many of us told the IETF would happen so I think it totally fair and correct that we revisit this issue with the scientific data we have now to beg the question is A6 ready or not. Should we put some controls on its use and deployment. But we don't have to do that for like reasons above with AAAA records. regards, /jim > -----Original Message----- > From: ext Christian Huitema [mailto:huitema@exchange.microsoft.com] > Sent: Thursday, January 25, 2001 11:37 AM > To: Ian Jackson; ipng@sunroof.eng.sun.com > Subject: RE: A6 benefits? > > > The motivation for A6 is the key database paradigm that atomic > information (e.g. a site prefix) should be stored exactly > once. This has > major consequences on ease of update, as well as caching. The ease of > update argument is clear: it is simpler to update one record > for a large > site than to update all records for all nodes in the site; this is > particularly true when the use of DNS security increases > wildly the cost > of any given update. The caching argument is also a natural > consequence > of the "atomic information" property: each component of the > information > can be given an appropriate TTL, which means that information > that does > not change, such as the lower bits of a node's address, can be stored > with a longer TTL than the site's prefix. The DNS is basically a > distributed database; database theory applies; storing atomic > information exactly once is a basic tenet of database theory; the A6 > design is a direct consequence of the theory. > > Jim, Randy and some other have made the argument that A6 > would increase > the load on the DNS, by requiring several transaction for any given > exchange. This type of argument, however, does not take caching into > account. Prefixes are common to several nodes; the probability that a > prefix information will be cached increases for prefixes that > are closer > to the root. If I am looking for the address of > "node.example.com", and > I am returned an A6 that contains the node identifier and a > reference to > "site-prefix.example.com", there are some serious chances that the A6 > record for "site-prefix" is already present in my local cache. This is > specially true if the requesting node is itself a member of the > example.com domain. > > We did in fact have this discussion in depth 2 years ago, when we > submitted the draft to the working group. The arguments on > each side of > the issue have not changed. Usage examples showed that the DNS load > would be lessened, not increased, if we did caching right, > and that the > total amount of information required to encode the addressing > data for a > site would be lessened, not increased, in the case of > multi-homed site. > In short, the A6 design trades off some additional design > complexity for > a lesser management load and a lesser use of DNS resource when either > renumbering or multi-homing are frequent. > > -- Christian Huitema > > > -----Original Message----- > > From: Ian Jackson [mailto:ian@davenant.greenend.org.uk] > > Sent: Wednesday, January 24, 2001 4:46 PM > > To: ipng@sunroof.eng.sun.com > > Subject: Re: A6 benefits? > > > > > > Steven M. Bellovin writes ("Re: A6 benefits? "): > > > In message <20010118090114.3487.qmail@cr.yp.to>, "D. J. > > Bernstein" writes: > > > >Is there some other claimed benefit of A6? > > > > > > Apart from not wanting more polling, the idea is to > > facilitate rapid > > > renumbering. > > > > When I described A6 to someone recently they said they > thought it was > > so that you could renumber entire networks automatically > based on core > > topology changes without the relevant leaf network admins' having to > > do anything. > > > > At the time I dismissed this idea as absurd; we have enough > > reliability problems as it is without large sites and networks being > > made unuseable even internally because someone somewhere at a > > different organisation made a mistake in a configuration and causes > > the DNS to start giving out wrong addresses. > > > > I haven't seen much motivation for A6 in the relevant RFCs and I-Ds, > > so perhaps I'm barking up the wrong tree - in any case, some > > explanation of why this is a good thing and how it is expected to be > > used would be helpful. > > > > Alternatively, perhaps I'm wrong and it is indeed the intent of the > > IPNG working groups that renumbering could happen entirely > > automatically, and need not involve an action by the > administrator of > > the site being renumbered. If so I have to say I'm rather alarmed, > > but perhaps I've missed some vital reason why this is a good idea. > > > > On the other hand, I can't see another good reason for A6. > After all, > > if renumbering is going to require an administrative action by the > > people who run the site being renumbered, they might as well use the > > entirely normal and standard zone changing mechanisms to do it. > > > > If an admin feels that doing a search-and-replace on their > zone files > > is too difficult or error-prone, then they can easily use one of any > > number of tools to help them generate the zone files > semiautomatically > > so that they only have to configure the network number in one place. > > If renumbering is too frequent to do like that (more than once a > > month, say) then I'm sure people will develop software to > help manage > > it, and perhaps there would be a role for an IETF protocol for doing > > so in a secure and reliable way. > > > > So the whole thing leaves me very confused: either A6 is part of > > something that to me at the moment looks like a mad scheme (with all > > due respect to the people that thought it up), or it's a way to stop > > it from being difficult to be an IPv6 DNS administrator > even if you're > > too lazy to find a Perl script and too stupid to write one. > > > > > AAAA is especially problematic if DNSSEC is used, since > that would > > > require resigning the entire zone -- and that's expensive. > > > > It seems to me that renumbering your entire network, which will > > involve reconfiguring and possibly breaking zillions of machines, > > adjusting firewalls, etc. etc., is *exactly* the kind of thing that > > security mechanisms should be controlling. > > > > Complaining that the security mechanisms make it too difficult, or > > hard for third parties to do, seems to be missing the point rather. > > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 25 13:23:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PLLVV16856 for ipng-dist; Thu, 25 Jan 2001 13:21:31 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PLLK216848 for ; Thu, 25 Jan 2001 13:21:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19967 for ; Thu, 25 Jan 2001 13:21:18 -0800 (PST) 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 OAA23557 for ; Thu, 25 Jan 2001 14:21:17 -0700 (MST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PLLCU06195; Thu, 25 Jan 2001 13:21:12 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0PLJnN10734; Thu, 25 Jan 2001 13:19:49 -0800 Message-Id: <200101252119.f0PLJnN10734@zed.isi.edu> Subject: Re: A6 benefits? To: huitema@exchange.microsoft.com (Christian Huitema) Date: Thu, 25 Jan 2001 13:19:49 -0800 (PST) Cc: ian@davenant.greenend.org.uk (Ian Jackson), ipng@sunroof.eng.sun.com In-Reply-To: from "Christian Huitema" at Jan 25, 2001 08:37:18 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 % In short, the A6 design trades off some additional design complexity for % a lesser management load and a lesser use of DNS resource when either % renumbering or multi-homing are frequent. % % -- Christian Huitema What has changed is some empirical, operational experience with A6/DNAME records. The expectation that the mgmt load would be less appears to be based on the premise that the overall "clue" factor would rise. What has occured is that the clue factor is (still) tending flat, with a rising population. The tools are -NOT- in place to ease the administrative complexities, (just where are my offsets anyway?) and the encoding methods are fairly non-obvious to the normal operational crowd. While the design may be conceptually elegant, the barriers to adoption are looking -very- high. (where oh where is a simple DNAME replacement for: %dig -x 192.168.10.10 'cause %dig -x 3ffe:1::c620:242 fails. Note that I can "cut" the v6 address from my ifconfig. But now, w/o my useful -x flag, I'm stuck with this: %dig 2.4.2.0.2.6.c.0.0.(yes, you need them all).1.e.f.f.3.ip6.int Not at all operationally friendly. The DNAME & A6 wigets are just to wierd to type in. Your mileage may vary. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 25 13:41:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PLeZL16937 for ipng-dist; Thu, 25 Jan 2001 13:40:35 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PLeN216930 for ; Thu, 25 Jan 2001 13:40:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01523 for ; Thu, 25 Jan 2001 13:40:21 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA07911 for ; Thu, 25 Jan 2001 13:40:21 -0800 (PST) Received: (qmail 25490 invoked by uid 1001); 25 Jan 2001 19:29:40 -0000 Date: 25 Jan 2001 19:29:40 -0000 Message-ID: <20010125192940.20339.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010125103227.23223.qmail@cr.yp.to> <200101251405.f0PE4sN00760@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mark.Andrews@nominum.com writes: > Dan stop assuming things about BIND 9's behaviour I didn't say anything about BIND 9. Please read my message again; I'm criticizing the protocol, not BIND. Think about your gigantic 6887ms lookup time when you get to the ``fourteen queries'' part. ---Dan Date: 18 Jan 2001 09:13:40 -0000 Message-ID: <20010118091340.20931.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: A6 unreliability A recent bind-users report pointed out that BIND 8 can't find the IPv4 address of www.monty.de, even though the monty.de configuration is valid and the relevant servers are responding quickly. Here's one way to understand what's going wrong. I'd like to write a program that talks to DNS servers to find an address given an FQDN. How much memory do I need? How many servers do I need to contact? Well, I might need 64KB for an incoming DNS message, during the brief moment before I parse it. There's not much persistent data: * The name I'm looking up. * The name of the closest zone found so far. * The addresses of servers for that zone. 16 is more than enough. A response from a server will give me the answer, or refer me to a closer zone. The number of queries is at most 4 for www.blah.com. Simple, isn't it? Oops, that's not quite right. I might receive a CNAME. In that case I'll have to change the name and start over. This may happen several times. RFC 1034 says that the first CNAME ``should always'' get me to the canonical name, to avoid ``extra indirections,'' but it also says that I should follow chains if they do happen. Suddenly there's no limit to the number of queries. I have to set my own artificial limits to catch loops, and pray that they're not too small. But wait. The algorithm still doesn't work. The referral can include some glueless server names---names without addresses. I need to put the query on hold while I look up _those_ addresses. So here's what I actually have to store: * The name I'm looking up. * The name of the closest known zone. * The known addresses of servers for that zone. * The names of servers whose addresses I still have to look up. * The name of a server whose address I'm looking up. * The name of the closest known zone to _that_. * The known addresses of servers for that zone. * The names of servers whose addresses I still have to look up. It doesn't end there. If there are names in the last list, I'll have to put the second lookup on hold while I look for the addresses of _those_ names. And so on. The servers for monty.de, for example, are {ns,ns2}.norplex.net. The servers for norplex.net are vserver.neptun11.de and ns1.mars11.de. The servers for neptun11.de are {ns,ns2}.germany.net. The servers for mars11.de are ns1.neptun11.de and www.gilching.de. The servers for gilching.de are ecrc.de and name.muenchen.roses.de. What an amazing display of gluelessness! Suddenly there's no limit to the amount of space I need. I don't have a single small array of addresses; I have an unlimited-length array of small arrays of names and addresses. This isn't so simple any more. The problem with BIND is that it doesn't set aside this space. It uses the naive data structure. The only way it can put a query on hold, and look up a server name, is by dropping the query. It hopes that the server name lookup (``sysquery'') will find the server name before the original client tries again. My DNS cache can handle several levels of gluelessness, so it's able to find www.monty.de---but it has to send _fourteen_ queries. That takes quite a bit of time. Even worse, there are fourteen opportunities for delays. I encourage my users to avoid CNAMEs. I encourage them to avoid glueless domains. My software automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default server names for fqdn. My users appreciate the speed and reliability. Now I'm looking at the IPv6 DNS proposals. Here's what I see: * ip6.int is similar to in-addr.arpa. The format is slightly less compact but allows many levels of delegation without CNAMEs. The final names are large but tolerable. Okay. It works. * AAAA requires a fairly clumsy transition; extending the A format would have been much cleaner. But AAAA in a future IPv6-only world will function the same way that A does today. Okay. It works. * DNAME exacerbates all the problems of CNAME. DNAMEs can be wrapped inside DNAMEs---and this is _encouraged_! We'll have people setting up huge CNAME/DNAME chains to match their corporate structures. * A6 exacerbates all the problems of glueless names in NS records. Suddenly there's another reason that a lookup will have to be put on hold---and, again, this is _encouraged_! DNAME and A6 are moving in the wrong direction: more gluelessness, slower lookups, more frequent delays, and more outages like monty.de. A6 creates reliability problems that are not present in AAAA. I object to DNAME and A6. I would object to them even if they were the only way to support easy renumbering. I cannot bring myself to inflict such a rickety system on future Internet users. ---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 Jan 25 13:51:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PLoUZ16963 for ipng-dist; Thu, 25 Jan 2001 13:50:30 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PLoI216956 for ; Thu, 25 Jan 2001 13:50:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10335 for ; Thu, 25 Jan 2001 13:50:17 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA12271 for ; Thu, 25 Jan 2001 13:50:16 -0800 (PST) Received: (qmail 4000 invoked by uid 1001); 25 Jan 2001 19:45:53 -0000 Date: 25 Jan 2001 19:45:53 -0000 Message-ID: <20010125194553.20465.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010124171155.29022.qmail@cr.yp.to> <2883.980415677@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 I agree with Elz that the following two steps would (1) eliminate the reliability problems of out-of-bailiwick NS records (2) without allowing caches to be poisoned: 1. Servers fetch glue, and provide glue in their responses, so that NS is always accompanied by A: e.g., aol.net NS dns-01.ns.aol.com and dns-01.ns.aol.com A 152.163.159.232. 2. Caches save the NS+A combination: aol.net NS+A 152.163.159.232. They don't save the A record separately. Of course, this is functionally identical to putting IP addresses into NS records, which is exactly how the protocol should have been designed in the first place. ---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 Jan 25 14:35:03 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PMXAn17016 for ipng-dist; Thu, 25 Jan 2001 14:33:10 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PMWr217001 for ; Thu, 25 Jan 2001 14:32:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22146 for ; Thu, 25 Jan 2001 14:32:49 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04202 for ; Thu, 25 Jan 2001 14:32:49 -0800 (PST) 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 OAA26792; Thu, 25 Jan 2001 14:32:48 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA18818; Thu, 25 Jan 2001 14:32:47 -0800 Message-ID: <3A70A8A9.C5A77764@hursley.ibm.com> Date: Thu, 25 Jan 2001 16:28:57 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bill Manning CC: Christian Huitema , Ian Jackson , ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: <200101252119.f0PLJnN10734@zed.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill Manning wrote: ... > The DNAME & A6 wigets are just to wierd to type in. Clearly they should be generated by tools, as should any bulk update of AAAA records. I don't see this as a decision factor. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jan 25 14:40:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PMdUt17048 for ipng-dist; Thu, 25 Jan 2001 14:39:30 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PMdL217041 for ; Thu, 25 Jan 2001 14:39:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18842 for ; Thu, 25 Jan 2001 14:39:21 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04244 for ; Thu, 25 Jan 2001 14:39:21 -0800 (PST) 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 OAA73478; Thu, 25 Jan 2001 14:39:21 -0800 Received: from hursley.ibm.com (gsine06.us.sine.ibm.com [9.14.6.46]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id OAA18508; Thu, 25 Jan 2001 14:39:20 -0800 Message-ID: <3A70AA31.F523ACD5@hursley.ibm.com> Date: Thu, 25 Jan 2001 16:35:29 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Ian Jackson CC: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010125103227.23223.qmail@cr.yp.to> <200101251405.f0PE4sN00760@drugs.dv.isc.org> <14960.32965.273622.945296@davenant.relativity.greenend.org.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian explained the reason. You can disagree, but that was the resason. Brian Ian Jackson wrote: > > Mark.Andrews@nominum.com writes ("Re: An easy example of A6 unreliability "): > > With A6 you *can* follow all the address delegations but > > you don't *have* to. Personally I expect sites to be too > > paraniod to have chains that go outside their administrative > > control and you will, likely as not, get the full chain > > returned. > > In which case A6 degenerates into an extremely complicated, > special-purpose and generally badly-designed macro substitution > feature. Surely that isn't the kind of thing that anyone would want > in an IETF protocol. > > So we must conclude that the people who think A6 is a good idea must > have some other reason. What is that reason ? > > 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 Jan 25 15:23:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PNM0P17213 for ipng-dist; Thu, 25 Jan 2001 15:22:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PNLp217206 for ; Thu, 25 Jan 2001 15:21:51 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00241 for ; Thu, 25 Jan 2001 15:21:52 -0800 (PST) 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 PAA22183 for ; Thu, 25 Jan 2001 15:21:51 -0800 (PST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PNLpU28939; Thu, 25 Jan 2001 15:21:51 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0PNKRS10882; Thu, 25 Jan 2001 15:20:27 -0800 Message-Id: <200101252320.f0PNKRS10882@zed.isi.edu> Subject: Re: A6 benefits? To: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 25 Jan 2001 15:20:27 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), huitema@exchange.microsoft.com (Christian Huitema), ian@davenant.greenend.org.uk (Ian Jackson), ipng@sunroof.eng.sun.com In-Reply-To: <3A70A8A9.C5A77764@hursley.ibm.com> from "Brian E Carpenter" at Jan 25, 2001 04:28:57 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 % % Bill Manning wrote: % ... % > The DNAME & A6 wigets are just to wierd to type in. % % Clearly they should be generated by tools, as should any bulk % update of AAAA records. I don't see this as a decision factor. % % Brian Generally yes. Operators still need to manipulate the lables and addresses during troubleshooting. basic tools like dig are indispensible. If you don't see this as a problem, you clearly don't work with DNS on a regular basis as an operator. bulk manipulation argues for tools. debugging problems has near zero to do with bulk updates. And the tools do not exit. The protocol designers didn't think it was important and the code developers were just implementing protocol specs. Having worked with both AAAA/A & PTRs as well as A6 & DNAME records, I'll avoid the later as long as possible. When their use outweighs the pain of operational deployment, they will be used. Right now, they are more trouble than they are worth. -- --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 Jan 25 15:38:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0PNbQk17239 for ipng-dist; Thu, 25 Jan 2001 15:37:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0PNbG217232 for ; Thu, 25 Jan 2001 15:37:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10003 for ; Thu, 25 Jan 2001 15:37:17 -0800 (PST) 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 PAA28210 for ; Thu, 25 Jan 2001 15:37:16 -0800 (PST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0PNbGU01150; Thu, 25 Jan 2001 15:37:16 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0PNZrn10911; Thu, 25 Jan 2001 15:35:53 -0800 Message-Id: <200101252335.f0PNZrn10911@zed.isi.edu> Subject: typing To: huitema@exchange.microsoft.com Date: Thu, 25 Jan 2001 15:35:53 -0800 (PST) Cc: ipng@sunroof.eng.sun.com, bmanning@ISI.EDU (Bill Manning) 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 or lumping A6 & DNAME together. They are distinct RR types. They share the concept of chaining. DNAME has a much more perverse syntax that A6. BITSTRING is even worse. Still, I expect that both of these will appear palatable when IDN strings are expected as the norm (in UTF8 or *ACE encoding... :) The things we put up with instead of developing a real directory service... :( -- --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 Jan 25 17:12:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0Q1B6U17370 for ipng-dist; Thu, 25 Jan 2001 17:11:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0Q1As217363 for ; Thu, 25 Jan 2001 17:10:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14995 for ; Thu, 25 Jan 2001 17:10:54 -0800 (PST) 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 RAA21418 for ; Thu, 25 Jan 2001 17:10:53 -0800 (PST) Received: (qmail 30984 invoked by uid 1001); 26 Jan 2001 00:11:19 -0000 Date: 26 Jan 2001 00:11:19 -0000 Message-ID: <20010126001119.23928.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema writes: > We did in fact have this discussion in depth 2 years ago, when we > submitted the draft to the working group. I'm skeptical. I can't find server-side indirection discussed anywhere in the archives. Please provide a verifiable reference. > The motivation for A6 is the key database paradigm that atomic > information (e.g. a site prefix) should be stored exactly once. Not just a ``paradigm,'' but a ``key paradigm''! Wow. I see the light! We have to abolish PTR records, because they repeat information from A records. Clients that want reverse lookups will have to try forward lookups on random names. Information should be stored exactly once! Perhaps you are unaware that there are entire books on the design of serious databases: credit-card databases, airline reservation databases, etc. All the designs violate your ``key paradigm'' in a huge number of ways. Information is stored more than once for the sake of security (e.g., double-entry bookkeeping for auditors), reliability (e.g., transaction logs), speed (e.g., caching, reverse indices), etc. > This has major consequences on ease of update, as well as caching. These are certainly issues to consider. They deserve rational analysis, not ignorant religious nonsense like ``storing atomic information exactly once is a basic tenet of database theory.'' ---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 Jan 25 23:29:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0Q7Rvw17570 for ipng-dist; Thu, 25 Jan 2001 23:27:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0Q7Rm217563 for ; Thu, 25 Jan 2001 23:27:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24640 for ; Thu, 25 Jan 2001 23:27:49 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29329 for ; Thu, 25 Jan 2001 23:27:48 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:260:8ff:fe8b:23e6]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id QAA18282; Fri, 26 Jan 2001 16:11:17 +0900 (JST) Date: Fri, 26 Jan 2001 16:26:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Re: [rfc2553bis] EAI_NODATA In-Reply-To: In your message of "Fri, 19 Jan 2001 19:09:36 -0500 (EST)" References: User-Agent: Wanderlust/2.3.0 (Roam) 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 20000414(IM141) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 19 Jan 2001 19:09:36 -0500 (EST), >>>>> Jim Bound said: > Sorry for late response. EAI_NODATA was replaced by EAI_AGAIN in XNS 5.2. > Also EAI_ADDRFAMILY is now EAI_FAMILY. > I will send last update to the id editors tonight and ask for last call. > The only changes from -01 to -02 were updates to IEEE references from > Andrew Golan at Sun and some edits. Good catch I removed EAI_NODATA and > EAI_ADDRFAMILY. Thanks for the clarification, I'll adjust our implementation according to the change. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 26 03:45:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QBiC917930 for ipng-dist; Fri, 26 Jan 2001 03:44:12 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QBi1217923 for ; Fri, 26 Jan 2001 03:44:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19268 for ; Fri, 26 Jan 2001 03:44:00 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02206 for ; Fri, 26 Jan 2001 03:44:00 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04100; Fri, 26 Jan 2001 06:43:59 -0500 (EST) Message-Id: <200101261143.GAA04100@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addr-arch-v3-03.txt Date: Fri, 26 Jan 2001 06:43:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-03.txt Pages : 25 Date : 25-Jan-01 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v3-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010125101837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010125101837.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 26 08:09:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QG82Z18150 for ipng-dist; Fri, 26 Jan 2001 08:08:02 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QG7q218143 for ; Fri, 26 Jan 2001 08:07:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07892 for ; Fri, 26 Jan 2001 08:07:53 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00555 for ; Fri, 26 Jan 2001 08:07:45 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0QG7kI03482; Fri, 26 Jan 2001 23:07:49 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of "25 Jan 2001 19:45:53 GMT." <20010125194553.20465.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Jan 2001 23:07:46 +0700 Message-ID: <3480.980525266@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 25 Jan 2001 19:45:53 -0000 From: "D. J. Bernstein" Message-ID: <20010125194553.20465.qmail@cr.yp.to> | I agree with Elz I'm not sure how you know you agree with me, or how much, but ... | 1. Servers fetch glue, This is something I have wanted for a very long time, and have asked about on the odd occasion. I keep getting told that the load on the servers for the big zones (COM especially of course) would simply be too much - considering the number of domains that have servers that are unreachable (or simply don't know they're supposed to be servers at all) much of the time, and the number of queries to be made, the theory is that without spending too much of the server resources on this, the data for the whole zone couldn't be fetched before the parts fetched first had timed out and need to be fetched again. I've never run a server for a zone that big, so I don't know if this is an accurate assessment or not of course, but it is hard to argue against - especially when I know how busy my server gets, serving a lot more zones it is true, but a lot smaller and less frequently accessed ones. | 2. Caches save the NS+A combination: aol.net NS+A 152.163.159.232. | They don't save the A record separately. I'm not sure that this as a requirement makes a lot of sense though. The NS and A records are likely to have different TTLs, and one expire before the other. Further, should the cache receive the A record from its authoritative server, and it happens to be different, I think I'd prefer the cache to keep (and use) that one. | Of course, this is functionally identical to putting IP addresses into | NS records, It is functionally equivalent from the point of view of solving the problem that you have been referring to recently, yes. Aside from that though, it is barely even similar. In particular, this way, the SIG that accompanies the A record would have been fetched by the server from the auth server for the A record, when the A record was fetched, and will be passed back to the cache (along with the SIG for the NS record which comes from the child zone, though there's probably some technicality of DNSSEC I'm skipping there, DNSSEC around zone cuts is a mysterious thing). If the NS record had been designed with the A record in it directly, then that address would be being signed by the owner of the zone that uses the nameserver, instead of the owner of the server that uses the address, which would be the wrong place indeed (correct from a DNSSEC point of view, but incorrect from a rational point of view). On the other hand, if the A in the NS was being generated by the parent zone server as part of the delegation (automatically) then either it isn't going to be signed at all (and would this be rejected out of hand by some servers that are configured to only accept signed data - sometime in the future when this is practical) or would be signed by the parent zone, which is simply bogus all around (even assuming that the server can get some kind of access to the key to do the signing). | which is exactly how the protocol should have been designed | in the first place. And there we don't agree at all. But I think we should cease discussing the DNS protocols on the ipng list - this has slipped rather far away from issues directly relating to A6 records. If there is to be any more on this, perhaps it ought to be raised again on namedroppers, where there are far more DNS experts around, including some who were part of the original DNS design (which I don't think this WG includes any of). 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 Jan 26 08:12:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QGBxr18168 for ipng-dist; Fri, 26 Jan 2001 08:11:59 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QGBo218161 for ; Fri, 26 Jan 2001 08:11:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12551 for ; Fri, 26 Jan 2001 08:11:50 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07888 for ; Fri, 26 Jan 2001 09:11:48 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id RAA25813 for ipng@sunroof.eng.sun.com; Fri, 26 Jan 2001 17:11:47 +0100 (MET) Date: Fri, 26 Jan 2001 17:11:46 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: A6 unreliability Message-ID: <20010126171146.E24338@theory.cs.uni-bonn.de> References: <20010118091340.20931.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="a1QUDc0q7S3U7/Jg" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010118091340.20931.qmail@cr.yp.to>; from djb@cr.yp.to on Thu, Jan 18, 2001 at 09:13:40AM -0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --a1QUDc0q7S3U7/Jg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 18, 2001 at 09:13:40AM -0000, D. J. Bernstein wrote: This doesn't invalidate your original point, but I disagree with this: > A recent bind-users report pointed out that BIND 8 can't find the IPv4 > address of www.monty.de, even though the monty.de configuration is valid > and the relevant servers are responding quickly. The servers might respond quickly at the moment, but the configuration is nevertheless invalid: % host -t any www.monty.de. www.monty.de is a nickname for monty.de monty.de name server ns.norplex.net monty.de name server ns2.norplex.net % traceroute ns2.norplex.net. traceroute to ns2.norplex.net (151.189.26.234), 30 hops max, 40 byte packets 1 xanthos.informatik.uni-bonn.de (131.220.4.3) 2 ms 2 ms 2 ms ... 14 grf-ffm-ge020.germany.net (151.189.3.121) 23 ms 19 ms 19 ms 15 151.189.26.234 (151.189.26.234) 20 ms 21 ms 25 ms % traceroute ns.norplex.net. traceroute to ns.norplex.net (151.189.12.193), 30 hops max, 40 byte packets 1 xanthos.informatik.uni-bonn.de (131.220.4.3) 2 ms 2 ms 2 ms ... 14 grf-ffm-ge020.germany.net (151.189.3.121) 46 ms 18 ms 20 ms 15 vserver.neptun11.de (151.189.12.193) 29 ms 21 ms 20 ms % Using an official secondary which is behind the same router is completely bogus, and at least until recently, no domain would be registered at all that didn't have a really independent secondary server. But it looks like nowadays it is ok to not pretend at all to have a secondary nameserver, and even people who should know better don't bother: % host -t any yp.to. yp.to name server a.ns.yp.to yp.to name server b.ns.yp.to % host -t any a.ns.yp.to. a.ns.yp.to has address 131.193.178.181 % host -t any b.ns.yp.to b.ns.yp.to has address 131.193.178.181 so why should clueless $30 ISPs do? Now, let's go back to discuss design of reliable networks. Regards, -is --a1QUDc0q7S3U7/Jg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOnGhvjCn4om+4LhpAQFRqwf9HvupT12kwcmUWqKt/lfhGjuA1x1Jf8mS SL2XpJ2S27YcLS83r/YOt9l4bArvTgwziT+rEm8BCUi5YMZFz5MbL/7HjRO6vofy Jxqzqqy48twVcGypLtuxK31LQZ8Mdhbnnj3pGHbAch8D2oiRpNCXpTVVbr0E84iB ZW+kqV2XNso58ue2nBs9ao4QVBp4gxY8sN/CNJWA54k7R4d5X6Kpv6kG+f3D8DjX 4ysI787nkryKD50Dc9s59FPPZFGgJwlc3zcMgtg+URO382a/NRtsw2JjbEU7mrgE R4+BrjqjpNlyCNRBSOjhwx3tLohQt8qBN+4Ggig36SrSKz1oz4d7pg== =VVyM -----END PGP SIGNATURE----- --a1QUDc0q7S3U7/Jg-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jan 26 08:14:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QGDwR18191 for ipng-dist; Fri, 26 Jan 2001 08:13:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QGDl218184 for ; Fri, 26 Jan 2001 08:13:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05787 for ; Fri, 26 Jan 2001 08:13:47 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05026 for ; Fri, 26 Jan 2001 08:13:44 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0QGDqI03497; Fri, 26 Jan 2001 23:13:53 +0700 (ICT) From: Robert Elz To: Bill Manning cc: brian@hursley.ibm.com (Brian E Carpenter), huitema@exchange.microsoft.com (Christian Huitema), ian@davenant.greenend.org.uk (Ian Jackson), ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? In-reply-to: Your message of "Thu, 25 Jan 2001 15:20:27 PST." <200101252320.f0PNKRS10882@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Jan 2001 23:13:52 +0700 Message-ID: <3495.980525632@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 25 Jan 2001 15:20:27 -0800 (PST) From: Bill Manning Message-ID: <200101252320.f0PNKRS10882@zed.isi.edu> | Generally yes. Operators still need to manipulate the lables and | addresses during troubleshooting. basic tools like dig are indispensible. Yes, they are... But Bill, dig didn't exist in the early days of IPv4 DNS either, and you actually had to type backwards IPv4 addresses with .IN-ADDR.ARPA in them to nslookup (and hope that idiot tool was deciding to work that day). Tools like these come from the needs of the community who are actually using the things - when there is enough use of IPv6 reverse lookups that someone gets frustrated enough, the tools will appear, just as they did for IPv4. What's more, that's the way it should be, I don't want someone building diagnostic tools before the actual needs have been discovered, or we'll end up with another piece of trash like nslookup... 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 Jan 26 09:02:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QH1FU18309 for ipng-dist; Fri, 26 Jan 2001 09:01:15 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QH16218302 for ; Fri, 26 Jan 2001 09:01:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19157 for ; Fri, 26 Jan 2001 09:01:05 -0800 (PST) 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 JAA21208 for ; Fri, 26 Jan 2001 09:01:05 -0800 (PST) Received: from zed.isi.edu (IDENT:root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.1/8.11.1) with ESMTP id f0QH14U22810; Fri, 26 Jan 2001 09:01:04 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f0QGxfa12379; Fri, 26 Jan 2001 08:59:41 -0800 Message-Id: <200101261659.f0QGxfa12379@zed.isi.edu> Subject: Re: A6 benefits? To: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 26 Jan 2001 08:59:38 -0800 (PST) Cc: bmanning@ISI.EDU (Bill Manning), brian@hursley.ibm.com (Brian E Carpenter), huitema@exchange.microsoft.com (Christian Huitema), ian@davenant.greenend.org.uk (Ian Jackson), ipng@sunroof.eng.sun.com In-Reply-To: <3495.980525632@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at Jan 26, 2001 11:13:52 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 % % Date: Thu, 25 Jan 2001 15:20:27 -0800 (PST) % From: Bill Manning % Message-ID: <200101252320.f0PNKRS10882@zed.isi.edu> % % | Generally yes. Operators still need to manipulate the lables and % | addresses during troubleshooting. basic tools like dig are indispensible. % % Yes, they are... But Bill, dig didn't exist in the early days of % IPv4 DNS either, and you actually had to type backwards IPv4 % addresses with .IN-ADDR.ARPA in them to nslookup (and hope that % idiot tool was deciding to work that day). True... but nslookup did. Have you tried looking up a fragment of a DNAME or BITSTRING lable recently? Not for the faint of heart (or without some OOB information). Chaining is "fun" :) -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 26 09:27:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QHQ3V18407 for ipng-dist; Fri, 26 Jan 2001 09:26:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QHPq218400 for ; Fri, 26 Jan 2001 09:25:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24712 for ; Fri, 26 Jan 2001 09:25:52 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA02040 for ; Fri, 26 Jan 2001 09:25:52 -0800 (PST) Received: (qmail 1187 invoked by uid 1001); 26 Jan 2001 16:51:21 -0000 Date: 26 Jan 2001 16:51:21 -0000 Message-ID: <20010126165121.15761.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: A6 unreliability References: <20010118091340.20931.qmail@cr.yp.to> <20010126171146.E24338@theory.cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The physical location of the servers has no relevance to the protocol failures under discussion. BIND's inability to find monty.de doesn't involve any lost packets; nor did the fourteen queries that I mentioned. Ignatios Souvatzis writes: > Using an official secondary which is behind the same router is > completely bogus, Will you keep saying that if it turns out that there are arrangements to instantly reroute the network in case of outages? As for my configuration, see http://cr.yp.to/djbdns/third-party.html. ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 26 09:59:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QHwJN18483 for ipng-dist; Fri, 26 Jan 2001 09:58:19 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QHw7218475 for ; Fri, 26 Jan 2001 09:58:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12949 for ; Fri, 26 Jan 2001 09:58:07 -0800 (PST) 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 JAA16458 for ; Fri, 26 Jan 2001 09:58:06 -0800 (PST) Received: (qmail 27804 invoked by uid 1001); 26 Jan 2001 17:29:10 -0000 Date: 26 Jan 2001 17:29:10 -0000 Message-ID: <20010126172910.22474.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010125194553.20465.qmail@cr.yp.to> <3480.980525266@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > I keep getting told that the load on the servers for the big zones > (COM especially of course) would simply be too much In fact, those servers provided glue for all NS records until recently, and they still provide glue for the vast majority of NS records. How do they avoid the efficiency problems? Easy: the glue is pushed to the servers by the registrants, rather than being pulled. > The NS and A records are likely to have different TTLs, and one expire > before the other. The TTL on the combination is the minimum, of course. This doesn't make a big difference in cacheability; see my analysis of MX records. (In fact, the TTLs are typically the same.) > the SIG that accompanies the A record would have been fetched by the > server from the auth server for the A record, Excuse me? A moment ago you didn't want to generate extra queries. You wanted to use the out-of-bailiwick glue. I'm explaining how to make that happen without allowing caches to be poisoned. The SIG semantics don't have to be modified. When the server copies the A record, it can also move it into its own zone, sign it, and change the NS record accordingly. Of course, this is functionally identical to signing an NS record that contains an IP address. You have to do a lot more parsing, and check more signatures, but the end result is the same. > this has slipped rather far away from issues directly > relating to A6 records. No. The issues are exactly the same. ---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 Jan 26 10:23:45 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QIMDY18534 for ipng-dist; Fri, 26 Jan 2001 10:22:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QIM0218527 for ; Fri, 26 Jan 2001 10:22:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09660 for ; Fri, 26 Jan 2001 10:22:00 -0800 (PST) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00507 for ; Fri, 26 Jan 2001 10:21:58 -0800 (PST) Received: from trantor.ferrara.linux.it (151.26.143.154) by smtp2.libero.it (5.5.015.5) id 3A5365A600F39A2C; Fri, 26 Jan 2001 19:21:47 +0100 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 24B3A97D00; Fri, 26 Jan 2001 14:46:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 1F75A97CFE; Fri, 26 Jan 2001 14:46:01 -0500 (EST) Date: Fri, 26 Jan 2001 14:46:01 -0500 (EST) From: Mauro Tortonesi To: Richard Draves Cc: ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: RE: src addr sel 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, 25 Jan 2001, Richard Draves wrote: first of all, thank for your reply. although i am surely not an expert kernel-level programmer, i am very interested in this argument. > [Resending from my Hotmail account. I fear the original did not make it out > to the list.] maybe because of problems with the net at your workplace, lately? ;-) don't be offended, it happens to everyone :-( > >i wonder if there is a working implementation of dest/src address > >selection that is fully conformant to this spec. i'd really like to know > >how the implementation issues have been solved. > > Yes, I have implemented it. It's pretty easy to implement. Basically when > getaddrinfo gets more than one address back from DNS, it uses an ioctl to > call down to the IPv6 stack to sort the addresses. Then all the real work is > in the IPv6 stack, where there is direct access to information like the > interfaces, addresses, routing table, etc. is there an opensource or free-software implementation? i'd REALLY like to take a look a it. i guess you have implemented this feature only in w2k, haven't you? > Another solution is to keep an invalidation counter this is a much more performant and interesting strategy than resorting a list every second. maybe you can add these considerations in the next version of your paper. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 26 11:06:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QJ4ew18574 for ipng-dist; Fri, 26 Jan 2001 11:04:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QJ4T218567 for ; Fri, 26 Jan 2001 11:04:29 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16808 for ; Fri, 26 Jan 2001 11:04:28 -0800 (PST) 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 LAA16886 for ; Fri, 26 Jan 2001 11:04:25 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14MEAa-0000O9-00 (Debian); Fri, 26 Jan 2001 19:04:24 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14MEAZ-0007qB-00 (Debian); Fri, 26 Jan 2001 19:04:23 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14961.51767.175509.20393@davenant.relativity.greenend.org.uk> Date: Fri, 26 Jan 2001 19:04:23 +0000 (GMT) To: Subject: RE: A6 benefits? 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: A6 benefits? "): > The motivation for A6 is the key database paradigm that atomic > information (e.g. a site prefix) should be stored exactly > once. [...] I agree with Dan's criticism of this argument, namely that it's pretty much just a mantra rather than a claim that can be justified and understood. But I want to say more in response to it: The DNS is not `a database' in that sense; it is indeed a component of a very unusual large distributed database, but other components include the software that updates and generates zonefiles. And it's certainly not true that database systems do not replicate information. Indeed, the database of which the DNS is part does a lot of replication of information, deliberately, to support availability and other useful properties. There is no reason, as I've explained, why even with AAAA records the prefix for a given network need be *originally* stored and managed more than once per administrative domain; there is a wealth of software that could manage the replication of this information into the zone files. So this argument in favour of A6 does not apply, because managing and storing the prefix information once does not imply A6 and can be done perfectly well (better, indeed) with AAAA. > ... The ease of update argument is clear: it is simpler to update > one record for a large site than to update all records for all nodes > in the site; With adequate software this is simply not true. > this is particularly true when the use of DNS security increases > wildly the cost of any given update. A reasonably modern computer can easily do 100 1kbit RSA signatures per second. So, if each host in a network needs an AAAA RR and a PTR RR and the corresponding NXTs, that's 4 signatures, so a complete renumbering of a 1000-host network would take approximately 40 seconds - less time than it would probably take to propagate the new zone to the secondaries ! > We did in fact have this discussion in depth 2 years ago, when we > submitted the draft to the working group. It's a shame that I wasn't involved in the relevant WG(s) at the time. I'd heard about AAAA, which seemed obvious and reasonable, and I made the assumption - with hindsight clearly naive - that insanity like A6 wouldn't get too far. I suppose should have seen which way the wind was blowing when I read the IPSEC I-Ds, but I thought that the insanity there was mainly due to the evil influence of cryptography politics. > The caching argument is also a natural consequence > of the "atomic information" property: each component of the information > can be given an appropriate TTL, ... > Jim, Randy and some other have made the argument that A6 would increase > the load on the DNS, by requiring several transaction for any given > exchange. This type of argument, however, does not take caching into > account. Prefixes are common to several nodes [...] This argument, as an argument in favour of A6, is bogus, as a small amount of thought demonstrates. Consider what happens if you want to find the address of a host you've not talked to before: With AAAA, you have to look up the AAAA RR (which won't be in your cache) and now you have the address. With A6, you have to look up the original A6 (which won't be in your cache), and then sometimes (if the next A6 isn't cached), the next one, and possibly so on up the chain. So for a host you haven't talked to before A6 is never even as cheap as AAAA, let alone cheaper. A6 is only cheaper under certain obscure TTL conditions when you talk to a host you've spoken to recently (first A6 in the cache), but which has been renumbered since (next A6 timed out) - and even then is only cheaper by one query for each renumbered host. When you talk to a network you haven't seen recently the A6 is always more expensive. Since you speak to new networks and new hosts (or networks and hosts whose data has timed out) much more often than networks you are already speaking to, AAAA involves fewer queries. 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 Jan 26 11:40:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QJdBX18605 for ipng-dist; Fri, 26 Jan 2001 11:39:11 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QJcx218598 for ; Fri, 26 Jan 2001 11:39:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09777 for ; Fri, 26 Jan 2001 11:38:59 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA00772 for ; Fri, 26 Jan 2001 11:38:58 -0800 (PST) Received: (qmail 11274 invoked by uid 1001); 26 Jan 2001 19:18:52 -0000 Date: 26 Jan 2001 19:18:52 -0000 Message-ID: <20010126191852.5157.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Extremely long TTLs References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema writes: > information that does not change, such as the lower bits of a node's > address, can be stored with a longer TTL than the site's prefix. Everything changes. Machines acquire extra IP addresses. Machines disappear. Even MAC addresses change: network cards die. (It isn't always possible, never mind easy, to reprogram the MAC address on the new card.) Those of us who write caches don't want to deal with users asking ``why am I getting the old address?'' when a novice administrator starts with a silly 6-week TTL and then suddenly realizes that he has to change the address. My cache never saves data for more than a week. Yes, TTLs vary. Yes, some fraction of queries will be saved by longer TTLs. But every record, no matter how stable, will be refreshed periodically. A careful analysis takes all of this into account. ---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 Jan 26 13:01:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QKuJq18689 for ipng-dist; Fri, 26 Jan 2001 12:56:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QKu9218682 for ; Fri, 26 Jan 2001 12:56:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18364 for ; Fri, 26 Jan 2001 12:56:08 -0800 (PST) Received: from mailhub1.almaden.ibm.com (mailhub1.almaden.ibm.com [198.4.83.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05359 for ; Fri, 26 Jan 2001 12:56:08 -0800 (PST) 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 MAA71812; Fri, 26 Jan 2001 12:55:49 -0800 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by maui.almaden.ibm.com (AIX4.3/8.9.3/8.7) with ESMTP id MAA20424; Fri, 26 Jan 2001 12:56:05 -0800 Message-ID: <3A71E3E8.8B76C00@hursley.ibm.com> Date: Fri, 26 Jan 2001 14:54:00 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Bill Manning CC: Christian Huitema , Ian Jackson , ipng@sunroof.eng.sun.com Subject: Re: A6 benefits? References: <200101252320.f0PNKRS10882@zed.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, I was thinking about bulk renumbering, not about diagnosis. I haven't had to dig on a regular basis recently, but I used to do it all the time... Brian Bill Manning wrote: > > % > % Bill Manning wrote: > % ... > % > The DNAME & A6 wigets are just to wierd to type in. > % > % Clearly they should be generated by tools, as should any bulk > % update of AAAA records. I don't see this as a decision factor. > % > % Brian > > Generally yes. Operators still need to manipulate the lables and > addresses during troubleshooting. basic tools like dig are indispensible. > If you don't see this as a problem, you clearly don't work with DNS > on a regular basis as an operator. > > bulk manipulation argues for tools. debugging problems has near zero > to do with bulk updates. And the tools do not exit. The protocol designers > didn't think it was important and the code developers were just implementing > protocol specs. Having worked with both AAAA/A & PTRs as well as A6 & DNAME > records, I'll avoid the later as long as possible. When their use outweighs > the pain of operational deployment, they will be used. Right now, they > are more trouble than they are worth. > > -- > --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jan 26 14:13:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0QMBdn18768 for ipng-dist; Fri, 26 Jan 2001 14:11:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QMBR218761 for ; Fri, 26 Jan 2001 14:11:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01937 for ; Fri, 26 Jan 2001 14:11:27 -0800 (PST) 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 OAA19323 for ; Fri, 26 Jan 2001 14:11:24 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14MH5U-0004r4-00 (Debian); Fri, 26 Jan 2001 22:11:20 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14MH5T-0008Ex-00 (Debian); Fri, 26 Jan 2001 22:11:19 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14961.62982.978316.834738@davenant.relativity.greenend.org.uk> Date: Fri, 26 Jan 2001 22:11:18 +0000 (GMT) To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability Newsgroups: chiark.mail.ietf.ipng In-Reply-To: <20010126172910.22474.qmail@cr.yp.to> References: <20010125194553.20465.qmail@cr.yp.to> <3480.980525266@brandenburg.cs.mu.OZ.AU> <20010126172910.22474.qmail@cr.yp.to> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk D. J. Bernstein writes ("Re: An easy example of A6 unreliability"): > The SIG semantics don't have to be modified. When the server copies the > A record, it can also move it into its own zone, sign it, and change the > NS record accordingly. This would I think be rather poor practice on the part of the server. Signing something just because someone else signed something is not usually a good idea, and usually indicates a design error somewhere. Now you'll probably just agree with me and tell us that the design error is that the NS record contains an A :-). Still, at first glance it doesn't seem like a very good idea. If people still seem to think it is then I suppose I should think about it harder and see what potential attacks there are. 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 Jan 26 16:10:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0R08xe18941 for ipng-dist; Fri, 26 Jan 2001 16:08:59 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0R08s218934 for ; Fri, 26 Jan 2001 16:08:54 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0R06rb04663 for ipng@sunroof.eng.sun.com; Fri, 26 Jan 2001 16:06:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0Q12K217351 for ; Thu, 25 Jan 2001 17:02:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13552 for ; Thu, 25 Jan 2001 17:02:21 -0800 (PST) Received: from hotmail.com (f95.law3.hotmail.com [209.185.241.95]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03938 for ; Thu, 25 Jan 2001 17:02:20 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Jan 2001 17:02:20 -0800 Received: from 131.107.3.86 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 26 Jan 2001 01:02:19 GMT X-Originating-IP: [131.107.3.86] From: "Richard Draves" To: mauro@ferrara.linux.it Cc: ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: RE: src addr sel Date: Thu, 25 Jan 2001 17:02:19 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jan 2001 01:02:20.0155 (UTC) FILETIME=[A23FDCB0:01C08733] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Resending from my Hotmail account. I fear the original did not make it out to the list.] >i wonder if there is a working implementation of dest/src address >selection that is fully conformant to this spec. i'd really like to know >how the implementation issues have been solved. Yes, I have implemented it. It's pretty easy to implement. Basically when getaddrinfo gets more than one address back from DNS, it uses an ioctl to call down to the IPv6 stack to sort the addresses. Then all the real work is in the IPv6 stack, where there is direct access to information like the interfaces, addresses, routing table, etc. > The destination address selection algorithm needs information about > potential source addresses. One possible implementation strategy is > for getipnodebyname() and getaddrinfo() to call down to the IPv6 > network layer with a list of destination addresses, sort the list in > the network layer with full current knowledge of available source > addresses, and return the sorted list to getipnodebyname() or > getaddrinfo(). This is simple and gives the best results but it > introduces the overhead of another system call. One way to reduce > this overhead is to cache the sorted address list in the resolver, > so that subsequent calls for the same name do not need to resort the > list. > imho this is not so simple to implement. it requires a tight coupling >between the network layer (kernel space) and the networking stuff of the C >library (user space), and a very careful design of the caching >policy (especially if we have to handle temporary, preferred and >deprecated addresses). It is in fact simple to implement. One simple strategy for having the resolver cache a sorted list is to resort the list if it was last sorted more than some short time ago, like a second. > Another implementation strategy is to call down to the network layer > to retrieve source address information and then sort the list of > addresses directly in the context of getipnodebyname() or > getaddrinfo(). To reduce overhead in this approach, the source > address information can be cached, amortizing the overhead of > retrieving it across multiple calls to getipnodebyname() and > getaddrinfo(). > >this is a simpler solution, as it requires only a minor interaction >between kernel- and user-space. but the complexity of the caching >algorithm is not reduced, and this implementation introduces another >problem: I disagree, I think this is a much more complicated implementation strategy because you have to pull lots of information into the user space context to do the sort there. But to each his own: the draft is explicitly not mandating an implementation strategy. It is trying to point out some possibilities. > In this approach, the implementation may not have > knowledge of the outgoing interface for each destination, so it MAY > use a looser definition of the candidate set during destination > address ordering. > >and this is surely a negative point. Yes, another reason I didn't choose this implementation strategy myself. >moreover, there are lots of other problems to be solved. in particular: > > 1) performance. it cannot be allowed by using cached data, as caching > is very difficult to do. and the spec says: > > In any case, if the implementation uses cached and possibly stale > information in its implementation of destination address selection, > or if the ordering of a cached list of destination addresses is > possibly stale, then it should ensure that the destination address > ordering returned to the application is no more than one second out > of date. For example, an implementation might make a system call to > check if any routing table entries or source address assignments > that might affect these algorithms have changed. > > because cached data is valid for no more than 1 sec., and the > implementation of a correct caching algorithm is VERY difficult, >caching is more a problem than a solution. There are many ways to implement this. One solution is just to resort if more than one second has gone by, in other words assume that any information more than one second old is stale. Another solution is to keep an invalidation counter in the stack. The counter is incremented any time there is change in relevant state, like the routing table or address assignments. Then when you cache information dependent on that state, you save a copy of the counter. You can later check the cached counter value against the current value to see if the cached computation result is stale. > 2) handling the policy table. it should be kept in kernel-space, but >designing a simple and safe way to edit it is surely not a trivial > task. It was a trivial task. The policy table is much like a routing table and I based the ioctls that retrieve/update the policy table on the routing table ioctls. Thanks, Rich _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jan 26 16:10:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0R09bE18953 for ipng-dist; Fri, 26 Jan 2001 16:09:37 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0R09V218946 for ; Fri, 26 Jan 2001 16:09:31 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0R07TJ04693 for ipng@sunroof.eng.sun.com; Fri, 26 Jan 2001 16:07:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0QBdY217910 for ; Fri, 26 Jan 2001 03:39:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18998 for ; Fri, 26 Jan 2001 03:39:33 -0800 (PST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29760 for ; Fri, 26 Jan 2001 03:39:33 -0800 (PST) Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA28302 for ; Fri, 26 Jan 2001 06:39:32 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA28261 for ; Fri, 26 Jan 2001 06:39:31 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jan 2001 12:39:30 +0100 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0AECC648@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: =?iso-8859-1?Q?Peder_Chr=2E_N=F8rgaard?= Cc: ipng@sunroof.eng.sun.com Subject: RE: MLD MIB Date: Fri, 26 Jan 2001 12:39:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f0QBdZ217911 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Comments inline > ---------- > From: Peder Chr. N鴕gaard[SMTP:Peder.C.Norgaard@ted.ericsson.dk] > Sent: Wednesday, January 24, 2001 9:51 PM > To: Wijnen, Bert (Bert) > Cc: Peder Chr. N鴕gaard; ipng@sunroof.eng.sun.com > Subject: RE: MLD MIB > > On Wed, 24 Jan 2001, Wijnen, Bert (Bert) wrote: > > > > > > > I have to disagree with the premises of this statement, if not the > > > conclusion. This change does indeed change the semantics of the > > > implementation, and also the value of the bytes on the wire. The > > > InterfaceIndex and the Ipv6IfIndex are two different numbering > schemes, > > Oh... are they? > > Then pls explain the difference between these two definitions: > > Of course. I cut a bit to emphasize: > > > Ipv6IfIndex ::= TEXTUAL-CONVENTION > : > > "A unique value, greater than zero for each > > internetwork-layer interface in the managed > ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^ > > > > InterfaceIndex ::= TEXTUAL-CONVENTION > : > > "A unique value, greater than zero, for each interface or > ^^^^^^^^^ > > interface sub-layer in the managed system. It is > ^^^^^^^^^^^^^^^^^^^ > > I read this as the difference between layer 3 only and all layers. > > Certainly the InterfaceIndex covers all layers. And I find in the > IPV6-MIB a mapping from Ipv6InterfaceIndex to the InterfaceIndex - the MIB > object ipv6IfLowerLayer - that mapping is meaningless if the two values > are supposed to be identical! This forced me to interpret the two TCs as > representing two independent numbering schemes. > Mmm... maybe... but I wonder if that was intentional. Anyway... the ipv6mib design team is looking at these MIBs and they will come up with proposed new (clariying text). > > They seem very much the same to me. > > And certainly, the data on the wire keeps to be an Integer32 with the > > same range!! The same is true for the other editorial changes. > > Oh, yes, the *encoding* is identical. But if you - as I have done - has > implemented IPV6-MIB according to abovementioned interpretation - the > *values* are different. > > > > and replacing the latter with the former forces changes in all > > > implementations. Cf discussion on the IPv6 Design Team homepage > > I do not see what needs to be changed in implementations. > > > > > . > > > > > That Design Team has been becoming active again, and they currently > > believe that it is best to get rid of Ipv6IfIndex. And they are looking > at > > existing MIBs that use this TC to see what changes are needed. And > > they will soon submit I-Ds (I hope) to be discussed. > > That would please me - if this is to be done, it must be done soon. > 'Cause that change *will* force me to change implementation. (no big > deal, of course - actually a simplification.) > Good to hear it is a simplification in yoru eyes. The DT is working hard on the MIBs. I hope to see I-Ds pretty soon now. > > > > > Unfortunately that discussion never reached a conclusion, so the > MLD-MIB > > > designers do not really have any guidance in the choice between the > two > > > schemes. Say, if the design team had concluded to do away with the > > > Ipv6IfIndex in the IPV6-MIB and friends, the MLD-MIB should of course > do > > > the same. > > > > > > From my own position, the proposed change does not hurt, for I have > not > > > completed the implementation of the MLD-MIB. But anyone with a > working > > > implementation of MLD-MIB will have to modify code to adapt to this > > > change. > > > > > As I said I doubt they have to change much code (if any). All depends a > bit > > on how an implementation was done. If anyone who implemented the MIB > > and who sees a big issue with this editorial change... pls scream. > > Couldn't agree more. I'm not screaming. Just noticing :-) > Good. So I went ahead and asked RFC-Editor to make those "editorial changes" Bert > --peder chr. > > > Bert > > > > -- > Peder Chr. N鴕gaard Senior System Developer, M. Sc. > Ericsson Telebit A/S tel: +45 89 38 52 53 > Skanderborgvej 232 fax: +45 89 38 51 01 > DK-8260 Viby J, Denmark mob: +45 21 28 66 58 > e-mail: Peder.C.Norgaard@ted.ericsson.dk > (old e-mail 1992-2000: pcn@tbit.dk) > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jan 26 17:33:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0R1VVT19050 for ipng-dist; Fri, 26 Jan 2001 17:31:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0R1VJ219043 for ; Fri, 26 Jan 2001 17:31:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16884 for ; Fri, 26 Jan 2001 17:31:20 -0800 (PST) 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 RAA02641 for ; Fri, 26 Jan 2001 17:31:19 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14MKD0-0001K4-00 (Debian); Sat, 27 Jan 2001 01:31:18 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14MKCz-0000Eb-00 (Debian); Sat, 27 Jan 2001 01:31:17 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14962.9444.676319.300018@davenant.relativity.greenend.org.uk> Date: Sat, 27 Jan 2001 01:31:16 +0000 (GMT) To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability Newsgroups: chiark.mail.ietf.ipng In-Reply-To: <14961.62982.978316.834738@davenant.relativity.greenend.org.uk> References: <20010125194553.20465.qmail@cr.yp.to> <3480.980525266@brandenburg.cs.mu.OZ.AU> <20010126172910.22474.qmail@cr.yp.to> <14961.62982.978316.834738@davenant.relativity.greenend.org.uk> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ian Jackson writes ("Re: An easy example of A6 unreliability"): > Now [Dan]'ll probably just agree with me and tell us that the design > error is that the NS record contains an A :-). Err, I mean, contains a domain but should contain an A. 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 Jan 26 21:49:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0R5mP519108 for ipng-dist; Fri, 26 Jan 2001 21:48:25 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0R5mD219101 for ; Fri, 26 Jan 2001 21:48:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10197 for ; Fri, 26 Jan 2001 21:48:13 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA17930 for ; Fri, 26 Jan 2001 22:48:09 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f0R5meX01394; Sat, 27 Jan 2001 12:48:40 +0700 (ICT) From: Robert Elz To: "D. J. Bernstein" cc: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability In-reply-to: Your message of "26 Jan 2001 17:29:10 GMT." <20010126172910.22474.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Jan 2001 12:48:40 +0700 Message-ID: <1392.980574520@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 26 Jan 2001 17:29:10 -0000 From: "D. J. Bernstein" Message-ID: <20010126172910.22474.qmail@cr.yp.to> | In fact, those servers provided glue for all NS records until recently, | and they still provide glue for the vast majority of NS records. Yes, it isn't providing the glue that is hard. | How do they avoid the efficiency problems? Easy: the glue is pushed to | the servers by the registrants, rather than being pulled. Which is exactly what turns out to not work at all well. Either there is what we have now, a (potentially anyway) secure out of band channel with which to advise on updates, which then just doesn't get used, or we have the client's server do the pushing. But it is quite common for there to be several servers configured to serve the same domain (client has left one ISP and gone to another - the old one doesn't take down the server for ages sometimes). Then we have two servers, each wanting to update the A record for the glue to match what it believes it ought be (and if the client has used the ns.my.domain type NS value in both cases, then the registry doesn't even get a clue which is correct from the name of the glue being updated). Further, it is quite likely that both might be signed, with SIGS that have not expired. All this just gets hard, which is why server pull is the simple implementation - it just means extra work for the server (actually receiving and processing the updates is about the same either way, but the server has to do more checking). | The TTL on the combination is the minimum, of course. Which removes useful functionality. | This doesn't make | a big difference in cacheability; see my analysis of MX records. (In | fact, the TTLs are typically the same.) You mean that not a lot of people know how to use TTLs intelligently, so let's not allow anyone to do so? | Excuse me? A moment ago you didn't want to generate extra queries. I don't think I said that: extra queries will sometimes be necessary. (I did say that an argument against doing server pull of glue is the extra work - that isn't my argument though). But that wouldn't be a result here. The SIG accompanies the A record when the server obtains it (which would happen with pull or push methodology). It then attaches it to the answers it sends others (and the others verify it if they feel inclined, the parent server doesn't need to). | The SIG semantics don't have to be modified. When the server copies the | A record, it can also move it into its own zone, sign it, and change the | NS record accordingly. No, you keep failing to understand - the server cannot sign anything, it has no keys available (in general). Signing is (sometimes) done only by a human (or for even better security, perhaps even a team of humans). | Of course, this is functionally identical to signing an NS record that | contains an IP address. You have to do a lot more parsing, and check | more signatures, but the end result is the same. It would be if it were done that way, but that isn't the way to do it (quite apart from which, the server can't "change the NS record" or the NS RRSet from the server, and the NN RRSet from the client wouldn't be the same - which is a configuration bug - a fairly common one, but still not one we should be encouraging). | > this has slipped rather far away from issues directly | > relating to A6 records. | No. The issues are exactly the same. But these are all internal DNS issues now, none of it is specifically related to IPv6 - it would still be better discussed on the namedroppers list where there is more DNS expertise available than exists here. 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 Jan 27 06:46:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0REijo19347 for ipng-dist; Sat, 27 Jan 2001 06:44:45 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0REiX219340 for ; Sat, 27 Jan 2001 06:44:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00288 for ; Sat, 27 Jan 2001 06:44:34 -0800 (PST) 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 GAA08835 for ; Sat, 27 Jan 2001 06:44:33 -0800 (PST) Received: from (davenant.greenend.org.uk) [172.31.80.6] by chiark.greenend.org.uk with esmtp (Exim 3.12 #2) id 14MWad-0006zq-00 (Debian); Sat, 27 Jan 2001 14:44:31 +0000 Received: from ian by davenant.greenend.org.uk with local (Exim 3.12 #2) id 14MWac-0003PP-00 (Debian); Sat, 27 Jan 2001 14:44:30 +0000 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14962.57038.393827.36000@davenant.relativity.greenend.org.uk> Date: Sat, 27 Jan 2001 14:44:30 +0000 (GMT) To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability Newsgroups: chiark.mail.ietf.ipng In-Reply-To: <20010126172910.22474.qmail@cr.yp.to> References: <20010125194553.20465.qmail@cr.yp.to> <3480.980525266@brandenburg.cs.mu.OZ.AU> <20010126172910.22474.qmail@cr.yp.to> <14961.62982.978316.834738@davenant.relativity.greenend.org.uk> <14962.9444.676319.300018@davenant.relativity.greenend.org.uk> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk D. J. Bernstein writes ("Re: An easy example of A6 unreliability"): > The SIG semantics don't have to be modified. When the server copies the > A record, it can also move it into its own zone, sign it, and change the > NS record accordingly. I complained: > This would I think be rather poor practice on the part of the server. > Signing something just because someone else signed something is not > usually a good idea, [...] In fact, you can set it up so that it's not necessary for the server to re-sign the A's for the nameservers into the parent zone. Consider a nameserver for example.com. If we have something like example.com NS ns0.iana.org foobar.iana.org A 10.0.0.1 then the obvious problem is that the client can't verify the signature on the A because the packet syntax makes it hard to make it clear which key signed it, and that the client doesn't necessarily have (and maybe will have trouble finding and verifying) the relevant zone key. However, in fact this is just the this surface problem. It arises because of the deeper problem that the cryptographic delegation structure is wrong. The key which signs the A doesn't really have anything to do with the key for example.com. The example.com key doesn't explicitly delegate to the key to [foobar.]iana.org; instead, it merely names iana.org and expects the general secure DNS infrastructure to find the right key to sign that record. The crypto delegation path is from example.com via (implicitly) the global root key to the keys for org, iana.org and then possibly another zone key for foobar.iana.org if that's a subzone. This is totally insane. Instead, if you do this example.com NS ns0.iana.org ns0.example.com A 10.0.0.1 and forbid that ns0 is delegated, then the delegation path problem doesn't arise. Here the delegation path is quite simple: com delegates by signing the NS RR and the example.com zone key, and the example.com zone key itself signs the A. A client which has all of the relevant RRs can check the certificate chain, and hence the validity of the nameserver address, straight away. If the client *doesn't* get both the address RR and its signature from the original server for com, they have a problem. They can't check the signature on the A, so they don't know that it's valid. They probably shouldn't cache it and should vaoid using it. At best they could use it as a hint to try to find authenticated copies of the same data - or alternatively, they could make queries for the delegation address and its signature record from the parent server, which hopefully has a copy. So I'm coming to the conclusion that to get delegation to work sensibly with secure DNS, we have to require something like this: * Delegation NS hostnames must be in the zone being delegated to (and must have exactly one extra label?) * When serving up a delegation, the parent server must pass on the glue, including the glue's signature. What if it won't fit in the packet ? Perhaps the server should set TC and the client should retry with TCP, or perhaps the parent server for a delegation must be willing to serve up the glue, including its signature, in response to an explicit request. 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 Jan 29 03:46:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0TBiiL20440 for ipng-dist; Mon, 29 Jan 2001 03:44:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0TBiX220433 for ; Mon, 29 Jan 2001 03:44:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13024 for ; Mon, 29 Jan 2001 03:44:32 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10428 for ; Mon, 29 Jan 2001 03:44:32 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29180; Mon, 29 Jan 2001 06:44:31 -0500 (EST) Message-Id: <200101291144.GAA29180@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-uni-based-mcast-01.txt Date: Mon, 29 Jan 2001 06:44:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Unicast-Prefix-based IPv6 Multicast Addresses Author(s) : B. Haberman, D. Thaler Filename : draft-ietf-ipngwg-uni-based-mcast-01.txt Pages : 5 Date : 26-Jan-01 This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-uni-based-mcast-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010126120330.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-uni-based-mcast-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010126120330.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 Jan 30 12:54:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0UKp6F21538 for ipng-dist; Tue, 30 Jan 2001 12:51:06 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0UKp1221531 for ; Tue, 30 Jan 2001 12:51:01 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f0UKmtW05727 for ipng@sunroof.eng.sun.com; Tue, 30 Jan 2001 12:48:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0UE2Q221266; Tue, 30 Jan 2001 06:02:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21221; Tue, 30 Jan 2001 06:02:27 -0800 (PST) Received: from indiainfo.com ([203.199.75.248]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA26108; Tue, 30 Jan 2001 06:02:25 -0800 (PST) Received: from [203.197.138.194] (account ) by indiainfo.com (CommuniGate Pro WebUser 3.4b7) with HTTP id 12256574; Tue, 30 Jan 2001 19:29:19 +0530 From: "Niveda Monyvannan" Subject: Linux static route configuration for IPv6 To: users@ipv6.org, ipng@sunroof.eng.sun.com, 6bone@isi.edu, ngtrans@sunroof.eng.sun.com X-Mailer: CommuniGate Pro Web Mailer v.3.4b7 Date: Tue, 30 Jan 2001 19:29:19 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We are using Redhat (Version 7.0, kernel 2.2.16-22). We have built the IPV6 kernel and loaded. We have added global unicast address for an interface using ifconfig add option. We are not able to add ipv6 route for a network. We did not have inet6_route exe on the m/c. we installed net_tools 1.56-2 package and tried 'route --inet6 add 2001:: fe80::d0:96c:7a6c eth0'. It is failing. Any help for configuring routes for IPV6 would be appreciated. Regards, Niveda. ---------------------------------------- http://mail.indiainfo.com First you had 10MB of free mail space. Now you can send mails in your own language !!! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jan 30 14:21:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0UMJWB21684 for ipng-dist; Tue, 30 Jan 2001 14:19:32 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0UMJL221677 for ; Tue, 30 Jan 2001 14:19:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22734 for ; Tue, 30 Jan 2001 14:19:22 -0800 (PST) Received: from muncher.math.uic.edu (muncher.math.uic.edu [131.193.178.181]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA26968 for ; Tue, 30 Jan 2001 15:19:21 -0700 (MST) Received: (qmail 30993 invoked by uid 1001); 30 Jan 2001 22:19:39 -0000 Date: 30 Jan 2001 22:19:39 -0000 Message-ID: <20010130221939.27335.qmail@cr.yp.to> From: "D. J. Bernstein" To: ipng@sunroof.eng.sun.com Subject: Re: An easy example of A6 unreliability References: <20010125194553.20465.qmail@cr.yp.to> <3480.980525266@brandenburg.cs.mu.OZ.AU> <20010126172910.22474.qmail@cr.yp.to> <14961.62982.978316.834738@davenant.relativity.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ian Jackson writes: > Signing something just because someone else signed something is not > usually a good idea, and usually indicates a design error somewhere. As the owner of cr.yp.to, I hereby declare that whitehouse.cr.yp.to has addresses 198.137.240.91 and 198.137.240.92. I copied those addresses from whitehouse.gov. Why do you care? Why do you think it isn't a good idea for me to do this? ---Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 31 07:04:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0VF1j922264 for ipng-dist; Wed, 31 Jan 2001 07:01:45 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0VF1a222257 for ; Wed, 31 Jan 2001 07:01:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24994 for ; Wed, 31 Jan 2001 07:01:36 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10779 for ; Wed, 31 Jan 2001 08:01:35 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA11077 for ; Wed, 31 Jan 2001 08:01:34 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA18275 for ; Wed, 31 Jan 2001 08:01:34 -0700 (MST)] Received: from email.mot.com (d50-39be.cig.mot.com [160.47.57.190]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2651.58) id ZNMB7ZKD; Wed, 31 Jan 2001 09:01:33 -0600 Message-ID: <3A7845D3.FC4C10AA@email.mot.com> Date: Wed, 31 Jan 2001 09:05:23 -0800 From: Kevin Wang Reply-To: kwang1@email.mot.com Organization: Motorola X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Java 2 and IPv6? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, All, I am going to move from Network layer to Transport layer. Any one can tell if I can use Sun Java 2 for IPv6 programming? I mean does Java 2 support IPv6? Any pointer to the resources will be greatly appreciated. Kevin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 31 09:55:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0VHs7N22390 for ipng-dist; Wed, 31 Jan 2001 09:54:07 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0VHrw222383 for ; Wed, 31 Jan 2001 09:53:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12508 for ; Wed, 31 Jan 2001 09:53:57 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07030 for ; Wed, 31 Jan 2001 09:53:57 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id E216972501; Wed, 31 Jan 2001 19:53:55 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 59371BA03; Wed, 31 Jan 2001 19:53:55 +0200 (EET) Message-ID: <3A785133.76F2E7C1@nomadiclab.com> Date: Wed, 31 Jan 2001 19:53:55 +0200 From: Pekka Nikander X-Mailer: Mozilla 4.76 (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: kwang1@email.mot.com Cc: ipng@sunroof.eng.sun.com, janne.lundberg@hut.fi Subject: Re: Java 2 and IPv6? References: <3A7845D3.FC4C10AA@email.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kevin Wang wrote: > I am going to move from Network layer to Transport layer. Any one can > tell if I can use Sun Java 2 for IPv6 programming? I mean does Java 2 > support IPv6? > Any pointer to the resources will be greatly appreciated. As far as I know, Sun is considering IPv6 support for JDK 1.4. Unfortunately, I don't know anything about its schedule. On the other hand, Janne Lundberg of HUT created experimental IPv6 support for Linux JDK 1.3 (or was it JDK1.2.2) last summer. I don't know if he has made it publicly available, but maybe he could comment the state of the work himself. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jan 31 12:41:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) id f0VKYCD22488 for ipng-dist; Wed, 31 Jan 2001 12:34:12 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.2+Sun/8.11.2) with ESMTP id f0VKY3222481 for ; Wed, 31 Jan 2001 12:34:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18726 for ; Wed, 31 Jan 2001 12:33:58 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20333 for ; Wed, 31 Jan 2001 13:33:57 -0700 (MST) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA09400; Wed, 31 Jan 2001 20:33:52 GMT Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id UAA21408; Wed, 31 Jan 2001 20:33:51 GMT Date: Wed, 31 Jan 2001 20:33:51 +0000 (GMT) From: Tim Chown To: Pekka Nikander cc: kwang1@email.mot.com, ipng@sunroof.eng.sun.com, janne.lundberg@hut.fi Subject: Re: Java 2 and IPv6? In-Reply-To: <3A785133.76F2E7C1@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 31 Jan 2001, Pekka Nikander wrote: > As far as I know, Sun is considering IPv6 support for JDK 1.4. > Unfortunately, I don't know anything about its schedule. It seems IPv6/Java will be available from Sun sometime this summer, for 1.4. In the meantime... There was a presentation on a Java/v6 port called Jano at the Madrid event this week. The URLs I noted down were: http://sourceforge.net/projects/jano and http://www.dit.upm.es/~jsr/jano But I haven't looked at it yet. The chap said he hadn't spoken to Sun (he said he got fed up waiting, so he did the code..) 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 --------------------------------------------------------------------