From owner-ipng@sunroof.eng.sun.com Mon Nov 1 00:19:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA187Mx29676 for ipng-dist; Mon, 1 Nov 1999 00:07:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA1875i29669 for ; Mon, 1 Nov 1999 00:07:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA13360 for ; Mon, 1 Nov 1999 00:07:02 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA23136 for ; Mon, 1 Nov 1999 00:07:00 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id IA32509; Mon, 1 Nov 1999 19:06:50 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ipngwg-default-addr-select-00.txt In-Reply-To: Your message of "Fri, 29 Oct 1999 00:00:05 MST." <4D0A23B3F74DD111ACCD00805F31D81014515D77@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Nov 1999 19:06:45 +1100 Message-Id: <29718.941443605@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 29 Oct 1999 00:00:05 -0700 From: Richard Draves Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515D77@RED-MSG-50> | No, the effect is to mandate the strong host model for sending unless an | application or upper-layer specifies a source address. Which (aside from responding to incoming connections) means essentially all the time, as applications just don't specify source addresses usually (if the kernel can't work it out, the application certainly isn't likely to be able to, and your average human certainly doesn't want to be involved). | I don't know about the rest of you, but I want IPv6 to be a better protocol | than IPv4. Yes, of course, but the question is what is better. I think IPv6 is better than IPv4 regardless of how source address selection is specified. | I don't see the problem - the machine enables its routing functionality, so | it stops listening to router advertisements and can forward between its | interfaces. You mean it has become a router. That means it has started sending RAs. That means it has to be ready to forward packets for nodes that observe the RAs that have been sent, and ... | Then it downloads its configuration. Yes. Sure. I'm sure we'd all be happy to run routers that follow that boot up sequence. Thanks all the same, but the routers I use will fetch their (complete) configuration, and only then become a router - until everything is fetched, the box is a multi-interface host. | Yes, the routing protocol as an upper-layer or application could always | specify a source address. I would expect that routing protocols will do that, they're one of the few applications that actually cares. But routing protocols weren't the applications I had in mind here - the configuration will be fetched by tftp, or ftp, or something like that usually, and while inside the router which is still a host, the precise point down the stack where the source address is set is pretty much irrelevant, I think it makes a nonsense of the requirement if the solution is "pick your source address at line 100 rather than line 200, because if you do it at line 200 you have violated the RFC, where at line 100 you haven't..." | Why is that? I would expect the source address of the new connection to be | the address assigned to the outgoing interface. Because I want the replies to get to me, and with unidirectional interfaces there's no guarantee that anyone is necessarily going to be able to route to a send-only interface. In fact, if you're doing strict strong model stuff (which is an option, even if semi-strong is the common case) I would think that is pretty much essential. | Well I'm no expert on IETF requirements for standards. But if your argument | is carried to its conclusion then you're saying that there can be no | standard at all for source address selection because apps could always | override anything the standard said. Surely that's not right. No, it isn't. The IETF could make a standard that mandates the source address of packets, and simply not allow applications to set the address. If there's really a good reason to restrict what the source address should be, that's really what should be being done. That's entirely testable. On the other hand, I see little point in specifying how source addresses MUST be set by the kernel, if all that means is that application developers have to invent an /etc/ipv6-source-address file that they read, and then set the source address based upon what is in that file instead of allowing the kernel to do it. What gain could that be to anyone. That's why writing down "this is how we think source addresses should be selected" is a fine idea, but pretending to conditionally mandate it is silly. You MUST do it this way .. unless you don't want to! And all of this is one of the reasons that the IETF has generally avoided doing any kind of API specs. | I also want to agree with Francis, if the candidate set is opened up to | include addresses from interfaces other than the outgoing interface, then | it's not at all clear what the right circumstances are. You suggest scope. Yes. | But there's also deprecated addresses (the outgoing interface only has | deprecated addresses, another interface has a preferred address) and policy | preferences (sending to a 6to4 address, the outgoing interface only has a | native address but another interface has a 6to4 address), | longest-matching-prefix, etc. (I have a proposal on this at the very end.) Yes. All of these might be relevant. I don't think we know for sure yet. So perhaps the best solution is to simply stop attempting to mandate anything in this area (after all, it doesn't really affect either how the network works, or how one writes applications, so the benefits have to be small at best). | OK, now your example assumes that it will be best (= maximize chances of | successful communication) if the node uses source address GA. | It's not at all clear that's the case. It isn't certain, that's true. | For example the interfaces A & B may be connected to networks that don't | have any connectivity. (I use nodes configured like this every day.) So | although GD can be reached through interface B, GD can't send replies back | to GA. However GD may actually be on-link to interface B, so that using | source address LB would lead to successful communication. Yes, though in that circumstance I'd like to believe that the nodes will detect that, and use a link local destination address as well. I believe that can be automated (without DNS foolishness), and have been meaning to write down how it can be done. | I also have some thoughts on "unnumbered interfaces". I still can't see that | they are actually useful for v6. Fully unnumbered, yes, I agree, but interfaces with only limited scope I believe can be. | IPv6 has plenty of address space. It's the big feature. Yes, I know. | Tunnels can be given /126s. Yes, then can, but out of whose address space does that /126 come? One of the reasons for the use of unnumbered links (which predates the real pressure on IPv4 addresses incidentally - ie: they weren't invented as an address conservation measure) is that you really don't want the link between two sites to be using address space from either of them. This is out of my field, but I think it complicates routing and boundary case issues. That explains all of the DMZ type class C nets that abound. While buring /126s for inter-site links is probably a reasonable thing to do, buring /48s most likely isn't. That seems to apply only to routers, but doesn't really (and in any case the router/host distinction in this area I dimply don't believe). | About manageability: Simplicity leads to manageability, and | it's simpler to just give interfaces their own addresses instead of trying | to make unnumbered interfaces work. If "unnumbered" interfaces have to be "made to work" then yes, that would be true. On the other hand, if unnumbered interfaces "just work", then the advantages of not needing to race around picking subnet numbers, etc, would seem to be the easier (simpler) case. | However it seems people have come to love unnumbered interfaces and don't | want to give them up. So they should be supported. It also seems that | unnumbered interfaces are desired for routers, they're not an issue for | hosts. Not true. | So my conclusion so far for modifying the draft is: That isn't what I would do. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 1 06:58:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA1En2700078 for ipng-dist; Mon, 1 Nov 1999 06:49:02 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA1Emqi00071 for ; Mon, 1 Nov 1999 06:48:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA29872 for ; Mon, 1 Nov 1999 06:48:53 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23882 for ; Mon, 1 Nov 1999 06:48:52 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id C72D0152091 for ; Mon, 1 Nov 1999 08:48:51 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 84FA84FB01; Mon, 1 Nov 1999 08:48:47 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 235294C905; Mon, 1 Nov 1999 08:48:47 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000028325; Mon, 1 Nov 1999 09:48:50 -0500 (EST) From: Jim Bound Message-Id: <199911011448.JAA0000028325@quarry.zk3.dec.com> To: Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ipngwg-default-addr-select-00.txt In-reply-to: Your message of "Fri, 29 Oct 1999 00:00:05 PDT." <4D0A23B3F74DD111ACCD00805F31D81014515D77@RED-MSG-50> Date: Mon, 01 Nov 1999 09:48:50 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Rich, Just listening to all the chatter.....on the draft... which is good.. >I don't know about the rest of you, but I want IPv6 to be a better protocol >than IPv4. It already is now but this makes it better. >Well I'm no expert on IETF requirements for standards. But if your argument >is carried to its conclusion then you're saying that there can be no >standard at all for source address selection because apps could always >override anything the standard said. Surely that's not right. Well I for one don't care if its a standard. getipnodebyname and friends are not standards but we are all implementing them for interoperability. src addr select is the same thing. As far as I am concerned your draft goes to the top of things to write code for on IPv6 today. But I do think standardizing this is a good idea but we may need to make it a BCP, I think we need guidance from the chairs here? >I also want to agree with Francis, if the candidate set is opened up to >include addresses from interfaces other than the outgoing interface, then >it's not at all clear what the right circumstances are. You suggest scope. >But there's also deprecated addresses (the outgoing interface only has >deprecated addresses, another interface has a preferred address) and policy >preferences (sending to a 6to4 address, the outgoing interface only has a >native address but another interface has a 6to4 address), >longest-matching-prefix, etc. (I have a proposal on this at the very end.) Scope should be included but we know so little about it as carpenters building IPv6. But we need it. >However it seems people have come to love unnumbered interfaces and don't >want to give them up. So they should be supported. It also seems that >unnumbered interfaces are desired for routers, they're not an issue for >hosts. They must live they exist in the architecture and permitted. >So my conclusion so far for modifying the draft is: > >a) for routers, open up the candidate set to include addresses assigned to >all interfaces. (Or more precisely, the outgoing interface plus interfaces >that can internally forward the destination address to the outgoing >interface. link-local destinations can't be forwarded between interfaces, >site-local destinations can only be forwarded between interfaces in the same >site.) Well as you see the forwarding btw interfaces is being discussed now. For now I agree with Steve that the standard permits such behavior, whether we change that is TBD based on the discussion. I don't see the harm of it being in the architecture from the mail just yet but listening. So you need to keep it in the spec is my feeling until the WG decides its not part of the architecture, Sam's mail brought up the most undesirable property and one we need to think about. >>b) add a rule (between 5 & 6) preferring source addresses assigned to the >>outgoing interface. So scope, deprecated/preferred, and policy issues are >>all more important, and longest-matching-prefix is less important. Yes. I was going to let this go and just implement it. This was my issue with 6to4 mandating longest match but it appears no one was listening so I did not throw in the issue of "scope", which I had to deal with big time for the base api. /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 Mon Nov 1 08:36:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA1GL1C00353 for ipng-dist; Mon, 1 Nov 1999 08:21:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA1GKni00346 for ; Mon, 1 Nov 1999 08:20:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA08147 for ; Mon, 1 Nov 1999 08:20:49 -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 IAA05478 for ; Mon, 1 Nov 1999 08:20:48 -0800 (PST) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id IAA05718 for ; Mon, 1 Nov 1999 08:20:47 -0800 (PST) Message-Id: <4.2.0.58.19991101081713.03b2f5e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 01 Nov 1999 08:18:10 -0800 To: ipng@sunroof.eng.sun.com From: The IESG (by way of Bob Hinden ) Subject: Protocol Action: OSPF for IPv6 to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'OSPF for IPv6' as a Proposed Standard. This document is the product of the Open Shortest Path First IGP Working Group. The IESG contact persons are David Oran and Rob Coltun. Technical Summary OSPFv6 is an updated version of the Open Shortest Path First routing protocol which has been in widepread use as an interior gateway protocol with IPv4 for a number of years. OSPFv6 enhances the protocol so that it may be used as an IGP for IP version 6. The fundamental mechanisms of OSPF (flooding, DR election, area support, SPF calculations, etc.) remain unchanged. However, some changes and enhancements were made. Addressing semantics have been removed from OSPF packets and the basic LSAs (link state advertisements). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis, using IPv6 link-local addresses, instead of on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol itself, instead relying on IPv6's Authentication Header and Encapsulating Security Payload. All of OSPF for IPv4's optional capabilities, including on-demand circuit support, NSSA areas, and the multicast extensions to OSPF (MOSPF) are also supported in OSPF for IPv6. Working Group Summary There was unanimous agreement within the working group that this protocol is ready for Proposed Standard status. Consensus was also unanimous on the technical content of the document. Protocol Quality The protocol was reviewed for the IESG by Dave Oran. There are two implementations, as described in Section 4 of draft-ietf-ospf-ospfv3-stdreport-00.txt. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 1 09:08:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA1GtTR00418 for ipng-dist; Mon, 1 Nov 1999 08:55:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA1GtJi00411 for ; Mon, 1 Nov 1999 08:55:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12831 for ; Mon, 1 Nov 1999 08:55:19 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA23652 for ; Mon, 1 Nov 1999 08:55:18 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 01 Nov 1999 08:54:37 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Mon, 1 Nov 1999 08:54:36 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515D98@RED-MSG-50> From: Richard Draves To: "'sm@bossette.engr.sgi.com'" , ipng@sunroof.eng.sun.com Subject: RE: ND on multi-homed nodes Date: Mon, 1 Nov 1999 08:54:19 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I see on a Solaris box we have (which is still running 2.5, so this > may have changed) that there are multiple network routes allowed > and there is a route for fe80::/10 for each interface. I assume > that stack performs ND for each route. Is this how others have > tackled this? No, we either pick one interface or we return an error, depending on what's in the routing table and whether the application has specified an interface in some way. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 1 12:06:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA1JqK800782 for ipng-dist; Mon, 1 Nov 1999 11:52:20 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA1JqFi00775 for ; Mon, 1 Nov 1999 11:52:15 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA00721 for ipng@sunroof.eng.sun.com; Mon, 1 Nov 1999 11:52:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA1Iewi00719 for ; Mon, 1 Nov 1999 10:40:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA15464 for ; Mon, 1 Nov 1999 10:40:57 -0800 (PST) Received: from nimitz.ca.sandia.gov (nimitz.ca.sandia.gov [146.246.243.56]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08524 for ; Mon, 1 Nov 1999 11:40:55 -0700 (MST) Received: (from bmah@localhost) by nimitz.ca.sandia.gov (8.9.3/8.9.3) id KAA88525; Mon, 1 Nov 1999 10:40:50 -0800 (PST) Message-Id: <199911011840.KAA88525@nimitz.ca.sandia.gov> X-Mailer: exmh version 2.1.0 09/18/1999 To: ipng@sunroof.eng.sun.com Cc: bmah@CA.Sandia.GOV Subject: RFC2553 and sockaddr_in6.sin6_flowinfo From: bmah@CA.Sandia.GOV (Bruce A. Mah) Reply-To: bmah@CA.Sandia.GOV X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Url: http://www.ca.sandia.gov/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_720593101P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 01 Nov 1999 10:40:50 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --==_Exmh_720593101P Content-Type: text/plain; charset=us-ascii Dumb question: According to RFC 2553 (sections 3.3 and 3.4), in a sockaddr_in6, the sin6_flowinfo member is supposed to hold the "IPv6 traffic class & flow info". Why is this member defined as a uint32_t, rather than as a struct that could allow manipulation of the traffic class and flow without resorting to bitshifting and htonl()/ntohl()? Just curious...thanks in advance. Bruce. --==_Exmh_720593101P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: SSAUMID28VBzyu1C+sDUBDwoZ7EqcG4l iQA/AwUBOB3esdjKMXFboFLDEQKAngCdGEiW4/L24rY6JoW+ecohY27cpVcAoPwn rhvLPSoChCwTdvIO5yt1kotI =NmC5 -----END PGP SIGNATURE----- --==_Exmh_720593101P-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 1 13:28:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA1LAYh00898 for ipng-dist; Mon, 1 Nov 1999 13:10:34 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA1LAMi00888 for ; Mon, 1 Nov 1999 13:10:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA27131 for ; Mon, 1 Nov 1999 13:10:21 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05306 for ; Mon, 1 Nov 1999 13:10:19 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 46D19152040; Mon, 1 Nov 1999 15:10:18 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id F09D8BC4C4; Mon, 1 Nov 1999 15:10:12 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 891C3B2A43; Mon, 1 Nov 1999 15:10:12 -0600 (CST) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000024612; Mon, 1 Nov 1999 16:10:17 -0500 (EST) Date: Mon, 1 Nov 1999 16:10:17 -0500 (EST) From: Jack McCann Message-Id: <199911012110.QAA0000024612@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com, sm@bossette.engr.sgi.com Subject: Re: ND on multi-homed nodes Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If the user has not specified the interface (e.g. set sin6_scope_id), we pick one for them. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 1 14:37:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA1MIfk01034 for ipng-dist; Mon, 1 Nov 1999 14:18:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA1MIPi01027 for ; Mon, 1 Nov 1999 14:18:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA20335 for ; Mon, 1 Nov 1999 14:18:25 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10868 for ; Mon, 1 Nov 1999 15:18:25 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA21284; Mon, 1 Nov 1999 14:11:50 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA33968; Mon, 1 Nov 1999 14:15:52 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA42803; Mon, 1 Nov 1999 14:15:51 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911012215.OAA42803@bossette.engr.sgi.com> Subject: Re: ND on multi-homed nodes To: mccann@zk3.dec.com (Jack McCann) Date: Mon, 1 Nov 1999 14:15:50 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911012110.QAA0000024612@quarry.zk3.dec.com> from "Jack McCann" at Nov 1, 99 04:10:17 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jack McCann wrote: > If the user has not specified the interface (e.g. set sin6_scope_id), > we pick one for them. Yes, I was thinking about ease of porting IPv4 apps to IPv6. Changing sockaddr to sockaddr_storage and using getipnodebyname() instead of gethostbyname() is easy. Having to parse scope ids is a pain, as is using getaddrinfo() IMO. Is there a case here for adding an extra parameter to getipnodebyname() to pass back the scope_id? Since porting to IPv6 requires recompilation anyway, one could also add a field to struct hostent, I guess. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 1 19:11:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA22s9U01639 for ipng-dist; Mon, 1 Nov 1999 18:54:09 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA22rwi01632 for ; Mon, 1 Nov 1999 18:54:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA25579 for ; Mon, 1 Nov 1999 18:53:58 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08772 for ; Mon, 1 Nov 1999 19:53:56 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id LAA21658; Tue, 2 Nov 1999 11:42:53 +0900 (JST) Date: Tue, 02 Nov 1999 11:52:28 +0900 Message-ID: <14366.20972.214621.9106S@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sm@bossette.engr.sgi.com Cc: mccann@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Sun, 31 Oct 1999 13:55:12 -0800 (PST)" <199910312155.NAA38208@bossette.engr.sgi.com> References: <199910281438.KAA0000031715@quarry.zk3.dec.com> <199910312155.NAA38208@bossette.engr.sgi.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 77 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 31 Oct 1999 13:55:12 -0800 (PST), >>>>> sm@bossette.engr.sgi.com (Sam Manthorpe) said: > Jack McCann wrote: >> A stray thought... >> >> [S|s]: >> >> where "S" is for "Scope" but it could be any character not >> currently allowed in a literal IPv6 address. > I like this proposal a lot. I agree scope-id should come first, for > the reasons already posted here Do you mean by "the reasons posted here" that scope-id should be the most significant part of the address? If so, what do you think of the question that I posted here: >>>>> On Thu, 28 Oct 1999 01:26:49 +0900, I said: > Is it so obvious that the scope_id part is the most significant part? > I'm not sure. It seems to me that we could recognize (for example) a > link-local address as follows: > 1. Look at the 1st 16 (or at least 10) bits of the address (fe80) and > recognize that this is a link-local address. i.e. this is the most > significant part. > 2. Then look at the scope identifier and recognize to which link the > address should belong. (In this scenario, the scope id is the 2nd > significant part) > 3. Finally use the host id part of the address (i.e. the last 64 bits) > to identify the node that the address specifies in the link. > So I feel the appropriate portion for the scope_id is subtle. However, > I don't stick to the idea that the scope id should be after an > address. I'd respect others' opinions. [back to your original message] > and using [s|S] instead of punctuation > mark avoids the old `but in shell this is interpreted as a ' > discussions. Hmm...I agree that using an alphabetical character would be safe in order to avoid the useless discussion. One thing that I fear is that a combination of alphabetical and numerical characters before (or after) an IPv6 address separated by ":" would incur less readability. For example, isn't the following address S12A:FEC0::123:4567:89AB:CDEF a bit confusing? Though it's not syntactically ambiguous (because "S" never appears in an IPv6 literal address), people might misread the syntax and think it represents an IPv6 address *without* any scope identifier. Am I a worrier? > Since is very generic > in terms of what one uses for delimiters and scope-ids, the only > real difference here is the sequence of the three elements, so this > is a minor change. That's right. As I said in an earlier message, I intentionally opened the specific syntax in the initial revision of the draft, because I knew we needed more discussion on this point. When we get a consensus, I'll wrap up the discussion and revise the draft with a more specific syntax (including the sequence of the elements). > Now, if only struct hostent used sockaddrs porting apps to IPv6 would > be easy. Exactly (though I believe we should use struct addrinfo instead of struct hostent). This is the goal we intended in the draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 1 21:06:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA24puO01702 for ipng-dist; Mon, 1 Nov 1999 20:51:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA24pli01695 for ; Mon, 1 Nov 1999 20:51:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA11376 for ; Mon, 1 Nov 1999 20:51:46 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA10110 for ; Mon, 1 Nov 1999 20:51:46 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA08269; Mon, 1 Nov 1999 20:44:57 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id UAA47541; Mon, 1 Nov 1999 20:49:00 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id UAA44439; Mon, 1 Nov 1999 20:48:57 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911020448.UAA44439@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: jinmei@isl.rdc.toshiba.co.jp (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Mon, 1 Nov 1999 20:48:57 -0800 (PST) Cc: mccann@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <14366.20972.214621.9106S@condor.isl.rdc.toshiba.co.jp> from "JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" at Nov 2, 99 11:52:28 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jinmei, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > > I like this proposal a lot. I agree scope-id should come first, for > > the reasons already posted here > > Do you mean by "the reasons posted here" that scope-id should be the > most significant part of the address? If so, what do you think of the > question that I posted here: Yes. > >>>>> On Thu, 28 Oct 1999 01:26:49 +0900, I said: > > > Is it so obvious that the scope_id part is the most significant part? > > I'm not sure. It seems to me that we could recognize (for example) a > > link-local address as follows: > > > 1. Look at the 1st 16 (or at least 10) bits of the address (fe80) and > > recognize that this is a link-local address. i.e. this is the most > > significant part. > > 2. Then look at the scope identifier and recognize to which link the > > address should belong. (In this scenario, the scope id is the 2nd > > significant part) > > 3. Finally use the host id part of the address (i.e. the last 64 bits) > > to identify the node that the address specifies in the link. > > > So I feel the appropriate portion for the scope_id is subtle. However, > > I don't stick to the idea that the scope id should be after an > > address. I'd respect others' opinions. Yes, I kind of agree with you about the `2nd most significant part' but not 100% (as you say, it's subtle :-) In the prototype implementation we have in IRIX, scope-ids are unique system wide, over all address types. i.e. you cannot have a site-local and link-local with the same scope-id. Intuitively, I feel the scope-id belongs -somewhere- up there near the address type end of the address descriptor and putting it before the start of the address is clearly preferable to trying to incorporate it in 2nd order position. Putting the scope-id at the tail address goes against my personal intuition, but this is clearly a grey area. > [back to your original message] > > > and using [s|S] instead of punctuation > > mark avoids the old `but in shell this is interpreted as a ' > > discussions. > > Hmm...I agree that using an alphabetical character would be safe in > order to avoid the useless discussion. One thing that I fear is that a > combination of alphabetical and numerical characters before (or after) > an IPv6 address separated by ":" would incur less readability. For > example, isn't the following address > > S12A:FEC0::123:4567:89AB:CDEF > > a bit confusing? Though it's not syntactically ambiguous (because "S" > never appears in an IPv6 literal address), people might misread the > syntax and think it represents an IPv6 address *without* any scope > identifier. Am I a worrier? I agree it kind of looks like that. Is this a bad thing? I suppose it is in the sense that IPv6 addresses are free to be sent between hosts by applications or humans whereas scope-ids are not. > Exactly (though I believe we should use struct addrinfo instead of > struct hostent). This is the goal we intended in the draft. Yes, using getaddrinfo() does solve that problem. Personally I don't like getaddrinfo() but I'm clearly in the minority :-) (actually I don't like scoped addresses either :-) As I said before, it is far preferable to me when explaining to programmers how to port to IPv6 to use simple things like replace gethostbyname() with getipnodebyname() etc, rather than having to explain the complexity of getaddrinfo() with all its semantic knobs and whistles and the non-trivial code reworking it requires. But that's another thread... If there was a way to avoid obsoleting getipnodeby*() due to scoped-address complexity, I would be happy. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 2 05:29:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA2DHwd01958 for ipng-dist; Tue, 2 Nov 1999 05:17:58 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA2DHmi01951 for ; Tue, 2 Nov 1999 05:17:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA01425 for ; Tue, 2 Nov 1999 05:17:47 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08648 for ; Tue, 2 Nov 1999 06:17:44 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id WAA24440; Tue, 2 Nov 1999 22:08:00 +0900 (JST) Date: Tue, 02 Nov 1999 22:17:33 +0900 Message-ID: <14366.58477.996200.62282F@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sm@bossette.engr.sgi.com Cc: ipng@sunroof.eng.sun.com Subject: Re: ND on multi-homed nodes In-Reply-To: In your message of "Sat, 30 Oct 1999 12:25:31 -0700 (PDT)" <199910301925.MAA33790@bossette.engr.sgi.com> References: <199910301925.MAA33790@bossette.engr.sgi.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 46 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 30 Oct 1999 12:25:31 -0700 (PDT), >>>>> sm@bossette.engr.sgi.com (Sam Manthorpe) said: > I'm not following the list 100%, so my apologies in advance if this > is a stupid/already answered question. Address resolution of link-local > addresses on multi-homed nodes appears to require neighbour discovery > on all interfaces of that node. I was wondering how others have > decided to implement this as I would like to follow the norm (if > there is one) for IRIX. Our (KAME's) kernel basically requires a link identifier when the kernel tries to resolve a link-layer address of an IPv6 link-local address. If no identifier is given but there is a default route, the kernel will just send packets to the default router without address resolution (I don't think this is a good behavior, though). Otherwise, the kernel will return an error. > I see on a Solaris box we have (which is still running 2.5, so this > may have changed) that there are multiple network routes allowed > and there is a route for fe80::/10 for each interface. I assume > that stack performs ND for each route. Is this how others have > tackled this? I don't think this (i.e. performing ND for each interface) is a good approach, since uniqueness of link-local addresses is not guaranteed at all when we consider more than one link; you could get NAs on different links in response to an NS targeting a link-local address. Which NA should we believe in such a case? By the way, ND on different links itself is not fully specified in the spec (i.e. RFC 2461) regardless of the scope of addresses in question, IMHO. For example, APPENDIX A of the RFC says as follows: There are a number of complicating issues that arise when Neighbor Discovery is used by hosts that have multiple interfaces. This section does not attempt to define the proper operation of multihomed hosts with regard to Neighbor Discovery. Rather, it identifies issues that require further study. I remember that someone (itojun?) pointed it out in the interim meeting in Tokyo, but I'm not sure the result (if any). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 2 06:11:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA2E3Ca01991 for ipng-dist; Tue, 2 Nov 1999 06:03:12 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA2E32i01984 for ; Tue, 2 Nov 1999 06:03:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA09574 for ; Tue, 2 Nov 1999 06:03:03 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18385 for ; Tue, 2 Nov 1999 06:03:03 -0800 (PST) Received: from [10.19.130.188] ([10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id GAA04804; Tue, 2 Nov 1999 06:02:16 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <14366.58477.996200.62282F@condor.isl.rdc.toshiba.co.jp> References: <199910301925.MAA33790@bossette.engr.sgi.com> <14366.58477.996200.62282F@condor.isl.rdc.toshiba.co.jp> Date: Tue, 2 Nov 1999 06:02:20 -0800 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: ND on multi-homed nodes Cc: sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:17 PM +0900 11/2/99, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Our (KAME's) kernel basically requires a link identifier when the >kernel tries to resolve a link-layer address of an IPv6 link-local >address. If no identifier is given but there is a default route, the >kernel will just send packets to the default router without address >resolution (I don't think this is a good behavior, though). Ah, here's another example of where a router might have to forward a link-local-destined packet. :-) I think you ought to have a notion of a "primary" or "default" interface that is used when the upper layer tried to send to a non-global address but does not specify the outgoing interface or scope zone. The same concept is already needed for multicasts, for similar reasons. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 2 07:47:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA2FYK102102 for ipng-dist; Tue, 2 Nov 1999 07:34:20 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA2FY9i02095 for ; Tue, 2 Nov 1999 07:34:11 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA16097 for ; Tue, 2 Nov 1999 07:34:10 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA21264 for ; Tue, 2 Nov 1999 07:34:09 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 3D806152143; Tue, 2 Nov 1999 09:34:09 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id E1C084FB06; Tue, 2 Nov 1999 09:34:03 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 89DC84C903; Tue, 2 Nov 1999 09:34:03 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000002336; Tue, 2 Nov 1999 10:34:07 -0500 (EST) From: Jim Bound Message-Id: <199911021534.KAA0000002336@quarry.zk3.dec.com> To: bmah@CA.Sandia.GOV Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC2553 and sockaddr_in6.sin6_flowinfo In-reply-to: Your message of "Mon, 01 Nov 1999 10:40:50 PST." <199911011840.KAA88525@nimitz.ca.sandia.gov> Date: Tue, 02 Nov 1999 10:34:07 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Dumb question: Good question. >According to RFC 2553 (sections 3.3 and 3.4), in a sockaddr_in6, the >sin6_flowinfo member is supposed to hold the "IPv6 traffic class & flow >info". Why is this member defined as a uint32_t, rather than as a >struct that could allow manipulation of the traffic class and flow >without resorting to bitshifting and htonl()/ntohl()? We left the field as uint32_t becasuse we were not given a green light on the flowlabel if it is done being broken down or if additional bits may be needed to support other functions or subfunctions within the flowlabel set of bits, or if a certain number of bits in the flowlabel even if not subdivided may cause indirection from the bit pattern. Hence, felt it wise to just define it as 32bit field. Another reason is that we are pretty sure of the alignment of uint field not causing problems for the sockaddr_in6 structure for those wanting to use the portability section of the spec. The field can always be loaded into a typedef for processing too. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 2 12:39:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA2KHh702541 for ipng-dist; Tue, 2 Nov 1999 12:17:43 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA2KHYi02534 for ; Tue, 2 Nov 1999 12:17:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA12142 for ; Tue, 2 Nov 1999 12:17:33 -0800 (PST) From: Alex_Conta@ne.3com.com Received: from smtp.NE.3Com.COM (smtp.ne.3com.com [151.104.25.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23511 for ; Tue, 2 Nov 1999 13:17:32 -0700 (MST) Received: from usboxmta.ne.3com.com (usboxmta.NE.3Com.COM [151.104.25.34]) by smtp.NE.3Com.COM (Pro-8.9.3/Pro-8.9.3) with SMTP id PAA15255; Tue, 2 Nov 1999 15:17:25 -0500 (EST) Received: by usboxmta.ne.3com.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525681D.007198AB ; Tue, 2 Nov 1999 15:40:46 -0500 X-Lotus-FromDomain: 3COM To: Steve Deering cc: ipng@sunroof.eng.sun.com, Richard Draves Message-ID: <8525681D.005CA97C.00@usboxmta.ne.3com.com> Date: Tue, 2 Nov 1999 15:20:21 -0500 Subject: RE: draft-ipngwg-default-addr-select-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, You may be right: your document will clarify the issues discussed and we could also have an off-line discussion to eliminate any confusion. But would like to underline on the list that, from my side, this discussion takes or took place because THE COST OF IPv6 UNICAST FORWARDING ENGINES IS A CONCERN. To sum-up, prior to this thread, in some people's understanding (wishful perhaps), the IPv6 UNICAST FORWARDING was ONE MECHANISM, that applied to all unicast destination addresses, with one SIMPLE exception: packets with LINK-LOCAL address destination WERE NOT FORWARDED. The exception was SIMPLE and COST EFFICIENT because it didn't require any additional mechanism. Also part of the sum-up, we (in this discussion) seem to contemplate two models: --------- MODEL I. 1. The IPv6 UNICAST FORWARDING consists of ONE MECHANISM, based on the longest prefix match. 2. The IPv6 UNICAST FORWARDING is based on a service model, in which **the destination address carries the entire forwarding information**. 3. IP v6 LINK-LOCAL UNICAST FORWARDING is excluded. because packets that do not carry topological information in their destination address require additional mechanisms to be forwarded. 4. IPv6 UNICAST FORWARDING can achieve any packet delivery order - traffic engineering- on a link, site, organization, or the global Internet, by using the right combination of destination addresses that contain topological information, and routing extension header. MODEL II. 1. The IPv6 UNICAST FORWARDING consists of SEVERAL MECHANISMS, of which one is based on the longest prefix match. Each mechanims is different froThe mechanisms are different separate 2. The IPv6 GLOBAL and SITE UNICAST FORWARDING are based on the topological information carried in the unicast destination address. 3. The IPv6 LINK FORWARDING is based on link information, which is not carried in the packet header destination address. This information is configured or gathered through some other mechanisms -- that need definition -- and allows packets to be forwarded on the same link, when a node has one or more interfaces connected to that same link. 4. IPv6 UNICAST FORWARDING can achieve any packet delivery order - traffic engineering- on a link, site, organisation, or the global Internet, by using the right combination of destination addresses and routing extension header. ------------- Note or conclusion: 1. both models achieve over-all the same packet delivery functions. 2. MODEL I is simpler and cheaper than MODEL II because it consists of ONE MECHANISM. 3. the restriction of MODEL I in regards of link-local forwarding, applies to a very low frequency occurrence, and it can be circumvented by site, or global address use. 4. the absence of the restriction in MODEL II has an additional cost that pays off in a case that has a reduced frequency of occurrence: nodes that have more than one interface connected to the same link. Alex Steve Deering on 10/29/99 08:23:19 PM Sent by: Steve Deering To: Alex Conta/US/3Com cc: Richard Draves , ipng@sunroof.eng.sun.com Subject: RE: draft-ipngwg-default-addr-select-00.txt At 4:15 PM -0400 10/29/99, Alex_Conta@ne.3com.com wrote: >I see the connection with site-local addresses. > >But the site filtering is easy, without any additional stuff, and the >matter of configuring a site border router is a *one, two, but not many >more* boxes matter. Alex, I don't know why you are leaping to the conclusion that my suggestion implies the need to configure many boxes. The sensible default for every box will be assume that each interface is attached to a different link. Only those boxes for which that assumption is false would have to be configured, which today is a very, very small number of boxes. If in the future it becomes more common for nodes to have multiple interfaces attached to the same link, we could easily develop a protocol to automatically detect that situation and autoconfigure the link-to- interface-set relationship. > Site addresses do not present a problem because all >routers on a site will forward site local packets on all interfaces, >EXCEPT: > > - the interfaces that have the "same site subnet ID", and > - the interfaces that are marked as connected to links that "go >outside" the site. > >Such interfaces (that "go outside") may be marked by simply configuring >them with NO site addresses. I'm confused by what you are saying, above, which seems to indicate that we have different models in our heads of how site scopes work. I guess my slides in Tokyo weren't enough to get us on the same page, and I know I have to get the document done that I promised on this topic. One aspect of the confusion is that you seem to be thinking in terms of a router distinguishing only between "inside" and "outside" a single site, whereas the model I have is that a router should be capable of being attached to multiple sites (via different interfaces), not just a single site. I'm not sure email is the best way to resolve our model mismatch -- let me work on my document, and we can also talk in Washington. At 4:49 PM -0400 10/29/99, Alex_Conta@ne.3com.com wrote: >Why would one put link local addresses in a router extension header? To force the packet to go from one node on a link, through another node on the same link, to reach a third node on the same link. > A link-local address has no topological information, albeit a site-local >address has: the subnet number, or ID, which makes a crucial difference: >site local packets can be forwarded within the site. For forwarding non-global addresses, you must take into account which interface it arrived on, or more accurately, which zone it arrived from (which is a piece of topological information). This is true for both link-local and site-local addresses. The (possibly only conceptual) link-local routing table within a router for each of its attached links is trivial, and does not require any topological information to be embedded in link-local addresses to work. In the normal case of a single interface, I, to a single link L, the link-local routing table for that link looks like this: next-hop = upper-layer FF80::/10 next-hop = I In the case of two interfaces, I1 and I2, to a single link L, the table looks like this: next-hop = upper-layer next-hop = upper-layer FF80::/10 next-hop = I1 FF80::/10 next-hop = I2 There is (conceptually) a separate such table for each link, and you use knowledge of the arrival interface of a link-local-destined packet to determine which table to use to forward such a packet. At 6:29 PM -0400 10/29/99, Alex_Conta@ne.3com.com wrote: >Phylosphically, and technically, if you forward, then you need to know >where to forward, and if the >destination does not tell you anything about "where", then there must be a >different place, or state, or mechanism that provides you the "where". Yes, in this case, the state is knowledge of your own link-local address(es) and knowledge of the arrival interface (or link). That is all that is necessary to make a forwarding decision for link-local destinations. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 2 13:50:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA2LVgK02662 for ipng-dist; Tue, 2 Nov 1999 13:31:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA2LVQi02655 for ; Tue, 2 Nov 1999 13:31:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA29062 for ; Tue, 2 Nov 1999 13:31:21 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA00554 for ; Tue, 2 Nov 1999 13:31:20 -0800 (PST) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id NAA12252; Tue, 2 Nov 1999 13:31:13 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <8525681D.005CA97C.00@usboxmta.ne.3com.com> References: <8525681D.005CA97C.00@usboxmta.ne.3com.com> Date: Tue, 2 Nov 1999 13:31:16 -0800 To: Alex_Conta@ne.3com.com From: Steve Deering Subject: RE: draft-ipngwg-default-addr-select-00.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, I disagree with your characterization of the issue. I think you are the one arguing for two mechanisms: one for link-locals and another for the other unicast scopes. I am arguing for a *single* mechanism -- longest-match look-up -- operating (conceptually) on multiple different routing tables (FIBs), one for each attached scope zone. >1. both models achieve over-all the same packet delivery functions. No, I don't think your model handles all the site-local cases. >2. MODEL I is simpler and cheaper than MODEL II because it consists of ONE >MECHANISM. No, my model consists of one mechanism. Your model consists of one mechanism plus special-case handling of link-locals, which is effectively a second mechanism. >3. the restriction of MODEL I in regards of link-local forwarding, applies >to a very low frequency occurrence, and it can be circumvented by site, or >global address use. No, we don't know that link-local communication will be low frequency in all cases. There may be scenarios (e.g., home networks) where there is significant link-local communication (e.g., audio packets from a stereo to some speakers). >4. the absence of the restriction in MODEL II has an additional cost that >pays off in a case that has a reduced frequency of occurrence: nodes that >have more than one interface connected to the same link. No, the absence of a restriction in my model has no additional cost, because special-case code for restricting link-locals is *absent*. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 2 14:43:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA2MCsb02700 for ipng-dist; Tue, 2 Nov 1999 14:12:54 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA2MCoi02693 for ; Tue, 2 Nov 1999 14:12:50 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id OAA01410 for ipng@sunroof.eng.sun.com; Tue, 2 Nov 1999 14:12:45 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA2Ebgi02039 for ; Tue, 2 Nov 1999 06:37:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA12021 for ; Tue, 2 Nov 1999 06:37:42 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01650 for ; Tue, 2 Nov 1999 07:37:37 -0700 (MST) Received: from lt.eth.ericsson.se (lt.eth.ericsson.se [164.48.158.205]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA26347 for ; Tue, 2 Nov 1999 15:37:35 +0100 (MET) Received: from demokritos.danubius by lt.eth.ericsson.se (8.8.8+Sun/SMI-SVR4) id PAA23533; Tue, 2 Nov 1999 15:37:33 +0100 (MET) Received: from eth.ericsson.se (localhost [127.0.0.1]) by demokritos.danubius (8.8.8+Sun/8.8.8) with ESMTP id PAA16035 for ; Tue, 2 Nov 1999 15:37:31 +0100 (MET) Message-ID: <381EF72A.86AC1F40@eth.ericsson.se> Date: Tue, 02 Nov 1999 15:37:30 +0100 From: Tamas Varga Organization: ETH/R/LT Ericsson Hungary - Traffic Lab X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Q: ipv6AddrAddress MIB variable Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello IPNGers, Excuse me for the bandwidth waste, if it was already discussed why ipv6AddrAddress has "not-accessible" access option in the ivp6 MIB (RFC2465). Is it a misprint, or there is some conceptual decision behind it. In the latter case, please give me a hint how to obtain the IPv6 addresses of an IPv6 host/router. Thanks in advance. Tomi -- Tamas Varga - ERICSSON Hungary, Traffic Lab Tamas.Varga.II@eth.ericsson.se H-1300 Budapest, Pf. 107 +36-1-437-7087 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 2 14:45:35 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA2MFm902713 for ipng-dist; Tue, 2 Nov 1999 14:15:48 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA2MFTi02706 for ; Tue, 2 Nov 1999 14:15:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA06455 for ; Tue, 2 Nov 1999 14:15:30 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA12836 for ; Tue, 2 Nov 1999 15:15:02 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Nov 1999 13:46:59 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Tue, 2 Nov 1999 13:46:59 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515DD1@RED-MSG-50> From: Richard Draves To: "'Robert Elz'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ipngwg-default-addr-select-00.txt Date: Tue, 2 Nov 1999 13:46:43 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | So my conclusion so far for modifying the draft is: > > That isn't what I would do. We've had a very good discussion, but I think further progress will require more input and viewpoints from others in the working group. Below I have some specific responses to a few points. > | I don't see the problem - the machine enables its routing > functionality, so > | it stops listening to router advertisements and can > forward between its > | interfaces. > > You mean it has become a router. That means it has started > sending RAs. > That means it has to be ready to forward packets for nodes > that observe the > RAs that have been sent, and ... No, until it has finished configuring itself it can send RAs with a zero router lifetime. > | Why is that? I would expect the source address of the new > connection to be > | the address assigned to the outgoing interface. > > Because I want the replies to get to me, and with > unidirectional interfaces > there's no guarantee that anyone is necessarily going to be > able to route > to a send-only interface. In fact, if you're doing strict > strong model > stuff (which is an option, even if semi-strong is the common > case) I would > think that is pretty much essential. The routing is easy to handle. One possibility is to assign addresses to both interfaces (the incoming and outgoing unidirectional interfaces) out of the same prefix and have that prefix be routed to the incoming unidirectional link. A strict strong model doesn't work for unidirectional links. It needs to be relaxed on the sending side and/or the receiving side. I am not proposing a strict strong model. Of course this is all hypothetical. No one has put on the table a complete proposal for how unidirectional links should work. We should not preclude someone from doing this in the future, and I think the proposed rules in the draft would let unidirectional links work in fairly natural ways. > | Well I'm no expert on IETF requirements for standards. > But if your argument > | is carried to its conclusion then you're saying that > there can be no > | standard at all for source address selection because apps > could always > | override anything the standard said. Surely that's not right. > > No, it isn't. The IETF could make a standard that mandates > the source > address of packets, and simply not allow applications to set > the address. > If there's really a good reason to restrict what the source > address should > be, that's really what should be being done. That's > entirely testable. > > On the other hand, I see little point in specifying how > source addresses > MUST be set by the kernel, if all that means is that > application developers > have to invent an /etc/ipv6-source-address file that they > read, and then set > the source address based upon what is in that file instead of > allowing the > kernel to do it. What gain could that be to anyone. > > That's why writing down "this is how we think source > addresses should be > selected" is a fine idea, but pretending to conditionally > mandate it is > silly. You MUST do it this way .. unless you don't want to! > > And all of this is one of the reasons that the IETF has > generally avoided > doing any kind of API specs. I'll defer to the working group chairs, IESG members, & others with more standards experience on whether source address selection can be the subject of a standard and whether such a standard can say MUST to the network layer but let upper-layers, apps, and administrators override the network layer. > So perhaps the best solution is to simply stop attempting to mandate > anything in this area (after all, it doesn't really affect either how > the network works, or how one writes applications, so the > benefits have > to be small at best). But I do think the default address selection rules in hosts could and probably will have a BIG effect on how the network works. > | For example the interfaces A & B may be connected to > networks that don't > | have any connectivity. (I use nodes configured like this > every day.) So > | although GD can be reached through interface B, GD can't > send replies back > | to GA. However GD may actually be on-link to interface B, > so that using > | source address LB would lead to successful communication. > > Yes, though in that circumstance I'd like to believe that the > nodes will > detect that, and use a link local destination address as > well. I believe > that can be automated (without DNS foolishness), and have > been meaning to > write down how it can be done. I don't think it can be automated (without increasing the load on the network by sending test packets). There's no way to tell by inspection of a destination address whether the destination address is really on-link. Whether the address matches a prefix in the On-Link Prefix List is just a hint. > | Tunnels can be given /126s. > > Yes, then can, but out of whose address space does that /126 come? One side or the other, doesn't matter. This is how the 6bone tunnels that I have right now work. > One of the reasons for the use of unnumbered links (which predates the > real pressure on IPv4 addresses incidentally - ie: they > weren't invented > as an address conservation measure) is that you really don't want the > link between two sites to be using address space from either of them. > This is out of my field, but I think it complicates routing > and boundary > case issues. That explains all of the DMZ type class C nets > that abound. It's beyond my expertise too. In any case, I've already agreed that IPv6 should support "unnumbered" interfaces on point-to-point links. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 2 19:32:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA332gB03054 for ipng-dist; Tue, 2 Nov 1999 19:02:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA332Ui03044 for ; Tue, 2 Nov 1999 19:02:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA29567 for ; Tue, 2 Nov 1999 19:02:30 -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 TAA00627 for ; Tue, 2 Nov 1999 19:02:29 -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 MAA22160 for ; Wed, 3 Nov 1999 12:02:23 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: getnameinfo(3) behavior on short string region From: itojun@iijlab.net Date: Wed, 03 Nov 1999 12:02:22 +0900 Message-ID: <22158.941598142@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, if you do the following: char h[2]; getnameinfo(sa, sa->sa_len, h, sizeof(h), NULL, 0, NI_NUMERICHOST) getnameinfo from NRL code fills in 1 letter into the buffer (h) and returns without error. getnameinfo from KAME code will raise error (by returning non-zero). Which behavior is more correct/natural/desired? There's nothing said in RFC2553. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 2 21:50:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA35lxI03196 for ipng-dist; Tue, 2 Nov 1999 21:47:59 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA35loi03185 for ; Tue, 2 Nov 1999 21:47:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA01186 for ; Tue, 2 Nov 1999 20:29:25 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19813 for ; Tue, 2 Nov 1999 20:29:23 -0800 (PST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id WAA12462; Tue, 2 Nov 1999 22:29:21 -0600 (CST) Date: Tue, 2 Nov 1999 22:29:21 -0600 (CST) From: David Borman Message-Id: <199911030429.WAA12462@frantic.bsdi.com> To: ipng@sunroof.eng.sun.com, itojun@iijlab.net Subject: Re: getnameinfo(3) behavior on short string region Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Subject: getnameinfo(3) behavior on short string region > From: itojun@iijlab.net > Date: Wed, 03 Nov 1999 12:02:22 +0900 > > > Hello, if you do the following: > > char h[2]; > getnameinfo(sa, sa->sa_len, h, sizeof(h), NULL, 0, NI_NUMERICHOST) > > getnameinfo from NRL code fills in 1 letter into the buffer (h) > and returns without error. getnameinfo from KAME code will raise error > (by returning non-zero). Which behavior is more > correct/natural/desired? There's nothing said in RFC2553. On page 30, RFC2553 says: The caller specifies not to return either string by providing a zero value for the hostlen or servlen arguments. Otherwise, the caller must provide buffers large enough to hold the nodename and the service name, including the terminating null characters. Even though it's not what I implemented when I first wrote a getnameinfo() function, having thought about it I'd read this part as saying that if the buffer is too small, returning an error is the right thing. Silently truncating the numeric string could be dangerous, especially if you wind up dropping just the last digit, since both could be valid IP addresses. E.g, if you have a 12 byte buffer and you are using the address for ftp.ietf.org, 132.151.1.19, with truncation (11 bytes plus a NULL) you'd get "132.151.1.1" instead, which would not be good. -David Borman, dab@bsdi.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 Nov 2 21:53:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA35plX03232 for ipng-dist; Tue, 2 Nov 1999 21:51:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA35pci03225 for ; Tue, 2 Nov 1999 21:51:38 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA11142 for ; Tue, 2 Nov 1999 17:11:17 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29233 for ; Tue, 2 Nov 1999 17:11:16 -0800 (PST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA01586; Wed, 3 Nov 1999 12:05:44 +1100 (EST) Date: Wed, 3 Nov 1999 12:05:44 +1100 (EST) From: Peter Tattam To: Steve Deering cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: ND on multi-homed nodes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 2 Nov 1999, Steve Deering wrote: > At 10:17 PM +0900 11/2/99, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >Our (KAME's) kernel basically requires a link identifier when the > >kernel tries to resolve a link-layer address of an IPv6 link-local > >address. If no identifier is given but there is a default route, the > >kernel will just send packets to the default router without address > >resolution (I don't think this is a good behavior, though). > > Ah, here's another example of where a router might have to forward a > link-local-destined packet. :-) > > I think you ought to have a notion of a "primary" or "default" interface > that is used when the upper layer tried to send to a non-global address > but does not specify the outgoing interface or scope zone. The same > concept is already needed for multicasts, for similar reasons. > > Steve > A thought on this... I know this is probably a pathelogical case, but if the transport layer can't work out which interface to send it, could it not start an ND on all interfaces and then only use the one where the ND arrives. If the link local address is generated using auto config, the probably of a clash would be low. Also the information is likely to be in the ND cache already if a node has already received a packet on one of the interfaces. You might need another ND state to identify ND probes which are speculative. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 3 10:30:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA3IR6h04093 for ipng-dist; Wed, 3 Nov 1999 10:27:06 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA3IQwi04084 for ; Wed, 3 Nov 1999 10:26:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA23219 for ; Wed, 3 Nov 1999 10:26:57 -0800 (PST) Received: from ns.nexabit.com (d28.nexabit.com [209.6.34.253]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA23817 for ; Wed, 3 Nov 1999 11:26:56 -0700 (MST) Received: by neonet_server1.nexabit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 3 Nov 1999 13:27:17 -0500 Message-ID: <1180113EC576D011AADE0060975B88B3A129F4@neonet_server1.nexabit.com> From: Dimitry Haskin To: Tamas Varga , ipng@sunroof.eng.sun.com Subject: RE: ipv6AddrAddress MIB variable Date: Wed, 3 Nov 1999 10:22:39 -0500 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tomi, ipv6AddrAddress is "not-accessible" since it serves as an index in ipv6AddrTable. ipv6AddrAddress can not be modified for any given table row. To obtain the IPv6 addresses of an IPv6 node you simply walk the ipv6AddrTable. ---------------------------------------------------------------------- Dimitry Haskin Lucent Technologies Internetworking Systems > -----Original Message----- > From: Tamas Varga [mailto:Tamas.Varga.II@eth.ericsson.se] > Sent: Tuesday, November 02, 1999 9:38 AM > To: ipng@sunroof.eng.sun.com > Subject: Q: ipv6AddrAddress MIB variable > > > Hello IPNGers, > > Excuse me for the bandwidth waste, if it was already > discussed why ipv6AddrAddress has "not-accessible" access > option in the ivp6 MIB (RFC2465). Is it a misprint, or > there is some conceptual decision behind it. In the latter > case, please give me a hint how to obtain the IPv6 addresses > of an IPv6 host/router. Thanks in advance. > > Tomi > > -- > Tamas Varga - ERICSSON Hungary, Traffic Lab > Tamas.Varga.II@eth.ericsson.se > H-1300 Budapest, Pf. 107 > +36-1-437-7087 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 3 10:45:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA3IgAL04153 for ipng-dist; Wed, 3 Nov 1999 10:42:10 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA3Ig2i04146 for ; Wed, 3 Nov 1999 10:42:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA11463 for ; Wed, 3 Nov 1999 07:30:43 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01493 for ; Wed, 3 Nov 1999 08:30:42 -0700 (MST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id ED3AA1520F1; Wed, 3 Nov 1999 09:30:41 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 7D840BC4C2; Wed, 3 Nov 1999 09:30:33 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 1C203B2A44; Wed, 3 Nov 1999 09:30:33 -0600 (CST) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000003702; Wed, 3 Nov 1999 10:30:40 -0500 (EST) Date: Wed, 3 Nov 1999 10:30:40 -0500 (EST) From: Jack McCann Message-Id: <199911031530.KAA0000003702@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com, itojun@iijlab.net Subject: Re: getnameinfo(3) behavior on short string region Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > char h[2]; > getnameinfo(sa, sa->sa_len, h, sizeof(h), NULL, 0, NI_NUMERICHOST) > > getnameinfo from NRL code fills in 1 letter into the buffer (h) > and returns without error. getnameinfo from KAME code will raise error > (by returning non-zero). Which behavior is more > correct/natural/desired? There's nothing said in RFC2553. The latest version of the X/Open Networking Services definition for getnameinfo() contains this text: On successful completion, function getnameinfo() returns the node and service names, if requested, in the buffers provided. The returned names are always null-terminated strings, and may be truncated if the actual values are longer than can be stored in the buffers provided. If the returned values are to be used as part of any further name resolution (for example, passed to getaddrinfo()), callers must either provide buffers large enough to store any result possible on the system or must check for truncation and handle that case appropriately. Coincidently, this text was introduced via a change request from NRL. Unfortunately, there is no mechanism specified with which to accomplish the "check for truncation". If Craig Metz is listening perhaps he can comment... - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 3 19:25:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA43Mse04687 for ipng-dist; Wed, 3 Nov 1999 19:22:54 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA43Mki04680 for ; Wed, 3 Nov 1999 19:22:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA05471 for ; Wed, 3 Nov 1999 19:22:46 -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 UAA14350 for ; Wed, 3 Nov 1999 20:22:45 -0700 (MST) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id TAA26403; Wed, 3 Nov 1999 19:22:44 -0800 (PST) Message-Id: <4.2.0.58.19991103192115.039889a0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 03 Nov 1999 19:21:44 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Proposed IPng Agenda for Washington DC IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the proposed agenda for IPng w.g. sessions at the Washington D.C. IETF. Both sessions will be multicast. Please send me changes, additions, and corrections. Thanks, Bob ------------------------------------------------------------------- WEDNESDAY, November 10, 1999 1300-1500 (Regency) Introduction / R. Hinden (5 min) Review Agenda / R. Hinden (5 min) Document Status / R. Hinden (10 min) Summary of Tokyo Interim Meeting / S. Deering (10 min) IPv6 extensions to RPC / S. Majee (15 min) TAHI IPv6 Interoperability Test Report H. Miyata (10 min) IPv6 Socket Scrubber / C. Williams (10 min) Connection/Link Status Investigation (CSI) / H. Kitamura (10 min) Unidirectional Link Routing / H. Afifi (5 min) IPng Statement on Privacy / S. Deering (5 min) Privacy Issues w/ Addrconf / Anonymous (20 min) THURSDAY, November 11, 1999 1300-1500 (Regency) Wireless Telephony / C. Perkins (30) Source Address Selection Draft (R. Draves) / S. Deering (30 min) Text Syntax for Scoped Addresses / T. Jinmmi (15 min) Inverse ARP / A. Conta (10 min) ------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 3 21:09:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4573H04718 for ipng-dist; Wed, 3 Nov 1999 21:07:03 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA456si04711 for ; Wed, 3 Nov 1999 21:06:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA07590 for ; Wed, 3 Nov 1999 21:06:53 -0800 (PST) From: Alex_Conta@ne.3com.com Received: from smtp.NE.3Com.COM (smtp.ne.3com.com [151.104.25.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA20021 for ; Wed, 3 Nov 1999 22:06:53 -0700 (MST) Received: from usboxmta.ne.3com.com (usboxmta.NE.3Com.COM [151.104.25.34]) by smtp.NE.3Com.COM (Pro-8.9.3/Pro-8.9.3) with SMTP id AAA02513; Thu, 4 Nov 1999 00:06:50 -0500 (EST) Received: by usboxmta.ne.3com.com(Lotus SMTP MTA v1.1 (385.6 5-6-1997)) id 8525681F.001E3D9E ; Thu, 4 Nov 1999 00:30:18 -0500 X-Lotus-FromDomain: 3COM To: Steve Deering cc: ipng@sunroof.eng.sun.com Message-ID: <8525681F.00198CD3.00@usboxmta.ne.3com.com> Date: Thu, 4 Nov 1999 00:09:51 -0500 Subject: link local packet forwarding -- it was RE: draft-ipngwg-default -addr-select-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >Alex, > >I disagree with your characterization of the issue. Your message points even more to the need of a document, or an explanation or conceptual model with details of how these mechanisms fit together. Otherwise the potential for missinterpretations and disagreements will perpetuate. If the mechanism that you envisaged and will document, works, and is universal, this is all beautiful and I WILL BE HAPPIER than I was with any other mechanisms. The concept of link-local packet forwarding is at the border of possible interpretations. Link-Local addresses are designed to be used for addressing on a single link for purposes such as auto-address configuration, neighbor discovery, or when no routers are present. A router receiving a link-local packet should act like a host: if it is not the host to which the packet is sent to, then it should discard the packet With the hope that you take this constructively, architecturally, in regarding scoped addresses, IMO, IPv6 should be consistent with the unicast forwarding as we know it. If a unicast packet has IP topology information then it is forwarded, otherwise it is not. Hence, a "link" is a "zone" with zero (NO) IP forwarding, (but of course with link specific forwarding/switching), while a "site" is a "zone" with IP forwarding. Otherwise, IMO, a convincing case for link-local forwarding is still to be made, and furthermore, the issues and side effects of inadvertent packet duplication, and forwarding are still to be resolved. I would urge you to make the information available to the list even in pieces, since the document, if it were an I-D, didn't make the 46th meeting dead-line, and a presentation in a WG, like in previous cases, still may leave room for assumptions, or speculations, which one is still too many, for building solid, deployable, forwarding engines. Thanks. >[...] >>1. both models achieve over-all the same packet delivery functions. > >No, I don't think your model handles all the site-local cases. Yes. It does. While a node can be on several sites, an interface is ON or OFF a site, i.e. it is supposed to be attached to not more than one site (draft-ietf-ipngwg-site-prefixes-03.txt,draft-ietf-ipngwg-scoped-routing-01 .txt). >>2. MODEL I is simpler and cheaper than MODEL II because it consists of ONE >>MECHANISM. > >No, my model consists of one mechanism. Your model... No. I am sorry! Model I is not mine. I'm sorry MODEL I is not mine. Regarding the NO forwarding of link-local packets, I think it is everybody's model, since it is so widely implemented. >...consists of one >mechanism plus special-case handling of link-locals, which is effectively >a second mechanism. No. NO FORWARDING is in programming language a "return", which is the END of a protocol engine mechanism, and NOT A SECOND mechanism. >>3. the restriction of MODEL I in regards of link-local forwarding, applies >>to a very low frequency occurrence, and it can be circumvented by site, or >>global address use. > >No, we don't know that link-local communication will be low frequency in >all cases. There may be scenarios (e.g., home networks) where there is >significant link-local communication (e.g., audio packets from a stereo >to some speakers). No. I refer to link-local forwarding, NOT link-local communication. YES. A node with two or more interfaces on the same link, and therefore Link-local forwarding, is a low frequency occurence (you mentioned it in a previous message). Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 3 22:12:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA465QW04747 for ipng-dist; Wed, 3 Nov 1999 22:05:26 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA464si04740 for ; Wed, 3 Nov 1999 22:04:54 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA929062; Wed, 3 Nov 1999 22:04:52 -0800 (PST) Date: Wed, 3 Nov 1999 22:04:46 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: Sam Manthorpe Cc: Jack McCann , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199910312155.NAA38208@bossette.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Now, if only struct hostent used sockaddrs porting apps to IPv6 would > be easy. Why not just use getaddrinfo instead of getipnodebyname? This might mean changing 20 lines of code compared to 10 lines of code with getipnodebyname (for a port of trivial example code to the new API). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 3 22:42:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA46e6b04789 for ipng-dist; Wed, 3 Nov 1999 22:40:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA46dbi04782 for ; Wed, 3 Nov 1999 22:39:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA10595; Wed, 3 Nov 1999 22:39:35 -0800 (PST) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA11984; Wed, 3 Nov 1999 22:39:35 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA01890; Wed, 3 Nov 1999 22:40:35 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA61161; Wed, 3 Nov 1999 22:39:31 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id WAA51455; Wed, 3 Nov 1999 22:39:29 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911040639.WAA51455@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: Erik.Nordmark@eng.sun.com Date: Wed, 3 Nov 1999 22:39:29 -0800 (PST) Cc: mccann@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Erik Nordmark" at Nov 3, 99 10:04:46 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > Why not just use getaddrinfo instead of getipnodebyname? > This might mean changing 20 lines of code compared to 10 lines of code > with getipnodebyname (for a port of trivial example code to the new API). Because the semantics of getipnodebyname() are very similar to those of gethostbyname() whereas the semantics of getaddrinfo() are not only more complex but _different_. I'm not disputing that getaddrinfo() is a nice, powerful function that solves the problem in an elegant fashion, but I would be happier if porting applications to use IPv6 were made as easy as possible. I think at the very least getipnodebyname() should ignore scope-ids in a literal address; what I would really like would be for it to be able to pass the scope-id back to the app somehow. Why not add a field to struct hostent? As an aside, has anybody implemented scope-ids in their name resolution code? How does NIS handle this for example? Thanks, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 3 23:22:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA47J9E04854 for ipng-dist; Wed, 3 Nov 1999 23:19:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA47J0i04847 for ; Wed, 3 Nov 1999 23:19:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA07199; Wed, 3 Nov 1999 23:19:00 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11162; Thu, 4 Nov 1999 00:18:59 -0700 (MST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id BAA03979; Thu, 4 Nov 1999 01:19:03 -0600 (CST) Date: Thu, 4 Nov 1999 01:19:03 -0600 (CST) From: David Borman Message-Id: <199911040719.BAA03979@frantic.bsdi.com> To: Erik.Nordmark@eng.sun.com, sm@bossette.engr.sgi.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: sm@bossette.engr.sgi.com (Sam Manthorpe) > Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt > Date: Wed, 3 Nov 1999 22:39:29 -0800 (PST) > > Erik Nordmark wrote: > > Why not just use getaddrinfo instead of getipnodebyname? > > This might mean changing 20 lines of code compared to 10 lines of code > > with getipnodebyname (for a port of trivial example code to the new API). > > Because the semantics of getipnodebyname() are very similar to those > of gethostbyname() whereas the semantics of getaddrinfo() are not > only more complex but _different_. I'm not disputing that getaddrinfo() > is a nice, powerful function that solves the problem in an elegant > fashion, but I would be happier if porting applications to use IPv6 > were made as easy as possible. I think at the very least > ... I'll just put in my $.02 again... Converting an AF_INET/gethostbyname() application to AF_INET6/getipnodebyname() is straight forward, but it assumes that the resulting binary will only be run on systems that support AF_INET6. If you take your binary, and try and run it on a kernel that does not have AF_INET6 support, it won't work. I like using getaddrinfo() because the resulting binary will work with both IPv6 and IPv4 addresses on kernels built with AF_INET6 support, and will still work with IPv4 addresses on kernels built without AF_INET6 support, since it will open up an AF_INET socket for an IPv4 address, instead of an AF_INET6 socket with an IPv4-mapped IPv6 address. We (BSDI) ship with IPv6 support, but we don't require that everyone build their kernels with IPv6 support. We ship one set of binaries that work both with and without IPv6 kernel support. I don't expect everyone to agree with me, and I won't try and convince those that feel that getipnodebyname() is sufficient. As long as your kernels always have AF_INET6 support, things will work just fine with AF_INET6/getipnodebyname(). But it just seems to me that getaddrinfo() provides a cleaner solution to multiple protocol support. (Of course, you could use IN6_IS_ADDR_V4MAPPED() to check the returned address from getipnodebyname(), and if it is one, then open an AF_INET socket instead of an AF_INET6 socket, and pull out the IPv4 address from the mapped address and fill in a sockaddr_in structure. Then your binary will run on non-AF_INET6 kernels. But if you do all that work, you might as well have just used getaddrinfo() in the first place, and have much cleaner looking code.) -David Borman, dab@bsdi.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 Nov 4 04:47:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4CjAr05044 for ipng-dist; Thu, 4 Nov 1999 04:45:10 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4Cj2i05037 for ; Thu, 4 Nov 1999 04:45:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA27977 for ; Thu, 4 Nov 1999 04:45:01 -0800 (PST) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27073 for ; Thu, 4 Nov 1999 04:44:59 -0800 (PST) Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id NAA19651; Thu, 4 Nov 1999 13:44:56 +0100 (MET) Received: (from nisse@localhost) by sanna.lysator.liu.se (8.8.8/8.8.7) id NAA00093; Thu, 4 Nov 1999 13:44:51 +0100 (MET) To: Jack McCann Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt References: <199910281438.KAA0000031715@quarry.zk3.dec.com> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 04 Nov 1999 13:44:45 +0100 In-Reply-To: Jack McCann's message of "Thu, 28 Oct 1999 10:38:17 -0400 (EDT)" Message-ID: Lines: 30 X-Mailer: Gnus v5.4.59/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jack McCann writes: > > Through the discussion so far, '@' seems bad for the delimiter and '-' > > seems acceptable. Does anyone have any other suggestions? > > A stray thought... > > [S|s]: > > where "S" is for "Scope" but it could be any character not > currently allowed in a literal IPv6 address. I'll throw in a cent or two as well... I'm not entirely sure in which contexts these siteid+address strings will be used. There are many contexts where you can use an "address" which can be either an ip4 address, an ip6 address, or a _dns_name_. Optionally followed by a separator (typically :) and a numeric port number or symbolic service name. If there is any chance that a site+address string will be useful in those contexts, it's important that the namespaces don't intersect, and that they are reasonably simple to distinguish. Using a character that is valid in a dns name ("s" "S" and "-" are all in this category) seems suboptimal. I would almost suggest using site/address. But perhaps that collides with the address/bits notation? /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 4 06:19:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4EFEV05178 for ipng-dist; Thu, 4 Nov 1999 06:15:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4EF5i05171 for ; Thu, 4 Nov 1999 06:15:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA26298 for ; Thu, 4 Nov 1999 06:15:05 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22094 for ; Thu, 4 Nov 1999 06:15:05 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id EBC1E9A9F3; Thu, 4 Nov 1999 08:15:04 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id EB55BBC4CB; Thu, 4 Nov 1999 08:14:52 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 8950EB2A42; Thu, 4 Nov 1999 08:14:52 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000015631; Thu, 4 Nov 1999 09:15:03 -0500 (EST) From: Jim Bound Message-Id: <199911041415.JAA0000015631@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: getnameinfo(3) behavior on short string region In-reply-to: Your message of "Tue, 02 Nov 1999 22:29:21 CST." <199911030429.WAA12462@frantic.bsdi.com> Date: Thu, 04 Nov 1999 09:15:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Per Daves response attached. I believe Dave's response is correct (thx Dave). But I want to point out that we (the IETF) have no control over getnameinfo or getaddrinfo it is a POSIX and XNET issue. This is why we did not touch nor extend these APIs from Info rfc2133 to rfc2553. I suggest if you or others see behaviors in these APIs which have errors to contact your XNET representative or IEEE representative on the POSIX committee. Clearly telling us on this list the error exists is useful, but we can't do anything here about it. Just like if XNET finds errors in UDP they can't do anything about it and must come to the IETF. This is one reason (and I have many) I will not use these APIs but prefer getipnodebyname and friends. Note this is a personal choice as a programmer and not the view of my company or necessarily the views of my colleagues who work on IPv6 with me. /jim >> Subject: getnameinfo(3) behavior on short string region >> From: itojun@iijlab.net >> Date: Wed, 03 Nov 1999 12:02:22 +0900 >> >> >> Hello, if you do the following: >> >> char h[2]; >> getnameinfo(sa, sa->sa_len, h, sizeof(h), NULL, 0, NI_NUMERICHOST) >> >> getnameinfo from NRL code fills in 1 letter into the buffer (h) >> and returns without error. getnameinfo from KAME code will raise error >> (by returning non-zero). Which behavior is more >> correct/natural/desired? There's nothing said in RFC2553. > >On page 30, RFC2553 says: > > The caller specifies not to return either string by providing a zero > value for the hostlen or servlen arguments. Otherwise, the caller > must provide buffers large enough to hold the nodename and the > service name, including the terminating null characters. > >Even though it's not what I implemented when I first wrote a getnameinfo() >function, having thought about it I'd read this part as saying that if >the buffer is too small, returning an error is the right thing. Silently >truncating the numeric string could be dangerous, especially if you wind up >dropping just the last digit, since both could be valid IP addresses. > >E.g, if you have a 12 byte buffer and you are using the address for >ftp.ietf.org, 132.151.1.19, with truncation (11 bytes plus a NULL) >you'd get "132.151.1.1" instead, which would not be good. -David Borman, dab@bsdi.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 Nov 4 07:26:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4FMkg05269 for ipng-dist; Thu, 4 Nov 1999 07:22:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4FMbi05262 for ; Thu, 4 Nov 1999 07:22:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA14928 for ; Thu, 4 Nov 1999 07:22:38 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06712 for ; Thu, 4 Nov 1999 08:22:36 -0700 (MST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id JAA05151; Thu, 4 Nov 1999 09:22:07 -0600 (CST) Date: Thu, 4 Nov 1999 09:22:07 -0600 (CST) From: David Borman Message-Id: <199911041522.JAA05151@frantic.bsdi.com> To: bound@zk3.dec.com, itojun@iijlab.net Subject: Re: getnameinfo(3) behavior on short string region Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > From: Jim Bound > Subject: Re: getnameinfo(3) behavior on short string region > Date: Thu, 04 Nov 1999 09:15:03 -0500 > ... > I believe Dave's response is correct (thx Dave). But I want to point > out that we (the IETF) have no control over getnameinfo or getaddrinfo > it is a POSIX and XNET issue. This is why we did not touch nor > extend these APIs from Info rfc2133 to rfc2553. I suggest if you or You are forgetting that only the getaddrinfo() function was taken from POSIX 1003.1g, not getnameinfo(). RFC2133/2553 is the definition of getnameinfo(). From page 29 of RFC 2553: The POSIX 1003.1g specification includes no function to perform the reverse conversion from getaddrinfo(): to look up a nodename and service name, given the binary address and port. Therefore, we define the following function: So while RFC2553 deferes to POSIX for the definition of getaddrinfo(), we do have control over getnameinfo(), and can correct the definition as we see fit. -David Borman, dab@bsdi.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 Nov 4 07:43:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4FeQa05301 for ipng-dist; Thu, 4 Nov 1999 07:40:26 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4FeGi05291 for ; Thu, 4 Nov 1999 07:40:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA03322 for ; Thu, 4 Nov 1999 07:40:16 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22928 for ; Thu, 4 Nov 1999 07:40:16 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 08A559AA11; Thu, 4 Nov 1999 09:40:16 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 17C5ABC4C6; Thu, 4 Nov 1999 09:40:04 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 97398B2A45; Thu, 4 Nov 1999 09:40:03 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000030979; Thu, 4 Nov 1999 10:40:13 -0500 (EST) From: Jim Bound Message-Id: <199911041540.KAA0000030979@quarry.zk3.dec.com> To: Erik Nordmark Cc: Sam Manthorpe , Jack McCann , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Wed, 03 Nov 1999 22:04:46 PST." Date: Thu, 04 Nov 1999 10:40:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Now, if only struct hostent used sockaddrs porting apps to IPv6 would >> be easy. > >Why not just use getaddrinfo instead of getipnodebyname? >This might mean changing 20 lines of code compared to 10 lines of code >with getipnodebyname (for a port of trivial example code to the new API). I don't agree. the inline code to change from gethostbyname to getipnodebyname is much more explicable and supporting addded trans mechanisms. see our programming examples at: www.ipv6.zk3-x.dec.com click on "Porting Guide" using getipnodebyname is more familiar to most programmers who use sockets we keep the semantics and the core inline logic of the code remains in tact you add the conditions of v4/v6. getaddrinfo and friends changes the programming paradigm a bit and what you must feed that api engine. I predict most will stay with getipnodebyname and as Sam stated previously its a pain. /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 Thu Nov 4 07:46:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4FjFK05334 for ipng-dist; Thu, 4 Nov 1999 07:45:15 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4Fj6i05327 for ; Thu, 4 Nov 1999 07:45:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA13882 for ; Thu, 4 Nov 1999 07:45:06 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25035 for ; Thu, 4 Nov 1999 07:45:03 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 00FA19AA46; Thu, 4 Nov 1999 09:45:02 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id EA4E7BC4CB; Thu, 4 Nov 1999 09:44:50 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 62B3CB2A4A; Thu, 4 Nov 1999 09:44:50 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000031972; Thu, 4 Nov 1999 10:45:01 -0500 (EST) From: Jim Bound Message-Id: <199911041545.KAA0000031972@quarry.zk3.dec.com> To: David Borman Cc: Erik.Nordmark@eng.sun.com, sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Thu, 04 Nov 1999 01:19:03 CST." <199911040719.BAA03979@frantic.bsdi.com> Date: Thu, 04 Nov 1999 10:45:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk dave, done it both ways and have code running with getipnodebyname. getipnodebyname when you ship v4 and v6 binaries. I agree with sam.......... also works nice with utilities like ifconfig, netstat, tcpdump etc. we have a choice lets leave it that and not get into a religious debate as I think that is what it will generate too. /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 Thu Nov 4 07:58:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4FtbW05366 for ipng-dist; Thu, 4 Nov 1999 07:55:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4FtRi05359 for ; Thu, 4 Nov 1999 07:55:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA18982 for ; Thu, 4 Nov 1999 07:55:27 -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 HAA29495 for ; Thu, 4 Nov 1999 07:55:26 -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 AAA12363; Fri, 5 Nov 1999 00:53:41 +0900 (JST) To: Jim Bound cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Thu, 04 Nov 1999 10:40:13 EST. <199911041540.KAA0000030979@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt From: itojun@iijlab.net Date: Fri, 05 Nov 1999 00:53:41 +0900 Message-ID: <12361.941730821@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Why not just use getaddrinfo instead of getipnodebyname? >>This might mean changing 20 lines of code compared to 10 lines of code >>with getipnodebyname (for a port of trivial example code to the new API). >I don't agree. the inline code to change from gethostbyname to >getipnodebyname is much more explicable and supporting addded trans >mechanisms. >see our programming examples at: www.ipv6.zk3-x.dec.com >click on "Porting Guide" I believe it is up to readers to choose, so I would like to show you URLs describing migration to getaddrinfo/getnameinfo: http://playground.iijlab.net/newsletter/19990630/ http://www.kame.net/newsletter/19980604/ (bit dated, need update) I personally prefer getaddrinfo/getnameinfo. It made my code much simpler, since you always manipulate sockaddr_xx (as res->ai-addr), not in_addr nor in6_addr. I use getaddrinfo/getnameinfo everywhere and am trying very hard to stay away from gethostby* or getipnodeby*. 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 Nov 4 08:09:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4G67N05385 for ipng-dist; Thu, 4 Nov 1999 08:06:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4G5wi05378 for ; Thu, 4 Nov 1999 08:05:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA20033 for ; Thu, 4 Nov 1999 08:05:59 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04685 for ; Thu, 4 Nov 1999 08:05:58 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id 3EAB09AA4B; Thu, 4 Nov 1999 10:05:34 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 765484FB13; Thu, 4 Nov 1999 10:05:24 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 087794C902; Thu, 4 Nov 1999 10:05:24 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000002671; Thu, 4 Nov 1999 11:05:33 -0500 (EST) From: Jim Bound Message-Id: <199911041605.LAA0000002671@quarry.zk3.dec.com> To: David Borman Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: getnameinfo(3) behavior on short string region In-reply-to: Your message of "Thu, 04 Nov 1999 09:22:07 CST." <199911041522.JAA05151@frantic.bsdi.com> Date: Thu, 04 Nov 1999 11:05:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk good point dave... I think getnameinfo should be given to XNET then. /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 Thu Nov 4 08:11:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4G9h105412 for ipng-dist; Thu, 4 Nov 1999 08:09:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4G9Pi05396 for ; Thu, 4 Nov 1999 08:09:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA20451 for ; Thu, 4 Nov 1999 08:09:26 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06248 for ; Thu, 4 Nov 1999 08:09:25 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id DEB6657A4D; Thu, 4 Nov 1999 10:09:24 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 03735BC4C6; Thu, 4 Nov 1999 10:09:13 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 96BA8B2A44; Thu, 4 Nov 1999 10:09:12 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000003982; Thu, 4 Nov 1999 11:09:23 -0500 (EST) From: Jim Bound Message-Id: <199911041609.LAA0000003982@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Fri, 05 Nov 1999 00:53:41 +0900." <12361.941730821@coconut.itojun.org> Date: Thu, 04 Nov 1999 11:09:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk and i find it simpler to use getipnodebyname......... no one is going to win this discussion.......... /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 Thu Nov 4 08:48:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4Gji305544 for ipng-dist; Thu, 4 Nov 1999 08:45:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4GjSi05529 for ; Thu, 4 Nov 1999 08:45:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA25258 for ; Thu, 4 Nov 1999 08:45:29 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13621 for ; Thu, 4 Nov 1999 09:45:12 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA01951; Fri, 5 Nov 1999 01:35:33 +0900 (JST) Date: Fri, 05 Nov 1999 00:51:12 +0900 Message-ID: <14369.43888.750576.62749T@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sm@bossette.engr.sgi.com Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Wed, 3 Nov 1999 22:39:29 -0800 (PST)" <199911040639.WAA51455@bossette.engr.sgi.com> References: <199911040639.WAA51455@bossette.engr.sgi.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 16 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 3 Nov 1999 22:39:29 -0800 (PST), >>>>> sm@bossette.engr.sgi.com (Sam Manthorpe) said: > As an aside, has anybody implemented scope-ids in their name resolution > code? How does NIS handle this for example? We (KAME) has implemented scope-id support as an extension to getaddrinfo() and getnameinfo(), as described in the scopedaddr-format draft. But it may not be what you want... As for NIS, we don't take care of it for now. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 4 08:49:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4GjkR05545 for ipng-dist; Thu, 4 Nov 1999 08:45:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4GjVi05534 for ; Thu, 4 Nov 1999 08:45:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA28303 for ; Thu, 4 Nov 1999 08:45:31 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22032 for ; Thu, 4 Nov 1999 08:45:13 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA01957; Fri, 5 Nov 1999 01:35:38 +0900 (JST) Date: Fri, 05 Nov 1999 01:40:39 +0900 Message-ID: <14369.46855.551062.12006I@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: peter@jazz-1.trumpet.com.au Cc: ipng@sunroof.eng.sun.com Subject: Re: ND on multi-homed nodes In-Reply-To: In your message of "Wed, 3 Nov 1999 12:05:44 +1100 (EST)" References: User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 3 Nov 1999 12:05:44 +1100 (EST), >>>>> Peter Tattam said: (I think you cited a different part of my mail from the one you intended, so I removed it.) > A thought on this... I know this is probably a pathelogical case, but if the > transport layer can't work out which interface to send it, could it not start > an ND on all interfaces and then only use the one where the ND arrives. If the > link local address is generated using auto config, the probably of a clash > would be low. That's true, but the probability is not zero. I'd rather prefer the idea of the default (or primary) interface, since it is easy to implement, covers the most typical cases (as Francis said in another thread), and is less confusing. However, IMO, it is implementation dependent. If you prefer the "ND for each link" approach, I won't oppose you. > Also the information is likely to be in the ND cache already if > a node has already received a packet on one of the interfaces. Yes, but the essential point does not change; can we believe that the cache entry designates the node that we intend? There maybe another node on another link that has the same link-local address. This example just means a variation of adopting the first received NA. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 4 08:49:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4Gkq405562 for ipng-dist; Thu, 4 Nov 1999 08:46:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4GkXi05547 for ; Thu, 4 Nov 1999 08:46:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA28532 for ; Thu, 4 Nov 1999 08:46:33 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14199 for ; Thu, 4 Nov 1999 09:46:21 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA01948; Fri, 5 Nov 1999 01:35:30 +0900 (JST) Date: Fri, 05 Nov 1999 00:46:11 +0900 Message-ID: <14369.43587.326852.36620E@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sm@bossette.engr.sgi.com Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Mon, 1 Nov 1999 20:48:57 -0800 (PST)" <199911020448.UAA44439@bossette.engr.sgi.com> References: <14366.20972.214621.9106S@condor.isl.rdc.toshiba.co.jp> <199911020448.UAA44439@bossette.engr.sgi.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 63 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 1 Nov 1999 20:48:57 -0800 (PST), >>>>> sm@bossette.engr.sgi.com (Sam Manthorpe) said: >> > So I feel the appropriate portion for the scope_id is subtle. However, >> > I don't stick to the idea that the scope id should be after an >> > address. I'd respect others' opinions. > Yes, I kind of agree with you about the `2nd most significant part' but > not 100% (as you say, it's subtle :-) In the prototype implementation we > have in IRIX, scope-ids are unique system wide, over all address types. > i.e. you cannot have a site-local and link-local with the same scope-id. > Intuitively, I feel the scope-id belongs -somewhere- up there near > the address type end of the address descriptor and putting it before > the start of the address is clearly preferable to trying to incorporate > it in 2nd order position. Putting the scope-id at the tail address goes > against my personal intuition, but this is clearly a grey area. Okay, I understand your point, but I'd like to keep this issue opened for a while. It's a minor detail and the difference is in intuition of each implementor, so we'll not be able to get a consensus easily... >> example, isn't the following address >> >> S12A:FEC0::123:4567:89AB:CDEF >> >> a bit confusing? Though it's not syntactically ambiguous (because "S" >> never appears in an IPv6 literal address), people might misread the >> syntax and think it represents an IPv6 address *without* any scope >> identifier. Am I a worrier? > I agree it kind of looks like that. Is this a bad thing? I suppose it > is in the sense that IPv6 addresses are free to be sent between > hosts by applications or humans whereas scope-ids are not. I didn't mean that this was bad, but I just meant it was confusing for a user. Even if a user (mis)types the above address instead of A12A:FEC0::123:4567:89AB:CDEF, the system will not return an error (at least about the syntax) and it'll be a hard work for the user to find what's wrong. >> Exactly (though I believe we should use struct addrinfo instead of >> struct hostent). This is the goal we intended in the draft. > Yes, using getaddrinfo() does solve that problem. Personally I > don't like getaddrinfo() but I'm clearly in the minority :-) > (actually I don't like scoped addresses either :-) > As I said before, it is far preferable to me when explaining to > programmers how to port to IPv6 to use simple things like > replace gethostbyname() with getipnodebyname() etc, rather than > having to explain the complexity of getaddrinfo() with all its > semantic knobs and whistles and the non-trivial code reworking it > requires. But that's another thread... I understand your point, but as you (and others) already said, getipnodebyname vs getaddrinfo will be another issue. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 4 08:49:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4Gkus05563 for ipng-dist; Thu, 4 Nov 1999 08:46:56 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4Gkci05555 for ; Thu, 4 Nov 1999 08:46:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA25425 for ; Thu, 4 Nov 1999 08:46:39 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22539 for ; Thu, 4 Nov 1999 08:46:31 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA01954; Fri, 5 Nov 1999 01:35:36 +0900 (JST) Date: Fri, 05 Nov 1999 01:21:39 +0900 Message-ID: <14369.45715.899582.10612R@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: ND on multi-homed nodes In-Reply-To: In your message of "Tue, 2 Nov 1999 06:02:20 -0800" References: <199910301925.MAA33790@bossette.engr.sgi.com> <14366.58477.996200.62282F@condor.isl.rdc.toshiba.co.jp> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 2 Nov 1999 06:02:20 -0800, >>>>> Steve Deering said: >> Our (KAME's) kernel basically requires a link identifier when the >> kernel tries to resolve a link-layer address of an IPv6 link-local >> address. If no identifier is given but there is a default route, the >> kernel will just send packets to the default router without address >> resolution (I don't think this is a good behavior, though). > I think you ought to have a notion of a "primary" or "default" interface > that is used when the upper layer tried to send to a non-global address > but does not specify the outgoing interface or scope zone. The same > concept is already needed for multicasts, for similar reasons. I agree, and "the primary interface (or link)" is not so difficult to implement; we only have to install an interface route for the prefix "fe80::/10" towards the primary interface. We are about to implement the notion of the primary interface in this way. Thanks for your suggestion. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 4 09:04:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4H20Y05678 for ipng-dist; Thu, 4 Nov 1999 09:02:00 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4H1oi05671 for ; Thu, 4 Nov 1999 09:01:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA26191; Thu, 4 Nov 1999 09:01:50 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21965; Thu, 4 Nov 1999 10:01:47 -0700 (MST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id LAA05495; Thu, 4 Nov 1999 11:01:15 -0600 (CST) Date: Thu, 4 Nov 1999 11:01:15 -0600 (CST) From: David Borman Message-Id: <199911041701.LAA05495@frantic.bsdi.com> To: bound@zk3.dec.com, Erik.Nordmark@eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com, sm@bossette.engr.sgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From owner-ipng@sunroof.eng.sun.com Thu Nov 4 09:44:36 1999 > From: Jim Bound > To: Erik Nordmark > Cc: Sam Manthorpe , Jack McCann , > ipng@sunroof.eng.sun.com > Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt > Date: Thu, 04 Nov 1999 10:40:13 -0500 > X-Mts: smtp > > > >> Now, if only struct hostent used sockaddrs porting apps to IPv6 would > >> be easy. > > > >Why not just use getaddrinfo instead of getipnodebyname? > >This might mean changing 20 lines of code compared to 10 lines of code > >with getipnodebyname (for a port of trivial example code to the new API). > > I don't agree. the inline code to change from gethostbyname to > getipnodebyname is much more explicable and supporting addded trans > mechanisms. I guess I just have this broken view of converting to getipnodebyname() as going from 1 to 2, whereas converting to getnameinfo() as going from 1 to N. As the old addage says, "in computer science there are only 3 interesting numbers, 0, 1 and many". getipnodebyname() is not going to allow a simple application operate over UN*X domain sockets, but getnameinfo() can. > see our programming examples at: www.ipv6.zk3-x.dec.com > click on "Porting Guide" It's a nice guide, but I'm not too suprised that it doesn't even mention the getaddrinfo()/getnameinfo() functions, so people using it won't even know that they exist. It'd be nice if the guide at least mentioned the functions. > using getipnodebyname is more familiar to most programmers who use > sockets we keep the semantics and the core inline logic of the code > remains in tact you add the conditions of v4/v6. > > getaddrinfo and friends changes the programming paradigm a bit and what > you must feed that api engine. Hey, in the old days, gethostbyname() only returned one address, and people wrote applications with that assumption in mind. Then, along came the ability to for gethostbyname() to return an array of addresses, and that required changing the programming paradigm to take advantage of trying multiple addresses if the first one failed. Programmers managed to handle that change without too much trouble. I think that most of them will be able to grasp how to convert to using getnameinfo(), and are capable of doing the minor code shuffling. Of course the main focus of changes between RFC 2133 and RFC 2553 was getipnodebyname and friends, because the older gethostbyname2() and friends were just not up to the task. There really wasn't much that needed to be changed with getaddrinfo() and getnameinfo(), so they just naturally weren't part of the discussion. I just like to gently remind people that while there has been a lot of focus on getipnodebyname() and friends, it is not the only game in town. Personally, I find that when I recode things to use getnameinfo(), I get cleaner, more generic code in the end. But while I changed ftp to use getnameinfo(), I did the quick hack for telnet to use gethostbyname2(). And the telnet code is a lot uglier than the ftp code. > I predict most will stay with getipnodebyname and as Sam stated > previously its a pain. The bottom line is that I think that both sets of functions are useful. You may feel that getnameinfo() is a pain, but just because you feel that way doesn't mean that everyone else will also feel that way. I will use whichever seems to be more appropriate for the task at hand, whereas you just seem to ignore the getnameinfo()/getaddrinfo() functions or say that they are too complex, and you pass that attitude on to others. That's one of the reasons why I periodically keep reminding people that the getnameinfo()/getaddrinfo() functions exist. It all depends on your goals. One of my main goals is to be able to compile a single binary that will support IPv6, but will still run with a kernel that does not have IPv6/AF_INET6 support. Using getnameinfo(), I have one call to look up the name and I have all the information to create the a socket with the correct address family, and the correct sockaddr structure to use for the connect(). If I use getipnodebyname(), I have to make two calls, one for IPv4 and one for IPv6, since I can't use IPv4-mapped IPv6 addresses, because those depend on AF_INET6 support. Or else I have to look at the IPv6 address, check to see if it is an IPv4-mapped IPv6 address, and convert it back to an IPv4 address so that I can use an AF_INET socket. It just gets ugly. But if you don't care about building a binary that runs on kernels without IPv6, then your code won't have to be that ugly. I guess the fact that I can make an application IPv6 capable without having to make it IPv6 aware is one of the things that I like about using getnameinfo(). getipnodebyname() doesn't give you that. -David Borman, dab@bsdi.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 Nov 4 10:41:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4Ib1D05789 for ipng-dist; Thu, 4 Nov 1999 10:37:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4Iari05782 for ; Thu, 4 Nov 1999 10:36:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA24416 for ; Thu, 4 Nov 1999 10:36:52 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04189 for ; Thu, 4 Nov 1999 11:36:51 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA28859 for <@external-mail-relay.sgi.com:ipng@sunroof.eng.sun.com>; Thu, 4 Nov 1999 10:32:46 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA39993 for <@relay.engr.sgi.com:ipng@sunroof.eng.sun.com>; Thu, 4 Nov 1999 10:36:50 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA54133 for ipng@sunroof.eng.sun.com; Thu, 4 Nov 1999 10:36:49 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911041836.KAA54133@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: ipng@sunroof.eng.sun.com Date: Thu, 4 Nov 1999 10:36:48 -0800 (PST) In-Reply-To: from "Niels Möller" at Nov 4, 99 01:44:45 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Apologies, it wasn't my intention to restart this getipnodebyname/getaddrinfo discussion again; this is clearly a religious point and we need both functions available. However, what I was interested to know was if I am the only one who sees sufficient need to add scope_id to hostent or add a parameter to getipnodebyname(). [ given that I do _not_ want to use getaddrinfo() :-) ] getipnodebyname() is almost useless IMO if it doesn't communicate the scope-id. Thanks, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 4 11:32:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4JTI205893 for ipng-dist; Thu, 4 Nov 1999 11:29:18 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4JT8i05886 for ; Thu, 4 Nov 1999 11:29:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA17467 for ; Thu, 4 Nov 1999 11:29:07 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10050 for ; Thu, 4 Nov 1999 11:29:06 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 75704578F7; Thu, 4 Nov 1999 13:29:06 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 9FF55BC4C6; Thu, 4 Nov 1999 13:28:54 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 1B47CB2A42; Thu, 4 Nov 1999 13:28:54 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000006940; Thu, 4 Nov 1999 14:29:04 -0500 (EST) From: Jim Bound Message-Id: <199911041929.OAA0000006940@quarry.zk3.dec.com> To: David Borman Cc: bound@zk3.dec.com, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, mccann@zk3.dec.com, sm@bossette.engr.sgi.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Thu, 04 Nov 1999 11:01:15 CST." <199911041701.LAA05495@frantic.bsdi.com> Date: Thu, 04 Nov 1999 14:29:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >Why not just use getaddrinfo instead of getipnodebyname? >> >This might mean changing 20 lines of code compared to 10 lines of code >> >with getipnodebyname (for a port of trivial example code to the new API). >> >> I don't agree. the inline code to change from gethostbyname to >> getipnodebyname is much more explicable and supporting addded trans >> mechanisms. >I guess I just have this broken view of converting to getipnodebyname() >as going from 1 to 2, whereas converting to getnameinfo() as going from >1 to N. As the old addage says, "in computer science there are only 3 >interesting numbers, 0, 1 and many". getipnodebyname() is not going to >allow a simple application operate over UN*X domain sockets, but >getnameinfo() can. And there is an old addage in "engineering" get the job done as quick as possible. Its a tradeoff of computer science vs engineering. Two different things all together. Please explain 1 to N.... If you mean more than AF_INET and AF_INET6 then I don't agree and don't care from a business perspective as an engineer about anything other than v4 or v6. If you mean getting back a mix of both v4 and v6 addresses getipnodebyname supports that and returns v4 as v4mapped. Mabye our approaches of implementing v4mapped and the IP stack for IPv6 are completely different. Is there a test to see if I am dealing with a v4 or v6 address not really the only concern is if I was passed in AF_INET or AF_INET6 to my server app. This not a hard condition to maintain and easy to write. And its self documenting. Also I don't see AI_ALL and AI_ADDRCONFIG are not part of of getaddrinfo? >> see our programming examples at: www.ipv6.zk3-x.dec.com >> click on "Porting Guide" > >It's a nice guide, but I'm not too suprised that it doesn't even >mention the getaddrinfo()/getnameinfo() functions, so people using >it won't even know that they exist. It'd be nice if the guide at least >mentioned the functions. Well we believe the two are tied together and await the fixes from XNET but they will be part of our guide eventually. We will provide both choices and one of our ISVs is using getaddr and friends. >> using getipnodebyname is more familiar to most programmers who use >> sockets we keep the semantics and the core inline logic of the code >> remains in tact you add the conditions of v4/v6. >> >> getaddrinfo and friends changes the programming paradigm a bit and what >> you must feed that api engine. >Hey, in the old days, gethostbyname() only returned one address, >and people wrote applications with that assumption in mind. Then, >along came the ability to for gethostbyname() to return an array >of addresses, and that required changing the programming paradigm >to take advantage of trying multiple addresses if the first one >failed. Programmers managed to handle that change without too >much trouble. I think that most of them will be able to grasp >how to convert to using getnameinfo(), and are capable of doing >the minor code shuffling. It was much more than that it was MT Safeness, additional flags, and a few more things. >Of course the main focus of changes between RFC 2133 and RFC 2553 >was getipnodebyname and friends, because the older gethostbyname2() >and friends were just not up to the task. There really wasn't much >that needed to be changed with getaddrinfo() and getnameinfo(), so >they just naturally weren't part of the discussion. scoping too. >I just like to gently remind people that while there has been >a lot of focus on getipnodebyname() and friends, it is not the >only game in town. Personally, I find that when I recode things >to use getnameinfo(), I get cleaner, more generic code in the end. >But while I changed ftp to use getnameinfo(), I did the quick >hack for telnet to use gethostbyname2(). And the telnet code >is a lot uglier than the ftp code. But we all know beauty is in the eye of the programmer :--).... >> I predict most will stay with getipnodebyname and as Sam stated >> previously its a pain. > >The bottom line is that I think that both sets of functions are >useful. You may feel that getnameinfo() is a pain, but just >because you feel that way doesn't mean that everyone else will >also feel that way. I will use whichever seems to be more >appropriate for the task at hand, whereas you just seem to ignore the getnameinfo()/getaddrinfo() functions or say that they are >too complex, and you pass that attitude on to others. That's one >of the reasons why I periodically keep reminding people that the >getnameinfo()/getaddrinfo() functions exist. And that fine and good. >It all depends on your goals. One of my main goals is to be able to >compile a single binary that will support IPv6, but will still run with >a kernel that does not have IPv6/AF_INET6 support. Using getnameinfo(), >I have one call to look up the name and I have all the information to >create the a socket with the correct address family, and the correct >sockaddr structure to use for the connect(). If I use getipnodebyname(), >I have to make two calls, one for IPv4 and one for IPv6, since I can't >use IPv4-mapped IPv6 addresses, because those depend on AF_INET6 support. >Or else I have to look at the IPv6 address, check to see if it is an >IPv4-mapped IPv6 address, and convert it back to an IPv4 address so that >I can use an AF_INET socket. It just gets ugly. But if you don't care >about building a binary that runs on kernels without IPv6, then your code >won't have to be that ugly. Well I don't have the same problem we built IPv6 to support AF_INET6 on down then send IPv4 if its a mapped address. >I guess the fact that I can make an application IPv6 capable without >having to make it IPv6 aware is one of the things that I like about >using getnameinfo(). getipnodebyname() doesn't give you that. Hmm. I can change and IP app to use Ipv6 or IPv4 and the stack does not have to support IPv6. Anyway.... Each of us have our preferences and I will continue to advocate use of getipnodebyname, unless its a new app. /jim -David Borman, dab@bsdi.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 Nov 4 11:36:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4JZ6r05915 for ipng-dist; Thu, 4 Nov 1999 11:35:06 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4JYvi05908 for ; Thu, 4 Nov 1999 11:34:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA29277 for ; Thu, 4 Nov 1999 11:34:56 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA12568 for ; Thu, 4 Nov 1999 11:34:51 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id DCF5F9A897; Thu, 4 Nov 1999 13:34:50 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 171D84FB15; Thu, 4 Nov 1999 13:34:42 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id B35D84C901; Thu, 4 Nov 1999 13:34:41 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000009688; Thu, 4 Nov 1999 14:34:49 -0500 (EST) From: Jim Bound Message-Id: <199911041934.OAA0000009688@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Thu, 04 Nov 1999 10:36:48 PST." <199911041836.KAA54133@bossette.engr.sgi.com> Date: Thu, 04 Nov 1999 14:34:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sam, >However, what I was interested to know was if I am the only one who >sees sufficient need to add scope_id to hostent or add a parameter >to getipnodebyname(). [ given that I do _not_ want to use getaddrinfo() :-) ] >getipnodebyname() is almost useless IMO if it doesn't communicate the >scope-id. scope-id is communicated to the stack via sockaddr_in6. Sorry if I am missing your point. But could tell us what you want to do with the scope-id? thanks /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 Thu Nov 4 12:12:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4K9GI05974 for ipng-dist; Thu, 4 Nov 1999 12:09:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4K98i05967 for ; Thu, 4 Nov 1999 12:09:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA06335 for ; Thu, 4 Nov 1999 12:09:07 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14733 for ; Thu, 4 Nov 1999 13:09:06 -0700 (MST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id OAA05930; Thu, 4 Nov 1999 14:08:40 -0600 (CST) Date: Thu, 4 Nov 1999 14:08:40 -0600 (CST) From: David Borman Message-Id: <199911042008.OAA05930@frantic.bsdi.com> To: bound@zk3.dec.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > From: Jim Bound > Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt > Date: Thu, 04 Nov 1999 14:29:04 -0500 > ... > Please explain 1 to N.... If you mean more than AF_INET and AF_INET6 Yes. > then I don't agree and don't care from a business perspective as an > engineer about anything other than v4 or v6. And I wouldn't expect anything else :-), as you have stated this position before. I belive it was along the lines of, if it was decided that IPv6 was lacking and a new version of IP was needed, you'd get out of the game and just go fishing. > If you mean getting back a mix of both v4 and v6 addresses > getipnodebyname supports that and returns v4 as v4mapped. > > Mabye our approaches of implementing v4mapped and the IP stack for IPv6 > are completely different. Perhaps. The issue that I have is that getting a v4mapped address means either using an AF_INET6 socket and sockaddr_in6, or recognizing that it is a v4mapped address, converting it to use a sockaddr_in, and then using an AF_INET socket. Since I want the binary to run on systems that are built without AF_INET6 support, that limits me to the latter case, which is where the code starts to get ugly. If I use getaddrinfo(), it tells me what type of socket to open, and gives me the appropriate sockaddr structure ready to go for the connect(). If I recall correctly, in the past you said that your systems have AF_INET6 support, and excluding it is not an option. If that is the case, you can use the former option, and the code doesn't have to get ugly. -David Borman, dab@bsdi.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 Nov 4 12:37:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4KRHM05999 for ipng-dist; Thu, 4 Nov 1999 12:27:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4KR5i05992 for ; Thu, 4 Nov 1999 12:27:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA08796 for ; Thu, 4 Nov 1999 12:27:04 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05255 for ; Thu, 4 Nov 1999 12:27:02 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id MAA20051; Thu, 4 Nov 1999 12:20:26 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA85968; Thu, 4 Nov 1999 12:24:29 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA58383; Thu, 4 Nov 1999 12:24:24 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911042024.MAA58383@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: bound@zk3.dec.com (Jim Bound) Date: Thu, 4 Nov 1999 12:24:24 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911041934.OAA0000009688@quarry.zk3.dec.com> from "Jim Bound" at Nov 4, 99 02:34:49 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > >However, what I was interested to know was if I am the only one who > >sees sufficient need to add scope_id to hostent or add a parameter > >to getipnodebyname(). [ given that I do _not_ want to use getaddrinfo() :-) ] > >getipnodebyname() is almost useless IMO if it doesn't communicate the > >scope-id. > > scope-id is communicated to the stack via sockaddr_in6. For example: telnet The way our implementation currently works is that the gets passed to getipnodebyname() and is converted to an IPv6 address in struct hostent. However, if contains a scope-id, even if getipnodebyname() ignores the scope-id and correctly translates the address, this will fail later if the link-local address belongs to a link other than the default link. How can the application know what scope-id to put in the sockaddr_in6? I also assume that there should be some support in DNS or icmp name lookups to get the correct scope-id, and this also should be passed back from getipnodybyname(). Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 4 14:52:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA4Mo0C06252 for ipng-dist; Thu, 4 Nov 1999 14:50:00 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA4Mnqi06245 for ; Thu, 4 Nov 1999 14:49:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA22418 for ; Thu, 4 Nov 1999 14:49:53 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06652 for ; Thu, 4 Nov 1999 14:49:52 -0800 (PST) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA14744 for ; Thu, 4 Nov 1999 14:49:51 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: Date: Thu, 4 Nov 1999 14:49:50 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Fwd: 46th IETF-Breakout Rooms Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI: >To: wgchairs@ietf.org, bofchairs@ietf.org >From: agenda@ietf.org >Subject: 46th IETF-Breakout Rooms >Date: Thu, 04 Nov 1999 17:09:49 -0500 > >Just a reminder that all meeting rooms will be equipped >with an overhead projector and a data projector. > >Marcia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 4 19:59:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA53uem06712 for ipng-dist; Thu, 4 Nov 1999 19:56:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA53uWi06705 for ; Thu, 4 Nov 1999 19:56:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA22616 for ; Thu, 4 Nov 1999 19:56:31 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA23943 for ; Thu, 4 Nov 1999 19:56:31 -0800 (PST) Received: from ix.netcom.com (dal-tx7-55.ix.netcom.com [207.94.122.183]) by smtp10.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id WAA24651; Thu, 4 Nov 1999 22:56:28 -0500 (EST) Message-ID: <382265E0.8BCFBC96@ix.netcom.com> Date: Thu, 04 Nov 1999 21:06:40 -0800 From: Jeff Williams X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: Re: draft-ietf-ipngwg-addrconf-privacy-01.txt References: <199910222107.RAA17403@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas and all, This might be considered expectable as a temporary "Fix" as long as the user has the option. Thomas Narten wrote: > Has been submitted. Early birds can find it at > ftp://ftp.cs.duke.edu/pub/narten/ietf/privacy.out. > > The major change is that it now calls for a node to have both public > and "anonymous" addresses simultaneously, and that anonymous addresses > apply to global scope prefixes only, not link-local or site-local. (It > would be trivial to make site-local addresses anonymous as well, but > it is not clear this is needed.) In addition, addresses change > periodically (e.g., once a day) and not just when a machine > restarts. Rich Draves also helped out and is now a coauthor. > > Thomas > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 4 20:26:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA54NS806768 for ipng-dist; Thu, 4 Nov 1999 20:23:28 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA54NJi06761 for ; Thu, 4 Nov 1999 20:23:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA24302 for ; Thu, 4 Nov 1999 20:23:18 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA01728 for ; Thu, 4 Nov 1999 20:23:18 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 19B51152058; Thu, 4 Nov 1999 22:23:18 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id B5CE84FB29; Thu, 4 Nov 1999 22:23:07 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 542684C903; Thu, 4 Nov 1999 22:23:07 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000031612; Thu, 4 Nov 1999 23:23:16 -0500 (EST) From: Jim Bound Message-Id: <199911050423.XAA0000031612@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Thu, 04 Nov 1999 12:24:24 PST." <199911042024.MAA58383@bossette.engr.sgi.com> Date: Thu, 04 Nov 1999 23:23:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >However, what I was interested to know was if I am the only one who >> >sees sufficient need to add scope_id to hostent or add a parameter >> >to getipnodebyname(). [ given that I do _not_ want to use getaddrinfo() :-) ] >> >getipnodebyname() is almost useless IMO if it doesn't communicate the >> >scope-id. >> >> scope-id is communicated to the stack via sockaddr_in6. > >For example: > > telnet > >The way our implementation currently works is that the > gets passed to getipnodebyname() and >is converted to an IPv6 address in struct hostent. However, >if contains a scope-id, even if getipnodebyname() >ignores the scope-id and correctly translates the address, this >will fail later if the link-local address belongs to a link other >than the default link. How can the application know what scope-id >to put in the sockaddr_in6? I also assume that there should be some >support in DNS or icmp name lookups to get the correct scope-id, >and this also should be passed back from getipnodybyname(). Now I see the complication. In the base api spec we state this is for future work and from the pointers to the Japan meeting this came up there too. I think we will see a separate piece of work for scoping which was what we decided when we added this field to sockaddr_in6. What we wanted to do was freeze the changes to the baseapi and define it in a manner that adjunct work could be done on it as needed and by the advanced API too. Be careful with the term link above. The sin6_scope_id >From rfc 2553: IPv6 addresses are scoped [2] so they could be link-local, site, organization, global, or other scopes at this time undefined. To support applications that want to be able to identify a set of interfaces for a specific scope, the IPv6 sockaddr_in structure must support a field that can be used by an implementation to identify a set of interfaces identifying the scope for an IPv6 address. and struct sockaddr_in6 { sa_family_t sin6_family; /* AF_INET6 */ in_port_t sin6_port; /* transport layer port # */ uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ struct in6_addr sin6_addr; /* IPv6 address */ uint32_t sin6_scope_id; /* set of interfaces for a scope */ }; It represents a set of interfaces for a scope. I look at interfaces equivalent to links. I believe once we define what the sin6_scope_id defines to the kernel then I believe it will come back from the hostent structure. If that means DNS also I am not sure and not sure that should be the case. For now I would leave the field as NULL and the default will take place which will be the norm anyway. If the field is undefined which it is now that means NULL. /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 Thu Nov 4 21:04:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA551NQ06835 for ipng-dist; Thu, 4 Nov 1999 21:01:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA551Ei06828 for ; Thu, 4 Nov 1999 21:01:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA19509 for ; Thu, 4 Nov 1999 21:01:14 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA13450 for ; Thu, 4 Nov 1999 21:01:13 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 572F79A93C; Thu, 4 Nov 1999 23:01:13 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id A8671BC4E8; Thu, 4 Nov 1999 23:01:01 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 4D52CB2A42; Thu, 4 Nov 1999 23:01:01 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000007917; Fri, 5 Nov 1999 00:01:12 -0500 (EST) From: Jim Bound Message-Id: <199911050501.AAA0000007917@quarry.zk3.dec.com> To: David Borman Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Thu, 04 Nov 1999 14:08:40 CST." <199911042008.OAA05930@frantic.bsdi.com> Date: Fri, 05 Nov 1999 00:01:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Perhaps. The issue that I have is that getting a v4mapped address means >either using an AF_INET6 socket and sockaddr_in6, or recognizing that >it is a v4mapped address, converting it to use a sockaddr_in, and then >using an AF_INET socket. Since I want the binary to run on systems >that are built without AF_INET6 support, that limits me to the latter >case, which is where the code starts to get ugly. If I use getaddrinfo(), >it tells me what type of socket to open, and gives me the appropriate >sockaddr structure ready to go for the connect(). This means you must always use PF_UNSPEC. The same can be done for a test for AF_INET6 with ifdef and once you target an IPv6 node with an APP this can be done too. >If I recall correctly, in the past you said that your systems have >AF_INET6 support, and excluding it is not an option. If that is the >case, you can use the former option, and the code doesn't have to >get ugly. Well I would word it different. The systems will all support AF_INET6 out of the box. You can write your code with getipnodebyname and friends or getaddrinfo and friends. Once XNET completes the work for getaddrinfo I will add. Again ugly is really not a good term to me. Whats ugly? I can argue that assembly code is more elegant in many ways over C code for many jobs. Then one could beat me up about constructs or the operations of overloading that can be done with a compiler. Then I would state I can time each instruction during unit-test phase and use recursion... on and on and on. I would claim the getipnodebyname code is more familiar to most too. I am being conservative here. The leap to getipnodebyname is a baby step. I don't know one production application in the market using getaddrinfo for IPv4, it has not had its function tested by fire, and either has getipnodebyname but its closer to what has been tested. We are not going anywhere here. I already stated and many many times. If one wants to use getaddrinfo thats fine. I just don't use it today. I was simply agreeing with a wg member in mail I find it not useful either thats all, and we we are now entering that place where rats live I think? Or like curly in the three stooges when he saw cheese??? Moe, Larry, cheese ----)..... Your arguments pro getaddrinfo are excellent too. /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 Thu Nov 4 21:07:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5566J06862 for ipng-dist; Thu, 4 Nov 1999 21:06:06 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA555ti06855 for ; Thu, 4 Nov 1999 21:05:55 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA191584; Thu, 4 Nov 1999 21:05:52 -0800 (PST) Date: Thu, 4 Nov 1999 21:05:41 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: Jim Bound Cc: Erik Nordmark , Sam Manthorpe , Jack McCann , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199911041540.KAA0000030979@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > >Why not just use getaddrinfo instead of getipnodebyname? > >This might mean changing 20 lines of code compared to 10 lines of code > >with getipnodebyname (for a port of trivial example code to the new API). > > I don't agree. the inline code to change from gethostbyname to > getipnodebyname is much more explicable and supporting addded trans > mechanisms. The only substancial difference is using a service name with getaddrinfo instead of a port number. If you check the diffs between the 3 examples below (gethostbyname, getipnodebyname, and getaddrinfo) and ignore the comment lines you'll see 10 differing lines between gethostbyname and getipnodebyname, and 21 differing lines between gethostbyname and getaddrinfo. The point is: if we feel that getaddrinfo has advantages (like being able to set sin6_scope_id) we can (either collectively or individually) recommend programmers to use getaddrinfo. The difference in porting complexity isn't very large. Thus the issue isn't which one is slightly simpler. When porting an application (with 1000 or 1000000 lines of code) to IPv6 the actual change to the source code is very minimal - all the cost is associated with testing that the ported application still works (over both IPv4 and IPv6). If we decide to disagree and not recommend getaddrinfo I'm not going to be upset. But it just seems odd to argue that because there are 11 lines less of code changes most of the applications will use getipnodebyname - even though we know there are some benefits for scope addresses if the applications use getaddrinfo. And as far as I can tell it is easier to make the loop over all addresses with getaddrinfo than with getipnodebyname. Adds only 4 lines to the getaddrinfo example. Erik ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR Content-Type: TEXT/X-sun-c-file; name="myc.c"; charset=us-ascii Content-Description: c-file int myconnect(char *hostname, int port) { struct sockaddr_in sin; struct hostent *hp; int sock; /* Get host address. */ hp = gethostbyname(hostname); if (hp == NULL || hp->h_addrtype != AF_INET || hp->h_length != 4) { (void) fprintf(stderr, "Unknown host \"%s\"\n", hostname); return (-1); } sin.sin_family = AF_INET; sin.sin_port = htons(port); (void) memcpy((void *)&sin.sin_addr, (void *)hp->h_addr, hp->h_length); /* Open socket. */ sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) { perror("socket"); return (-1); } /* Connect to the host. */ if (connect(sock, (struct sockaddr *)&sin, sizeof (sin)) == -1) { perror("connect"); (void) close(sock); return (-1); } return (sock); } ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR Content-Type: TEXT/X-sun-c-file; name="myc2.c"; charset=us-ascii Content-Description: c-file int myconnect(char *hostname, int port) { struct sockaddr_in6 sin; struct hostent *hp; int sock, errnum; /* Get host address. An IPv4-mapped IPv6 address is okay. */ hp = getipnodebyname(hostname, AF_INET6, AI_DEFAULT, &errnum); if (hp == NULL) { (void) fprintf(stderr, "Unknown host \"%s\"\n", hostname); return (-1); } /* Make sure all sockaddr_in6 fields are zero */ bzero(&sin, sizeof (sin)); sin.sin6_family = hp->h_addrtype; sin.sin6_port = htons(port); (void) memcpy((void *)&sin.sin6_addr, (void *)hp->h_addr, hp->h_length); freehostent(hp); /* Open socket. */ sock = socket(AF_INET6, SOCK_STREAM, 0); if (sock == -1) { perror("socket"); return (-1); } /* Connect to the host. */ if (connect(sock, (struct sockaddr *)&sin, sizeof (sin)) == -1) { perror("connect"); (void) close(sock); return (-1); } return (sock); } ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR Content-Type: TEXT/X-sun-c-file; name="myc3.c"; charset=us-ascii Content-Description: c-file int myconnect(char *hostname, char *servicename) { struct addrinfo *res, *aip; struct addrinfo hints; int sock = -1; int error; /* Get host address. Any type of address will do. */ bzero(&hints, sizeof (hints)); hints.ai_flags = AI_ALL|AI_ADDRCONFIG; hints.ai_socktype = SOCK_STREAM; error = getaddrinfo(hostname, servicename, &hints, &aip); if (error != 0) { (void) fprintf(stderr, "getaddrinfo: %s for host %s service %s\n", gai_strerror(error), hostname, servicename); return (-1); } /* Open socket. */ sock = socket(aip->ai_family, aip->ai_socktype, aip->ai_protocol); if (sock == -1) { perror("socket"); freeaddrinfo(res); return (-1); } /* Connect to the host. */ if (connect(sock, aip->ai_addr, aip->ai_addrlen) == -1) { perror("connect"); (void) close(sock); return (-1); } freeaddrinfo(res); return (sock); } ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 4 21:25:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA55MeQ06932 for ipng-dist; Thu, 4 Nov 1999 21:22:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA55MUi06925 for ; Thu, 4 Nov 1999 21:22:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA21100 for ; Thu, 4 Nov 1999 21:22:29 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA20246 for ; Thu, 4 Nov 1999 21:22:29 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id C740A152041 for ; Thu, 4 Nov 1999 23:22:28 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id B5CE74FB03; Thu, 4 Nov 1999 23:22:18 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 6C9084C902 for ; Thu, 4 Nov 1999 23:22:18 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000011164; Fri, 5 Nov 1999 00:22:27 -0500 (EST) From: Jim Bound Message-Id: <199911050522.AAA0000011164@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Wed, 27 Oct 1999 19:15:19 +0200." <199910271715.TAA20375@givry.inria.fr> Date: Fri, 05 Nov 1999 00:22:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >1. Introduction > > There are several types of scoped addresses defined in the "IPv6 > Addressing Architecture" [ADDRARCH]. Since uniqueness of a scoped > address is guaranteed only within the according scope, the semantics > for a scoped address is ambiguous on a scope boundary. For example, > when a user specifies to send a packet from a node to a link-local > address of another node, the user must specify the link of the > destination as well, if the node is attached to more than one link. The last sentence is not necessarily true. It is not the link that must be specified but the scope. This is much different. And as you say below: > This characteristic of scoped addresses may introduce additional cost > to scope-aware applications; a scope-aware application may have to > provide a way to specify an instance of a scope for each scoped > address (e.g. a specific link for a link-local address) that the > application uses. Also, it is hard for a user to "cut and paste" a > scoped address due to the ambiguity of its scope. The key phrase is scope-aware applications. It is not required by IPv6 that any application be "scope aware". It is a feature we are in the process of defining and the semantics and the syntax. I look forward to the discussion at the ipng meeting, but I think this draft is premature similar to 6to4 specifying the address selection mechanism before we had a src address selection plan. Likewise we need a plan for scoping and what it means. I believe that was an action item to discuss and get started for ipng and I believe that work must be a predecessor to this work before we can agree this spec is valid. I also think we may or may not need to have the address as part of the sin6_scope_id field. It could be any type of data to-be-defined. Also unless this is to be anymore than an informational RFC for general knowledge but not a standard. Either put your discussion of getaddrinfoo in an appendix or address all parts of the base API. We cannot have specs that only work with one part of the base API. /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 Thu Nov 4 21:47:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA55i2L06972 for ipng-dist; Thu, 4 Nov 1999 21:44:02 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA55hsi06965 for ; Thu, 4 Nov 1999 21:43:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA22253 for ; Thu, 4 Nov 1999 21:43:52 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26747 for ; Thu, 4 Nov 1999 21:43:52 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id AE71257A40; Thu, 4 Nov 1999 23:43:51 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 1D651BC4CC; Thu, 4 Nov 1999 23:43:40 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id A1CFFB2A43; Thu, 4 Nov 1999 23:43:39 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000014185; Fri, 5 Nov 1999 00:43:50 -0500 (EST) From: Jim Bound Message-Id: <199911050543.AAA0000014185@quarry.zk3.dec.com> To: Erik Nordmark Cc: Jim Bound , Sam Manthorpe , Jack McCann , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Thu, 04 Nov 1999 21:05:41 PST." Date: Fri, 05 Nov 1999 00:43:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The only substancial difference is using a service name with getaddrinfo >instead of a port number. So. Not a reason to use getaddrinfo. >If you check the diffs between the 3 examples below (gethostbyname, >getipnodebyname, and getaddrinfo) and ignore the comment lines you'll see >10 differing lines between gethostbyname and getipnodebyname, >and 21 differing lines between gethostbyname and getaddrinfo. getaddrinfo also has more work within the API implementation. its not jsut the 21 differing lines but whats happening with the lib is called to execute. >The point is: if we feel that getaddrinfo has advantages (like being able >to set sin6_scope_id) we can (either collectively or individually) recommend >programmers to use getaddrinfo. The difference in porting complexity >isn't very large. Thus the issue isn't which one is slightly simpler. >When porting an application (with 1000 or 1000000 lines of code) >to IPv6 the actual change to the source code is very minimal - all the cost >is associated with testing that the ported application still works (over both >IPv4 and IPv6). Agreed. But I just sent my first mail to this thread and I think no draft should specify behavior for scoping that does not include getipnodebyname. If it does I will have to write a counter proposal. That would be stupid. Folks are already using getipnodebyname. Also getaddrinfo is far from proven to be useful its all theory till as a model. XNET is still fixing it and we had a bug just today that had to be clarified. >If we decide to disagree and not recommend getaddrinfo I'm not going to >be upset. But it just seems odd to argue that because there are 11 lines less >of code changes most of the applications will use getipnodebyname - even >though we know there are some benefits for scope addresses if the applications >use getaddrinfo. I will be upset and make a battle of it. As far as I can take it. >.And as far as I can tell it is easier to make the loop over all addresses >with getaddrinfo than with getipnodebyname. Adds only 4 lines to the >getaddrinfo example. A loop can be done for the hostent structure too. Also getaddrinfo requires more pointer processing and passing in the examples provided as it should. getaddrinfo may be a good "middleware" api, getipnodebyname is for system apps. I would also like to see different independent test results on performance for both if we must have this debate. The process to try to kill getipnodebyname will be more work than working with it. And the draft of this thread is in error not incluing getipnodebyname IMO and I intend to make a point of this in D.C. Do we want to start this battle? /jim ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR Content-Type: TEXT/X-sun-c-file; name="myc.c"; charset=us-ascii Content-Description: c-file int myconnect(char *hostname, int port) { struct sockaddr_in sin; struct hostent *hp; int sock; /* Get host address. */ hp = gethostbyname(hostname); if (hp == NULL || hp->h_addrtype != AF_INET || hp->h_length != 4) { (void) fprintf(stderr, "Unknown host \"%s\"\n", hostname); return (-1); } sin.sin_family = AF_INET; sin.sin_port = htons(port); (void) memcpy((void *)&sin.sin_addr, (void *)hp->h_addr, hp->h_length); /* Open socket. */ sock = socket(AF_INET, SOCK_STREAM, 0); if (sock == -1) { perror("socket"); return (-1); } /* Connect to the host. */ if (connect(sock, (struct sockaddr *)&sin, sizeof (sin)) == -1) { perror("connect"); (void) close(sock); return (-1); } return (sock); } ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR Content-Type: TEXT/X-sun-c-file; name="myc2.c"; charset=us-ascii Content-Description: c-file int myconnect(char *hostname, int port) { struct sockaddr_in6 sin; struct hostent *hp; int sock, errnum; /* Get host address. An IPv4-mapped IPv6 address is okay. */ hp = getipnodebyname(hostname, AF_INET6, AI_DEFAULT, &errnum); if (hp == NULL) { (void) fprintf(stderr, "Unknown host \"%s\"\n", hostname); return (-1); } /* Make sure all sockaddr_in6 fields are zero */ bzero(&sin, sizeof (sin)); sin.sin6_family = hp->h_addrtype; sin.sin6_port = htons(port); (void) memcpy((void *)&sin.sin6_addr, (void *)hp->h_addr, hp->h_length); freehostent(hp); /* Open socket. */ sock = socket(AF_INET6, SOCK_STREAM, 0); if (sock == -1) { perror("socket"); return (-1); } /* Connect to the host. */ if (connect(sock, (struct sockaddr *)&sin, sizeof (sin)) == -1) { perror("connect"); (void) close(sock); return (-1); } return (sock); } ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR Content-Type: TEXT/X-sun-c-file; name="myc3.c"; charset=us-ascii Content-Description: c-file int myconnect(char *hostname, char *servicename) { struct addrinfo *res, *aip; struct addrinfo hints; int sock = -1; int error; /* Get host address. Any type of address will do. */ bzero(&hints, sizeof (hints)); hints.ai_flags = AI_ALL|AI_ADDRCONFIG; hints.ai_socktype = SOCK_STREAM; error = getaddrinfo(hostname, servicename, &hints, &aip); if (error != 0) { (void) fprintf(stderr, "getaddrinfo: %s for host %s service %s\n", gai_strerror(error), hostname, servicename); return (-1); } /* Open socket. */ sock = socket(aip->ai_family, aip->ai_socktype, aip->ai_protocol); if (sock == -1) { perror("socket"); freeaddrinfo(res); return (-1); } /* Connect to the host. */ if (connect(sock, aip->ai_addr, aip->ai_addrlen) == -1) { perror("connect"); (void) close(sock); return (-1); } freeaddrinfo(res); return (sock); } ---LA_F2156943608R-1A-941778346=:431NCE.IlHAFeR-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Nov 4 21:57:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA55tCF07013 for ipng-dist; Thu, 4 Nov 1999 21:55:12 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA55t3i07006 for ; Thu, 4 Nov 1999 21:55:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA16634 for ; Thu, 4 Nov 1999 21:55:02 -0800 (PST) Received: from frantic.bsdi.com (frantic.weston.BSDI.COM [209.173.194.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA22524 for ; Thu, 4 Nov 1999 22:55:01 -0700 (MST) Received: (from dab@localhost) by frantic.bsdi.com (8.9.0/8.9.0) id XAA06763; Thu, 4 Nov 1999 23:54:36 -0600 (CST) Date: Thu, 4 Nov 1999 23:54:36 -0600 (CST) From: David Borman Message-Id: <199911050554.XAA06763@frantic.bsdi.com> To: bound@zk3.dec.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Jim Bound > Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt > Date: Fri, 05 Nov 1999 00:01:11 -0500 > ... > I don't know one production application in the market using getaddrinfo > for IPv4, it has not had its function tested by fire, and either has > getipnodebyname but its closer to what has been tested. You might be referring to 3rd party applications, but in BSD/OS 4.x, ftp/ftpd, route, finger/fingerd, netstat, ifconfig and ping are all using getaddrinfo() or getnameinfo(). -David Borman, dab@bsdi.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 Nov 4 23:28:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA57PtW07050 for ipng-dist; Thu, 4 Nov 1999 23:25:55 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA57Pii07043 for ; Thu, 4 Nov 1999 23:25:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA22377 for ; Thu, 4 Nov 1999 23:25:44 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA10879 for ; Fri, 5 Nov 1999 00:25:44 -0700 (MST) Received: from ix.netcom.com (dal-tx1-51.ix.netcom.com [207.94.120.115]) by smtp10.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id CAA26395; Fri, 5 Nov 1999 02:24:58 -0500 (EST) Message-ID: <3822A085.8AF2B423@ix.netcom.com> Date: Fri, 05 Nov 1999 01:16:53 -0800 From: Jeff Williams X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Jim Dunn CC: "ipng@sunroof.eng.sun.com" , "vinton g. cerf - ISOC" Subject: Re: Interview with Vint Cerf from CNN Website. References: <01BF215D.6AF61310@wstaalnt544731.ukcore.bt.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and all, Looks like old Vinton is again contradicting himself in this article. Not overly unusual for him though. Just about a month ago his response to the privacy or security problems with IPv6 was that IPsec would handle it. Go figure... But it was worth a chuckle to read anyway, thanks! >;) Jim Dunn wrote: > I came across this on CNN's website. > > http://www.cnn.com/TECH/computing/9910/27/cerf.ipv6.idg/cerf.ipv6.html > > 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 > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 5 02:38:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5Aa6C07246 for ipng-dist; Fri, 5 Nov 1999 02:36:06 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5AZvi07239 for ; Fri, 5 Nov 1999 02:35:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA15987 for ; Fri, 5 Nov 1999 02:35:55 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA20628 for ; Fri, 5 Nov 1999 03:35:50 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA14356; Fri, 5 Nov 1999 11:35:44 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA28996; Fri, 5 Nov 1999 11:35:43 +0100 (MET) Message-Id: <199911051035.LAA28996@givry.inria.fr> From: Francis Dupont To: sm@bossette.engr.sgi.com (Sam Manthorpe) cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Thu, 04 Nov 1999 10:36:48 PST. <199911041836.KAA54133@bossette.engr.sgi.com> Date: Fri, 05 Nov 1999 11:35:38 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: However, what I was interested to know was if I am the only one who sees sufficient need to add scope_id to hostent or add a parameter to getipnodebyname(). getipnodebyname() is almost useless IMO if it doesn't communicate the scope-id. => I don't know if we should add a field in hostent or extend the h_addr/h_addr_list[X] field. I am in favor of the second solution because in fact the scope ID is a property of addresses, not of nodes. Another point is the standard coding: bcopy(hp->h_addr, &sin.sin6_addr, hp-h_length); will copy both the address and its scope ID. Francis.Dupont@inria.fr PS: this is related to my idea of a new scoped address structure of course. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 5 03:40:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5Bbi007329 for ipng-dist; Fri, 5 Nov 1999 03:37:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5BbZi07322 for ; Fri, 5 Nov 1999 03:37:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA18662 for ; Fri, 5 Nov 1999 03:37:34 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04180 for ; Fri, 5 Nov 1999 04:37:33 -0700 (MST) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id UAA05680; Fri, 5 Nov 1999 20:26:45 +0900 (JST) Date: Fri, 05 Nov 1999 20:36:15 +0900 Message-ID: <14370.49455.912031.40681D@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Fri, 05 Nov 1999 00:22:26 -0500" <199911050522.AAA0000011164@quarry.zk3.dec.com> References: <199910271715.TAA20375@givry.inria.fr> <199911050522.AAA0000011164@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 75 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your comments. >>>>> On Fri, 05 Nov 1999 00:22:26 -0500, >>>>> Jim Bound said: >> There are several types of scoped addresses defined in the "IPv6 >> Addressing Architecture" [ADDRARCH]. Since uniqueness of a scoped >> address is guaranteed only within the according scope, the semantics >> for a scoped address is ambiguous on a scope boundary. For example, >> when a user specifies to send a packet from a node to a link-local >> address of another node, the user must specify the link of the >> destination as well, if the node is attached to more than one link. > The last sentence is not necessarily true. It is not the link that must > be specified but the scope. This is much different. And as you say > below: I'm sorry for the confusing text, but the last sentence is just an example for a link-local address. In general, of course, we should use the term "scope". >> This characteristic of scoped addresses may introduce additional cost >> to scope-aware applications; a scope-aware application may have to >> provide a way to specify an instance of a scope for each scoped >> address (e.g. a specific link for a link-local address) that the >> application uses. Also, it is hard for a user to "cut and paste" a >> scoped address due to the ambiguity of its scope. > The key phrase is scope-aware applications. It is not required by IPv6 > that any application be "scope aware". That's right. So the proposal is meaningful only for scope-aware applications. And there exist such applications definitely. > It is a feature we are in the > process of defining and the semantics and the syntax. Exactly. > I look forward to the discussion at the ipng meeting, but I think this > draft is premature similar to 6to4 specifying the address selection > mechanism before we had a src address selection plan. Likewise we need > a plan for scoping and what it means. I believe that was an action item > to discuss and get started for ipng and I believe that work must be a > predecessor to this work before we can agree this spec is valid. I agree that we should define "scope" more specifically, but I still believe that our proposal can progress on a parallel with defining the semantics of scope. > I also think we may or may not need to have the address as part of the > sin6_scope_id field. It could be any type of data to-be-defined. The mapping between the proposed format and the sin6_scope_id field described in the draft is just an example. We won't require the mapping. > Also unless this is to be anymore than an informational RFC for general > knowledge but not a standard. Either put your discussion of > getaddrinfoo in an appendix or address all parts of the base API. We > cannot have specs that only work with one part of the base API. I apologize for the incomplete examples. I didn't intend to get rid of other functions defined in the basic API such as getipnodebyname(). It's (again) just an example as a reference. In a revised version of the draft, I'll put the examples in an appendix and/or show some extension to the hostent structure so that getipnodeby*() can also handle the proposed format of scoped addresses. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 5 04:21:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5CIeJ07364 for ipng-dist; Fri, 5 Nov 1999 04:18:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5CIVi07357 for ; Fri, 5 Nov 1999 04:18:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA20921 for ; Fri, 5 Nov 1999 04:18:29 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA29406 for ; Fri, 5 Nov 1999 04:18:28 -0800 (PST) Received: from hygro.adsl.duke.edu (localhost [127.0.0.1]) by hygro.adsl.duke.edu (8.8.7/8.8.7) with ESMTP id HAA01589 for ; Fri, 5 Nov 1999 07:17:54 -0500 Message-Id: <199911051217.HAA01589@hygro.adsl.duke.edu> To: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addrconf-privacy-01.txt Date: Fri, 05 Nov 1999 07:17:54 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This might be considered expectable as a temporary "Fix" as long > as the user has the option. "temporary fix" implies the proposed solution is not adequate long-term. This assertion needs justification, if it's to be taken seriously. > Thomas Narten wrote: > > Has been submitted. Early birds can find it at > > ftp://ftp.cs.duke.edu/pub/narten/ietf/privacy.out. > > > > The major change is that it now calls for a node to have both public > > and "anonymous" addresses simultaneously, and that anonymous addresses > > apply to global scope prefixes only, not link-local or site-local. (It > > would be trivial to make site-local addresses anonymous as well, but > > it is not clear this is needed.) In addition, addresses change > > periodically (e.g., once a day) and not just when a machine > > restarts. Rich Draves also helped out and is now a coauthor. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 5 06:15:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5ECsp07457 for ipng-dist; Fri, 5 Nov 1999 06:12:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5ECki07450 for ; Fri, 5 Nov 1999 06:12:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA20146 for ; Fri, 5 Nov 1999 06:12:46 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11108 for ; Fri, 5 Nov 1999 07:12:45 -0700 (MST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 33EE15797F; Fri, 5 Nov 1999 08:12:45 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 912F84FB33; Fri, 5 Nov 1999 08:12:33 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 25C374C903; Fri, 5 Nov 1999 08:12:33 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000002363; Fri, 5 Nov 1999 09:12:44 -0500 (EST) From: Jim Bound Message-Id: <199911051412.JAA0000002363@quarry.zk3.dec.com> To: Francis Dupont Cc: sm@bossette.engr.sgi.com (Sam Manthorpe), ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Fri, 05 Nov 1999 11:35:38 +0100." <199911051035.LAA28996@givry.inria.fr> Date: Fri, 05 Nov 1999 09:12:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >=> I don't know if we should add a field in hostent or extend >the h_addr/h_addr_list[X] field. I am in favor of the second solution >because in fact the scope ID is a property of addresses, not of nodes. >Another point is the standard coding: >bcopy(hp->h_addr, &sin.sin6_addr, hp-h_length); >will copy both the address and its scope ID. >PS: this is related to my idea of a new scoped address structure of course. Well your code above won't work without the PS caveat. Well I don't we touch getipnodebyname again it is frozen. Also I think this idea of a new scoped address structure sucks and a very bad idea. This is really really bad. sockaddr_in6 must be left alone 1) because we have a solution without messing with it and 2) your now messing with deployed base. Just define how sin6_scope_id should be used and what it should contain. The default case is sin6_scope_id == ZERO or NULL. Applications that port to Ipv6 who are not scope aware should not be affected by not setting sin6_scope_id to anything. /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 Nov 5 06:18:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5EG3P07476 for ipng-dist; Fri, 5 Nov 1999 06:16:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5EFri07469 for ; Fri, 5 Nov 1999 06:15:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA02806 for ; Fri, 5 Nov 1999 06:15:54 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12328 for ; Fri, 5 Nov 1999 07:15:53 -0700 (MST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id EC581104C91; Fri, 5 Nov 1999 08:15:52 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 605B84FB2F; Fri, 5 Nov 1999 08:15:41 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 087774C902; Fri, 5 Nov 1999 08:15:41 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000002821; Fri, 5 Nov 1999 09:15:51 -0500 (EST) From: Jim Bound Message-Id: <199911051415.JAA0000002821@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Fri, 05 Nov 1999 20:36:15 +0900." <14370.49455.912031.40681D@condor.isl.rdc.toshiba.co.jp> Date: Fri, 05 Nov 1999 09:15:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK... another question.......... another point....... do you believe the sin6_scope_id should be used to define scope? Or where Francis's PS comment where scope is inherent in the sockaddr_in6 address? this is a critical point. thanks /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 Nov 5 11:11:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5J7pn07812 for ipng-dist; Fri, 5 Nov 1999 11:07:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5J7gi07805 for ; Fri, 5 Nov 1999 11:07:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA22363 for ; Fri, 5 Nov 1999 11:07:42 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17436 for ; Fri, 5 Nov 1999 12:07:40 -0700 (MST) Received: from ix.netcom.com (dal-tx7-32.ix.netcom.com [207.94.122.160]) by smtp10.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id OAA00705; Fri, 5 Nov 1999 14:07:31 -0500 (EST) Message-ID: <3823452D.219EA5DD@ix.netcom.com> Date: Fri, 05 Nov 1999 12:59:25 -0800 From: Jeff Williams X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addrconf-privacy-01.txt References: <199911051217.HAA01589@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas and all, Possibly you have forgotten, but I have already posted in some detail along with several others the specifics with respect to your response here several weeks ago to this list. You may wish to review the archives of this list for further details as to those posts in this respect. Thomas Narten wrote: > > This might be considered expectable as a temporary "Fix" as long > > as the user has the option. > > "temporary fix" implies the proposed solution is not adequate > long-term. This assertion needs justification, if it's to be taken > seriously. > > > Thomas Narten wrote: > > > > Has been submitted. Early birds can find it at > > > ftp://ftp.cs.duke.edu/pub/narten/ietf/privacy.out. > > > > > > The major change is that it now calls for a node to have both public > > > and "anonymous" addresses simultaneously, and that anonymous addresses > > > apply to global scope prefixes only, not link-local or site-local. (It > > > would be trivial to make site-local addresses anonymous as well, but > > > it is not clear this is needed.) In addition, addresses change > > > periodically (e.g., once a day) and not just when a machine > > > restarts. Rich Draves also helped out and is now a coauthor. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 5 11:15:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5JD9U07830 for ipng-dist; Fri, 5 Nov 1999 11:13:09 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5JD0i07823 for ; Fri, 5 Nov 1999 11:13:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA24654 for ; Fri, 5 Nov 1999 11:12:59 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17256 for ; Fri, 5 Nov 1999 11:12:58 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA19816; Fri, 5 Nov 1999 14:12:47 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA22708; Fri, 5 Nov 1999 14:12:50 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA24428; Fri, 5 Nov 1999 14:08:34 -0500 Message-Id: <199911051908.OAA24428@rotala.raleigh.ibm.com> To: Jeff Williams cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addrconf-privacy-01.txt In-Reply-To: Message from Jeff Williams of "Fri, 05 Nov 1999 12:59:25 PST." <3823452D.219EA5DD@ix.netcom.com> Date: Fri, 05 Nov 1999 14:08:34 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Possibly you have forgotten, but I have already posted in some > detail along with several others the specifics with respect to your > response here several weeks ago to this list. You may wish to > review the archives of this list for further details as to those posts > in this respect. I have read all the previous messages and do not know what specific point(s) you are refering to. Please be specific. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 5 11:27:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5JNio07865 for ipng-dist; Fri, 5 Nov 1999 11:23:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5JNai07858 for ; Fri, 5 Nov 1999 11:23:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA01612 for ; Fri, 5 Nov 1999 11:23:35 -0800 (PST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25046 for ; Fri, 5 Nov 1999 12:23:32 -0700 (MST) Received: from ix.netcom.com (dal-tx7-32.ix.netcom.com [207.94.122.160]) by smtp7.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id OAA27118; Fri, 5 Nov 1999 14:23:29 -0500 (EST) Message-ID: <382348EC.83D6ABF2@ix.netcom.com> Date: Fri, 05 Nov 1999 13:15:24 -0800 From: Jeff Williams X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: Thomas Narten Subject: Re: draft-ietf-ipngwg-addrconf-privacy-01.txt References: <199911051908.OAA24428@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas and all, As I said in my previous post, those specific points are well covered in my and others comments regarding this subject area. Evidently your very quick review missed some of those, based on your response here. Please do a very careful review. At present I don't have the time to repeat myself and others presently. Thank you for your cooperation in advance. Thomas Narten wrote: > > Possibly you have forgotten, but I have already posted in some > > detail along with several others the specifics with respect to your > > response here several weeks ago to this list. You may wish to > > review the archives of this list for further details as to those posts > > in this respect. > > I have read all the previous messages and do not know what specific > point(s) you are refering to. Please be specific. > > Thomas Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 5 11:48:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5JiYW07930 for ipng-dist; Fri, 5 Nov 1999 11:44:34 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5JiTi07922 for ; Fri, 5 Nov 1999 11:44:29 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA07181 for ipng@sunroof.eng.sun.com; Fri, 5 Nov 1999 11:44:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA58Lhi07121 for ; Fri, 5 Nov 1999 00:21:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA08592 for ; Fri, 5 Nov 1999 00:21:44 -0800 (PST) From: tkuiper@tobit.com Received: from mail.tobit.com (tobit.com [62.52.80.126]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA15319 for ; Fri, 5 Nov 1999 00:21:43 -0800 (PST) Message-Id: <199911050821.AAA15319@venus.Sun.COM> Subject: Novell Netware IPv6 Implementation To: ipng@sunroof.eng.sun.com Date: 05 Nov 99 08:21:45 UT X-Priority: 3 (Normal) Importance: normal X-Mailer: David by Tobit Software, Germany (PM-6.00a (0160)) X-David-Sym: 0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1DD2510B41FE" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------1DD2510B41FE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Does anyone know about an IPv6 Implementation for Novell Netware? I've send severall mails to Novell but all I get back is a pointer to some web sites which say its "going to be" built in into Netware 5 (documents are from this March). However, I didn't find any IPv6 stuff in the Netware 5 Version. Some real info would be welcome. Regards Thomas Kuiper Thomas Kuiper | tkuiper@tobit.com | __ Core Development | TK3680-RIPE | /__/\ Tobit Software GmbH | ICQ #8345483 | ask your server. \__\/ To: 6bone@ISI.EDU Cc: ipng@sunroof.eng.sun.com ipv6@uni-muenster.de --------------1DD2510B41FE-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 5 11:52:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5JoSl07971 for ipng-dist; Fri, 5 Nov 1999 11:50:28 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5JoJi07964 for ; Fri, 5 Nov 1999 11:50:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA26574 for ; Fri, 5 Nov 1999 11:50:18 -0800 (PST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06975 for ; Fri, 5 Nov 1999 11:50:17 -0800 (PST) Received: from ix.netcom.com (dal-tx47-39.ix.netcom.com [198.211.44.231]) by smtp7.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id OAA13570; Fri, 5 Nov 1999 14:50:04 -0500 (EST) Message-ID: <38234F26.F789BF35@ix.netcom.com> Date: Fri, 05 Nov 1999 13:41:58 -0800 From: Jeff Williams X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Thomas Narten CC: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addrconf-privacy-01.txt References: <199911051908.OAA24428@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas and all, Again, I already have in several previous posts. Please review more carefully. Thank you for your cooperation in advance... Thomas Narten wrote: > > Possibly you have forgotten, but I have already posted in some > > detail along with several others the specifics with respect to your > > response here several weeks ago to this list. You may wish to > > review the archives of this list for further details as to those posts > > in this respect. > > I have read all the previous messages and do not know what specific > point(s) you are refering to. Please be specific. > > Thomas > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 5 12:43:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA5KZ4p08051 for ipng-dist; Fri, 5 Nov 1999 12:35:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA5KYsi08043 for ; Fri, 5 Nov 1999 12:34:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA10616 for ; Fri, 5 Nov 1999 12:34:53 -0800 (PST) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27162 for ; Fri, 5 Nov 1999 12:34:53 -0800 (PST) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id MAA09151; Fri, 5 Nov 1999 12:34:08 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id MAA90216; Fri, 5 Nov 1999 12:33:03 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id MAA63967; Fri, 5 Nov 1999 12:33:01 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911052033.MAA63967@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: bound@zk3.dec.com (Jim Bound) Date: Fri, 5 Nov 1999 12:33:01 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911050423.XAA0000031612@quarry.zk3.dec.com> from "Jim Bound" at Nov 4, 99 11:23:15 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > Now I see the complication. In the base api spec we state this is for > future work and from the pointers to the Japan meeting this came up > there too. I think we will see a separate piece of work for scoping > which was what we decided when we added this field to sockaddr_in6. > What we wanted to do was freeze the changes to the baseapi and define it > in a manner that adjunct work could be done on it as needed and by the > advanced API too. Okay, I'm happier knowing that this issue is being addressed. My concern comes from the fact that in our implementation is it stands today (we support scope-id in the kernel), I have no way of pinging to a link-local address that is on a link other than the one pointed to be the fe80::/10 default route. I could solve this problem by adding code to ping to parse a scope-id and set the sin6_scope_id in the sockaddr but that's clearly not the way to go. I could use getaddrinfo(), but I would much prefer to have the required functionality in getipnodebyname(). Thanks, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 5 16:14:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA60AWq08361 for ipng-dist; Fri, 5 Nov 1999 16:10:32 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA60ANi08354 for ; Fri, 5 Nov 1999 16:10:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA23243 for ; Fri, 5 Nov 1999 16:10:23 -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 QAA20881 for ; Fri, 5 Nov 1999 16:10:22 -0800 (PST) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id QAA11975; Fri, 5 Nov 1999 16:09:49 -0800 (PST) Message-Id: <4.2.0.58.19991105160522.03a59900@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 05 Nov 1999 16:08:41 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng Agenda for Washington DC IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Attached is the agenda for IPng w.g. sessions at the Washington D.C. IETF. Both sessions will be multicast. Please send me changes, additions, and corrections. Thanks, Bob ------------------------------------------------------------------- WEDNESDAY, November 10, 1999 1300-1500 (Regency) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Summary of Tokyo Interim Meeting / S. Deering (10 min) IPv6 extensions to RPC / S. Majee (15 min) TAHI IPv6 Interoperability Test Report H. Miyata (10 min) IPv6 Socket Scrubber / C. Williams (10 min) Connection/Link Status Investigation (CSI) / H. Kitamura (10 min) Unidirectional Link Routing / H. Afifi (5 min) IPng Statement on Privacy / S. Deering (5 min) Privacy Issues w/ Addrconf / Anonymous (20 min) THURSDAY, November 11, 1999 1300-1500 (Regency) Wireless Telephony / C. Perkins (30) Source Address Selection Draft (R. Draves) / S. Deering (30 min) Text Syntax for Scoped Addresses / T. Jinmei (15 min) Inverse ARP / A. Conta (10 min) Link-Local Packet Forwarding / A. Conta (15 min) ------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 5 18:42:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA62Xg008524 for ipng-dist; Fri, 5 Nov 1999 18:33:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA62XXi08517 for ; Fri, 5 Nov 1999 18:33:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA10847 for ; Fri, 5 Nov 1999 18:33:32 -0800 (PST) Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28780 for ; Fri, 5 Nov 1999 18:33:32 -0800 (PST) Received: from ix.netcom.com (dal-tx48-26.ix.netcom.com [198.211.45.90]) by smtp6.mindspring.com (8.8.5/8.8.5) with ESMTP id VAA25666; Fri, 5 Nov 1999 21:33:24 -0500 (EST) Message-ID: <3823ADAF.780D2EEA@ix.netcom.com> Date: Fri, 05 Nov 1999 20:25:19 -0800 From: Jeff Williams X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Bob Hinden CC: ipng@sunroof.eng.sun.com Subject: Re: IPng Agenda for Washington DC IETF References: <4.2.0.58.19991105160522.03a59900@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob and all, Seems like there is precious little time spent on IPv6 Privacy issues here. Is that intentional I wonder? Bob Hinden wrote: > Attached is the agenda for IPng w.g. sessions at the Washington D.C. > IETF. Both sessions will be multicast. > > Please send me changes, additions, and corrections. > > Thanks, > Bob > > ------------------------------------------------------------------- > > WEDNESDAY, November 10, 1999 1300-1500 (Regency) > > Introduction / S. Deering (5 min) > Review Agenda / S. Deering (5 min) > Document Status / R. Hinden (10 min) > Summary of Tokyo Interim Meeting / S. Deering (10 min) > IPv6 extensions to RPC / S. Majee (15 min) > TAHI IPv6 Interoperability Test Report H. Miyata (10 min) > IPv6 Socket Scrubber / C. Williams (10 min) > Connection/Link Status Investigation (CSI) / H. Kitamura (10 min) > Unidirectional Link Routing / H. Afifi (5 min) > IPng Statement on Privacy / S. Deering (5 min) > Privacy Issues w/ Addrconf / Anonymous (20 min) > > THURSDAY, November 11, 1999 1300-1500 (Regency) > > Wireless Telephony / C. Perkins (30) > Source Address Selection Draft (R. Draves) / S. Deering (30 min) > Text Syntax for Scoped Addresses / T. Jinmei (15 min) > Inverse ARP / A. Conta (10 min) > Link-Local Packet Forwarding / A. Conta (15 min) > > ------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 6 05:50:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA6Dlfv08819 for ipng-dist; Sat, 6 Nov 1999 05:47:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA6DlXi08812 for ; Sat, 6 Nov 1999 05:47:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA11134 for ; Sat, 6 Nov 1999 05:47:33 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA22865 for ; Sat, 6 Nov 1999 05:47:33 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id AA287151F98; Sat, 6 Nov 1999 07:47:32 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 876B84FB06; Sat, 6 Nov 1999 07:47:19 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 346974C901; Sat, 6 Nov 1999 07:47:19 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id IAA0000028440; Sat, 6 Nov 1999 08:47:31 -0500 (EST) From: Jim Bound Message-Id: <199911061347.IAA0000028440@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Fri, 05 Nov 1999 12:33:01 PST." <199911052033.MAA63967@bossette.engr.sgi.com> Date: Sat, 06 Nov 1999 08:47:31 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sam, this is good input to the work on scopes tbd. as jack mccann pointed out in our implementation if scopeid is non-null and address is link-local then scope-id equals interface ID. for now this is one way to do it and not break the spec. note this works with getipnodebyname by just setting sin6_scope_id to the value of the interface you would want to ping with link-local in your case and previoius mail. thanks /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 Sat Nov 6 06:18:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA6EDsY08868 for ipng-dist; Sat, 6 Nov 1999 06:13:54 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA6EDki08861 for ; Sat, 6 Nov 1999 06:13:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA00054 for ; Sat, 6 Nov 1999 06:13:46 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09328 for ; Sat, 6 Nov 1999 07:13:45 -0700 (MST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 4DFF4104BAE for ; Sat, 6 Nov 1999 08:13:45 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 6E7D3BC4C3; Sat, 6 Nov 1999 08:13:30 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 266E0B2A42 for ; Sat, 6 Nov 1999 08:13:30 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000003609; Sat, 6 Nov 1999 09:13:44 -0500 (EST) From: Jim Bound Message-Id: <199911061413.JAA0000003609@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Fri, 05 Nov 1999 12:33:01 PST." <199911052033.MAA63967@bossette.engr.sgi.com> Date: Sat, 06 Nov 1999 09:13:44 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks I want to point out with getaddrinfo: One of our engineers pointed this out and I also alluded to it in my mail discussion with Dave. XNET would have to add the necessary flags in getaddrinfo that are used by getipnodebyname, but they are not part of the getaddrinfo in rfc2553. /jim ----------------------------------------------------------- Jim This is from ipng list battle about getipnode*/getaddrinfo. Please note that hints.ai_flags below is set to invalid flags (by my last understanding of rfc 2553). -vlad Erik Nordmark wrote: > > int > myconnect(char *hostname, char *servicename) > { > struct addrinfo *res, *aip; > struct addrinfo hints; > int sock = -1; > int error; > > /* Get host address. Any type of address will do. */ > bzero(&hints, sizeof (hints)); > hints.ai_flags = AI_ALL|AI_ADDRCONFIG; > hints.ai_socktype = SOCK_STREAM; > > error = getaddrinfo(hostname, servicename, &hints, &aip); > if (error != 0) { > (void) fprintf(stderr, > "getaddrinfo: %s for host %s service %s\n", > gai_strerror(error), hostname, servicename); > return (-1); > } > > /* Open socket. */ > sock = socket(aip->ai_family, aip->ai_socktype, aip->ai_protocol); > if (sock == -1) { > perror("socket"); > freeaddrinfo(res); > return (-1); > } > > /* Connect to the host. */ > if (connect(sock, aip->ai_addr, aip->ai_addrlen) == -1) { > perror("connect"); > (void) close(sock); > return (-1); > } > freeaddrinfo(res); > return (sock); > } -- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 09:55:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA6Hraw08934 for ipng-dist; Sat, 6 Nov 1999 09:53:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA6HrRi08927 for ; Sat, 6 Nov 1999 09:53:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA28791 for ; Sat, 6 Nov 1999 09:53:26 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19961 for ; Sat, 6 Nov 1999 09:53:03 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id CAA11310; Sun, 7 Nov 1999 02:41:23 +0900 (JST) Date: Sun, 07 Nov 1999 02:50:56 +0900 Message-ID: <14372.27264.97404.9765Q@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Fri, 05 Nov 1999 09:15:51 -0500" <199911051415.JAA0000002821@quarry.zk3.dec.com> References: <14370.49455.912031.40681D@condor.isl.rdc.toshiba.co.jp> <199911051415.JAA0000002821@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 47 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 05 Nov 1999 09:15:51 -0500, >>>>> Jim Bound said: > do you believe the sin6_scope_id should be used to define scope? Yes. > Or where Francis's PS comment where scope is inherent in the > sockaddr_in6 address? I may miss your point, but do you mean the in6_addr structure here? As far as I know, his proposal is like this: struct in6_scaddr { struct in6_addr sc6_addr; uint32_t sc6_scope_id; }; which should replace the in6_addr structure itself. But, okay, this is a minor detail. > this is a critical point. Hmm...this seems a difficult question to answer.. If I could design the basic API from the scratch, I'd support the Francis' idea, since a scoped address without its scope identifier is incomplete as an IP address. However, from a deployment point of view, replacing such a fundamental structure has too big impact. It'll affect many existing applications and break source/binary level compatibility. So my current position is: - we should keep the sockaddr_in6 structure and just define the semantics of the sin6_scope_id field. - we could define a new structure like in6_scaddr, but the new structure should not affect existing applications and library functions. Is this clear (and acceptable, I hope) for you? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 6 11:48:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA6JjV008978 for ipng-dist; Sat, 6 Nov 1999 11:45:31 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA6JjMi08971 for ; Sat, 6 Nov 1999 11:45:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA04963 for ; Sat, 6 Nov 1999 11:45:21 -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 LAA02484 for ; Sat, 6 Nov 1999 11:45:21 -0800 (PST) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id LAA10063; Sat, 6 Nov 1999 11:45:20 -0800 (PST) Message-Id: <4.2.0.58.19991106114202.00d2ae70@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 06 Nov 1999 11:44:15 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Re: IPng Agenda for Washington DC IETF Cc: Bob Hinden In-Reply-To: <3823ADAF.780D2EEA@ix.netcom.com> References: <4.2.0.58.19991105160522.03a59900@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If anyone would like agenda time to talk about specific issues, please contact the chairs as has been requested in previous messages. Bob >At 08:25 PM 11/5/99 -0800, Jeff Williams wrote: > Seems like there is precious little time spent on IPv6 Privacy >issues here. Is that intentional I wonder? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 13:41:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA6LdGd09007 for ipng-dist; Sat, 6 Nov 1999 13:39:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA6Lcti09000 for ; Sat, 6 Nov 1999 13:38:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA07738 for ; Sat, 6 Nov 1999 13:38:53 -0800 (PST) Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25153 for ; Sat, 6 Nov 1999 14:38:53 -0700 (MST) Received: from ix.netcom.com (dal-tx43-60.ix.netcom.com [207.221.94.188]) by smtp10.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id QAA09723; Sat, 6 Nov 1999 16:38:49 -0500 (EST) Message-ID: <3824BA22.BFEFCE78@ix.netcom.com> Date: Sat, 06 Nov 1999 15:30:42 -0800 From: Jeff Williams X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Bob Hinden CC: ipng@sunroof.eng.sun.com Subject: Re: IPng Agenda for Washington DC IETF References: <4.2.0.58.19991105160522.03a59900@mailhost.iprg.nokia.com> <4.2.0.58.19991106114202.00d2ae70@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob and all, Please consider my previous post, (See Below) as being so contacted. Thank you for your cooperation in advance. Bob Hinden wrote: > If anyone would like agenda time to talk about specific issues, please > contact the chairs as has been requested in previous messages. > > Bob > > >At 08:25 PM 11/5/99 -0800, Jeff Williams wrote: > > Seems like there is precious little time spent on IPv6 Privacy > >issues here. Is that intentional I wonder? > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 7 20:21:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA84JG409641 for ipng-dist; Sun, 7 Nov 1999 20:19:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA84J5i09634 for ; Sun, 7 Nov 1999 20:19:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA01554 for ; Sun, 7 Nov 1999 20:19:04 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA13285 for ; Sun, 7 Nov 1999 21:19:03 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 07 Nov 1999 19:36:05 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Sun, 7 Nov 1999 19:36:05 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712ED1@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Date: Sun, 7 Nov 1999 19:36:04 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > note this works with getipnodebyname by just setting sin6_scope_id to > the value of the interface you would want to ping with link-local in > your case and previoius mail. I think Sam's point (or at least mine if it wasn't) is that since getipnodebyname doesn't return a sin6_scope_id, you can't just pass it a numeric address string (the format of which is what this thread started out discussing) like "2/fe80::1" and get back something that has parsed the scope_id part and put in a nice variable for you. getaddrinfo, by virtue of returning an addrinfo structure containing a sockaddr_in6 rather than a hostent structure containing a in6_addr, does this. So if you want to use getipnodebyname with numeric scoped address strings, you have to seperately parse the address string the user gives you for potential scope. This is extra work, and makes it harder for a programmer to support scoped addresses via getipnodebyname than via getaddrinfo. And if you want to use getipnodebyname with DNS names that correspond to scoped addresses, you can't. The possible courses of action I've seen proposed by various people are (I could have forgot some): (1) Do nothing. Programs aren't required to be "scope aware", so programmers who want their programs to work with scoped addresses can either use getaddrinfo or perform the extra parsing themselves. This has the nice quality that we don't have to change this part of the basic API at this late date. It has the downside that you can't get scoped addresses out of the DNS this way. (2) Change getipnodebyname to return an additional out parameter which is the scope_id of the address being returned in the hostent structure. This has the problem that hostents can contain multiple addresses, which might have different scope_ids. But for numeric address strings, the hostent will never contain more than one address, so it wouldn't matter for them... but many people think that we should be able to put scoped addresses in the DNS, where this would break. (3) Change the hostent structure to contain a scope_id field in addition to an in6_addr field. This also has the problem with hostents containing multiple addresses. (4) Change the in6_addr field in hostents to a new field that groups a scope_id field in with the 128 bit address field. This is pretty clean, but involves changing the basic API spec. Oh, and unless I'm missing something, the same issue exists for inet_ntop, inet_pton, and getipnodebyaddr. --Brian > > thanks > /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 Sun Nov 7 22:27:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA86LNb09712 for ipng-dist; Sun, 7 Nov 1999 22:21:23 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA86LCi09705 for ; Sun, 7 Nov 1999 22:21:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA29622 for ; Sun, 7 Nov 1999 22:21:11 -0800 (PST) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA28496 for ; Sun, 7 Nov 1999 23:21:11 -0700 (MST) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id WAA00751; Sun, 7 Nov 1999 22:20:28 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA35006; Sun, 7 Nov 1999 22:19:21 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id WAA74133; Sun, 7 Nov 1999 22:19:19 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911080619.WAA74133@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: bzill@microsoft.com (Brian Zill) Date: Sun, 7 Nov 1999 22:19:19 -0800 (PST) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <3D2036E25376D31197A100805FEAD892712ED1@RED-MSG-02> from "Brian Zill" at Nov 7, 99 07:36:04 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Zill wrote: > > note this works with getipnodebyname by just setting sin6_scope_id to > > the value of the interface you would want to ping with link-local in > > your case and previoius mail. > > I think Sam's point (or at least mine if it wasn't) is that since > getipnodebyname doesn't return a sin6_scope_id, you can't just pass it a > numeric address string (the format of which is what this thread started out > discussing) like "2/fe80::1" and get back something that has parsed the > scope_id part and put in a nice variable for you. Yes, that was my point. > The possible courses of action I've seen proposed by various people are (I > could have forgot some): [ snip ] One other backwardsly compatible idea I was toying with was to define a new flag for getipnodebyname() which, if set, indicates that the app wants a sockaddr_in6 address rather than a `raw' IPv6 address in the h_addr_list array. I was pondering on just how ugly it was before I sent it to the list, but since you bring the subject up, there it is. > Oh, and unless I'm missing something, the same issue exists for inet_ntop, > inet_pton, and getipnodebyaddr. Hmm, yes, I guess it does. Thanks, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 8 04:35:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA8CT4A09921 for ipng-dist; Mon, 8 Nov 1999 04:29:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA8CSsi09914 for ; Mon, 8 Nov 1999 04:28:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA23359 for ; Mon, 8 Nov 1999 04:28:53 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA00846 for ; Mon, 8 Nov 1999 04:28:52 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 026DD1520DE; Mon, 8 Nov 1999 06:28:52 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id E43184FB01; Mon, 8 Nov 1999 06:28:35 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 8C4D84C902; Mon, 8 Nov 1999 06:28:35 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id HAA0000007752; Mon, 8 Nov 1999 07:28:50 -0500 (EST) From: Jim Bound Message-Id: <199911081228.HAA0000007752@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Sun, 07 Nov 1999 02:50:56 +0900." <14372.27264.97404.9765Q@condor.isl.rdc.toshiba.co.jp> Date: Mon, 08 Nov 1999 07:28:50 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So my current position is: > - we should keep the sockaddr_in6 structure and just define the > semantics of the sin6_scope_id field. > - we could define a new structure like in6_scaddr, but the new > structure should not affect existing applications and library > functions. > >Is this clear (and acceptable, I hope) for you? > Yes it is. I am not sure we need a new structure if we define semantics of sin6_scope_id. Good response..thanks... /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 Mon Nov 8 04:49:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA8Ck1309957 for ipng-dist; Mon, 8 Nov 1999 04:46:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA8Cjqi09950 for ; Mon, 8 Nov 1999 04:45:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA20313 for ; Mon, 8 Nov 1999 04:45:51 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05963 for ; Mon, 8 Nov 1999 04:45:51 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id DA310104B84 for ; Mon, 8 Nov 1999 06:45:50 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id D58B84FB1A; Mon, 8 Nov 1999 06:45:34 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 73E384C901; Mon, 8 Nov 1999 06:45:34 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id HAA0000010372; Mon, 8 Nov 1999 07:45:49 -0500 (EST) From: Jim Bound Message-Id: <199911081245.HAA0000010372@quarry.zk3.dec.com> To: Brian Zill Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Sun, 07 Nov 1999 19:36:04 PST." <3D2036E25376D31197A100805FEAD892712ED1@RED-MSG-02> Date: Mon, 08 Nov 1999 07:45:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk brian, other option is to have an operation to perform scoping on the field once back from getipnodebyname. we need to discuss this at ipng this week. /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 Mon Nov 8 11:51:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA8JiiS10358 for ipng-dist; Mon, 8 Nov 1999 11:44:44 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA8JiZi10351 for ; Mon, 8 Nov 1999 11:44:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA27785 for ; Mon, 8 Nov 1999 11:44:34 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08610 for ; Mon, 8 Nov 1999 11:44:33 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id UAA17100; Mon, 8 Nov 1999 20:44:29 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA09987; Mon, 8 Nov 1999 20:44:29 +0100 (MET) Message-Id: <199911081944.UAA09987@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Sun, 07 Nov 1999 02:50:56 +0900. <14372.27264.97404.9765Q@condor.isl.rdc.toshiba.co.jp> Date: Mon, 08 Nov 1999 20:44:28 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> Jim Bound said: > do you believe the sin6_scope_id should be used to define scope? Yes. => there is a misunderstanding. I think in some cases an IPv6 address alone (an in6_addr structure) is not enough and a scope ID must be provided with it. Of course the sin6_scope_id field should be used when a full sockaddr_in6 is there. My problem is that for perhaps not so good reasons some applications use directly in6_addr structures without scope IDs. This is wrong and can be fixed in two ways: - use a sockaddr_in6 in place of an in6_addr - add a scope ID field in these applications. The second solution may be useful if the price of a sockaddr_in6 (or a sockaddr_storage) is too high but we want the same thing, ie. kill wrong ways to deal with IPv6 addresses in applications... > this is a critical point. Hmm...this seems a difficult question to answer.. If I could design the basic API from the scratch, I'd support the Francis' idea, since a scoped address without its scope identifier is incomplete as an IP address. => we agree about what is the problem to solve. However, from a deployment point of view, replacing such a fundamental structure has too big impact. It'll affect many existing applications and break source/binary level compatibility. => this is not my proposal! I don't want to change the in6_addr everywhere, I'd just like to convince people who use in6_addr today to change to something with a scope ID and if sockaddr_in6 is too expensive I propose a cheap way to do it. There are many places where an address with a scope is enough, the first example is the in6_pktinfo structure... So my current position is: - we should keep the sockaddr_in6 structure and just define the semantics of the sin6_scope_id field. - we could define a new structure like in6_scaddr, but the new structure should not affect existing applications and library functions. Is this clear (and acceptable, I hope) for you? => this is my position too. BTW about getipnodebyname(), we need to get a way to have scope ID(s) added to the result (the hostent structure). If we don't do that getipnodebyname() won't be used because it will be too easy to find examples which break it. A scope ID is more a property of an address than of a hostent, then we should restrict hostent to one address if we can put only one scope ID in it, or add an optional (default value will be 0) scope ID per address. I've just given a way to code (address, scope ID) pairs... Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 8 19:31:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA93MPi10890 for ipng-dist; Mon, 8 Nov 1999 19:22:25 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA93MGi10883 for ; Mon, 8 Nov 1999 19:22:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA00310 for ; Mon, 8 Nov 1999 19:22:15 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA14930 for ; Mon, 8 Nov 1999 20:22:14 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA10284465; Mon, 8 Nov 1999 19:22:10 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA98934; Mon, 8 Nov 1999 19:22:07 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id TAA78481; Mon, 8 Nov 1999 19:22:06 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911090322.TAA78481@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: Francis.Dupont@inria.fr (Francis Dupont) Date: Mon, 8 Nov 1999 19:22:05 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911081944.UAA09987@givry.inria.fr> from "Francis Dupont" at Nov 8, 99 08:44:28 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > BTW about getipnodebyname(), we need to get a way to have scope ID(s) > added to the result (the hostent structure). If we don't do that > getipnodebyname() won't be used because it will be too easy to find > examples which break it. Yes that was exactly the point of the related tributary-thread. > A scope ID is more a property of an address than of a hostent, > then we should restrict hostent to one address if we can put only > one scope ID in it, or add an optional (default value will be 0) > scope ID per address. I've just given a way to code (address, scope ID) > pairs... Yes, as you and Brian have explained, per hostent or per-call-to- getipnodebyname() scope-ids aren't really sound; I now think the only real way to solve the problem is to change the data types used in the list of addresses from in6_addr to either sockaddr_in6 or your proposed sockaddr_in6_lite (if I may call it that). Should this just be done, breaking the existing API? What about the additional getipnodebyname() flag indicating that a scope-id is desired that I suggested in my last mail? -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 8 20:29:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA94NBK10960 for ipng-dist; Mon, 8 Nov 1999 20:23:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA94N2i10953 for ; Mon, 8 Nov 1999 20:23:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA01497 for ; Mon, 8 Nov 1999 20:23:01 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA29438 for ; Mon, 8 Nov 1999 21:22:58 -0700 (MST) Received: from localhost ([3ffe:507:182:1:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id NAA00691; Tue, 9 Nov 1999 13:10:41 +0900 (JST) Date: Tue, 09 Nov 1999 13:21:44 +0900 Message-ID: <14375.41304.882729.51988Z@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Mon, 08 Nov 1999 20:44:28 +0100" <199911081944.UAA09987@givry.inria.fr> References: <14372.27264.97404.9765Q@condor.isl.rdc.toshiba.co.jp> <199911081944.UAA09987@givry.inria.fr> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 08 Nov 1999 20:44:28 +0100, >>>>> Francis Dupont said: > => there is a misunderstanding. I think in some cases an IPv6 address > alone (an in6_addr structure) is not enough and a scope ID must be > provided with it. Of course the sin6_scope_id field should be used > when a full sockaddr_in6 is there. > My problem is that for perhaps not so good reasons some applications > use directly in6_addr structures without scope IDs. This is wrong and > can be fixed in two ways: > - use a sockaddr_in6 in place of an in6_addr > - add a scope ID field in these applications. > The second solution may be useful if the price of a sockaddr_in6 > (or a sockaddr_storage) is too high but we want the same thing, > ie. kill wrong ways to deal with IPv6 addresses in applications... Ah, okay. Sorry for misunderstanding and thank you for clarification. > So my current position is: > - we should keep the sockaddr_in6 structure and just define the > semantics of the sin6_scope_id field. > - we could define a new structure like in6_scaddr, but the new > structure should not affect existing applications and library > functions. > Is this clear (and acceptable, I hope) for you? > => this is my position too. Okay, thanks. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 8 21:36:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA95U8O11038 for ipng-dist; Mon, 8 Nov 1999 21:30:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA95Tai11030 for ; Mon, 8 Nov 1999 21:29:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA16326 for ; Mon, 8 Nov 1999 21:29:34 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA04125 for ; Mon, 8 Nov 1999 21:29:34 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Nov 1999 21:26:56 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Mon, 8 Nov 1999 21:26:56 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712ED8@RED-MSG-02> From: Brian Zill To: "'sm@bossette.engr.sgi.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Date: Mon, 8 Nov 1999 21:26:55 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: sm@bossette.engr.sgi.com [mailto:sm@bossette.engr.sgi.com] > > I now think the only real way to solve the problem > is to change the data types used in the list of > addresses from in6_addr to either sockaddr_in6 or > your proposed sockaddr_in6_lite (if I may call it > that). Should this just be done, breaking the > existing API? I agree that this is the only way to cleanly solve the problem. Basically, everything that takes an in_addr today should also take a scope_id along with it. A scoped IPv6 address isn't complete without its corresponding scope id, so this is clearly the correct thing to do. However, it means changing a lot of the existing basic API spec, which might not sit well with some people. Personally, I'm leaning toward accepting the pain now and doing it right, rather than be sorry later. > What about the additional getipnodebyname() flag > indicating that a scope-id is desired that I > suggested in my last mail? That's another option - leave the existing functionality while providing equivalent scope aware versions either through flags to the existing APIs or to a new track of parallel APIs. Of course, this would leave us open to the criticism that getipnodebyname and friends are already new APIs for IPv6, so we should specify them correctly, rather than create what are going to immediately become outdated legacy interfaces. --Brian > > -- Sam > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 > sm@engr.sgi.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 Nov 9 04:52:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9Chdr11257 for ipng-dist; Tue, 9 Nov 1999 04:43:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9ChJi11250 for ; Tue, 9 Nov 1999 04:43:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA20047 for ; Tue, 9 Nov 1999 04:43:18 -0800 (PST) Received: from basil.cdt.luth.se (basil.cdt.luth.se [130.240.64.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14997 for ; Tue, 9 Nov 1999 05:43:16 -0700 (MST) Received: from hogan (slip129-37-49-184.ca.us.prserv.net [129.37.49.184]) by basil.cdt.luth.se (8.9.3/8.7.3) with SMTP id NAA02464; Tue, 9 Nov 1999 13:42:55 +0100 (MET) Message-Id: <3.0.6.32.19991109144740.0083d680@cdt.luth.se> X-Sender: micke@cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 09 Nov 1999 14:47:40 +0100 To: ipng@sunroof.eng.sun.com, rem-conf@es.net, pilc@grc.nasa.gov, iptel@lists.research.bell-labs.com From: Mikael Degermark Subject: Robust Header Compression BOF agenda Cc: micke@basil.cdt.luth.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a revised agenda for the robust header compression BOF to be held today Tuesday. As this is the night of the social event, we will ignore the break and instead aim to finish 17.45 at the latest. ------------- Robust Header compression BOF (robhc) Tuesday, November 9 at 1545-1800 ========== CHAIRS: Mikael Degermark Stephen Pink DESCRIPTION: The cellular community is now standardizing the next generation cellular systems. These systems will use IP to deliver telephony to coming mobile phones, to allow end-to-end IP telephony. As cellular bandwith is expensive, radio spectrum efficiency is of outmost importance and thus the IP/UDP/RTP headers must be compressed over the air. 3GPP has specified the requirements for the needed header compression scheme and it has been shown that no current header compression scheme in the IETF can satisfy these requirements. CRTP [RFC-2508] is the closest candidate but is not sufficiently robust against errors on the link, i.e., CRTP cannot deliver acceptable performance at the anticipated error rates. It is likely that the number of users of cellular IP telephony will be larger than the current number of people using TCP/IP, therefore it is important that a suitable header compression scheme is developed. The BOF will outline the relevant properties of the cellular links, the requirements, and will explain why CRTP fails. One or more proposals for a suitable header compression scheme will be presented, and finally we will discuss if and how the IETF will work on standardizing a suitable header compression scheme. AGENDA 0. Introduction Mikael Degermark 1. 3GPP timeline Mats Nilsson 2. 3GPP requirements on robust header compression. Khiem Le, Nokia draft-degermark-hc-requirements-00.txt 3. Why CRTP is not good enough Mikael Degermark draft-degermark-crtp-eval-00.{ps,txt} 4. Cellular link properties affecting header compression - delays, error rates & error distributions for EDGE, WCDMA, GSM, etc. Krister Svanbro, Ericsson 5. RObust Checksum-based header COmpression - ROCCO Lars-Erik Jonsson, Ericsson draft-jonsson-robust-hc-02.{ps,txt} 6. Should we propose that a WG is formed? Outline of charter presented. Mikael Degermark -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 07:26:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9FDpR11359 for ipng-dist; Tue, 9 Nov 1999 07:13:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9FDZi11352 for ; Tue, 9 Nov 1999 07:13:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA13851 for ; Tue, 9 Nov 1999 07:13:35 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03825 for ; Tue, 9 Nov 1999 07:13:29 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id QAA12757; Tue, 9 Nov 1999 16:13:23 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id QAA29461; Tue, 9 Nov 1999 16:13:21 +0100 (MET) Message-Id: <199911091513.QAA29461@givry.inria.fr> From: Francis Dupont To: Brian Zill cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Sun, 07 Nov 1999 19:36:04 PST. <3D2036E25376D31197A100805FEAD892712ED1@RED-MSG-02> Date: Tue, 09 Nov 1999 16:13:15 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: So if you want to use getipnodebyname with numeric scoped address strings, you have to seperately parse the address string the user gives you for potential scope. This is extra work, and makes it harder for a programmer to support scoped addresses via getipnodebyname than via getaddrinfo. And if you want to use getipnodebyname with DNS names that correspond to scoped addresses, you can't. The possible courses of action I've seen proposed by various people are (I could have forgot some): (1-4)... Oh, and unless I'm missing something, the same issue exists for inet_ntop, inet_pton, and getipnodebyaddr. => Brian, this is an excellent summary! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 07:38:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9FS2f11410 for ipng-dist; Tue, 9 Nov 1999 07:28:02 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9FRpi11403 for ; Tue, 9 Nov 1999 07:27:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA15467 for ; Tue, 9 Nov 1999 07:27:51 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15060 for ; Tue, 9 Nov 1999 08:27:45 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id QAA13152; Tue, 9 Nov 1999 16:27:25 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id QAA11824; Tue, 9 Nov 1999 16:27:23 +0100 (MET) Message-Id: <199911091527.QAA11824@givry.inria.fr> From: Francis Dupont To: sm@bossette.engr.sgi.com (Sam Manthorpe) cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Mon, 08 Nov 1999 19:22:05 PST. <199911090322.TAA78481@bossette.engr.sgi.com> Date: Tue, 09 Nov 1999 16:27:22 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Should this just be done, breaking the existing API? => to break the API is a non-goal... The choice is between to show the extra infos in the h_length or not. First is better but has more impact. What about the additional getipnodebyname() flag indicating that a scope-id is desired that I suggested in my last mail? => a new flag will help if the h_length reflects more than an in6_addr but the issue becomes "is this flag set in the default?". Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 08:08:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9G4Pt11483 for ipng-dist; Tue, 9 Nov 1999 08:04:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9G4Gi11476 for ; Tue, 9 Nov 1999 08:04:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA04403 for ; Tue, 9 Nov 1999 08:04:16 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25956 for ; Tue, 9 Nov 1999 08:04:16 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id D7C1B152188; Tue, 9 Nov 1999 10:04:15 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 89DC84FB06; Tue, 9 Nov 1999 10:03:57 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 20E184C903; Tue, 9 Nov 1999 10:03:57 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000028482; Tue, 9 Nov 1999 11:04:14 -0500 (EST) From: Jim Bound Message-Id: <199911091604.LAA0000028482@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: Francis.Dupont@inria.fr (Francis Dupont), ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Mon, 08 Nov 1999 19:22:05 PST." <199911090322.TAA78481@bossette.engr.sgi.com> Date: Tue, 09 Nov 1999 11:04:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I strongly objecty to this and will object as far as need be. getipnodebyanme is frozen and in products we cannot change it. if we change it we don't have a clue and should never work on APIs in the ietf for IPv6 again. I am serious folks. Changing this will break products and cause a deployment of IPv6 issue. I am bringing this up at the IAB this wed evening at the IETF. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 08:09:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9G7iS11492 for ipng-dist; Tue, 9 Nov 1999 08:07:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9G7Zi11485 for ; Tue, 9 Nov 1999 08:07:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA25212 for ; Tue, 9 Nov 1999 08:07:35 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27483 for ; Tue, 9 Nov 1999 08:07:35 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 190229A9C6; Tue, 9 Nov 1999 10:07:34 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 33638BC4D2; Tue, 9 Nov 1999 10:07:12 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id ADF5BB2A42; Tue, 9 Nov 1999 10:07:11 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000031692; Tue, 9 Nov 1999 11:07:32 -0500 (EST) From: Jim Bound Message-Id: <199911091607.LAA0000031692@quarry.zk3.dec.com> To: Brian Zill Cc: "'sm@bossette.engr.sgi.com'" , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Mon, 08 Nov 1999 21:26:55 PST." <3D2036E25376D31197A100805FEAD892712ED8@RED-MSG-02> Date: Tue, 09 Nov 1999 11:07:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, You have not shipped a product and not even a date when you might. We have shipped a product and other UNIX vendors are eminant. Not only does it not sit well it will start a war. Is it worth it? I am loading my guns now ----).... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 08:25:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9GLUl11556 for ipng-dist; Tue, 9 Nov 1999 08:21:30 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9GLLi11549 for ; Tue, 9 Nov 1999 08:21:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA06383 for ; Tue, 9 Nov 1999 08:21:21 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09930 for ; Tue, 9 Nov 1999 09:21:20 -0700 (MST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 242581520C6; Tue, 9 Nov 1999 10:21:20 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 495BCBC4D2; Tue, 9 Nov 1999 10:20:58 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id C8CB6B2A43; Tue, 9 Nov 1999 10:20:57 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000007284; Tue, 9 Nov 1999 11:21:18 -0500 (EST) From: Jim Bound Message-Id: <199911091621.LAA0000007284@quarry.zk3.dec.com> To: Francis Dupont Cc: Brian Zill , "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Tue, 09 Nov 1999 16:13:15 +0100." <199911091513.QAA29461@givry.inria.fr> Date: Tue, 09 Nov 1999 11:21:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk francis, scoped addresses will be the exception not the norm. do you think oracle will use scoped addresses lets not change the api fore the non-norm. XNET should be doing this I am convinced reading this mail /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 08:25:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9GNGO11565 for ipng-dist; Tue, 9 Nov 1999 08:23:16 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9GN6i11558 for ; Tue, 9 Nov 1999 08:23:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA16936 for ; Tue, 9 Nov 1999 08:23:06 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10897 for ; Tue, 9 Nov 1999 09:23:06 -0700 (MST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id A9F529A9FB for ; Tue, 9 Nov 1999 10:23:05 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 653D84FB05; Tue, 9 Nov 1999 10:22:47 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 171D74C901 for ; Tue, 9 Nov 1999 10:22:47 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000005009; Tue, 9 Nov 1999 11:23:04 -0500 (EST) From: Jim Bound Message-Id: <199911091623.LAA0000005009@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: ietf ipng agenda Date: Tue, 09 Nov 1999 11:23:04 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk steve/bob, Could we put the scope address and src addr selection at the top of this list for our meeting. it is a highly need technical debate (which is unusual at IETF meetings this week) and more important than the political issues of privacy bigtime... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 10:22:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9IFrk11743 for ipng-dist; Tue, 9 Nov 1999 10:15:53 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9IFmi11736 for ; Tue, 9 Nov 1999 10:15:48 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA11386 for ipng@sunroof.eng.sun.com; Tue, 9 Nov 1999 10:15:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9Ecai11327 for ; Tue, 9 Nov 1999 06:38:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA11424 for ; Tue, 9 Nov 1999 06:38:36 -0800 (PST) From: khiem.le@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18890 for ; Tue, 9 Nov 1999 06:38:31 -0800 (PST) Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3) with ESMTP id QAA07497; Tue, 9 Nov 1999 16:36:42 +0200 (EET) Received: from esebh02nok.ntc.nokia.com (esebh02nok.ntc.nokia.com [131.228.118.151]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA28783; Tue, 9 Nov 1999 16:36:40 +0200 (EET) Received: by esebh02nok with Internet Mail Service (5.5.2650.10) id ; Tue, 9 Nov 1999 16:18:41 +0200 Message-ID: <8572CF1E2A95D211A1190008C7EAA2464F5BFD@daeis05nok> To: micke@cdt.luth.se, ipng@sunroof.eng.sun.com, rem-conf@es.net, pilc@grc.nasa.gov, iptel@lists.research.bell-labs.com Cc: micke@basil.cdt.luth.se Subject: RE: Robust Header Compression BOF agenda Date: Tue, 9 Nov 1999 16:18:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mikael, I think you forgot an item on the agenda. As we discussed and agreed, we are going to present a robust RTP header compression scheme. This is separate from the 3GPP requirements item. Also, due to my schedule constraints, as discussed last week, would it be possible to reshuffle the items on the agenda as follows (items 1 and 2 back-to-back will save some time, i.e. together they should take less than 30 min): AGENDA 0. Introduction Mikael Degermark 1. 3GPP requirements on robust header compression. Chris Clanton, Nokia draft-degermark-hc-requirements-00.txt 2. A robust and efficient RTP header compression scheme Khiem Le, Nokia 3. Why CRTP is not good enough Mikael Degermark draft-degermark-crtp-eval-00.{ps,txt} 4. 3GPP timeline Mats Nilsson 5. Cellular link properties affecting header compression - delays, error rates & error distributions for EDGE, WCDMA, GSM, etc. Krister Svanbro, Ericsson 6. RObust Checksum-based header COmpression - ROCCO Lars-Erik Jonsson, Ericsson draft-jonsson-robust-hc-02.{ps,txt} 7. Should we propose that a WG is formed? Outline of charter presented. Mikael Degermark Thanks Khiem -----Original Message----- From: EXT Mikael Degermark [mailto:micke@cdt.luth.se] Sent: Tuesday, November 09, 1999 7:48 AM To: ipng@sunroof.eng.sun.com; rem-conf@es.net; pilc@grc.nasa.gov; iptel@lists.research.bell-labs.com Cc: micke@basil.cdt.luth.se Subject: Robust Header Compression BOF agenda This is a revised agenda for the robust header compression BOF to be held today Tuesday. As this is the night of the social event, we will ignore the break and instead aim to finish 17.45 at the latest. ------------- Robust Header compression BOF (robhc) Tuesday, November 9 at 1545-1800 ========== CHAIRS: Mikael Degermark Stephen Pink DESCRIPTION: The cellular community is now standardizing the next generation cellular systems. These systems will use IP to deliver telephony to coming mobile phones, to allow end-to-end IP telephony. As cellular bandwith is expensive, radio spectrum efficiency is of outmost importance and thus the IP/UDP/RTP headers must be compressed over the air. 3GPP has specified the requirements for the needed header compression scheme and it has been shown that no current header compression scheme in the IETF can satisfy these requirements. CRTP [RFC-2508] is the closest candidate but is not sufficiently robust against errors on the link, i.e., CRTP cannot deliver acceptable performance at the anticipated error rates. It is likely that the number of users of cellular IP telephony will be larger than the current number of people using TCP/IP, therefore it is important that a suitable header compression scheme is developed. The BOF will outline the relevant properties of the cellular links, the requirements, and will explain why CRTP fails. One or more proposals for a suitable header compression scheme will be presented, and finally we will discuss if and how the IETF will work on standardizing a suitable header compression scheme. AGENDA 0. Introduction Mikael Degermark 1. 3GPP timeline Mats Nilsson 2. 3GPP requirements on robust header compression. Khiem Le, Nokia draft-degermark-hc-requirements-00.txt 3. Why CRTP is not good enough Mikael Degermark draft-degermark-crtp-eval-00.{ps,txt} 4. Cellular link properties affecting header compression - delays, error rates & error distributions for EDGE, WCDMA, GSM, etc. Krister Svanbro, Ericsson 5. RObust Checksum-based header COmpression - ROCCO Lars-Erik Jonsson, Ericsson draft-jonsson-robust-hc-02.{ps,txt} 6. Should we propose that a WG is formed? Outline of charter presented. Mikael Degermark -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 10:22:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9ILQ111755 for ipng-dist; Tue, 9 Nov 1999 10:21:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9ILFi11745 for ; Tue, 9 Nov 1999 10:21:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA28649 for ; Tue, 9 Nov 1999 10:21:15 -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 KAA16407 for ; Tue, 9 Nov 1999 10:21:08 -0800 (PST) Received: from new (dhcp21-fh37.fh.ietf.innovationslab.net [130.128.21.37]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id KAA08885; Tue, 9 Nov 1999 10:19:23 -0800 (PST) Message-Id: <4.2.2.19991109101720.03b890f0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 09 Nov 1999 10:18:12 -0800 To: Jim Bound From: Bob Hinden Subject: Re: ietf ipng agenda Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911091623.LAA0000005009@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, We had scheduled it for the second session where there will be more time to discuss it. Bob >Could we put the scope address and src addr selection at the top of this >list for our meeting. it is a highly need technical debate (which is >unusual at IETF meetings this week) and more important than the >political issues of privacy bigtime... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 10:28:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9IRFa11826 for ipng-dist; Tue, 9 Nov 1999 10:27:15 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9IR6i11819 for ; Tue, 9 Nov 1999 10:27:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA29849 for ; Tue, 9 Nov 1999 10:27:06 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26834 for ; Tue, 9 Nov 1999 11:27:05 -0700 (MST) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA19114; Tue, 9 Nov 1999 10:21:10 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA63808; Tue, 9 Nov 1999 10:25:02 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA63298; Tue, 9 Nov 1999 10:24:58 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911091824.KAA63298@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: bound@zk3.dec.com (Jim Bound) Date: Tue, 9 Nov 1999 10:24:58 -0800 (PST) Cc: Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com In-Reply-To: <199911091604.LAA0000028482@quarry.zk3.dec.com> from "Jim Bound" at Nov 9, 99 11:04:14 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Jim Bound wrote: > I strongly objecty to this and will object as far as need be. What exactly do you object to? changing the default behaviour of getipnodebyname() or changing the API period? I don't see any harm in updating the spec with additional functionality that does not influence existing apps either at the API or ABI level. (i.e. the new flag requesting sockaddr_in6_lite). I do of course see the harm in _breaking_ an API, but my proposal wasn't to break it. We (SGI) don't currently have this issue since we haven't shipped yet, so I don't really care much either way. However, if getipnodebyname() doesn't have _any_ possibility of supporting scope-ids I will never use it. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 9 10:35:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9IWpx11872 for ipng-dist; Tue, 9 Nov 1999 10:32:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9IWhi11865 for ; Tue, 9 Nov 1999 10:32:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA01071 for ; Tue, 9 Nov 1999 10:32:42 -0800 (PST) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00724 for ; Tue, 9 Nov 1999 11:32:39 -0700 (MST) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id KAA07993; Tue, 9 Nov 1999 10:31:55 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA90144; Tue, 9 Nov 1999 10:30:47 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id KAA74092; Tue, 9 Nov 1999 10:30:46 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911091830.KAA74092@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: bound@zk3.dec.com (Jim Bound) Date: Tue, 9 Nov 1999 10:30:45 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911091621.LAA0000007284@quarry.zk3.dec.com> from "Jim Bound" at Nov 9, 99 11:21:18 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > scoped addresses will be the exception not the norm. Agreed, but I want my apps to work the exceptions as well. I personally hope to see scoped addresses used as little as possible but I still want my apps to support them. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 9 13:15:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9L88i12095 for ipng-dist; Tue, 9 Nov 1999 13:08:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9L7oi12088 for ; Tue, 9 Nov 1999 13:07:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA29427 for ; Tue, 9 Nov 1999 13:07:47 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA27482 for ; Tue, 9 Nov 1999 14:07:46 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Nov 1999 12:28:15 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Nov 1999 12:28:11 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712EDC@RED-MSG-02> From: Brian Zill To: "'sm@bossette.engr.sgi.com'" , bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Date: Tue, 9 Nov 1999 12:28:06 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk After discussing this issue with Jim Bound in the hallway, he's convinced me (in his usual totally rational, non-emotional way :-) that some people will be very upset if we change the API in a non-backwards compatible way. While those of us who haven't yet carved our APIs in stone may not care, it would be a bad thing to "reward" the early deployers by changing the API out from under them. Therefore, I'm now leaning toward "option #2" from my previous mail, which is to use flags like Sam Manthorpe suggested or a parallel set of APIs that are scope aware. Since getipnodebyname already takes a flag field, making this backwards compatible is straightforward (flag would have to default to no scope_id). inet_ntop and inet_pton are more problematic. For them, I'm leaning toward defining an equivalent set that work on sockaddrs rather than in?_addrs. While getipnodebyaddr doesn't take a flag field, it might not be a problem (discussed below). Another option is to just recommend the use of getaddrinfo (and duck the bricks Jim will throw). Another thing I've noticed in this discussion is some confusion over the definition/use of scope_ids. While this has been discussed a lot at various meetings to what I perceived as a consensus, I don't think it has been written down anywhere. What I think the definition of a scope_id is: A scope_id is an *instance* of a scope (it's not a scope -- a scope is link-local, site-local, global, interplanetary, whatever). By an instance, I mean it is an identifier denoting a specific link (for link-local addresses), a specific site (for site-local addresses), a specific planet (for global addresses), etc. And it is node-specific -- that is, it can have different values denoting the same thing on different nodes (at least for link-local and site-local, we seem to be treating zero as the universal scope_id value for Earth when we're dealing with global addresses :-). Because of the node-specific property of scope_ids, I think the idea (floated from time to time) of putting scope_id information into the DNS, is very problematic and shouldn't be allowed/persued. Therefore, I don't think we need to care about getipnodebyaddr not being scope-aware. We do care for getipnodebyname since we'd like it to be able to parse numeric address strings with a scope_id in some format (which is what we started out discussing in this thread before taking off on this tangent). --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 13:57:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9LsJg12172 for ipng-dist; Tue, 9 Nov 1999 13:54:19 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9LsAi12165 for ; Tue, 9 Nov 1999 13:54:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA05169 for ; Tue, 9 Nov 1999 13:54:09 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23958 for ; Tue, 9 Nov 1999 14:54:09 -0700 (MST) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id NAA19312; Tue, 9 Nov 1999 13:48:15 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA15898; Tue, 9 Nov 1999 13:52:12 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA82960; Tue, 9 Nov 1999 13:52:01 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911092152.NAA82960@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: bzill@MICROSOFT.com (Brian Zill) Date: Tue, 9 Nov 1999 13:52:00 -0800 (PST) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <3D2036E25376D31197A100805FEAD892712EDC@RED-MSG-02> from "Brian Zill" at Nov 9, 99 12:28:06 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Zill wrote: > What I think the definition of a scope_id is: A scope_id is an *instance* of > a scope (it's not a scope -- a scope is link-local, site-local, global, > interplanetary, whatever). By an instance, I mean it is an identifier > denoting a specific link (for link-local addresses), a specific site (for > site-local addresses), a specific planet (for global addresses), etc. And > it is node-specific -- that is, it can have different values denoting the > same thing on different nodes (at least for link-local and site-local, we > seem to be treating zero as the universal scope_id value for Earth when > we're dealing with global addresses :-). Yes, this is also my understanding of scope-id, very nicely explained again. > Because of the node-specific property of scope_ids, I think the idea > (floated from time to time) of putting scope_id information into the DNS, is > very problematic and shouldn't be allowed/persued. I agree that scope_id information should not be _in_ the DNS, _but_ it should be added by the resolver. Before looking at DNS, what about based name resolution? I would suppose that for link-local addresses name resolution should proceed as follows: 1 send name lookup ICMP packets on each attached link 2 interface on which the reply is received determines the scope-id to be associated with the link-local address 3 libc name resolution function (e.g. getaddrinfo) returns this scope-id to application along with the link-local address. I would like getipnodebyname() to be able to do this too. As for DNS, I belive that the same technique can be applied; i.e. the scope-id to be associated with a link-local or site-local address is that of the interface through which the DNS server was reached. > we need to care about getipnodebyaddr not being scope-aware. We do care for > getipnodebyname since we'd like it to be able to parse numeric address > strings with a scope_id in some format (which is what we started out > discussing in this thread before taking off on this tangent). Yes, this too. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 9 14:06:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9M4Xa12211 for ipng-dist; Tue, 9 Nov 1999 14:04:33 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9M4Oi12204 for ; Tue, 9 Nov 1999 14:04:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA07292 for ; Tue, 9 Nov 1999 14:04:23 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20260 for ; Tue, 9 Nov 1999 14:04:22 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 3E11D579E8; Tue, 9 Nov 1999 16:04:22 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 84FA84FB04; Tue, 9 Nov 1999 16:04:03 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 2F8784C901; Tue, 9 Nov 1999 16:04:03 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000030258; Tue, 9 Nov 1999 17:04:21 -0500 (EST) From: Jim Bound Message-Id: <199911092204.RAA0000030258@quarry.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: ietf ipng agenda In-reply-to: Your message of "Tue, 09 Nov 1999 10:18:12 PST." <4.2.2.19991109101720.03b890f0@mailhost.iprg.nokia.com> Date: Tue, 09 Nov 1999 17:04:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk if you put it up front we will have the time. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 14:14:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9MCIw12279 for ipng-dist; Tue, 9 Nov 1999 14:12:18 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9MC9i12272 for ; Tue, 9 Nov 1999 14:12:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA08818 for ; Tue, 9 Nov 1999 14:12:07 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24441 for ; Tue, 9 Nov 1999 14:12:07 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 2CFAD57A73; Tue, 9 Nov 1999 16:12:07 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 5EB1ABC4D2; Tue, 9 Nov 1999 16:11:45 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id DE301B2A42; Tue, 9 Nov 1999 16:11:44 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000031687; Tue, 9 Nov 1999 17:12:05 -0500 (EST) From: Jim Bound Message-Id: <199911092212.RAA0000031687@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: bound@zk3.dec.com (Jim Bound), Francis.Dupont@inria.fr, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Tue, 09 Nov 1999 10:24:58 PST." <199911091824.KAA63298@bossette.engr.sgi.com> Date: Tue, 09 Nov 1999 17:12:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sam, I object to changing the API at all. It sends the wrong message to the market and ISVs. But I will discuss an adjunct to the Base API that does not break the API. In fact will provide the update. But what I don't want is for RFC 2553 to become obsolete. But first I think we need a write up on scope-ids so we are all understanding the same problem and not talking past each other. I think that is in process now. I would like to see us all agree to the problem we are trying to solve. I would also like to see a list of applications that exist today that need to be scope aware? I would like to see a list of applications in the future that could use scoping? What I don't want is to say getipnodebyname won't work until we have discussed the possibilities. I don't think DNS RRs should carry scope-ids either. I am open to "engineering analysis in this working group" what I am not open to is vague principals changing our Base API for IPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 14:37:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9MXqD12334 for ipng-dist; Tue, 9 Nov 1999 14:33:52 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9MXfi12327 for ; Tue, 9 Nov 1999 14:33:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA05943 for ; Tue, 9 Nov 1999 14:33:40 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16375 for ; Tue, 9 Nov 1999 15:33:38 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA04119; Tue, 9 Nov 1999 14:33:26 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA09281; Tue, 9 Nov 1999 14:33:26 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id OAA28141; Tue, 9 Nov 1999 14:34:26 -0800 (PST) Date: Tue, 9 Nov 1999 14:34:26 -0800 (PST) From: Tim Hartrick Message-Id: <199911092234.OAA28141@feller.mentat.com> To: bzill@microsoft.com, sm@bossette.engr.sgi.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sam, Brian, > > Brian Zill wrote: > > What I think the definition of a scope_id is: A scope_id is an *instance* of > > a scope (it's not a scope -- a scope is link-local, site-local, global, > > interplanetary, whatever). By an instance, I mean it is an identifier > > denoting a specific link (for link-local addresses), a specific site (for > > site-local addresses), a specific planet (for global addresses), etc. And > > it is node-specific -- that is, it can have different values denoting the > > same thing on different nodes (at least for link-local and site-local, we > > seem to be treating zero as the universal scope_id value for Earth when > > we're dealing with global addresses :-). > > Yes, this is also my understanding of scope-id, very nicely explained > again. > Indeed. A nice encapsulation of the intent. I wish I had written it myself when I first proposed the idea of adding the scope identifier to the sockaddr- in6. If the rhetoric had not been so thick in that initial discussion we may well have not missed the details that we are causing us some pain. > > Because of the node-specific property of scope_ids, I think the idea > > (floated from time to time) of putting scope_id information into the DNS, is > > very problematic and shouldn't be allowed/persued. > > I agree that scope_id information should not be _in_ the DNS, _but_ it > should be added by the resolver. Before looking at DNS, what about > based name resolution? > I would suppose that for link-local addresses name resolution should > proceed as follows: > > 1 send name lookup ICMP packets on each attached link > > 2 interface on which the reply is received determines the > scope-id to be associated with the link-local address > > 3 libc name resolution function (e.g. getaddrinfo) returns > this scope-id to application along with the link-local > address. > > I would like getipnodebyname() to be able to do this too. As for > DNS, I belive that the same technique can be applied; i.e. the > scope-id to be associated with a link-local or site-local address > is that of the interface through which the DNS server was reached. > I agree with Sam. It is difficult to conceive of a circumstance that would lead to link-local addresses appearing in the DNS. It is not difficult to conceive of a time when a "two faced DNS" scheme would be in place for some organization that was the merge of two organizations that both used site-local addresses. In this case, site-local addresses would appear in the DNS but it would be up to the resolver, by some as yet undefined means, to apply appropriate scope qualification to addresses returned from the DNS server. In addition, as much as we may scream and cry about it, the /etc/hosts file or equivalent is not going away as a "database" of address to name mappings. We need to think in terms beyond just what the DNS will store if we want to do this in a way that satisfies the operational requirements of the environ- ment in which IPv6 aware applications will be running. That includes database systems other than DNS. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 14:41:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9Mden12356 for ipng-dist; Tue, 9 Nov 1999 14:39:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9MdTi12349 for ; Tue, 9 Nov 1999 14:39:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA22672 for ; Tue, 9 Nov 1999 14:39:30 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20314 for ; Tue, 9 Nov 1999 15:39:29 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA04187; Tue, 9 Nov 1999 14:39:28 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA09386; Tue, 9 Nov 1999 14:39:29 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id OAA28144; Tue, 9 Nov 1999 14:40:29 -0800 (PST) Date: Tue, 9 Nov 1999 14:40:29 -0800 (PST) From: Tim Hartrick Message-Id: <199911092240.OAA28144@feller.mentat.com> To: bzill@microsoft.com, sm@bossette.engr.sgi.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Sam, > > Indeed. A nice encapsulation of the intent. I wish I had written it myself > when I first proposed the idea of adding the scope identifier to the sockaddr- > in6. If the rhetoric had not been so thick in that initial discussion we > may well have not missed the details that we are causing us some pain. > Arghh.. Mangled sentence. I meant "details that are now causing us some pain." Proofing before sending is the correct order. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 14:43:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9MfuC12378 for ipng-dist; Tue, 9 Nov 1999 14:41:56 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9Mfji12371 for ; Tue, 9 Nov 1999 14:41:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA07837 for ; Tue, 9 Nov 1999 14:41:44 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21541 for ; Tue, 9 Nov 1999 15:41:45 -0700 (MST) Received: from [130.128.20.100] (ssh.cisco.com [171.69.10.34]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA12961; Tue, 9 Nov 1999 14:41:39 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: <3D2036E25376D31197A100805FEAD892712EDC@RED-MSG-02> References: <3D2036E25376D31197A100805FEAD892712EDC@RED-MSG-02> Date: Tue, 9 Nov 1999 14:42:23 -0800 To: Brian Zill From: Steve Deering Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:28 PM -0800 11/9/99, Brian Zill wrote: >What I think the definition of a scope_id is: A scope_id is an *instance* of >a scope (it's not a scope -- a scope is link-local, site-local, global, >interplanetary, whatever). At the Tokyo interim WG meeting, I suggested the use of the term "zone" for a scope instance, based on the precedent set by IPv6 scoped multicast addressing (e.g., the in the MZAP protocol). If that suggestion were adopted, the "scope_id" would be more accurately named "zone_id". Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 14:56:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9Mqsi12413 for ipng-dist; Tue, 9 Nov 1999 14:52:54 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9Mqji12406 for ; Tue, 9 Nov 1999 14:52:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA10251 for ; Tue, 9 Nov 1999 14:52:45 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17314 for ; Tue, 9 Nov 1999 14:52:45 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id 902EF9A85F; Tue, 9 Nov 1999 16:52:44 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 0FCA84FB04; Tue, 9 Nov 1999 16:52:26 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 8EBE84C902; Tue, 9 Nov 1999 16:52:25 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000006620; Tue, 9 Nov 1999 17:52:43 -0500 (EST) From: Jim Bound Message-Id: <199911092252.RAA0000006620@quarry.zk3.dec.com> To: Tim Hartrick Cc: bzill@microsoft.com, sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Tue, 09 Nov 1999 14:34:26 PST." <199911092234.OAA28141@feller.mentat.com> Date: Tue, 09 Nov 1999 17:52:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk tim, brian, sam, this is a good discussion.. I too like brian's description and its short and to the point. one item we need to decide is when does the scope-id need to be set? before dns access? if DNS don't know about them then why? after dns access? Seems yes? but why can't this happen after getipnodename gets back to the app? My impression is that scope-id can apply to any scope address..so a link-local, site, and global could all be valid for a particular scope-id? Then src addr selects which address is appropriate. so this tells me that the scope-id has to be set before getipnodebyname returns? SAM: I would like to avoid icmp traffic being necessary to do this in my resolver...seems like a definite performance hit>?????? ?????? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 15:01:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9MxRn12439 for ipng-dist; Tue, 9 Nov 1999 14:59:27 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9MxIi12432 for ; Tue, 9 Nov 1999 14:59:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA18079 for ; Tue, 9 Nov 1999 14:59:18 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20954 for ; Tue, 9 Nov 1999 14:59:18 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 0379D57941; Tue, 9 Nov 1999 16:59:18 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 8EBE84FB04; Tue, 9 Nov 1999 16:58:59 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id DCDE84C904; Tue, 9 Nov 1999 16:58:58 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000007688; Tue, 9 Nov 1999 17:59:16 -0500 (EST) From: Jim Bound Message-Id: <199911092259.RAA0000007688@quarry.zk3.dec.com> To: Steve Deering Cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Tue, 09 Nov 1999 14:42:23 PST." Date: Tue, 09 Nov 1999 17:59:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think zone has to much ringing of DNS syntax and will cause confusion too. perimeter_id seems more appropriate... but is it worth changing the rfc 2553 name space? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 15:37:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9NFb712498 for ipng-dist; Tue, 9 Nov 1999 15:15:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9NFQi12487 for ; Tue, 9 Nov 1999 15:15:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA03634 for ; Tue, 9 Nov 1999 15:15:26 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29016 for ; Tue, 9 Nov 1999 15:15:26 -0800 (PST) Received: from [130.128.20.100] (ssh.cisco.com [171.69.10.34]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA18445; Tue, 9 Nov 1999 15:08:40 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: <199911092259.RAA0000007688@quarry.zk3.dec.com> References: <199911092259.RAA0000007688@quarry.zk3.dec.com> Date: Tue, 9 Nov 1999 15:09:19 -0800 To: Jim Bound From: Steve Deering Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Cc: Brian Zill , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:59 PM -0500 11/9/99, Jim Bound wrote: >I think zone has to much ringing of DNS syntax and will cause confusion >too. That's a good point. >perimeter_id seems more appropriate... Perhaps, though it's an identifier for the area inside the perimeter, not the perimeter itself. >but is it worth changing the rfc 2553 name space? Maybe. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 9 15:44:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dA9Nh9W12559 for ipng-dist; Tue, 9 Nov 1999 15:43:09 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dA9Nh0i12552 for ; Tue, 9 Nov 1999 15:43:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA26677 for ; Tue, 9 Nov 1999 15:43:01 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13073 for ; Tue, 9 Nov 1999 15:43:00 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA246597; Tue, 9 Nov 1999 15:39:53 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA92040; Tue, 9 Nov 1999 15:39:50 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA83776; Tue, 9 Nov 1999 15:39:48 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911092339.PAA83776@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: bound@zk3.dec.com (Jim Bound) Date: Tue, 9 Nov 1999 15:39:47 -0800 (PST) Cc: tim@mentat.com, bzill@microsoft.com, ipng@sunroof.eng.sun.com In-Reply-To: <199911092252.RAA0000006620@quarry.zk3.dec.com> from "Jim Bound" at Nov 9, 99 05:52:43 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Brian, Tim, Jim Bound wrote: > one item we need to decide is when does the scope-id need to be set? > > before dns access? if DNS don't know about them then why? I would say no, not before, _unless_ the app explicitly asks for that using something like s1: passed into the resolution function. > after dns access? Seems yes? Yes, I would say so. In the absence of any knowledge of what site or link the address may be found on, it may be advantageous to do simultaneous DNS quieres on each site/link (I really hate all the ugliness scoped addresses introduce). We determine the scope-id to add to the IPv6 address by the interface on which the first reply arrives. > but why can't this happen after getipnodename gets back to the app? Because then the app must know something about how the name resolution was performed in order to determine which scope-id to use. This kind of stuff should be hidden in libc and kernel IMHO. > SAM: I would like to avoid icmp traffic being necessary to do this in > my resolver...seems like a definite performance hit>?????? Absolutely, I wasn't talking about ICMP being necessary, I was just giving an example of how I imagine the mechanism working with ICMP name resolution. In IRIX, for example, the name resolution mechanisms are `hot-pluggable' specified in /etc/nsswitch.conf Incidentally, I have implemented an alternative mechanism to ICMP name lookups for link-locals using UDP instead of ICMP. It's called PNRP (Plug-n-play Name Resolution Protocol) and keeps local tables of peers, populated through address advertisements, rather than sending ICMP messages upon demand. In the Oslo meeting Alain convinced me that the ICMP mechanism was a better scheme, but I'm no longer convinced of this, particularly in light of the scope-id complications. If there is interest, I would be happy to write up the scheme. -- Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 9 16:32:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAA0RfI12623 for ipng-dist; Tue, 9 Nov 1999 16:27:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAA0RUi12616 for ; Tue, 9 Nov 1999 16:27:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA19212 for ; Tue, 9 Nov 1999 16:27:30 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA16281 for ; Tue, 9 Nov 1999 17:27:29 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 09 Nov 1999 15:59:20 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Nov 1999 15:59:20 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712EDE@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" , Tim Hartrick Cc: sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Date: Tue, 9 Nov 1999 15:59:12 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > At the Tokyo interim WG meeting, I suggested > the use of the term "zone" for a scope instance I too prefer the term "zone" to "scope_id". I think it would have eliminated the confusion between scopes and scope_ids if only we'd thought of it earlier. However, I agree with Jim that changing the name of the field in the sockaddr_in6 at this point isn't worth the pain. We can still call them zones I suppose. Sam, Tim, Good points about wanting to resolve scoped names without putting them in the DNS directly. I'll have to think about this some more, if we're going to support this it'd be nice to find a solution for getipnodebyaddr that's as reasonable as adding a new flag value is for getipnodebyname. Jim, > this is a good discussion.. Agreed. I think we're getting somewhere. > one item we need to decide is when does the scope-id need to be set? Well, it only *needs* to be set before making socket calls like connect, bind, etc which take sockaddrs. I would expect that any name resolution (or numeric text string to binary address conversion) functions that output sockaddrs would fill it in along with the rest of the address. > before dns access? if DNS don't know about them then why? As Tim and Sam have mentioned, your local resolver may know about them, even if the DNS doesn't. This, along with the numeric string to binary stuff, is the motivation behind wanting the library routines to return a sockaddr_in? instead of an in?_addr. Francis (I think it was) also put on the table the option of returning a new structure that contains only the in6_addr and the scope_id, thus avoiding the overhead of the extra bytes in sockaddr_in6. Is this a big enough memory/performance issue to care? I dunno. > after dns access? Seems yes? Er, I'd say seems no. Otherwise you have each app trying to do zone (scope_id) determination on it's own. Better to have is consistently handled in the resolver library, I would think. > My impression is that scope-id can apply to any scope address..so a > link-local, site, and global could all be valid for a particular > scope-id? Then src addr selects which address is appropriate. Maybe some of the confusion here is that for a single-homed node, there is only one possible value for the scope_id in each scope, so if you didn't keep the scope_id with the rest of the address, you could always figure it out later. But every multi-homed node will have multiple valid scope_ids for link-local scoped addresses (one per interface), and possibly multiple valid scope_ids for site-local addresses (if the node is multi-sited). Thus, a scoped address is ambiguous without an accompanying scope_id. They are one-for-one. Another way to think of it is that a scoped address isn't really an address without a scope_id. One could even apply the term "address" to the combination of the 128 bit part and the scope_id part (but that would get confusing, so let's not :-) Anyhow, this means (to me, at any rate) that one should try to keep an address with its scope_id. Whenever you get a scoped address from a user, or from some name resolution method, you should get a scope_id with it (or apply some default). BTW, as currently "defined", the namespace of scope_id values is a separate one for each scope (this should be implementer's choice actually, the point is that the "definition" as I understand it doesn't require scope_ids to be unique across all scopes). In other words, I can have a link-local address on one interface with a scope_id of 1 and a site-local address on a different interface with a scope_id of 1. In the first case, the scope_id is the interface index, in the second case, it's the site identifier. > SAM: I would like to avoid icmp traffic being necessary to do this in > my resolver...seems like a definite performance hit>?????? I think he was talking about (Matt Crawford's?) draft on ICMP-based name resolution? Do people think I should write up something on this before the Thursday meeting? Chairs, are there extra minutes anywhere to discuss this separate from the textual format issue? --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 10 09:57:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAHrY813292 for ipng-dist; Wed, 10 Nov 1999 09:53:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAHrHi13271 for ; Wed, 10 Nov 1999 09:53:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA09114 for ; Wed, 10 Nov 1999 01:59:16 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA07723 for ; Wed, 10 Nov 1999 01:59:13 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA28547; Wed, 10 Nov 1999 20:59:10 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: Your message of "Tue, 09 Nov 1999 15:59:12 -0800." <3D2036E25376D31197A100805FEAD892712EDE@RED-MSG-02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Nov 1999 20:59:09 +1100 Message-Id: <4128.942227949@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 9 Nov 1999 15:59:12 -0800 From: Brian Zill Message-ID: <3D2036E25376D31197A100805FEAD892712EDE@RED-MSG-02> | Thus, a scoped address is ambiguous without an accompanying scope_id. Some of you may remember that a totally different way of handling this was proposed before ... that is, noticing that there is only one global scope (zone, inside of perimiter, whatever it is to be called), which therefore needs no identification, there are a much larger number of sites - but only a subset of those need identification from any particular node (identifying a site address that you can't reach is kind of nice, but practically useless), and zillions more links, but again, only those actually connected to a node need identifying (but that number will be no less than the number of scopes). Then look at the IPv6 addressing formats for global, site local, and link local, and notice that there are no (real) spare bits in global addresses, quite a few in site locals, and lots in link locals, and wonder if perhaps the scope_id (zone identifier, whatever) might just fit fairly nicely in the 128 available bits that we have already, and that all applications are already passing around - and that doing so (with whatever support is needed in the kernel or libraries to fill in the bits, and remove them again when appropriate) just might be a way to make the vast majority of applications just magically work, without any specific knowledge that there are such things as less than global addresses. Sure, some applications are going to need to understand, and deal with the issues that arise - they'll need to do that however the extra id is passed around, only the details vary. And yes, there are some issues that need to be worked out with this scheme, there are some things that need to be dealt with (those things which really care what is in the packets on the wire need to know what bits will be left there, and which will be zapped for example), but I suspect those are manageable. I will also say that I was most pleased when I saw that the KAME IPv6 stack uses this general method for identifying its link local interface addresses - and that all seems to work just fine (it needs some better documentation, as it surprises some people when they first encounter it, but aside from that, it all just works. I'm sure there is some code in there somewhere making it all just work of course). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 10 09:58:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAHuQH13321 for ipng-dist; Wed, 10 Nov 1999 09:56:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAHuCi13311 for ; Wed, 10 Nov 1999 09:56:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12971 for ; Wed, 10 Nov 1999 08:53:10 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17870 for ; Wed, 10 Nov 1999 08:52:56 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA17126; Wed, 10 Nov 1999 17:52:48 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id RAA14981; Wed, 10 Nov 1999 17:52:45 +0100 (MET) Message-Id: <199911101652.RAA14981@givry.inria.fr> From: Francis Dupont To: Brian Zill cc: "'Jim Bound'" , Tim Hartrick , sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Tue, 09 Nov 1999 15:59:12 PST. <3D2036E25376D31197A100805FEAD892712EDE@RED-MSG-02> Date: Wed, 10 Nov 1999 17:52:36 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (This is not an answer to Brian's mail) I believe we know what is the problem, the whole set of solutions but we still need a way to not break the API (and keep Jim happy :-). Then my proposal is to introduce a compilation flag, undefined by default, which should be defined before netdb.h and arpa/inet.h includes. If the flag is not defined current state aplies. If the flag is defined then getipnodebyname(), inet_pton(), ... deal with scope IDs too. Is it a reasonable and not too uggly compromise? Thanks Francis.Dupont@inria.fr PS: in order to not get extensions for flow ID, DS field, ports, ... I believe we should keep my light structure proposal. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 10 10:01:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAHxNX13381 for ipng-dist; Wed, 10 Nov 1999 09:59:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAHxBi13374 for ; Wed, 10 Nov 1999 09:59:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA24143 for ; Wed, 10 Nov 1999 03:23:04 -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 DAA26495 for ; Wed, 10 Nov 1999 03:23:02 -0800 (PST) Received: by odin.digi-data.com id <15379>; Wed, 10 Nov 1999 07:18:32 -0400 Message-Id: <99Nov10.071832ast.15379@odin.digi-data.com> Date: Wed, 10 Nov 1999 07:25: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: Steve Deering CC: Jim Bound , Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt References: <199911092259.RAA0000007688@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Steve and Jim, Perhaps the word "Region" is the one you seek? Yours sincerely, Robert Honore. Steve Deering wrote: > > At 5:59 PM -0500 11/9/99, Jim Bound wrote: > >I think zone has to much ringing of DNS syntax and will cause confusion > >too. > > That's a good point. > > >perimeter_id seems more appropriate... > > Perhaps, though it's an identifier for the area inside the perimeter, > not the perimeter itself. > > >but is it worth changing the rfc 2553 name space? > > Maybe. > > Steve > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 10 10:12:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAI8CT13475 for ipng-dist; Wed, 10 Nov 1999 10:08:12 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAI81i13468 for ; Wed, 10 Nov 1999 10:08:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA03747 for ; Wed, 10 Nov 1999 10:08:00 -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 KAA04749 for ; Wed, 10 Nov 1999 10:07:54 -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 DAA16338; Thu, 11 Nov 1999 03:07:33 +0900 (JST) To: Robert Elz cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Wed, 10 Nov 1999 20:59:09 +1100. <4128.942227949@munnari.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt From: itojun@iijlab.net Date: Thu, 11 Nov 1999 03:07:33 +0900 Message-ID: <16336.942257253@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (snip) >I will also say that I was most pleased when I saw that the KAME IPv6 >stack uses this general method for identifying its link local interface >addresses - and that all seems to work just fine (it needs some better >documentation, as it surprises some people when they first encounter it, >but aside from that, it all just works. I'm sure there is some code in >there somewhere making it all just work of course). To clarify: KAME puts interface id into 4th byte of IPv6 address for link-local addresses and link-local multicast addresess, but this is FOR KERNEL INTERNALSTRUCTURES ONLY (like interface address structure, routing tables. As documented, this is only for in-kernel usage. From userland we recommend users to use advanced api. "ping6 fe80:9::1" (telnet to fe80::1 on interface 9) accidentaly works, but is not recommended. The way to go is, IMHO: 1. ping6 -I interface9 fe80::1 2. ping6 fe80::1@interface9 (based on scopedaddr-format-00) yes, ping6 uses getaddrinfo(). This is kind of ugly but is necessary to avoid too many changes in BSD style function signature for ip6_output()... (where src and dst addr are passed in IPv6 header, no other place) 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 Nov 10 11:32:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAJTBo13627 for ipng-dist; Wed, 10 Nov 1999 11:29:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAJSxi13620 for ; Wed, 10 Nov 1999 11:28:59 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA20749 for ; Wed, 10 Nov 1999 11:28:57 -0800 (PST) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA23716 for ; Wed, 10 Nov 1999 11:28:57 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Wed Nov 10 14:18:11 EST 1999 Received: from smb.research.att.com ([135.207.25.14]) by research; Wed Nov 10 14:25:07 EST 1999 Received: by smb.research.att.com (Postfix, from userid 54047) id 285E3ACADC; Wed, 10 Nov 1999 14:24:57 -0500 (EST) Received: from smb.research.att.com (localhost [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id D041BABC3E; Wed, 10 Nov 1999 14:24:52 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Francis Dupont Cc: Brian Zill , "'Jim Bound'" , Tim Hartrick , sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Nov 1999 14:24:51 -0500 Message-Id: <19991110192457.285E3ACADC@smb.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199911101652.RAA14981@givry.inria.fr>, Francis Dupont writes: >(This is not an answer to Brian's mail) > >I believe we know what is the problem, the whole set of solutions >but we still need a way to not break the API (and keep Jim happy :-). > >Then my proposal is to introduce a compilation flag, undefined by default, >which should be defined before netdb.h and arpa/inet.h includes. >If the flag is not defined current state aplies. >If the flag is defined then getipnodebyname(), inet_pton(), ... >deal with scope IDs too. > Personally, I find it very ugly and hard to maintain, especially across multiple platforms where the mechanism for setting that flag may be different. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 10 12:59:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAKt6W13714 for ipng-dist; Wed, 10 Nov 1999 12:55:06 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAKsvi13707 for ; Wed, 10 Nov 1999 12:54:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA02957 for ; Wed, 10 Nov 1999 12:54:56 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09779 for ; Wed, 10 Nov 1999 12:54:54 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA20578; Wed, 10 Nov 1999 21:54:52 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA18014; Wed, 10 Nov 1999 21:54:50 +0100 (MET) Message-Id: <199911102054.VAA18014@givry.inria.fr> From: Francis Dupont To: "Steven M. Bellovin" cc: Brian Zill , "'Jim Bound'" , Tim Hartrick , sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Wed, 10 Nov 1999 14:24:51 EST. <19991110192457.285E3ACADC@smb.research.att.com> Date: Wed, 10 Nov 1999 21:54:48 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Personally, I find it very ugly => I agree, this is ugly but some of them *don't* want to update the API. and hard to maintain, especially across multiple platforms where the mechanism for setting that flag may be different. => I don't understand your concern. I propose to optionally add #define before some #include. Of course the name of the flag will be the same everywhere (if nobody finds something better :-). Perhaps you'd prefer (??) to add a -Dxxx in CFLAGS in Makefiles? Regards Francis.Dupont@inria.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 Nov 10 13:04:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAL2Su13740 for ipng-dist; Wed, 10 Nov 1999 13:02:28 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAL2Ii13729 for ; Wed, 10 Nov 1999 13:02:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA04508 for ; Wed, 10 Nov 1999 13:02:17 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13926 for ; Wed, 10 Nov 1999 13:02:16 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA20696; Wed, 10 Nov 1999 22:02:15 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA09901; Wed, 10 Nov 1999 22:02:13 +0100 (MET) Message-Id: <199911102102.WAA09901@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: sm@bossette.engr.sgi.com (Sam Manthorpe), ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Tue, 09 Nov 1999 17:12:05 EST. <199911092212.RAA0000031687@quarry.zk3.dec.com> Date: Wed, 10 Nov 1999 22:02:13 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I would also like to see a list of applications that exist today that need to be scope aware? => all the management applications (ping, traceroute, SNMP tools, ...) and some last chance applications like telnet. I would like to see a list of applications in the future that could use scoping? => any applications which should not be used only at a global scope (like whois for instance). What I don't want is to say getipnodebyname won't work until we have discussed the possibilities. => I think you don't want to convert near all the applications to getnameinfo only because of this problem... I don't think DNS RRs should carry scope-ids either. => DNS should never have a location function IMHO. I am open to "engineering analysis in this working group" what I am not open to is vague principals changing our Base API for IPv6. => we agree about what is the problem and a set of reasonable solution. Now we have to pick one and to find the best way to apply it. Francis.Dupont@inria.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 Nov 10 13:20:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAALFOl13808 for ipng-dist; Wed, 10 Nov 1999 13:15:24 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAALFBi13789 for ; Wed, 10 Nov 1999 13:15:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA09627 for ; Wed, 10 Nov 1999 13:15:00 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20809 for ; Wed, 10 Nov 1999 13:14:54 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id NAA872856; Wed, 10 Nov 1999 13:14:41 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id NAA15425; Wed, 10 Nov 1999 13:14:38 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id NAA85127; Wed, 10 Nov 1999 13:14:38 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911102114.NAA85127@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 10 Nov 1999 13:14:37 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4128.942227949@munnari.OZ.AU> from "Robert Elz" at Nov 10, 99 08:59:09 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Then look at the IPv6 addressing formats for global, site local, and link > local, and notice that there are no (real) spare bits in global addresses, > quite a few in site locals, and lots in link locals, and wonder if perhaps > the scope_id (zone identifier, whatever) might just fit fairly nicely in the > 128 available bits that we have already, and that all applications are already > passing around - and that doing so (with whatever support is needed in the > kernel or libraries to fill in the bits, and remove them again when > appropriate) just might be a way to make the vast majority of applications > just magically work, without any specific knowledge that there are such things > as less than global addresses. This is kind of attractive. I think the big disadvantage of this approach is the risk of the embedded scope-id being passed across the net or across humans to other hosts. This is still a problem with but much less so since the scope-id part is easily recognisable by humans and easily parsable. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 10 13:44:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAALehd13844 for ipng-dist; Wed, 10 Nov 1999 13:40:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAALeYi13837 for ; Wed, 10 Nov 1999 13:40:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA10679 for ; Wed, 10 Nov 1999 13:40:32 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04531 for ; Wed, 10 Nov 1999 13:40:32 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id A22D457975; Wed, 10 Nov 1999 15:40:31 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 84FA84FB0E; Wed, 10 Nov 1999 15:40:11 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id F06674C901; Wed, 10 Nov 1999 15:40:10 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000020138; Wed, 10 Nov 1999 16:40:29 -0500 (EST) From: Jim Bound Message-Id: <199911102140.QAA0000020138@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: bound@zk3.dec.com (Jim Bound), tim@mentat.com, bzill@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Tue, 09 Nov 1999 15:39:47 PST." <199911092339.PAA83776@bossette.engr.sgi.com> Date: Wed, 10 Nov 1999 16:40:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sam, >> but why can't this happen after getipnodename gets back to the app? >Because then the app must know something about how the name >resolution was performed in order to determine which scope-id to >use. This kind of stuff should be hidden in libc and kernel IMHO. I thought of this after I sent the mail. Yes it should be hidden. >> SAM: I would like to avoid icmp traffic being necessary to do this in >> my resolver...seems like a definite performance hit>?????? > >Absolutely, I wasn't talking about ICMP being necessary, I was just >giving an example of how I imagine the mechanism working with ICMP >name resolution. In IRIX, for example, the name resolution mechanisms >are `hot-pluggable' specified in /etc/nsswitch.conf Oh OK. >Incidentally, I have implemented an alternative mechanism to ICMP >name lookups for link-locals using UDP instead of ICMP. It's called >PNRP (Plug-n-play Name Resolution Protocol) and keeps local tables >of peers, populated through address advertisements, rather than >sending ICMP messages upon demand. In the Oslo meeting Alain convinced >me that the ICMP mechanism was a better scheme, but I'm no longer >convinced of this, particularly in light of the scope-id complications. >If there is interest, I would be happy to write up the scheme. Well at IPng I heard today that we may move icmp lookups to standards track. If you have an alternative we need to hear more about this now on the list. /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 Wed Nov 10 14:13:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAMCBf13904 for ipng-dist; Wed, 10 Nov 1999 14:12:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAMC2i13897 for ; Wed, 10 Nov 1999 14:12:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA17213 for ; Wed, 10 Nov 1999 14:12:00 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22358 for ; Wed, 10 Nov 1999 14:11:59 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 9A2E71520F5; Wed, 10 Nov 1999 16:11:58 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id A99984FB0E; Wed, 10 Nov 1999 16:11:38 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 409E84C902; Wed, 10 Nov 1999 16:11:38 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000028510; Wed, 10 Nov 1999 17:11:57 -0500 (EST) From: Jim Bound Message-Id: <199911102211.RAA0000028510@quarry.zk3.dec.com> To: Francis Dupont Cc: Jim Bound , sm@bossette.engr.sgi.com (Sam Manthorpe), ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Wed, 10 Nov 1999 22:02:13 +0100." <199911102102.WAA09901@givry.inria.fr> Date: Wed, 10 Nov 1999 17:11:57 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk francis et al... I agree......... /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 Wed Nov 10 14:13:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAMAN913895 for ipng-dist; Wed, 10 Nov 1999 14:10:23 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAMAEi13888 for ; Wed, 10 Nov 1999 14:10:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA20997 for ; Wed, 10 Nov 1999 14:10:12 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21296 for ; Wed, 10 Nov 1999 14:10:12 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id D01279A815; Wed, 10 Nov 1999 16:10:08 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id D31A84FB0E; Wed, 10 Nov 1999 16:09:48 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 2F8784C903; Wed, 10 Nov 1999 16:09:48 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000028692; Wed, 10 Nov 1999 17:10:03 -0500 (EST) From: Jim Bound Message-Id: <199911102210.RAA0000028692@quarry.zk3.dec.com> To: "Steven M. Bellovin" Cc: Francis Dupont , Brian Zill , "'Jim Bound'" , Tim Hartrick , sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of "Wed, 10 Nov 1999 14:24:51 EST." <19991110192457.285E3ACADC@smb.research.att.com> Date: Wed, 10 Nov 1999 17:10:03 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk should we at least have a discussion of changing hostent structure so its backwards compatible? The reason I ask is that I would love to get a TTL for each address too as a side benefit????? /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 Wed Nov 10 14:24:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAAML9h13949 for ipng-dist; Wed, 10 Nov 1999 14:21:09 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAAMKvi13942 for ; Wed, 10 Nov 1999 14:20:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA19440 for ; Wed, 10 Nov 1999 14:20:58 -0800 (PST) Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA27636 for ; Wed, 10 Nov 1999 14:20:57 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Wed Nov 10 17:10:11 EST 1999 Received: from smb.research.att.com ([135.207.25.14]) by research; Wed Nov 10 17:17:44 EST 1999 Received: by smb.research.att.com (Postfix, from userid 54047) id 2D9BBACAE2; Wed, 10 Nov 1999 17:15:22 -0500 (EST) Received: from smb.research.att.com (localhost [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 2980DABC3E; Wed, 10 Nov 1999 17:15:17 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: "Steven M. Bellovin" To: Francis Dupont Cc: Brian Zill , "'Jim Bound'" , Tim Hartrick , sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Nov 1999 17:09:38 -0500 Message-Id: <19991110221522.2D9BBACAE2@smb.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199911102054.VAA18014@givry.inria.fr>, Francis Dupont writes: > In your previous mail you wrote: > > Personally, I find it very ugly > >=> I agree, this is ugly but some of them *don't* want to update the API. > > and hard to maintain, especially across multiple platforms where > the mechanism for setting that flag may be different. > >=> I don't understand your concern. I propose to optionally add >#define before some #include. Of course the name of the flag >will be the same everywhere (if nobody finds something better :-). >Perhaps you'd prefer (??) to add a -Dxxx in CFLAGS in Makefiles? That latter was what I thought you were implying. I'm still not fond of #ifdefs for things like that, but it's better than my misinterpretation of your idea. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 10 15:56:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAANpEA14010 for ipng-dist; Wed, 10 Nov 1999 15:51:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAANogi14003 for ; Wed, 10 Nov 1999 15:50:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA09480 for ; Wed, 10 Nov 1999 15:50:41 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07183 for ; Wed, 10 Nov 1999 16:50:41 -0700 (MST) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id PAA01906; Wed, 10 Nov 1999 15:44:48 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA74830; Wed, 10 Nov 1999 15:48:48 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA88901; Wed, 10 Nov 1999 15:48:47 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911102348.PAA88901@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: bound@zk3.dec.com (Jim Bound) Date: Wed, 10 Nov 1999 15:48:46 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911102140.QAA0000020138@quarry.zk3.dec.com> from "Jim Bound" at Nov 10, 99 04:40:29 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Jim Bound wrote: > Well at IPng I heard today that we may move icmp lookups to standards > track. If you have an alternative we need to hear more about this now > on the list. Yes, I have an alternative, but I don't think it has any impact of the icmp lookup draft; it's just an alternative. The main design goal behind PNRP was a scenario where several name resolution mechanisms may need to be employed to find the address for a name. If we try, for example, to use the following, in this order: 1 icmp name lookups 2 DNS 3 files then the problem I have with icmp name lookups is that there is no negative feedback mechanism so the only way to know if the resolution fails is to wait for a timeout. How long should this timeout be? The longer it is, the longer I wait before doing a DNS query (which can also be slow). PNRP solves this problem by keeping a local list of peers' name-address pairs. This list is constructed by peers periodically advertising their names and corresponding link-local addresses via multicast. When a name request is made, the resolver knows very quickly if it corresponds to the link-local address of a peer. The disadvantage of this approach is the potential size of this local list. I have a prototype that runs on IRIX and it runs well, but we do have a small number of IPv6 nodes in the lab. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 10 17:31:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAB1R2L14089 for ipng-dist; Wed, 10 Nov 1999 17:27:02 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAB1Qoi14082 for ; Wed, 10 Nov 1999 17:26:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA03318 for ; Wed, 10 Nov 1999 17:26:50 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22945 for ; Wed, 10 Nov 1999 18:26:48 -0700 (MST) 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 KAA20613; Thu, 11 Nov 1999 10:25:09 +0900 (JST) To: sm@bossette.engr.sgi.com (Sam Manthorpe) cc: bound@zk3.dec.com (Jim Bound), ipng@sunroof.eng.sun.com In-reply-to: sm's message of Wed, 10 Nov 1999 15:48:46 PST. <199911102348.PAA88901@bossette.engr.sgi.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt From: itojun@iijlab.net Date: Thu, 11 Nov 1999 10:25:09 +0900 Message-ID: <20611.942283509@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Jim Bound wrote: >> Well at IPng I heard today that we may move icmp lookups to standards >> track. If you have an alternative we need to hear more about this now >> on the list. My take is that you can't really rely upon icmp namelookup. It works fine for "two machine connected by cross-cable" situation (as they talked in zeroconf meeting), but not good for general use. The way I use is for diagnosis. KAME ping6 has a option to do icmp name lookup. This works great for debugging purposes. I suggest adding text fragment that says "icmp hostname lookup is for debugging purposes, not for general daily use like resolvers". To share my feeling, please consider the following cases: 1. what do you do if you see two or more nodes with the same name. 2. most of novice users leave hostname unconfigured. default value would be like "myhost.mynet" or "myhost.netbsd". it makes situation 1 to happen more frequently. 3. many configures hostname as FQDN (like "lychee.itojun.org"), many configures as non-FQDN (like "lychee"). what if you are looking for "lychee.itojun.org" and got a reply from "lychee" (or other way around). 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 Nov 10 19:55:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAB3rRR14189 for ipng-dist; Wed, 10 Nov 1999 19:53:27 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAB3rIi14182 for ; Wed, 10 Nov 1999 19:53:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA12296 for ; Wed, 10 Nov 1999 19:53:16 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA08300 for ; Wed, 10 Nov 1999 20:53:16 -0700 (MST) Received: from localhost ([3ffe:507:182:1:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id MAA00569; Thu, 11 Nov 1999 12:42:34 +0900 (JST) Date: Thu, 11 Nov 1999 12:53:49 +0900 Message-ID: <14378.15821.311542.9106S@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bzill@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Tue, 9 Nov 1999 15:59:12 -0800 " <3D2036E25376D31197A100805FEAD892712EDE@RED-MSG-02> References: <3D2036E25376D31197A100805FEAD892712EDE@RED-MSG-02> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 15 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 9 Nov 1999 15:59:12 -0800 , >>>>> Brian Zill said: > Do people think I should write up something on this before the Thursday > meeting? Chairs, are there extra minutes anywhere to discuss this separate > from the textual format issue? I agree that API issues should be separately discussed (if we can find extra time slot), since they are not necessarility related to the textual representation itself but are very important. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 10 21:32:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAB5Tvn14227 for ipng-dist; Wed, 10 Nov 1999 21:29:57 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAB5Tmi14220 for ; Wed, 10 Nov 1999 21:29:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA24560 for ; Wed, 10 Nov 1999 21:29:47 -0800 (PST) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA12847 for ; Wed, 10 Nov 1999 21:29:47 -0800 (PST) Received: from cthulhu.engr.sgi.com (gate3-relay.engr.sgi.com [130.62.1.234]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id VAA01231; Wed, 10 Nov 1999 21:30:47 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id VAA24599; Wed, 10 Nov 1999 21:29:36 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id VAA92004; Wed, 10 Nov 1999 21:29:34 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911110529.VAA92004@bossette.engr.sgi.com> Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt To: itojun@iijlab.net Date: Wed, 10 Nov 1999 21:29:34 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20611.942283509@coconut.itojun.org> from "itojun@iijlab.net" at Nov 11, 99 10:25:09 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > >Jim Bound wrote: > >> Well at IPng I heard today that we may move icmp lookups to standards > >> track. If you have an alternative we need to hear more about this now > >> on the list. > > My take is that you can't really rely upon icmp namelookup. > It works fine for "two machine connected by cross-cable" situation > (as they talked in zeroconf meeting), but not good for general use. > The way I use is for diagnosis. KAME ping6 has a option to do > icmp name lookup. This works great for debugging purposes. > > I suggest adding text fragment that says "icmp hostname lookup is > for debugging purposes, not for general daily use like resolvers". > > To share my feeling, please consider the following cases: > 1. what do you do if you see two or more nodes with the same name. We're talking about a plug-n-play scenario right? I don't think ICMP (or PNRP) name lookups is a general solution for name resoltution, but I think it does add value in certain situations. For example, a home network, where one user is configuring names for all nodes (still talking about link-local addresses) but doesn't want a special server for name resolution. > 2. most of novice users leave hostname unconfigured. default value > would be like "myhost.mynet" or "myhost.netbsd". it makes > situation 1 to happen more frequently. In the conceptual model I have in my head of the plug-n-play, dentist's office scenario, there will rarely by any '.' in the name, rather names like `printer' and `toaster'. Far from unique, but unique locally. As for the `novice users leave hostname unconfigured'; users will configure their hostnames after having read the manual after trying to do any kind of networking with their node. > 3. many configures hostname as FQDN (like "lychee.itojun.org"), many > configures as non-FQDN (like "lychee"). what if you are looking > for "lychee.itojun.org" and got a reply from "lychee" (or other way > around). Again, I don't think this is the kind of scenario that ICMP name lookup tries to address; this is more DNS's job. The problem you describe exists already with IPv4 and isn't really a valid point against ICMP name lookups. Summary: I think the ICMP name lookup mechanism addresses a scenario that doesn't currently exist with IPv4; that of the plug-n-play network. For the kind of unique name resolution you are talking about there are always other mechanisms such as DNS, which will co-exist with ICMP name lookup. When I think of ICMP namelookup I think of Appletalk... Cheers, -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 10 21:43:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAB5fAp14262 for ipng-dist; Wed, 10 Nov 1999 21:41:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAB5f0i14255 for ; Wed, 10 Nov 1999 21:41:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA25178 for ; Wed, 10 Nov 1999 21:40:59 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA05353 for ; Wed, 10 Nov 1999 22:40:49 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id OAA00987; Thu, 11 Nov 1999 14:25:06 +0900 (JST) Date: Thu, 11 Nov 1999 14:36:21 +0900 Message-ID: <14378.21973.684476.65113P@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sm@bossette.engr.sgi.com Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-Reply-To: In your message of "Wed, 10 Nov 1999 13:14:37 -0800 (PST)" <199911102114.NAA85127@bossette.engr.sgi.com> References: <4128.942227949@munnari.OZ.AU> <199911102114.NAA85127@bossette.engr.sgi.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 10 Nov 1999 13:14:37 -0800 (PST), >>>>> sm@bossette.engr.sgi.com (Sam Manthorpe) said: >> Then look at the IPv6 addressing formats for global, site local, and link >> local, and notice that there are no (real) spare bits in global addresses, >> quite a few in site locals, and lots in link locals, and wonder if perhaps >> the scope_id (zone identifier, whatever) might just fit fairly nicely in the >> 128 available bits that we have already, and that all applications are already >> passing around - and that doing so (with whatever support is needed in the >> kernel or libraries to fill in the bits, and remove them again when >> appropriate) just might be a way to make the vast majority of applications >> just magically work, without any specific knowledge that there are such things >> as less than global addresses. > This is kind of attractive. I think the big disadvantage of this > approach is the risk of the embedded scope-id being passed across the > net or across humans to other hosts. This is still a problem with > but much less so since > the scope-id part is easily recognisable by humans and easily parsable. Exactly. In fact, this is one of the reasons that we (KAME) have purged the embedded syntax like fe80:1::xxxx from the userland. As itojun said, we still use the old syntax in the kernel, but it is a hack which is a kind of a necessary evil. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 10 22:13:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAB62wv14307 for ipng-dist; Wed, 10 Nov 1999 22:02:58 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAB62mi14300 for ; Wed, 10 Nov 1999 22:02:48 -0800 (PST) Received: from jurassic.Eng.Sun.COM (eastapp.East.Sun.COM [129.148.163.25]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA490049; Wed, 10 Nov 1999 22:02:35 -0800 (PST) From: Erik Nordmark Message-Id: <199911110602.WAA490049@jurassic.eng.sun.com> Date: Thu, 11 Nov 1999 01:06:21 -0500 To: , "Sam Manthorpe" Cc: , "Jim Bound" Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. what do you do if you see two or more nodes with the same name. Good question. > 2. most of novice users leave hostname unconfigured. default value > would be like "myhost.mynet" or "myhost.netbsd". it makes > situation 1 to happen more frequently. The specification could specify a default name based on the mac address. Thus a lookup for the address a20:1ff:fe1:234 would return the string "a20:1ff:fe1:234". That would avoid all unconfigured nodes getting some silly default. Alternatively, the default could be the zero length string and the protocol could specify that when hostname == "" don't respond to any queries. Erik 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 Nov 11 06:14:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABDsth14423 for ipng-dist; Thu, 11 Nov 1999 05:54:55 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABDshi14416 for ; Thu, 11 Nov 1999 05:54:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA08054 for ; Thu, 11 Nov 1999 05:54:44 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09439 for ; Thu, 11 Nov 1999 05:54:43 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id OAA07250; Thu, 11 Nov 1999 14:54:39 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA15614; Thu, 11 Nov 1999 14:54:38 +0100 (MET) Message-Id: <199911111354.OAA15614@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: "Steven M. Bellovin" , Brian Zill , Tim Hartrick , sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt In-reply-to: Your message of Wed, 10 Nov 1999 17:10:03 EST. <199911102210.RAA0000028692@quarry.zk3.dec.com> Date: Thu, 11 Nov 1999 14:54:37 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: should we at least have a discussion of changing hostent structure so its backwards compatible? The reason I ask is that I would love to get a TTL for each address too as a side benefit????? => this was in a previous version of the API and I like this too! Francis.Dupont@inria.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 Nov 11 07:03:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABEeJM14465 for ipng-dist; Thu, 11 Nov 1999 06:40:19 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABEe9i14458 for ; Thu, 11 Nov 1999 06:40:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA12121 for ; Thu, 11 Nov 1999 06:40:09 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA15522 for ; Thu, 11 Nov 1999 07:40:08 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Nov 1999 06:39:49 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Nov 1999 06:39:49 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712EE3@RED-MSG-02> From: Brian Zill To: "'JINMEI Tatuya / ????'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt Date: Thu, 11 Nov 1999 06:36:05 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > JINMEI, Tatuya wrote: > > Brian Zill said: > > Do people think I should write up something on > > this before the Thursday meeting? > > I agree that API issues should be separately discussed (if we can find > extra time slot), since they are not necessarility related to the > textual representation itself but are very important. I suspect that since ipng wg ran over yesterday and we needed to defer two of those presentations until today, that there won't be any extra time to discuss this during the wg meeting. If we do, great, if we don't, maybe the interested parties can get together for a hallway meeting or something. The issues here strike me as both too important and too far from consensus for us to expect any resolution at this IETF, we'll probably need to discuss this a lot more on the list. There is a bit of overlap between the API issues and the format issues (such as whether host names should resolve to an address with scope_id, or whether the scope_ids can be applied "externally" to host names). I'll be sure to bring this up at the meeting :-) --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 Nov 11 07:38:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABFIE814490 for ipng-dist; Thu, 11 Nov 1999 07:18:14 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABFHZi14483 for ; Thu, 11 Nov 1999 07:17:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA28296 for ; Thu, 11 Nov 1999 07:16:51 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA00663 for ; Thu, 11 Nov 1999 08:16:51 -0700 (MST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Nov 1999 07:02:48 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Nov 1999 07:02:48 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712EE4@RED-MSG-02> From: Brian Zill To: "'sm@bossette.engr.sgi.com'" Cc: ipng@sunroof.eng.sun.com Subject: ICMP host name lookups Date: Thu, 11 Nov 1999 07:02:47 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I changed the subject line since this isn't about scope_id formats anymore. > From: sm@bossette.engr.sgi.com [mailto:sm@bossette.engr.sgi.com] > Summary: I think the ICMP name lookup mechanism addresses a scenario > that doesn't currently exist with IPv4; that of the plug-n-play > network. [...] > > When I think of ICMP namelookup I think of Appletalk... > > Cheers, > -- Sam I agree, this is where ICMP host name lookups are most attractive. But for that particular scenario, there may be better methods. I'll admit now that I haven't read the draft since a much earlier version; since I'm always a couple drafts behind in my reading, the experimental ones come last. Now that this has been proposed for standards track again, I'll have to review it. I've heard several good ideas for the "dentist's office" DNS scenario since ICMP lookups first came out and am not sure if they're now included in this or not. Basically, what I'm saying is that I don't think it's appropriate to consider a draft automatically "wg approved" for standards track just because we were happy to approve it as experimental. As for autoconfiguration node name defaults, it's nice to include the manufactorer name and function (i.e. "Sunbeam toaster", or using Erik's unique number suggestion, "Sunbeam toaster 0000:dead:beef:cafe") so that a quick glance at the name will tell you what it is. --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 Nov 11 08:35:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABGDhh14554 for ipng-dist; Thu, 11 Nov 1999 08:13:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABGDYi14547 for ; Thu, 11 Nov 1999 08:13:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA08006 for ; Thu, 11 Nov 1999 08:13:34 -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 IAA05275 for ; Thu, 11 Nov 1999 08:13:33 -0800 (PST) Received: from new (dhcp21-fh37.fh.ietf.innovationslab.net [130.128.21.37]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id IAA23422; Thu, 11 Nov 1999 08:13:27 -0800 (PST) Message-Id: <4.2.2.19991111080518.03e12020@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 11 Nov 1999 08:11:00 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: W.G. Last Call on "DNS Extensions to Support IPv6 Address Aggregation and Renumbering" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a IPng working group last call for comments on advancing the following document as a Proposed Standard: Title : DNS Extensions to Support IPv6 Address Aggregation and Renumbering Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-05.txt Pages : 17 Date : 15-Oct-99 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on November 18, 1999. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 11 09:03:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABGh8f14595 for ipng-dist; Thu, 11 Nov 1999 08:43:08 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABGgxi14588 for ; Thu, 11 Nov 1999 08:43:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA29660 for ; Thu, 11 Nov 1999 08:43:00 -0800 (PST) Received: from infobro.com (ns.infobro.com [204.255.254.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA16447 for ; Thu, 11 Nov 1999 09:42:59 -0700 (MST) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 11 Nov 1999 11:42:45 -0500 Received: by localhost with Microsoft MAPI; Thu, 11 Nov 1999 11:42:43 -0500 Message-ID: <01BF2C39.DDEF2AA0.eric@infobro.com> From: "Eric D. Williams" To: "'sallyh@ludwig.sc.intel.com'" Cc: "'hinden@iprg.nokia.com'" , "'ipng@sunroof.eng.sun.com'" Subject: RUN-WG Draft for IPng list discussions on privacy... Date: Thu, 11 Nov 1999 11:42:36 -0500 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sally, On Monday at IETF 46 I visited the run-wg meeting. I was delighted to find that run-wg was attempting to address the issues around the collection and re-distribution of persistent state information ('Cookies') in the recent draft (although I did not have a copy of the draft, myself). In the IPng-wg (1st gathering) I brought the issue concerning the run-wg draft and its addressing of 'Cookies' as it relates to recently discussed IPv6 privacy issues. B. Hinden asked me to forward a copy of your most recently discussed draft to the IPng mailing list , we would like to review the draft for our discussion in addition to your excellent work. Thanks. Eric Eric Williams, Pres. Information Brokers, Inc. Phone: +1 202.889.4395 http://www.infobro.com/ Fax: +1 202.889.4396 mailto:eric@infobro.com Pager: +1 301.303.8998 For More Info: info@infobro.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 Nov 11 09:48:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABHS6W14659 for ipng-dist; Thu, 11 Nov 1999 09:28:06 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABHRvi14652 for ; Thu, 11 Nov 1999 09:27:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02239 for ; Thu, 11 Nov 1999 09:27:57 -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 JAA17170 for ; Thu, 11 Nov 1999 09:27:56 -0800 (PST) Received: from new (dhcp21-fh37.fh.ietf.innovationslab.net [130.128.21.37]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA29907; Thu, 11 Nov 1999 09:26:31 -0800 (PST) Message-Id: <4.2.2.19991111092215.03b3eb90@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 11 Nov 1999 09:25:16 -0800 To: "Eric D. Williams" From: Bob Hinden Subject: Re: RUN-WG Draft for IPng list discussions on privacy... Cc: "'sallyh@ludwig.sc.intel.com'" , "'hinden@iprg.nokia.com'" , "'ipng@sunroof.eng.sun.com'" In-Reply-To: <01BF2C39.DDEF2AA0.eric@infobro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Eric, >B. Hinden asked me to forward a copy of your most recently discussed draft to >the IPng mailing list , we would like to review the >draft for our discussion in addition to your excellent work. Thanks. Actually, I asked that you forward a link (e.g. a URL) to the draft. Please do not send the actual draft to the IPng list. I am not sure if the IPng w.g. will discuss this draft, but I thought it might be of interest to some people in the IPng w.g. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 11 10:43:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABINXA14712 for ipng-dist; Thu, 11 Nov 1999 10:23:33 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABINNi14705 for ; Thu, 11 Nov 1999 10:23:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA13522 for ; Thu, 11 Nov 1999 10:23:23 -0800 (PST) Received: from infobro.com (ns.infobro.com [204.255.254.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA16378 for ; Thu, 11 Nov 1999 11:23:22 -0700 (MST) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 11 Nov 1999 13:23:13 -0500 Received: by localhost with Microsoft MAPI; Thu, 11 Nov 1999 13:23:11 -0500 Message-ID: <01BF2C47.E6946BD0.eric@infobro.com> From: "Eric D. Williams" To: "'Bob Hinden'" Cc: "'sallyh@ludwig.sc.intel.com'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: RUN-WG Draft for IPng list discussions on privacy... Date: Thu, 11 Nov 1999 13:21:51 -0500 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry Bob, I was only expecting a link not the entire draft. As to "discussion" certainly a poor choice of words, "interest" is definitely better. My thinking actually was to pass the link and include the specific relevant language covered as a interesting approach and as fodder for any further perusal. My thinking is the drafts addressing of issues of dissemination/privacy concerning persistent state 'Cookies' is probably the most relevant aspect. Thanks, Eric Eric Williams, Pres. Information Brokers, Inc. Phone: +1 202.889.4395 http://www.infobro.com/ Fax: +1 202.889.4396 mailto:eric@infobro.com Pager: +1 301.303.8998 For More Info: info@infobro.com On Thursday, November 11, 1999 12:25 PM, Bob Hinden [SMTP:hinden@iprg.nokia.com] wrote: > Eric, > > >B. Hinden asked me to forward a copy of your most recently discussed draft > >to > >the IPng mailing list , we would like to review > >the > >draft for our discussion in addition to your excellent work. Thanks. > > Actually, I asked that you forward a link (e.g. a URL) to the > draft. Please do not send the actual draft to the IPng list. > > I am not sure if the IPng w.g. will discuss this draft, but I thought it > might be of interest to some people in the IPng w.g. > > Thanks, > Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 11 12:15:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABJtGu14791 for ipng-dist; Thu, 11 Nov 1999 11:55:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABJt5i14784 for ; Thu, 11 Nov 1999 11:55:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA04121 for ; Thu, 11 Nov 1999 11:55:04 -0800 (PST) Received: from samantha.lysator.liu.se (samantha.lysator.liu.se [130.236.254.202]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19263 for ; Thu, 11 Nov 1999 11:55:02 -0800 (PST) Received: from sanna.lysator.liu.se (nisse@sanna.lysator.liu.se [130.236.254.206]) by samantha.lysator.liu.se (8.9.3/8.9.3) with ESMTP id UAA12117; Thu, 11 Nov 1999 20:41:03 +0100 (MET) Received: (from nisse@localhost) by sanna.lysator.liu.se (8.8.8/8.8.7) id UAA29304; Thu, 11 Nov 1999 20:40:58 +0100 (MET) To: "Steven M. Bellovin" Cc: Francis Dupont , Brian Zill , "'Jim Bound'" , Tim Hartrick , sm@bossette.engr.sgi.com, ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt References: <19991110221522.2D9BBACAE2@smb.research.att.com> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels Möller) Date: 11 Nov 1999 20:40:57 +0100 In-Reply-To: "Steven M. Bellovin"'s message of "Wed, 10 Nov 1999 17:09:38 -0500" Message-ID: Lines: 34 X-Mailer: Gnus v5.4.59/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Steven M. Bellovin" writes: > In message <199911102054.VAA18014@givry.inria.fr>, Francis Dupont writes: > >=> I don't understand your concern. I propose to optionally add > >#define before some #include. Of course the name of the flag > >will be the same everywhere (if nobody finds something better :-). > >Perhaps you'd prefer (??) to add a -Dxxx in CFLAGS in Makefiles? > > That latter was what I thought you were implying. I'm still not fond of > #ifdefs for things like that, but it's better than my misinterpretation of > your idea. I agree with this. Quite strongly. If there are parallell lookup mechanism with similar but different semantics, it is inevitable that some program will want to use both of them. Consider a perl interpreter with a zillion of modules compiled in, with some shared recursivly included file needing to include some system headers. Using defines *inside* the system header file to choose the right behaviour, for each module, will cause head-aches. Please also consider the typical #define-guards against multiple inclusions... It's better to use distinct names (say, getipnodebyname and getipnodebyname_with_scope_id). Programs that only want the scope_id-behaviour can still do #define getipnodebyname getipnodebyname_with_scope_id if they really want, but the effects of this are easier to avoid or localize. Having two distinct and well-specified names also makes it straight-forward to detect them with tools like autoconf. /Niels -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 11 12:58:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABKYY414948 for ipng-dist; Thu, 11 Nov 1999 12:34:34 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABKYNi14941 for ; Thu, 11 Nov 1999 12:34:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA16951 for ; Thu, 11 Nov 1999 12:34:04 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA06387 for ; Thu, 11 Nov 1999 13:34:04 -0700 (MST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Nov 1999 12:33:45 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Nov 1999 12:23:13 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515E29@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: presentation notes Date: Thu, 11 Nov 1999 12:23:10 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was able to listen in on Steve's presentation (thanks Steve!) of my slides. My mbone connection started working literally a couple seconds before Steve started the presentation. There were some audio dropouts so I didn't catch everything. I tried speaking up, but nobody at the meeting heard anything. In the discussion of the default policy table... There were some comments about adding an entry for translatable addresses, lower precedence than 6to4 and v4-compatible address. That sounds fine to me. As to why I gave 6to4 and v4-compatible addresses the same precedence - I expect 6to4 addresses to see much greater use in practice. But if two hosts both have both 6to4 and v4-compatible addresses, is there some good default reason for them to use the 6to4 addresses instead of the v4-compatible addresses? It seemed more like a site policy/preference if that is desired. There were some questions about how the examples work, I'll send separate mail about them. For controversial issue 1 - the consensus seemed to be Yes & Yes. So we can have a standards-track document on default destination address ordering & source address selection, and the document can use MUST while still giving applications & upper-layers the leeway to override default choices. For controversial issue 2 - Did I hear Steve say he'd given up on this one? So there is consensus to use a deprecated source address to avoid using a source address of insufficient scope? About why I listed policy as a reason to use a deprecated address - here's an example: Suppose there are two destination addresses, 6to4 and native, and two candidate source addresses, 6to4 (preferred) and native (deprecated). The destination addresses will be ordered 6to4 before native, and for the 6to4 destination the 6to4 source will be chosen. However suppose an application sends to the native destination address anyway. Then I think it's better to use the deprecated native source address instead of the preferred 6to4 source address. For controversial issue 3 (weak vs semi-strong vs strong) - Not enough time for discussion, no consensus yet. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 11 13:38:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABLEuL14986 for ipng-dist; Thu, 11 Nov 1999 13:14:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABLEfi14979 for ; Thu, 11 Nov 1999 13:14:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA09954 for ; Thu, 11 Nov 1999 13:14:39 -0800 (PST) Received: from highroad.ds.ietf.innovationslab.net (highroad.noc.ietf.innovationslab.net [130.128.8.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29458 for ; Thu, 11 Nov 1999 14:14:38 -0700 (MST) Received: from sardine (dhcp22-fh18.fh.ietf.innovationslab.net [130.128.22.18]) by highroad.ds.ietf.innovationslab.net (8.9.3/8.9.3) with ESMTP id QAA12935; Thu, 11 Nov 1999 16:21:09 -0500 Message-Id: <4.2.0.58.19991111220220.00a415f0@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 11 Nov 1999 22:13:09 +0100 To: Richard Draves , "'IPng List'" From: Alain Durand Subject: Re: presentation notes In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515E29@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 21:23 11/11/99 , Richard Draves wrote: >As to why I gave 6to4 and v4-compatible addresses the same precedence - I >expect 6to4 addresses to see much greater use in practice. But if two hosts >both have both 6to4 and v4-compatible addresses, is there some good default >reason for them to use the 6to4 addresses instead of the v4-compatible >addresses? It seemed more like a site policy/preference if that is desired. My concern is about phasing out the transition mechanisms . Going from 6to4 to native IPv6 seems to me much easier than going from IPv4 compatible to native IPv6. The reason being that, when a site use the 6to4 mechanism, everything within the site is already native. Meaning IPv6 site infrastructure, routers, ... With IPv4 compatible, communication is directly from a dual stack host to another dual stack host, no IPv6 infrastructure whatsoever is used. Given that, if a site use IPv4 compatible and 6to4 at the same time it will be much easier when it will move to native IPv6 if already the communication were using 6to4 than IPv4 compatible addresses. For this reason, I think we should differentiate 6to4 and IPv4 compatible and give priority to 6to4. In the same line, having "default" somewhere in the middle may have some strange impact if people start using by mistake not yet defined addresses (outside of 2000::/3) - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 11 13:40:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABLPwG15028 for ipng-dist; Thu, 11 Nov 1999 13:25:58 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABLPpi15021 for ; Thu, 11 Nov 1999 13:25:51 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA17438 for ipng@sunroof.eng.sun.com; Thu, 11 Nov 1999 13:25:38 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABLK2i15006 for ; Thu, 11 Nov 1999 13:20:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA19332 for ; Thu, 11 Nov 1999 13:20:01 -0800 (PST) Received: from clio.sc.intel.com (clio.sc.intel.com [143.183.152.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA03302 for ; Thu, 11 Nov 1999 14:19:59 -0700 (MST) Received: from Ludwig.sc.intel.com (ludwig.sc.intel.com [143.183.53.32]) by clio.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with SMTP id NAA27415; Thu, 11 Nov 1999 13:19:46 -0800 (PST) Received: by Ludwig.sc.intel.com (4.1/SMI-4.1) id AA19594; Thu, 11 Nov 99 13:17:21 PST Date: Thu, 11 Nov 99 13:17:21 PST From: sallyh@Ludwig.sc.intel.com (Sally Hambridge) Message-Id: <9911112117.AA19594@Ludwig.sc.intel.com> To: "Eric D. Williams" , "'sallyh@ludwig.sc.intel.com'" Cc: "'hinden@iprg.nokia.com'" , "'ipng@sunroof.eng.sun.com'" Subject: Re: RUN-WG Draft for IPng list discussions on privacy... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ftp://ftp.isi.edu/internet-drafts/draft-ietf-run-adverts-01.txt Note - we only have one statement about "persistant state information" (soon to be "cookies"). I'm not sure that anything else in the draft (or even that statement) is worth the IPng WG's time. All we say is that people collecting personal info should tell that they are doing it, what they plan to do with it, and allow people they are collecting from to opt out. If any of this is of interest I'm glad you might find it so. Sally sallyh@ludwig.sc.intel.com >Sally, > >On Monday at IETF 46 I visited the run-wg meeting. I was delighted to find >that run-wg was attempting to address the issues around the collection and >re-distribution of persistent state information ('Cookies') in the recent draft >(although I did not have a copy of the draft, myself). In the IPng-wg (1st >gathering) I brought the issue concerning the run-wg draft and its addressing >of 'Cookies' as it relates to recently discussed IPv6 privacy issues. > >B. Hinden asked me to forward a copy of your most recently discussed draft to >the IPng mailing list , we would like to review the >draft for our discussion in addition to your excellent work. Thanks. > >Eric >Eric Williams, Pres. >Information Brokers, Inc. Phone: +1 202.889.4395 >http://www.infobro.com/ Fax: +1 202.889.4396 >mailto:eric@infobro.com Pager: +1 301.303.8998 > For More Info: info@infobro.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 Nov 11 14:46:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABMOlR15106 for ipng-dist; Thu, 11 Nov 1999 14:24:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABMOci15099 for ; Thu, 11 Nov 1999 14:24:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA08992 for ; Thu, 11 Nov 1999 14:24:39 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA10310 for ; Thu, 11 Nov 1999 15:24:38 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Nov 1999 14:24:25 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Nov 1999 14:24:24 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515E33@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: my examples Date: Thu, 11 Nov 1999 14:24:19 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It sounded like the ISP preference examples were confusing. Here are the slides with pictures: ftp://ftp.research.microsoft.com/users/richdr/slides.pdf ftp://ftp.research.microsoft.com/users/richdr/slides.ppt The setup is that ISP 1 is using prefixes 2004::/16 and 2006::/16. ISP 2 is using the prefix 2005::/16. Site A is connected to ISP 1 and is using prefix 2004:A::/48. Site B is connected to both ISP 1 and ISP 2 and is using prefixes 2005:B::/48 and 2006:B::/48. When Site A initiates communication with Site B, it has to choose a destination address. Site B nodes will have two addresses in the DNS, because Site B is using two prefixes. By default the algorithm will always pick the "wrong" address. This is because a source address in 2004:A::/48 has a longer match against the 2005:B::/48 address compared to a 2006:B::/48 address. So a node in Site A will pick the 2005:B::/48 destination address, and traffic will get routed through ISP 2 instead of staying within ISP 1. Adding an entry in Site A's policy table for 2006::/16, giving that destination prefix higher precedence, fixes the problem. For completeness I also showed an entry for 2004::/16, Site A's ISP's other prefix. These entries don't do anything special with Label & MatchSrcLabel. The next example is when Site B initiates communication with Site A. It has to choose a source address. Again, the default longest-matching-prefix rules pick the "wrong" source address. If Site B cares about this, it can add policies to fix the problem. As in the first example, there are policies to give higher precedence to Site B's ISPs' prefixes. But now the policies also control source address selection using Label and MatchSrcLabel - communication with sites attached to ISP 1 will use a 2006::/16 (or 2004::/16 but that's moot) source address, so return traffic comes back via ISP 1. In this example, the policy for ::/0 says that communication with other sites will use a 2005::/16 source address, so ISP 2 is the default ISP for return traffic. Hope this makes it clearer... Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 11 14:46:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABMWiQ15125 for ipng-dist; Thu, 11 Nov 1999 14:32:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABMWZi15118 for ; Thu, 11 Nov 1999 14:32:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA04161 for ; Thu, 11 Nov 1999 14:32:36 -0800 (PST) Received: from hotmail.com (f325.hotmail.com [207.82.251.213]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA15386 for ; Thu, 11 Nov 1999 14:32:36 -0800 (PST) Received: (qmail 42318 invoked by uid 0); 11 Nov 1999 22:32:35 -0000 Message-ID: <19991111223235.42317.qmail@hotmail.com> Received: from 130.128.34.71 by www.hotmail.com with HTTP; Thu, 11 Nov 1999 14:32:35 PST X-Originating-IP: [130.128.34.71] From: "" To: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: presentation notes Date: Thu, 11 Nov 1999 14:32:35 PST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From: Richard Draves >To: "'IPng List'" >Subject: presentation notes >Date: Thu, 11 Nov 1999 12:23:10 -0800 ... >There were some comments about adding an entry for translatable addresses, >lower precedence than 6to4 and v4-compatible address. That sounds fine to >me. > Actualy it might be more complex than that. Let me explain. Translatable addresses as defined in Erik's SIIT are: 0:0:0:0:FFFF:0:IPv4/96 In NAT-PT, as translatable addresses, we originally used any PREFIX::/96 (that NAT-PT inserts infront of IPv4 addresses on DNS replies). This is needed so you can have multiple NAT-PTs in a network. The only issue with the above PREFIX::/96 is that the client behind the NAT-PT CAN NOT distinguish it from a global IPv6 address. One alternative was to use Erik's translatable but this does not give us the ability to have multiple NAT-PTs. A middle ground is the following: 0:0:x:y:FFFF:0:IPv4/96 The 0:0::/8 sais that the address is embedded IPv4; the x:y allows for structure and multiple NAT-PTs and the rest is Erik's translatable. => the network can have multiple NAT-PT and the client *knows* when that if communicates with this address will go throuhg translation According to the table Steve presented though this would have same precedence with global addresses? I suggested that 0:0::/8 should go at the bottom (as opposed to just the 0:0:0:0:FFFF:0::/96) but this would then include the IPv4 compatible addresses (0::0:IPv4/96) Is there any other way to represent this? George P.S: Please note that in practice implementors and net admins will use whatever PREFIX::/96 they want. I am just trying to make a *recommendation* that helps transition and does not impact native connectivity! ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 11 14:46:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dABMTWw15115 for ipng-dist; Thu, 11 Nov 1999 14:29:32 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dABMTMi15108 for ; Thu, 11 Nov 1999 14:29:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA27509 for ; Thu, 11 Nov 1999 14:29:23 -0800 (PST) Received: from infobro.com (ns.infobro.com [204.255.254.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA12892 for ; Thu, 11 Nov 1999 15:29:23 -0700 (MST) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 11 Nov 1999 17:27:57 -0500 Received: by localhost with Microsoft MAPI; Thu, 11 Nov 1999 17:27:55 -0500 Message-ID: <01BF2C6A.16FDA3A0.eric@infobro.com> From: "Eric D. Williams" To: "'ipng@sunroof.eng.sun.com'" Subject: FW: RUN-WG Draft for IPng list discussions on privacy... Date: Thu, 11 Nov 1999 17:27:20 -0500 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----Original Message----- From: Eric D. Williams [SMTP:eric@infobro.com] Sent: Thursday, November 11, 1999 5:21 PM To: 'Sally Hambridge'; 'hinden@iprg.nokia.com' Subject: RE: RUN-WG Draft for IPng list discussions on privacy... That is exactly what I am referencing. it is enough for me, as I don't think the IPng w.g.'s time should be wasted on discussing these issues of information gathering/dissemination/privacy at the expense of good auto-configuration, it seems to be more of a 'sociological BCP' issue than an protocol engineering one. Your point is well taken. I realize the draft does not speak on this issue at length, however I believe (and I could certainly be wrong here) that it is the only language in IETF documents that addresses the use of and disclosure of said objects. Thanks again. Also, this treatment could certainly also be relevant for the 'wiretapping' issue discussed last night as that issue, in my mind, relates entirely to host security and the management of persistent host configuration 'information'. BTW: IMHO, the language could be more encompassing if left as 'persistent state information' rather than 'Cookies' or, better yet, inclusive of other persistent state info. outside of cookies. It seems when dealing with these issues one sentence CAN make a whole lot of difference in perception. Eric On Thursday, November 11, 1999 4:17 PM, Sally Hambridge [SMTP:sallyh@Ludwig.sc.intel.com] wrote: > ftp://ftp.isi.edu/internet-drafts/draft-ietf-run-adverts-01.txt > > Note - we only have one statement about "persistant state information" > (soon to be "cookies"). I'm not sure that anything else in the > draft (or even that statement) is worth the IPng WG's time. > > All we say is that people collecting personal info should tell > that they are doing it, what they plan to do with it, and allow > people they are collecting from to opt out. If any of this is > of interest I'm glad you might find it so. > > Sally > sallyh@ludwig.sc.intel.com > > >Sally, > > > >On Monday at IETF 46 I visited the run-wg meeting. I was delighted to find > >that run-wg was attempting to address the issues around the collection and > >re-distribution of persistent state information ('Cookies') in the recent > >draft > >(although I did not have a copy of the draft, myself). In the IPng-wg (1st > >gathering) I brought the issue concerning the run-wg draft and its addressing > > > >of 'Cookies' as it relates to recently discussed IPv6 privacy issues. > > > >B. Hinden asked me to forward a copy of your most recently discussed draft to > > > >the IPng mailing list , we would like to review the > > > >draft for our discussion in addition to your excellent work. Thanks. > > > >Eric > >Eric Williams, Pres. > >Information Brokers, Inc. Phone: +1 202.889.4395 > >http://www.infobro.com/ Fax: +1 202.889.4396 > >mailto:eric@infobro.com Pager: +1 301.303.8998 > > For More Info: info@infobro.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 Nov 11 21:57:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAC5cOg15426 for ipng-dist; Thu, 11 Nov 1999 21:38:24 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAC5cDi15419 for ; Thu, 11 Nov 1999 21:38:13 -0800 (PST) Received: from jurassic.Eng.Sun.COM (eastapp.East.Sun.COM [129.148.163.25]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA251841; Thu, 11 Nov 1999 21:38:07 -0800 (PST) From: Erik Nordmark Message-Id: <199911120538.VAA251841@jurassic.eng.sun.com> Date: Fri, 12 Nov 1999 00:41:21 -0500 To: "Richard Draves" , "'IPng List'" Subject: Re: my examples X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >It sounded like the ISP preference examples were confusing. I just got thing wrong in my head - partially due to the 2005 and 2006 prefixes being in different order in the ISP boxes and in the site boxes. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 14 20:47:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAF4S8417201 for ipng-dist; Sun, 14 Nov 1999 20:28:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAF4Rwi17194 for ; Sun, 14 Nov 1999 20:28:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA10521 for ; Sun, 14 Nov 1999 20:27:57 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26008 for ; Sun, 14 Nov 1999 20:27:57 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id B42325796F for ; Sun, 14 Nov 1999 22:27:56 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id F1B314FB02; Sun, 14 Nov 1999 22:27:28 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 9C4014C90D; Sun, 14 Nov 1999 22:27:28 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000001253; Sun, 14 Nov 1999 23:27:55 -0500 (EST) From: Jim Bound Message-Id: <199911150427.XAA0000001253@quarry.zk3.dec.com> To: Brian Zill Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Implementing the architectural principles of Scope-IDs Date: Sun, 14 Nov 1999 23:27:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Subject was: Re: draft-ietf-ipngwg-scopedaddr-format-00.txt I changed the subject to another thread that I believe must run simultaneously while we resolve the API issues and what our course will be regarding scope-ids and I think other issues. Right now the use of scope-ids (zone-id, or region-ids) is at best a concept and principal within the addressing architecture for IPv6. Before we all go off and change things I would like to hear some real implementation ideas presented to see how scope-ids will work in practice within IPv6. It is my bias right now that they will not work without affecting other systems within the IP protocol suite if they are to be implemented in addition to them being architected. Here is one way I thought of them being implemented: 1. When an ip-name is looked-up to DNS and a response comes back the scope-id is attached to the api caller based on the scope-id the interface is within. So if a dns query goes out over le0 and le0 is within scope-id of FUZZY then the address that comes back would be assigned sin6-scope-id of FUZZY. 2. Likewise when the name for an ip-address is looked up the scope-id if going over le0 would be given FUZZY. But what if the DNS server is the server for all scope-ids for this node but the only interface to the DNS server happens to be within the scope-id FUZZY. And there is another scope-id called CLEAR on another set of interfaces for the node. For example the DNS at sin-scope-id FUZZY : www.one.com A6 fec0::234 (node is within FUZZY scope-id) www.two.com A6 fec0::234 (node is within CLEAR scope-id) If the node sends out a DNS request for www.two.com on FUZZY scope-id region/zone it will get back an address and assign it the sin6_scope_id of FUZZY. But the packet will in fact go to www.once.com not www.two.com. So my search for an implementation absract for sin6-scope-id will not work with the assignment of the scope-id based on the interface on which the query/response takes place for DNS, in the above example. I think we need to nail down the use of this architecture precept of scoped addresses except for link-local and multicast in the present Ipv6 aggr and addr specs (rfc 2373/2374). In fact I am glad now they are not at Draft Std as this gives me pause thinking about this. We don't have to revisit the entire notion of scope-ids for the purposes of getxx APIs but we do need to prove it can work abstractly, and certainly before we adopt any changes to the existing and deployed APIs. Robert Elz's suggestion is looking pretty good to me right now!!!! And if we can figure this out a strong "health warning" needs to be attached to the solutions that there is even much pain with IPv6 when you don't use Global Addresses. /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 Mon Nov 15 03:49:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAFBUAJ17365 for ipng-dist; Mon, 15 Nov 1999 03:30:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAFBTwi17355 for ; Mon, 15 Nov 1999 03:29:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA28038 for ; Mon, 15 Nov 1999 03:29:58 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA13440 for ; Mon, 15 Nov 1999 04:29:57 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Nov 1999 01:19:32 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Nov 1999 01:19:32 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712EF0@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: FW: Implementing the architectural principles of Scope-IDs Date: Mon, 15 Nov 1999 01:19:27 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > I changed the subject to another thread [...] Yes, we've gotten way off the subject of textual representation of scoped addresses. > Right now the use of scope-ids (zone-id, or region-ids) > is at best a concept and principal within the addressing > architecture for IPv6. Is it? The use of the scope_id field with link-local addresses seems to be very well understood and implemented widely. The use of scope_ids with site-local addresses is fairly well understood, although not widely implemented at the moment. Most of what you appear to be arguing in this message is that name to address translation isn't well defined for scoped addresses. I disagree, as I'll get to below. However, I first want to say that I think both link-local and site-local addresses are wonderful concepts and perfectly useable for some applications without ever attaching names to them. > Before we all go off and change things I would like > to hear some real implementation ideas presented to > see how scope-ids will work in practice within IPv6. Okay. > It is my bias right now that they will not work without > affecting other systems within the IP protocol suite if > they are to be implemented in addition to them > being architected. I disagree. I think they are fairly straight-forward to implement. Most of the issues that are being discussed in this thread are not protocol issues (that is, they don't affect the behavior of the protocol or interoperability). They are host issues that we're trying to agree upon to avoid confusing users (i.e. the textual representation issue) and to make code easier to port between platforms (i.e. the API issue). > Here is one way I thought of them being implemented: > > 1. When an ip-name is looked-up to DNS and a response > comes back the scope-id is attached to the api caller > based on the scope-id the interface is within. So if a > dns query goes out over le0 and le0 is within scope-id > of FUZZY then the address that comes back would be > assigned sin6-scope-id of FUZZY. Determination of the scope_id value based on the interface used to access the name service only works for zone/region/district specific name resolution systems. For this reason, I think we need to talk about link-local and site-local addresses separately since I expect them to be handled differently. For link-local addresses, I can imagine a resolver determining the scope_id based on what link it performed the name resolution on. I don't expect the name resolution to be the DNS in that case, but rather a link-specific lookup mechanism like Matt Crawford's icmp-name-lookups. For site-local addresses, Erik Nordmark's site-prefixes draft specifies a method for handling name to address translation via the global DNS. A resolving node can determine whether or not one (or more) of its interfaces are in the same site as the target node based on whether the target node's global addresses have a prefix that is in the interface's site prefix list. I think Erik's draft is pretty good at explaining how to do this. > 2. Likewise when the name for an ip-address is looked > up the scope-id if going over le0 would be given FUZZY. Again, for zone/region/district specific lookups, sure. Otherwise, no. > But what if the DNS server is the server for all > scope-ids for this node but the only interface to > the DNS server happens to be within the scope-id FUZZY. If the DNS server contains records for multiple sites than you are describing a lookup mechanism which isn't zone/region/district specific. Erik's draft specifies how multi-sited nodes that are looking up fully-qualified domain names in the global DNS can determine the site-local addresses corresponding to those names (assuming they have any). > And there is another scope-id called CLEAR on another > set of interfaces for the node. > > For example the DNS at sin-scope-id FUZZY : > > www.one.com A6 fec0::234 (node is within FUZZY scope-id) > > www.two.com A6 fec0::234 (node is within CLEAR scope-id) > > If the node sends out a DNS request for www.two.com on > FUZZY scope-id region/zone it will get back an address > and assign it the sin6_scope_id of FUZZY. But the > packet will in fact go to www.once.com not www.two.com. Not if you implement Erik's draft. It doesn't matter how you reach the global DNS. If you look up www.two.com, you'll get back both global and site-local addresses. If any of the global addresses has a prefix which matches a prefix in one of your interface's site prefix list than the site-local addresses can be used with a scope_id taken from the site id of the interface with the matching prefix. > So my search for an implementation absract for > sin6-scope-id will not work with the assignment > of the scope-id based on the interface on which > the query/response takes place for DNS, in the > above example. I suspect that's why Erik's draft details a different method :-) > I think we need to nail down the use of this > architecture precept of scoped addresses except > for link-local and multicast in the present Ipv6 > aggr and addr specs (rfc 2373/2374). Personally, I only have questions about scoped multicast addresses. Unicast node-local, link-local and site-local all seem pretty straight-forward to me. > We don't have to revisit the entire notion of > scope-ids for the purposes of getxx APIs but we do > need to prove it can work abstractly, and certainly > before we adopt any changes to the existing and > deployed APIs. I agree we don't have to revisit the entire notion of scope ids. It's the current specification of the getxx APIs which I think we need to revisit. > Robert Elz's suggestion is looking pretty good to me right now!!!! It's a cute hack. However, I think it's dangerous from the standpoint that these things which aren't really addresses are being exposed at user-level. They would inevitably end up being passed around as data, at which point programs would start breaking. It's also kind of ugly and could be confusing to programmers. I'd rather the API was as clean and easy to understand as possible. > And if we can figure this out a strong "health warning" > needs to be attached to the solutions that there is > even much pain with IPv6 when you don't use > Global Addresses. I'm having trouble parsing this. --Brian > > /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 Mon Nov 15 08:34:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAFGBeh17471 for ipng-dist; Mon, 15 Nov 1999 08:11:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAFGBSi17464 for ; Mon, 15 Nov 1999 08:11:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA22232 for ; Mon, 15 Nov 1999 08:11:28 -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 IAA11376 for ; Mon, 15 Nov 1999 08:11:26 -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 BAA08308; Tue, 16 Nov 1999 01:09:37 +0900 (JST) To: daniele@zk3.dec.com cc: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: TCP/UDP over IPv6 MIB From: itojun@iijlab.net Date: Tue, 16 Nov 1999 01:09:37 +0900 Message-ID: <8306.942682177@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, TCP/UDP over IPv6 MIB (rfc245[24]) places MIB tree under experimental tree. Is there any plan to update it, or any reason for "experimental"? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 15 08:34:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAFGB2k17462 for ipng-dist; Mon, 15 Nov 1999 08:11:02 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAFGAri17455 for ; Mon, 15 Nov 1999 08:10:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA14268 for ; Mon, 15 Nov 1999 08:10:52 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10949 for ; Mon, 15 Nov 1999 08:10:48 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 31E6E9A8D6 for ; Mon, 15 Nov 1999 10:10:47 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id BADB7BC4DB; Mon, 15 Nov 1999 10:10:14 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 33F35B2A46; Mon, 15 Nov 1999 10:10:14 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000006926; Mon, 15 Nov 1999 11:10:29 -0500 (EST) From: Jim Bound Message-Id: <199911151610.LAA0000006926@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: FW: Implementing the architectural principles of Scope-IDs In-reply-to: Your message of "Mon, 15 Nov 1999 01:19:27 PST." <3D2036E25376D31197A100805FEAD892712EF0@RED-MSG-02> Date: Mon, 15 Nov 1999 11:10:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Right now the use of scope-ids (zone-id, or region-ids) >> is at best a concept and principal within the addressing >> architecture for IPv6. >Is it? The use of the scope_id field with link-local addresses seems to be >very well understood and implemented widely. The use of scope_ids with >site-local addresses is fairly well understood, although not widely >implemented at the moment. I agree for link-local addresses and said that below. If we believe the concept is well defined and want to point to Erik's draft that is fine but that draft needs much more WG review and discussion then. My point is that site-local addresses will not work without "something" else being defined and we all agree to. We have not all agreed to Erik's draft and that is a work item for this WG. Ergo the use of site-local addresses are not well understood or implemented. So I will focus the dicussion further. >Most of what you appear to be arguing in this message is that name to >address translation isn't well defined for scoped addresses. I disagree, as >I'll get to below. However, I first want to say that I think both >link-local and site-local addresses are wonderful concepts and perfectly >useable for some applications without ever attaching names to them. Not. This is just one bit of pain from the entire use of site-local addresses and I think Erik's draft has some assumptions (all thru the draft there are assumptions) we all better discuss if we agree with. But they are just one set of assumptions. I agree with you they are good "concepts". I think link-local is wonderful and was there in the beginnning when we defined them and have put them into a product stack. Site-Local is a different matter and needs more discussion for "unicast". >> Before we all go off and change things I would like >> to hear some real implementation ideas presented to >> see how scope-ids will work in practice within IPv6. >Okay. Good. >> It is my bias right now that they will not work without >> affecting other systems within the IP protocol suite if >> they are to be implemented in addition to them >> being architected. >I disagree. I think they are fairly straight-forward to implement. Most of >the issues that are being discussed in this thread are not protocol issues >(that is, they don't affect the behavior of the protocol or >interoperability). They are host issues that we're trying to agree upon to >avoid confusing users (i.e. the textual representation issue) and to make >code easier to port between platforms (i.e. the API issue). I disagree with you. If we all agree with Erik's enhancements to ND and the assumptions about the use of Global and Site-Local addresses we can avoid the DNS problem (2 faced DNS), but those assumptions I think must be part of the operational parts of DNS when site-local addresses are used. This IMO affects DNS which is part of IP indirectly. And if you re-read my statement above I did not use the word protocol in the context you state above. I consider DNS to be part of the IP protocol suite. >> Here is one way I thought of them being implemented: >> >> 1. When an ip-name is looked-up to DNS and a response >> comes back the scope-id is attached to the api caller >> based on the scope-id the interface is within. So if a >> dns query goes out over le0 and le0 is within scope-id >> of FUZZY then the address that comes back would be >> assigned sin6-scope-id of FUZZY. >Determination of the scope_id value based on the interface used to access >the name service only works for zone/region/district specific name >resolution systems. For this reason, I think we need to talk about >link-local and site-local addresses separately since I expect them to be >handled differently. I agree 100%. They are completely different issues. >For link-local addresses, I can imagine a resolver determining the scope_id >based on what link it performed the name resolution on. I don't expect the >name resolution to be the DNS in that case, but rather a link-specific >lookup mechanism like Matt Crawford's icmp-name-lookups. I agree and will hold my comments on Matts draft till later as I am re-looking a that draft now. Erik's draft also has a means to handle the link-local case I think too. I don't think link-local addresses should be permitted in the DNS!!! >For site-local addresses, Erik Nordmark's site-prefixes draft specifies a >method for handling name to address translation via the global DNS. A >resolving node can determine whether or not one (or more) of its interfaces >are in the same site as the target node based on whether the target node's >global addresses have a prefix that is in the interface's site prefix list. >I think Erik's draft is pretty good at explaining how to do this. My discussion below assumed no global addresses are being used at all by the site in the normal case. Sure if global addresses are present as an A6/AAAAA record they will help differentiate my case below if a site-prefix is advertised as Erik suggests. But I am presenting one case right now and assuming the site DNS only has names and sitelocal addresses. >> 2. Likewise when the name for an ip-address is looked >> up the scope-id if going over le0 would be given FUZZY. >Again, for zone/region/district specific lookups, sure. Otherwise, no. DNS does not differentiate btw lookups being zone/region/district at all? >> But what if the DNS server is the server for all >> scope-ids for this node but the only interface to >> the DNS server happens to be within the scope-id FUZZY. >If the DNS server contains records for multiple sites than you are >describing a lookup mechanism which isn't zone/region/district specific. Sure I am. It can have servers on each site so the 1-N number of servers are not relevant. What is returned is the issue. >Erik's draft specifies how multi-sited nodes that are looking up >fully-qualified domain names in the global DNS can determine the site-local >addresses corresponding to those names (assuming they have any). I know. I am late with it but I need to send input on this draft when the site is not using Global addresses for most nodes cause they want to use the idea of private addresses. I will get this thread out this week if I can. I think Erik's draft does not handle the case below. >> And there is another scope-id called CLEAR on another >> set of interfaces for the node. >> >> For example the DNS at sin-scope-id FUZZY : >> >> www.one.com A6 fec0::234 (node is within FUZZY scope-id) >> >> www.two.com A6 fec0::234 (node is within CLEAR scope-id) >> >> If the node sends out a DNS request for www.two.com on >> FUZZY scope-id region/zone it will get back an address >> and assign it the sin6_scope_id of FUZZY. But the >> packet will in fact go to www.once.com not www.two.com. >Not if you implement Erik's draft. It doesn't matter how you reach the >global DNS. If you look up www.two.com, you'll get back both global and >site-local addresses. If any of the global addresses has a prefix which >matches a prefix in one of your interface's site prefix list than the >site-local addresses can be used with a scope_id taken from the site id of >the interface with the matching prefix. You changed my example. There are no global addresses for www.one or www.two. >> So my search for an implementation absract for >> sin6-scope-id will not work with the assignment >> of the scope-id based on the interface on which >> the query/response takes place for DNS, in the >> above example. >I suspect that's why Erik's draft details a different method :-) I don't believe Erik solves the problem case above but that is part of the input I owe Erik on that spec. >> I think we need to nail down the use of this >> architecture precept of scoped addresses except >> for link-local and multicast in the present Ipv6 >> aggr and addr specs (rfc 2373/2374). >Personally, I only have questions about scoped multicast addresses. Unicast >node-local, link-local and site-local all seem pretty straight-forward to >me. Funny. Multicast is crystal clear to me ....---)........... And link-local............ >> We don't have to revisit the entire notion of >> scope-ids for the purposes of getxx APIs but we do >> need to prove it can work abstractly, and certainly >> before we adopt any changes to the existing and >> deployed APIs. > >I agree we don't have to revisit the entire notion of scope ids. It's the >current specification of the getxx APIs which I think we need to revisit. I completely disagree. If anyone tells me we can change the API because a draft exists that does not IMO have wide consensus and not a lot of input and review is a corner stone to change the existing user interface to IPv6 for existing customers then I will tell them this is not a wise decision, until we have the discussion I have asked to start on this mail thread. >> Robert Elz's suggestion is looking pretty good to me right now!!!! >It's a cute hack. However, I think it's dangerous from the standpoint that >these things which aren't really addresses are being exposed at user-level. >They would inevitably end up being passed around as data, at which point >programs would start breaking. It's also kind of ugly and could be >confusing to programmers. I'd rather the API was as clean and easy to >understand as possible. What??? Please state why and how this would break user data? >> And if we can figure this out a strong "health warning" >> needs to be attached to the solutions that there is >> even much pain with IPv6 when you don't use >> Global Addresses. >I'm having trouble parsing this. Using scope-ids: 1) requires additional specification 2) requires more processing at each node 3) requires parsing and sorting DNS records 4) has all the limitations of any private addresses 5) and renumbering will not occur anymore with IPv6 than IPv4 It has overhead and overhead needs health warnings. And as I said we still do not have a crystal clear vision of how site-locals can be used and deployed. /jim --Brian > > /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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 11:49:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAFJVaQ17801 for ipng-dist; Mon, 15 Nov 1999 11:31:36 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAFJVUi17794 for ; Mon, 15 Nov 1999 11:31:30 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA11251 for ipng@sunroof.eng.sun.com; Mon, 15 Nov 1999 11:31:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAFGIYi17480 for ; Mon, 15 Nov 1999 08:18:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA15142 for ; Mon, 15 Nov 1999 08:18:34 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15795 for ; Mon, 15 Nov 1999 08:18:31 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 1CF8B1521B2; Mon, 15 Nov 1999 10:18:31 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id A64D6BC4D9; Mon, 15 Nov 1999 10:17:58 -0600 (CST) Received: from iota.zk3.dec.com (iota.zk3.dec.com [16.140.32.65]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id B9D26B2A45; Mon, 15 Nov 1999 10:17:56 -0600 (CST) Received: from zk3.dec.com by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM) id LAA0000010531; Mon, 15 Nov 1999 11:18:28 -0500 (EST) Message-ID: <383031DB.B44C79A8@zk3.dec.com> Date: Mon, 15 Nov 1999 11:16:27 -0500 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.7 [en] (X11; I; OSF1 V5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com, Mike Daniele Subject: Re: TCP/UDP over IPv6 MIB References: <8306.942682177@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net wrote: > Hello, TCP/UDP over IPv6 MIB (rfc245[24]) places MIB tree under > experimental tree. Is there any plan to update it, or any reason > for "experimental"? > > itojun " It is assumed that the objects defined in this memo will eventually be defined in an update to [TCP MIB]. For this reason, the module identity is assigned under the experimental portion of the MIB. " Note that the *module identity* is assigned under experimental, but the management objects themselves are assigned under mib-2.tcp/udp. This way when we do update the v4 TCP/UDP MIBs to include these new tables, there will be no impact to implementations. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 15 15:25:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAFNLMa18212 for ipng-dist; Mon, 15 Nov 1999 15:21:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAFNLEi18205 for ; Mon, 15 Nov 1999 15:21:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA11731 for ; Mon, 15 Nov 1999 15:21:14 -0800 (PST) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA15326 for ; Mon, 15 Nov 1999 15:21:13 -0800 (PST) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Nov 1999 15:19:58 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Nov 1999 15:19:57 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA2169F@RED-MSG-50> From: Richard Draves To: "'gtsirt@hotmail.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: presentation notes Date: Mon, 15 Nov 1999 15:19:53 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Two comments - 1. You note that implementors and administrators might use any prefix for translation. If the default policy table has an entry for translatable addresses, it needs to be some standard prefix that is widely used enough to be worth the bother. 2. The policy table is a longest-matching-prefix lookup table, so there's no problem with having (for example) one policy for ::/8 and another policy for ::/96 and another policy for ::/0. Thanks, Rich > -----Original Message----- > From: gtsirt@hotmail.com [mailto:gtsirt@hotmail.com] > Sent: Thursday, November 11, 1999 2:33 PM > To: Richard Draves; ipng@sunroof.eng.sun.com > Subject: Re: presentation notes > > > > > > >From: Richard Draves > >To: "'IPng List'" > >Subject: presentation notes > >Date: Thu, 11 Nov 1999 12:23:10 -0800 > ... > >There were some comments about adding an entry for > translatable addresses, > >lower precedence than 6to4 and v4-compatible address. That > sounds fine to > >me. > > > > Actualy it might be more complex than that. Let me explain. > > Translatable addresses as defined in Erik's SIIT are: > 0:0:0:0:FFFF:0:IPv4/96 > > In NAT-PT, as translatable addresses, we originally used any > PREFIX::/96 > (that NAT-PT inserts infront of IPv4 addresses on DNS > replies). This is > needed so you can have multiple NAT-PTs in a network. The > only issue with > the above PREFIX::/96 is that the client behind the NAT-PT CAN NOT > distinguish it from a global IPv6 address. One alternative > was to use Erik's > translatable but this does not give us the ability to have > multiple NAT-PTs. > A middle ground is the following: > 0:0:x:y:FFFF:0:IPv4/96 > > The 0:0::/8 sais that the address is embedded IPv4; the x:y > allows for > structure and multiple NAT-PTs and the rest is Erik's > translatable. => the > network can have multiple NAT-PT and the client *knows* when that if > communicates with this address will go throuhg translation > > According to the table Steve presented though this would have same > precedence with global addresses? > I suggested that 0:0::/8 should go at the bottom (as opposed > to just the > 0:0:0:0:FFFF:0::/96) but this would then include the IPv4 compatible > addresses (0::0:IPv4/96) > > Is there any other way to represent this? > > George > > P.S: Please note that in practice implementors and net admins > will use > whatever PREFIX::/96 they want. I am just trying to make a > *recommendation* > that helps transition and does not impact native connectivity! > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 16:09:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAG066K18254 for ipng-dist; Mon, 15 Nov 1999 16:06:06 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAG05qi18247 for ; Mon, 15 Nov 1999 16:05:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA16857 for ; Mon, 15 Nov 1999 16:05:53 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15662 for ; Mon, 15 Nov 1999 16:05:46 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980305.SGI.8.8.8-aspam-6.2/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA407281; Mon, 15 Nov 1999 16:02:37 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA45675; Mon, 15 Nov 1999 16:02:31 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id QAA15301; Mon, 15 Nov 1999 16:02:30 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911160002.QAA15301@bossette.engr.sgi.com> Subject: Re: FW: Implementing the architectural principles of Scope-IDs To: bound@zk3.dec.com (Jim Bound) Date: Mon, 15 Nov 1999 16:02:29 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911151610.LAA0000006926@quarry.zk3.dec.com> from "Jim Bound" at Nov 15, 99 11:10:28 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the concepts are not widely understood. Or maybe they are widely understood but everybody understands their own personal concept :-) Jim Bound wrote: > >For site-local addresses, Erik Nordmark's site-prefixes draft specifies a > >method for handling name to address translation via the global DNS. A > >resolving node can determine whether or not one (or more) of its interfaces > >are in the same site as the target node based on whether the target node's > >global addresses have a prefix that is in the interface's site prefix list. > >I think Erik's draft is pretty good at explaining how to do this. > > My discussion below assumed no global addresses are being used at all by > the site in the normal case. I agree with Jim. I don't see why the set of nodes encompassed by a particular site-prefix should be the same as those encompassed by a `site' in the site-local meaning of the word. I agree that this will me the norm, but don't see a need for making this a requirement. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.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 Nov 15 17:04:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAG11rj18339 for ipng-dist; Mon, 15 Nov 1999 17:01:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAG11ii18332 for ; Mon, 15 Nov 1999 17:01:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA12708 for ; Mon, 15 Nov 1999 17:01:44 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA08596 for ; Mon, 15 Nov 1999 16:29:55 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Nov 1999 15:28:23 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Mon, 15 Nov 1999 15:28:22 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA216A0@RED-MSG-50> From: Richard Draves To: "'Alain Durand'" Cc: "'IPng List'" Subject: RE: presentation notes Date: Mon, 15 Nov 1999 15:28:18 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My concern is about phasing out the transition mechanisms > . > Going from 6to4 to native IPv6 seems to me much easier > than going from IPv4 compatible to native IPv6. > The reason being that, when a site use the 6to4 mechanism, > everything within the site is already native. Meaning IPv6 > site infrastructure, routers, ... > With IPv4 compatible, communication is directly from > a dual stack host to another dual stack host, no IPv6 infrastructure > whatsoever is used. > > Given that, if a site use IPv4 compatible and 6to4 at the same time > it will be much easier when it will move to native IPv6 if already > the communication were using 6to4 than IPv4 compatible addresses. > > For this reason, I think we should differentiate 6to4 and > IPv4 compatible > and give priority to 6to4. In practice, I would expect 6to4 will mostly be used to give addresses to nodes that do not have v4 connectivity. That's the big win of 6to4. So the vast majority of nodes with 6to4 addresses will not have v4-compatible addresses. So this will be moot. 6to4 gateways might be assigned both v4-compatible and 6to4 addresses, but it will be equally efficient to reach them using either address. So for them, no need to make a distinction. Can you flesh out a transition scenario where giving a preference to 6to4 addresses over v4-compatible addresses will help the transition? > In the same line, having "default" somewhere in the middle may > have some strange impact if people start using by mistake > not yet defined addresses (outside of 2000::/3) So are you suggesting giving a middle preference to 2000::/3 and last place to ::/0? I don't like biasing against new address formats like that, it might inhibit innovation. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 15 17:45:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAG1gPS18416 for ipng-dist; Mon, 15 Nov 1999 17:42:25 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAG1gHi18409 for ; Mon, 15 Nov 1999 17:42:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA14754 for ; Mon, 15 Nov 1999 17:42:17 -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 SAA11091 for ; Mon, 15 Nov 1999 18:42:15 -0700 (MST) Received: from darkstar.iprg.nokia.com (root@darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id RAA19262; Mon, 15 Nov 1999 17:41:13 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id RAA28385; Mon, 15 Nov 1999 17:41:13 -0800 X-Virus-Scanned: Mon, 15 Nov 1999 17:41:13 -0800 Nokia Silicon Valley Email Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma028293; Mon, 15 Nov 99 17:41:08 -0800 Message-Id: <4.2.2.19991115173850.037be900@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 15 Nov 1999 17:39:51 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Minutes from Tokyo IPng Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The minutes from the Tokyo IPng meeting are now available at: http://playground.sun.com/pub/ipng/html/meetings.html Please send corrections to me. Bob p.s. Sorry for the delay getting the minutes out. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 17:52:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAG1ot818443 for ipng-dist; Mon, 15 Nov 1999 17:50:55 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAG1oli18436 for ; Mon, 15 Nov 1999 17:50:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA08192 for ; Mon, 15 Nov 1999 17:50:46 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA05600 for ; Mon, 15 Nov 1999 17:50:46 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 6855D15219E; Mon, 15 Nov 1999 19:50:46 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id D1F614FB01; Mon, 15 Nov 1999 19:50:17 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 6B6C14C904; Mon, 15 Nov 1999 19:50:17 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000005719; Mon, 15 Nov 1999 20:50:45 -0500 (EST) From: Jim Bound Message-Id: <199911160150.UAA0000005719@quarry.zk3.dec.com> To: members@ipv6forum.com, deployment@ipv6.org, ipng@sunroof.eng.sun.com Subject: IPv6 Press Recap of Oct 1999 IPv6 Spawar Event Date: Mon, 15 Nov 1999 20:50:45 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://www.gcn.com/vol18_no36/news/948-1.html We will have a bake-off at U.S. Navy Spawar May 10-11, 2000. Hope to see more vendors there and implementations. Also will be looking for implentation topics to be presented. /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 Mon Nov 15 17:58:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAG1tjI18472 for ipng-dist; Mon, 15 Nov 1999 17:55:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAG1tai18465 for ; Mon, 15 Nov 1999 17:55:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA05772 for ; Mon, 15 Nov 1999 17:55:36 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA16683 for ; Mon, 15 Nov 1999 18:55:35 -0700 (MST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 63129152093; Mon, 15 Nov 1999 19:55:35 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id C83214FB01; Mon, 15 Nov 1999 19:55:06 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 641914C902; Mon, 15 Nov 1999 19:55:06 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000007877; Mon, 15 Nov 1999 20:55:34 -0500 (EST) From: Jim Bound Message-Id: <199911160155.UAA0000007877@quarry.zk3.dec.com> To: deployment@ipv6.org, ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: Research Project porting Kame to Alpha Date: Mon, 15 Nov 1999 20:55:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please just reply to me. As Kame becomes the code base for BSD I am exploring funding a project to port Kame code base to Alpha. If anyone is interested or knows of someone or entity that would be interested please send me email. Most likely it would be wise to start with Netbsd base to get to Kame, but maybe not. thanks /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 Mon Nov 15 21:01:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAG4wft18613 for ipng-dist; Mon, 15 Nov 1999 20:58:41 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAG4wXi18606 for ; Mon, 15 Nov 1999 20:58:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA28100 for ; Mon, 15 Nov 1999 20:58:32 -0800 (PST) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA12860 for ; Mon, 15 Nov 1999 21:58:30 -0700 (MST) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id EAA00218; Tue, 16 Nov 1999 04:53:21 GMT Message-Id: <199911160453.EAA00218@orchard.arlington.ma.us> To: Jim Bound cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: Re: Research Project porting Kame to Alpha In-Reply-To: Message from Jim Bound of "Mon, 15 Nov 1999 20:55:34 EST." <199911160155.UAA0000007877@quarry.zk3.dec.com> Date: Mon, 15 Nov 1999 23:53:20 -0500 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk KAME works fine on NetBSD/alpha. - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 15 23:35:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAG7XGj18677 for ipng-dist; Mon, 15 Nov 1999 23:33:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAG7X4i18670 for ; Mon, 15 Nov 1999 23:33:05 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA13279 for ; Mon, 15 Nov 1999 23:33:05 -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 XAA14288 for ; Mon, 15 Nov 1999 23:33:02 -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 QAA14817; Tue, 16 Nov 1999 16:29:01 +0900 (JST) To: Jim Bound cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au In-reply-to: bound's message of Mon, 15 Nov 1999 20:55:34 EST. <199911160155.UAA0000007877@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Research Project porting Kame to Alpha From: itojun@iijlab.net Date: Tue, 16 Nov 1999 16:29:01 +0900 Message-ID: <14815.942737341@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >As Kame becomes the code base for BSD I am exploring funding a project >to port Kame code base to Alpha. If anyone is interested or knows of >someone or entity that would be interested please send me email. Most >likely it would be wise to start with Netbsd base to get to Kame, but >maybe not. Just FYI. KAME runs on any platform that is supported by NetBSD, therefore it runs on NetBSD/alpha as well. There are two ways to get KAME-on-alpha code: - install NetBSD 1.4.1 onto your alpha box, then replace the kernel with the one built from KAME tree (get one from ftp.kame.net) - install NetBSD-current onto your alpha box. I have alpha box for testing and most of 64-bit alignment issues are already solved. If you find any 64-bit alignment issues (or endian issues), please let us know. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 16 01:42:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAG9eMo18768 for ipng-dist; Tue, 16 Nov 1999 01:40:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAG9eAi18761 for ; Tue, 16 Nov 1999 01:40:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA20116 for ; Tue, 16 Nov 1999 01:40:10 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA19371 for ; Tue, 16 Nov 1999 02:40:10 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Nov 1999 01:28:29 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Nov 1999 01:18:25 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712EF7@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Implementing the architectural principles of Scope-IDs Date: Tue, 16 Nov 1999 01:18:20 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > >The use of the scope_id field with link-local > >addresses seems to be very well understood and > >implemented widely. The use of scope_ids with > >site-local addresses is fairly well understood, > >although not widely implemented at the moment. > > I agree for link-local addresses and said that below. Okay, glad we agree on that at least. > If we believe the concept is well defined and want > to point to Erik's draft that is fine but that draft > needs much more WG review and discussion then. Absolutely. My point was only that one method for name to site-local address resolution exists. It may not be the method the working group decides upon in the long run, but its existence shows that this is not an unsolvable problem. As an aside, I expect that there will be multiple possible methods for site administrators to choose from, depending upon whether or not they want to run a private address server of some sort. > My point is that site-local addresses will not work > without "something" else being defined and we all agree to. To be pedantic, I think you mean that name to address resolution for site-local addresses needs to be defined. The numerical addresses themselves will work even in the absence of a method for performing name to site-local address resolution. > We have not all agreed to Erik's draft and that is > a work item for this WG. Ergo the use of site-local > addresses are not well understood or implemented. I don't think that follows. They are two different issues; the lack of one doesn't imply the other. We have not all agreed on how to perform name to address resolution for link-local addresses either (Matt's draft is one possibility), but that doesn't mean that the use of link-local addresses is not well understood or implemented. > >I first want to say that I think both link-local > >and site-local addresses are wonderful concepts > >and perfectly useable for some applications > >without ever attaching names to them. > > Not. Care to elaborate? I can certainly use link-local and site-local addresses without having them correspond to some name in a database somewhere. > I agree with you they are good "concepts". > I think link-local is wonderful and was there in > the beginnning when we defined them and have put > them into a product stack. Site-Local is a > different matter and needs more discussion > for "unicast". Okay, this appears to be the core issue, or at least a core issue. I don't understand why you think site-local is a "different matter" than link-local. You mentioned name to address resolution, but we don't have working group approval of a method for doing that with link-local either. What makes link-local "wonderful", but site-local a pariah? In the interest of brevity, and because I don't believe it's one of the core issues in contention, I'm going to skip over the back-and-forth on the site-local address name resolution discussion. If someone really wants me to launch into this, let me know. Otherwise, I'll just summarize my position: I think Erik's draft will work if you want to put site-local addresses in the global DNS. I can imagine other mechanisms which will work if you want to have a "two-faced DNS" or private name service of some sort -- there just needs to be some method for the resolver to determine which site any site-specific name services it may access belongs. I don't think this is rocket science. Onward to the other core issue: > >I agree we don't have to revisit the entire notion > >of scope ids. It's the current specification of the > >getxx APIs which I think we need to revisit. > > I completely disagree. If anyone tells me we can > change the API because a draft exists that does not > IMO have wide consensus and not a lot of input and > review is a corner stone to change the existing > user interface to IPv6 for existing customers then > I will tell them this is not a wise decision, until > we have the discussion I have asked to start on this > mail thread. I think we need to revisit the API. But not because of Erik's draft or any other draft. And not just because of site-local addresses either, although that's part of it. We need to revisit it because even link-local addresses do not work with the getxx APIs as they are currently specified. Now what to do about the API is an open issue. Carl Williams (hope I have his name right) rounded up a bunch of us last Thursday to have dinner and discuss the subject. But the appropriate place to reach resolution is on this list. So I hope Carl will post his notes from that discussion as a starting point. --Brian P.S. To answer an earlier question: > >> Robert Elz's suggestion is looking > >> pretty good to me right now!!!! > > >It's a cute hack. However, I think it's dangerous > >from the standpoint that these things which aren't > >really addresses are being exposed at user-level. > >They would inevitably end up being passed around > >as data, at which point programs would start > >breaking. It's also kind of ugly and could be > >confusing to programmers. I'd rather the API was > >as clean and easy to understand as possible. > > What??? Please state why and how this would break user data? My concern is that if the API presents to the programmer this thing which is usually an address, but in the case of scoped addresses isn't really an address since it hides a scope id in there, then programs will end up being written which treat it as an address and thus break upon encountering scoped addresses. The classic example is a program that passes an IP address to another node in the application data portion of the packet. It'll work just fine for global addresses, but not scoped addresses because the hidden bits are node specific. I think it is far better to make it explicit to programmers what is going on, so they can understand it and make proper decisions, rather than hide things like this from them that can bite them later. Besides, this would also mean changing the API from what is specified now (RFC 2553 includes the sin6_scope_id field in a sockaddr_in6), so what's the win? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 16 03:04:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAGB2VT18835 for ipng-dist; Tue, 16 Nov 1999 03:02:31 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAGB2Mi18828 for ; Tue, 16 Nov 1999 03:02:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA14656 for ; Tue, 16 Nov 1999 03:02:22 -0800 (PST) From: george.tsirtsis@bt.com Received: from babelfish.axion.bt.co.uk (babelfish.axion.bt.co.uk [132.146.17.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA02452 for ; Tue, 16 Nov 1999 03:02:21 -0800 (PST) Received: from cbtlipnt02.btlabs.bt.co.uk by babelfish.axion.bt.co.uk (local) with ESMTP; Tue, 16 Nov 1999 11:01:47 +0000 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id ; Tue, 16 Nov 1999 11:01:42 -0000 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB202DBA159@mbtlipnt02.btlabs.bt.co.uk> To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com, george.tsirtsis@bt.com Subject: RE: presentation notes Date: Tue, 16 Nov 1999 11:01:37 -0000 X-Mailer: Internet Mail Service (5.5.2448.0) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Richard Draves [SMTP:richdr@microsoft.com] > Sent: Monday, November 15, 1999 11:20 PM > To: 'gtsirt@hotmail.com' > Cc: ipng@sunroof.eng.sun.com > Subject: RE: presentation notes > > Two comments - > > 1. You note that implementors and administrators might use any prefix for > translation. If the default policy table has an entry for translatable > addresses, it needs to be some standard prefix that is widely used enough > to > be worth the bother. > I agree, we need the smallest default table that will work for 99.9% of cases. > 2. The policy table is a longest-matching-prefix lookup table, so there's > no > problem with having (for example) one policy for ::/8 and another policy > for > ::/96 and another policy for ::/0. > I see, so what I suggest is the default to be: ::/96 (IPv4 compatible) have preference over ::/8 (other IPv4 embedded like mapped, Erik's translated and my NATed) Does that make sense? George > Thanks, > Rich > > > -----Original Message----- > > From: gtsirt@hotmail.com [mailto:gtsirt@hotmail.com] > > Sent: Thursday, November 11, 1999 2:33 PM > > To: Richard Draves; ipng@sunroof.eng.sun.com > > Subject: Re: presentation notes > > > > > > > > > > > > >From: Richard Draves > > >To: "'IPng List'" > > >Subject: presentation notes > > >Date: Thu, 11 Nov 1999 12:23:10 -0800 > > ... > > >There were some comments about adding an entry for > > translatable addresses, > > >lower precedence than 6to4 and v4-compatible address. That > > sounds fine to > > >me. > > > > > > > Actualy it might be more complex than that. Let me explain. > > > > Translatable addresses as defined in Erik's SIIT are: > > 0:0:0:0:FFFF:0:IPv4/96 > > > > In NAT-PT, as translatable addresses, we originally used any > > PREFIX::/96 > > (that NAT-PT inserts infront of IPv4 addresses on DNS > > replies). This is > > needed so you can have multiple NAT-PTs in a network. The > > only issue with > > the above PREFIX::/96 is that the client behind the NAT-PT CAN NOT > > distinguish it from a global IPv6 address. One alternative > > was to use Erik's > > translatable but this does not give us the ability to have > > multiple NAT-PTs. > > A middle ground is the following: > > 0:0:x:y:FFFF:0:IPv4/96 > > > > The 0:0::/8 sais that the address is embedded IPv4; the x:y > > allows for > > structure and multiple NAT-PTs and the rest is Erik's > > translatable. => the > > network can have multiple NAT-PT and the client *knows* when that if > > communicates with this address will go throuhg translation > > > > According to the table Steve presented though this would have same > > precedence with global addresses? > > I suggested that 0:0::/8 should go at the bottom (as opposed > > to just the > > 0:0:0:0:FFFF:0::/96) but this would then include the IPv4 compatible > > addresses (0::0:IPv4/96) > > > > Is there any other way to represent this? > > > > George > > > > P.S: Please note that in practice implementors and net admins > > will use > > whatever PREFIX::/96 they want. I am just trying to make a > > *recommendation* > > that helps transition and does not impact native connectivity! > > > > ______________________________________________________ > > Get Your Private, Free Email at http://www.hotmail.com > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 16 03:26:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAGBNrH18884 for ipng-dist; Tue, 16 Nov 1999 03:23:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAGBNii18877 for ; Tue, 16 Nov 1999 03:23:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA03373 for ; Tue, 16 Nov 1999 03:23:44 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA16538 for ; Tue, 16 Nov 1999 04:23:42 -0700 (MST) Received: from assan (assan.imag.fr [129.88.31.17]) by imag.imag.fr (8.9.3/8.8.5) with ESMTP id MAA16005; Tue, 16 Nov 1999 12:23:34 +0100 (MET) Message-Id: <4.2.0.58.19991116105212.00a27470@brahma.imag.fr> X-Sender: durand@brahma.imag.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 16 Nov 1999 12:16:51 +0100 To: Richard Draves From: Alain Durand Subject: RE: presentation notes Cc: "'IPng List'" In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101CA216A0@RED-MSG-50> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 15:28 15/11/99 -0800, Richard Draves wrote: > > For this reason, I think we should differentiate 6to4 and > > IPv4 compatible > > and give priority to 6to4. > >In practice, I would expect 6to4 will mostly be used to give addresses to >nodes that do not have v4 connectivity. That's the big win of 6to4. So the >vast majority of nodes with 6to4 addresses will not have v4-compatible >addresses. So this will be moot. I disagree there. My view of 6to4 is to give a global prefix to a site that can not have v6 service at the same time as v4 service from its ISP. This, regardless to the fact that you have or not enough IPv4 addresses on your hosts. Actually some hosts may have IPv4 addresses, some not. >Can you flesh out a transition scenario where giving a preference to 6to4 >addresses over v4-compatible addresses will help the transition? Let's take the example of a site where you introduce IPv6 gradually using 6to4 and IPv4 compatible techniques. The servers that will need to be accessed both from the v6 world and the v4 world are assigned a 6to4 IPv6 address, an IPv4 address (global or private), and an IPv4 compatible address. Within the same site, some subnets are v6 aware, meaning that there is an IPv6 router advertising 6to4 prefixes and some others are not, meaning that no IPv6 prefix is advertised. On those nets, IPv6 dual stack hosts may use IPv4 compatible addresses to connect to the servers. When those subnets become IPv6 aware, i.e. an IPv6 router is installed, all the sudden the dual stack hosts get a 6to4 IPv6 address on top of the IPv4 compatible one. Network admin might espect those hosts to use the address derived from this 6to4 prefix and not the IPv4 compatible address. In that case, the transition will be easier if 6to4 addresses were giving a better priority over v4 compatible. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 16 07:33:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAGFUng19075 for ipng-dist; Tue, 16 Nov 1999 07:30:49 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAGFUei19068 for ; Tue, 16 Nov 1999 07:30:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA10051 for ; Tue, 16 Nov 1999 07:30:40 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28551 for ; Tue, 16 Nov 1999 07:30:38 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 6E7EC1521DA; Tue, 16 Nov 1999 09:30:37 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 2AAF9BC4EC; Tue, 16 Nov 1999 09:30:01 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id A0188B2A44; Tue, 16 Nov 1999 09:30:00 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000006223; Tue, 16 Nov 1999 10:30:35 -0500 (EST) From: Jim Bound Message-Id: <199911161530.KAA0000006223@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , deployment@ipv6.org, ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: Re: Research Project porting Kame to Alpha In-reply-to: Your message of "Tue, 16 Nov 1999 16:29:01 +0900." <14815.942737341@coconut.itojun.org> Date: Tue, 16 Nov 1999 10:30:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Itojun...this saves me some funding money I can use elsewhere for IPv6. p.s. we are pulling your test suites over this week fyi from TAHI work. thanks again, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 16 09:44:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAGHfg019324 for ipng-dist; Tue, 16 Nov 1999 09:41:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAGHfXi19317 for ; Tue, 16 Nov 1999 09:41:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02755 for ; Tue, 16 Nov 1999 09:41:34 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18856 for ; Tue, 16 Nov 1999 09:41:32 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 491B9104C3A for ; Tue, 16 Nov 1999 11:41:30 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 3A9814FB03; Tue, 16 Nov 1999 11:41:00 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id BE6E14C902; Tue, 16 Nov 1999 11:40:59 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000011418; Tue, 16 Nov 1999 12:41:28 -0500 (EST) From: Jim Bound Message-Id: <199911161741.MAA0000011418@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: Implementing the architectural principles of Scope-IDs In-reply-to: Your message of "Tue, 16 Nov 1999 01:18:20 PST." <3D2036E25376D31197A100805FEAD892712EF7@RED-MSG-02> Date: Tue, 16 Nov 1999 12:41:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi brian, >> If we believe the concept is well defined and want >> to point to Erik's draft that is fine but that draft >> needs much more WG review and discussion then. > >Absolutely. My point was only that one method for name to site-local >address resolution exists. It may not be the method the working group >decides upon in the long run, but its existence shows that this is not an >unsolvable problem. As an aside, I expect that there will be multiple >possible methods for site administrators to choose from, depending upon >whether or not they want to run a private address server of some sort. Well I don't know about multiple possible ways. Erik's draft is a significant addition to ND and our implementations even before src addr selection. I am about ready to start a thread on Erik's draft. >> My point is that site-local addresses will not work >> without "something" else being defined and we all agree to. > >To be pedantic, I think you mean that name to address resolution for >site-local addresses needs to be defined. The numerical addresses >themselves will work even in the absence of a method for performing name to >site-local address resolution. Well Erik's draft solves my problem by saying when a site only has site-local addresses addresses for sites with site-local addresses must be in the site where the DNS exists. This is an operational restriction for DNS. I will discuss this on the other thread I will begat. >> We have not all agreed to Erik's draft and that is >> a work item for this WG. Ergo the use of site-local >> addresses are not well understood or implemented. > >I don't think that follows. They are two different issues; the lack of one >doesn't imply the other. We have not all agreed on how to perform name to >address resolution for link-local addresses either (Matt's draft is one >possibility), but that doesn't mean that the use of link-local addresses is >not well understood or implemented. The use of of site-local addresses is in the process of being defined. OK............ >> >I first want to say that I think both link-local >> >and site-local addresses are wonderful concepts >> >and perfectly useable for some applications >> >without ever attaching names to them. >> >> Not. >Care to elaborate? I can certainly use link-local and site-local addresses >without having them correspond to some name in a database somewhere. Link-Local I agree with. I don't believe they should exist in the DNS. In that sense names are unimportant for link-local addresses. They are known by the ND processes and btw adjacent router links. Site-Local are different. They will be used by applications off link. I think any address of this nature needs names. Sure it can be done without them but I don't consider that useful,. >> I agree with you they are good "concepts". >> I think link-local is wonderful and was there in >> the beginnning when we defined them and have put >> them into a product stack. Site-Local is a >> different matter and needs more discussion >> for "unicast". >Okay, this appears to be the core issue, or at least a core issue. I don't >understand why you think site-local is a "different matter" than link-local. >You mentioned name to address resolution, but we don't have working group >approval of a method for doing that with link-local either. What makes >link-local "wonderful", but site-local a pariah? The link-local address is used to get things started for IPv6 via ND or DHCPv6. It is also used for routers to communicate to adjacent links. Its an address for the IPv6 Architecture to get the node up and running and learn about its link neighbors. If folks want to telnet et al to it we can't stop them but I think that is fiat rather than by design. Also for testing. Except in the Dentist office scenario. For link-local addresses they should be key'd in via a user when used by apps or in a config file (this is OK for link-local as they are not renumbered but if privacy stuff is on then they may need to be refreshed). So I view link-local as step 1 and for the Dentist office but after that a greater address should be used for DST and SRC always for apps. Site-Local brings into the picture communicating within a site offlink instead of global addresses. It creates an addition need for scope-ids. I don't believe in private addresses - but we are stuck with them now for IPv6. I don't believe renumbering will be as frequent as Erik's draft alludes and the draft can't use them for some mobile node and home based mobile node communications either. I suggest we continue this discussion when I start the thread on Erik's latest draft. >In the interest of brevity, and because I don't believe it's one of the core >issues in contention, I'm going to skip over the back-and-forth on the >site-local address name resolution discussion. If someone really wants me >to launch into this, let me know. Otherwise, I'll just summarize my >position: I think Erik's draft will work if you want to put site-local >addresses in the global DNS. I can imagine other mechanisms which will work >if you want to have a "two-faced DNS" or private name service of some sort >-- there just needs to be some method for the resolver to determine which >site any site-specific name services it may access belongs. I don't think >this is rocket science. It requires operational rules. Any such rules must be optional. The IETF cannot mandate how we run our networks only provide the standards. We can pick this up in the thread on Eriks draft. >Onward to the other core issue: >> >I agree we don't have to revisit the entire notion >> >of scope ids. It's the current specification of the >> >getxx APIs which I think we need to revisit. >> >> I completely disagree. If anyone tells me we can >> change the API because a draft exists that does not >> IMO have wide consensus and not a lot of input and >> review is a corner stone to change the existing >> user interface to IPv6 for existing customers then >> I will tell them this is not a wise decision, until >> we have the discussion I have asked to start on this >> mail thread. >I think we need to revisit the API. But not because of Erik's draft or any >other draft. And not just because of site-local addresses either, although >that's part of it. We need to revisit it because even link-local addresses >do not work with the getxx APIs as they are currently specified. Well I don't agree. They do work. But are they working in an elegant manner. >Now what to do about the API is an open issue. Carl Williams (hope I have >his name right) rounded up a bunch of us last Thursday to have dinner and >discuss the subject. But the appropriate place to reach resolution is on >this list. So I hope Carl will post his notes from that discussion as a >starting point. Name is right. I will be sending API issues thread too. I heard about the meeting and await the notes. Erik and I were not there and need to see the results. As it appears we have to update rfc2553 I am wondering how it will look when we are done. But that is another thread. >P.S. To answer an earlier question: > >> >> Robert Elz's suggestion is looking >> >> pretty good to me right now!!!! >> >> >It's a cute hack. However, I think it's dangerous >> >from the standpoint that these things which aren't >> >really addresses are being exposed at user-level. >> >They would inevitably end up being passed around >> >as data, at which point programs would start > >breaking. It's also kind of ugly and could be > >confusing to programmers. I'd rather the API was > >as clean and easy to understand as possible. > >> What??? Please state why and how this would break user data? >My concern is that if the API presents to the programmer this thing which is >usually an address, but in the case of scoped addresses isn't really an >address since it hides a scope id in there, then programs will end up being >written which treat it as an address and thus break upon encountering scoped >addresses. The classic example is a program that passes an IP address to >another node in the application data portion of the packet. It'll work just >fine for global addresses, but not scoped addresses because the hidden bits >are node specific. I think it is far better to make it explicit to >programmers what is going on, so they can understand it and make proper >decisions, rather than hide things like this from them that can bite them >later. I think this is a thin argument against Roberts proposal. upon return from getipnodebyname(). If site-local or link-local address sockaddr_in6.sin6_scope_id = scope-id-within-address returned This is pretty simple and leaves the existing API for getipnodebyname in tact. It also permits us to do what I relayed in my example. Now: www.one.com IN A6 fec0::FUZZY::EUI www.two.com IN A6 fec0::CLEAR::EUI An app can now take advantage of the scope-id right in the address for link-local and site-local. This would also work with Erik's draft with some tweaking. >Besides, this would also mean changing the API from what is specified now >(RFC 2553 includes the sin6_scope_id field in a sockaddr_in6), so what's the >win? I show you that above. It now becomes just a clarification to getipnodebyname and getaddrinfo. No change to the API. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 16 12:26:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAGKN1p19844 for ipng-dist; Tue, 16 Nov 1999 12:23:01 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAGKMoi19837 for ; Tue, 16 Nov 1999 12:22:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA10323 for ; Tue, 16 Nov 1999 12:22:50 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA25659 for ; Tue, 16 Nov 1999 12:22:49 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 16 Nov 1999 12:10:59 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Tue, 16 Nov 1999 12:10:59 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712EF8@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Implementing the architectural principles of Scope-IDs Date: Tue, 16 Nov 1999 12:10:57 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, Okay, sounds like we should discuss the site-local issues in another thread dedicated to that topic. And I want to wait for Carl to post his notes before launching into the API issue full steam. But your last message proposed an option I hadn't considered before. Your interpretation of the proposal Robert Elz's brought back from the dead is different than mine. I recall it as *always* storing the scope id information in the extra bits of the in6_addr, even when it's part of a sockaddr_in6, and thus not having a separate sin6_scope_id field. The protocol stack would be responsible for stripping those bits out before sending the packets on the wire and adding them when packets come in. Your suggestion of just using those extra bits when passing things into and out of the getxx APIs isn't one that I'd heard before. We didn't discuss anything like this at the dinner. Using this idea as a backwards-compatible hack for dealing with getipnodebyname and getipnodebyaddr is much more palatable to me. It's still not clean, but for those wanting clean, we have getaddrinfo and getnameinfo. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 16 13:11:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAGL6ZP19923 for ipng-dist; Tue, 16 Nov 1999 13:06:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAGL6Qi19916 for ; Tue, 16 Nov 1999 13:06:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA00698 for ; Tue, 16 Nov 1999 13:06:25 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19946 for ; Tue, 16 Nov 1999 13:06:24 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 8A573151FDA for ; Tue, 16 Nov 1999 15:06:23 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 68C73BC4E9; Tue, 16 Nov 1999 15:05:47 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 06A30B2A44; Tue, 16 Nov 1999 15:05:46 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000021039; Tue, 16 Nov 1999 16:06:22 -0500 (EST) From: Jim Bound Message-Id: <199911162106.QAA0000021039@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: Implementing the architectural principles of Scope-IDs In-reply-to: Your message of "Tue, 16 Nov 1999 12:10:57 PST." <3D2036E25376D31197A100805FEAD892712EF8@RED-MSG-02> Date: Tue, 16 Nov 1999 16:06:21 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, yes. I also don't care if we leave the bits in the address either but I guess it could affect routability of sitelocal. I hope to get to the site thread this week and Erik probably does too. But its pressed as I am off on a mini hunting trip for 3 days before U.S. Thanksgiving where I hope to get my own turkey the old fashion way. But I will do my best. The other thing is I am not as anti-getaddrinfo as I may sound. I just advised one of our internal engineering teams they may infact want to use getaddrinfo for their subsystem port to the IPv6 stack which our group does. I really don't want to shoot getipnodebyname in the head unless there is no choice I do think it has its use and purpose. I also would like to use site-local addresses (if we must --)..) in the most efficient way. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 16 14:28:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAGMNX120017 for ipng-dist; Tue, 16 Nov 1999 14:23:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAGMNPi20010 for ; Tue, 16 Nov 1999 14:23:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA18993 for ; Tue, 16 Nov 1999 14:23:25 -0800 (PST) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14871 for ; Tue, 16 Nov 1999 15:23:25 -0700 (MST) Received: from localhost (rglr@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id RAA05560; Tue, 16 Nov 1999 17:22:53 -0500 (EST) Date: Tue, 16 Nov 1999 17:22:53 -0500 From: Ray LaRocca To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, ipng@sunroof.eng.sun.com, ipmembers@iol.unh.edu Subject: UNH Mobility Testing Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello All, The UNH InterOperability Lab is enhancing its IPv6 Test Suite by implementing tests for Mobility support for IPv6. We are looking for some representative implementation to assist in the final development of our tests. If you are interested in participating in this process please contact me. Regards, -Ray -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 17 10:47:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAHIiJO20888 for ipng-dist; Wed, 17 Nov 1999 10:44:19 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAHIi8i20881 for ; Wed, 17 Nov 1999 10:44:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA10746 for ; Wed, 17 Nov 1999 10:44:06 -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 LAA15012 for ; Wed, 17 Nov 1999 11:44:06 -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 MAA06489; Wed, 17 Nov 1999 12:43:35 -0600 (CST) Message-Id: <199911171843.MAA06489@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: New (last?) A6 draft submitted Date: Wed, 17 Nov 1999 12:43:35 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted draft-ietf-ipngwg-dns-lookups-06.txt to the i-d editor. The following are ALL the changes since -05: 1. Updated the silent co-authors' affiliations 2. Added a table of contents 3. Dropped ", one new query type" from the abstract, since there was no new qtype defined. 4. Changed "on" to "and" in the title of section 7. The ipngwg chairs announced a one-week last call on -05, on the understanding that fixes 3 & 4 above were still to be made. Unfortunately the last call does not seem to have been CC'd to namedroppers as it ought to have been. I have not seen any last call comments on -05. 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 Nov 17 15:46:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAHNhJn21154 for ipng-dist; Wed, 17 Nov 1999 15:43:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAHNhAi21147 for ; Wed, 17 Nov 1999 15:43:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA26662 for ; Wed, 17 Nov 1999 15:43:10 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06785 for ; Wed, 17 Nov 1999 15:43:09 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 334BB9A82C for ; Wed, 17 Nov 1999 17:43:09 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 3E2F2BC4C2; Wed, 17 Nov 1999 17:42:31 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id DFAB1B2A43 for ; Wed, 17 Nov 1999 17:42:30 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id SAA0000031684; Wed, 17 Nov 1999 18:43:08 -0500 (EST) From: Jim Bound Message-Id: <199911172343.SAA0000031684@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Textual Address Change for Scope-IDs Date: Wed, 17 Nov 1999 18:43:08 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I strongly object to the idea of changing in6_addr to contain the scope-ID as an additional character. This should not be confused with Roberts proposal of adding scope-id in SLA or such part of an IPv6 address, which I think is a very good idea. I object to be clear to stuff like: SITEAfec0::2 (where fec0 starts the address) We should use the companion field defined for this called sin6_scope_ID. To hold the scope-id. I have heard from several developers in other discussions this is a bad idea. We need to discuss the merits of this and the drawbacks. I see no merits. Drawbacks: 1. Pollutes the IPv6 address 2. Causes changes to API functions that use addresses and in XNET 3. Adds no value to the issue of resolving scope-ids. 4. Users can easily add scope-id to sys cmds like ifconfig 5. Lots of others but I will stop for now. Comments either way please, but we need to discuss this as its own thread. thanks /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 Wed Nov 17 17:54:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAI1oZN21296 for ipng-dist; Wed, 17 Nov 1999 17:50:36 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAI1oPi21289 for ; Wed, 17 Nov 1999 17:50:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA19850 for ; Wed, 17 Nov 1999 17:50:25 -0800 (PST) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA10448 for ; Wed, 17 Nov 1999 18:50:24 -0700 (MST) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 17 Nov 1999 17:45:43 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Nov 1999 17:45:43 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F07@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Wed, 17 Nov 1999 17:45:40 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Could you rephrase this please? I don't understand what position you are taking. The subject line is about textual address representation, but then you talk about the binary representation (in6_addr, sin6_scope_id, the proposal Robert Elz resurrected, etc) with what appears to be a bit of textual representation thrown in. Thanks, --Brian > -----Original Message----- > From: Jim Bound [mailto:bound@zk3.dec.com] > Sent: Wednesday, November 17, 1999 15:43 > To: ipng@sunroof.eng.sun.com > Subject: Textual Address Change for Scope-IDs > > > Folks, > > I strongly object to the idea of changing in6_addr to contain the > scope-ID as an additional character. This should not be confused with > Roberts proposal of adding scope-id in SLA or such part of an IPv6 > address, which I think is a very good idea. > > I object to be clear to stuff like: > > SITEAfec0::2 (where fec0 starts the address) > > We should use the companion field defined for this called > sin6_scope_ID. > To hold the scope-id. > > I have heard from several developers in other discussions > this is a bad > idea. > > We need to discuss the merits of this and the drawbacks. > > I see no merits. > > Drawbacks: > 1. Pollutes the IPv6 address > 2. Causes changes to API functions that use addresses and in XNET > 3. Adds no value to the issue of resolving scope-ids. > 4. Users can easily add scope-id to sys cmds like ifconfig > 5. Lots of others but I will stop for now. > > Comments either way please, but we need to discuss this as its own > thread. > > thanks > /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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 18 03:56:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAIBrB421552 for ipng-dist; Thu, 18 Nov 1999 03:53:11 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAIBr0i21545 for ; Thu, 18 Nov 1999 03:53:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA04806 for ; Thu, 18 Nov 1999 03:53:00 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05384 for ; Thu, 18 Nov 1999 04:52:59 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17773; Thu, 18 Nov 1999 06:52:53 -0500 (EST) Message-Id: <199911181152.GAA17773@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-dns-lookups-06.txt Date: Thu, 18 Nov 1999 06:52:47 -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 : DNS Extensions to Support IPv6 Address Aggregation and Renumbering Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-06.txt Pages : 18 Date : 17-Nov-99 This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-dns-lookups-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991117134115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-lookups-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991117134115.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 18 10:57:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAIIscV21934 for ipng-dist; Thu, 18 Nov 1999 10:54:38 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAIIsXi21927 for ; Thu, 18 Nov 1999 10:54:34 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA16166 for ipng@sunroof.eng.sun.com; Thu, 18 Nov 1999 10:54:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAIEKdi21625 for ; Thu, 18 Nov 1999 06:20:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA03661 for ; Thu, 18 Nov 1999 06:20:40 -0800 (PST) From: tkuiper@tobit.com Received: from mail.tobit.com (tobit.com [62.52.80.126]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA14664 for ; Thu, 18 Nov 1999 06:20:38 -0800 (PST) Message-Id: <199911181420.GAA14664@venus.Sun.COM> Subject: Fun with Novell and IPv6 To: ipng@sunroof.eng.sun.com Date: 18 Nov 99 14:20:38 UT X-Priority: 3 (Normal) Importance: normal X-Mailer: David by Tobit Software, Germany (PM-6.00a (0162)) X-David-Sym: 0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1DD2510B41FE" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------1DD2510B41FE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Since I try to get IPv6 running with Netware (its one of the main reasons I try IPv6 here and connected to 6bone) I tried once again to find someone who could tell me about a Novell Netware implementation for IPv6. So I tried forums.novell.com (NNTP). I can only see this issue with a bit sarcasm, but, read ahead. Subject: No IPv6 for Netware? Date: Wed, 17 Nov 1999 09:49:18 +0100 From: Thomas Kuiper Organization: Tobit Software Newsgroups: novell.generaltcpip Hi, I've been looking around for a Netware IPv6 Stack but couldn't find it either on Netware 5 or somewhere on the Novell site. Are there any IPv6 implementations for Netware? On http://developer.novell.com/research/appnotes/1997/march/03/04.htm its noted that there is "going to be" support for it in the next generation of products (Netware 5?). Also NTP is mentioned there as upcoming feature, but I didn't find IP Security/NTP or IPv6 inside Netware 5. Best regards, Thomas Kuiper ~~~~ First reply: Subject: Re: No IPv6 for Netware? Date: Wed, 17 Nov 1999 08:29:34 -0500 From: Michael Bell Organization: Novell Support Connection Forums Newsgroups: novell.generaltcpip NTP is built into TIMESYNC as of SP1 or 2. IPv6 -- no, I think this is still not available. Michael J. Bell Novell Support Connection Volunteer Sysop ~~~~ Second reply: Subject: Re: No IPv6 for Netware? Date: Wed, 17 Nov 1999 08:56:23 EST From: Joseph Moore [SysOp] Organization: Novell Support Connection Forums Newsgroups: novell.generaltcpip I don't think IPv6 is available for NetWare yet. Joe Moore Novell Support Connection Volunteer Sysop http://www.joenettroll.net/network.html http://www.planetall.com/main.asp?s=3D1043&cid=3D223904 http://www.planetall.com/main.asp?cid=3D223904&gid=3D40734&s=3D40 NO EMAIL PLEASE!!!!! ~~~~ Third reply: Subject: Re: No IPv6 for Netware? Date: Wed, 17 Nov 1999 20:21:29 -0700 From: Craig Johnson Organization: Novell Support Connection Forums Newsgroups: novell.generaltcpip Ipv6 isn't there yet. I believe that is still 'in development'. Craig Johnson Novell Support Connection SysOp ~~~~~~~~~~~~~~~~~~ cut here ~~~~~~~~~~~~~~~~~~~~~~~~~ so I thought: wow, hm, 2 support guys of Novell say "I *think* its not done yet" and one says "I BELIEVE(!) its in development", lets ask them for a time. So I wrote: Subject: Re: No IPv6 for Netware? Date: Wed, 17 Nov 1999 15:53:04 +0100 From: Thomas Kuiper Organization: Tobit Software Newsgroups: novell.generaltcpip I really would like to know but nobody at Novell could tell me this. There are the specs... ~~~~ and the best reply I have ever seen from a support guy: Subject: Re: No IPv6 for Netware? Date: Thu, 18 Nov 1999 06:00:08 EST From: Joseph Moore [SysOp] Organization: Novell Support Connection Forums Newsgroups: novell.generaltcpip Thomas Kuiper : Well, none of us work for Novell...so we don't know either. Joe Moore Novell Support Connection Volunteer Sysop http://www.joenettroll.net/network.html http://www.planetall.com/main.asp?s=3D1043&cid=3D223904 http://www.planetall.com/main.asp?cid=3D223904&gid=3D40734&s=3D40 NO EMAIL PLEASE!!!!! ~~~~~~~~~~~~~~~~~~ cut here ~~~~~~~~~~~~~~~~~~~~~~~~~ why couldn't they say that in the first place :( Novell has a contact listed about IPv6 on: http://playground.sun.com/ipng/ipng-implementations.html#Novell if you try to mail him postmaster@novell.com sends you back that andy@novell.com isn't valid anymore :-< So IPv6 got dropped at all now at Novell or what? Only one document from 1997 on their server telling it will be availiable "in a future release". I'm lost now. It would be really wonderfull if someone could tell me what is going on at Novell with IPv6. Gruss/Regards, Thomas Thomas Kuiper | tkuiper@tobit.com | www.tobit.com __ Core Development | TK3680-RIPE | /__/\ Tobit Software GmbH | ICQ #8345483 | ask your server. \__\/ To: join@uni-muenster.de ipng@sunroof.eng.sun.com 6bone@isi.edu Cc: jokes@irc.ircnet.dk dv@engerim.dachbu.de --------------1DD2510B41FE-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 18 11:24:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAIJLCm21997 for ipng-dist; Thu, 18 Nov 1999 11:21:12 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAIJL7i21990 for ; Thu, 18 Nov 1999 11:21:07 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA16262 for ipng@sunroof.eng.sun.com; Thu, 18 Nov 1999 11:20:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAIJHqi21974 for ; Thu, 18 Nov 1999 11:18:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA26471 for ; Thu, 18 Nov 1999 11:17:51 -0800 (PST) From: miyakawa@nttmcl.com Received: from wholefoods.nttmcl.com (wholefoods.nttmcl.com [216.69.70.134]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00975 for ; Thu, 18 Nov 1999 12:17:51 -0700 (MST) Received: from localhost by wholefoods.nttmcl.com (8.9.0/3.5W(96/10/22)) id LAA21405 for ; Thu, 18 Nov 1999 11:17:33 -0800 (PST) To: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Wed, 17 Nov 1999 18:43:08 -0500" <199911172343.SAA0000031684@quarry.zk3.dec.com> References: <199911172343.SAA0000031684@quarry.zk3.dec.com> X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991118111733B.miyakawa@wholefoods.nttmcl.com> Date: Thu, 18 Nov 1999 11:17:33 -0800 X-Dispatcher: imput version 980905(IM100) Lines: 51 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IPv6 specialists, In article <199911172343.SAA0000031684@quarry.zk3.dec.com>, Mr.Jim Bound writes: >I strongly object to the idea of changing in6_addr to contain the >scope-ID as an additional character. If you mention about Jinmei-Onoe's draft-ietf-ipngwg-scopedaddr-format-00.txt, I think it does not propose such a thing. But it says just that "Let's unify scoped address expressions for commands and their results. The proposal is 'sockaddr_in6 sin6_scope_id'". That's all. As you mentioned, > 4. Users can easily add scope-id to sys cmds like ifconfig Yes, I think so too. But, still it's very inconvinient if command parameters and return values use different expressions for that, isn't it ? We should employ one unique notation to express scoped addresses in results of "netstat -rn", command line parameters of telnet, ftp, route, ......, not just only for UNIX like environments but router configurations, SMTP (maybe)..... and so on. to make our operations EASY. So, Mr.Bound, I think you could agree with that idea. I really hope that everyone agrees with this point, too. Regards, Shin MIYAKAWA, Ph.D Research Lead, Internet Technologies NTT Multimedia Communications Laboratories PaloAlto, CA, USA P.S. As a staff belongs to one of ISPs who are seriously considering about IPv6, I will strongly recommend to take care about these things (using some unified expression) when our BUSINESS sectors ask me to comment about PURCHASING IPv6 equipments. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 18 16:28:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJ0Q9t22368 for ipng-dist; Thu, 18 Nov 1999 16:26:09 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJ0Pvi22361 for ; Thu, 18 Nov 1999 16:25:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA10118 for ; Thu, 18 Nov 1999 16:25:57 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21929 for ; Thu, 18 Nov 1999 16:25:56 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 632489A956; Thu, 18 Nov 1999 18:25:56 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id AB84BBC4D9; Thu, 18 Nov 1999 18:25:50 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 41F60B2A42; Thu, 18 Nov 1999 18:25:50 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id TAA0000014671; Thu, 18 Nov 1999 19:25:54 -0500 (EST) From: Jim Bound Message-Id: <199911190025.TAA0000014671@quarry.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: New (last?) A6 draft submitted In-reply-to: Your message of "Wed, 17 Nov 1999 12:43:35 CST." <199911171843.MAA06489@gungnir.fnal.gov> Date: Thu, 18 Nov 1999 19:25:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, I don't want to hold up a last call. But one thing I have heard from implementors of the draft for BIND is that the depth of the chains for A6 records can cause some issues for performance and partial addresses which cannot be returned. The discussion among implementors of this is that we probably need some operational statements regarding the use of A6 records. I think that is a separate draft personally and this should move forward, but wanted to send in this thought. /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 Thu Nov 18 18:02:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJ1xP622439 for ipng-dist; Thu, 18 Nov 1999 17:59:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJ1xHi22432 for ; Thu, 18 Nov 1999 17:59:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA17386 for ; Thu, 18 Nov 1999 17:59:17 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24506 for ; Thu, 18 Nov 1999 17:59:16 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 551D157A79; Thu, 18 Nov 1999 19:59:16 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id A5378BC4CB; Thu, 18 Nov 1999 19:59:10 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 4AACEB2A43; Thu, 18 Nov 1999 19:59:10 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id UAA0000002433; Thu, 18 Nov 1999 20:59:15 -0500 (EST) From: Jim Bound Message-Id: <199911190159.UAA0000002433@quarry.zk3.dec.com> To: miyakawa@nttmcl.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Thu, 18 Nov 1999 11:17:33 PST." <19991118111733B.miyakawa@wholefoods.nttmcl.com> Date: Thu, 18 Nov 1999 20:59:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi shin, no I was not referring to the draft. I was referring to conversations I heard and some mail during the discussion of the draft. I agree with you sent me too. thanks /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 Thu Nov 18 18:26:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJ2NoO22474 for ipng-dist; Thu, 18 Nov 1999 18:23:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJ2Nfi22467 for ; Thu, 18 Nov 1999 18:23:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA01705 for ; Thu, 18 Nov 1999 18:23:41 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01700 for ; Thu, 18 Nov 1999 18:23:41 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id BCD10104D80 for ; Thu, 18 Nov 1999 20:23:40 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 14B484FB16; Thu, 18 Nov 1999 20:23:35 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id B5D684C904; Thu, 18 Nov 1999 20:23:34 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id VAA0000007115; Thu, 18 Nov 1999 21:23:39 -0500 (EST) From: Jim Bound Message-Id: <199911190223.VAA0000007115@quarry.zk3.dec.com> To: Brian Zill Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Wed, 17 Nov 1999 17:45:40 PST." <3D2036E25376D31197A100805FEAD892712F07@RED-MSG-02> Date: Thu, 18 Nov 1999 21:23:39 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi brian, I don't want to see our std text representation of addresses contain scope-ids. A previous mail from Shin seemed to parse my issue fine. I don't want to see inet_ntop or inet_pton changed at this point in time. They are deployed and in BIND production nodes today. /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 Thu Nov 18 23:31:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJ7S9T22567 for ipng-dist; Thu, 18 Nov 1999 23:28:09 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJ7Rvi22560 for ; Thu, 18 Nov 1999 23:27:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA17204 for ; Thu, 18 Nov 1999 23:27:58 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA23145 for ; Fri, 19 Nov 1999 00:27:57 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 18 Nov 1999 23:25:30 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Nov 1999 23:25:30 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F0C@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Thu, 18 Nov 1999 23:25:28 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry Jim, but it still looks to me that you're contradicting yourself. You tell me: > I don't want to see our std text representation > of addresses contain scope-ids. You tell Shin: > no I was not referring to the draft. I was > referring to conversations I heard and some mail > during the discussion of the draft. > > I agree with you sent me too. These two statements are contradictory. The draft is about what the standard form of text representation should be for scoped addresses. It assumes as a basic principle that there should be one. So if you agree with what Shin sent, does that mean you agree with his statement "We should employ one unique notation to express scoped addresses in [long list of examples]" If so, then I don't understand what it is that you heard or saw discussed that you don't agree with (regarding textual representation). On the other hand, if you're saying that we shouldn't have a standard notation for expressing scoped addresses, than I disagree with you. I agree with the draft that there should be one, my only nit is that I believe the scope id should come first, not last. This is for two reasons (1) to avoid colliding with the common way of writing prefix lengths (address/prefix-length) and (2) IPv6 addresses are big-endian, so it is more consistent for the scope id to come first. So for scoped addresses, I think it should be " ". For global addresses, you'd only have the "" part. > I don't want to see inet_ntop or inet_pton changed at this point in > time. They are deployed and in BIND production nodes today. Well, this is back to the API issue again, and I thought we were trying to stick to one issue per subject line. I believe that there are solutions to the API problem that don't involve changing inet_ntop or inet_pton. But I'll leave that for the API discussion. --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 Nov 18 23:57:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJ7sOD22608 for ipng-dist; Thu, 18 Nov 1999 23:54:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJ7sEi22601 for ; Thu, 18 Nov 1999 23:54:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA18392; Thu, 18 Nov 1999 23:54:13 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA27780; Fri, 19 Nov 1999 00:54:11 -0700 (MST) 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 QAA22859; Fri, 19 Nov 1999 16:53:28 +0900 (JST) To: matt@3am-software.com, erik.nordmark@eng.sun.com cc: ipng@sunroof.eng.sun.com Subject: 2292bis comment X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: itojun@iijlab.net Date: Fri, 19 Nov 1999 16:53:28 +0900 Message-ID: <22857.942998008@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a comment about 2292bis-01, chapter 3.2 (ICMPv6 filter). What is the semantics of raw socket with ICMPv6 filter? I can imagine several interpretations: a. it will throw any ICMPv6 packet to the userland, regardless of ICMPv6 checksum nor any validation failure. b. it will throw ICMPv6 packet to the userland, only if it passes ICMPv6 checksum check. the kernel does not do further validations. c. it will throw ICMPv6 packet to the userland, only if it looks completely okay to the kernel (checksum is okay and all validations are passed). Since: - it is raw socket, and - we have IPV6_CHECKSUM automatically turned on I think it would be (b) or (c), not (a). what is the position of the authors? I would like to see clarification to help userland programmers. 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 Nov 19 07:40:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJFcXR22824 for ipng-dist; Fri, 19 Nov 1999 07:38:33 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJFcPi22817 for ; Fri, 19 Nov 1999 07:38:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA03502 for ; Fri, 19 Nov 1999 07:38:24 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14627 for ; Fri, 19 Nov 1999 07:38:24 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 2D05D1522A5 for ; Fri, 19 Nov 1999 09:38:24 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 2F046BC4C4; Fri, 19 Nov 1999 09:38:18 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id C0CF7B2A42; Fri, 19 Nov 1999 09:38:17 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000013165; Fri, 19 Nov 1999 10:38:22 -0500 (EST) From: Jim Bound Message-Id: <199911191538.KAA0000013165@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Thu, 18 Nov 1999 23:25:28 PST." <3D2036E25376D31197A100805FEAD892712F0C@RED-MSG-02> Date: Fri, 19 Nov 1999 10:38:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk brian, Ok thanks for keeping on this. I guess I don't agree with Shin and now see the source of my confusion and what I disagree with. I think any input to anything with scope-id should be put in sin6_scope ID field first. I think now we all agree with that it should not be part of the IPv6 address. For some reason I thought some were proposing this. But if I want to use infconfig for scoped addresses as an example to discuss this beast. It should be keyed in as follows: ifconfig fe80::1 FUZZY le0 NOT ifconfig fe80::1|FUZZY le0 I also don't believe any strings passing around ipv6+scope-ids should exist like the above. I think scope-ids should be kept distinct and separate. So I do not support Shin's draft then and think it is not necessary. I thought they wanted be able to identify the next field with a delimiter separately like: ifconfig fe80::1 | FUZZY le0 Where "|" tells an application parsing the above that following this is the scope-id. Which I would agree to. /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 Nov 19 07:45:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJFi5622846 for ipng-dist; Fri, 19 Nov 1999 07:44:05 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJFhui22839 for ; Fri, 19 Nov 1999 07:43:56 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA04936 for ; Fri, 19 Nov 1999 07:43:56 -0800 (PST) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17122 for ; Fri, 19 Nov 1999 07:43:55 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp1.ntcom.nortel.net; Fri, 19 Nov 1999 10:43:20 -0500 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XA9D93R5; Fri, 19 Nov 1999 10:43:20 -0500 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VZWDXJVT; Fri, 19 Nov 1999 10:43:18 -0500 Message-ID: <38356F69.3FB441F6@nortelnetworks.com> Date: Fri, 19 Nov 1999 10:40:25 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Updated Scoped Routing draft Content-Type: multipart/mixed; boundary="------------E2A35A155A25869FA0F1F632" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------E2A35A155A25869FA0F1F632 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I have just submitted the following draft to the I-D editor. Please direct comments to me or the mailing list. -- Brian Haberman Advanced Network Research Nortel Networks haberman@nortelnetworks.com --------------E2A35A155A25869FA0F1F632 Content-Type: text/plain; charset=us-ascii; name="rtg-site.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="rtg-site.txt" IPNGWG Working Group B. Haberman Internet Draft Nortel Networks draft-ietf-ipngwg-scoped-routing-02.txt November 1999 Expires May 2000 Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document outlines a mechanism for generating forwarding tables that include scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward packets addressed to scoped unicast or multicast addresses regardless of the routing protocol. These rules apply to all scoped addresses. 1. Introduction This document defines a set of rules for the generation of forwarding table entries for scoped addresses. These rules will describe the handling of scoped addresses for both single site and site boundary routers. These rules apply to all routing protocols that support IPv6 addresses. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Assumptions and Definitions This document makes several assumptions concerning sites: - Links belong to at most one site - Interfaces belong to the site of the attached link, if any Haberman 1 Internet Draft Routing of Scoped IPv6 Addresses November 1999 - Nodes are a part of all sites which their interfaces belong to, and no other sites - Site boundaries are identical for unicast and multicast traffic - A single interface can be in at most one site - Each interface participating in a site has a site identifier - In the absence of explicit configuration, all site identifiers on a node default to the same value A single site router is defined as a router configured with the same site identifier on all interfaces. A site boundary router is defined as a router that has at least 2 distinct site identifiers. * * * * * Site ID = X * * * +-*---|-------|---*-+ | * i/f 1 i/f 2 * | | *************** | | | | | | Router | ******************* ******************* | * * | Site ID = Y -i/f 3 * * i/f 4- Site ID = Default | * * | ******************* ******************* +-------------------+ Figure 1: Multi-Sited Router 3. Single Site Routing In a single site router, a routing protocol can advertise and route all addresses and prefixes, except the link-local prefixes, on all interfaces. This configuration does not require any special handling for site local addresses. The reception and transmission of site local addresses is handled in the same manner as globally scoped addresses. This applies to both unicast and multicast routing protocols. 4. Site Boundary Unicast Routing With respect to site boundaries, routers must consider which interfaces a packet can be transmitted on as well as control the propagation of routing information specific to the site. This includes controlling which prefixes can be advertised on an interface. 4.1 Routing Protocols When a routing protocol determines that it is a site boundary router, it must perform additional work in order to protect inter site integrity and still maintain intra site connectivity. Haberman 2 Internet Draft Routing of Scoped IPv6 Addresses November 1999 In order to maintain connectivity, the routing protocol must be able to create forwarding information for the global prefixes as well as for all of the site prefixes for each of its attached sites. The most straightforward way of doing this is to create up to (n+1) forwarding tables; one for the global prefixes, if any, and one for each of the (n) sites. To protect inter site integrity; routers must be selective in the forwarding information that is shared with neighboring routers. Routing protocols routinely transmit their routing information to its neighboring routers. When a router is transmitting this routing information, it must not include any information about sites other than the site defined on the interface used to reach a neighbor. As an example, the router in Figure 1 must advertise routing information on four interfaces. The information advertised is as follows: - Interface 1 - All global prefixes - All site prefixes learned from Interfaces 1 and 2 - Interface 2 - All global prefixes - All site prefixes learned from Interfaces 1 and 2 - Interface 3 - All global prefixes - All site prefixes learned from Interface 3 - Interface 4 - All global prefixes - No site prefixes By imposing advertisement rules, site integrity is maintained by keeping all site routing information contained within the site. 4.2 Packet Forwarding In addition to the extra cost of generating additional forwarding information for each site, site boundary routers must also do some additional checking when forwarding packets that contain site local addresses. If a packet being forwarded contains a site local destination address, regardless of the scope of the source address, the router must perform the following: - Lookup incoming interface's site identifier - Perform route lookup for destination address in arrival interface's site scoped routing table If a packet being forwarded contains a site local source address and a global scoped destination address, the following must be performed: - Lookup outgoing interface's site identifier - Compare inbound and outbound interfaces' site identifiers If the site identifiers match, the packet can be forwarded. If they do not match, an ICMPv6 destination unreachable message must be sent to Haberman 3 Internet Draft Routing of Scoped IPv6 Addresses November 1999 the sender with a code value, code = 2 (beyond scope of source address). 5. Scoped Multicast Routing With IPv6 multicast, there are multiple scopes supported. Multicast routers must be able to control the propagation of scoped packets based on administratively configured boundaries. 5.1 Routing Protocols Multicast routing protocols must follow the same rules as the unicast protocols. They will be required to maintain information about global prefixes as well as information about all scope boundaries that exist on the router. Multicast protocols that rely on underlying unicast protocols for route exchange (i.e. PIM, MOSPF) will not suffer as much of a performance impact since the unicast protocol will handle the forwarding table generation. They must be able to handle the additional scope boundaries used in multicast addresses. Multicast protocols that generate and maintain their own routing tables will have to perform the additional route calculations for scope boundaries. All multicast protocols will be forced to handle fourteen additional scooping identifiers above the site identifiers supported in IPv6 unicast addresses. 5.2 Packet Forwarding The following combinations describe the forwarding rules for multicast: - Global multicast destination / Global unicast source - Global multicast destination / Site local unicast source - Scoped multicast destination / Global unicast source - Scoped multicast destination / Site local unicast source The first combination requires no special processing over what is currently in place for global IPv6 multicast. The remaining combinations should result in the router performing the same identifiers check as outlined for the site local unicast addresses. Since IPv6 multicast supports fifteen unique multicast scopes, it is assumed that scopes 0x1 through 0x4 are strictly less than the unicast site scope, scope 0x5 (site) is equal to the unicast site scope, scopes 0x6 through 0xd are strictly greater than the unicast site scope and strictly less than the unicast global scope, and scope 0xe is equal to the unicast global scope. 6. Protocol Impact The performance impact on routing protocols is obvious. Routers implementing scoped address support will be forced to perform an additional check in the main forwarding path to determine if the source address is a site-local address. This will add overhead to the processing of every packet flowing through the router. In addition, Haberman 4 Internet Draft Routing of Scoped IPv6 Addresses November 1999 there will be some storage overhead for the scope identifiers. If scoped addresses are going to be realized, this performance impact may be acceptable. 7. Security Considerations This document specifies a set of guidelines that allow routers to prevent site-specific information from leaking out of each site. If site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised. 8. References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1999. Acknowledgements The author would like to thank Thomas Narten, Steve Deering, Erik Nordmark, and Matt Crawford for their comments and reviews of this document. Haberman 5 Author's Address Brian Haberman Nortel Networks 4309 Emperor Blvd. Suite 200 Durham, NC 27703 1-919-992-4439 Email : haberman@nortelnetworks.com Haberman 6 --------------E2A35A155A25869FA0F1F632-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 19 09:59:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJHupF23132 for ipng-dist; Fri, 19 Nov 1999 09:56:51 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJHudi23125 for ; Fri, 19 Nov 1999 09:56:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA14864 for ; Fri, 19 Nov 1999 09:56:38 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA17855 for ; Fri, 19 Nov 1999 10:56:37 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 19 Nov 1999 09:54:51 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Fri, 19 Nov 1999 09:54:51 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F0D@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Fri, 19 Nov 1999 09:54:40 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, Thanks for clarifying your position. > I think any input to anything with scope-id > should be put in sin6_scope ID field first. > I think now we all agree with that it should > not be part of the IPv6 address. I believe that in user-space, when an IPv6 endpoint is stored as a binary, that the scope id should be in its own field (aka sin6_scope_id). The 128 bit IPv6 "address" should be in a separate field (aka sin6_addr). So I think we agree on this. > For some reason I thought some were > proposing this. Well, the common interpretation of the old proposal that Robert Elz recently brought back up is that you would merge the scope id information into the sin6_addr field and everywhere else you used a in6_addr. I'm against this, because I think it would be too confusing to programmers. > But if I want to use infconfig for scoped addresses as an example to > discuss this beast. It should be keyed in as follows: > > ifconfig fe80::1 FUZZY le0 > > NOT > > ifconfig fe80::1|FUZZY le0 > > I also don't believe any strings passing around ipv6+scope-ids should > exist like the above. Here I disagree with you. I think it is inevitable that people will want to put these two together since a scoped address isn't complete without its corresponding scope id. At least two existing implementations already do have such textual representations, and (unfortunately) use a different format. So I think something like the Jinmei/Onoe draft (it's not Shin's draft, he was just commenting on it) is needed. Otherwise we'll end up with everybody having their own representation. > So I do not support Shin's draft then > and think it is not necessary. I > thought they wanted be able to identify > the next field with a delimiter > separately like: > > ifconfig fe80::1 | FUZZY le0 > > Where "|" tells an application parsing the > above that following this is the scope-id. > Which I would agree to. But this is logically the same thing! It's just a delimiter that contains spaces. Personally, I think it's easier on parsers for us to choose a delimiter that doesn't contain spaces. --Brian > > /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 Nov 19 10:20:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJIEul23196 for ipng-dist; Fri, 19 Nov 1999 10:14:56 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJIEki23189 for ; Fri, 19 Nov 1999 10:14:46 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA18691 for ; Fri, 19 Nov 1999 10:14:45 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27386 for ; Fri, 19 Nov 1999 10:14:44 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 713CD152166 for ; Fri, 19 Nov 1999 12:14:44 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id AE8CE4FB16; Fri, 19 Nov 1999 12:14:38 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 51C6E4C904; Fri, 19 Nov 1999 12:14:38 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000019813; Fri, 19 Nov 1999 13:14:42 -0500 (EST) From: Jim Bound Message-Id: <199911191814.NAA0000019813@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Fri, 19 Nov 1999 09:54:40 PST." <3D2036E25376D31197A100805FEAD892712F0D@RED-MSG-02> Date: Fri, 19 Nov 1999 13:14:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk no big deal we just disagree... what do others think??? I will go with consensus as always... but I don't wnat to change inet_ntop or inet_pton if we go down this path we need new apis. but thats Ok as I already know I am going to have to do update to rfc2553 I think... but we can't break existing implementations when it happens. I will bring up roberts idea again when we discuss eriks site prefix draft. /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 Nov 19 13:35:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAJLVNN23446 for ipng-dist; Fri, 19 Nov 1999 13:31:23 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAJLVCi23439 for ; Fri, 19 Nov 1999 13:31:13 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA534690; Fri, 19 Nov 1999 13:31:09 -0800 (PST) Date: Fri, 19 Nov 1999 13:31:08 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 2292bis comment To: itojun@iijlab.net Cc: matt@3am-software.com, erik.nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <22857.942998008@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have a comment about 2292bis-01, chapter 3.2 (ICMPv6 filter). > What is the semantics of raw socket with ICMPv6 filter? > I can imagine several interpretations: > a. it will throw any ICMPv6 packet to the userland, regardless of > ICMPv6 checksum nor any validation failure. > b. it will throw ICMPv6 packet to the userland, only if it > passes ICMPv6 checksum check. the kernel does not do further > validations. > c. it will throw ICMPv6 packet to the userland, only if it looks > completely okay to the kernel (checksum is okay and all validations > are passed). b) makes the most sense to me. "All validations" can not be true in general since it requires the kernel to know about all future ICMP based protocols, which is impossible. You could say e.g. "all validations for icmp types ..." but that would be different for different implementations. Thus from the perspective of the application it can not assume that the protocol stack knows about a particular ICMP type thus it must do the validation checks in the application. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 19 18:02:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAK1xdo23703 for ipng-dist; Fri, 19 Nov 1999 17:59:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAK1xTi23696 for ; Fri, 19 Nov 1999 17:59:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA10780 for ; Fri, 19 Nov 1999 17:59:28 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02720 for ; Fri, 19 Nov 1999 17:59:28 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA18592; Fri, 19 Nov 1999 17:52:09 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id RAA24853; Fri, 19 Nov 1999 17:52:09 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id RAA00791; Fri, 19 Nov 1999 17:53:06 -0800 (PST) Date: Fri, 19 Nov 1999 17:53:06 -0800 (PST) From: Tim Hartrick Message-Id: <199911200153.RAA00791@feller.mentat.com> To: bzill@microsoft.com, bound@zk3.dec.com Subject: Re: Textual Address Change for Scope-IDs Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > what do others think??? > I am convinced that some additional textual notation is required. I thought so when we had the last jihad on scoped addresses. The issue just got drowned out in all the other discussion. I have not yet formed an opinion as to what that notation should be. > I will go with consensus as always... > > but I don't wnat to change inet_ntop or inet_pton > In my opinion the interfaces to these two routines can and should remain the same. The code which implements inet_pton might need to be enhanced to parse over the scope-id notation. That could be left to vendors' descretion since not all vendors need to support the notation immediately. > if we go down this path we need new apis. > Probably. > but thats Ok as I already know I am going to have to do update to > rfc2553 I think... but we can't break existing implementations when it > happens. > That would be the goal. Clearly, breaking binaries is bad. > I will bring up roberts idea again when we discuss eriks site prefix > draft. > I kind of wish you wouldn't since it was such a lovely cat fight when we discussed this three years ago and discarded it as an option.:-) Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 19 21:24:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) id dAK5L4s23799 for ipng-dist; Fri, 19 Nov 1999 21:21:04 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta6+Sun/8.10.0.Beta6) with ESMTP id dAK5Kti23792 for ; Fri, 19 Nov 1999 21:20:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA24472 for ; Fri, 19 Nov 1999 21:20:54 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA12806 for ; Fri, 19 Nov 1999 21:20:52 -0800 (PST) Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Sat, 20 Nov 1999 10:47:04 +0530 Received: from muralia.future.futsoft.com ([10.0.14.41]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA00803 for ; Sat, 20 Nov 1999 10:42:38 +0530 Received: by muralia.future.futsoft.com with Microsoft Mail id <01BF3343.E9E09C20@muralia.future.futsoft.com>; Sat, 20 Nov 1999 10:42:16 +0530 Message-Id: <01BF3343.E9E09C20@muralia.future.futsoft.com> From: Murali Krishna Ch To: "ipng@sunroof.eng.sun.com" Subject: IPv6 Routing Date: Sat, 20 Nov 1999 10:42:09 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi How routing is done in IPv6? In case of IPv4 it uses a routing table and/or learns routes from Routing table. Can you please help me in understanding IPv6 routing? Pl. give me some RFCs related to it. Thanks a lot for your interest in answering this mail. cheers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 20 20:05:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL401124171 for ipng-dist; Sat, 20 Nov 1999 20:00:01 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL3xrc24164 for ; Sat, 20 Nov 1999 19:59:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA04575 for ; Sat, 20 Nov 1999 19:59:52 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12408 for ; Sat, 20 Nov 1999 19:59:52 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 09E92104BD4; Sat, 20 Nov 1999 21:59:52 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 18E8FBC4C2; Sat, 20 Nov 1999 21:59:46 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id A63C9B2A42; Sat, 20 Nov 1999 21:59:45 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000021477; Sat, 20 Nov 1999 22:59:50 -0500 (EST) From: Jim Bound Message-Id: <199911210359.WAA0000021477@quarry.zk3.dec.com> To: Tim Hartrick Cc: bzill@microsoft.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Fri, 19 Nov 1999 17:53:06 PST." <199911200153.RAA00791@feller.mentat.com> Date: Sat, 20 Nov 1999 22:59:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks tim... Not sure any of this should ever affect existing inet_nt/pt functions. if we can revisit the api yet again we can revisit roberts idea :--). It may make revisiting the api easier :---).... Or we could just bag site local addresses in ipv6 then we would have to not revisit either api or roberts idea :---) /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 Sat Nov 20 20:52:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL4luj24204 for ipng-dist; Sat, 20 Nov 1999 20:47:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL4llc24197 for ; Sat, 20 Nov 1999 20:47:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA15273 for ; Sat, 20 Nov 1999 20:47:47 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA28288 for ; Sat, 20 Nov 1999 21:47:46 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id NAA08475; Sun, 21 Nov 1999 13:35:45 +0900 (JST) Date: Sun, 21 Nov 1999 13:47:11 +0900 Message-ID: <14391.31055.510925.74466C@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bzill@microsoft.com Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs In-Reply-To: In your message of "Fri, 19 Nov 1999 09:54:40 -0800" <3D2036E25376D31197A100805FEAD892712F0D@RED-MSG-02> References: <3D2036E25376D31197A100805FEAD892712F0D@RED-MSG-02> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 62 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 19 Nov 1999 09:54:40 -0800, >>>>> Brian Zill said: >> For some reason I thought some were >> proposing this. > Well, the common interpretation of the old proposal that Robert Elz recently > brought back up is that you would merge the scope id information into the > sin6_addr field and everywhere else you used a in6_addr. I'm against this, > because I think it would be too confusing to programmers. Agreed. Merging the scope id into the sin6_addr field was used in older versions of the KAME (WIDE) IPv6 stack, which was what Robert Elz mentioned in his previous mail, but we discarded the approach (at least in the user space) because of the same reason above. >> But if I want to use infconfig for scoped addresses as an example to >> discuss this beast. It should be keyed in as follows: >> >> ifconfig fe80::1 FUZZY le0 >> >> NOT >> >> ifconfig fe80::1|FUZZY le0 >> >> I also don't believe any strings passing around ipv6+scope-ids should >> exist like the above. > Here I disagree with you. I think it is inevitable that people will want to > put these two together since a scoped address isn't complete without its > corresponding scope id. At least two existing implementations already do > have such textual representations, and (unfortunately) use a different > format. So I think something like the Jinmei/Onoe draft (it's not Shin's > draft, he was just commenting on it) is needed. Otherwise we'll end up with > everybody having their own representation. I agree with Brian. In fact, one of the motivations of our draft is to avoid an unfortunate situation that every implementation has its own (maybe different) representation and users are confused. Currently, there are at least two different representations (i.e. MSR's and KAME's), but I believe that the difference is relatively a minor issue and we can agree on a specific format. As for the API issues, the new textual representation will surely introduce some extensions or changes in the current basic and/or advanced APIs. But without the extensions, you'd modify every application that should handle scoped addresses. For example, in order to allow the ifconfig program like 'ifconfig fe80::1 FUZZY le0', you should introduce some extensions to the existing APIs or modify the ifconfig program itself. I belive the latter approach is more painful for programmers and should be avoided. We should undoubtedly ensure as much lower-compatibilty as possible when introducing such extensions to the existing APIs and applications. I'm willing to cooperate with other implementors on this point and to make an effort to accomplish this. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 20 21:24:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL5Jfl24233 for ipng-dist; Sat, 20 Nov 1999 21:19:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL5JWc24226 for ; Sat, 20 Nov 1999 21:19:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA16252 for ; Sat, 20 Nov 1999 21:19:31 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA20500 for ; Sat, 20 Nov 1999 21:19:31 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 366B357863; Sat, 20 Nov 1999 23:19:31 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 5D0214FB01; Sat, 20 Nov 1999 23:19:25 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id E5BA14C901; Sat, 20 Nov 1999 23:19:24 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000000662; Sun, 21 Nov 1999 00:19:29 -0500 (EST) From: Jim Bound Message-Id: <199911210519.AAA0000000662@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bzill@microsoft.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 13:47:11 +0900." <14391.31055.510925.74466C@condor.isl.rdc.toshiba.co.jp> Date: Sun, 21 Nov 1999 00:19:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >As for the API issues, the new textual representation will surely >introduce some extensions or changes in the current basic and/or >advanced APIs. But without the extensions, you'd modify every >application that should handle scoped addresses. For example, in order >to allow the ifconfig program like 'ifconfig fe80::1 FUZZY le0', you >should introduce some extensions to the existing APIs or modify the >ifconfig program itself. I belive the latter approach is more painful >for programmers and should be avoided. I strongly don't agree with the above and its the bottom line I am glad you articulated this so crystal clear. The way I want it as you have it above it causes no change at all to the API in that case. All that is done is we go into ifconfig and add another parameter and move it directly to sin6_scope_id. Then sockaddr_in6 is complete architecturally with this issue. What you, Brian, and Tim are doing is supporting a change to every module in the source pool that for some of us vendors has been deployed, where this is not an issue. And why if it is adopted needs a new API not additions to the existing ones. But I disagree strongly with this premise being used to concatenate the scope and the address textually. At the end of the day the scope is not useful if not entered into sin6_scope_id. There is no benefit to the code and more work to do this and is a very bad idea IMO. >We should undoubtedly ensure as much lower-compatibilty as possible >when introducing such extensions to the existing APIs and >applications. I'm willing to cooperate with other implementors on this >point and to make an effort to accomplish this. No impact to the APIs is what I am asking. /jim JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Nov 20 21:42:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL5bxp24268 for ipng-dist; Sat, 20 Nov 1999 21:37:59 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL5boc24261 for ; Sat, 20 Nov 1999 21:37:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA16809 for ; Sat, 20 Nov 1999 21:37:49 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26106 for ; Sat, 20 Nov 1999 21:37:49 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 389D69A842; Sat, 20 Nov 1999 23:37:49 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 591CEBC4C3; Sat, 20 Nov 1999 23:37:43 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id EFA63B2A42; Sat, 20 Nov 1999 23:37:42 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000003480; Sun, 21 Nov 1999 00:37:47 -0500 (EST) From: Jim Bound Message-Id: <199911210537.AAA0000003480@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 13:47:11 +0900." <14391.31055.510925.74466C@condor.isl.rdc.toshiba.co.jp> Date: Sun, 21 Nov 1999 00:37:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Where else do you see this being used besides as the user interface. I think we should discuss where this will be useful. But is it useful any place else other than the user interface? If not then this is really an implementation GUI issue only and not an IETF issue or an API issue. The sin6_scope_id should be presented within a software implementation either as its own parameter or as part of the structure sing6_scope_id. Also inet_pton and inet_ntop were invented to work with IPv6 addresses proper. If one should add a scope-id to the address in a string representation as you suggest it no longer is an IPv6 Address by any standard we have today. Hence, it should have its own API for parsing. This should not be a change to the APIs that work with IPv6 addresses. /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 Sat Nov 20 22:15:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL6DBM24305 for ipng-dist; Sat, 20 Nov 1999 22:13:11 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL6Coc24298 for ; Sat, 20 Nov 1999 22:12:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA17945 for ; Sat, 20 Nov 1999 22:12:48 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA05609 for ; Sat, 20 Nov 1999 23:12:48 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA00762; Sat, 20 Nov 1999 22:10:12 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id WAA37296; Sat, 20 Nov 1999 22:10:10 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id WAA44630; Sat, 20 Nov 1999 22:10:07 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911210610.WAA44630@bossette.engr.sgi.com> Subject: Re: Textual Address Change for Scope-IDs To: bound@zk3.dec.com (Jim Bound) Date: Sat, 20 Nov 1999 22:10:07 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911210519.AAA0000000662@quarry.zk3.dec.com> from "Jim Bound" at Nov 21, 99 00:19:29 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is another possibility which I don't think has been considered yet: Put the scope-id in the in6_addr in the same way as KAME do (did?) it, _but_ only in the binary instances of the address, never in textual representation. In other words, getipnodebyname() would give you an in6_addr with the scope-id inserted near the top of the address, but functions like inet_ntop() would ignore that byte, interpreting it as zero, so that the user never actually sees it's there. This has the following advantages: 1) Solves the problem of scope-id ambiguity of addresses created by getipnodebyname() and inet_pton(). 2) The textual representation of IPv6 addresses seen by the user (and passed around from app to app, system to system) would not contain the scope-id and would thus be completely portable, as they should be. 3) No changes to applications. 4) No changes to the API docs. 5) Doesn't break the API or ABI. I don't _think_ this exactly what KAME are doing, is it? I'm assuming not. I can't think of any disadvantages to this scheme, but I'm sure somebody else on the list can :-) Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 00:56:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL8sGi24389 for ipng-dist; Sun, 21 Nov 1999 00:54:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL8s6c24382 for ; Sun, 21 Nov 1999 00:54:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA22564 for ; Sun, 21 Nov 1999 00:54:06 -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 AAA23237 for ; Sun, 21 Nov 1999 00:54:05 -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 RAA18254; Sun, 21 Nov 1999 17:52:26 +0900 (JST) To: Jim Bound cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Sun, 21 Nov 1999 00:37:46 EST. <199911210537.AAA0000003480@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Sun, 21 Nov 1999 17:52:25 +0900 Message-ID: <18252.943174345@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Where else do you see this being used besides as the user interface. >I think we should discuss where this will be useful. >But is it useful any place else other than the user interface? Jim, I think you are not getting the reason why jinmei came up with the draft. Please read the following and share the problem with us. It is very long, but please read it patiently (I really hoped you to be present at 2nd ipng slot...). Sorry for possible typos and grammatical mistakes, I tried my best. (I tend to believe that internet-draft should provide more background information that lead us to the resulting specification. Currently drafts tend to describe resulting specification only...) itojun *** >From now on, please forget about DNS or other FQDN-to-address mapping. All we have is numeric text representation - like we are in dentist's office. *** If you have a node with multiple interface/scope, sin6_scope_id is *required* to disambiguate two scope instances ("zones" in Steve's terminology). For example, if your node have two interfaces, and would like to throw a packet to fe80::x, you MUST disambiguate it somehow. Because of the design of link-local scope, fe80::x can be on both sides, and they can be different node. Probabilistic selection of destination is a nightmare. If you do not supply scope identification with scoped IPv6 address, that address is not sufficient for pointing single instance on network. fe80::x | ===+==== ether segment 1 | your node | ===+==== ether segment 2 | fe80::x (different instance) Jim, what you are trying to push now is: - modify every application that would specify sin6_scope_id, and have additional command line option for them (like "ping6 -I link fe80::x) - and put no modification to RFC2553. We all have been doing that, and we found it insufficient and very cumbersome. This is the very reason why jinmei came up with draft-ietf-ipngwg-scopedaddr-format-00.txt. Here are step-by-step description of reasons: - If you have two or more interfaces on a node, and/or if you have reachability to multiple sites, you MUST disambiguate destination somehow, for EVERY IPv6 operation you would make (telnet, ftp, ping6, rsh, ssh, whatever). - It is impossible to modify EVERY application that makes IPv6 operation. Also, in Jim's way we can't provide the users uniform command line syntax, or GUI menu box, for specifying scope (some tool may have already using -I, for example). You will end up providing: % ping6 -I link fe80::x % telnet -S link fe80::x % ssh -s link fe80::x This is not uniform and users will have trouble remembering options. - So, we needed to come up with uniform way to specify, or print, scoped address notation. For now let us suppose that we agree to use fe80::x@link. This way, you can provide the users a uniform syntax, like: % ping6 fe80::x@link % telnet fe80::x@link % ssh fe80::x@link Also, if routing table is shown like this by netstat: Dest Gateway Flags Refs default fe80::x@link UG 0 You can just do a cut-and-paste to perform ping6 to your default gateway. *** The above is what the draft is all about. Jim do you see the point? *** How to support this notation by API is totally different story. Read on. - It is very easy to do it with get{addr,name}info(), as they return sockaddr_in6. - It is very hard to support it transparently with inet_{ntop,pton}() and/or getipnodeby{addr,name}(). There are many options. - One choice is to not to support it with those APIs, and document that they will not be returning "scope" part. By using those API functions you may not be able to support multiple-zone cases. Though they may not be complete, they have their own merit; they provide a easy way to porting effort in the early-days (but again, the application will have a caveat - it will not be able to handle multiple-zone cases). - Another choice is to change those APIs, somehow. I'm not sure how to do it, I'm not sure if the change can be backward-compatible, I'm not sure if the change worth it, I'm not sure if they make any sense (they will return in6_addr and they have no room for returning sin6_scope_id). How to preform FQDN-to-numeric mapping is totally different story. There are so many options/discussions here, including: (1) how to provide DNS database for scoped space, (2) DNS spec itself (DNS is designed as single-tree database to be shared among everyone in the world. I'm not sure if it makes sense to provide DNS database for scoped zone. I'm not sure how we can standardize how to provide scoped DNS database. Nowadays, at firewall boundary every admin does it differently. Proposal we have in our hand are: draft-ietf-dnsind-local-names-07.txt draft-ietf-ipngwg-site-prefixes-03.txt Here are very general mapping strategies I can imagine: - I believe that FQDN should need no separate notion of scope. FQDN should be complete by its own, and should be somehow mapped into pair. The DNS mapping provides: FQDN -> If you have two root for DNS database, you may be able to specify preference by DNS search order ("search" keyword in resolv.conf). - Some would say that we need to map like this: -> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 01:00:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL8wuY24415 for ipng-dist; Sun, 21 Nov 1999 00:58:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL8wic24404 for ; Sun, 21 Nov 1999 00:58:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA22247 for ; Sun, 21 Nov 1999 00:58:45 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA23938 for ; Sun, 21 Nov 1999 00:58:45 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 00:57:04 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 00:57:04 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F13@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 00:57:04 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Jim Bound > > Not sure any of this should ever affect > existing inet_nt/pt functions. It wouldn't have to. We could leave them around for binary compatibility with what is already deployed. > if we can revisit the api yet again we > can revisit roberts idea :--). Actually, I'm not sure it was Robert's idea. I got the impression it was just an old (rejected) idea that he brought back up. I don't know whose idea it was in the first place. > It may make revisiting the api easier :---).... Adopting it would break binary compatibility with existing apps, which I thought you were against. > Or we could just bag site local addresses > in ipv6 then we would have to not revisit > either api or roberts idea :---) At the risk of repeating myself a billion times, the same issue exists for link-local addresses. Getting rid of site-local addresses would not make this issue go away. --Brian > > /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 Sun Nov 21 01:11:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL986M24456 for ipng-dist; Sun, 21 Nov 1999 01:08:06 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL97vc24449 for ; Sun, 21 Nov 1999 01:07:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA09956 for ; Sun, 21 Nov 1999 01:07:57 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25429 for ; Sun, 21 Nov 1999 01:07:56 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA01930; Sun, 21 Nov 1999 01:05:19 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id BAA16856; Sun, 21 Nov 1999 01:05:18 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id BAA43846; Sun, 21 Nov 1999 01:05:16 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911210905.BAA43846@bossette.engr.sgi.com> Subject: Re: Textual Address Change for Scope-IDs To: bzill@microsoft.com (Brian Zill) Date: Sun, 21 Nov 1999 01:05:15 -0800 (PST) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <3D2036E25376D31197A100805FEAD892712F13@RED-MSG-02> from "Brian Zill" at Nov 21, 99 00:57:04 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Zill wrote: > At the risk of repeating myself a billion times, the same issue exists for > link-local addresses. Getting rid of site-local addresses would not make > this issue go away. Yes, but multiple ND on each interface for link-locals, although _theoretically_ flawed would work in practice. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 01:19:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL9GgE24503 for ipng-dist; Sun, 21 Nov 1999 01:16:42 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL9GOc24496 for ; Sun, 21 Nov 1999 01:16:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA15327 for ; Sun, 21 Nov 1999 01:16:23 -0800 (PST) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA26608 for ; Sun, 21 Nov 1999 01:16:23 -0800 (PST) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 01:14:43 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 01:14:43 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F14@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 01:14:42 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Jim Bound > > If one should add a scope-id to the address > in a string representation as you suggest > it no longer is an IPv6 Address by any standard > we have today. Hence, it should have its own > API for parsing. This should not be a change > to the APIs that work with IPv6 addresses. So as long as we retain the current behavior of inet_pton, inet_ntop, getipnodebyaddr and getipnodebyname for backwards compatibility with existing deployed applications, you'll be happy? Or at least quit complaining? --Brian > > /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 Sun Nov 21 01:27:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL9Oqt24544 for ipng-dist; Sun, 21 Nov 1999 01:24:52 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL9Ofc24537 for ; Sun, 21 Nov 1999 01:24:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA23387 for ; Sun, 21 Nov 1999 01:24:40 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA27990 for ; Sun, 21 Nov 1999 01:24:39 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 01:24:26 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 01:24:25 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F15@RED-MSG-02> From: Brian Zill To: "'sm@bossette.engr.sgi.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 01:24:25 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Sam Manthorpe > > There is another possibility which I don't think > has been considered yet: > > Put the scope-id in the in6_addr in the same way as > KAME do (did?) it, _but_ only in the binary instances > of the address, never in textual representation. > > [...] > > I can't think of any disadvantages to this scheme, but I'm sure > somebody else on the list can :-) No doubt :-) The problem with this scheme is that it doesn't solve the textual representation problem. Users should be able to specify scoped addresses in a standard way that doesn't change when they move from implementation to implementation. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 01:49:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAL9kpT24575 for ipng-dist; Sun, 21 Nov 1999 01:46:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAL9kcc24568 for ; Sun, 21 Nov 1999 01:46:38 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA15884 for ; Sun, 21 Nov 1999 01:46:36 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA01286 for ; Sun, 21 Nov 1999 01:46:37 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 01:46:34 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 01:46:34 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F16@RED-MSG-02> From: Brian Zill To: "'sm@bossette.engr.sgi.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 01:46:33 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sam Manthorpe wrote: > > Brian Zill wrote: > > At the risk of repeating myself a billion times, > > the same issue exists for link-local addresses. > > Getting rid of site-local addresses would not > > make this issue go away. > > Yes, but multiple ND on each interface for link-locals, > although _theoretically_ flawed would work in practice. I suspect you're just playing devil's advocate, but: I think it's more than theoretical, point-to-point links and tunnels often have small integer numbers as their interface identifiers. Multiple ND has its problems and is non-trivial to implement. Besides, I don't _want_ to throw away site-local addresses, and I suspect most of the others on this list don't either. Especially not just because the API is broken (and easily fixed). I'll point out that site-local addresses are part of an IETF standards document, whereas the API is just an informational document that one doesn't have to follow to be IPv6 standards complaint. Discussing changing the protocol just to make the API discussion go a little easier strikes me as bizarre at best. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 02:22:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALAKaF24625 for ipng-dist; Sun, 21 Nov 1999 02:20:36 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALAKRc24618 for ; Sun, 21 Nov 1999 02:20:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA25201 for ; Sun, 21 Nov 1999 02:20:26 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27783 for ; Sun, 21 Nov 1999 03:20:26 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id CAA06538; Sun, 21 Nov 1999 02:16:17 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id CAA46592; Sun, 21 Nov 1999 02:20:24 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id CAA45338; Sun, 21 Nov 1999 02:20:18 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911211020.CAA45338@bossette.engr.sgi.com> Subject: Re: Textual Address Change for Scope-IDs To: bzill@microsoft.com (Brian Zill) Date: Sun, 21 Nov 1999 02:20:17 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3D2036E25376D31197A100805FEAD892712F15@RED-MSG-02> from "Brian Zill" at Nov 21, 99 01:24:25 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Brian Zill wrote: > The problem with this scheme is that it doesn't solve the textual > representation problem. Users should be able to specify scoped addresses in > a standard way that doesn't change when they move from implementation to > implementation. Oh, sorry, I wasn't clear enough in the explanation. The model I had in my head (which I forgot to write) is that getipnodebyname() and inet_pton() _do_ parse the standardized representation of an IPv6 address with a scope-id tagged on (e.g. link1:fe80...). They have to do that in order to set the scope-id in the binary IPv6 address they create. I'm trying to find a way for getipnodebyname() and inet_pton() to recognize scope-ids that keeps everybody happy. I want these functions to do that because adding per-application functionality for this is silly IMHO. Sure, you can make new functions to do this but then getipnodebyname() and inet_pton() get obsoleted which is even worse than breaking the API/ABI. I guess this does require an update to the rfc/draft but doesn't break the API (btw I'm still unclear if Jim objects as strongly to reving the inet-draft as he does to breaking the API). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 02:28:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALARxI24655 for ipng-dist; Sun, 21 Nov 1999 02:27:59 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALARoc24648 for ; Sun, 21 Nov 1999 02:27:51 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA16879 for ; Sun, 21 Nov 1999 02:27:49 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08024 for ; Sun, 21 Nov 1999 02:27:49 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id CAA04370; Sun, 21 Nov 1999 02:27:47 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id CAA07835; Sun, 21 Nov 1999 02:27:46 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id CAA40976; Sun, 21 Nov 1999 02:27:45 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911211027.CAA40976@bossette.engr.sgi.com> Subject: Re: Textual Address Change for Scope-IDs To: bzill@microsoft.com (Brian Zill) Date: Sun, 21 Nov 1999 02:27:44 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3D2036E25376D31197A100805FEAD892712F16@RED-MSG-02> from "Brian Zill" at Nov 21, 99 01:46:33 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, Brian Zill wrote: > I think it's more than theoretical, point-to-point links and tunnels often > have small integer numbers as their interface identifiers. Either there's a misunderstanding or I missed something. I'm thinking: ping . The kernel doesn't know what interface to use so it does ND on all of them. The first reply it gets wins. I don't get the connection with interface identifier numbers, but it _is_ late. Multiple ND has > its problems and is non-trivial to implement. Don't know about other kernel designs, but in bsd based ones like IRIX, `non-trivial' is an understatement :-) I know, I already looked into it. > Besides, I don't _want_ to throw away site-local addresses, and I suspect > most of the others on this list don't either. Especially not just because > the API is broken (and easily fixed). I agree absolutely with the second sentance. As an implementor, I don't like site-local at all because it causes a multitude of problems and I have yet to hear a convincing argument as to their merit; but this list has already been down that path ad-nauseum and I don't want to start this thread again; the decision has been so I apologise for touching on the subject again :-) > I'll point out that site-local > addresses are part of an IETF standards document, whereas the API is just an > informational document that one doesn't have to follow to be IPv6 standards > complaint. Discussing changing the protocol just to make the API discussion > go a little easier strikes me as bizarre at best. Agreed, as per above. Cheers, Sam. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 02:50:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALAmXg24687 for ipng-dist; Sun, 21 Nov 1999 02:48:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALAmOc24680 for ; Sun, 21 Nov 1999 02:48:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA25234 for ; Sun, 21 Nov 1999 02:48:23 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11113 for ; Sun, 21 Nov 1999 02:48:22 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA06620; Sun, 21 Nov 1999 11:48:16 +0100 (MET) Message-ID: <19991121114816.A6240@theory.cs.uni-bonn.de> Date: Sun, 21 Nov 1999 11:48:16 +0100 From: Ignatios Souvatzis To: Sam Manthorpe , Brian Zill Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs References: <3D2036E25376D31197A100805FEAD892712F16@RED-MSG-02> <199911211027.CAA40976@bossette.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199911211027.CAA40976@bossette.engr.sgi.com>; from Sam Manthorpe on Sun, Nov 21, 1999 at 02:27:44AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Nov 21, 1999 at 02:27:44AM -0800, Sam Manthorpe wrote: > > Either there's a misunderstanding or I missed something. I'm > thinking: ping . The kernel doesn't know what > interface to use so it does ND on all of them. The first reply > it gets wins. I don't get the connection with interface identifier > numbers, but it _is_ late. uhm... shouldn't you have a routing table set up to use site local addresses? -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 03:06:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALB3iR24718 for ipng-dist; Sun, 21 Nov 1999 03:03:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALB3Xc24711 for ; Sun, 21 Nov 1999 03:03:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA25764 for ; Sun, 21 Nov 1999 03:03:31 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA13490 for ; Sun, 21 Nov 1999 03:03:31 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 03:03:29 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 03:03:29 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F17@RED-MSG-02> From: Brian Zill To: "'sm@bossette.engr.sgi.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 03:03:26 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sam Manthorpe wrote: > Brian Zill wrote: > > The problem with this scheme [...] > > Oh, sorry, I wasn't clear enough in the explanation. > > The model I had in my head (which I forgot to write) > is that getipnodebyname() and inet_pton() _do_ parse > the standardized representation of an IPv6 address > with a scope-id tagged on (e.g. link1:fe80...). > They have to do that in order to set the > scope-id in the binary IPv6 address they create. Oh, okay. Thanks for clarifying. I thought you meant they'd only be able to return a scope-id when talking to scope-aware name resolvers. But I think the other direction (getipnodebyaddr and inet_ntop) is important too. Then we're getting close to Jim's earlier idea of just doing this packing/unpacking before/after calling one of these "legacy" APIs. > I'm trying to find a way for getipnodebyname() > and inet_pton() to recognize scope-ids that keeps > everybody happy. An excellent goal, but it's beginning to look like a tall order :-) > I want these functions to do that because adding > per-application functionality for this is silly IMHO. Except for Jim, I think we're pretty much agreed on that too. > Sure, you can make new functions to do this but > then getipnodebyname() and inet_pton() get obsoleted > which is even worse than breaking the API/ABI. Is it worse? What if it turns out to be impossible to make them fully scope-aware while maintaining backwards binary compatibility? Jim seems to be pretty adament about not breaking backwards binary compatibility, it's less clear as to whether he'd agree to keeping them around in some sort of deprecated state. On the positive side, it looks like we now have a couple of ideas for making these scope-aware without breaking existing apps. Personally, I still need some time to think them through before I'll decide which direction to support. And yes, it's too late tonight to do that :-) > I guess this does require an update to the rfc/draft > but doesn't break the API (btw I'm still unclear if > Jim objects as strongly to reving the inet-draft as > he does to breaking the API). Yes, it would be nice if Jim would clarify this. Thanks, --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 03:19:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALBEU324766 for ipng-dist; Sun, 21 Nov 1999 03:14:30 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALBEJc24759 for ; Sun, 21 Nov 1999 03:14:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA12795 for ; Sun, 21 Nov 1999 03:14:19 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA15097 for ; Sun, 21 Nov 1999 03:14:17 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 03:14:06 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 03:14:05 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F18@RED-MSG-02> From: Brian Zill To: "'sm@bossette.engr.sgi.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 03:14:04 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Sam, > Either there's a misunderstanding or I missed > something. I'm thinking: ping . > The kernel doesn't know what interface to use so it > does ND on all of them. The first reply it gets > wins. I don't get the connection with interface > identifier numbers, but it _is_ late. Ah, I thought you meant ping and not site-local since this was in the context of doing away with site-local. In that case, you could potentially be connected to a bunch of PPP links or tunnels that are more likely to have low integer numbers as their interface identifiers. Thus fe80::1 might be both a common and ambiguous address for a neighbor. > Don't know about other kernel designs, but in > bsd based ones like IRIX, `non-trivial' is an > understatement :-) Yeah, ours too. I suspect it's universal. :-) > but this list has already been down that path > [doing away with site-local] ad-nauseum and > I don't want to start this thread again; the > decision has been so I apologise for touching > on the subject again :-) Agreed. Let's just drop it. Thanks, --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 04:03:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALC0oM24818 for ipng-dist; Sun, 21 Nov 1999 04:00:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALC0fc24811 for ; Sun, 21 Nov 1999 04:00:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA13748 for ; Sun, 21 Nov 1999 04:00:39 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA06524 for ; Sun, 21 Nov 1999 05:00:35 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id LA10347; Sun, 21 Nov 1999 22:55:56 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Sun, 21 Nov 1999 17:52:25 +0900." <18252.943174345@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Nov 1999 22:55:56 +1100 Message-Id: <12612.943185356@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 21 Nov 1999 17:52:25 +0900 From: itojun@iijlab.net Message-ID: <18252.943174345@coconut.itojun.org> | If you have a node with multiple interface/scope, sin6_scope_id is | *required* to disambiguate two scope instances ("zones" in Steve's | terminology). Yes, that is certainly true. | Jim, what you are trying to push now is: | - modify every application that would specify sin6_scope_id, and | have additional command line option for them | (like "ping6 -I link fe80::x) That is fairly unreasonable - though I an not sure it is worse than ... | - So, we needed to come up with uniform way to specify, or print, | scoped address notation. For now let us suppose that we agree to use | fe80::x@link. The difference here is who gets the pain. In the first it is the application programmers, who have to manage to provide a (fairly) consistent user interface and deal with it all over the place. In the second it is the users who have to figure out when they need to add the stray extra syntax, and what it should be (when it is possible to cut/paste that would not be too hard, but it isn't always). Then you have to convince them it is necessary (sometimes) - ping of a global address will work without it, from some hosts (those with only one interface, or only in one site) all addresses will work without it. But sometimes it is needed. As a user interface, that sucks. And it doesn't matter in the slightest what the actual syntax looks like. This is why I still think that putting the id inside the address makes more sense than any other proposal I have seen. Aside to Brian Zill: I don't think this was originally my idea either - I think I picked it up from a comment made by someone else ages ago - but it was me who argued for it back when it was rejected years ago. Aside to Jim Bound: what I am suggesting (just like everyone else) *is* an API change. My one happens to be binary compatible across the interface with the current API (all variants). Not that I think that is essential - early adopters of standards get the benefit of being their first, the price they may pay for that is that things just might change from under them. I am not in the slightest worried about users getting confused by these things - your average user should *never* see a hex format IPv6 address, only a domain name format). The few remaining users, those that do have to deal with these things can learn this extra bit of trivia as easily as they can learn about mask and compare type operations, longest match, etc. The hard part of that learning is to appreciate why it is necessary to specify this extra piece of info, when it is "obvious to everyone" that there is only one node anywhere I can reach with the address I am entering. Once that is grasped, the detail of the syntax of where the number is written is minor. I suspect that much of the reason that we can't get much agreement on what is important here is because we really have no common agreement on how the limited scope addresses should, or will, be used. Anything and everything from "they're useless, they will never be used" to "these addresses should be used whereevr possible, with global addresses only used when there is no other way" exists I believe. This lack of any common ground means that we all see the issues differently - what is important to one is irrelevant to another. I think it might be a good idea to simply forget about standardising this (in any form - including informational recommendations) until we have a better general sense of what is needed, where, and why. This is going to mean that implementations are all going to do different things, and users won't get any consistency - but that's normal in an immature product, which site & link local addressing certainly is (while there are kind of analogs in IPv4, when you look closely, they're really nothing like the same at all). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 04:27:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALCPHV24850 for ipng-dist; Sun, 21 Nov 1999 04:25:17 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALCP6c24843 for ; Sun, 21 Nov 1999 04:25:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA10081 for ; Sun, 21 Nov 1999 04:25:05 -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 EAA26265 for ; Sun, 21 Nov 1999 04:25:04 -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 VAA19306; Sun, 21 Nov 1999 21:24:50 +0900 (JST) To: Robert Elz cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Sun, 21 Nov 1999 22:55:56 +1100. <12612.943185356@munnari.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Sun, 21 Nov 1999 21:24:50 +0900 Message-ID: <19304.943187090@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Jim, what you are trying to push now is: > | - modify every application that would specify sin6_scope_id, and > | have additional command line option for them > | (like "ping6 -I link fe80::x) >That is fairly unreasonable - though I an not sure it is worse than ... > | - So, we needed to come up with uniform way to specify, or print, > | scoped address notation. For now let us suppose that we agree to use > | fe80::x@link. >The difference here is who gets the pain. Yup. I only described the background thoughts for the draft. >This is why I still think that putting the id inside the address makes more >sense than any other proposal I have seen. Aside to Brian Zill: I don't I can tell you about our experience. KAME has been using IPv6 address that embeds interface identifier for kernel internal structure, like: fe80:1::2e0:98ff:fe00:309f for fe80::2e0:98ff:fe00:309f on interface 1 The embedded form appears on routing table, or interface address structure (struct ifnet, for *BSD). Sometimes embedded form is exposed to userland program, via routing socket, ioctl, or kmem. We did not hide the 4th byte for quite some time on outputs from netstat or ifconfig (which uses routing socket or ioctl), like: >>ne2: flags=8863 mtu 1500 >> address: 00:e0:98:00:30:9f >> media: Ethernet manual >> inet 210.160.95.98 netmask 0xfffffff0 broadcast 210.160.95.111 >> inet6 fe80:1::2e0:98ff:fe00:309f prefixlen 64 Our experience is, users will get confused if we print address expression that differs from that appears on the wire. IPv6 introductory material does not speak about "embedded" form, so they have no idea what is the 4th byte (though we document it repeatedly in KAME documents, 95% of users do not read them at all :-P). So, we are now using fe80::x@link form in many places. I believe it provided much ease of use to the users. We get less questions about embedded form. >>ne2: flags=8863 mtu 1500 >> address: 00:e0:98:00:30:9f >> media: Ethernet manual >> inet 210.160.95.98 netmask 0xfffffff0 broadcast 210.160.95.111 >> inet6 fe80::2e0:98ff:fe00:309f@ne2 prefixlen 64 scopeid 0x1 itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 05:35:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALDXS424889 for ipng-dist; Sun, 21 Nov 1999 05:33:28 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALDXJc24881 for ; Sun, 21 Nov 1999 05:33:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA02440 for ; Sun, 21 Nov 1999 05:33:20 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA07021 for ; Sun, 21 Nov 1999 05:33:16 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id NA14237; Mon, 22 Nov 1999 00:31:49 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Sun, 21 Nov 1999 21:24:50 +0900." <19304.943187090@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 22 Nov 1999 00:31:49 +1100 Message-Id: <15398.943191109@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 21 Nov 1999 21:24:50 +0900 From: itojun@iijlab.net Message-ID: <19304.943187090@coconut.itojun.org> | I can tell you about our experience. | KAME has been using IPv6 address that embeds interface identifier for | kernel internal structure, like: Yes, I know, I am running it. I love it. I *like* to see the addresses that way. It will be a pity to see it vanish the next time I upgrade (if that is what will happen). | Our experience is, users will get confused if we print address | expression that differs from that appears on the wire. IPv6 | introductory material does not speak about "embedded" form, yes, right now that would be a problem - as this method is not generally documented anywhere in particular, people won't expect it. However, were this adopted as the "normal" way for these addresses to appear, then all the rest of that doc (the next edition of Christian's book, etc) would all get fixed, and this would be much less of a 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 Sun Nov 21 05:39:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALDcoP24919 for ipng-dist; Sun, 21 Nov 1999 05:38:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALDcec24912 for ; Sun, 21 Nov 1999 05:38:40 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA29166 for ; Sun, 21 Nov 1999 05:38:41 -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 FAA07856 for ; Sun, 21 Nov 1999 05:38:40 -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 WAA19938; Sun, 21 Nov 1999 22:38:09 +0900 (JST) To: Robert Elz cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 22 Nov 1999 00:31:49 +1100. <15398.943191109@munnari.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Sun, 21 Nov 1999 22:38:09 +0900 Message-ID: <19936.943191489@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >yes, right now that would be a problem - as this method is not generally >documented anywhere in particular, people won't expect it. However, were >this adopted as the "normal" way for these addresses to appear, then all >the rest of that doc (the next edition of Christian's book, etc) would all >get fixed, and this would be much less of a problem. One additional comment on embedding scope id into address: The portion we are using for scope id (3rd and 4th byte of the address for KAME case) is not really a reserved field. We need a update to RFC2373 2.5.8 (for scoped unicast) and 2.7 (for multicast) as well if we are going to take this route. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 06:49:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALEl0Q24992 for ipng-dist; Sun, 21 Nov 1999 06:47:00 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALEkpc24985 for ; Sun, 21 Nov 1999 06:46:51 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA00784 for ; Sun, 21 Nov 1999 06:46:51 -0800 (PST) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20737 for ; Sun, 21 Nov 1999 06:46:50 -0800 (PST) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id OAA07395; Sun, 21 Nov 1999 14:46:31 GMT Message-Id: <199911211446.OAA07395@orchard.arlington.ma.us> To: itojun@iijlab.net cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Message from itojun@iijlab.net of "Sun, 21 Nov 1999 22:38:09 +0900." <19936.943191489@coconut.itojun.org> Date: Sun, 21 Nov 1999 09:46:31 -0500 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I also like the idea of stuffing the scope id into the more-or-less-unused parts of link-local and site-local addresses, as done by KAME; having to allocate additional space to possibly store a scope id seems like a waste.. the addresses are big enough as it is.. As done by Kame, it does limit you to 2**16 different scopes of each type but this doesn't seem to be a significant restriction (and, at least for link local addresses, bytes 5 and 6 should be easily grabbable). Reserving bytes 3..8 of link-local addresses (and bytes 3..6 of site-local addresses) seems like a good idea anyway... - 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 Sun Nov 21 06:53:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALEq6W25023 for ipng-dist; Sun, 21 Nov 1999 06:52:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALEpvc25016 for ; Sun, 21 Nov 1999 06:51:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA01807 for ; Sun, 21 Nov 1999 06:51:58 -0800 (PST) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21633 for ; Sun, 21 Nov 1999 06:51:57 -0800 (PST) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id OAA07429; Sun, 21 Nov 1999 14:51:47 GMT Message-Id: <199911211451.OAA07429@orchard.arlington.ma.us> To: Ignatios Souvatzis cc: Sam Manthorpe , Brian Zill , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Message from Ignatios Souvatzis of "Sun, 21 Nov 1999 11:48:16 +0100." <19991121114816.A6240@theory.cs.uni-bonn.de> Date: Sun, 21 Nov 1999 09:51:47 -0500 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Either there's a misunderstanding or I missed something. I'm > > thinking: ping . The kernel doesn't know what > > interface to use so it does ND on all of them. The first reply > > it gets wins. I don't get the connection with interface identifier > > numbers, but it _is_ late. > > uhm... shouldn't you have a routing table set up to use site local addresses? Your system may have interfaces connected to multiple sites who are using the same site-local addresses. that's why you need some sort of scope id. I'd rather jam a scope id into a "reserved" part of the address than have to effectively expand addresses to 20 bytes.. (but i'd also rather just kill site-local addresses..) - 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 Sun Nov 21 07:07:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALF40325058 for ipng-dist; Sun, 21 Nov 1999 07:04:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALF3jc25051 for ; Sun, 21 Nov 1999 07:03:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA04341 for ; Sun, 21 Nov 1999 07:03:44 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21945 for ; Sun, 21 Nov 1999 08:03:42 -0700 (MST) 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 AAA20890; Mon, 22 Nov 1999 00:03:28 +0900 (JST) To: Bill Sommerfeld cc: ipng@sunroof.eng.sun.com In-reply-to: sommerfeld's message of Sun, 21 Nov 1999 09:46:31 EST. <199911211446.OAA07395@orchard.arlington.ma.us> 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: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Mon, 22 Nov 1999 00:03:28 +0900 Message-ID: <20888.943196608@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I also like the idea of stuffing the scope id into the >more-or-less-unused parts of link-local and site-local addresses, as >done by KAME; having to allocate additional space to possibly store a >scope id seems like a waste.. the addresses are big enough as it is.. Though I think many understands it, there are some twistswith address-with-embedded-scope: - on-wire form and printable form will become different. broken implementation may throw embedded form onto the wire and cause problems. - printable form cannot be exchanged across machines, like cur-and-paste across xterm for different machines (fe80::x@link has the same problem, though). - at IETF meetings, for site-local addresses, there has been discussion about use of "printable" scope name used across a site (like "cisco" and "stanford", advertised somehow across a scope). If we embed scope into address, and if FQDN and numeric address mapping is like -> we will have no chance to introduce printable scope name. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 08:32:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALGTmG25101 for ipng-dist; Sun, 21 Nov 1999 08:29:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALGTdc25094 for ; Sun, 21 Nov 1999 08:29:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA14995 for ; Sun, 21 Nov 1999 08:29:39 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA09923 for ; Sun, 21 Nov 1999 08:29:35 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA16179; Mon, 22 Nov 1999 03:27:59 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Mon, 22 Nov 1999 00:03:28 +0900." <20888.943196608@coconut.itojun.org> Date: Mon, 22 Nov 1999 03:27:58 +1100 Message-Id: <16371.943201678@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 22 Nov 1999 00:03:28 +0900 From: itojun@iijlab.net Message-ID: <20888.943196608@coconut.itojun.org> | Though I think many understands it, there are some twistswith | address-with-embedded-scope: | - on-wire form and printable form will become different. Yes, that's certainly true. | broken implementation may throw embedded form onto the wire and | cause problems. But that is almost irrelevant. Broken implementations can do almost anything, and while it is a good idea not to deliberately design things so as to encourage brokenness, the possibility of something being boken should not be taken as a restriction (use it to choose between two otherwise equal choices, but not more than that). | - printable form cannot be exchanged across machines, like | cur-and-paste across xterm for different machines | (fe80::x@link has the same problem, though). Yes, to both. Though as long as the implementations don't force the ids upon me, and lets me use whatever I like, I can, if I want, cause the id's to be consistent across all the systems where cut & paste would be likely to be useful. For example, I could use the subnet number from my global addresses as my interface id's in link local addresses. (Since the interface id field in a link local will probably be bigger than the subnet id in a global, I will have lots more id's around to number the links with no global addressing). That way, every system will use the same ID. I can also pick some random numbering scheme for any sites I deal with, and assign the same ids to each site on every system. I should not be forced to do that, but implementations ought allow me to (not just force 0 1 2 3 4 .. in some arbitrary order). Of course, this is just a quality of implementation issue, and doesn't need to be written anywhere. | - at IETF meetings, for site-local addresses, there has been | discussion about use of "printable" scope name used across a site | (like "cisco" and "stanford", advertised somehow across a scope). | If we embed scope into address, and if FQDN and numeric address | mapping is like | -> | we will have no chance to introduce printable scope name. Not necessarily. If you followed that logic we wouldn't have printable host names, or printable service (port) names, ... All this means is that the way you were thinking of doing it might not work. As best I recall, the scope_id that exists currently is an integer anyway, so something would have to map from the name to the number. Where the number gets put is the only issue after that - is it in a separate field, or buried inside the address. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 09:30:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALHSh625224 for ipng-dist; Sun, 21 Nov 1999 09:28:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALHSWc25217 for ; Sun, 21 Nov 1999 09:28:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA17115 for ; Sun, 21 Nov 1999 09:28:31 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22071 for ; Sun, 21 Nov 1999 09:28:30 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id CAA09891; Mon, 22 Nov 1999 02:16:47 +0900 (JST) Date: Mon, 22 Nov 1999 02:28:13 +0900 Message-ID: <14392.11181.148730.3063M@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: In your message of "Sun, 21 Nov 1999 00:19:29 -0500" <199911210519.AAA0000000662@quarry.zk3.dec.com> References: <14391.31055.510925.74466C@condor.isl.rdc.toshiba.co.jp> <199911210519.AAA0000000662@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 21 Nov 1999 00:19:29 -0500, >>>>> Jim Bound said: >> As for the API issues, the new textual representation will surely >> introduce some extensions or changes in the current basic and/or >> advanced APIs. But without the extensions, you'd modify every >> application that should handle scoped addresses. For example, in order >> to allow the ifconfig program like 'ifconfig fe80::1 FUZZY le0', you >> should introduce some extensions to the existing APIs or modify the >> ifconfig program itself. I belive the latter approach is more painful >> for programmers and should be avoided. > I strongly don't agree with the above and its the bottom line I am glad > you articulated this so crystal clear. > The way I want it as you have it above it causes no change at all to the > API in that case. All that is done is we go into ifconfig and add > another parameter and move it directly to sin6_scope_id. Then > sockaddr_in6 is complete architecturally with this issue. >...(snip) Okay, so you prefer the former approach. Now I'm in a different position than yours, so I'd like to hear other implementors' opinions and obey the consensus (if we can get one). Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 09:30:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALHRHP25206 for ipng-dist; Sun, 21 Nov 1999 09:27:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALHR8c25199 for ; Sun, 21 Nov 1999 09:27:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA07633 for ; Sun, 21 Nov 1999 09:27:07 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21850 for ; Sun, 21 Nov 1999 09:27:06 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id CAA09895 for ; Mon, 22 Nov 1999 02:16:56 +0900 (JST) Date: Mon, 22 Nov 1999 02:28:21 +0900 Message-ID: <14392.11189.811155.30564X@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: In your message of "Sun, 21 Nov 1999 17:52:25 +0900" <18252.943174345@coconut.itojun.org> References: <199911210537.AAA0000003480@quarry.zk3.dec.com> <18252.943174345@coconut.itojun.org> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 21 Nov 1999 17:52:25 +0900, >>>>> itojun@iijlab.net said: >> Where else do you see this being used besides as the user interface. >> I think we should discuss where this will be useful. >> But is it useful any place else other than the user interface? > Jim, I think you are not getting the reason why jinmei came up > with the draft. Please read the following and share the problem > with us. Thank you very much, itojun. Your memo describes our motivation perfectly. There is nothing that I'd add to respond to the questions from Jim. > (I tend to believe that internet-draft should provide more background > information that lead us to the resulting specification. Currently > drafts tend to describe resulting specification only...) Okay, if I have a chance to revise the draft, I'll try to desribe more precise background. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 09:30:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALHRp025215 for ipng-dist; Sun, 21 Nov 1999 09:27:51 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALHRfc25208 for ; Sun, 21 Nov 1999 09:27:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA19124 for ; Sun, 21 Nov 1999 09:27:40 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21991 for ; Sun, 21 Nov 1999 09:27:39 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id CAA09899; Mon, 22 Nov 1999 02:17:03 +0900 (JST) Date: Mon, 22 Nov 1999 02:28:29 +0900 Message-ID: <14392.11197.544972.85469U@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: kre@munnari.OZ.AU Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: In your message of "Sun, 21 Nov 1999 22:55:56 +1100" <12612.943185356@munnari.OZ.AU> References: <18252.943174345@coconut.itojun.org> <12612.943185356@munnari.OZ.AU> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 51 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 21 Nov 1999 22:55:56 +1100, >>>>> Robert Elz said: > | Jim, what you are trying to push now is: > | - modify every application that would specify sin6_scope_id, and > | have additional command line option for them > | (like "ping6 -I link fe80::x) > That is fairly unreasonable - though I an not sure it is worse than ... > | - So, we needed to come up with uniform way to specify, or print, > | scoped address notation. For now let us suppose that we agree to use > | fe80::x@link. > The difference here is who gets the pain. In the first it is the application > programmers, who have to manage to provide a (fairly) consistent user interface > and deal with it all over the place. In the second it is the users who have > to figure out when they need to add the stray extra syntax, and what it should > be (when it is possible to cut/paste that would not be too hard, but it isn't > always). Then you have to convince them it is necessary (sometimes) - ping > of a global address will work without it, from some hosts (those with only > one interface, or only in one site) all addresses will work without it. > But sometimes it is needed. As a user interface, that sucks. And it > doesn't matter in the slightest what the actual syntax looks like. I think that users will get the pain in the former approach as well; "Users have to figure out when they need to add the extra OPTION. ping of a global address will work without it, all addresses will work without it". (snip) > I think it might be a good idea to simply forget about standardising this > (in any form - including informational recommendations) until we have a > better general sense of what is needed, where, and why. This is going to > mean that implementations are all going to do different things, and users > won't get any consistency - but that's normal in an immature product, which > site & link local addressing certainly is (while there are kind of analogs in > IPv4, when you look closely, they're really nothing like the same at all). I agree that we need try to get the general sense, but I belive we should do now. I think that IPv6 is now fairly mature and that (at least) the semantics, usage, and importance of link-local addresses are clear enough. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 11:35:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALJX8v25327 for ipng-dist; Sun, 21 Nov 1999 11:33:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALJWxc25320 for ; Sun, 21 Nov 1999 11:33:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA21127 for ; Sun, 21 Nov 1999 11:32:58 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18646 for ; Sun, 21 Nov 1999 11:32:58 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id DA244104BBF; Sun, 21 Nov 1999 13:32:57 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id F30374FB03; Sun, 21 Nov 1999 13:32:51 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 804474C901; Sun, 21 Nov 1999 13:32:51 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000031277; Sun, 21 Nov 1999 14:32:56 -0500 (EST) From: Jim Bound Message-Id: <199911211932.OAA0000031277@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 17:52:25 +0900." <18252.943174345@coconut.itojun.org> Date: Sun, 21 Nov 1999 14:32:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, >>Where else do you see this being used besides as the user interface. >>I think we should discuss where this will be useful. >>But is it useful any place else other than the user interface? > > Jim, I think you are not getting the reason why jinmei came up > with the draft. Please read the following and share the problem > with us. It is very long, but please read it patiently (I really > hoped you to be present at 2nd ipng slot...). Sorry for possible > typos and grammatical mistakes, I tried my best. I do get the reason and don't agree with the idea. Thats all. > (I tend to believe that internet-draft should provide more background > information that lead us to the resulting specification. Currently > drafts tend to describe resulting specification only...) Well I think all drafts should have pretty good overviews for sure. This is missing in some of my specs too and I intend to correct it. A good overview can help reduce discussion. Thomas Narten has been telling a few of us we need this in the Internet Area and I for one agree with him. >*** >>From now on, please forget about DNS or other FQDN-to-address mapping. >All we have is numeric text representation - like we are in dentist's >office. >*** This is fine. >If you have a node with multiple interface/scope, sin6_scope_id is >*required* to disambiguate two scope instances ("zones" in Steve's >terminology). Agreed. >For example, if your node have two interfaces, and would like to >throw a packet to fe80::x, you MUST disambiguate it somehow. >Because of the design of link-local scope, fe80::x can be on both >sides, and they can be different node. Probabilistic selection of >destination is a nightmare. If you do not supply scope identification >with scoped IPv6 address, that address is not sufficient for pointing >single instance on network. Ok but this has been common knowledge since we invented them and we put code in to solve the problem in various places. So OK.. I will keep reading but have learned nothing new as your stating the obvious. fe80::x | ===+==== ether segment 1 | your node | ===+==== ether segment 2 | fe80::x (different instance) >Jim, what you are trying to push now is: >- modify every application that would specify sin6_scope_id, and > have additional command line option for them > (like "ping6 -I link fe80::x) >- and put no modification to RFC2553. Yes I am and with great intent too. >We all have been doing that, and we found it insufficient and >very cumbersome. This is the very reason why jinmei came up with >draft-ietf-ipngwg-scopedaddr-format-00.txt. I have heard you find it cumbersome and Brian finds it cumbersome and I am still not clear what Tim thinks so when you say "we" please don't speak for all the implementors or define what we means if that means KAME thats fine. I don't find it cumbersome at all. In fact I strongly believe parameterization for user interfaces is fine. >Here are step-by-step description of reasons: >- If you have two or more interfaces on a node, and/or if you have > reachability to multiple sites, you MUST disambiguate destination > somehow, for EVERY IPv6 operation you would make > (telnet, ftp, ping6, rsh, ssh, whatever). I don't agree. If you are telneting to another node you should just specify a destination address as a user whether its in the same scope-id or not users SHOULD NOT have to type ftp FUZZY|FEC0::1 OR ftp FUZZY FEC0::1 that is unacceptable. Same for ftp, ping, rsh, ssh, whatever and I also think having ping6 or ping4 is bogus and it should just be ping. But for sysadmin commands like ifconfig that is an entirely different manner. Are you saying that a user must need to know the scope-id in addition to the IPv6 address when it keys in the dst address for ftp, telnet, ping etc.. If so I strongly disagree with you and if this were true IPv6 is dead right now in the market. It also completely broke the key concept of Ipv6 which is simplicity and that it is extensible to the IPv4 architecture. Fortuneately I think you have just shown though an error in your thinking about this problem most likely. You cannot specify the dst scope-id for an address at the client, you have know way of knowning. And for the apps your listing we don't and should not have to specify the source address. >- It is impossible to modify EVERY application that makes IPv6 > operation. Also, in Jim's way we can't provide the users uniform > command line syntax, or GUI menu box, for specifying scope (some > tool may have already using -I, for example). This is not impossible and so far I have seen only one application that needs this at the user interface "ifconfig" I am waiting to hear of others on the list. Which by the way was one of my questions you did not answer at all and proceeded to ask me questions. Do you want to use two way communications or just pose the questions you want to talk about. > You will end up providing: > % ping6 -I link fe80::x > % telnet -S link fe80::x > % ssh -s link fe80::x > This is not uniform and users will have trouble remembering options. Users will not want to know about scope IDs at all. If a user pings another node at FE80::x on another node. I agree that is a problem. But it is the implementation that must resolve the issue not the user or the user should use a FQDN and this is possible in the dentist office too. But if your saying IPv6 now has caused the following: command-to-server dst-address (which is what we have today with ftp, telnet etc) NOW command-to-server scope-id-from-this-client dst-address Then I think the entire notion of scoped addresses must be revisited and we should again discuss the idea of EIDs with Locators and ask Noel Chiappa to come help us sort this out. Cause I think this is one of his issues with IPv6 and I am thinking now I agree with him. Lets not change just the API lets go back and see if we have to rearchitect this beast correctly. I think we are fine though what we need to do is hide this from the user in some manner and keep ftp, telnet, etc and friends from the client telling the the application what the scope-id for the client the app should use to pick the correct source scope-id so it gets to the right dst address. This is where Robert Elz's propsal shines. We embed the scope in the address and pull it out when we use the address in any manner this way the DNS works, the user don't have to key in scopes, etc... >- So, we needed to come up with uniform way to specify, or print, > scoped address notation. For now let us suppose that we agree to use > fe80::x@link. This way, you can provide the users a uniform > syntax, like: > % ping6 fe80::x@link > % telnet fe80::x@link > % ssh fe80::x@link > Also, if routing table is shown like this by netstat: > Dest Gateway Flags Refs > default fe80::x@link UG 0 > You can just do a cut-and-paste to perform ping6 to your default > gateway. First I ported ping and got rid of have to use things like ping6. If you have to use ping6 in KAME you need to fix that one. Anyway: I really disagree with the above. The rt entry for this should have its own link column. What you depict is horrible. >*** >The above is what the draft is all about. Jim do you see the point? >*** Itojun I do see the point and I don't agree with the problem statement, and don't agree with the solution. Do you get my point. >How to support this notation by API is totally different story. Read on. >- It is very easy to do it with get{addr,name}info(), as they return > sockaddr_in6. >- It is very hard to support it transparently with inet_{ntop,pton}() > and/or getipnodeby{addr,name}(). There are many options. > - One choice is to not to support it with those APIs, and document that > they will not be returning "scope" part. By using those API functions > you may not be able to support multiple-zone cases. > Though they may not be complete, they have their own merit; > they provide a easy way to porting effort in the early-days (but again, > the application will have a caveat - it will not be able to handle > multiple-zone cases). > - Another choice is to change those APIs, somehow. I'm not sure > how to do it, I'm not sure if the change can be backward-compatible, > I'm not sure if the change worth it, I'm not sure if they make any sense > (they will return in6_addr and they have no room for returning > sin6_scope_id). This is different discussion and we will discuss once we get the input from Carl Williams. >How to preform FQDN-to-numeric mapping is totally different story. >There are so many options/discussions here, including: >(1) how to provide DNS database for scoped space, Different thread but I agree it needs to be resolved. >(2) DNS spec itself (DNS is designed as single-tree database to be shared > among everyone in the world. I'm not sure if it makes sense to > provide DNS database for scoped zone. I'm not sure how we can > standardize how to provide scoped DNS database. Nowadays, at firewall > boundary every admin does it differently. Proposal we have in our hand > are: > draft-ietf-dnsind-local-names-07.txt > draft-ietf-ipngwg-site-prefixes-03.txt Which DNS spec? RFC 1035 or 1036? If we are to change DNS because of IPv6 then IPv6 has a major error. >Here are very general mapping strategies I can imagine: >- I believe that FQDN should need no separate notion of scope. FQDN should > be complete by its own, and should be somehow mapped into > pair. The DNS mapping provides: > FQDN -> This is the discussion and how we do this is TBD. > If you have two root for DNS database, you may be able to specify preference > by DNS search order ("search" keyword in resolv.conf). >- Some would say that we need to map like this: > -> Well we don't get to reinvent DNS with IPv6 I will tell you that right now or Internet applications etc.. Or I will become an IPv6 Hater--)... Also I appreciate your aggressiveness and your hard work on KAME, but you are not planning on shipping a product that a customer will use to my knowledge and KAME is a pub domain code base. I don't see GM or Toyota using KAME or freebsd to run their manufacturing or business operations. So please try to see my viewpoint here that is affected by production quality products as vendors alter the base operating system and networking subsystem for our customers. I have to be much more conservative in my thinking than if I was working on a public domain code base such as KAME. Somewhere there is a balance that needs to happen I realize but I think this whole notion of scope-ids needs a lot of discussion, attention, and review before we change anything in IPv6 like the APIs, DNS, Resolver code etc.. I am glad KAME is experimenting with this now but please don't always assume you experiments are going to be the answer to the standard we all use for IPv6. thanks /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 Sun Nov 21 11:40:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALJd9x25378 for ipng-dist; Sun, 21 Nov 1999 11:39:09 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALJd1c25371 for ; Sun, 21 Nov 1999 11:39:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA00381 for ; Sun, 21 Nov 1999 11:39:00 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19759 for ; Sun, 21 Nov 1999 11:38:59 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id E4BA45787C for ; Sun, 21 Nov 1999 13:38:58 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 0FF674FB03; Sun, 21 Nov 1999 13:38:53 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id AEA774C901; Sun, 21 Nov 1999 13:38:52 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000032011; Sun, 21 Nov 1999 14:38:57 -0500 (EST) From: Jim Bound Message-Id: <199911211938.OAA0000032011@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 00:57:04 PST." <3D2036E25376D31197A100805FEAD892712F13@RED-MSG-02> Date: Sun, 21 Nov 1999 14:38:57 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> It may make revisiting the api easier :---).... >Adopting it would break binary compatibility with existing apps, which I >thought you were against. Not at all. I said it would make it easier. If I get back an adress like this: fe80::FUZZY::1 with getipnodebyname we would strip out the fuzzy at the resolver and stick it in sin6_scope_id. 1) we would need new flag for getipnodebyname to pass sockaddr_in6 2) change hostent to be different in backwards compatible way 3) shoot getipnodebyname in the head and use getaddrinfo >> Or we could just bag site local addresses >> in ipv6 then we would have to not revisit >> either api or roberts idea :---) > >At the risk of repeating myself a billion times, the same issue exists for >link-local addresses. Getting rid of site-local addresses would not make >this issue go away. Well I am not going to repeat my self I have already answered you on this twice. /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 Sun Nov 21 11:46:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALJi3q25412 for ipng-dist; Sun, 21 Nov 1999 11:44:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALJhsc25405 for ; Sun, 21 Nov 1999 11:43:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA11940 for ; Sun, 21 Nov 1999 11:43:53 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20785 for ; Sun, 21 Nov 1999 11:43:53 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 2CFB4104C68 for ; Sun, 21 Nov 1999 13:43:53 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 3CFA0BC4DA; Sun, 21 Nov 1999 13:43:47 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id DA144B2A42; Sun, 21 Nov 1999 13:43:46 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000000468; Sun, 21 Nov 1999 14:43:52 -0500 (EST) From: Jim Bound Message-Id: <199911211943.OAA0000000468@quarry.zk3.dec.com> To: Brian Zill Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 01:14:42 PST." <3D2036E25376D31197A100805FEAD892712F14@RED-MSG-02> Date: Sun, 21 Nov 1999 14:43:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> If one should add a scope-id to the address >> in a string representation as you suggest >> it no longer is an IPv6 Address by any standard >> we have today. Hence, it should have its own >> API for parsing. This should not be a change >> to the APIs that work with IPv6 addresses. > >So as long as we retain the current behavior of inet_pton, inet_ntop, >getipnodebyaddr and getipnodebyname for backwards compatibility with >existing deployed applications, you'll be happy? Or at least quit >complaining? I resent your coment using the word "complaining". But will not say more and will let you imagine what I want to say to you. I am discussing an issue with you and others. I have no problem changing anything as long as its well thought out and will work and is considerate of what has been deployed. /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 Sun Nov 21 11:52:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALJp7D25447 for ipng-dist; Sun, 21 Nov 1999 11:51:07 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALJowc25440 for ; Sun, 21 Nov 1999 11:50:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA21869 for ; Sun, 21 Nov 1999 11:50:57 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21906 for ; Sun, 21 Nov 1999 12:50:56 -0700 (MST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 92E6A104C76; Sun, 21 Nov 1999 13:50:56 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 9EA66BC4D5; Sun, 21 Nov 1999 13:50:50 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 3AC91B2A42; Sun, 21 Nov 1999 13:50:50 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000001160; Sun, 21 Nov 1999 14:50:55 -0500 (EST) From: Jim Bound Message-Id: <199911211950.OAA0000001160@quarry.zk3.dec.com> To: Brian Zill Cc: "'sm@bossette.engr.sgi.com'" , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 01:46:33 PST." <3D2036E25376D31197A100805FEAD892712F16@RED-MSG-02> Date: Sun, 21 Nov 1999 14:50:55 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk brian, Not liking sitelocal addresses has nothing to do with the API. The API is just a symptom of the core problem. And those standards are not full standards and not even draft standards so they can be changed. And right now if I saw a last call for the addressing stuff to draft standard I would object. So I am glad this discussion got started because until about 2 weeks ago I would have supported the specs but because folks want to make this really integrated and force it down we need to get it right or get rid of it. So its a good thing we are having this discussion. And I resent you denigrating the value of the API which is the most exposed part of IPv6 to many users. Of course if you have not shipped IPv6 you could not really understand this practically, but only theoretically. And if one is not working on a production stack in engineering then I can realise that the API would have less weight to such a viewpoint than mine. /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 Sun Nov 21 12:01:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALJwka25481 for ipng-dist; Sun, 21 Nov 1999 11:58:46 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALJwbc25474 for ; Sun, 21 Nov 1999 11:58:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA22179 for ; Sun, 21 Nov 1999 11:58:36 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22781 for ; Sun, 21 Nov 1999 12:58:36 -0700 (MST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 0DE245787C; Sun, 21 Nov 1999 13:58:36 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 340B5BC4EA; Sun, 21 Nov 1999 13:58:30 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id BFA20B2A43; Sun, 21 Nov 1999 13:58:29 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000001957; Sun, 21 Nov 1999 14:58:34 -0500 (EST) From: Jim Bound Message-Id: <199911211958.OAA0000001957@quarry.zk3.dec.com> To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: bzill@microsoft.com (Brian Zill), ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 02:20:17 PST." <199911211020.CAA45338@bossette.engr.sgi.com> Date: Sun, 21 Nov 1999 14:58:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Sam, >I guess this does require an update to the rfc/draft but doesn't >break the API (btw I'm still unclear if Jim objects as strongly to >reving the inet-draft as he does to breaking the API). putting my co-author hat on now for RFC 2553 (not my architect or implementors view which is much different OK). Once we agree to the answer that solves the problem at hand we will take that input and rev another version of RFC 2553. I think how we know when the answer is completed will help when we get Carl's write up on the API and Carl is also doing a write up on the whole scope-id issue and I think Brian has defined that part well. They we need to make sure all other ideas are dead or we have consenus. Then I will start writing. Then I will put out a draft of the changes for this work. The WG can review it and XNET. We move forward here. As an author though I will have to really search hard if we break binary compatibility and will need vendor input and some market input on such a decision. I have already scheduled time in my work load as this will be a task I bet around January 2000 for me. I think the discussion and review of what Carl will do will take this long. with my rfc co-author hat on only, /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 Sun Nov 21 12:19:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALKDuX25524 for ipng-dist; Sun, 21 Nov 1999 12:13:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALKDlc25516 for ; Sun, 21 Nov 1999 12:13:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA22708 for ; Sun, 21 Nov 1999 12:13:45 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27390 for ; Sun, 21 Nov 1999 12:13:45 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 10A129A81D; Sun, 21 Nov 1999 14:13:45 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 30E24BC4EB; Sun, 21 Nov 1999 14:13:39 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id B4994B2A45; Sun, 21 Nov 1999 14:13:38 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000004380; Sun, 21 Nov 1999 15:13:44 -0500 (EST) From: Jim Bound Message-Id: <199911212013.PAA0000004380@quarry.zk3.dec.com> To: Brian Zill Cc: "'sm@bossette.engr.sgi.com'" , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 03:14:04 PST." <3D2036E25376D31197A100805FEAD892712F18@RED-MSG-02> Date: Sun, 21 Nov 1999 15:13:43 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not dropping the deprecation of site-local unless the entire space is made very clear not just for APIs. I don't want to have to change the API after we do it next time at least for scope-ids and this issue. /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 Sun Nov 21 12:34:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALKR0d25579 for ipng-dist; Sun, 21 Nov 1999 12:27:00 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALKQqc25572 for ; Sun, 21 Nov 1999 12:26:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA23240 for ; Sun, 21 Nov 1999 12:26:51 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00065 for ; Sun, 21 Nov 1999 12:26:50 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 18600104C0D; Sun, 21 Nov 1999 14:26:50 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 299EDBC4EB; Sun, 21 Nov 1999 14:26:44 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id ABF83B2A42; Sun, 21 Nov 1999 14:26:43 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000006059; Sun, 21 Nov 1999 15:26:48 -0500 (EST) From: Jim Bound Message-Id: <199911212026.PAA0000006059@quarry.zk3.dec.com> To: Robert Elz Cc: itojun@iijlab.net, Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 21 Nov 1999 22:55:56 +1100." <12612.943185356@munnari.OZ.AU> Date: Sun, 21 Nov 1999 15:26:48 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, >I think it might be a good idea to simply forget about standardising this >(in any form - including informational recommendations) until we have a >better general sense of what is needed, where, and why. This is going to >mean that implementations are all going to do different things, and users >won't get any consistency - but that's normal in an immature product, which >site & link local addressing certainly is (while there are kind of analogs in >IPv4, when you look closely, they're really nothing like the same at all). I agree with you in this mail. I have had to respond to several offline queries and my real issue is that it would be good if we nail this down for once and for all before we make further changes. If we go off now and change things then I fear we will be changing them again as we learn more about them. This IMO is not wise. I have no issue having pain as an early implementor of a standard. But I think there are tests of reaonability to such pain, or we will not get early implementors of standards, in the IETF. I do think the idea whoever proposed it to incorporate the scope-id in the address is a good one. But what I have also learned is that the addressing specs as far as scoped-addresses and I think especially site-local would have no business or are ready for draft standard. This is a tell-tale sign of IPv6 I for one am not happy about and believe it will now hurt IPv6. We should have left IMO opinion IPv6 with global and link-local addresses and left the site-local out. The arguments that they help with renumbering and permit private address space are not worth the trouble as global addresses are plentiful for IPv6 and we should just work harder on the renumbering problems. /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 Sun Nov 21 13:02:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALKxnV25619 for ipng-dist; Sun, 21 Nov 1999 12:59:49 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALKxcc25612 for ; Sun, 21 Nov 1999 12:59:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA13882 for ; Sun, 21 Nov 1999 12:59:37 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA29183 for ; Sun, 21 Nov 1999 13:59:36 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 12:59:29 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 12:59:29 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F19@RED-MSG-02> From: Brian Zill To: "'JINMEI Tatuya / ????'" , kre@munnari.OZ.AU Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 12:59:25 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: jinmei@isl.rdc.toshiba.co.jp > > Robert Elz said: > > The difference here is who gets the pain. In the > > first it is the application programmers, who have > > to manage to provide a (fairly) consistent user > > interface and deal with it all over the place. > > In the second it is the users who have to figure > > out when they need to add the stray extra syntax, > > and what it should be > > I think that users will get the pain in the former approach as well; I agree with Jinmei, the user pain is at least as bad in the non-standard format case as in the standard format case. I won't argue that the standard format case is pain-free, but it is certainly easier for a user to remember a consistent syntax that works across all commands than to remember all the different flags that the various commands take (since it's unlikely that they'll be consistent). I agree with both Robert and Jinmei that the standard format case is easier for the programmer. > I agree that we need try to get the general sense, but I belive we > should do now. I think that IPv6 is now fairly mature and that (at > least) the semantics, usage, and importance of link-local addresses > are clear enough. I agree again. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 13:27:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALLOsM25658 for ipng-dist; Sun, 21 Nov 1999 13:24:54 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALLOic25651 for ; Sun, 21 Nov 1999 13:24:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA03907 for ; Sun, 21 Nov 1999 13:24:43 -0800 (PST) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA01877 for ; Sun, 21 Nov 1999 14:24:42 -0700 (MST) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 13:22:58 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 13:22:58 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F1A@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 13:22:57 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > From: Jim Bound > > >> It may make revisiting the api easier :---).... > > > Adopting it would break binary compatibility with > > existing apps, which I thought you were against. > > Not at all. I said it would make it easier. > If I get back an adress like this: > > fe80::FUZZY::1 with getipnodebyname we would strip out > the fuzzy at the resolver and stick it in sin6_scope_id. > > 1) we would need new flag for getipnodebyname > to pass sockaddr_in6 > 2) change hostent to be different in backwards > compatible way > 3) shoot getipnodebyname in the head and > use getaddrinfo Is this an acceptable solution for you? It is for me. But what you're describing here isn't the "Robert Elz proposal" (for lack of a better name -- thanks Robert for clearing that up). Robert's proposal is to change all uses of in6_addr to contain embedded scope ids. This includes the sockaddr_in6 sin6_addr field, which means we'd no longer need or want the separate sin6_scope_id field. Thus my claim that adopting this proposal would break binary compatibility with the existing API (which has the sin6_scope_id field). > > At the risk of repeating myself a billion times, > > the same issue exists for link-local addresses. > > Getting rid of site-local addresses would not make > > this issue go away. > > Well I am not going to repeat my self I have already > answered you on this twice. I'm sorry you feel that way, Jim. I have read and reread your messages on this subject, and nothing you've said makes me think that this issue doesn't exist for link-local addresses. --Brian > > /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 Sun Nov 21 13:45:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALLhRQ25693 for ipng-dist; Sun, 21 Nov 1999 13:43:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALLhHc25686 for ; Sun, 21 Nov 1999 13:43:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA25475 for ; Sun, 21 Nov 1999 13:43:15 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA03712 for ; Sun, 21 Nov 1999 14:43:15 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 13:41:35 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 13:41:35 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F1B@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 13:41:32 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > >> If one should add a scope-id to the address > >> in a string representation as you suggest > >> it no longer is an IPv6 Address by any standard > >> we have today. Hence, it should have its own > >> API for parsing. This should not be a change > >> to the APIs that work with IPv6 addresses. > > > >So as long as we retain the current behavior of inet_pton, > >inet_ntop, getipnodebyaddr and getipnodebyname for backwards > >compatibility with existing deployed applications, you'll be > >happy? Or at least quit complaining? > > I resent your coment using the word "complaining". But will > not say more and will let you imagine what I want to say to you. I meant no negative connotations towards you by the use of the word "complaining". Feel free to change the last sentence to "... have no objections" or "... could live with". Either one would convey what I meant to say. > I am discussing an issue with you and others. > > I have no problem changing anything as long as > its well thought out and will work and is considerate > of what has been deployed. Good, I feel the same way. I think everything I've discussed has been considerate of what has been deployed. You convinced me at IETF that we shouldn't change the API in a way that is not backwards binary compatible, and I haven't been arguing anything else. I hope nobody comes up with a convincing argument for doing so, I don't think anyone has so far. --Brian > > /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 Sun Nov 21 14:55:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALMqkc25741 for ipng-dist; Sun, 21 Nov 1999 14:52:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALMqbc25734 for ; Sun, 21 Nov 1999 14:52:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA06733 for ; Sun, 21 Nov 1999 14:52:38 -0800 (PST) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00614 for ; Sun, 21 Nov 1999 14:52:37 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id OAA12358; Sun, 21 Nov 1999 14:48:25 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA83144; Sun, 21 Nov 1999 14:52:31 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id OAA46568; Sun, 21 Nov 1999 14:52:29 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911212252.OAA46568@bossette.engr.sgi.com> Subject: Re: Textual Address Change for Scope-IDs To: ignatios@cs.uni-bonn.de (Ignatios Souvatzis) Date: Sun, 21 Nov 1999 14:52:29 -0800 (PST) Cc: bzill@microsoft.com, ipng@sunroof.eng.sun.com In-Reply-To: <19991121114816.A6240@theory.cs.uni-bonn.de> from "Ignatios Souvatzis" at Nov 21, 99 11:48:16 am X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios Souvatzis wrote: > > On Sun, Nov 21, 1999 at 02:27:44AM -0800, Sam Manthorpe wrote: > > > > Either there's a misunderstanding or I missed something. I'm > > thinking: ping . The kernel doesn't know what > > interface to use so it does ND on all of them. The first reply > > it gets wins. I don't get the connection with interface identifier > > numbers, but it _is_ late. > > uhm... shouldn't you have a routing table set up to use site local addresses? Sorry, I mean not . The point was that you can solve the link-local address ambiguity using simultaneous ND on each interface. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 15:11:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALN8nA25772 for ipng-dist; Sun, 21 Nov 1999 15:08:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALN8ec25765 for ; Sun, 21 Nov 1999 15:08:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA28228 for ; Sun, 21 Nov 1999 15:08:41 -0800 (PST) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03897 for ; Sun, 21 Nov 1999 15:08:40 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA02441; Sun, 21 Nov 1999 15:04:25 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA84595; Sun, 21 Nov 1999 15:03:00 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA47996; Sun, 21 Nov 1999 15:02:58 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911212302.PAA47996@bossette.engr.sgi.com> Subject: Re: Textual Address Change for Scope-IDs To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 21 Nov 1999 15:02:58 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <12612.943185356@munnari.OZ.AU> from "Robert Elz" at Nov 21, 99 10:55:56 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > I am not in the slightest worried about users getting confused by these > things - your average user should *never* see a hex format IPv6 address, > only a domain name format). The few remaining users, those that do have > to deal with these things can learn this extra bit of trivia as easily as > they can learn about mask and compare type operations, longest match, etc. > The hard part of that learning is to appreciate why it is necessary to > specify this extra piece of info, when it is "obvious to everyone" that > there is only one node anywhere I can reach with the address I am entering. > Once that is grasped, the detail of the syntax of where the number is > written is minor. I think that isn't the real issue. The problem with textual representation of IPv6 addresses with embedded scope-ids is that they are not portable between nodes. This is a real issue; one that will many sysadmin shell scripts to fail. Or even internally on the same node. If you physically unplug interface on a node then very likely the scope-id of interface will have changed when the machine is booted. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 15:19:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALNITd25803 for ipng-dist; Sun, 21 Nov 1999 15:18:29 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALNHkc25795 for ; Sun, 21 Nov 1999 15:17:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA07440 for ; Sun, 21 Nov 1999 15:17:06 -0800 (PST) Received: from pneumatic-tube.sgi.com (pneumatic-tube.sgi.com [204.94.214.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13953 for ; Sun, 21 Nov 1999 16:17:05 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by pneumatic-tube.sgi.com (980327.SGI.8.8.8-aspam/980310.SGI-aspam) via ESMTP id PAA07762; Sun, 21 Nov 1999 15:12:27 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA31374; Sun, 21 Nov 1999 15:11:05 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA47562; Sun, 21 Nov 1999 15:11:03 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911212311.PAA47562@bossette.engr.sgi.com> Subject: Re: Textual Address Change for Scope-IDs To: itojun@iijlab.net Date: Sun, 21 Nov 1999 15:11:03 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <19304.943187090@coconut.itojun.org> from "itojun@iijlab.net" at Nov 21, 99 09:24:50 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, itojun@iijlab.net wrote: > I can tell you about our experience. It sounds like you are already doing what I suggested in my mail yesterday (apologies for not having recognised that beforehand). Do you have inet_ntop() hide the fourth byte? In the current IRIX prototype, we have have netstat print scoped addresses in the form: link1:fe80::... I agree that this, or the reverse KAME representation, is a good thing for reducing user confusion. Your solutions sounds like a good one to me and you have had real-world exposure of it. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 15:25:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALNN0k25833 for ipng-dist; Sun, 21 Nov 1999 15:23:00 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALNMpc25826 for ; Sun, 21 Nov 1999 15:22:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA19936 for ; Sun, 21 Nov 1999 15:22:51 -0800 (PST) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA14599 for ; Sun, 21 Nov 1999 16:22:51 -0700 (MST) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 15:22:25 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 15:22:25 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CC41209@RED-MSG-50> From: Richard Draves To: sm@bossette.engr.sgi.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 15:22:25 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is another possibility which I don't think has been considered > yet: > > Put the scope-id in the in6_addr in the same way as > KAME do (did?) it, _but_ only in the binary instances > of the address, never in textual representation. > > In other words, getipnodebyname() would give you an in6_addr > with the scope-id inserted near the top of the address, > but functions like inet_ntop() would ignore that byte, > interpreting it as zero, so that the user never actually > sees it's there. This is an intriguing idea, but I haven't decided yet if it's good or bad. Let me rephrase it (maybe change it a little): - the in6_addr binary representation would take some of the currently unused bits in link-local, site-local (and multicast? did we ever figure out if sin6_scope_id is used for multicast?) addresses for storing the scope-id. - however, in the textual representation those bits would appear to be zero and the scope-id would be indicated with a separate delimiter character and number, like the jinmei draft. For example (assuming a 16-bit scopeid): binary representation is fe80 0001 0000 0000 0a00 46ff fe04 6747 text representation is 1/fe80::a00:46ff:fe04:6747 or fe80::a00:46ff:fe04:6747@1 > This has the following advantages: > > 1) Solves the problem of scope-id ambiguity of addresses > created by getipnodebyname() and inet_pton(). > > 2) The textual representation of IPv6 addresses > seen by the > user (and passed around from app to app, system to system) > would not contain the scope-id and would thus be > completely portable, as they should be. > > 3) No changes to applications. > > 4) No changes to the API docs. > > 5) Doesn't break the API or ABI. > > I don't _think_ this exactly what KAME are doing, is it? I'm assuming > not. > > I can't think of any disadvantages to this scheme, but I'm sure > somebody else on the list can :-) The disadvantage of this scheme is that everything that takes a binary IPv6 address and puts it on the wire needs to be cognizant of the special scope-id bits and zero them out. For the IPv6 stack itself, this isn't such a big deal. However applications put binary addresses into data streams that go on the wire. So it would impact applications. The counter-argument is, applications that are putting scoped addresses into their data streams probably need to know what they are doing anyway, or else they'll screw up and send the scoped address outside of its scope zone. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 15:46:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dALNhn925865 for ipng-dist; Sun, 21 Nov 1999 15:43:49 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dALNhec25858 for ; Sun, 21 Nov 1999 15:43:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA29371 for ; Sun, 21 Nov 1999 15:43:40 -0800 (PST) Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16945 for ; Sun, 21 Nov 1999 16:43:40 -0700 (MST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA06907; Sun, 21 Nov 1999 15:43:32 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA99990; Sun, 21 Nov 1999 15:43:29 -0800 (PST) mail_from (sm@bossette.engr.sgi.com) Received: (from sm@localhost) by bossette.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) id PAA04906; Sun, 21 Nov 1999 15:43:25 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199911212343.PAA04906@bossette.engr.sgi.com> Subject: Re: Textual Address Change for Scope-IDs To: richdr@microsoft.com (Richard Draves) Date: Sun, 21 Nov 1999 15:43:24 -0800 (PST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101CC41209@RED-MSG-50> from "Richard Draves" at Nov 21, 99 03:22:25 pm X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, Richard Draves wrote: > This is an intriguing idea, but I haven't decided yet if it's good or bad. > > Let me rephrase it (maybe change it a little): > - the in6_addr binary representation would take some of the currently unused > bits in link-local, site-local (and multicast? did we ever figure out if > sin6_scope_id is used for multicast?) addresses for storing the scope-id. > - however, in the textual representation those bits would appear to be zero > and the scope-id would be indicated with a separate delimiter character and > number, like the jinmei draft. > > For example (assuming a 16-bit scopeid): > binary representation is fe80 0001 0000 0000 0a00 46ff fe04 6747 > text representation is 1/fe80::a00:46ff:fe04:6747 or > fe80::a00:46ff:fe04:6747@1 Yes, exactly. Thanks for the example. > The disadvantage of this scheme is that everything that takes a binary IPv6 > address and puts it on the wire needs to be cognizant of the special > scope-id bits and zero them out. For the IPv6 stack itself, this isn't such > a big deal. However applications put binary addresses into data streams that > go on the wire. So it would impact applications. Good point. I agree that those who write apps that send binary addresses over the while should know what they are doing. However, it does introduce a backwards compatability problem for legacy apps who are not expecting the embedded scope-ids. This problem can be solved in part for getipnodebyname() by adding a flag requesting embedded scope-id and changing AI_DEFAULT to include that new flag. inet_ntop() is more problematic. -- Sam ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 16:30:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM0Rtd25898 for ipng-dist; Sun, 21 Nov 1999 16:27:55 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM0Rkc25891 for ; Sun, 21 Nov 1999 16:27:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA22508 for ; Sun, 21 Nov 1999 16:27:46 -0800 (PST) Received: from newman.itea.ntnu.no (newman.itea.ntnu.no [129.241.18.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22614 for ; Sun, 21 Nov 1999 17:27:45 -0700 (MST) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by newman.itea.ntnu.no (8.9.3/8.9.3) with ESMTP id BAA14955; Mon, 22 Nov 1999 01:27:49 +0100 (MET) From: Stig Venaas Received: (from venaas@localhost) by alfa.itea.ntnu.no (8.7.3/8.7.3) id BAA25266; Mon, 22 Nov 1999 01:28:22 +0100 (MET) Message-ID: <19991122012821.A23983@itea.ntnu.no> Date: Mon, 22 Nov 1999 01:28:21 +0100 To: Sam Manthorpe , Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs References: <4D0A23B3F74DD111ACCD00805F31D8101CC41209@RED-MSG-50> <199911212343.PAA04906@bossette.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199911212343.PAA04906@bossette.engr.sgi.com>; from Sam Manthorpe on Sun, Nov 21, 1999 at 03:43:24PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, Nov 21, 1999 at 03:43:24PM -0800, Sam Manthorpe wrote: > > Good point. I agree that those who write apps that send binary addresses > over the while should know what they are doing. However, it does introduce > a backwards compatability problem for legacy apps who are not expecting > the embedded scope-ids. I think some apps that pass binary addresses might have to pass scope-id as well. I've had a hard time figuring out what to think of scope-ids. It really depends a lot on what they are. If a scope-id is just an interface identifier, it won't make sense using them in DNS, scripts etc. and I think things could get messy quite easily. I tend to think that link- local doesn't belong in DNS at all, site-local might be possible, using Jim's idea of looking at the scope for the interface the DNS lookup was sent from. Users really shouldn't have to know what interface to use though. If scope-ids should be something else, there must be some way to configure what the id should be, and the id allocation might have to be administered, one could perhaps use AS-numbers for site-local scope-id. If one ends up administrating id's, why not just use global addresses? I actually think that we can cope without scope-ids for site-local addresses. In most cases where two sites are interconnected, they would have global addresses in order to have communication between internal hosts at the two sites. One could then use global addresses for all communications, or at least for traffic originating at border hosts. Stig -- Stig Venaas UNINETT/NTNU -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 21 18:09:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM27G726015 for ipng-dist; Sun, 21 Nov 1999 18:07:16 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM277c26008 for ; Sun, 21 Nov 1999 18:07:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA13634 for ; Sun, 21 Nov 1999 18:07:07 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA16674 for ; Sun, 21 Nov 1999 18:07:04 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA22196; Mon, 22 Nov 1999 13:04:58 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Mon, 22 Nov 1999 02:28:29 +0900." <14392.11197.544972.85469U@condor.isl.rdc.toshiba.co.jp> Date: Mon, 22 Nov 1999 13:04:58 +1100 Message-Id: <20289.943236298@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 22 Nov 1999 02:28:29 +0900 From: JINMEI Tatuya Message-ID: <14392.11197.544972.85469U@condor.isl.rdc.toshiba.co.jp> | I agree that we need try to get the general sense, but I belive we | should do now. I think that IPv6 is now fairly mature and that (at | least) the semantics, usage, and importance of link-local addresses | are clear enough. Part of IPv6 are now getting quite mature - but the usage of other than global unicast addresses isn't one of those parts. There simply aren't enough big enough sites that are seriously using IPv6 for the various "wouldn't it be great if I could ..." ideas to have been discovered, let alone tested yet. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 18:20:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM2FOL26041 for ipng-dist; Sun, 21 Nov 1999 18:15:24 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM2FFc26034 for ; Sun, 21 Nov 1999 18:15:16 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA13998 for ; Sun, 21 Nov 1999 18:15:15 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA18653 for ; Sun, 21 Nov 1999 18:14:34 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA23369; Mon, 22 Nov 1999 13:13:41 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: sm@bossette.engr.sgi.com (Sam Manthorpe) Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Sun, 21 Nov 1999 15:02:58 -0800." <199911212302.PAA47996@bossette.engr.sgi.com> Date: Mon, 22 Nov 1999 13:13:40 +1100 Message-Id: <20368.943236820@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 21 Nov 1999 15:02:58 -0800 (PST) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-ID: <199911212302.PAA47996@bossette.engr.sgi.com> | I think that isn't the real issue. The problem with textual | representation of IPv6 addresses with embedded scope-ids is that | they are not portable between nodes. This is a real issue; one | that will many sysadmin shell scripts to fail. Or even internally | on the same node. If you physically unplug interface on a node | then very likely the scope-id of interface will have changed | when the machine is booted. If the ids are simply being forced by the kernel, then yes, they would. But in that case, so would 1/FE... (or ...@1) type addresses. As a user interface, having the kernel simply assign sequential numbers is nice and simple, and for some uses, might be the best. But for more general functional useability, I think those identifiers need to be sysadmin assigned - probably via an arg to ifconfig (or whatever is like it). Then they can remain stable, whatever the user interface looks like. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 18:26:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM2PGM26072 for ipng-dist; Sun, 21 Nov 1999 18:25:16 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM2P7c26065 for ; Sun, 21 Nov 1999 18:25:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA14671 for ; Sun, 21 Nov 1999 18:25:07 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA07738 for ; Sun, 21 Nov 1999 19:21:54 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA23054; Mon, 22 Nov 1999 13:10:51 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Jim Bound Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Sun, 21 Nov 1999 14:32:56 CDT." <199911211932.OAA0000031277@quarry.zk3.dec.com> Date: Mon, 22 Nov 1999 13:10:46 +1100 Message-Id: <20341.943236646@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 21 Nov 1999 14:32:56 -0500 From: Jim Bound Message-ID: <199911211932.OAA0000031277@quarry.zk3.dec.com> | This is where Robert Elz's propsal shines. We embed the scope in the | address and pull it out when we use the address in any manner this way | the DNS works, the user don't have to key in scopes, etc... Ah ... no .. I certainly don't think it is possible to stick embedded scopes into addresses in the DNS - that would force them to be consistent everywhere (everyone would have to be using the same values, and I doubt that is possible). Except when they are the only addresses, in a private DNS, I don't believe anything but global addresses should be in the DNS at all. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 18:38:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM2ZcV26107 for ipng-dist; Sun, 21 Nov 1999 18:35:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM2ZUc26100 for ; Sun, 21 Nov 1999 18:35:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA28833 for ; Sun, 21 Nov 1999 18:35:29 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA09920 for ; Sun, 21 Nov 1999 19:35:26 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id CA19251; Mon, 22 Nov 1999 13:23:50 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Stig Venaas Cc: Sam Manthorpe , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Mon, 22 Nov 1999 01:28:21 BST." <19991122012821.A23983@itea.ntnu.no> Date: Mon, 22 Nov 1999 13:23:45 +1100 Message-Id: <20399.943237425@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 22 Nov 1999 01:28:21 +0100 From: Stig Venaas Message-ID: <19991122012821.A23983@itea.ntnu.no> | If one ends up administrating id's, why not just use global addresses? This again all comes down to what you think the less than global scope addresses are to be used for, One use that I think everyone seens is as a kind of replacement for IPv4 "private" addresses (net 10 and the like) for disconnected sites. That is, if global addresses come only from your upstream site (to get aggregation to work) and there is no generic "assign me a global address without me telling you where I will connect it, as I don't know, and might never" type service anywhere, then some other kind of address needs to be available, and link local and site local, can fill that need. That much is pretty simple, and if that is the only use, then in a sense scope-ids aren't needed (link locals would be used when there is only one link - and for the purposes defined to require them, which need no scopes as they're already bound to interfaces - there would only be one site local address). However, another theory is that site local addresses (or link local when it works) ought to be used for *all* communications between nodes when they can work, to insulate those connections from changes to global addressing (your local fileserver to client connections don't all die because you have changed provider - they can remain stable for years). If that is what ends up happening, then we do need to cope with the nodes with more than one local zone (for link locals, this means everything with more than one interface). Again, I just don't think we have enough experience with the possibilities of such things yet to actually make a decision. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 20:04:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM42Al26181 for ipng-dist; Sun, 21 Nov 1999 20:02:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM420c26174 for ; Sun, 21 Nov 1999 20:02:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA22043 for ; Sun, 21 Nov 1999 20:01:59 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA23575 for ; Sun, 21 Nov 1999 21:01:58 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 21 Nov 1999 20:01:52 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Nov 1999 20:01:52 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F1D@RED-MSG-02> From: Brian Zill To: "'sm@bossette.engr.sgi.com'" , "'tim@mentat.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Sun, 21 Nov 1999 20:01:49 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can someone (Tim?) who remembers the discussion regarding this proposal from three (?) years ago summarize why the working group decided not to pursue this direction and instead choose to have the separate sin6_scope_id field? Besides the couple of issues discussed below and in Itojun's mail, the only other argument against it that is immediately apparent to me is that switching to this scheme would break backwards binary compatibility for apps that currently expect the sockaddr_in6 struct to contain a sin6_scope_id field. And that obviously wasn't an issue back then. Was there some other showstopper argument? Thanks, --Brian Sam Manthorpe wrote: > Richard Draves wrote: > > This is an intriguing idea, but I haven't decided > > yet if it's good or bad. > > > > Let me rephrase it (maybe change it a little): > > - the in6_addr binary representation would take > > some of the currently unused bits in link-local, > > site-local (and multicast? did we ever figure > > out if sin6_scope_id is used for multicast?) > > addresses for storing the scope-id. > > - however, in the textual representation those > > bits would appear to be zero and the scope-id > > would be indicated with a separate delimiter > > character and number, like the jinmei draft. > > > > For example (assuming a 16-bit scopeid): > > binary representation is > > fe80 0001 0000 0000 0a00 46ff fe04 6747 > > text representation is > > 1/fe80::a00:46ff:fe04:6747 or > > fe80::a00:46ff:fe04:6747@1 > > Yes, exactly. Thanks for the example. > > > The disadvantage of this scheme is that everything > > that takes a binary IPv6 address and puts it on the > > wire needs to be cognizant of the special scope-id > > bits and zero them out. For the IPv6 stack itself, > > this isn't such a big deal. However applications > > put binary addresses into data streams that > > go on the wire. So it would impact applications. > > Good point. I agree that those who write apps that > send binary addresses over the while should know what > they are doing. However, it does introduce a backwards > compatability problem for legacy apps who are not > expecting the embedded scope-ids. > > This problem can be solved in part for getipnodebyname() > by adding a flag requesting embedded scope-id and > changing AI_DEFAULT to include that new flag. > inet_ntop() is more problematic. > > -- Sam > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Sam Manthorpe, SGI. tel: (650)933-2856 fax: (650)932-2856 > sm@engr.sgi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 21:03:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM51AO26218 for ipng-dist; Sun, 21 Nov 1999 21:01:10 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM510c26211 for ; Sun, 21 Nov 1999 21:01:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA10960 for ; Sun, 21 Nov 1999 21:01:00 -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 VAA02332 for ; Sun, 21 Nov 1999 21:00:58 -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 OAA28355; Mon, 22 Nov 1999 14:00:41 +0900 (JST) To: sm@bossette.engr.sgi.com (Sam Manthorpe) cc: ipng@sunroof.eng.sun.com In-reply-to: sm's message of Sun, 21 Nov 1999 15:11:03 PST. <199911212311.PAA47562@bossette.engr.sgi.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Mon, 22 Nov 1999 14:00:41 +0900 Message-ID: <28353.943246841@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >itojun@iijlab.net wrote: >> I can tell you about our experience. >It sounds like you are already doing what I suggested in my mail >yesterday (apologies for not having recognised that beforehand). >Do you have inet_ntop() hide the fourth byte? No, we do the following processing in the userland manually: - grab address from, say, routing socket it has sockaddr_in6, with: sin6_addr: fe80:1::x:y:z:u sin6_scope_id: 0 - if scoped address is returned, userland code modifies it before printing sin6_addr: fe80::x:y:z:u sin6_scope_id: 1 - then, give the sockaddr_in6 to getnameinfo() to get: "fe80::x:y:z:u@link" The above userland tweak is a temporary solution for us. I think the right thing to do is to fix kernel routing socket to return sockaddr_in6 with scope_id field properly filled in (i.e. never show embedded form to the userland). >In the current IRIX prototype, we have have netstat print scoped >addresses in the form: link1:fe80::... I agree that this, or the >reverse KAME representation, is a good thing for reducing user confusion. >Your solutions sounds like a good one to me and you have had >real-world exposure of it. Do you have getaddrinfo(3) that does "link1:fe80::x:y:z:u"? In that case, the above story will be the same. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 21:54:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM5qBn26295 for ipng-dist; Sun, 21 Nov 1999 21:52:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM5q0c26288 for ; Sun, 21 Nov 1999 21:52:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA18855 for ; Sun, 21 Nov 1999 21:51:59 -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 VAA16838 for ; Sun, 21 Nov 1999 21:51:58 -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 OAA29217; Mon, 22 Nov 1999 14:50:23 +0900 (JST) To: Jim Bound cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Sun, 21 Nov 1999 14:32:56 EST. <199911211932.OAA0000031277@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Mon, 22 Nov 1999 14:50:23 +0900 Message-ID: <29215.943249823@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Here are step-by-step description of reasons: >>- If you have two or more interfaces on a node, and/or if you have >> reachability to multiple sites, you MUST disambiguate destination >> somehow, for EVERY IPv6 operation you would make >> (telnet, ftp, ping6, rsh, ssh, whatever). >I don't agree. If you are telneting to another node you should just >specify a destination address as a user whether its in the same scope-id >or not users SHOULD NOT have to type ftp FUZZY|FEC0::1 OR ftp FUZZY >FEC0::1 that is unacceptable. Same for ftp, ping, rsh, ssh, whatever >and I also think having ping6 or ping4 is bogus and it should just be >ping. But for sysadmin commands like ifconfig that is an entirely >different manner. ping4/ping6 is not the point of this topic so I'm going to ignore the word above. Hope you are okay with it. >Are you saying that a user must need to know the scope-id in >addition to the IPv6 address when it keys in the dst address for ftp, >telnet, ping etc.. If so I strongly disagree with you and if this were >true IPv6 is dead right now in the market. It also completely broke the >key concept of Ipv6 which is simplicity and that it is extensible to the >IPv4 architecture. Fortuneately I think you have just shown though an >error in your thinking about this problem most likely. You cannot >specify the dst scope-id for an address at the client, you have know way >of knowning. And for the apps your listing we don't and should not have >to specify the source address. Aha, this is the point... I strongly disagree with you Jim. What should happen if you do "telnet fe80::x" when you have fe80::x on both side of your multi-interface host, like the diagram I included in the previous email? Just pick them at random? That is not user friendly and unpredictable. Also, it becomes very trivial to do trojan horse on your telnet attempt. I can just place an PC with fe80::x on it, onto your 3rd interface (and your multi-interface host will pick my PC in 33% of possibility). User needs to disambiguate the destination, by specifying 16bits of in6_addr and scope_id. Otherwise bad guy will be coming to do trojan-horse on you. Also, there's NO draft that says "if you have multiple candidate zones you MUST transmit NS to all the candidate zones". This needs to be clarified before we go on. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 21 22:46:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM6hsC26328 for ipng-dist; Sun, 21 Nov 1999 22:43:54 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM6hhc26321 for ; Sun, 21 Nov 1999 22:43:43 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA16984 for ; Sun, 21 Nov 1999 22:43:42 -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 WAA01815 for ; Sun, 21 Nov 1999 22:43:41 -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 PAA29770 for ; Mon, 22 Nov 1999 15:43:39 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Mon, 22 Nov 1999 14:50:23 JST. <29215.943249823@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Mon, 22 Nov 1999 15:43:39 +0900 Message-ID: <29768.943253019@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Also, it becomes very trivial to do trojan horse on your telnet > attempt. I can just place an PC with fe80::x on it, onto your 3rd > interface (and your multi-interface host will pick my PC in 33% of > possibility). User needs to disambiguate the destination, by > specifying 16bits of in6_addr and scope_id. Otherwise bad guy will > be coming to do trojan-horse on you. typo. "128bytes of in6_addr, and scope_id" (or 16bytes). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 22 01:59:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAM9vJ826473 for ipng-dist; Mon, 22 Nov 1999 01:57:19 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAM9vAc26466 for ; Mon, 22 Nov 1999 01:57:11 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA01213 for ; Mon, 22 Nov 1999 01:57:10 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03313 for ; Mon, 22 Nov 1999 01:57:07 -0800 (PST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id UAA17509; Mon, 22 Nov 1999 20:54:52 +1100 (EST) Date: Mon, 22 Nov 1999 20:54:52 +1100 (EST) From: Peter Tattam To: Jim Bound cc: Robert Elz , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: <199911212026.PAA0000006059@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 21 Nov 1999, Jim Bound wrote: > Robert, > > >I think it might be a good idea to simply forget about standardising this > >(in any form - including informational recommendations) until we have a > >better general sense of what is needed, where, and why. This is going to > >mean that implementations are all going to do different things, and users > >won't get any consistency - but that's normal in an immature product, which > >site & link local addressing certainly is (while there are kind of analogs in > >IPv4, when you look closely, they're really nothing like the same at all). > > I agree with you in this mail. I have had to respond to several offline > queries and my real issue is that it would be good if we nail this down > for once and for all before we make further changes. If we go off now > and change things then I fear we will be changing them again as we learn > more about them. This IMO is not wise. > > I have no issue having pain as an early implementor of a standard. But > I think there are tests of reaonability to such pain, or we will not get > early implementors of standards, in the IETF. > > I do think the idea whoever proposed it to incorporate the scope-id in > the address is a good one. I thought it was a logical solution to the issue - assumed it was discarded originally for some reason, hence the search for an alternative since the standard was laid in concrete. > > But what I have also learned is that the addressing specs as far as > scoped-addresses and I think especially site-local would have no > business or are ready for draft standard. This is a tell-tale sign of > IPv6 I for one am not happy about and believe it will now hurt IPv6. > We should have left IMO opinion IPv6 with global and link-local addresses > and left the site-local out. The arguments that they help with > renumbering and permit private address space are not worth the trouble > as global addresses are plentiful for IPv6 and we should just work > harder on the renumbering problems. > > /jim > Jim, the fact that this earlier alternative was (erroneously?) discarded is an argument in favour for *NOT* rushing standards, which I believe you have been pushing for. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 22 04:05:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAMC3Of26587 for ipng-dist; Mon, 22 Nov 1999 04:03:24 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAMC3Ec26580 for ; Mon, 22 Nov 1999 04:03:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA29425 for ; Mon, 22 Nov 1999 04:03:11 -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 EAA15592 for ; Mon, 22 Nov 1999 04:03:11 -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 HAA29557; Mon, 22 Nov 1999 07:03:05 -0500 (EST) Message-Id: <199911221203.HAA29557@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-scoped-routing-02.txt Date: Mon, 22 Nov 1999 07:03:05 -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 : Routing of Scoped Addresses in the Internet Protocol Version 6 (IPv6) Author(s) : B. Haberman Filename : draft-ietf-ipngwg-scoped-routing-02.txt Pages : 6 Date : 19-Nov-99 This document outlines a mechanism for generating forwarding tables that include scoped IPv6 addresses. It defines a set of rules for routers to implement in order to forward packets addressed to scoped unicast or multicast addresses regardless of the routing protocol. These rules apply to all scoped addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoped-routing-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-scoped-routing-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-scoped-routing-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: <19991119105009.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-scoped-routing-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-scoped-routing-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991119105009.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 22 07:40:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAMFbj726747 for ipng-dist; Mon, 22 Nov 1999 07:37:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAMFbYc26740 for ; Mon, 22 Nov 1999 07:37:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA29963 for ; Mon, 22 Nov 1999 07:37:33 -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 IAA08968 for ; Mon, 22 Nov 1999 08:37:32 -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 JAA04044; Mon, 22 Nov 1999 09:29:52 -0600 (CST) Message-Id: <199911221529.JAA04044@gungnir.fnal.gov> To: itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Sun, 21 Nov 1999 17:52:25 +0900. <18252.943174345@coconut.itojun.org> Date: Mon, 22 Nov 1999 09:29:52 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm convinced. Not about the particular example of "@" as the separator, but about the general approach. Itojun wrote: > [...] > Jim, I think you are not getting the reason why jinmei came up > with the draft. Please read the following and share the problem > with us. It is very long, but please read it patiently ... 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 Mon Nov 22 10:36:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAMIXls27009 for ipng-dist; Mon, 22 Nov 1999 10:33:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAMIXac27002 for ; Mon, 22 Nov 1999 10:33:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA25724 for ; Mon, 22 Nov 1999 10:33:35 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01455 for ; Mon, 22 Nov 1999 11:33:33 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA28881; Mon, 22 Nov 1999 10:33:09 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA08904; Mon, 22 Nov 1999 10:33:07 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id KAA01470; Mon, 22 Nov 1999 10:34:04 -0800 (PST) Date: Mon, 22 Nov 1999 10:34:04 -0800 (PST) From: Tim Hartrick Message-Id: <199911221834.KAA01470@feller.mentat.com> To: sm@bossette.engr.sgi.com, bzill@microsoft.com Subject: RE: Textual Address Change for Scope-IDs Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > > Can someone (Tim?) who remembers the discussion regarding this proposal from > three (?) years ago summarize why the working group decided not to pursue > this direction and instead choose to have the separate sin6_scope_id field? > > Besides the couple of issues discussed below and in Itojun's mail, the only > other argument against it that is immediately apparent to me is that > switching to this scheme would break backwards binary compatibility for apps > that currently expect the sockaddr_in6 struct to contain a sin6_scope_id > field. And that obviously wasn't an issue back then. Was there some other > showstopper argument? > Well it didn't really happen that way. The working group rejected embedding the interface identifier in the addresses but those opposed to the embedding didn't really make a counter proposal on how to deal with the inherent ambiguity of this address type. There were at least a couple implementations at the the time that were using this trick but were actually transmitting the bits on the wire. Once the working group decided not to do the embedding the implementations stopped putting the bits on the wire. At the time, all of the discussion really centered around link/interface identification. Nobody had really been paying attention to the site-local address issue. Some number of IETFs later (I think the second LA?) there was a long drawn out discussion about how site local addresses were supposed to work. There was a camp which insisted that the site boundaries should go through links so that we could avoid the inherent ambiguity which would result if site boundaries went through nodes. The other camp argued that it was more natural to have site boundaries go through nodes even though this caused multi-sited ambiguity. The link boundary folks lost the day (I was in this camp). It was after this discussion that I started to think that it was essential that we come up with a standard API mechanism to deal with the interface and site ambiguity issue. I wasn't the first to think this. The KAME (then WIDE) folks had broached the subject quite a while before. The working group just didn't get it at the time. Now the arguments that killed the embedding solution were largely akin to the arguments we are seeing now. There was also a general unhappiness with attempting to identify links with some bits "stolen" from the middle of the address. Since these bits are only meaningful within the node, putting them on the wire was frowned upon. I am having trouble summerizing the arguments made by the opponents. This is for a couple of reasons. First, at the time I was arguing the other side and second most of this argument occured at an IETF meeting. I can't recall which one so I can't provide a pointer to the minutes. It was one of the San Jose meetings I think. I am sure I have some of the facts and chronology incorrect but that is the best I can do without looking through archives and minutes. In any event, at this point I am opposed to trying this embedding idea. We have the tools we need to solve this problem without stepping back in time three years. In retrospect I believe that I was wrong to favor this em- bedding approach at that time. It is a quick and dirty way to make a multi- homed node work but it is (no offense intended) a hack. We can make things work without embedding scope information in the addresses and without breaking existing binaries anymore than they are already broken. We should just do that. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 22 11:31:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAMJSQ827085 for ipng-dist; Mon, 22 Nov 1999 11:28:26 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAMJSHc27078 for ; Mon, 22 Nov 1999 11:28:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA13114; Mon, 22 Nov 1999 11:28:15 -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 MAA28891; Mon, 22 Nov 1999 12:28:14 -0700 (MST) Received: from darkstar.iprg.nokia.com (root@darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id LAA04085; Mon, 22 Nov 1999 11:27:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id LAA12348; Mon, 22 Nov 1999 11:27:40 -0800 X-Virus-Scanned: Mon, 22 Nov 1999 11:27:40 -0800 Nokia Silicon Valley Email Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma012270; Mon, 22 Nov 99 11:27:34 -0800 Message-Id: <4.2.2.19991122112058.03932030@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 22 Nov 1999 11:25:37 -0800 To: narten@raleigh.ibm.com, nordmark@eng.sun.com From: Bob Hinden Subject: Request to Advance "DNS Extensions to Support IPv6 Address Aggregation and Renumbering" Cc: scoya@ietf.org, deering@cisco.com, 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 a Proposed Standard: Title : DNS Extensions to Support IPv6 Address Aggregation and Renumbering Author(s) : M. Crawford, C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-06.txt Pages : 18 Date : 17-Nov-99 A working group last call for this document was completed on November 18, 1999 and the document was discussed at the IPng w.g. session held at the Washington, DC IETF. Also, the Namedroppers list was notified of the intent to advance this document to Proposed Standard. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 22 14:02:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAMLwZE27229 for ipng-dist; Mon, 22 Nov 1999 13:58:35 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAMLwVc27222 for ; Mon, 22 Nov 1999 13:58:31 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA18158 for ipng@sunroof.eng.sun.com; Mon, 22 Nov 1999 13:58:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAMLncc27204 for ; Mon, 22 Nov 1999 13:49:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA25126 for ; Mon, 22 Nov 1999 13:49:36 -0800 (PST) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29214 for ; Mon, 22 Nov 1999 14:49:35 -0700 (MST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by breeze.research.telcordia.com (8.9.3/8.9.3) with ESMTP id QAA18336; Mon, 22 Nov 1999 16:49:17 -0500 (EST) Received: from seascape.bellcore.com (pptpdhcp25.research.telcordia.com [192.4.9.250]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id QAA10385; Mon, 22 Nov 1999 16:49:11 -0500 (EST) Message-Id: <4.1.19991122163348.0096c410@mailee.research.telcordia.com> X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 22 Nov 1999 16:45:49 -0500 To: Tim Hartrick , sm@bossette.engr.sgi.com, bzill@microsoft.com From: Christian Huitema Subject: RE: Textual Address Change for Scope-IDs Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911221834.KAA01470@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have always considered the "site address" an atrocious leftover of Net 10, and the more I see this discussion unfolding, the stronger my conviction. I can swallow the unidentified link address -- such address are necessary for autoconfig. But I have a very hard time trying to understand what exactly is good in the site address format: 1) It does not exactly simplify autoconfig, since one has to program some form of site identifier in the nodes, 2) It cannot be stored in a directory, 3) It should not be routed, but then it has to be propagated for the needs of mobile nodes, 4) It is very hard to handle in multisited nodes. It seems that allowing some actual identifier, or magic number, or whatever, in the uppermost bits of the site addresses would go a long way towards solving the problem. Consider an address form of , where "site-id" is a flat binary identifier: 1) It can be autoconfigured through router advertisements, 2) It can be stored in the DNS, and the hosts can easily be instructed to only use an address of this format if the "site-id" matches one of the sites to which they belong, 3) Routers can easily be instructed to only forward the site id that they recognize, and to ignore all other ids, thus limiting possible leakage, 4) Multi-sited hosts can use classic routing techniques to direct site-addressed packets to the most appropriate interface, or tunnel. It may be too late to get rid of the site-id entirely. But we could very well start experimenting with the insertion of magicg numbers in the structure, or maybe with an alternate address format. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 22 18:39:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAN2RnP27518 for ipng-dist; Mon, 22 Nov 1999 18:27:49 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAN2Rdc27511 for ; Mon, 22 Nov 1999 18:27:39 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA840636; Mon, 22 Nov 1999 18:27:37 -0800 (PST) Date: Mon, 22 Nov 1999 18:27:37 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Textual Address Change for Scope-IDs To: Sam Manthorpe Cc: Jim Bound , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199911210610.WAA44630@bossette.engr.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is another possibility which I don't think has been considered > yet: > > Put the scope-id in the in6_addr in the same way as > KAME do (did?) it, _but_ only in the binary instances > of the address, never in textual representation. This assumes that applications always use inet_ntop or equivalent when they pass the address to a peer over the wire. I think such an assumption is dangerous - I've seen too much IPv4 code which just prints the octets and is not using inet_ntoa. If this will be the case for IPv6 applications the effect would be that they will fail in off ways when using less than global scope addresses. It will be a pain to debug such problems due to the "hiding" of the scope id. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 22 18:53:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAN2lZU27543 for ipng-dist; Mon, 22 Nov 1999 18:47:36 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAN2lRc27536 for ; Mon, 22 Nov 1999 18:47:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA26760; Mon, 22 Nov 1999 18:47:26 -0800 (PST) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA18888; Mon, 22 Nov 1999 19:47:23 -0700 (MST) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id CAA06594; Tue, 23 Nov 1999 02:47:22 GMT Message-Id: <199911230247.CAA06594@orchard.arlington.ma.us> To: Erik Nordmark cc: Sam Manthorpe , Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Message from Erik Nordmark of "Mon, 22 Nov 1999 18:27:37 PST." Date: Mon, 22 Nov 1999 21:47:21 -0500 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the other hand, I think the ipv6 textual format is sufficiently more complicated that programmers will be significantly less likely to roll their own. Also, with the KAME representation, the scope-id isn't "hidden" if you cheat this way; it's actually fairly visible, in the second 16-bit word of the address.. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 23 08:32:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dANGTs327925 for ipng-dist; Tue, 23 Nov 1999 08:29:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dANGTjc27918 for ; Tue, 23 Nov 1999 08:29:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA18107; Tue, 23 Nov 1999 08:29:45 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02885; Tue, 23 Nov 1999 09:29:43 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA21234; Tue, 23 Nov 1999 17:29:34 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id RAA04648; Tue, 23 Nov 1999 17:29:32 +0100 (MET) Message-Id: <199911231629.RAA04648@givry.inria.fr> From: Francis Dupont To: Erik Nordmark cc: itojun@iijlab.net, matt@3am-software.com, ipng@sunroof.eng.sun.com Subject: Re: 2292bis comment In-reply-to: Your message of Fri, 19 Nov 1999 13:31:08 PST. Date: Tue, 23 Nov 1999 17:29:21 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I have a comment about 2292bis-01, chapter 3.2 (ICMPv6 filter). > What is the semantics of raw socket with ICMPv6 filter? > I can imagine several interpretations: > a. it will throw any ICMPv6 packet to the userland, regardless of > ICMPv6 checksum nor any validation failure. > b. it will throw ICMPv6 packet to the userland, only if it > passes ICMPv6 checksum check. the kernel does not do further > validations. > c. it will throw ICMPv6 packet to the userland, only if it looks > completely okay to the kernel (checksum is okay and all validations > are passed). => I have implemented c) because I give the packet to the raw input routine only when the kernel has finished to deal with it. b) makes the most sense to me. "All validations" can not be true in general since it requires the kernel to know about all future ICMP based protocols, which is impossible. => it is possible to be not so hard in validation checks, for instance I discard unknown types only when they are not information types. You could say e.g. "all validations for icmp types ..." but that would be different for different implementations. => there are some common rules but I agree they should be written down (not only in the source code). Thus from the perspective of the application it can not assume that the protocol stack knows about a particular ICMP type thus it must do the validation checks in the application. => in any case it is better to do validation checks twice than none, then application MUST do them! Francis.Dupont@inria.fr PS: the final text should be open, ie. kernel can do some further (then checksum) validations. PPS: the real problem is to know if the kernel should deal with ICMP interesting packets before or after give them to the application. (note that before/after semantic is not clear on a multi-processor) I believe no assumption is the best answer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 23 09:29:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dANHQo028001 for ipng-dist; Tue, 23 Nov 1999 09:26:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dANHQdc27994 for ; Tue, 23 Nov 1999 09:26:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA18455; Tue, 23 Nov 1999 09:26:38 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00818; Tue, 23 Nov 1999 10:26:37 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA03580; Tue, 23 Nov 1999 09:26:58 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA02665; Tue, 23 Nov 1999 09:26:58 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id JAA01837; Tue, 23 Nov 1999 09:27:55 -0800 (PST) Date: Tue, 23 Nov 1999 09:27:55 -0800 (PST) From: Tim Hartrick Message-Id: <199911231727.JAA01837@feller.mentat.com> To: Erik.Nordmark@eng.sun.com, Francis.Dupont@inria.fr Subject: Re: 2292bis comment Cc: itojun@iijlab.net, matt@3am-software.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, The processing sequence we use is: 1) Verify checksum. If it fails the checksum then discard it. 2) Allow the kernel to process ICMPv6 messages types in which it is interested. If the ICMPv6 message fails any validity check during this processing then discard it. 3) Apply the socket's filter. If the socket has requested the ICMPv6 message's type pass the ICMPv6 message to the socket. 4) Repeat step 3 for each socket that is listening for ICMPv6 messages. In general it seems to me that if the kernel knows a message is in- valid it shouldn't waste the application's time by passing it out to user space. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 23 16:16:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAO0DVo28534 for ipng-dist; Tue, 23 Nov 1999 16:13:32 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAO0DMc28527 for ; Tue, 23 Nov 1999 16:13:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA04296 for ; Tue, 23 Nov 1999 16:13:23 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08502 for ; Tue, 23 Nov 1999 16:13:18 -0800 (PST) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Tue, 23 Nov 1999 18:12:20 -0600 Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XHBWCHAC; Tue, 23 Nov 1999 19:12:12 -0500 Received: from sbishop.corpeast.baynetworks.com (SBISHOP [132.245.132.172]) by zbl6c002.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id WM2PX0CW; Tue, 23 Nov 1999 19:12:11 -0500 Message-Id: <3.0.32.19991123190635.0102cb6c@ZBL6C002.corpeast.baynetworks.com> X-Sender: scbishop@ZBL6C002.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 23 Nov 1999 19:06:35 -0500 To: ipng@sunroof.eng.sun.com From: "Scott Bishop" Subject: IPv6 Conference Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Another article on IPV6. I hadn't seen it come across the list yet. I thought folks might be interested. Regards, Scott >Date: Mon, 22 Nov 1999 14:59:59 -0500 (EST) >From: Dan Joyal >X-Sender: djoyal@milwaukee >To: "Bishop, Scott (S.B.) [EXCHANGE:BL60:DS49-M]" >cc: "Wood, Susanna (S.C.) [EXCHANGE:BL60:495-I]" >Subject: IPv6 Conference > > >Here's the URL for the "Government Computer News" IPv6 conference article. > >http://www.gcn.com/vol18_no36/news/948-1.html > >-Dan > - Scott E. Bishop IP Product Line Manager Multi-Media Enterprise Division Enterprise Solutions Nortel Networks Phone: (978) 288-8329 or ESN 248-8329 or X88329 Pager: (800) 309-0387 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 23 17:33:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAO1V2h28645 for ipng-dist; Tue, 23 Nov 1999 17:31:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAO1Upc28638 for ; Tue, 23 Nov 1999 17:30:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA19018 for ; Tue, 23 Nov 1999 17:30:52 -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 RAA10953 for ; Tue, 23 Nov 1999 17:30:51 -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 KAA27211; Wed, 24 Nov 1999 10:30:43 +0900 (JST) To: Francis Dupont cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Tue, 23 Nov 1999 17:29:21 +0100. <199911231629.RAA04648@givry.inria.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: 2292bis comment From: itojun@iijlab.net Date: Wed, 24 Nov 1999 10:30:43 +0900 Message-ID: <27209.943407043@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> b) makes the most sense to me. >> "All validations" can not be true in general since it requires the >> kernel to know about all future ICMP based protocols, which is impossible. >=> it is possible to be not so hard in validation checks, for instance >I discard unknown types only when they are not information types. >> You could say e.g. "all validations for icmp types ..." >> but that would be different for different implementations. >=> there are some common rules but I agree they should be written down >(not only in the source code). If we put validation in the kernel before throwing packets to the userland, we will not be able to implement certain class of userland applications. example: a userland application that monitors and prints invalid ICMPv6 packets (maybe academic example...). We may be able to extend 2292 if there are high demand on it: putting "kernel's thoughts on validity of the packet" into ancillary data? (too much?) I would like to see some consensus here, and some explicit words in 2292bis. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 23 18:05:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAO23D628693 for ipng-dist; Tue, 23 Nov 1999 18:03:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAO232c28686 for ; Tue, 23 Nov 1999 18:03:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA23798 for ; Tue, 23 Nov 1999 18:03:02 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA07066 for ; Tue, 23 Nov 1999 19:03:02 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA05723; Tue, 23 Nov 1999 18:02:47 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id SAA13911; Tue, 23 Nov 1999 18:02:48 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id SAA02171; Tue, 23 Nov 1999 18:03:45 -0800 (PST) Date: Tue, 23 Nov 1999 18:03:45 -0800 (PST) From: Tim Hartrick Message-Id: <199911240203.SAA02171@feller.mentat.com> To: Francis.Dupont@inria.fr, itojun@iijlab.net Subject: Re: 2292bis comment Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > If we put validation in the kernel before throwing packets to the > userland, we will not be able to implement certain class of userland > applications. > example: a userland application that monitors and prints invalid > ICMPv6 packets (maybe academic example...). > You will be able to implement them. You just can't do it using an AF_INET6, SOCK_RAW, IPPROTO_ICMPV6 socket. This type of application can always be written using a link layer packet filter facility. There is a certain class of applications which should be written using link layer packet filters. Any application that is looking for packets which would otherwise be discarded by the layer above the link layer is in that class in my opinion. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 24 00:26:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAO8N9h29224 for ipng-dist; Wed, 24 Nov 1999 00:23:09 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAO8Mwc29217 for ; Wed, 24 Nov 1999 00:22:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA22512 for ; Wed, 24 Nov 1999 00:22:59 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA10700 for ; Wed, 24 Nov 1999 00:22:57 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id JAA09595; Wed, 24 Nov 1999 09:22:55 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id JAA15618; Wed, 24 Nov 1999 09:22:53 +0100 (MET) Message-Id: <199911240822.JAA15618@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: 2292bis comment In-reply-to: Your message of Wed, 24 Nov 1999 10:30:43 +0900. <27209.943407043@coconut.itojun.org> Date: Wed, 24 Nov 1999 09:22:39 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If we put validation in the kernel before throwing packets to the userland, we will not be able to implement certain class of userland applications. example: a userland application that monitors and prints invalid ICMPv6 packets (maybe academic example...). => for this kind of applications I believe something like BPF is better, it can give invalid IPv6 packets too (for instance with an anycast source address) and it can send them... Regards Francis.Dupont@inria.fr PS: I am still in favor of c) with a MAY for validations. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 24 09:31:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAOHRkn29461 for ipng-dist; Wed, 24 Nov 1999 09:27:46 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAOHRbc29454 for ; Wed, 24 Nov 1999 09:27:38 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA03702 for ; Wed, 24 Nov 1999 09:27:37 -0800 (PST) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA14148 for ; Wed, 24 Nov 1999 09:27:36 -0800 (PST) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Nov 1999 09:26:54 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Nov 1999 09:26:54 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA2172A@RED-MSG-50> From: Richard Draves To: "'itojun@iijlab.net'" , Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: RE: 2292bis comment Date: Wed, 24 Nov 1999 09:23:56 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If we put validation in the kernel before throwing > packets to the > userland, we will not be able to implement certain > class of userland > applications. > example: a userland application that monitors and prints invalid > ICMPv6 packets (maybe academic example...). I have not been following this discussion too closely (since we don't implement the advanced API), but a general thought - most applications will want "cooked" packets. A few applications (testing and the like) want "raw" packets, but they can have a different interface. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 24 13:48:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAOLjIe29668 for ipng-dist; Wed, 24 Nov 1999 13:45:18 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAOLjEc29661 for ; Wed, 24 Nov 1999 13:45:14 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA20501 for ipng@sunroof.eng.sun.com; Wed, 24 Nov 1999 13:44:51 -0800 (PST) Received: from antley.eng.sun.com (antley [129.146.86.225]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with SMTP id dAOLaIc29642 for ; Wed, 24 Nov 1999 13:36:19 -0800 (PST) Received: from antley by antley.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA03142; Wed, 24 Nov 1999 13:35:41 -0800 Message-Id: <199911242135.NAA03142@antley.eng.sun.com> Date: Wed, 24 Nov 1999 13:35:41 -0800 (PST) From: Carl Williams Reply-To: Carl Williams Subject: IPv6 Socket scrubber is available for downloading To: ipng@sunroof.eng.sun.com Cc: carlw@antley.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 2xnuerOkL2zsMfZSF/j88w== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As stated in my presentation at IETF-DC the IPv6 Socket scrubber would be made available for downloading. The IPv6 Socket scrubber is now out on the external web site: http://www.sun.com/solaris/ipv6 Enjoy! Carl -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 24 16:03:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAONxnx29800 for ipng-dist; Wed, 24 Nov 1999 15:59:49 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAONxcc29793 for ; Wed, 24 Nov 1999 15:59:39 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA263730; Wed, 24 Nov 1999 15:59:37 -0800 (PST) Date: Wed, 24 Nov 1999 15:59:25 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 2292bis comment To: Tim Hartrick Cc: Erik.Nordmark@eng.sun.com, Francis.Dupont@inria.fr, itojun@iijlab.net, matt@3am-software.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199911231727.JAA01837@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In general it seems to me that if the kernel knows a message is in- > valid it shouldn't waste the application's time by passing it out to user > space. Sure, but that doesn't provide any help for portable applications since they don't know what different kernel implementations will consider invalid. But for extensibility I don't think the kernel should be dropping unknown ICMP types - an application might want to use new types. In most cases those types will be informational but for extensibility I don't see any harm in passing up unknown error types (suject to the ICMP6_FILTER stuff). Thus what we can say in the 2292bis is something like: The protocol stack will verify the ICMPv6 checksum and discard any packets with invalid checksums. An implementation might perform additional validity checks on the ICMP message content and discard malformed packets. However, a portable application must not assume that such validity checks have been performed. The protocol stack should not automatically discard packets if the ICMP type is unknown to the stack. For extensibility reasons received ICMP packets with any type (informational or error) must be passed to the applications (subject to ICMP6_FILTER filtering on the type value and the checksum verification). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Nov 24 16:06:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAP04o029823 for ipng-dist; Wed, 24 Nov 1999 16:04:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAP04dc29816 for ; Wed, 24 Nov 1999 16:04:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA05012; Wed, 24 Nov 1999 16:04:38 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA03163; Wed, 24 Nov 1999 17:04:37 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA10332; Wed, 24 Nov 1999 16:04:59 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id QAA06374; Wed, 24 Nov 1999 16:05:00 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id QAA03822; Wed, 24 Nov 1999 16:05:56 -0800 (PST) Date: Wed, 24 Nov 1999 16:05:56 -0800 (PST) From: Tim Hartrick Message-Id: <199911250005.QAA03822@feller.mentat.com> To: Erik.Nordmark@eng.sun.com Subject: Re: 2292bis comment Cc: Francis.Dupont@inria.fr, itojun@iijlab.net, matt@3am-software.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > > In general it seems to me that if the kernel knows a message is in- > > valid it shouldn't waste the application's time by passing it out to user > > space. > > Sure, but that doesn't provide any help for portable applications > since they don't know what different kernel implementations will consider > invalid. > Yes. The applications may have to do what amounts to duplicate checking. As Francis said, double checking is better than none. > But for extensibility I don't think the kernel should be dropping unknown > ICMP types - an application might want to use new types. > In most cases those types will be informational but for extensibility > I don't see any harm in passing up unknown error types (suject to the > ICMP6_FILTER stuff). > Sure. Any stack that did that would be fubar, but I guess we need to say that explicitly and not leave it to chance. > Thus what we can say in the 2292bis is something like: > The protocol stack will verify the ICMPv6 checksum and discard > any packets with invalid checksums. > > An implementation might perform additional validity checks > on the ICMP message content and discard malformed packets. > However, a portable application must not assume that such > validity checks have been performed. > > The protocol stack should not automatically discard packets if > the ICMP type is unknown to the stack. For extensibility reasons > received ICMP packets with any type (informational or error) > must be passed to the applications (subject to ICMP6_FILTER filtering > on the type value and the checksum verification). > Sounds find to me. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 26 06:04:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAQE1JX00480 for ipng-dist; Fri, 26 Nov 1999 06:01:19 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAQE19c00473 for ; Fri, 26 Nov 1999 06:01:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA12586 for ; Fri, 26 Nov 1999 06:01:11 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA20393 for ; Fri, 26 Nov 1999 06:00:56 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id 433419AA3D; Fri, 26 Nov 1999 08:00:55 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 25E5C4FB04; Fri, 26 Nov 1999 08:00:49 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id AE9DC4C907; Fri, 26 Nov 1999 08:00:48 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000016600; Fri, 26 Nov 1999 09:00:53 -0500 (EST) From: Jim Bound Message-Id: <199911261400.JAA0000016600@quarry.zk3.dec.com> To: Robert Elz Cc: Jim Bound , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Mon, 22 Nov 1999 13:10:46 +1100." <20341.943236646@munnari.OZ.AU> Date: Fri, 26 Nov 1999 09:00:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 21 Nov 1999 14:32:56 -0500 From: Jim Bound Message-ID: <199911211932.OAA0000031277@quarry.zk3.dec.com> | This is where Robert Elz's propsal shines. We embed the scope in the | address and pull it out when we use the address in any manner this way | the DNS works, the user don't have to key in scopes, etc... >Ah ... no .. I certainly don't think it is possible to stick embedded >scopes into addresses in the DNS - that would force them to be consistent >everywhere (everyone would have to be using the same values, and I doubt >that is possible). Except when they are the only addresses, in a private >DNS, I don't believe anything but global addresses should be in the DNS at >all. Then you disagree with Erik's proposal for site prefixes? I think Sam made a good argument about why not to embed them in the DNS (le0 crashes and comes back up in different site). I would like to see us all agree that ONLY global addresses are in the DNS for sure. That would be progress. thanks /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 Nov 26 06:26:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAQENYP00504 for ipng-dist; Fri, 26 Nov 1999 06:23:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAQENPc00497 for ; Fri, 26 Nov 1999 06:23:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA27326 for ; Fri, 26 Nov 1999 06:23:26 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27707 for ; Fri, 26 Nov 1999 06:23:21 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 3A2581521AF; Fri, 26 Nov 1999 08:23:16 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 02CD84FB04; Fri, 26 Nov 1999 08:23:10 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 954984C909; Fri, 26 Nov 1999 08:23:09 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000009299; Fri, 26 Nov 1999 09:23:15 -0500 (EST) From: Jim Bound Message-Id: <199911261423.JAA0000009299@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Mon, 22 Nov 1999 14:50:23 +0900." <29215.943249823@coconut.itojun.org> Date: Fri, 26 Nov 1999 09:23:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Itojun, >>>Here are step-by-step description of reasons: >>>- If you have two or more interfaces on a node, and/or if you have >>> reachability to multiple sites, you MUST disambiguate destination >>> somehow, for EVERY IPv6 operation you would make >>> (telnet, ftp, ping6, rsh, ssh, whatever). >>I don't agree. If you are telneting to another node you should just >>specify a destination address as a user whether its in the same scope-id >>or not users SHOULD NOT have to type ftp FUZZY|FEC0::1 OR ftp FUZZY >>FEC0::1 that is unacceptable. Same for ftp, ping, rsh, ssh, whatever >>and I also think having ping6 or ping4 is bogus and it should just be >>ping. But for sysadmin commands like ifconfig that is an entirely >>different manner. > ping4/ping6 is not the point of this topic so I'm going to ignore > the word above. Hope you are okay with it. I am OK with that I was trying to see if that was a tell tale sign of your implementation choice but I guess not. >>Are you saying that a user must need to know the scope-id in >>addition to the IPv6 address when it keys in the dst address for ftp, >>telnet, ping etc.. If so I strongly disagree with you and if this were >>true IPv6 is dead right now in the market. It also completely broke the >>key concept of Ipv6 which is simplicity and that it is extensible to the >>IPv4 architecture. Fortuneately I think you have just shown though an >>error in your thinking about this problem most likely. You cannot >>specify the dst scope-id for an address at the client, you have know way >>of knowning. And for the apps your listing we don't and should not have >>to specify the source address. But let me verify something. I believe you are NOT saying the user must know the scope_id for the dst address to use an app? I believe you are saying the user must convey the source scope_id for the src of communications? Which is correct above? > Aha, this is the point... > I strongly disagree with you Jim. What should happen if you do > "telnet fe80::x" when you have fe80::x on both side of your > multi-interface host, like the diagram I included in the previous > email? Just pick them at random? That is not user friendly and > unpredictable. Well for link-local I think this is bogus and link-local addresses should only be used for ND, DHCPv6, ifconfig, and control protocols they should not be permitted to be used for higher layer apps. But I also think a link-local address should never be used as a source address when the destination address is global either. link-local addresses is an address that most users should not even know about. But I don't agree it is not user friendly and if we must figure this out it must be done without the user having to know about scope-ids. > Also, it becomes very trivial to do trojan horse on your telnet > attempt. I can just place an PC with fe80::x on it, onto your 3rd > interface (and your multi-interface host will pick my PC in 33% of > possibility). User needs to disambiguate the destination, by > specifying 16bits of in6_addr and scope_id. Otherwise bad guy will > be coming to do trojan-horse on you. If we do not put scope-ids in the DNS how does one know the scope-id as a user for destinations in the first place. The way to fix this for link-local is to extend ND to state that if a end node has more than one physical link the end node must make sure that NO link-local address have been duplicated across multiple links. nodeX / \ link FUZZY to nodeY link CLEAR to nodeZ | | nodeY nodeZ fe80::1 fe80::2 So during the DAD phase of Addrconf nodeX would inform either nodeY or nodeZ if they have both configured the address fe80::1. Details could be discussed if we want to visit this path. But this problem should be fixed in ND + Addrconf not by hacking it to work with APIs and DNS or other mechanisms. > Also, there's NO draft that says "if you have multiple candidate > zones you MUST transmit NS to all the candidate zones". This needs > to be clarified before we go on. I am saying above that may in fact be required. /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 Nov 26 06:53:35 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAQEoNc00524 for ipng-dist; Fri, 26 Nov 1999 06:50:23 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAQEoEc00517 for ; Fri, 26 Nov 1999 06:50:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA19043 for ; Fri, 26 Nov 1999 06:50:15 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07517 for ; Fri, 26 Nov 1999 06:50:15 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 9A7DC104BC7; Fri, 26 Nov 1999 08:50:14 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 68553BC4F2; Fri, 26 Nov 1999 08:50:08 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id DC2E5B2A46; Fri, 26 Nov 1999 08:50:07 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id JAA0000002804; Fri, 26 Nov 1999 09:50:12 -0500 (EST) From: Jim Bound Message-Id: <199911261450.JAA0000002804@quarry.zk3.dec.com> To: Peter Tattam Cc: Jim Bound , Robert Elz , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Mon, 22 Nov 1999 20:54:52 +1100." Date: Fri, 26 Nov 1999 09:50:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Jim, the fact that this earlier alternative was (erroneously?) discarded is >an argument in favour for *NOT* rushing standards, which I believe you have >been pushing for. I agree we cannot rush them. But if something more than the API is radically broken with scopes more than the API we better fix it quick. I think we now have unearthed a basic flaw in the IPv6 architecture, but we will see. I hope I am wrong. /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 Nov 26 14:12:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAQMAGp00628 for ipng-dist; Fri, 26 Nov 1999 14:10:17 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAQMA5c00621 for ; Fri, 26 Nov 1999 14:10:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA09703 for ; Fri, 26 Nov 1999 14:10:04 -0800 (PST) Received: from itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA09753 for ; Fri, 26 Nov 1999 15:09:58 -0700 (MST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.8.8/3.7W) with ESMTP id HAA00820; Sat, 27 Nov 1999 07:06:33 +0900 (JST) To: Jim Bound cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Fri, 26 Nov 1999 09:23:14 EST. <199911261423.JAA0000009299@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs cc: itojun@coconut.itojun.org From: Jun-ichiro itojun Hagino Date: Sat, 27 Nov 1999 07:06:33 +0900 Message-ID: <818.943653993@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>Are you saying that a user must need to know the scope-id in >>>addition to the IPv6 address when it keys in the dst address for ftp, >>>telnet, ping etc.. If so I strongly disagree with you and if this were >>>true IPv6 is dead right now in the market. It also completely broke the >>>key concept of Ipv6 which is simplicity and that it is extensible to the >>>IPv4 architecture. Fortuneately I think you have just shown though an >>>error in your thinking about this problem most likely. You cannot >>>specify the dst scope-id for an address at the client, you have know way >>>of knowning. And for the apps your listing we don't and should not have >>>to specify the source address. >But let me verify something. >I believe you are NOT saying the user must know the scope_id for the dst >address to use an app? First of all, don't think about DNS mapping here. Only think about numeric addresses. I am saying this. More correctly: If you transmit a packet to scoped destination, you need to disambiguate between existing scope zones (links or sites) and denote a single scope zone by the time you reach IPv6 layer. There are several chances to disambiguate it. - User may specify it explicitly, by "ping6 -S link0 fe80::1" - If your node have only one interface, you have no other choice so you can make it a default interface. NOTE: you have loopback interface always, so actually you have to pick one of two interfaces if you have single ethernet outlet (loopback and ethernet). - If user did not specify, the node may be able to obey admin's decision somewhere on the node. This can be implemented by routing table (like "route add -inet6 fe80::/10 -interface foo"), or some configuration setup into the kernel. >I believe you are saying the user must convey the source scope_id for >the src of communications? >Which is correct above? If you send a packet to scoped destination address, scope zone must be made un-ambiguous before you reach IPv6 layer. >> I strongly disagree with you Jim. What should happen if you do >> "telnet fe80::x" when you have fe80::x on both side of your >> multi-interface host, like the diagram I included in the previous >> email? Just pick them at random? That is not user friendly and >> unpredictable. >Well for link-local I think this is bogus and link-local addresses >should only be used for ND, DHCPv6, ifconfig, and control protocols they >should not be permitted to be used for higher layer apps. But I also >think a link-local address should never be used as a source address when >the destination address is global either. link-local addresses is an >address that most users should not even know about. There are people trying to use link-local (zeroconf, dentist office) for real communication and we can't just ignore them. Also you have to support site-locals and multicast scopes. >But I don't agree it is not user friendly and if we must figure this out >it must be done without the user having to know about scope-ids. If you wish, you can let the node admin connfigure default scope zone. >> Also, it becomes very trivial to do trojan horse on your telnet >> attempt. I can just place an PC with fe80::x on it, onto your 3rd >> interface (and your multi-interface host will pick my PC in 33% of >> possibility). User needs to disambiguate the destination, by >> specifying 16bits of in6_addr and scope_id. Otherwise bad guy will >> be coming to do trojan-horse on you. >If we do not put scope-ids in the DNS how does one know the scope-id as >a user for destinations in the first place. DNS issues can be solved in multiple ways, and I believe it is VERY separate topic. I want you to think separately. I put a possible solution here, but THIS IS OUTSIDE OF THE KEY DISCUSSION. No, I never said that we are going to put scope-id into DNS. Global DNS tree MUST contain global addresses only. Local DNS tree must contain 128bit portion only, and it has no scope-id in it. There's no question here. If you have site-local connectivity, you are in situation where you are in firewalled world. You have connectivity to inside-firewall nodes, who uses fec0::/10 (like 10.0.0.0/8), and global cloud. You can have separate DNS tree for each of them, like: tree under internal.dec.com. which is reachable only in the firewall cloud (site-local DNS tree) tree under . (root) which is reachable worldwide (global DNS tree) You may need to configure extended /etc/resolv.conf to: contact DNS server for internal.dec.com first if you get the answer, scope id for sitelocal = 3 next, contact global DNS server if you get the answer, scope id for sitelocal = 0 (invalid) Then you kick getaddrinfo(3). What happens here will be: - you say getaddrinfo("jimbound"). - this is ambiguous and get disambiguated by DNS search order in /etc/resolv.conf, and if you configure "internal.dec.com" and "dec.com" you will have 3 FQDN candidates. jimbound.internal.dec.com. jimbound.dec.com. jimbound. - You will try to resolve them looking at extended /etc/resolv.conf. (1) you try to resolve jimbound.internal.dec.com with site-local name server. if there's an entry like below: jimbound.internal.dec.com. IN AAAA fec0::x you will get the following answer into struct addrinfo. scopeid is filled in by LOCAL RESOLVER: fec0::x, scopeid = 3 (2) next, you will contact global DNS server for jimbound.internal.dec.com. (I think you will need to contact regardless of failure or success of (1)). It will fail. (3) you will try to resolve jimbound.dec.com. with site-local DNS server. no entry on the database. (4) you will try to resolve jimbound.dec.com. you get jimbound.dec.com. IN AAAA 3ffe:9999::x and you will get following struct addrinfo. 3ffe:9999::x, scopeid = 0 (because it is global) As a result, you will have two entries for your query: fec0::x, scopeid = 3 3ffe:9999::x, scopeid = 0 (because it is global) This story never puts scopeid into DNS database, and works with multiple scope zones. >The way to fix this for link-local is to extend ND to state that if a >end node has more than one physical link the end node must make sure >that NO link-local address have been duplicated across multiple links. I strongly disagree. Admins are using interface id "1" or "2" all the time and it is impossible. If you take link-local scoped multicast address, you will have the same solicited node multicast address if you have two nodes on different side with same interface ID. The strategy never work if you think about site-locals (you have no help from ND) >> Also, there's NO draft that says "if you have multiple candidate >> zones you MUST transmit NS to all the candidate zones". This needs >> to be clarified before we go on. >I am saying above that may in fact be required. No NEVER, this way you can never make scoped addresses work. Scoped address will not going to vanish. Even if you may be able to nuke site-local scope at next IETF:-), you can never nuke link-local scope and multicast scopes. Link-locals are essential to ND (apparently), and there are scenarios (dentist office) and people (like zeroconf) who are trying to use link-locals in real communication. Therefore, we need to make scoped address work. Your policy (try to send packet to multiple zones) works only in the following situations and you make the problem narrower by dropping support for other cases: - for link-local, you are assuming that you do not see same fe80::x on both sides. Once you have same fe80::x on both sides by coincidence, you are doomed. - for site-local, you are assuming either (1) node is not placed at the site border (no node will be connected to two or more sites), or (2) there's no same address used in sites you are connected. Once you have two more or nodes, in different site, which uses the same fec0::x, you are doomed. This case is worse since if you send two TCP SYN, you are (a) bothering routers in both sites, (b) you may legally get two TCP SYN and bothering one of correct fec0::x. In any case, if you do not disambiguate scope zone you would like to send, as I wrote trojan horse attack is very easily possible. We (KAME team apparently, but others as well) have been thinking how scoped address should be handled, and we came to the fact we always need to disambiguate scope zones before we reach IPv6 layer like ip6_output(). 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 Nov 26 15:47:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAQNidX00675 for ipng-dist; Fri, 26 Nov 1999 15:44:39 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAQNiSc00668 for ; Fri, 26 Nov 1999 15:44:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA12931 for ; Fri, 26 Nov 1999 15:44:28 -0800 (PST) Received: from itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22677 for ; Fri, 26 Nov 1999 16:44:26 -0700 (MST) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.8.8/3.7W) with ESMTP id IAA01198 for ; Sat, 27 Nov 1999 08:37:00 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Sat, 27 Nov 1999 07:06:33 JST. <818.943653993@lychee.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: Jun-ichiro itojun Hagino Date: Sat, 27 Nov 1999 08:37:00 +0900 Message-ID: <1196.943659420@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Then you kick getaddrinfo(3). What happens here will be: > - you say getaddrinfo("jimbound"). > - this is ambiguous and get disambiguated by DNS search order in > /etc/resolv.conf, and if you configure "internal.dec.com" and > "dec.com" you will have 3 FQDN candidates. > jimbound.internal.dec.com. > jimbound.dec.com. > jimbound. > - You will try to resolve them looking at extended /etc/resolv.conf. > (1) you try to resolve jimbound.internal.dec.com with site-local > name server. if there's an entry like below: > jimbound.internal.dec.com. IN AAAA fec0::x > you will get the following answer into struct addrinfo. > scopeid is filled in by LOCAL RESOLVER: > fec0::x, scopeid = 3 > (2) next, you will contact global DNS server for > jimbound.internal.dec.com. (I think you will need to contact > regardless of failure or success of (1)). It will fail. > (3) you will try to resolve jimbound.dec.com. with site-local DNS > server. no entry on the database. > (4) you will try to resolve jimbound.dec.com. you get > jimbound.dec.com. IN AAAA 3ffe:9999::x > and you will get following struct addrinfo. > 3ffe:9999::x, scopeid = 0 (because it is global) Correction. normal resolver will not do (2) - (4). It terminates at (1) As a result of the above, you will have one entry for your query: fec0::x, scopeid = 3 Similarly, if you have configured DNS search order to: internal.compaq.com. internal.dec.com. dec.com. . (root) The resolver will query the following, in order: jimbound.internal.compaq.com. -> fec0::y, scopeid 2 jimbound.internal.dec.com. -> fec0::x, scopeid 3 jimbound.dec.com. -> 3ffe:9999::x, scopeid 0 jimbound. -> normally it does not exist The first one matched will be used. You will be configuring which scope zone (i.e. "internal.compaq" sitelocal cloud or "internal.dec" sitelocal cloud) to prefer, by DNS search order. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 28 06:06:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dASE49X01086 for ipng-dist; Sun, 28 Nov 1999 06:04:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dASE40c01079 for ; Sun, 28 Nov 1999 06:04:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA04268 for ; Sun, 28 Nov 1999 06:04:01 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA26238 for ; Sun, 28 Nov 1999 06:03:57 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id NA07235; Mon, 29 Nov 1999 00:58:40 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Jim Bound Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: Your message of "Fri, 26 Nov 1999 09:00:52 CDT." <199911261400.JAA0000016600@quarry.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Nov 1999 00:58:39 +1100 Message-Id: <14402.943797519@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 26 Nov 1999 09:00:52 -0500 From: Jim Bound Message-ID: <199911261400.JAA0000016600@quarry.zk3.dec.com> | Then you disagree with Erik's proposal for site prefixes? Yes. I haven't commented in detail because I haven't found the time to read it carefully enough to do that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 28 09:02:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dASGxvw01153 for ipng-dist; Sun, 28 Nov 1999 08:59:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dASGxmc01146 for ; Sun, 28 Nov 1999 08:59:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA04325 for ; Sun, 28 Nov 1999 08:59:48 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13709 for ; Sun, 28 Nov 1999 09:59:47 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA01567; Sun, 28 Nov 1999 17:59:45 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id RAA21531; Sun, 28 Nov 1999 17:59:44 +0100 (MET) Message-Id: <199911281659.RAA21531@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Wed, 17 Nov 1999 18:43:08 EST. <199911172343.SAA0000031684@quarry.zk3.dec.com> Date: Sun, 28 Nov 1999 17:59:43 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I agree with Itojun nearly at 100% because we have a common problem and we are still looking for the same kind of solutions (for instance I never like to embedded scope idea but now KAME people (users of this since) shout this is not a good idea then I can add more...). I'll try to find details in my 10 day mail buffer where I can say new things. Regards Francis.Dupont@inria.fr PS: I have ping and ping6 but it is not an implementation choice, just laziness (:-)... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 09:21:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dASHJb201181 for ipng-dist; Sun, 28 Nov 1999 09:19:37 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dASHJSc01174 for ; Sun, 28 Nov 1999 09:19:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA08287 for ; Sun, 28 Nov 1999 09:19:28 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10235 for ; Sun, 28 Nov 1999 09:19:28 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id SAA01762; Sun, 28 Nov 1999 18:19:25 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id SAA24068; Sun, 28 Nov 1999 18:19:24 +0100 (MET) Message-Id: <199911281719.SAA24068@givry.inria.fr> From: Francis Dupont To: Robert Elz cc: itojun@iijlab.net, Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Sun, 21 Nov 1999 22:55:56 +1100. <12612.943185356@munnari.OZ.AU> Date: Sun, 28 Nov 1999 18:19:22 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: | If you have a node with multiple interface/scope, sin6_scope_id is | *required* to disambiguate two scope instances ("zones" in Steve's | terminology). Yes, that is certainly true. => I believe that now near everybody agree? | Jim, what you are trying to push now is: | - modify every application that would specify sin6_scope_id, and | have additional command line option for them | (like "ping6 -I link fe80::x) That is fairly unreasonable - => this is NOT reasonable and ping/traceroute are not the only example where scoped & numerical addresses should be allowed. For instance when you have a major problem in your network you'd like to use a scoped & numerical address to do a telnet on your router (in this kind of case the DNS is the first thing which breaks :-). though I an not sure it is worse than ... => don't forget the user should always use *names* then when [s]he uses numerical addresses you can hammer h{i,e}s fingers. I think the weight of the hammer doesn't matter but I'd like to get a standard syntax. | - So, we needed to come up with uniform way to specify, or print, | scoped address notation. For now let us suppose that we agree to use | fe80::x@link. As a user interface, that sucks. => yes, using something which is not a name sucks... I have two (new?) arguments against the embedded scope idea: - a name is better than a local/volatile number (if the scope ID is an interface index, the index is by definition local to the node and on a laptop it can change and is essentially unpredictable (a name adds an indirection level which can solve these problems) - multicast addresses use scopes and I prefer to pick some bits for other purposes than to solve this issue (this argument applies to binary format too). Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 28 09:43:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dASHfBV01208 for ipng-dist; Sun, 28 Nov 1999 09:41:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dASHf2c01201 for ; Sun, 28 Nov 1999 09:41:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA18921 for ; Sun, 28 Nov 1999 09:41:02 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17225 for ; Sun, 28 Nov 1999 10:41:01 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id SAA02043; Sun, 28 Nov 1999 18:40:58 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id SAA15541; Sun, 28 Nov 1999 18:40:57 +0100 (MET) Message-Id: <199911281740.SAA15541@givry.inria.fr> From: Francis Dupont To: Robert Elz cc: Stig Venaas , Sam Manthorpe , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Mon, 22 Nov 1999 13:23:45 +1100. <20399.943237425@munnari.OZ.AU> Date: Sun, 28 Nov 1999 18:40:56 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: | If one ends up administrating id's, why not just use global addresses? => the best answer is the user should use names (in fact the user would like to use names for IPv4 and will *want* to use names for IPv6 :-). This again all comes down to what you think the less than global scope addresses are to be used for, => even we can get rid of site-local addresses (or apply Christian's idea) the problem remains for link-local addresses which are useful in some cases (mainly emmergency situations then I agree that common users should not use scoped & numerical addresses but I can't accept that all users must not use them). One use that I think everyone seens is as a kind of replacement for IPv4 "private" addresses (net 10 and the like) for disconnected sites. => I never have a concern about this use of site-local addresses. However, another theory is that site local addresses (or link local when it works) ought to be used for *all* communications between nodes when they can work, to insulate those connections from changes to global addressing (your local fileserver to client connections don't all die because you have changed provider - they can remain stable for years). => this will be the case if we adopt the address selection rules but this should be internally managed by the API, ie. the user will give a name and the right thing will happen. If that is what ends up happening, then we do need to cope with the nodes with more than one local zone (for link locals, this means everything with more than one interface). => there are nodes with more than one interface then the problem is *real*. Again, I just don't think we have enough experience with the possibilities of such things yet to actually make a decision. => I disagree. At the beginning we have no way to specified the outgoing interface then we have to wait the in6_pktinfo stuff which gave a solution for special cases (like RIPng tools) but not a general one. Then we have got RFC 2553 with the scope ID and the chance to get a general solution and to apply it to all applications, then we need a standard syntax (draft-ietf-ipngwg-scopedaddr-format-00.txt) and a way to use it in the API (current discussion). Unfortunately we have enough experience to know what we need... Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 28 09:51:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dASHoDv01235 for ipng-dist; Sun, 28 Nov 1999 09:50:13 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dASHo5c01228 for ; Sun, 28 Nov 1999 09:50:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09125 for ; Sun, 28 Nov 1999 09:50:05 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18037 for ; Sun, 28 Nov 1999 10:50:04 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id SAA02116; Sun, 28 Nov 1999 18:50:02 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id SAA20490; Sun, 28 Nov 1999 18:50:01 +0100 (MET) Message-Id: <199911281750.SAA20490@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: Robert Elz , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Fri, 26 Nov 1999 09:00:52 EST. <199911261400.JAA0000016600@quarry.zk3.dec.com> Date: Sun, 28 Nov 1999 18:50:00 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I would like to see us all agree that ONLY global addresses are in the DNS for sure. That would be progress. => I buy this! The DNS is by definition global and can't take care of locations, each time I've seen something which doesn't follow these principles it has failed (when I see a dual-head monster I'd like to cut a neck :-). But this remark doesn't apply to other name services (ie. tools which translate names to addresses) Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Nov 28 10:10:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dASI8Re01262 for ipng-dist; Sun, 28 Nov 1999 10:08:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dASI8Jc01255 for ; Sun, 28 Nov 1999 10:08:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA19768 for ; Sun, 28 Nov 1999 10:08:19 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21133 for ; Sun, 28 Nov 1999 10:08:18 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id TAA02371; Sun, 28 Nov 1999 19:08:17 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id TAA10285; Sun, 28 Nov 1999 19:08:16 +0100 (MET) Message-Id: <199911281808.TAA10285@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Fri, 26 Nov 1999 09:23:14 EST. <199911261423.JAA0000009299@quarry.zk3.dec.com> Date: Sun, 28 Nov 1999 19:08:15 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I strongly disagree with you Jim. What should happen if you do > "telnet fe80::x" when you have fe80::x on both side of your > multi-interface host, like the diagram I included in the previous > email? Just pick them at random? That is not user friendly and > unpredictable. => I'd like to add some multicast applications in examples because multicast addresses are as ambiguous as possible in this context... Well for link-local I think this is bogus and link-local addresses should only be used for ND, DHCPv6, ifconfig, and control protocols they should not be permitted to be used for higher layer apps. => this is not acceptable for me. You are trying to change a "should not" in a "must not". But I also think a link-local address should never be used as a source address when the destination address is global either. link-local addresses is an address that most users should not even know about. => I agree but this is not the point. But I don't agree it is not user friendly and if we must figure this out it must be done without the user having to know about scope-ids. => it is not user friendly to disallow something without necessity. The way to fix this for link-local is to extend ND to state that if a end node has more than one physical link the end node must make sure that NO link-local address have been duplicated across multiple links. => I don't know if this is possible to implement and I don't want this. Ambiguity is a property of the local scope idea, I think it is better to learn to live with it than to twist the model... Regards Francis.Dupont@inria.fr PS: your real problem is that getipnodebyxxx() should be updated, isn't it? About inet_ntop/pton() I believe a new set of functions can be defined because programmers should deal with *names* (in fact getipnodebyname() accepts numeric address string then this detail should get a low priority). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 10:41:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dASIcrl01290 for ipng-dist; Sun, 28 Nov 1999 10:38:53 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dASIcic01283 for ; Sun, 28 Nov 1999 10:38:44 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA20683 for ; Sun, 28 Nov 1999 10:38:44 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27952 for ; Sun, 28 Nov 1999 10:38:43 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id TAA02639; Sun, 28 Nov 1999 19:38:33 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id TAA22959; Sun, 28 Nov 1999 19:38:31 +0100 (MET) Message-Id: <199911281838.TAA22959@givry.inria.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: Jim Bound , ipng@sunroof.eng.sun.com, itojun@coconut.itojun.org Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Sat, 27 Nov 1999 07:06:33 +0900. <818.943653993@lychee.itojun.org> Date: Sun, 28 Nov 1999 19:38:25 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: First of all, don't think about DNS mapping here. Only think about numeric addresses. => because if you have a name the scope ID if needed will be automagically given by the name to address translation (by construction of this service). I am saying this. More correctly: If you transmit a packet to scoped destination, you need to disambiguate between existing scope zones (links or sites) and denote a single scope zone by the time you reach IPv6 layer. There are several chances to disambiguate it. - User may specify it explicitly, by "ping6 -S link0 fe80::1" - If your node have only one interface, you have no other choice so you can make it a default interface. NOTE: you have loopback interface always, so actually you have to pick one of two interfaces if you have single ethernet outlet (loopback and ethernet). - If user did not specify, the node may be able to obey admin's decision somewhere on the node. This can be implemented by routing table (like "route add -inet6 fe80::/10 -interface foo"), or some configuration setup into the kernel. => I think all current implementations use this kind of rule set, don't they? >But I don't agree it is not user friendly and if we must figure this out >it must be done without the user having to know about scope-ids. If you wish, you can let the node admin configure default scope zone. => not this can be the only solution because it is usually restricted to the node admin (ie. to modify the default zone each time you'd like to use a scoped & numerical address is not an acceptable solution even this works in many cases (but not all cases)). Scoped address will not going to vanish. Even if you may be able to nuke site-local scope at next IETF:-) => it will be enough to nuke multi-sited situations... you can never nuke link-local scope and multicast scopes. Link-locals are essential to ND (apparently), => in fact link-locals are essential to autoconfiguration. For instance link-locals make DHCPv6 far simpler than DHCP (I've found the real problem of DHCPv6, this is simply its name: if DHCPv6 was named ISFAA then it had been there since years :-). and there are scenarios (dentist office) => the simplest scenario: no router at all. and people (like zeroconf) who are trying to use link-locals in real communication. Therefore, we need to make scoped address work. => I agree!!! We (KAME team apparently, but others as well) have been thinking how scoped address should be handled, and we came to the fact we always need to disambiguate scope zones before we reach IPv6 layer like ip6_output(). => I was very happy to get with RFC 2553 a good and general solution for scope zones (far better than in6_pktinfo) and I'd like to use it with getipnodebyxxx(). I've changed my stack in order to carry a scope ID where it is needed and the behavior on a multi-interface node is more than better, I'd like to go further not backward... (this is for Jim, as I've said I agree with you at nearly 100%) Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 05:42:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATDb7a01601 for ipng-dist; Mon, 29 Nov 1999 05:37:07 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATDavc01594 for ; Mon, 29 Nov 1999 05:36:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA01715 for ; Mon, 29 Nov 1999 05:36:58 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25174 for ; Mon, 29 Nov 1999 06:36:57 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19594; Mon, 29 Nov 1999 08:36:55 -0500 (EST) Message-Id: <199911291336.IAA19594@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-ipv6multihome-with-aggr-00.txt Date: Mon, 29 Nov 1999 08:36:55 -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 : IPv6 Multihoming with Route Aggregation Author(s) : J. Yu Filename : draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt Pages : 7 Date : 24-Nov-99 With the growing requirements for reliable Internet connectivity, increasing number of enterprises choose to acquire Internet connectivity from more than one Internet Service Providers (ISPs) for the purpose of connectivity redundancy and traffic load distribution. The potential of large number of multi-connection sites impose direct challenge on routing aggregation and consequently on scalability of the global Internet routing. Hence a solution is highly desirable which provides the benefit of multi-connection as well as the better scalability of the global routing system. In addition, such solution needs to be simple enough to be operationally manageable. With the fast growth of ISP networks as well as enterprise networks, network manageability is becoming an increasingly important requirement. This document describes a solution which achieves the stated goals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991124120438.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6multihome-with-aggr-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991124120438.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 09:27:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATHMoe01693 for ipng-dist; Mon, 29 Nov 1999 09:22:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATHMec01686 for ; Mon, 29 Nov 1999 09:22:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA02104 for ; Mon, 29 Nov 1999 09:22:40 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14924 for ; Mon, 29 Nov 1999 09:22:38 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id BB2A515215F; Mon, 29 Nov 1999 11:22:36 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 59BCD4FB06; Mon, 29 Nov 1999 11:22:30 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id D8B0D4C90B; Mon, 29 Nov 1999 11:22:29 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000004777; Mon, 29 Nov 1999 12:22:29 -0500 (EST) From: Jim Bound Message-Id: <199911291722.MAA0000004777@quarry.zk3.dec.com> To: Jun-ichiro itojun Hagino Cc: Jim Bound , ipng@sunroof.eng.sun.com, itojun@coconut.itojun.org Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sat, 27 Nov 1999 07:06:33 +0900." <818.943653993@lychee.itojun.org> Date: Mon, 29 Nov 1999 12:22:28 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>Are you saying that a user must need to know the scope-id in >>>>addition to the IPv6 address when it keys in the dst address for ftp, >>>>telnet, ping etc.. If so I strongly disagree with you and if this were >>>>true IPv6 is dead right now in the market. It also completely broke the >>>>key concept of Ipv6 which is simplicity and that it is extensible to the >>>>IPv4 architecture. Fortuneately I think you have just shown though an >>>>error in your thinking about this problem most likely. You cannot >>>>specify the dst scope-id for an address at the client, you have know way >>>>of knowning. And for the apps your listing we don't and should not have >>>>to specify the source address. >>But let me verify something. >>I believe you are NOT saying the user must know the scope_id for the dst >>address to use an app? > First of all, don't think about DNS mapping here. Only think about > numeric addresses. You could make this discussion much better by answering my questions above instead of shouting at me and being controlling. If you continue to not answer my questions I will not respond to your mail anymore I don't like one-way conversations. I said nothing about DNS in my above questions. > I am saying this. More correctly: > If you transmit a packet to scoped destination, > you need to disambiguate between existing scope zones > (links or sites) and denote a single scope zone > by the time you reach IPv6 layer. > There are several chances to disambiguate it. > - User may specify it explicitly, by "ping6 -S link0 fe80::1" > - If your node have only one interface, you have no other choice > so you can make it a default interface. NOTE: you have loopback > interface always, so actually you have to pick one of two interfaces > if you have single ethernet outlet (loopback and ethernet). > - If user did not specify, the node may be able to obey admin's > decision somewhere on the node. This can be implemented by routing > table (like "route add -inet6 fe80::/10 -interface foo"), or > some configuration setup into the kernel. This is possible for this type of "systems application" yes. But I am more interested in this case: user app like Netscape, Oracle, MSA-Accounting Network Software, etc. does: getaddrinfo (host.foo.com) I will use your preferred API OK. When it comes back the node has an address which it got from a DNS lookup of the name for the dst of the node. How does the node know what the dst scope-id is for host.foo.com? >>I believe you are saying the user must convey the source scope_id for >>the src of communications? >>Which is correct above? > If you send a packet to scoped destination address, scope zone must > be made un-ambiguous before you reach IPv6 layer. And I am asking how is that done? What spec what details? >>> I strongly disagree with you Jim. What should happen if you do >>> "telnet fe80::x" when you have fe80::x on both side of your >>> multi-interface host, like the diagram I included in the previous >>> email? Just pick them at random? That is not user friendly and >>> unpredictable. >>Well for link-local I think this is bogus and link-local addresses >>should only be used for ND, DHCPv6, ifconfig, and control protocols they >>should not be permitted to be used for higher layer apps. But I also >>think a link-local address should never be used as a source address when >>the destination address is global either. link-local addresses is an >>address that most users should not even know about. > There are people trying to use link-local (zeroconf, dentist office) > for real communication and we can't just ignore them. > Also you have to support site-locals and multicast scopes. I agree about the dentist office. I just don't agree that site-locals are needed or should ever be used. >>But I don't agree it is not user friendly and if we must figure this out >>it must be done without the user having to know about scope-ids. > If you wish, you can let the node admin connfigure default scope > zone. True. But how is it automated? If we just say admins go figure this out they will puke all over IPv6 and sitelocal addresses. >>> Also, it becomes very trivial to do trojan horse on your telnet >>> attempt. I can just place an PC with fe80::x on it, onto your 3rd >>> interface (and your multi-interface host will pick my PC in 33% of >>> possibility). User needs to disambiguate the destination, by >>> specifying 16bits of in6_addr and scope_id. Otherwise bad guy will >>> be coming to do trojan-horse on you. >>If we do not put scope-ids in the DNS how does one know the scope-id as >>a user for destinations in the first place. > DNS issues can be solved in multiple ways, and I believe it is > VERY separate topic. I want you to think separately. Don't EVER TELL ME WHAT TO THINK AGAIN. I would like to discuss how this is going to work architecturally before we go fixing the API mechanisms under getaddrinfo. To use your favorite API again. > I put a possible solution here, but THIS IS OUTSIDE OF THE KEY > DISCUSSION. > No, I never said that we are going to put scope-id into DNS. I never said you did if I did please send me the mail where I said you said this? The mail is fast now and I don't think I said you said this. > Global DNS tree MUST contain global addresses only. Local DNS tree > must contain 128bit portion only, and it has no scope-id in it. > There's no question here. Then the only draft we have for site-local addresses will not work if we all agree to this (and I agree), hence; we have no underlying solution to scope-ids and we are talking about changing API semantics and syntax for something that is not well defined for "practice" in a network site. > If you have site-local connectivity, you are in situation where > you are in firewalled world. You have connectivity to inside-firewall > nodes, who uses fec0::/10 (like 10.0.0.0/8), and global cloud. > You can have separate DNS tree for each of them, like: I don't agree with your premise. If your using sitelocal addresses only then a firewall may infact not be needed like a Big Dentist Office. I agree we can have separate DNS trees and some rules but that is not written down anywhere or described for implementors. > tree under internal.dec.com. > which is reachable only in the firewall cloud > (site-local DNS tree) > tree under . (root) > which is reachable worldwide (global DNS tree) > You may need to configure extended /etc/resolv.conf to: > contact DNS server for internal.dec.com first > if you get the answer, scope id for sitelocal = 3 Whoa here. Who gave back the sitelocal equalivalent to 3? How did it know this? > next, contact global DNS server > if you get the answer, scope id for sitelocal = 0 (invalid) > Then you kick getaddrinfo(3). What happens here will be: > - you say getaddrinfo("jimbound"). > - this is ambiguous and get disambiguated by DNS search order in > /etc/resolv.conf, and if you configure "internal.dec.com" and > "dec.com" you will have 3 FQDN candidates. > jimbound.internal.dec.com. > jimbound.dec.com. > jimbound. OK this is normal resolver stuff. > - You will try to resolve them looking at extended /etc/resolv.conf. > (1) you try to resolve jimbound.internal.dec.com with site-local > name server. if there's an entry like below: > jimbound.internal.dec.com. IN AAAA fec0::x > you will get the following answer into struct addrinfo. > scopeid is filled in by LOCAL RESOLVER: > fec0::x, scopeid = 3 WHere again did the scope-id = 3 come from? In resolv.conf file? Then its hardcoded and this breaks renumbering and one of the reasons for site-local addresses. > (2) next, you will contact global DNS server for > jimbound.internal.dec.com. (I think you will need to contact > regardless of failure or success of (1)). It will fail. > (3) you will try to resolve jimbound.dec.com. with site-local DNS > server. no entry on the database. > (4) you will try to resolve jimbound.dec.com. you get > jimbound.dec.com. IN AAAA 3ffe:9999::x > and you will get following struct addrinfo. > 3ffe:9999::x, scopeid = 0 (because it is global) > As a result, you will have two entries for your query: > fec0::x, scopeid = 3 > 3ffe:9999::x, scopeid = 0 (because it is global) But the scope-id was filled in after the Response Query from DNS so your saying scope-ids are hardwired into files on the node which are then copied to addrinfo struct? This breaks renumbering objective and PIER WG would object to this solution. And so do I. > This story never puts scopeid into DNS database, and works with > multiple scope zones. Yep and as I said breaks the principles of renumbering which are I think important or we would not be facing what we face with A6 records. >>The way to fix this for link-local is to extend ND to state that if a >>end node has more than one physical link the end node must make sure >>that NO link-local address have been duplicated across multiple links. > I strongly disagree. Admins are using interface id "1" or "2" > all the time and it is impossible. If you take link-local scoped > multicast address, you will have the same solicited node multicast > address if you have two nodes on different side with same interface ID. Well we can agree to disagree no problem. > The strategy never work if you think about site-locals (you have no > help from ND) I don't agree. >>> Also, there's NO draft that says "if you have multiple candidate >>> zones you MUST transmit NS to all the candidate zones". This needs >>> to be clarified before we go on. >>I am saying above that may in fact be required. > No NEVER, this way you can never make scoped addresses work. Have you not learned in your IPv6 work to NEVER say NEVER. > Scoped address will not going to vanish. Even if you may be able to > nuke site-local scope at next IETF:-), you can never nuke link-local > scope and multicast scopes. Link-locals are essential to ND > (apparently), and there are scenarios (dentist office) and people > (like zeroconf) who are trying to use link-locals in real > communication. Therefore, we need to make scoped address work. Well I intend to try to nuke site-local addresses and keep link-locals. See my mail response to Christian Huitema I am working on now and will send later. > Your policy (try to send packet to multiple zones) works only in the > following situations and you make the problem narrower by dropping > support for other cases: > - for link-local, you are assuming that you do not see same fe80::x > on both sides. Once you have same fe80::x on both sides by > coincidence, you are doomed. Wrong. I will see duplicate NS's in my ND daemon and this can be part of the NUD software too. > - for site-local, you are assuming either (1) node is not placed > at the site border (no node will be connected to two or more sites), > or (2) there's no same address used in sites you are connected. > Once you have two more or nodes, in different site, which uses > the same fec0::x, you are doomed. This case is worse since if you > send two TCP SYN, you are (a) bothering routers in both sites, > (b) you may legally get two TCP SYN and bothering one of correct > fec0::x. site-local should be nuked. this is the problem. > In any case, if you do not disambiguate scope zone you would like > to send, as I wrote trojan horse attack is very easily possible. I agree. > We (KAME team apparently, but others as well) have been thinking how > scoped address should be handled, and we came to the fact we always > need to disambiguate scope zones before we reach IPv6 layer like > ip6_output(). We have done the same on Compaq Tru64 UNIX IP stack. But the architecture for using scopes in apps with sitelocal is still not defined and a big hole for us to all interoperate. /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 Mon Nov 29 09:32:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATHVQX01715 for ipng-dist; Mon, 29 Nov 1999 09:31:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATHVHc01704 for ; Mon, 29 Nov 1999 09:31:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09742 for ; Mon, 29 Nov 1999 09:31:17 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20086 for ; Mon, 29 Nov 1999 09:31:16 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id A8555104D2E; Mon, 29 Nov 1999 11:31:14 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 5B71ABC4F6; Mon, 29 Nov 1999 11:31:08 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id E3E9BB2A43; Mon, 29 Nov 1999 11:31:07 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000007559; Mon, 29 Nov 1999 12:31:13 -0500 (EST) From: Jim Bound Message-Id: <199911291731.MAA0000007559@quarry.zk3.dec.com> To: Francis Dupont Cc: Jim Bound , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Sun, 28 Nov 1999 19:08:15 +0100." <199911281808.TAA10285@givry.inria.fr> Date: Mon, 29 Nov 1999 12:31:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well for link-local I think this is bogus and link-local addresses should only be used for ND, DHCPv6, ifconfig, and control protocols they should not be permitted to be used for higher layer apps. >=> this is not acceptable for me. You are trying to change a "should not" >in a "must not". Guilty as charged. Exactly my intentions. But I also think a link-local address should never be used as a source address when the destination address is global either. link-local addresses is an address that most users should not even know about. >=> I agree but this is not the point. It is relative because we cannot continue to just say everything goes if it can be done and we will make it work later. This is the wrong thinking model for IPv6. It was OK when we lived in architecture and thinking about it land but we are not in shipping product land and the rules are way to loose in some places with IPv6. Thats my input to the WG after implenting this stuff. But I don't agree it is not user friendly and if we must figure this out it must be done without the user having to know about scope-ids. >=> it is not user friendly to disallow something without necessity. If it hurts then it either must fixed or removed. The way to fix this for link-local is to extend ND to state that if a end node has more than one physical link the end node must make sure that NO link-local address have been duplicated across multiple links. >=> I don't know if this is possible to implement and I don't want this. >Ambiguity is a property of the local scope idea, I think it is better >to learn to live with it than to twist the model... I strongly disagree. It is possible to implement or I would not have brought it up. >PS: your real problem is that getipnodebyxxx() should be updated, isn't it? >About inet_ntop/pton() I believe a new set of functions can be defined >because programmers should deal with *names* (in fact getipnodebyname() >accepts numeric address string then this detail should get a low priority). I resent your implication. I would never as a man on the planet play these kind of games because I don't want to change and API or anything I work on in the IETF or on my job. I am convinced we must accept the pain and shoot getipnodebyname in the head and deprecate it and move to getaddrinfo. I thought you knew me better as a person and my own integrity. I am quite bummed out you would think this about me Francis!! But that does not mean I support putting scope-ids in any API when they are as ill-defined and unknown as they are today. We also IMO have to revisit the entire reason for site-locals one of which was "renumbering" and you said you agreed with Itojun and his mail will break that as the scope-id was hardwired. More when I respond to Christian's mail. /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 Mon Nov 29 09:47:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATHi6B01738 for ipng-dist; Mon, 29 Nov 1999 09:44:06 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATHhuc01731 for ; Mon, 29 Nov 1999 09:43:57 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA06726 for ; Mon, 29 Nov 1999 09:43:57 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28171 for ; Mon, 29 Nov 1999 09:43:55 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id C7254104CB9; Mon, 29 Nov 1999 11:43:54 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 7E5BD4FB04; Mon, 29 Nov 1999 11:43:48 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id E003D4C907; Mon, 29 Nov 1999 11:43:47 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000016275; Mon, 29 Nov 1999 12:43:48 -0500 (EST) From: Jim Bound Message-Id: <199911291743.MAA0000016275@quarry.zk3.dec.com> To: Christian Huitema Cc: Tim Hartrick , sm@bossette.engr.sgi.com, bzill@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Mon, 22 Nov 1999 16:45:49 EST." <4.1.19991122163348.0096c410@mailee.research.telcordia.com> Date: Mon, 29 Nov 1999 12:43:47 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, >I have always considered the "site address" an atrocious leftover of Net >10, and the more I see this discussion unfolding, the stronger my >conviction. I can swallow the unidentified link address -- such address are >necessary for autoconfig. But I have a very hard time trying to understand >what exactly is good in the site address format: I agree 100%. >1) It does not exactly simplify autoconfig, since one has to program some >form of site identifier in the nodes, Exactly. >2) It cannot be stored in a directory, Exactly. >3) It should not be routed, but then it has to be propagated for the needs >of mobile nodes, Exactly. >4) It is very hard to handle in multisited nodes. Exactly. Also as a network implementor for over 15 years I am feeling deja vu (been here before) here. I recall having to implement and make a protocol work that had unknowns and not-well-defined features that affected applications (thats the key if it affects applications) that architects thru over the wall to implementors and it was also one of the proposed IPng solutions back in 1994. The horrors of this to the APIs and apps caused this prootocol to never reach the market on any wide scale. The architects defined a neat idea (in their mind) but never really waited to see if it would work in practice. IPv6 can work but I strongly urge you to help me and anyone else shoot these site-local addresses in the head. We have enough global address space with IPv6 that we can re-create a Net-10 within the IPv6 exponential number of addresses. As far as renumbering the only way to solve that is develop further addrconf and router-renumbering and get folks to stop hard coding address semantics in configuration files via sys admins. IPv6 can be extended to do this and this is a wonderful part of our basic architecture. I consider site-local addresses as bad as variable address lengths and we did not permit them in the architecture. >It seems that allowing some actual identifier, or magic number, or >whatever, in the uppermost bits of the site addresses would go a long way >towards solving the problem. Consider an address form of prefix>, where "site-id" is a flat binary >identifier: If we make it part of the actual address that is a differnt discussion I think. >1) It can be autoconfigured through router advertisements, Yes it can. >2) It can be stored in the DNS, and the hosts can easily be instructed to >only use an address of this format if the "site-id" matches one of the >sites to which they belong, Yes it can. >3) Routers can easily be instructed to only forward the site id that they >recognize, and to ignore all other ids, thus limiting possible leakage, Yes they can. >4) Multi-sited hosts can use classic routing techniques to direct >site-addressed packets to the most appropriate interface, or tunnel. Yes they can. >It may be too late to get rid of the site-id entirely. But we could very >well start experimenting with the insertion of magicg numbers in the >structure, or maybe with an alternate address format. I don't think its too late to shoot them in the head at all. But if we cannot I think any discussions of using them in the real world are premature until we define how they can be used. Its an idea that has not been discussed and parsed enough to be used in practice. /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 Mon Nov 29 10:22:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATIIjF01810 for ipng-dist; Mon, 29 Nov 1999 10:18:45 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATIIXc01803 for ; Mon, 29 Nov 1999 10:18:33 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA00492 for ipng@sunroof.eng.sun.com; Mon, 29 Nov 1999 10:18:07 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dARJuAc00852 for ; Sat, 27 Nov 1999 11:56:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA11941 for ; Sat, 27 Nov 1999 11:56:09 -0800 (PST) Received: from smtppop2.gte.net (smtppop2.gte.net [207.115.153.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11427 for ; Sat, 27 Nov 1999 11:56:08 -0800 (PST) Received: from compaq (pm4a24.incom.net [206.171.123.40]) by smtppop2.gte.net with SMTP for ; id NAA10154077 Sat, 27 Nov 1999 13:54:22 -0600 (CST) Message-ID: <000201bf3911$d046ee80$287babce@compaq> From: "Todd Middleswart" To: Subject: I need some facts concerning RFC 2452 Date: Sat, 27 Nov 1999 11:58:25 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01BF38CE.B5B32C20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0004_01BF38CE.B5B32C20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please inform me on who proposed the RFC, the date of the RFC, and = lastly the problem it solves or the improvement that it suggests ------=_NextPart_000_0004_01BF38CE.B5B32C20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please inform me on who proposed the = RFC, the=20 date of the RFC, and lastly the problem it solves or the improvement = that it=20 suggests
------=_NextPart_000_0004_01BF38CE.B5B32C20-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 10:27:03 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATIPlf01875 for ipng-dist; Mon, 29 Nov 1999 10:25:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATIPac01868 for ; Mon, 29 Nov 1999 10:25:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA20924 for ; Mon, 29 Nov 1999 10:25: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 KAA24093 for ; Mon, 29 Nov 1999 10:25: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 DAA21642; Tue, 30 Nov 1999 03:23:51 +0900 (JST) To: Jim Bound cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Mon, 29 Nov 1999 12:22:28 EST. <199911291722.MAA0000004777@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Tue, 30 Nov 1999 03:23:51 +0900 Message-ID: <21640.943899831@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk beware: This email is very long. The summary is: - I'm not promoting site-locals. - I'm promoting more correct use of scope id. - Summary of my thinking on scope id is this. - when user specifies FQDN, it should come with no explicit scope id. FQDN must be resolved into <128bit IPv6 address, scope id> pair. - when user specifies numeric IPv6 address, (1) user must specify scope id explicitly, or (2) system default setting (like routing table) must pick single scope id. - There are ways to resolve FQDN into pair. - draft-ietf-ipngwg-site-prefixes-03.txt. consider the following situation: - you've got site local prefix advertisement A from interface X, interface X belongs to site ALPHA. - you've got site local prefix advertisement B from interface Y, interface Y belongs to site BETA. If the given FQDN resolves to an IPv6 address that matches A, it should be in site ALPHA. Now you have <128-bit IPv6 address, scope> pair. - see the latter half of my previous email. - Even if you remove site local from the spec the above use of scope id will not change. - sending NDs to multiple interfaces is a bad idea. Jim, sorry if you are irritated by my bad English. I really tried to answer your questions. Let me recap. There are some reordering of sentences. >>>But let me verify something. >>>I believe you are NOT saying the user must know the scope_id for the dst >>>address to use an app? >>>I believe you are saying the user must convey the source scope_id for >>>the src of communications? >>>Which is correct above? The above question is not "pick one of these" kind of question so it did not make sense to me to pick one. so I answered with descriptions. I need to do it again. For both of questions, my answer is like below. - when user specifies FQDN, it should come with no explicit scope id. FQDN must be resolved into <128bit IPv6 address, scope id> pair. - when user specifies numeric IPv6 address, (1) user must specify scope id explicitly, or (2) system default setting (like routing table) must pick single scope id. The following line in the previous email: >> I am saying this. More correctly: tries to answer the first question (the line was right below the first question). I am saying that "the user must know the scope_id for the dst address to use an app" if she specifies numeric IPv6 address. The following lines in the previous email: >> If you send a packet to scoped destination address, scope zone must >> be made un-ambiguous before you reach IPv6 layer. tries to clarify the second question. First of all, "source scope_id" in your question is incorrect. User need not specify "source". All she specifies is destination. >You could make this discussion much better by answering my questions >above instead of shouting at me and being controlling. If you continue to >not answer my questions I will not respond to your mail anymore I don't >like one-way conversations. I really tried to answer your questions. I did not try to shout. >This is possible for this type of "systems application" yes. The rule I wrote is for all the applications. There's no difference between systems application (like ifconfig, ping6) and normal application (telnet, netscape). How can a user know which command falls into which category? >But I am more interested in this case: >user app like Netscape, Oracle, MSA-Accounting Network Software, etc. >does: > getaddrinfo (host.foo.com) I will use your preferred API OK. >When it comes back the node has an address which it got from a DNS >lookup of the name for the dst of the node. >How does the node know what the dst scope-id is for host.foo.com? FQDN must be resolved into <128-bit IPv6 address, scope> pair, by using: - draft-ietf-ipngwg-site-prefixes-03.txt. consider the following situation: - you've got site local prefix advertisement A from interface X, interface X belongs to site ALPHA. - you've got site local prefix advertisement B from interface Y, interface Y belongs to site BETA. If the given FQDN resolves to an IPv6 address that matches A, it should be in site ALPHA. Now you have <128-bit IPv6 address, scope> pair. - see the latter half of my previous email. >> There are people trying to use link-local (zeroconf, dentist office) >> for real communication and we can't just ignore them. >> Also you have to support site-locals and multicast scopes. >I agree about the dentist office. I just don't agree that site-locals >are needed or should ever be used. There are specs that use site-locals. To name a few: - router renumbering - DHCPv6 How do you plan to change those? I'm just okay if you nuke site-local addresses (as long as you update those specs). However, even if you nuke site-locals, you need to disambiguagte numeric IPv6 address by specifying scope id. >>>But I don't agree it is not user friendly and if we must figure this out >>>it must be done without the user having to know about scope-ids. >> If you wish, you can let the node admin connfigure default scope >> zone. >True. >But how is it automated? >If we just say admins go figure this out they will puke all over IPv6 >and sitelocal addresses. Even for link-locals you need the above admin configuration, or user specification of scope id. It looks you are assuming that I'm promoting site-locals. I'm not fan of site-locals. I'm not promoting site-locals. I'm just promoting correct use of scope id, which applies for ALL scoped addresses we have, like: - link-local unicast - site-local unicast - multicast with 14 non-global scope I'll be okay, or happy, if you nuke site-locals. Even if you nuke site-locals, you can't forget about scope id. >> DNS issues can be solved in multiple ways, and I believe it is >> VERY separate topic. I want you to think separately. >Don't EVER TELL ME WHAT TO THINK AGAIN. >I would like to discuss how this is going to work architecturally before >we go fixing the API mechanisms under getaddrinfo. To use your favorite >API again. I just tried to clarify that scope id issue and DNS issue are very separate. It seem that you are mixing up them so I just wanted you to separate these. Maybe my wording was wrong, I apologize if it was. >> I put a possible solution here, but THIS IS OUTSIDE OF THE KEY >> DISCUSSION. >> No, I never said that we are going to put scope-id into DNS. >I never said you did if I did please send me the mail where I said you >said this? The mail is fast now and I don't think I said you said this. Here's the line made me write the above: >>>From: Jim Bound >>>Message-Id: <199911261423.JAA0000009299@quarry.zk3.dec.com> >>>To: itojun@iijlab.net >>>If we do not put scope-ids in the DNS how does one know the scope-id as >>>a user for destinations in the first place. You look like assuming that I'm going to put scope-id into DNS database. I may be wrong. >> Global DNS tree MUST contain global addresses only. Local DNS tree >> must contain 128bit portion only, and it has no scope-id in it. >> There's no question here. >Then the only draft we have for site-local addresses will not work if we >all agree to this (and I agree), hence; we have no underlying solution >to scope-ids and we are talking about changing API semantics and syntax >for something that is not well defined for "practice" in a network site. Do you agree with draft-ietf-ipngwg-site-prefixes-03.txt, or my lines above? Anyway, draft-ietf-ipngwg-site-prefixes-03.txt places global IPv6 addresses only onto DNS database so I'm saying the same thing with draft-ietf-ipngwg-site-prefixes-03.txt. We have underlying solution for resolving FQDN into <128bit IPv6 address, scope-id> pair. again: - draft-ietf-ipngwg-site-prefixes-03.txt. consider the following situation: - you've got site local prefix advertisement A from interface X, interface X belongs to site ALPHA. - you've got site local prefix advertisement B from interface Y, interface Y belongs to site BETA. If the given FQDN resolves to an IPv6 address that matches A, it should be in site ALPHA. Now you have <128-bit IPv6 address, scope> pair. - see the latter half of my previous email. If you say there's no draft, I'll write up one if you agree that use of scope id, and user's explicit specification of scope id are very important. >> If you have site-local connectivity, you are in situation where >> you are in firewalled world. You have connectivity to inside-firewall >> nodes, who uses fec0::/10 (like 10.0.0.0/8), and global cloud. >> You can have separate DNS tree for each of them, like: >I don't agree with your premise. If your using sitelocal addresses only >then a firewall may infact not be needed like a Big Dentist Office. >I agree we can have separate DNS trees and some rules but that is not >written down anywhere or described for implementors. Correct me if I'm wrong, I believe DNS management in firewalled environment is never really documented. The only document I know of is draft-ietf-dnsind-local-names-07.txt. Again I'm not promoting site-locals. I just can't stop people from using them as they are on the documents for a very long period of time, and there are specs that depend on site-locals. Combined use of site-local and global address is very similar to firewalled site, with sort of packet filters at the edge. >> You may need to configure extended /etc/resolv.conf to: >> contact DNS server for internal.dec.com first >> if you get the answer, scope id for sitelocal = 3 >Whoa here. Who gave back the sitelocal equalivalent to 3? >How did it know this? You can pick any number as you want, as scope id is local to a node. You just need to give different number to different site you belong. >> - You will try to resolve them looking at extended /etc/resolv.conf. >> (1) you try to resolve jimbound.internal.dec.com with site-local >> name server. if there's an entry like below: >> jimbound.internal.dec.com. IN AAAA fec0::x >> you will get the following answer into struct addrinfo. >> scopeid is filled in by LOCAL RESOLVER: >> fec0::x, scopeid = 3 >WHere again did the scope-id = 3 come from? >In resolv.conf file? >Then its hardcoded and this breaks renumbering and one of the reasons >for site-local addresses. Again it is local to your node. This does not make any harm to renumbering. Renumbering will occur in one of a site you belong, not across multiple sites you belong (why "stanford" and "cisco" needs to be renumbered at the same time?). Even if "stanford" experiences renumber, you do not need to change your idea of scope id for "stanford". >But the scope-id was filled in after the Response Query from DNS so your >saying scope-ids are hardwired into files on the node which are then >copied to addrinfo struct? >This breaks renumbering objective and PIER WG would object to this >solution. And so do I. Yes to the first 3 lines, scope id will be filled in after the resolver got the reply from DNS server. scope id is hardwired into files on the node. However, this does not break renumbering. >> This story never puts scopeid into DNS database, and works with >> multiple scope zones. >Yep and as I said breaks the principles of renumbering which are I think >important or we would not be facing what we face with A6 records. No, renumber should work just fine. >> I strongly disagree. Admins are using interface id "1" or "2" >> all the time and it is impossible. If you take link-local scoped >> multicast address, you will have the same solicited node multicast >> address if you have two nodes on different side with same interface ID. >Well we can agree to disagree no problem. >> The strategy never work if you think about site-locals (you have no >> help from ND) >I don't agree. Do you use multihomed nodes every day? Why can you live with "send ND to all interface" node? I can't. >> Scoped address will not going to vanish. Even if you may be able to >> nuke site-local scope at next IETF:-), you can never nuke link-local >> scope and multicast scopes. Link-locals are essential to ND >> (apparently), and there are scenarios (dentist office) and people >> (like zeroconf) who are trying to use link-locals in real >> communication. Therefore, we need to make scoped address work. >Well I intend to try to nuke site-local addresses and keep link-locals. >See my mail response to Christian Huitema I am working on now and will >send later. Again, I'm not promoting site-locals. I'm just fine if you are happy with more explicit use of scope id. >> Your policy (try to send packet to multiple zones) works only in the >> following situations and you make the problem narrower by dropping >> support for other cases: >> - for link-local, you are assuming that you do not see same fe80::x >> on both sides. Once you have same fe80::x on both sides by >> coincidence, you are doomed. >Wrong. I will see duplicate NS's in my ND daemon and this can be part >of the NUD software too. NUD? isn't it DAD? Anyway, I believe you are wrong. Consider the following diagram. fe80::x | network A my node | network B fe80::x On network A, fe80::x will perform DAD to detect other fe80::x on network A. There's no such guy and DAD will success. On network B, fe80::x will perform DAD to detect other fe80::x on network B. There's no such guy and DAD will success. Therefore, there will be two fe80::x visible from my node. You are saying that, any multi-interface node must take care of the network on the other side during DAD process (i.e. if fe80::x on network A transmit DAD packet, my node needs to forward that to network B to make sure that there's no fe80::x on network B). This is not on the spec. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 10:54:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATIq9I01974 for ipng-dist; Mon, 29 Nov 1999 10:52:09 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATIq4c01967 for ; Mon, 29 Nov 1999 10:52:05 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA00580 for ipng@sunroof.eng.sun.com; Mon, 29 Nov 1999 10:51:39 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATIgMc01948 for ; Mon, 29 Nov 1999 10:42:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA05545 for ; Mon, 29 Nov 1999 10:42:22 -0800 (PST) Received: from artemis.rus.uni-stuttgart.de (artemis.rus.uni-stuttgart.de [129.69.1.28]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05578 for ; Mon, 29 Nov 1999 11:42:20 -0700 (MST) Received: from ksat10 (ksat10.rus.uni-stuttgart.de [129.69.30.170]) by artemis.rus.uni-stuttgart.de (8.8.8/8.8.8) with SMTP id TAA15488; Mon, 29 Nov 1999 19:42:18 +0100 (MET) env-from (christ@rus.uni-stuttgart.de) From: "Paul Christ" To: "Todd Middleswart" , Subject: RE: I need some facts concerning RFC 2452 Date: Mon, 29 Nov 1999 19:50:43 +0100 Message-ID: <000601bf3a9a$a3da98d0$aa1e4581@ksat10.rus.uni-stuttgart.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01BF3AA3.059F00D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <000201bf3911$d046ee80$287babce@compaq> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF3AA3.059F00D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Please inform me on who proposed the RFC, the date of the RFC hm, (jawoll), Did you look by any chance -say - at www.ietf.org Paul Christ p.s.: Mike Daniele Compaq Computer Corporation 110 Spit Brook Rd Nashua, NH 03062 Phone: +1-603-884-1423 EMail: daniele@zk3.dec.com RFC 2452 TCP MIB for IPv6 December 1998 -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Todd Middleswart Sent: Samstag, 27. November 1999 20:58 To: ipng@sunroof.eng.sun.com Subject: I need some facts concerning RFC 2452 Please inform me on who proposed the RFC, the date of the RFC, and lastly the problem it solves or the improvement that it suggests ------=_NextPart_000_0007_01BF3AA3.059F00D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=20 Please inform me on who proposed the RFC, = the date of=20 the RFC
 
hm,=20 (jawoll),
 
Paul=20 Christ
 
p.s.:=20
 
    Mike = Daniele
   Compaq=20 Computer Corporation
   110 Spit Brook Rd
   = Nashua,=20 NH 03062

   Phone: +1-603-884-1423
   = EMail: daniele@zk3.dec.com=
 
   RFC=20 2452           &nb= sp;       =20 TCP MIB for=20 IPv6           &nb= sp;  =20 December 1998
-----Original Message-----
=20 owner-ipng@sunroof.eng.sun.com = [mailto:owner-ipng@sunroof.eng.sun.com]On=20 Behalf Of Todd Middleswart
Sent: Samstag, 27. November = 1999=20 20:58
To: ipng@sunroof.eng.sun.com
Subject: I need = some=20 facts concerning RFC 2452

Please inform me on who proposed = the RFC, the=20 date of the RFC, and lastly the problem it solves or the improvement = that it=20 suggests
------=_NextPart_000_0007_01BF3AA3.059F00D0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 11:12:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATJ9i702009 for ipng-dist; Mon, 29 Nov 1999 11:09:44 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATJ9ac02002 for ; Mon, 29 Nov 1999 11:09:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA28824 for ; Mon, 29 Nov 1999 11:09:35 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA19037 for ; Mon, 29 Nov 1999 12:09:34 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Nov 1999 11:05:45 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Nov 1999 11:05:45 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21754@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" , Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: RE: Textual Address Change for Scope-IDs Date: Mon, 29 Nov 1999 11:05:34 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But I am more interested in this case: > > user app like Netscape, Oracle, MSA-Accounting Network Software, etc. > does: > > getaddrinfo (host.foo.com) I will use your preferred API OK. > > When it comes back the node has an address which it got from a DNS > lookup of the name for the dst of the node. > > How does the node know what the dst scope-id is for host.foo.com? Jim, I think you're asking where the getaddrinfo() implementation (when resolving names, not literal addresses) gets the scope-ids that it returns? For names that resolve to link-local addresses: presumably some special link-local name resolution method is being used, like the ICMP-based mechanism. In any case, the scope-id should identify the link on which the name resolution was performed. For names that resolve to site-local addresses: Erik's site-prefixes draft needs some additional explanation of this point, but I think it's a pretty simple extension of the procedure in the "host name lookups" section. (I've recently implemented Erik's draft and I have a list of comments to send when I get some time - this is one of them.) For name that resolve to global addresses: the scope-id is zero. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 13:51:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATLmYn02169 for ipng-dist; Mon, 29 Nov 1999 13:48:34 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATLmNc02162 for ; Mon, 29 Nov 1999 13:48:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA23679 for ; Mon, 29 Nov 1999 13:48:22 -0800 (PST) Received: from inet-vrs-02.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA07592 for ; Mon, 29 Nov 1999 14:48:21 -0700 (MST) Received: from 157.54.9.104 by inet-vrs-02.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Nov 1999 13:46:10 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Nov 1999 13:46:29 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F37@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" , Christian Huitema Cc: ipng@sunroof.eng.sun.com Subject: Regarding site-local addresses Date: Mon, 29 Nov 1999 13:46:26 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I changed the subject line to better reflect the issue. I think site-local addresses, or something very much like them, is useful and will work fine. Jim Bound writes: > Christian Huitema writes: > >I have always considered the "site address" > >an atrocious leftover of Net 10, and the more > >I see this discussion unfolding, the stronger my > >conviction. I believe that if we do not specify site-local addresses specifically, we will end up with the equivalent of IPv4's net 10 anyway, due to marketplace pressures. The "new devices" or "home automation" crowd will want all of their IPv6 enabled dishwashers, water heaters, light switches, stereos, etc. to be able to talk to one another without making Joe and Jane Average get an Internet connection and global addresses. Since multiple links will likely be in use in the home (power-line, telephone-line, Ethernet, multiple types of wireless), link-local addresses will not work. If we don't define site-local addresses now, manufacturers of such devices will either lobby for them, use some random prefix, or simply not use IPv6. > >I can swallow the unidentified link address -- > >such address are necessary for autoconfig. > >But I have a very hard time trying to understand > >what exactly is good in the site address format: > > I agree 100%. The good thing about specifying site-local addresses now is that all IPv6 routers will, by default, understand that site-local addresses must not be forwarded outside of the site. Introducing a "net 10" at a later date is more likely to result in leakage of such addresses into the global internet (or between "net 10" sites). > >1) It does not exactly simplify autoconfig, > > since one has to program some form of site > > identifier in the nodes, > > Exactly. No, a single-sited end node doesn't need to know anything about site identifiers. > >2) It cannot be stored in a directory, > > Exactly. No, a site-specific directory can hold site-local addresses. > >3) It should not be routed, but then it has > > to be propagated for the needs of mobile nodes, > > Exactly. I don't claim to be a mobile-IP expert, but I thought this was a solved problem in the mobile-IP draft. > >4) It is very hard to handle in multisited nodes. > > Exactly. I don't see this either, but I guess it depends upon your definition of "very hard". Tagging every interface in a routing node with a node-specific site-id and then only forwarding between like site-ids seems pretty straight-forward. So does only allowing end node originated packets to go out via interfaces with a site-id that matches the one in the sin6_scope_id field. Our implementation does both of these today. Everything else is UI/API. The only hard part here has been getting all the makers of stacks for "old style" computers (the kind people sit in front of and type at) to agree on the UI/API. The "new device" crowd could care less. Site-locals will work just fine for them. All they need is already in RFC 2373. > IPv6 can work but I strongly urge you to help me > and anyone else shoot these site-local addresses > in the head. IPv6 does work. So do site-local addresses. I strongly urge everyone to keep them as part of the standard or we'll be needlessly excluding many potential uses of IPv6. > We have enough global address space with IPv6 that > we can re-create a Net-10 within the IPv6 > exponential number of addresses. Yes, we could do that. This is basically what the site-local prefix does today. I see advantages to establishing it now (stated above) and no advantage to waiting. In summary, I see many potential uses for site-local addresses. Making renumbering easier is not the only (or maybe even a good use) of site-local addresses. We should consider that they are most useful outside of the corporate workplace PC/workstation environment, where having global addresses is not a given. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 14:32:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATMTDs02237 for ipng-dist; Mon, 29 Nov 1999 14:29:13 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATMT2c02230 for ; Mon, 29 Nov 1999 14:29:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA11114 for ; Mon, 29 Nov 1999 14:29:02 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24599 for ; Mon, 29 Nov 1999 15:29:02 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA28647; Mon, 29 Nov 1999 14:21:26 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA08400; Mon, 29 Nov 1999 14:21:26 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id OAA05729; Mon, 29 Nov 1999 14:22:22 -0800 (PST) Date: Mon, 29 Nov 1999 14:22:22 -0800 (PST) From: Tim Hartrick Message-Id: <199911292222.OAA05729@feller.mentat.com> To: bound@zk3.dec.com, huitema@research.telcordia.com, bzill@microsoft.com Subject: Re: Regarding site-local addresses Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > Yes, we could do that. This is basically what the site-local prefix does > today. I see advantages to establishing it now (stated above) and no > advantage to waiting. > > In summary, I see many potential uses for site-local addresses. Making > renumbering easier is not the only (or maybe even a good use) of site-local > addresses. We should consider that they are most useful outside of the > corporate workplace PC/workstation environment, where having global > addresses is not a given. > I agree with Brian on all counts. Something like Net 10 will exist in the IPv6 world. By defining site-local addresses within the architecture we have the opportunity to get it done right so that all of the problems which exist in the IPv4 world with Net 10 won't exist at all, or will be lessened substantially, in the IPv6 world. The consensus of this working has been in favor of this feature for a long, long, long time. It is really disturbing that we can't move forward with creating solutions around the existing architecture but instead keep fighting the same battles over and over and over and over. We need to move forward. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 14:56:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATMr1c02271 for ipng-dist; Mon, 29 Nov 1999 14:53:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATMqpc02264 for ; Mon, 29 Nov 1999 14:52:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA27896 for ; Mon, 29 Nov 1999 14:52:52 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08912 for ; Mon, 29 Nov 1999 14:52:50 -0800 (PST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 15FF3104C11; Mon, 29 Nov 1999 16:52:50 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id BEBE74FB07; Mon, 29 Nov 1999 16:52:43 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 50E174C90B; Mon, 29 Nov 1999 16:52:43 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000032757; Mon, 29 Nov 1999 17:52:48 -0500 (EST) From: Jim Bound Message-Id: <199911292252.RAA0000032757@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of "Mon, 29 Nov 1999 13:46:26 PST." <3D2036E25376D31197A100805FEAD892712F37@RED-MSG-02> Date: Mon, 29 Nov 1999 17:52:48 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I changed the subject line to better reflect the issue. I think site-local >addresses, or something very much like them, is useful and will work fine. good change. >Jim Bound writes: >> Christian Huitema writes: >> >I have always considered the "site address" >> >an atrocious leftover of Net 10, and the more >> >I see this discussion unfolding, the stronger my >> >conviction. > >I believe that if we do not specify site-local addresses specifically, we >will end up with the equivalent of IPv4's net 10 anyway, due to marketplace >pressures. The "new devices" or "home automation" crowd will want all of >their IPv6 enabled dishwashers, water heaters, light switches, stereos, etc. >to be able to talk to one another without making Joe and Jane Average get an >Internet connection and global addresses. Since multiple links will likely >be in use in the home (power-line, telephone-line, Ethernet, multiple types >of wireless), link-local addresses will not work. If we don't define >site-local addresses now, manufacturers of such devices will either lobby >for them, use some random prefix, or simply not use IPv6. Don't agree, global addresses will work. There is enough of them and the only reason Net 10 will exist. >> >I can swallow the unidentified link address -- >> >such address are necessary for autoconfig. >> >But I have a very hard time trying to understand >> >what exactly is good in the site address format: >> >> I agree 100%. > >The good thing about specifying site-local addresses now is that all IPv6 >routers will, by default, understand that site-local addresses must not be >forwarded outside of the site. Introducing a "net 10" at a later date is >more likely to result in leakage of such addresses into the global internet >(or between "net 10" sites). Correct use of global addresses will do the same thing. >> >1) It does not exactly simplify autoconfig, >> > since one has to program some form of site >> > identifier in the nodes, >> >> Exactly. >No, a single-sited end node doesn't need to know anything about site >identifiers. For a multisited node this is necessary. >> >2) It cannot be stored in a directory, >> >> Exactly. > >No, a site-specific directory can hold site-local addresses. No one on this appears to want them in DNS any place else is another discussion and proposal. Also their identity would need to be defined. >> >3) It should not be routed, but then it has >> > to be propagated for the needs of mobile nodes, >> >> Exactly. >I don't claim to be a mobile-IP expert, but I thought this was a solved >problem in the mobile-IP draft. If you keep going back to the Home Agent yes otherwise it has the same problem any node would have with a duplicate address across different sites. >> >4) It is very hard to handle in multisited nodes. >> >> Exactly. > >I don't see this either, but I guess it depends upon your definition of >"very hard". Tagging every interface in a routing node with a node-specific >site-id and then only forwarding between like site-ids seems pretty >straight-forward. So does only allowing end node originated packets to go >out via interfaces with a site-id that matches the one in the sin6_scope_id >field. Our implementation does both of these today. Thats not the problem or how I interpreted Christian's mail. How are they defined so we can all use them interoperably. >Everything else is UI/API. The only hard part here has been getting all the >makers of stacks for "old style" computers (the kind people sit in front of >and type at) to agree on the UI/API. The "new device" crowd could care >less. Site-locals will work just fine for them. All they need is already >in RFC 2373. Simply don't agree. Where is the draft that discusses the use of site-local addresses? Do you think its Erik's? If so do you agree we should do that? We can't do it 10 different ways. >> IPv6 can work but I strongly urge you to help me >> and anyone else shoot these site-local addresses >> in the head. > >IPv6 does work. So do site-local addresses. I strongly urge everyone to >keep them as part of the standard or we'll be needlessly excluding many >potential uses of IPv6. They do not work in a standard interoperable manner and the IETF has no spec on their use other than Eriks. Are you saying we have no work to do on site-local addresses in the working group? >> We have enough global address space with IPv6 that >> we can re-create a Net-10 within the IPv6 >> exponential number of addresses. >Yes, we could do that. This is basically what the site-local prefix does >today. I see advantages to establishing it now (stated above) and no >advantage to waiting. We just don't agree. >In summary, I see many potential uses for site-local addresses. Making >renumbering easier is not the only (or maybe even a good use) of site-local >addresses. We should consider that they are most useful outside of the >corporate workplace PC/workstation environment, where having global >addresses is not a given. Net 10 is not something customers did other than IPv4 address space is exhausted. /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 Mon Nov 29 14:59:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATMw3x02289 for ipng-dist; Mon, 29 Nov 1999 14:58:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATMvsc02282 for ; Mon, 29 Nov 1999 14:57:54 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA08495 for ; Mon, 29 Nov 1999 14:57:51 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12068 for ; Mon, 29 Nov 1999 14:57:47 -0800 (PST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id E04575782D; Mon, 29 Nov 1999 16:57:45 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 93AB6BC4D5; Mon, 29 Nov 1999 16:57:39 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 1647AB2A42; Mon, 29 Nov 1999 16:57:39 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id RAA0000032436; Mon, 29 Nov 1999 17:57:44 -0500 (EST) From: Jim Bound Message-Id: <199911292257.RAA0000032436@quarry.zk3.dec.com> To: Tim Hartrick Cc: bound@zk3.dec.com, huitema@research.telcordia.com, bzill@microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of "Mon, 29 Nov 1999 14:22:22 PST." <199911292222.OAA05729@feller.mentat.com> Date: Mon, 29 Nov 1999 17:57:44 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I agree with Brian on all counts. Something like Net 10 will exist in the >IPv6 world. By defining site-local addresses within the architecture we >have the opportunity to get it done right so that all of the problems which >exist in the IPv4 world with Net 10 won't exist at all, or will be lessened >substantially, in the IPv6 world. The reasons for net 10 in IPv4 do not exist in IPv6. >The consensus of this working has been in favor of this feature for a long, >long, long time. It is really disturbing that we can't move forward with >creating solutions around the existing architecture but instead keep fighting >the same battles over and over and over and over. We need to move forward. Consenus was we would like them in the architecture. But after two years we have no solutions. In any research activity if there are no solutions for something it is valid to re-check their merit. That is what is being done here and I will continue to do it on anything in IPv6 that is not being used or has been defined clearly. What is being asked is there still consensus for this part of IPv6. You francis, and Brian say yes. 3 of us say no. So I guess we need to hear from more folks. We do not have consensus. if we do then this time lets find a solution before we go changing things because of them. /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 Mon Nov 29 15:16:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATNCsN02335 for ipng-dist; Mon, 29 Nov 1999 15:12:55 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATNChc02328 for ; Mon, 29 Nov 1999 15:12:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA02578 for ; Mon, 29 Nov 1999 15:12:44 -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 QAA14983 for ; Mon, 29 Nov 1999 16:12:43 -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 RAA15749; Mon, 29 Nov 1999 17:05:12 -0600 (CST) Message-Id: <199911292305.RAA15749@gungnir.fnal.gov> To: Jim Bound Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Regarding site-local addresses In-reply-to: Your message of Mon, 29 Nov 1999 17:57:44 EST. <199911292257.RAA0000032436@quarry.zk3.dec.com> Date: Mon, 29 Nov 1999 17:05:12 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim says: > The reasons for net 10 in IPv4 do not exist in IPv6. True, but other reasons do exist. We've discussed them before. Can we stop re-fighting the battles and move on? Since you're counting, I for one am in favor of keeping site-local addresses. 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 Mon Nov 29 15:39:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATNaeB02398 for ipng-dist; Mon, 29 Nov 1999 15:36:40 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATNaUc02391 for ; Mon, 29 Nov 1999 15:36:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA18044 for ; Mon, 29 Nov 1999 15:36:32 -0800 (PST) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26453 for ; Mon, 29 Nov 1999 16:36:30 -0700 (MST) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id XAA70254 for ; Mon, 29 Nov 1999 23:36:28 GMT Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id XAA15092 for ; Mon, 29 Nov 1999 23:36:26 GMT Message-ID: <38430D4B.55A40C89@hursley.ibm.com> Date: Mon, 29 Nov 1999 17:33:31 -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: ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses References: <199911292222.OAA05729@feller.mentat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The sad fact is that there are many people "out there" who believe that Net 10 and NAT is a security feature (e.g., see today on the IETF main list, but it's a very widespread myth). This myth is very hard to eradicate. Frankly it may be so deeply believed that eliminating site-local addresses, while academically correct, would be a tactical error ("IETF abolishes privacy feature of IPv6, allows anyone to switch on your refrigerator light"). Brian Tim Hartrick wrote: > > All, > > > > > Yes, we could do that. This is basically what the site-local prefix does > > today. I see advantages to establishing it now (stated above) and no > > advantage to waiting. > > > > In summary, I see many potential uses for site-local addresses. Making > > renumbering easier is not the only (or maybe even a good use) of site-local > > addresses. We should consider that they are most useful outside of the > > corporate workplace PC/workstation environment, where having global > > addresses is not a given. > > > > I agree with Brian on all counts. Something like Net 10 will exist in the > IPv6 world. By defining site-local addresses within the architecture we > have the opportunity to get it done right so that all of the problems which > exist in the IPv4 world with Net 10 won't exist at all, or will be lessened > substantially, in the IPv6 world. > > The consensus of this working has been in favor of this feature for a long, > long, long time. It is really disturbing that we can't move forward with > creating solutions around the existing architecture but instead keep fighting > the same battles over and over and over and over. We need to move forward. > > Tim Hartrick > Mentat Inc. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 15:50:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dATNlCZ02426 for ipng-dist; Mon, 29 Nov 1999 15:47:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATNl1c02419 for ; Mon, 29 Nov 1999 15:47:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA20215 for ; Mon, 29 Nov 1999 15:47:02 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA12003 for ; Mon, 29 Nov 1999 15:47:00 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA29110; Mon, 29 Nov 1999 15:39:59 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id PAA10312; Mon, 29 Nov 1999 15:39:59 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id PAA05773; Mon, 29 Nov 1999 15:40:57 -0800 (PST) Date: Mon, 29 Nov 1999 15:40:57 -0800 (PST) From: Tim Hartrick Message-Id: <199911292340.PAA05773@feller.mentat.com> To: bound@zk3.dec.com Subject: Re: Regarding site-local addresses Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > >I agree with Brian on all counts. Something like Net 10 will exist in the > >IPv6 world. By defining site-local addresses within the architecture we > >have the opportunity to get it done right so that all of the problems which > >exist in the IPv4 world with Net 10 won't exist at all, or will be lessened > >substantially, in the IPv6 world. > > The reasons for net 10 in IPv4 do not exist in IPv6. > I simply disagree with this assertion. And that is all it is, an assertion. The use of Net 10 in the IPv4 world is driven by more than just the lack of available globally routeable address space. Given that local addresses are both useful and problematic in IPv4 there is a powerful argument for trying to make them available and less probematic in the IPv6 world. The alternative is to wait for customer demand to force there existance at some point in the future when it will be impossible to make them less problematic. Additionally, as Matt pointed out, there are new reasons in IPv6 for private addressing. Specifically, easier support for renumbering. > > Consenus was we would like them in the architecture. But after two > years we have no solutions. In any research activity if there are no > solutions for something it is valid to re-check their merit. That is > what is being done here and I will continue to do it on anything in IPv6 > that is not being used or has been defined clearly. > > What is being asked is there still consensus for this part of IPv6. You > francis, and Brian say yes. 3 of us say no. So I guess we need to hear from > more folks. > > We do not have consensus. > So how many more times are we going to "vote" on this. Ten, twenty, fifty? As many as it takes to get the answer one side or the other wants? That is what your first paragraph implies. Everytime we start working on a solution we have to go back to square one and reevaluate the previous consensus? That doesn't sound productive. The reason we can't get to solutions is specifically because everytime some- one starts working on and attempting to discuss a solution we end up arguing about issues that have already been decided. As a result folks that don't have a bounty of extra time to simply waste on arguing the same points give up on the discussion and try and get some work done. As a result no complete solutions, just full E-mail boxes. > if we do then this time lets find a solution before we go changing > things because of them. > We have tried repeatedly to get discussions going on solutions. Every single time we end up arguing the same points over and over. Very tiresome. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 16:06:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU038G02479 for ipng-dist; Mon, 29 Nov 1999 16:03:08 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU033c02472 for ; Mon, 29 Nov 1999 16:03:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id QAA00992 for ipng@sunroof.eng.sun.com; Mon, 29 Nov 1999 16:02:39 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dATNq4c02445 for ; Mon, 29 Nov 1999 15:52:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA10991 for ; Mon, 29 Nov 1999 15:52:00 -0800 (PST) Received: from breeze.research.telcordia.com (breeze-fddi.research.telcordia.com [192.4.5.9]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14776 for ; Mon, 29 Nov 1999 15:51:55 -0800 (PST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by breeze.research.telcordia.com (8.9.3/8.9.3) with ESMTP id SAA08724; Mon, 29 Nov 1999 18:51:52 -0500 (EST) Received: from seascape.research.telcordia.com (pptpdhcp25.research.telcordia.com [192.4.9.250]) by mailee.research.telcordia.com (8.8.8/8.8.8) with SMTP id SAA00865; Mon, 29 Nov 1999 18:51:52 -0500 (EST) Message-Id: <4.1.19991129184002.009dc3d0@mailee.research.telcordia.com> X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 29 Nov 1999 18:48:22 -0500 To: "Matt Crawford" , Jim Bound From: Christian Huitema Subject: Re: Regarding site-local addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199911292305.RAA15749@gungnir.fnal.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:05 PM 11/29/99 -0600, Matt Crawford wrote: >Jim says: >> The reasons for net 10 in IPv4 do not exist in IPv6. > >True, but other reasons do exist. We've discussed them before. Can >we stop re-fighting the battles and move on? Since you're counting, >I for one am in favor of keeping site-local addresses. I tend to believe that the site-local addresses, as currently defined, will come out to hurt us in the future. I agree with Brian Zill that we have to provide a solution for the autoconfiguration of non connected sites, e.g. a home network with a mix of wireless, firewire, IP over the electric mesh, and what else. I am not sure, however, that the existence of the site address per se solves the problem. If I am not mistaken, a host will only start configuring site addresses if a router advertizes a site address prefix. This router will have to be somehow configured, and prefixes will have to be allocated to the various LANs. From an operational point of view, configuring the router with a "uniquely tagged" site local address would be no harder than using a "zero-tagged" address. The specific experiment I would like is to insert an optional site-id, or site signature, in the site-local address format. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 16:23:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU0HX502542 for ipng-dist; Mon, 29 Nov 1999 16:17:33 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU0HMc02535 for ; Mon, 29 Nov 1999 16:17:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA11527 for ; Mon, 29 Nov 1999 16:17:22 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01012 for ; Mon, 29 Nov 1999 16:17:22 -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 SAA16182 for ; Mon, 29 Nov 1999 18:16:31 -0600 (CST) Message-Id: <199911300016.SAA16182@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Regarding site-local addresses In-reply-to: Your message of Mon, 29 Nov 1999 18:48:22 EST. <4.1.19991129184002.009dc3d0@mailee.research.telcordia.com> Date: Mon, 29 Nov 1999 18:16:31 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian says: > ... If I am not mistaken, a host will only > start configuring site addresses if a router advertizes a site address > prefix. This router will have to be somehow configured, and prefixes will > have to be allocated to the various LANs. If we accept the premise that site boundaries must be manually configured, then I think the possibility of a self-organizing multi-link site is not difficult. Not quite trivial, but not difficult. An isolated router could assign random subnet numbers (or do we have to say SLAs?) and advertise them with a short lifetime -- on the order of minutes. Upon detecting another router (through means not specified here) it would exchange routing information, but not establish full connectivity until conflicting subnets are renumbered and the conflicting prefizes have been timed out by existing ND mechanisms. The prefix lifetimes might gradually increase with the size of the set of cooperating routers. Some heuristic about certain types of links being presumed not to extend the site (modems, and any other popular access medium of the day) could even relax the assumption that site boundaries need manual configuration. 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 Mon Nov 29 17:05:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU12Yr02647 for ipng-dist; Mon, 29 Nov 1999 17:02:34 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU12Pc02640 for ; Mon, 29 Nov 1999 17:02:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA15702 for ; Mon, 29 Nov 1999 17:02:25 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA26089 for ; Mon, 29 Nov 1999 17:02:24 -0800 (PST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id MAA00799; Tue, 30 Nov 1999 12:00:34 +1100 (EST) Date: Tue, 30 Nov 1999 12:00:34 +1100 (EST) From: Peter Tattam To: Brian Zill cc: "'Jim Bound'" , Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-Reply-To: <3D2036E25376D31197A100805FEAD892712F37@RED-MSG-02> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Nov 1999, Brian Zill wrote: > I changed the subject line to better reflect the issue. I think site-local > addresses, or something very much like them, is useful and will work fine. > > Jim Bound writes: > > Christian Huitema writes: > > >I have always considered the "site address" > > >an atrocious leftover of Net 10, and the more > > >I see this discussion unfolding, the stronger my > > >conviction. > > I believe that if we do not specify site-local addresses specifically, we > will end up with the equivalent of IPv4's net 10 anyway, due to marketplace > pressures. The "new devices" or "home automation" crowd will want all of > their IPv6 enabled dishwashers, water heaters, light switches, stereos, etc. > to be able to talk to one another without making Joe and Jane Average get an > Internet connection and global addresses. Since multiple links will likely > be in use in the home (power-line, telephone-line, Ethernet, multiple types > of wireless), link-local addresses will not work. If we don't define > site-local addresses now, manufacturers of such devices will either lobby > for them, use some random prefix, or simply not use IPv6. Hmm. There's a tiny hole in this argument in that there is a possibility that a customer might want a largish intranet that traverses sites. Site local addresses would not be able to be used because the routers know not to forward such packets. So there would still exist the need for a net 10 style prefix that routers would not restrict. I think there probably should be an in-between solution that by default is not routed between routers, but if needs arise such a switch can be turned off should a customer need the facility. Leaking would be minimized because you would explicitly have to enable the feature. > > > >I can swallow the unidentified link address -- > > >such address are necessary for autoconfig. > > >But I have a very hard time trying to understand > > >what exactly is good in the site address format: > > > > I agree 100%. > > The good thing about specifying site-local addresses now is that all IPv6 > routers will, by default, understand that site-local addresses must not be > forwarded outside of the site. Introducing a "net 10" at a later date is > more likely to result in leakage of such addresses into the global internet > (or between "net 10" sites). > > > >1) It does not exactly simplify autoconfig, > > > since one has to program some form of site > > > identifier in the nodes, > > > > Exactly. > > No, a single-sited end node doesn't need to know anything about site > identifiers. > > > >2) It cannot be stored in a directory, > > > > Exactly. > > No, a site-specific directory can hold site-local addresses. > > > >3) It should not be routed, but then it has > > > to be propagated for the needs of mobile nodes, > > > > Exactly. > > I don't claim to be a mobile-IP expert, but I thought this was a solved > problem in the mobile-IP draft. > > > >4) It is very hard to handle in multisited nodes. > > > > Exactly. > > I don't see this either, but I guess it depends upon your definition of > "very hard". Tagging every interface in a routing node with a node-specific > site-id and then only forwarding between like site-ids seems pretty > straight-forward. So does only allowing end node originated packets to go > out via interfaces with a site-id that matches the one in the sin6_scope_id > field. Our implementation does both of these today. > > Everything else is UI/API. The only hard part here has been getting all the > makers of stacks for "old style" computers (the kind people sit in front of > and type at) to agree on the UI/API. The "new device" crowd could care > less. Site-locals will work just fine for them. All they need is already > in RFC 2373. > > > IPv6 can work but I strongly urge you to help me > > and anyone else shoot these site-local addresses > > in the head. > > IPv6 does work. So do site-local addresses. I strongly urge everyone to > keep them as part of the standard or we'll be needlessly excluding many > potential uses of IPv6. > > > We have enough global address space with IPv6 that > > we can re-create a Net-10 within the IPv6 > > exponential number of addresses. > > Yes, we could do that. This is basically what the site-local prefix does > today. I see advantages to establishing it now (stated above) and no > advantage to waiting. > > In summary, I see many potential uses for site-local addresses. Making > renumbering easier is not the only (or maybe even a good use) of site-local > addresses. We should consider that they are most useful outside of the > corporate workplace PC/workstation environment, where having global > addresses is not a given. I generally agree with your arguments. Site local addresses have my vote. Peter > > --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 > -------------------------------------------------------------------- > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 18:20:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU2F2c02718 for ipng-dist; Mon, 29 Nov 1999 18:15:02 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU2Erc02711 for ; Mon, 29 Nov 1999 18:14:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA06029 for ; Mon, 29 Nov 1999 18:14:54 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21481 for ; Mon, 29 Nov 1999 19:14:52 -0700 (MST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id NAA05793; Tue, 30 Nov 1999 13:14:46 +1100 (EST) Date: Tue, 30 Nov 1999 13:14:45 +1100 (EST) From: Peter Tattam To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-Reply-To: <38430D4B.55A40C89@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Nov 1999, Brian E Carpenter wrote: > The sad fact is that there are many people "out there" who believe that > Net 10 and NAT is a security feature (e.g., see today on the IETF main list, > but it's a very widespread myth). > > This myth is very hard to eradicate. Frankly it may be so deeply believed > that eliminating site-local addresses, while academically correct, would be > a tactical error ("IETF abolishes privacy feature of IPv6, allows anyone > to switch on your refrigerator light"). > > Brian > Them's fighting words :) But seriously, I use net 10.0.0.0, 192.168.0.0 and 172.16.0.0 regularly for internal work. The primary reason is that I know that while I'm playing around, even if packets leak out with the addresses, it's highly unlikely that anyone outside our network can reach those addresses directly which achieves the purpose. The secondary reason is that v4 addresses for me are very difficult to obtain, especially to use them expediently in my network research. As far as security goes, to me it's horses for courses. If I want to run a full blown firewall, I can do all the necessaries, spend the money and whatever and very likely I'd use net 10 anyway just in case my firewall broke for some stupid reason. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 20:45:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU4gee02794 for ipng-dist; Mon, 29 Nov 1999 20:42:40 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU4gVc02787 for ; Mon, 29 Nov 1999 20:42:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA26302 for ; Mon, 29 Nov 1999 20:42:31 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA11451 for ; Mon, 29 Nov 1999 20:42:30 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id EB2F6151FB6; Mon, 29 Nov 1999 22:42:29 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id CE8AC148506; Mon, 29 Nov 1999 22:42:29 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 465684FB06; Mon, 29 Nov 1999 22:42:23 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id B1C294C908; Mon, 29 Nov 1999 22:42:22 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000024545; Mon, 29 Nov 1999 23:42:27 -0500 (EST) From: Jim Bound Message-Id: <199911300442.XAA0000024545@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Tue, 30 Nov 1999 03:23:51 +0900." <21640.943899831@coconut.itojun.org> Date: Mon, 29 Nov 1999 23:42:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > beware: This email is very long. The summary is: thats OK with me. This is very important. We should not limit email size to address issues in IPv6. > - I'm not promoting site-locals. OK. > - I'm promoting more correct use of scope id. OK. I will comment more on this at the very end OK as I think it will help clarify my issue here. > - Summary of my thinking on scope id is this. > - when user specifies FQDN, it should come with no explicit scope id. > FQDN must be resolved into <128bit IPv6 address, scope id> pair. > - when user specifies numeric IPv6 address, (1) user must specify > scope id explicitly, or (2) system default setting (like routing > table) must pick single scope id. Agree with you. > - There are ways to resolve FQDN into pair. > - draft-ietf-ipngwg-site-prefixes-03.txt. > consider the following situation: > - you've got site local prefix advertisement A from interface X, > interface X belongs to site ALPHA. > - you've got site local prefix advertisement B from interface Y, > interface Y belongs to site BETA. > If the given FQDN resolves to an IPv6 address that matches > A, it should be in site ALPHA. Now you have > <128-bit IPv6 address, scope> pair. > - see the latter half of my previous email. On the surface this will work but one must also accept all the assumptions in draft-ietf-ipngwg-site-prefixes-03.txt and I do not believe those assumptions have consensus. > - Even if you remove site local from the spec the above use of scope id > will not change. This is true in the abstract but the entire draft is about site-local addresses. To me that is like saying believe that horses could fly because of the story I tell, but if the story did not exist the horses can fly. So I see your point but cannot take the leap of faith to apply it to scope-ids for me. But I do see your point. > - sending NDs to multiple interfaces is a bad idea. I won't go here it will just mess up this discussion I want to keep where your going. But I do think my idea will work but that is another discussion. If its a bad idea thats not a problem I will present it anyway to see if all think its a bad idea. > Jim, sorry if you are irritated by my bad English. I really tried to Itojun. English is not an issue at this end. My issue is the notion of working on scope-ids which I think are only useful for site-local addresses, because I don't believe link-local addresses should be used by ftp, ping, telnet and friends. But I am listening. As your the only one disagreeing with me using real examples and abstract code discussion which I appreciate. > answer your questions. Let me recap. There are some reordering > of sentences. OK. >>>But let me verify something. >>>I believe you are NOT saying the user must know the scope_id for the dst >>>address to use an app? >>>I believe you are saying the user must convey the source scope_id for >>>the src of communications? >>>Which is correct above? > The above question is not "pick one of these" kind of question so > it did not make sense to me to pick one. so I answered with > descriptions. I need to do it again. OK it could be me but I thought they were yes or no answers. > For both of questions, my answer is like below. > - when user specifies FQDN, it should come with no explicit scope id. > FQDN must be resolved into <128bit IPv6 address, scope id> pair. OK. > - when user specifies numeric IPv6 address, (1) user must specify > scope id explicitly, or (2) system default setting (like routing > table) must pick single scope id. OK. > The following line in the previous email: >>> I am saying this. More correctly: > tries to answer the first question (the line was right below the first > question). I am saying that "the user must know the scope_id for > the dst address to use an app" if she specifies numeric IPv6 address. OK that was not clear for me and I just missed that. I would agree for the src address but I am not clear the user can specify that for the dst address unless it is the default rt_entry or whatever. > The following lines in the previous email: >>> If you send a packet to scoped destination address, scope zone must >>> be made un-ambiguous before you reach IPv6 layer. > tries to clarify the second question. First of all, "source scope_id" > in your question is incorrect. User need not specify "source". > All she specifies is destination. If one uses matching scope yes. But lets use those awful site-local addresses. dst address == fec0::2::3 if the node is multi-sited then it is imperative a scope be chosen. the address could live in both sites. >>You could make this discussion much better by answering my questions >>above instead of shouting at me and being controlling. If you continue to >>not answer my questions I will not respond to your mail anymore I don't >>like one-way conversations. > > I really tried to answer your questions. I did not try to shout. OK I believe you it sounded like shouting but that could be me. >>This is possible for this type of "systems application" yes. > > The rule I wrote is for all the applications. There's no difference > between systems application (like ifconfig, ping6) and normal > application (telnet, netscape). How can a user know which command > falls into which category? OK let me try this. Oracle app does getaddrinfo(host.x.com) [shortened version OK].... Well right now consensus is that the DNS only stores global addresses so if it finds one.... This is where I get lost. If DNS only stores global addresses why would the app ever get back a site-local address? It can't? Unless we fabricate one from a change to draft-ietf-ipngwg-site-prefixes-03.txt which would be necessary. Based on the site-prefix length and some knowledge that host.x.com is in one of the sites for the node. Transparent to the app. >But I am more interested in this case: >user app like Netscape, Oracle, MSA-Accounting Network Software, etc. >does: > getaddrinfo (host.foo.com) I will use your preferred API OK. >When it comes back the node has an address which it got from a DNS >lookup of the name for the dst of the node. >How does the node know what the dst scope-id is for host.foo.com? > FQDN must be resolved into <128-bit IPv6 address, scope> pair, > by using: > - draft-ietf-ipngwg-site-prefixes-03.txt. > consider the following situation: > - you've got site local prefix advertisement A from interface X, > interface X belongs to site ALPHA. > - you've got site local prefix advertisement B from interface Y, > interface Y belongs to site BETA. > If the given FQDN resolves to an IPv6 address that matches > A, it should be in site ALPHA. Now you have > <128-bit IPv6 address, scope> pair. > - see the latter half of my previous email. Agree and this would work with alteration to the site-prefix draft. But I would claim after one has done all this just use the global address. Why bother with the site-local address and that discussion needs to be revisited IMO. >> There are people trying to use link-local (zeroconf, dentist office) >> for real communication and we can't just ignore them. >> Also you have to support site-locals and multicast scopes. >I agree about the dentist office. I just don't agree that site-locals >are needed or should ever be used. > There are specs that use site-locals. To name a few: > - router renumbering > - DHCPv6 I would have to go check router renumbering but for DHCPv6 its a site-local-multicast address which I don't have issues with an are not an issue as they are common to all sites as we specify. All nodes wanting to hear that multicast must join that multicast address so the sending node does not have to worry about scope-id relating to interface. > How do you plan to change those? I don't have to change DHCPv6 and will let Matt respond to router renumbering as opposed to me going and checking. > I'm just okay if you nuke site-local addresses (as long as you update > those specs). However, even if you nuke site-locals, you need to > disambiguagte numeric IPv6 address by specifying scope id. site-local-unicast and site-local-multicast are two different types of addresses. multicast does not have the same problem set at all. >>>But I don't agree it is not user friendly and if we must figure this out >>>it must be done without the user having to know about scope-ids. >> If you wish, you can let the node admin connfigure default scope >> zone. >True. >But how is it automated? >If we just say admins go figure this out they will puke all over IPv6 >and sitelocal addresses. > Even for link-locals you need the above admin configuration, or user > specification of scope id. Right now yes but I may propose a fix for that as we have implemented it just fine. > It looks you are assuming that I'm promoting site-locals. > I'm not fan of site-locals. I'm not promoting site-locals. > I'm just promoting correct use of scope id, which applies > for ALL scoped addresses we have, like: > - link-local unicast > - site-local unicast > - multicast with 14 non-global scope I don't think multicast has the same problem set. > I'll be okay, or happy, if you nuke site-locals. Even if you nuke > site-locals, you can't forget about scope id. I would agree we need scope-id for link-local. For multicast I believe we need to specify the interface for multicast and also receive the interface it went out on. But that does no harm as if no one joined the group no one knows any better. >>> DNS issues can be solved in multiple ways, and I believe it is >>> VERY separate topic. I want you to think separately. >>Don't EVER TELL ME WHAT TO THINK AGAIN. >>I would like to discuss how this is going to work architecturally before >>we go fixing the API mechanisms under getaddrinfo. To use your favorite >>API again. > > I just tried to clarify that scope id issue and DNS issue are > very separate. It seem that you are mixing up them so I just > wanted you to separate these. I was not mixing them up. I wanted to see what you just did and that is to make this work without affecting DNS. But if there is no global address for the node in the DNS and an app looks for host.x.com then no address available comes back and even with draft-ietf-ipngwg-site-prefixes-03.txt picking a site address with no global address is very questionable in my mind. Just use the global address. > Maybe my wording was wrong, I apologize if it was. No. the sequence was hard for me to follow reading mail quickly. >>> I put a possible solution here, but THIS IS OUTSIDE OF THE KEY >>> DISCUSSION. >>> No, I never said that we are going to put scope-id into DNS. >>I never said you did if I did please send me the mail where I said you >>said this? The mail is fast now and I don't think I said you said this. > > Here's the line made me write the above: >>>>From: Jim Bound >>>>Message-Id: <199911261423.JAA0000009299@quarry.zk3.dec.com> >>>>To: itojun@iijlab.net >>>>If we do not put scope-ids in the DNS how does one know the scope-id as >>>>a user for destinations in the first place. > You look like assuming that I'm going to put scope-id into DNS > database. I may be wrong. I did not say you were going to do this above you assumed it. This is where folks must be very careful with assumptions from email. I was asking a question of an if-then construct. But I did not say you said put scope-ids in DNS. This may be an english translation problem on my part. >>> Global DNS tree MUST contain global addresses only. Local DNS tree >>> must contain 128bit portion only, and it has no scope-id in it. >>> There's no question here. >>Then the only draft we have for site-local addresses will not work if we >>all agree to this (and I agree), hence; we have no underlying solution >>to scope-ids and we are talking about changing API semantics and syntax >>for something that is not well defined for "practice" in a network site. > Do you agree with draft-ietf-ipngwg-site-prefixes-03.txt, or my lines > above? Anyway, draft-ietf-ipngwg-site-prefixes-03.txt places global > IPv6 addresses only onto DNS database so I'm saying the same thing > with draft-ietf-ipngwg-site-prefixes-03.txt. >From draft-ietf-ipngwg-site-prefixes-03.txt 8.1. Host Name Lookups The node will inspect the AAAA/A6 RRset returned from DNS to check if one or more of the global addresses belong to the same site as itself. This is done by comparing all the global addresses against all the prefixes in the Site Prefix List. If there are no matches then the site-local addresses in the RRset must not be used. If there are one or more matches then the node should prefer using the site-local address(es) over the global addresses. This can be done by sorting the addresses before they are returned to the application and excluding the addresses that are subsumed by the site-local addresses. So draft-ietf-ipngwg-site-prefixes-03.txt does say have site-local addresses in the DNS and there are other examples in the draft. My issue is if there are no site-local addresses in DNS as you and I agree with and others. Then the draft can be made to work if the DNS returns a global address from the site-prefix length addition to ND spec. But if the node has a global address I say use it. Thats where I seem to disagree with a few of you. > We have underlying solution for resolving FQDN into <128bit IPv6 > address, scope-id> pair. again: > - draft-ietf-ipngwg-site-prefixes-03.txt. > consider the following situation: > - you've got site local prefix advertisement A from interface X, >> interface X belongs to site ALPHA. > - you've got site local prefix advertisement B from interface Y, > interface Y belongs to site BETA. > If the given FQDN resolves to an IPv6 address that matches > A, it should be in site ALPHA. Now you have > <128-bit IPv6 address, scope> pair. > - see the latter half of my previous email. It takes a global address match to find this though... We are going in circles here. > If you say there's no draft, I'll write up one if you agree that > use of scope id, and user's explicit specification of scope id > are very important. if we agree on the problem in the working group then we should extend draft-ietf-ipngwg-site-prefixes-03.txt and not reinvent the wheel and make that work is my best guess approach. >> If you have site-local connectivity, you are in situation where >> you are in firewalled world. You have connectivity to inside-firewall >> nodes, who uses fec0::/10 (like 10.0.0.0/8), and global cloud. >> You can have separate DNS tree for each of them, like: >I don't agree with your premise. If your using sitelocal addresses only >then a firewall may infact not be needed like a Big Dentist Office. >I agree we can have separate DNS trees and some rules but that is not >written down anywhere or described for implementors. > Correct me if I'm wrong, I believe DNS management in firewalled > environment is never really documented. The only document I know of > is draft-ietf-dnsind-local-names-07.txt. I don't believe that really documents what we are talking about here and I don't think anyone can. Thats the whole point of a firewall. I am saying above that firewall is a non-issue for the discussion and resolution of scope-ids. > Again I'm not promoting site-locals. I just can't stop people from > using them as they are on the documents for a very long period of > time, and there are specs that depend on site-locals. Uh... Well based on all this mail. I don't think any user are using these in any fashion. And they are not even Draft Standards so we can change them at the last minute in the IETF. > Combined use of site-local and global address is very similar to > firewalled site, with sort of packet filters at the edge. Thats a stretch...but it would work but I would not advise users to do thsi anymore I would using Net 10 and NAT in IPv4. >>> You may need to configure extended /etc/resolv.conf to: >>> contact DNS server for internal.dec.com first >>> if you get the answer, scope id for sitelocal = 3 >>Whoa here. Who gave back the sitelocal equalivalent to 3? >>How did it know this? > You can pick any number as you want, as scope id is local to > a node. You just need to give different number to different site > you belong. But how did you know 3 was right? >> - You will try to resolve them looking at extended /etc/resolv.conf. >> (1) you try to resolve jimbound.internal.dec.com with site-local >> name server. if there's an entry like below: >> jimbound.internal.dec.com. IN AAAA fec0::x >> you will get the following answer into struct addrinfo. >> scopeid is filled in by LOCAL RESOLVER: >> fec0::x, scopeid = 3 >WHere again did the scope-id = 3 come from? >In resolv.conf file? >Then its hardcoded and this breaks renumbering and one of the reasons >for site-local addresses. > Again it is local to your node. This does not make any harm > to renumbering. Renumbering will occur in one of a site you belong, > not across multiple sites you belong (why "stanford" and "cisco" > needs to be renumbered at the same time?). Even if "stanford" > experiences renumber, you do not need to change your idea of > scope id for "stanford". Ohhhhh... cisco and stanford are not different sites but different domains in the truest DNS sense. So I don't agree with another of your premises. The way I view site is as follows: General Motors Truck and Bus Building is Site A Plant Floor Assembly Building is Site B Chasis Division Building is Site C A Web Server is serving all sites at General Motors to all buildings and has 3 FDDI ports to each building so each is a different link. I would claim we all don't agree on the scope of a site and its boundaries. One reason I have an issue with them being used. >>But the scope-id was filled in after the Response Query from DNS so your >>saying scope-ids are hardwired into files on the node which are then >>copied to addrinfo struct? >>This breaks renumbering objective and PIER WG would object to this >>solution. And so do I. > Yes to the first 3 lines, scope id will be filled in after the > resolver got the reply from DNS server. scope id is hardwired into > files on the node. > However, this does not break renumbering. Of course it does. Esp if only global addresses are stored in the DNS. These are needed to parse the prefix length to determine the scope-id for a site. Hence, the scope-id is relative to the prefix of a global prefix and if it changes so must the relation to the scope-id (using the database concept of relation). Somewhere the file has to relate 3ffe::23::12/48 to Site A (as an example) which relates to scope-id 3 lets say. If your using fec0::23::12/48 to speak with a node in the same site and the prefix is renumbered to say that 4ffe::45::65/48 now is the prefix for Site A the connection will break. >> This story never puts scopeid into DNS database, and works with >> multiple scope zones. >Yep and as I said breaks the principles of renumbering which are I think >important or we would not be facing what we face with A6 records. > No, renumber should work just fine. No it does not. >>> I strongly disagree. Admins are using interface id "1" or "2" >>> all the time and it is impossible. If you take link-local scoped >>> multicast address, you will have the same solicited node multicast >>> address if you have two nodes on different side with same interface ID. >>Well we can agree to disagree no problem. >>> The strategy never work if you think about site-locals (you have no >>> help from ND) >>I don't agree. > > Do you use multihomed nodes every day? Why can you live with > "send ND to all interface" node? I can't. I can that is what IPv6 is all about. Also why multicast scopes don't break anything. I just pound it out to all interfaces if the user don't specify and interface. I will receive any packets (accepting the ACK implosion if it happens of course which don't scale) that come back to me. Not a problem. >>> Scoped address will not going to vanish. Even if you may be able to >>> nuke site-local scope at next IETF:-), you can never nuke link-local >>> scope and multicast scopes. Link-locals are essential to ND >>> (apparently), and there are scenarios (dentist office) and people >>> (like zeroconf) who are trying to use link-locals in real >>> communication. Therefore, we need to make scoped address work. >>Well I intend to try to nuke site-local addresses and keep link-locals. >>See my mail response to Christian Huitema I am working on now and will >>send later. > Again, I'm not promoting site-locals. I'm just fine if you are happy > with more explicit use of scope id. I will not buy into scope-id definition until we finish issues with site-local addresses. But once we do that I agree we need them for link-local but that is a different issue. >>> Your policy (try to send packet to multiple zones) works only in the >>> following situations and you make the problem narrower by dropping >>> support for other cases: >>> - for link-local, you are assuming that you do not see same fe80::x >>> on both sides. Once you have same fe80::x on both sides by >>> coincidence, you are doomed. >>Wrong. I will see duplicate NS's in my ND daemon and this can be part >>of the NUD software too. > > NUD? isn't it DAD? No NUD. This is where ND cache lives (I agree its an implementation issue) and that is where NS's can be determined. We could put a check that when the NS happens we check if there is a similar NS on our other site interface as this should be one cache IMO. DAD could be used to check it too but I think the node should come up and then realize it has duplicated a link-local with a sister site and then fix it. But that would be part of the discussion and maybe there are other alternatives. > Anyway, I believe you are wrong. Consider the following diagram. > > fe80::x > | network A > my node > | network B > fe80::x > > On network A, fe80::x will perform DAD to detect other fe80::x on > network A. There's no such guy and DAD will success. Agreed as I said above UNLESS my-node checks its ND cache. > On network B, fe80::x will perform DAD to detect other fe80::x on > network B. There's no such guy and DAD will success. > Therefore, there will be two fe80::x visible from my node. When my-node sees that (it will be in the ND cache) it can tell one of them hey change your EUI. So I am not wrong. > You are saying that, any multi-interface node must take care of > the network on the other side during DAD process > (i.e. if fe80::x on network A transmit DAD packet, my node needs to > forward that to network B to make sure that there's no fe80::x on > network B). This is not on the spec. After DAD I am saying. So its a new spec just like draft-ietf-ipngwg-site-prefixes-03.txt. If we want to do this I will write the spec. But I am not wrong. /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 Mon Nov 29 21:41:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU5ctn02831 for ipng-dist; Mon, 29 Nov 1999 21:38:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU5cjc02824 for ; Mon, 29 Nov 1999 21:38:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA12573 for ; Mon, 29 Nov 1999 21:38:43 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA11528 for ; Mon, 29 Nov 1999 22:38:40 -0700 (MST) 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 OAA29486; Tue, 30 Nov 1999 14:36:52 +0900 (JST) To: Jim Bound cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Mon, 29 Nov 1999 23:42:26 EST. <199911300442.XAA0000024545@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Textual Address Change for Scope-IDs From: itojun@iijlab.net Date: Tue, 30 Nov 1999 14:36:52 +0900 Message-ID: <29484.943940212@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The following lines in the previous email: >>>> If you send a packet to scoped destination address, scope zone must >>>> be made un-ambiguous before you reach IPv6 layer. >> tries to clarify the second question. First of all, "source scope_id" >> in your question is incorrect. User need not specify "source". >> All she specifies is destination. >If one uses matching scope yes. But lets use those awful site-local >addresses. >dst address == fec0::2::3 >if the node is multi-sited then it is imperative a scope be chosen. the >address could live in both sites. I agree that you need to use a source address with matching scope. This is true for link-local unicast, and scoped multicasts (14 scopes) as well. >>>This is possible for this type of "systems application" yes. >> The rule I wrote is for all the applications. There's no difference >> between systems application (like ifconfig, ping6) and normal >> application (telnet, netscape). How can a user know which command >> falls into which category? >OK let me try this. Oracle app does getaddrinfo(host.x.com) [shortened >version OK].... Well right now consensus is that the DNS only stores >global addresses so if it finds one.... >This is where I get lost. If DNS only stores global addresses why would >the app ever get back a site-local address? It can't? >Unless we fabricate one from a change to >draft-ietf-ipngwg-site-prefixes-03.txt which would be necessary. >Based on the site-prefix length and some knowledge that host.x.com is in >one of the sites for the node. Transparent to the app. Name resolution can be anything. DNS, icmp namelookup, /etc/hosts, whatever. In firewalled site admins may handcruft their own DNS tree to hold scoped address just for local use. What we really need to think is how to reach the desired destination the user have specified. To do this I'm saying that more explicit use of scope id is necessary to handle: - link-local unicast - site-local unicast - scoped multicasts >> Do you agree with draft-ietf-ipngwg-site-prefixes-03.txt, or my lines >> above? Anyway, draft-ietf-ipngwg-site-prefixes-03.txt places global >> IPv6 addresses only onto DNS database so I'm saying the same thing >> with draft-ietf-ipngwg-site-prefixes-03.txt. >>From draft-ietf-ipngwg-site-prefixes-03.txt >8.1. Host Name Lookups (snip) >So draft-ietf-ipngwg-site-prefixes-03.txt does say have site-local >addresses in the DNS and there are other examples in the draft. >My issue is if there are no site-local addresses in DNS as you and I >agree with and others. Then the draft can be made to work if the DNS >returns a global address from the site-prefix length addition to ND >spec. >But if the node has a global address I say use it. Thats where I seem >to disagree with a few of you. My apologies. I need to re-read site-prefixes-03. But my thinking on use of scope id does not change (it is not tightly coupled). >> We have underlying solution for resolving FQDN into <128bit IPv6 >> address, scope-id> pair. again: >> - draft-ietf-ipngwg-site-prefixes-03.txt. >> consider the following situation: >> - you've got site local prefix advertisement A from interface X, >>> interface X belongs to site ALPHA. >> - you've got site local prefix advertisement B from interface Y, >> interface Y belongs to site BETA. >> If the given FQDN resolves to an IPv6 address that matches >> A, it should be in site ALPHA. Now you have >> <128-bit IPv6 address, scope> pair. >> - see the latter half of my previous email. >It takes a global address match to find this though... We are going in >circles here. what cycle? Could you give me a step-by-step example? >> Again I'm not promoting site-locals. I just can't stop people from >> using them as they are on the documents for a very long period of >> time, and there are specs that depend on site-locals. >Uh... Well based on all this mail. I don't think any user are using >these in any fashion. And they are not even Draft Standards so we can >change them at the last minute in the IETF. Another example of the use of site-locals. To run IBGP session in a site while allowing the site renumber, you would need to run IBGP tcp session over site-local address. >>>> You may need to configure extended /etc/resolv.conf to: >>>> contact DNS server for internal.dec.com first >>>> if you get the answer, scope id for sitelocal = 3 >>>Whoa here. Who gave back the sitelocal equalivalent to 3? >>>How did it know this? >> You can pick any number as you want, as scope id is local to >> a node. You just need to give different number to different site >> you belong. >But how did you know 3 was right? The node admin can just pick 3, or 200, or anything. This is an identifier to disambiguate scope seen from a single node (in this case the subject scope is "site"). This is just like you are calling your ethernet interface "de0", while I'm calling mine "cnw0". This will never be exposed to outside. >>WHere again did the scope-id = 3 come from? >>In resolv.conf file? >>Then its hardcoded and this breaks renumbering and one of the reasons >>for site-local addresses. Again admin can pick one at will and put that into some configuration file in the node. Even if hardcoded, this does not break renumbering in a site. >> Again it is local to your node. This does not make any harm >> to renumbering. Renumbering will occur in one of a site you belong, >> not across multiple sites you belong (why "stanford" and "cisco" >> needs to be renumbered at the same time?). Even if "stanford" >> experiences renumber, you do not need to change your idea of >> scope id for "stanford". >Ohhhhh... cisco and stanford are not different sites but different >domains in the truest DNS sense. In the above "stanford" and "cisco" are different site, and the node we're looking at is multi-sited. Then how do you think. >So I don't agree with another of your >premises. The way I view site is as follows: >General Motors > Truck and Bus Building is Site A > Plant Floor Assembly Building is Site B > Chasis Division Building is Site C >A Web Server is serving all sites at General Motors to all buildings and >has 3 FDDI ports to each building so each is a different link. >I would claim we all don't agree on the scope of a site and its >boundaries. One reason I have an issue with them being used. My proposal does not break even in the above example. I can safely assign site id 1 to A, 2 to B and 3 to C. Even when the general motors gets renumbered, the site boundary (seen from the 3-legged web server) does not change so there's no problem. Currently defined router renumbering protocol takes care of renumbering single site only. There is no good way to redefine definition of "scope boundary" at runtime. Are you going to propose the latter? >> However, this does not break renumbering. >Of course it does. Esp if only global addresses are stored in the DNS. >These are needed to parse the prefix length to determine the scope-id >for a site. Hence, the scope-id is relative to the prefix of a global >prefix and if it changes so must the relation to the scope-id (using the >database concept of relation). >Somewhere the file has to relate 3ffe::23::12/48 to Site A (as an >example) which relates to scope-id 3 lets say. >If your using fec0::23::12/48 to speak with a node in the same site and >the prefix is renumbered to say that 4ffe::45::65/48 now is the prefix >for Site A the connection will break. You can relate network interface and site id, not the prefix and site id (assuming that a network interface belongs to at most 1 site - draft-ietf-ipngwg-scoped-routing-02.txt). This was my thinking. Apologies if I sounded differently. >> Again, I'm not promoting site-locals. I'm just fine if you are happy >> with more explicit use of scope id. >I will not buy into scope-id definition until we finish issues with >site-local addresses. But once we do that I agree we need them for >link-local but that is a different issue. Hmm. I would like to know what others say. >> On network A, fe80::x will perform DAD to detect other fe80::x on >> network A. There's no such guy and DAD will success. >Agreed as I said above UNLESS my-node checks its ND cache. >> On network B, fe80::x will perform DAD to detect other fe80::x on >> network B. There's no such guy and DAD will success. >> Therefore, there will be two fe80::x visible from my node. >When my-node sees that (it will be in the ND cache) it can tell one of >them hey change your EUI. >So I am not wrong. How do you notify the victim if you think the victim's link-local is invalid? Why poor fe80::x on network A needs to change its interface ID even if it have passed DAD process successfully??? Also "my node"'s behavior is probabilistic. This may be fe80::x on A, or fe80::x on B, who will be told to leave. It must be deterministic. >> You are saying that, any multi-interface node must take care of >> the network on the other side during DAD process >> (i.e. if fe80::x on network A transmit DAD packet, my node needs to >> forward that to network B to make sure that there's no fe80::x on >> network B). This is not on the spec. >After DAD I am saying. >So its a new spec just like draft-ietf-ipngwg-site-prefixes-03.txt. >If we want to do this I will write the spec. >But I am not wrong. Your proposal does not scale. If you have more than 2 ethernet interfaces (put it as N), with 100 hosts connected to each of the medium, you need to deal with tons of such situations. To conform there's no duplicate, you need to send probes to (N-1) ethernet interfaces every time you see fe80::x on any of your interface. It is not clear when you can be sure if there's no fe80::x on other (N-1) interface (timeout parameter is very hard to determine). I would say that this is a impossible requirement for a multihomed node (both router and host). Also this is rather giant leap from the model we used in IPv4 model. Network A and B needs to be very separate. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 21:54:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU5poL02862 for ipng-dist; Mon, 29 Nov 1999 21:51:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU5pfc02855 for ; Mon, 29 Nov 1999 21:51:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA18572 for ; Mon, 29 Nov 1999 21:51:41 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11790 for ; Mon, 29 Nov 1999 21:51:40 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 10671104C1B; Mon, 29 Nov 1999 23:51:40 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 0A12EFB101; Mon, 29 Nov 1999 23:51:40 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 97905BC4CA; Mon, 29 Nov 1999 23:51:33 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 3B8F5B2A42; Mon, 29 Nov 1999 23:51:33 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000029117; Tue, 30 Nov 1999 00:51:38 -0500 (EST) From: Jim Bound Message-Id: <199911300551.AAA0000029117@quarry.zk3.dec.com> To: Tim Hartrick Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of "Mon, 29 Nov 1999 15:40:57 PST." <199911292340.PAA05773@feller.mentat.com> Date: Tue, 30 Nov 1999 00:51:38 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, This is very important and I recall when Erik first put his draft out very few of us responded and I was one of them. But now two years later after not reaching consensus on that draft I see less than optimal discussions on the use of this feature in IPv6. And it has affected anyone who has deployed IPv6 as a user not worrying about site-local addresses. For that reason and for that reason only it deservers this barage of discussion if for no other reason to drift us towards working on a solution that can be implemented. It sounds like Rich Draves is about ready to respond to Eriks proposal and I will as I said I would very soon (I wanted to look at implementation affects first) that will get us where you want to go. But if we deploy something and then we have to break our users because of a piece of IPv6 architecture that was not well defined previously you can count on me checking it to death. It could be things have changed and the reasons we wanted and supported something two years ago have changed. Also at Wash D.C. I had many many people come up to me with out me prompting them and say "I wish site-local addresses were dead" but we got them now and have to live with them. This alone deserved the position I took by "my" standards. I don't think they are needed, will never be needed, the market will not need them, they are an illusion to help renumbering, but it is going to be one of those things yet again we put in IPv6 that will create more bloat and the resolver part of our code is getting pretty bloated lately: Parse A6 Records - did I get all the addresses or just some where the chain is known. Source/Address and Matching Selection Keep cache of interfaces for the above. More code to support getaddrinfo or at least we have to move it around. Now lets parse for scope and site-identifier prefixes And we don't have consensus we have a few saying we have discussed this, lets move on, we have been here before, etc. So what! thats what this iterative process is all about. Its working on the standard for IPv6. This is new ground not known to any of us really, it is not like Net 10 at all whatsoever. But I intend to go work on Eriks draft and will leave it to others to send in their thoughts. We have had much more people say shoot site-local in the head than lets keep them. But I see your point and your frustration I hope you can see mine. /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 Mon Nov 29 21:58:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU5v6s02888 for ipng-dist; Mon, 29 Nov 1999 21:57:06 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU5uvc02881 for ; Mon, 29 Nov 1999 21:56:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA13418 for ; Mon, 29 Nov 1999 21:56:56 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15515 for ; Mon, 29 Nov 1999 22:56:56 -0700 (MST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 52F46152019; Mon, 29 Nov 1999 23:56:56 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 4EACA148506; Mon, 29 Nov 1999 23:56:56 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id A66EC4FB06; Mon, 29 Nov 1999 23:56:49 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 50FBC4C90B; Mon, 29 Nov 1999 23:56:49 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000019569; Tue, 30 Nov 1999 00:56:54 -0500 (EST) From: Jim Bound Message-Id: <199911300556.AAA0000019569@quarry.zk3.dec.com> To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of "Mon, 29 Nov 1999 17:33:31 CST." <38430D4B.55A40C89@hursley.ibm.com> Date: Tue, 30 Nov 1999 00:56:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The sad fact is that there are many people "out there" who believe that >Net 10 and NAT is a security feature (e.g., see today on the IETF main list, >but it's a very widespread myth). I hate putting stuff in architecture because of myths. I am sorry it is very distasteful. >This myth is very hard to eradicate. Frankly it may be so deeply believed >that eliminating site-local addresses, while academically correct, would be >a tactical error ("IETF abolishes privacy feature of IPv6, allows anyone >to switch on your refrigerator light"). This is unfortuneately a valid point. We have had to put a lot of stuff in IPv6 IMO for this reason; like 8 extra bytes. But this is the best mail and most honest mail I have seen pro site-local addresses. /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 Mon Nov 29 22:48:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU6fbX03044 for ipng-dist; Mon, 29 Nov 1999 22:41:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU6fOc03037 for ; Mon, 29 Nov 1999 22:41:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA21340 for ; Mon, 29 Nov 1999 22:41:23 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA25270 for ; Mon, 29 Nov 1999 23:41:23 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Nov 1999 22:39:42 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Nov 1999 22:39:41 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F3A@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Regarding site-local addresses Date: Mon, 29 Nov 1999 22:39:37 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, I'm not sure I fully understand your position. Jim Bound writes: > Don't agree, global addresses will work. > There is enough of them and the > only reason Net 10 will exist. Are you saying that to use IPv6 on more than a single link, you must have a global prefix available? That's the case if we eliminate site-local addresses. I think this is an unreasonable restriction on the use of IPv6. Every multi-link use of IPv6 should not require an Internet connection. Which it will since with IPv6, unlike IPv4, you only "lease" (from your ISP) not "own" (from a registry) your IP address space. You have to have an ISP-provided allocation to get global addresses. Every factory floor, private home, etc. is not going to want to have a permanent Internet connection. This would prevent, for example, a home with multiple links from using IPv6 when not dialed into their ISP. I think some form of site-local addressing is required to handle disconnected and occasionally connected nets. If we don't mandate a site-local prefix now, people will just start picking random ones for their disconnected networks until the whole net 10 story repeats itself. Two messages ago, I thought you were saying that we should recreate a net-10 equivalent within the global address space. But I fail to see how that differs from the currently defined site-local addresses, except for the particular pattern of bits used for the prefix. > Where is the draft that discusses the use of > site-local addresses? RFC 2373, section 2.5.8. Everything I'm arguing for here is defined there in just 13 lines of text. You said in an earlier message that you would object to forwarding this RFC from Proposed to Draft standard because of this issue, and I'm trying to understand your objections. > Do you think its Erik's? No, Erik's draft is a proposal for a method for performing site-specific name resolution. It has nothing to do with the specification and use of the addresses themselves. > If so do you agree we should do that? > We can't do it 10 different ways. At the moment, I'm ambivalent about Erik's draft. I agree that if we decide to do site-specific name resolution that we should do it in the same (or at least an interoperable) way. But it does seem to me that there is room here for local solutions (Erik's draft is an exception because it affects the global DNS). But that's a separate issue for the "Regarding site-local name resolution" thread. > >IPv6 does work. So do site-local addresses. > >I strongly urge everyone to keep them as part > >of the standard or we'll be needlessly > >excluding many potential uses of IPv6. > > They do not work in a standard interoperable > manner and the IETF has no spec on their use > other than Eriks. The spec is RFC 2373, and our implementation will interoperate with any other that follows it. I don't understand your claim that they don't work. If you want more explanation than is in 2373, Steve Deering has said he would write a more explanatory draft (and has asked me to join him on it). Would that be useful? > Are you saying we have no work to do on > site-local addresses in the working group? With the addresses themselves? Yes, I'm happy with how they're defined in RFC 2373. I think that provides the folks over in the zeroconf area, for example, with all they need to use IPv6. If you want to support site-specific name resolution, that still needs to be resolved, as does (dare I say it) the API issue. But the specification of the addresses themselves and how they're used by the protocol seems fine to me. If you're saying we have to every possible end use and aspect of site-local addresses figured out before we can include them, than I disagree with you. I will note that you recently stated in another message that we shouldn't let lack of multicast routing experience prevent IPv6 deployment (and thus the currently defined multicast addresses, which are also specified by RFC 2373). Other follow-up answers: > >No, a site-specific directory can hold > >site-local addresses. > > No one on this appears to want them in DNS > any place else is another discussion and > proposal. Also their identity would need to > be defined. More specifically, no one on this list appears to want scope-ids in the DNS. Site-local addresses is another story (Erik's draft is an example of putting site-local addresses in the global DNS; my reference above was to putting site-local addresses in a site-specific directory, which could be a private DNS). But you're right, this discussion belongs in another thread. I don't understand what you mean by "identity", could you clarify this please? > >Everything else is UI/API. The only hard > >part here has been getting all the makers > >of stacks for "old style" computers (the > >kind people sit in front of and type at) > >to agree on the UI/API. The "new device" > >crowd could care less. Site-locals will > >work just fine for them. All they need > >is already in RFC 2373. > > Simply don't agree. Which part? There are 5 sentences there. All of it? I pretty sure everyone on this list would agree that getting everyone to agree on the API has been hard :-) --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 23:06:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU72jH03090 for ipng-dist; Mon, 29 Nov 1999 23:02:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU72Zc03083 for ; Mon, 29 Nov 1999 23:02:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA17051 for ; Mon, 29 Nov 1999 23:02:33 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA00011 for ; Tue, 30 Nov 1999 00:02:33 -0700 (MST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Nov 1999 23:01:58 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Nov 1999 23:01:57 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F3B@RED-MSG-02> From: Brian Zill To: "'Peter Tattam'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Regarding site-local addresses Date: Mon, 29 Nov 1999 23:01:53 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Peter, I don't think there is a problem here. > Hmm. There's a tiny hole in this argument in that > there is a possibility that a customer might want > a largish intranet that traverses sites. Well, as currently defined, a "site" can contain 65,536 subnets. Define largish :-) I don't foresee that a single intranet will ever exceed that, but if so, there are 38 unclaimed zero bits to the left of those 16. I suppose we could explicitly reserve them now. > I think there probably should be an in-between > solution that by default is not routed between > routers, but if needs arise such a switch can > be turned off should a customer need the facility. > Leaking would be minimized because you > would explicitly have to enable the feature. Well, if router vendors make it the default for links to be in different sites unless specifically configured otherwise, you have the equivalent today. Thanks, --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 29 23:39:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAU7Zfo03134 for ipng-dist; Mon, 29 Nov 1999 23:35:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAU7ZVc03127 for ; Mon, 29 Nov 1999 23:35:31 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA25190 for ; Mon, 29 Nov 1999 23:35:31 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27078 for ; Mon, 29 Nov 1999 23:35:30 -0800 (PST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id SAA29338; Tue, 30 Nov 1999 18:35:26 +1100 (EST) Date: Tue, 30 Nov 1999 18:35:26 +1100 (EST) From: Peter Tattam To: Brian Zill cc: ipng@sunroof.eng.sun.com Subject: RE: Regarding site-local addresses In-Reply-To: <3D2036E25376D31197A100805FEAD892712F3B@RED-MSG-02> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 29 Nov 1999, Brian Zill wrote: > Hi Peter, > > I don't think there is a problem here. > > > Hmm. There's a tiny hole in this argument in that > > there is a possibility that a customer might want > > a largish intranet that traverses sites. > > Well, as currently defined, a "site" can contain 65,536 subnets. Define > largish :-) I don't foresee that a single intranet will ever exceed that, > but if so, there are 38 unclaimed zero bits to the left of those 16. I > suppose we could explicitly reserve them now. Arrgghhh... silly me. I think I have site local and link local addressing mixed up. My counter argument was based on the premise that widely dispersed routers might not want to easily route site local addresses. If this can be guaranteed to still work, I can see no reason why specifically defined site local addresses should continue to exist, and that what has been done so far should have no problem. How about a "hands up" for all those who have worked with net 10 style addresses. For me, I don't have a problem. They serve their limit purpose well. I feel that I would be deprived if they were no longer available. > > > I think there probably should be an in-between > > solution that by default is not routed between > > routers, but if needs arise such a switch can > > be turned off should a customer need the facility. > > Leaking would be minimized because you > > would explicitly have to enable the feature. > > Well, if router vendors make it the default for links to be in different > sites unless specifically configured otherwise, you have the equivalent > today. > > Thanks, > --Brian > Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 30 03:39:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAUBagL03475 for ipng-dist; Tue, 30 Nov 1999 03:36:42 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAUBaXc03468 for ; Tue, 30 Nov 1999 03:36:34 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA08364 for ; Tue, 30 Nov 1999 03:36:32 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19861 for ; Tue, 30 Nov 1999 03:36:31 -0800 (PST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA21286; Tue, 30 Nov 1999 12:29:31 +0100 (MET) Message-ID: <19991130122930.A20758@theory.cs.uni-bonn.de> Date: Tue, 30 Nov 1999 12:29:30 +0100 From: Ignatios Souvatzis To: Brian Zill , "'Jim Bound'" Cc: ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses References: <3D2036E25376D31197A100805FEAD892712F3A@RED-MSG-02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <3D2036E25376D31197A100805FEAD892712F3A@RED-MSG-02>; from Brian Zill on Mon, Nov 29, 1999 at 10:39:37PM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Nov 29, 1999 at 10:39:37PM -0800, Brian Zill wrote: > Hi Jim, > > I'm not sure I fully understand your position. > > Jim Bound writes: > > Don't agree, global addresses will work. > > There is enough of them and the > > only reason Net 10 will exist. > > Are you saying that to use IPv6 on more than a single link, you must have a > global prefix available? That's the case if we eliminate site-local > addresses. > I think this is an unreasonable restriction on the use of IPv6. Every > multi-link use of IPv6 should not require an Internet connection. Which it > will since with IPv6, unlike IPv4, you only "lease" (from your ISP) not > "own" (from a registry) your IP address space. You have to have an > ISP-provided allocation to get global addresses. Every factory floor, > private home, etc. is not going to want to have a permanent Internet > connection. This would prevent, for example, a home with multiple links > from using IPv6 when not dialed into their ISP. About what I wanted to say. -is -- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals. -- obs@burnout.demon.co.uk (obscurity) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 30 07:26:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAUFN5J03733 for ipng-dist; Tue, 30 Nov 1999 07:23:05 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAUFMuc03726 for ; Tue, 30 Nov 1999 07:22:56 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA20187 for ; Tue, 30 Nov 1999 07:22:46 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15838 for ; Tue, 30 Nov 1999 07:22:44 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 26910104D47; Tue, 30 Nov 1999 09:22:44 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id 13AB7FB102; Tue, 30 Nov 1999 09:22:44 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id ACA644FB08; Tue, 30 Nov 1999 09:22:37 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 154844C909; Tue, 30 Nov 1999 09:22:37 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000007084; Tue, 30 Nov 1999 10:22:37 -0500 (EST) From: Jim Bound Message-Id: <199911301522.KAA0000007084@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Tue, 30 Nov 1999 14:36:52 +0900." <29484.943940212@coconut.itojun.org> Date: Tue, 30 Nov 1999 10:22:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>If one uses matching scope yes. But lets use those awful site-local >>addresses. >>dst address == fec0::2::3 >>if the node is multi-sited then it is imperative a scope be chosen. the >>address could live in both sites. > > I agree that you need to use a source address with matching scope. > This is true for link-local unicast, and scoped multicasts (14 scopes) > as well. The reason I don't agree that multicast has the same property set problem is as a sender I can spray multicast on all scope set of interfaces. Its an address to listen too for receivers. In the responses to the sender the scope is known from any responses as it comes back on an interface. This disambiguates the scope to the sender from the responses. Unicast scopes have a different problem set in my view. > What we really need to think is how to reach the desired > destination the user have specified. To do this I'm saying that > more explicit use of scope id is necessary to handle: > - link-local unicast > - site-local unicast > - scoped multicasts All multicast addresses are scoped. These are not the same issue. >>> We have underlying solution for resolving FQDN into <128bit IPv6 >>> address, scope-id> pair. again: >>> - draft-ietf-ipngwg-site-prefixes-03.txt. >>> consider the following situation: >>> - you've got site local prefix advertisement A from interface X, >>>> interface X belongs to site ALPHA. >>> - you've got site local prefix advertisement B from interface Y, >>> interface Y belongs to site BETA. >>> If the given FQDN resolves to an IPv6 address that matches >>> A, it should be in site ALPHA. Now you have >> <128-bit IPv6 address, scope> pair. >>> - see the latter half of my previous email. >>It takes a global address match to find this though... We are going in >>circles here. > what cycle? Could you give me a step-by-step example? Same algorithm re-stated is all I was saying. >>> Again I'm not promoting site-locals. I just can't stop people from >>> using them as they are on the documents for a very long period of >>> time, and there are specs that depend on site-locals. >>Uh... Well based on all this mail. I don't think any user are using >>these in any fashion. And they are not even Draft Standards so we can >>change them at the last minute in the IETF. > Another example of the use of site-locals. > To run IBGP session in a site while allowing the site renumber, > you would need to run IBGP tcp session over site-local address. This I agree could be a good use of site-local addresses. >>>>> You may need to configure extended /etc/resolv.conf to: >>>>> contact DNS server for internal.dec.com first >>>>> if you get the answer, scope id for sitelocal = 3 >>>>Whoa here. Who gave back the sitelocal equalivalent to 3? >>>>How did it know this? >>> You can pick any number as you want, as scope id is local to >>> a node. You just need to give different number to different site >>> you belong. >>But how did you know 3 was right? > The node admin can just pick 3, or 200, or anything. This is an > identifier to disambiguate scope seen from a single node (in this case > the subject scope is "site"). > This is just like you are calling your ethernet interface "de0", > while I'm calling mine "cnw0". This will never be exposed to outside. I know that. What I was asking where did one set the relation between Site A = 3 and Site B = 4. But nevermind I know the answer and how I would do it. >>>WHere again did the scope-id = 3 come from? >>>In resolv.conf file? >>>Then its hardcoded and this breaks renumbering and one of the reasons >>>for site-local addresses. > > Again admin can pick one at will and put that into some configuration > file in the node. > > Even if hardcoded, this does not break renumbering in a site. It does. Any relations that exist which depend on the site prefix will break when the site prefix changes. If the site prefix is based on a global address then the site address mechanics are affected by a renumber operation on global addresses. >>> Again it is local to your node. This does not make any harm >>> to renumbering. Renumbering will occur in one of a site you belong, >>> not across multiple sites you belong (why "stanford" and "cisco" >>> needs to be renumbered at the same time?). Even if "stanford" >>> experiences renumber, you do not need to change your idea of >>> scope id for "stanford". >>Ohhhhh... cisco and stanford are not different sites but different >>domains in the truest DNS sense. > In the above "stanford" and "cisco" are different site, and the > node we're looking at is multi-sited. Then how do you think. So the node in the middle is connected to both cisco and stanford? Then that is fine. That was not clear to me anyway in your mail above. >>So I don't agree with another of your >>premises. The way I view site is as follows: >>General Motors >> Truck and Bus Building is Site A >> Plant Floor Assembly Building is Site B >> Chasis Division Building is Site C >>A Web Server is serving all sites at General Motors to all buildings and >>has 3 FDDI ports to each building so each is a different link. >>I would claim we all don't agree on the scope of a site and its >>boundaries. One reason I have an issue with them being used. > My proposal does not break even in the above example. I can safely > assign site id 1 to A, 2 to B and 3 to C. Even when the general > motors gets renumbered, the site boundary (seen from the 3-legged > web server) does not change so there's no problem. Sure it will. The reason is that a scope-id by itself as a unary type is useless without an address. The tuple must have two elements: site A or 1 prefix associated with this site according to Erik's draft If the prefix changes then the tuple is invalid and must be updated. > Currently defined router renumbering protocol takes care of renumbering > single site only. There is no good way to redefine definition of > "scope boundary" at runtime. Are you going to propose the latter? Not me. You should send this out as separate mail thread and ask Matt Crawford to respond. >>> However, this does not break renumbering. >>Of course it does. Esp if only global addresses are stored in the DNS. >>These are needed to parse the prefix length to determine the scope-id >>for a site. Hence, the scope-id is relative to the prefix of a global >>prefix and if it changes so must the relation to the scope-id (using the >>database concept of relation). >>Somewhere the file has to relate 3ffe::23::12/48 to Site A (as an >>example) which relates to scope-id 3 lets say. >>If your using fec0::23::12/48 to speak with a node in the same site and >>the prefix is renumbered to say that 4ffe::45::65/48 now is the prefix >>for Site A the connection will break. > You can relate network interface and site id, not the prefix and > site id (assuming that a network interface belongs to at most 1 > site - draft-ietf-ipngwg-scoped-routing-02.txt). This was my thinking. > Apologies if I sounded differently. I don't have time right now to go look at that draft today. I will as the solution to this progresses. You may want to point this out too in a separate mail thread. >>> Again, I'm not promoting site-locals. I'm just fine if you are happy >>> with more explicit use of scope id. >>I will not buy into scope-id definition until we finish issues with >>site-local addresses. But once we do that I agree we need them for >>link-local but that is a different issue. > Hmm. I would like to know what others say. OK. >>> On network A, fe80::x will perform DAD to detect other fe80::x on >>> network A. There's no such guy and DAD will success. >>Agreed as I said above UNLESS my-node checks its ND cache. >>> On network B, fe80::x will perform DAD to detect other fe80::x on >>> network B. There's no such guy and DAD will success. >>> Therefore, there will be two fe80::x visible from my node. >>When my-node sees that (it will be in the ND cache) it can tell one of >>them hey change your EUI. >>So I am not wrong. > How do you notify the victim if you think the victim's link-local > is invalid? That would be a new ND message type or option. > Why poor fe80::x on network A needs to change its interface ID > even if it have passed DAD process successfully??? yep. > Also "my node"'s behavior is probabilistic. This may be fe80::x on A, > or fe80::x on B, who will be told to leave. It must be deterministic. the first one in my-nodes ND cache wins. >>> You are saying that, any multi-interface node must take care of >>> the network on the other side during DAD process >>> (i.e. if fe80::x on network A transmit DAD packet, my node needs to >>> forward that to network B to make sure that there's no fe80::x on >>> network B). This is not on the spec. >>After DAD I am saying. >>So its a new spec just like draft-ietf-ipngwg-site-prefixes-03.txt. >>If we want to do this I will write the spec. >>But I am not wrong. > Your proposal does not scale. If you have more than 2 ethernet > interfaces (put it as N), with 100 hosts connected to each of the > medium, you need to deal with tons of such situations. To conform > there's no duplicate, you need to send probes to (N-1) ethernet > interfaces every time you see fe80::x on any of your interface. > It is not clear when you can be sure if there's no fe80::x on > other (N-1) interface (timeout parameter is very hard to determine). > I would say that this is a impossible requirement for a multihomed > node (both router and host). First. I think in future discussions be careful to say I am wrong. All I said is I could make it work. Saying it don't scale is fine I did not say it did. So saying things like "your wrong" is not a good presentation to one discussing something with another. It implies it can't be done. It can be done but may not scale is a different statement and a different tone in a discussion. There are times to say the words wrong, or you don't have a clue, or whatever, but that is not I hope where our discussion has been. But back to the point of scaling. But again your using the word "impossible" above. Please don't do that it is not valid. You contradict yourself. First you say it will not scale meaning to me anyway it will work but perform poorly. You should have said: This is not an optimal requirement for a node. This I would deal with well and I think others. But I would argue the entire issue of scopes is not optimal and either will be the solution. Anyway I will jump into a fight very quickly when folks use fighting words and I don't think that is what you intended or is your objective to try to belittle me or anything like that. But I could perceive that with some of the words you use at times. I know what interface and what address is associated with that interface, hence, what link it is on and thus what site it is in. I would not have to probe all interfaces or all sites I would know that from the array of pointers in my ND cache. It clearly adds more code to ND processing. But I have decided to go work on Erik's draft for now and get off this thread as some on the list don't want to discuss this anymore. > Also this is rather giant leap from the model we used in IPv4 model. > Network A and B needs to be very separate. The entire notion of site-local and link-local addresses and having to add scope-ids to addresses is a giant leap from the IPv4 model, hence so is my proposal to fix it for link-local. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 30 07:26:21 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAUFNrL03742 for ipng-dist; Tue, 30 Nov 1999 07:23:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAUFNec03735 for ; Tue, 30 Nov 1999 07:23:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA16926 for ; Tue, 30 Nov 1999 07:23:41 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16376 for ; Tue, 30 Nov 1999 07:23:39 -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 JAA19994; Tue, 30 Nov 1999 09:16:00 -0600 (CST) Message-Id: <199911301516.JAA19994@gungnir.fnal.gov> To: Jim Bound Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Regarding site-local addresses In-reply-to: Your message of Tue, 30 Nov 1999 00:51:38 EST. <199911300551.AAA0000029117@quarry.zk3.dec.com> Date: Tue, 30 Nov 1999 09:16:00 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, you keep saying we never had consensus on site-local addresses but obviously we did because 2373 passed WG & IETF last call. Please make it clear that you're talking about Erik's site-prefixes draft, if that's what you do mean. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 30 07:29:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAUFSMr03769 for ipng-dist; Tue, 30 Nov 1999 07:28:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAUFSBc03762 for ; Tue, 30 Nov 1999 07:28:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA21677 for ; Tue, 30 Nov 1999 07:28:11 -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 IAA26175 for ; Tue, 30 Nov 1999 08:28:10 -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 JAA20062; Tue, 30 Nov 1999 09:27:14 -0600 (CST) Message-Id: <199911301527.JAA20062@gungnir.fnal.gov> To: Peter Tattam Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Regarding site-local addresses In-reply-to: Your message of Tue, 30 Nov 1999 18:35:26 +1100. Date: Tue, 30 Nov 1999 09:27:14 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter T says: > Arrgghhh... silly me. I think I have site local and link local addressing > mixed up. My counter argument was based on the premise that widely dispersed > routers might not want to easily route site local addresses. If this can be > guaranteed to still work, I can see no reason why specifically defined site > local addresses should continue to exist, and that what has been done so far > should have no problem. Now I have no idea at all what you are saying. > How about a "hands up" for all those who have worked with net 10 > style addresses. Yo. I've used nets from the 192.168.0.0/16 block where link-local would have been appropriate, and from 172.16.0.0/12 where site-local would have been appropriate. 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 Tue Nov 30 07:54:11 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAUFpGL03841 for ipng-dist; Tue, 30 Nov 1999 07:51:16 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAUFp7c03834 for ; Tue, 30 Nov 1999 07:51:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA23468 for ; Tue, 30 Nov 1999 07:51:07 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03479 for ; Tue, 30 Nov 1999 07:51:06 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 7DCB757952; Tue, 30 Nov 1999 09:50:54 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 7B5A754603 for ; Tue, 30 Nov 1999 09:50:54 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 3C5844FB0C; Tue, 30 Nov 1999 09:50:48 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id C02E44C909; Tue, 30 Nov 1999 09:50:47 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000023410; Tue, 30 Nov 1999 10:50:53 -0500 (EST) From: Jim Bound Message-Id: <199911301550.KAA0000023410@quarry.zk3.dec.com> To: Brian Zill Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of "Mon, 29 Nov 1999 22:39:37 PST." <3D2036E25376D31197A100805FEAD892712F3A@RED-MSG-02> Date: Tue, 30 Nov 1999 10:50:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >I'm not sure I fully understand your position. Then any more mail on this list is not going to help or yet another response. I will be working on Erik's draft at this point. If we can define a workable solution then thats great. But if 2373 went to go for DS I would just send my objection to the IESG at this point as one engineers view, until I see a draft like Eriks that demonstrates the use of site-local addresses that has consensus. And I would claim to the IESG as one of the Ipv6 architects, long-time implementor of IPv6, and one of the diehard champions of IPv6, that they need to see more about site-locals than we have done thus far for that address type, before making it a DS which means its essence is frozen. I am done discussing it here, based on the nasty probes I am getting. Like Francis's too and yours. Itojun is talking to me the way he talks I have no issue with that mail exchange. Tim is just tired of the discussion as is Matt. Several people has the common sense to send me private mail to see where I was coming from which I appreciate if things get confused. There are enough IPv6 addresses that we should never need Net-10 for even the lightbulb in my fridge. Brian Carpenters mail convinced me to move on here not yours or the other mail. He hit the nail on the head. It is tactically required to support them and I will not win the political battle even if I could win the technical battle. Also all this mail has completely convinced me that IPv6 is DEFINITELY NOT READY FOR FULL STANDARD status, and for that I am grateful. Per a discussion in another forum we are both on. p.s. the problem with your word "complaining" in previous mail is as follows. saying I am complaining is like saying I am "whining" saying I have objections is fine. words to me are important they convey attitude. I too use words like that but own up to them when I do. And sometimes those words are important to use. right now I am a bit mifted at you and your presentation, I will get over it but my genetic makeup and lifes experiences taught me to not "hold" grudges, hell I "embrace" them. But I will get over it in time. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 30 08:24:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAUGLaQ03903 for ipng-dist; Tue, 30 Nov 1999 08:21:36 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAUGLRc03896 for ; Tue, 30 Nov 1999 08:21:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA18965 for ; Tue, 30 Nov 1999 08:21:28 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22920 for ; Tue, 30 Nov 1999 08:21:25 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 7A628151FBA; Tue, 30 Nov 1999 10:21:18 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id 72B13148506; Tue, 30 Nov 1999 10:21:18 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id EC285BC4CC; Tue, 30 Nov 1999 10:21:11 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 6C602B2A43; Tue, 30 Nov 1999 10:21:11 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000013382; Tue, 30 Nov 1999 11:21:17 -0500 (EST) From: Jim Bound Message-Id: <199911301621.LAA0000013382@quarry.zk3.dec.com> To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of "Tue, 30 Nov 1999 09:16:00 CST." <199911301516.JAA19994@gungnir.fnal.gov> Date: Tue, 30 Nov 1999 11:21:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Jim, you keep saying we never had consensus on site-local addresses >but obviously we did because 2373 passed WG & IETF last call. Please >make it clear that you're talking about Erik's site-prefixes draft, >if that's what you do mean. thats a good point. Yes I am working on Eriks draft now. I am off this topic. There is a lot in 2373. I think there is a bug with site-local. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 30 09:05:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAUH2c804004 for ipng-dist; Tue, 30 Nov 1999 09:02:38 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAUH2Tc03997 for ; Tue, 30 Nov 1999 09:02:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA04695 for ; Tue, 30 Nov 1999 09:02:29 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12140 for ; Tue, 30 Nov 1999 10:02:27 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA09586 for ; Tue, 30 Nov 1999 09:02:25 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199911300556.AAA0000019569@quarry.zk3.dec.com> References: <199911300556.AAA0000019569@quarry.zk3.dec.com> Date: Tue, 30 Nov 1999 09:02:28 -0800 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Re: Regarding site-local addresses Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Though I am not especially fond of site-local addresses myself, the working group previously made the decision to keep site-locals in the architecture, based on all the same pro and con arguments that are being replayed now. I have not seen any new observations that would justify revisiting that decision, and to go back on that decision would do much more harm than good at this point, in my opinion. The same is true for the notion of embedding a site ID inside a site- local address. I feel badly about not paying more attention to the API specs when they were first being written. I had hoped that the few discussions we had during IETF meetings (e.g., the discussions that clarified that scope boundaries cut through nodes, not links), would have been sufficient to make clear the consequences of scoped addresses on the APIs, forwarding rules, routing data structures, user interfaces, etc., but that was wishful thinking on my part. Clearly some people understood these issues at the time, but others have had to spend a lot of time and email discovering them, effort that could have been avoided if I had delivered on my frequent promises to write up what I understood about scoped addresses (something I *still* intend to do). (As a weak defence, I'll point out that issues of APIs, UIs, data structures, etc. have traditionally been considered out-of-scope for the IETF -- our job has been to define the formats of packets and the required/desired/allowed behavior of nodes as observable from the outside, leaving maximum freedom to the implementors in how they accomplish those behaviors. We have more often been chastised for over-specifying protocols, than for under-specifying them, when it comes to node internals.) Anyway, most of the implementors active on this list appear to have worked out the consequences of scoped addresses and are doing the right things to support them, and are sharing that knowledge. The one major area of uncertainty is name resolution, and on that topic I must disagree with Jim that there is WG consensus that site-local addresses must never appear in (any part of) the DNS. Too few people have commented on that, and there is insufficient agreement among those who have commented, to conclude that there is any such consensus. I can well imagine that name resolution for site-locals would best be handled by DNS servers within each site, and I think it is far too premature to rule that out. I also don't think the lack of a current agreement on how name resolution will be done for site-locals represents any sort of major "flaw" in IPv6. Reaching agreement on, documenting, and standardizing all the aspects of IPv6 has been a big job, of course, and it was quite reasonable to defer this particular, relatively low-priority issue, while working out other, more important issues. After all, the lack of an agreed way to do site-local name resolution does not prevent the deployment and use of IPv6, as those who think site-locals ought to be abolished must agree. It just prevents user-friendly use of site-local addresses at this point in IPv6's development. And as others have pointed out, it would easier to make progress on that problem if we didn't have to spend so much time re-arguing issues that have already been decided. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 30 10:24:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dAUILTL04310 for ipng-dist; Tue, 30 Nov 1999 10:21:29 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dAUILOc04303 for ; Tue, 30 Nov 1999 10:21:25 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA01683 for ipng@sunroof.eng.sun.com; Tue, 30 Nov 1999 10:20:58 -0800 (PST) Received: from antley.eng.sun.com (antley [129.146.86.225]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with SMTP id dAU87Oc03202 for ; Tue, 30 Nov 1999 00:07:24 -0800 (PST) Received: from antley by antley.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA12803; Tue, 30 Nov 1999 00:06:43 -0800 Message-Id: <199911300806.AAA12803@antley.eng.sun.com> Date: Tue, 30 Nov 1999 00:06:43 -0800 (PST) From: Carl Williams Reply-To: Carl Williams Subject: Scope ID secret Cabal (minutes) To: ipng@sunroof.eng.sun.com Cc: carlw@antley.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: XyFBtmJAcp67yFlLP5Ix4g== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound asked a number of the ipng wg members who have been working on the IPv6 extensions to the socket API to meet, discuss and provide feedback to the ipng working group on the effects of the scope id with the existing IPv6 socket API. Below are the minutes to the meeting. I tried to provide some organization to the note taking I did. Here is the organization: - Purpose of meeting - Who Attended - APIs that are effected by the scope id issue - Some raw discussion details of our debate - Conclusions/recommendations - Issues the group didn't reach agreement on We attempted to be complete in identifying all API issues relating to scope id. It is the hope that by publishing these minutes that they will serve to focus debate and discussion on the scope address issue in order to facilitate a complete solution this time around. Carl Minutes from IETF-DC socket API meeting --------------------------------------- Purpose of meeting: Jim Bound asked a number of the ipng wg members who are working on implementing the IPv6 extensions to the socket API to meet and discuss the problems of the scope id with the existing IPv6 socket API. We were asked to publish to the working group alias any recommendations that the group arrived at as well as enumerate any additional issues in which no consensus was reached. At a minimum the group sought to enumerate all the issues of scope addresses with the existing IPv6 socket specification and publish them to the ipng alias. Attendees of the Meeting: Jack McCann (Compaq), Tim Hartrick (Mentat), Chris Harding (Open Group), Brian Zill (MSFT), Jun-ichiro Hagino (KAME project), Tatuya Jinmei (KAME Project), Carl Williams (Sun), Yanick Pouffary (Compaq), Maryann Maher (ISI). Minutes were sent out to all participants including Erik Nordmark (Sun) and Jim Bound (Compaq) for editing purposes. It shouldn't be assumed that each participant agrees to all the statements detailed in the minutes. The working group participants were able to reach consensus on some key items which have been outlined in the "Recommendation" section below. APIs that are effected by the scope id issue -------------------------------------------- o getipnodebyname(), getipnodebyaddr() o inet_ntop(), inet_pton() o INET6_ADDRSTRLEN o ifindex APIs getipnodebyname()/getipnodebyaddr() =================================== The group identified possible options to dealing with scope addresses and the getipnodebyname()/getipnodebyaddr() APIs: (a) Extend the getipnodebyname() interface to work with scoped addresses. (b) Standard compile flag fix (c) Deprecate getipnodebyname()/getipnodebyaddr() (d) Define function to cut out scope id and pass it into a yet to be defined function. The other address portion would be passed into getipnodebyaddress() (e) Simply use getaddrinfo()/getnameinfo() as scopes are transparent to these interfaces. (a) would break backward compatibility. A compile flag was not a realistic option and deprecating getipnodebyname()/getipnodebyaddr() may have unwanted psychological consequences on those looking to port their applications to use the IPv6 socket API. The conclusion the group reached was to adopt (e) and provide an applicability statement for the getipnodebyname() and getipnodebyaddr() interfaces detailing the circumstances of the limitations of these APIs. Problem with scope information and name-to-address and address-to-name resolution: * Comments made during the meeting * Resolver should know what scope the host is in so DNS knows who to query. There could be two DNS servers to query (in case of host in two sites). Want to look at the scope id to know which one. Magic won't be generic to DNS. A comment was made that it is conceivable that you can call on both - pass back scope info to state which direction you're going. *** Get same information if you're feeding into getaddrinfo(). Tim: More than one reason against doing this. First, you have the same exact problem if the host is multihomed. Link local addresses with this identifier makes getipnodebyname() useless for multihome host. Brian: Vendors/Implementors have been writing applications with getipnodebyname()/getipnodebyaddr() and testing them with global address and then in the field people are using link local addresses and things break. Jun-ichiro: Use site address on wrong link is API or configuration issue. DNS is only name service that has this problem. addr something scope_id restrict it to only numeric address. Does name correspond to address and scope. If name is in both sites, DNS will respond to both sites (fec0@japan, feco@usa). Type in fully-qualified domain name. If you use scope id, then name should contain scope. Resolver should return addr + scope id. Should we allow a scope qualifier on a name? No, DNS will decide which one you hit based on domain search order. Jack: Why site specific for numeric and not more? Jun-ichiro: System administrator must configure DNS correctly so that there is no name collision. Jun-ichiro proposed the following mapping: -> Jun-ichiro will send out more details (in separate email) to the ipng working group alias on a proposal to map between FQDN, numeric, and scope. Brian: Asked whether textual representations of scope ids with addresses should apply only to numeric addresses or nodenames (fully qualified or not). In other words, would we support "1/deering" and/or "cisco/deering". (This assumes that we _are_ supporting things like "1/fec0::dead:beef:cafe" and "cisco/fec0::dead:beef:cafe") The answer (quickly voiced and not challenged) was no, we wouldn't support those. A nodename should always map to a scope id and numeric address, so attaching a scope id to a nodename would be ambiguous since you'd have two scope ids then. Jack: We have been living in denial regarding scope addresses. Jim B: Can't break existing binaries. Can't deprecate getipnodeby*(). Tim: There is no "water to wine" solution. Can't fix getipnodeby*() in binary compatible way. We only need one set of interfaces. We have those with getaddrinfo()/getnameinfo() which work with scope addresses. Even if getipnodebyname() was extended to work with scope addresses, old binaries will still do the old thing. getaddrinfo() ============= Should also define the AI_ADDRCONFIG flag with getaddrinfo(). This allows applications to weed out addresses that they can't communicate with. There was also a proposal to have getaddrinfo() return mapped addresses. There were concerns that this would change the basic definition of getaddrinfo() in terms of it being protocol-independent. Since there is little support for fixing getipnodebyname(), it is being recommended that the getaddrinfo() flags (ai_flags field of addrinfo structure) value also support: AI_ADDRCONFIG AI_DEFAULT AI_ALL AI_V4MAPPED The current programming paradigm that is being recommended with getaddrinfo() remains intact. There may be some cases whereby being able to toggle getaddrinfo() to return only AF_INET6 with mapped addresses may make porting existing applications easier. This proposal is allowing additional flexibility similar to what getipnodebyname() offers. For example, the application can choose to have only AF_INET6 addrinfo structures returned by getaddrinfo (containing mapped addresses) rather than deal with both AF_INET and AF_INET6 sockets (using pure IPv4 and native IPv6 addresses). Recommendations =============== The participants attending the API meeting reached a consensus on the following issues. We are making these recommendations to the ipng working group alias for debate. 1. It is recommended that we should leave getipnodebyname()/ getipnodebyaddr() as they are and provide an applicability statement detailing the circumstances of the limitations of these APIs. It was recommended that the getaddrinfo()/getnameinfo() APIs work with scope addresses and as such applications should simply use these APIs. 2. Add the AI_ADDRCONFIG flag to getaddrinfo(). There was discussion at this meeting of whether this was ok given that POSIX has a copyright on this API. Chris Harding explained that we could change this API. Currently, the XNET is being merged into the Austin group. Chris states that as far as XNS and POSIX are concerned, we should proceed with the current plan, which is to merge the sockets part of the recently approved XNS specification into the Austin Group work on a combined Open Group/POSIX standard for UNIX. (There is a Sanity Check of XNS still to come, but we can not make technical changes during a Sanity Check). The new version of XNS should not be published, but be used purely as input to Austin. Chris points out that once the dust has settled on what is needed to be done to the API to fix this problem, we can input that to the Austin Group so that it can be incorporated in the joint UNIX standard. 3. inet_ntop()/inet_pton() It is recommended that the use of getaddrinfo() and getnameinfo() be used with the AI_NUMERICHOST flag to obtain the same functionality that inet_ntop()/inet_pton() provides but still work with scope addresses. 4. It was noted at the meeting that the getxxxbyyyy call (e.g., getipnodebyname()) made porting existing applications easier (more of a 1-1 mapping). A bit more coding when using the getaddrinfo()/getnameinfo() functions. 5. It was obvious to everyone at the meeting that there is no "water to wine" solution. Other Issues: ============= Other issues that we didn't have enough time to discuss and that we are noting so that they can be discussed on the ipng alias: 1. INET6_ADDRSTRLEN INET6_ADDRSTRLEN is defined to be 46 characters. The value of INET6_ADDRSTRLEN depends on how we make a textual representation of "scope_id" portion. There was some mention in the meeting for defining the following getnameinfo(3) flags: NI_NUMREICHOST host is numeric (46 digits maximum) NI_NUMREICSCOPE scope is numeric (2^32 => 10 max digits) NI_NUMREICPORT port is numeric (2^16 => 5 digits) getnameinfo(3) would return: fec0::1@cisco if you give NI_NUMERICHOST fec0::1@3 if you give NI_NUMERICHOST | NI_NUMERICSCOPE deering.cisco.com if you give NI_NUMERICSCOPE deering.cisco.com if you give 0 Jun-ichiro also stated in a follow-up email that it is okay to leave INET6_ADDRSTRLEN as is (= 46), and add a note that says "it is only for inet_ntop(), don't use it with getnameinfo. This does not include scope portion". Jun-ichiro points out that we have NI_MAXHOST for getnameinfo, which is the only function that returns addr@scope of scope/addr. NI_MAXHOST is more suitable than INET6_ADDRSTRLEN as getnameinfo may return a string for other protocol families as well. Jun-ichiro and others recommend that NI_MAXHOST should be used for getnameinfo() and RFC2553-bis should say it loudly. 2. How do we make the stuff that currently uses ifindex (such as joining a multicast group) provide the ability to say "use that site" instead of specifying an actual interface. We didn't discuss this issue during our meeting but I would like to note the problem in the minutes for completeness. Courtesy of Erik I included his summary on the ifindex issue: "The issues I brought up in Tokyo (see my slides). One of the things that is missing wrt different scopes/zones is: How do we make the stuff that currently uses ifindex (such as joining a multicast group) provide the ability to say "use that site" instead of specifying an actual interface. The room suggested generalizing the use of ifindex in the API to be a "zone id". Thus you could envision calling if_nametoindex("cisco") where "cisco" is a site name advertised using MZAP (or in Router Advertisements if we choose to incorporate MZAP functionality as a new option) and the resulting index would be used in IPV6_JOIN_GROUP, IPV6_MULTICAST_IF, etc. If we choose to go this way it would make sense to generalize the name if_nametoindex to be e.g. zone_nametoindex (while preserving the old for compatibility) and presumably having a zone_nameindex which can produce different types of lists (interfaces, links, sites). But perhaps we need to have the more general discussion if this all makes sense before we look at extensions and clarifications to the basic API." 3. It is recommended that the following getipnodebyname() flags also be defined for getaddrinfo(): AI_ADDRCONFIG AI_DEFAULT AI_ALL AI_V4MAPPED Specification of their use will be analogous to that of getipnodebyname(). There was support for adding these flags to the getaddrinfo() interface, but I am leaving the proposal in the "Other Issues" section as we didn't have a chance to completely discuss the proposal at the API meeting. NOTE: There was strong consensus on adding AI_ADDRCONFIG to getaddrinfo() so this is listed in the "Recommendation" section above. I am also listing it here for completeness. 4. Jun-ichiro will send out more details (in separate email) to the ipng working group alias on a proposal to map between FQDN, numeric, and scope. Credits: Thanks for all those who participated in the discussion and to Tim Hartrick (Mentat) who came up the title of the meeting :). Thanks to Erik and Jim for their comments on the minutes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 30 21:09:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB156Kt05814 for ipng-dist; Tue, 30 Nov 1999 21:06:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB156Bc05807 for ; Tue, 30 Nov 1999 21:06:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA06547 for ; Tue, 30 Nov 1999 21:06:11 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA09622 for ; Tue, 30 Nov 1999 21:06:10 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id CC7F0104BB4; Tue, 30 Nov 1999 23:06:08 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext04.compaq.com (Postfix) with ESMTP id C7F4EFB101; Tue, 30 Nov 1999 23:06:08 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 666204FB07; Tue, 30 Nov 1999 23:06:02 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 0E7E04C90F; Tue, 30 Nov 1999 23:06:02 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id AAA0000001337; Wed, 1 Dec 1999 00:06:07 -0500 (EST) From: Jim Bound Message-Id: <199912010506.AAA0000001337@quarry.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of "Tue, 30 Nov 1999 09:02:28 PST." Date: Wed, 01 Dec 1999 00:06:06 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Per site-locals in DNS: I did not say there is consensus, if I did I mean't it appears to be moving in that direction IMO. The issue is still to-be-discussed. But if you read the mails you will find people saying they don't belong in DNS. Which is what I was reflecting. But site-locals now that we are trying to use them in an interoperable manner are showing pain that we have not worked out standard details for their use. We will do that now, whether you get your doc done or not as time is of the essence as I watch what folks want to do with them. But your doc would be very timely now and a big help. As far as the API issue you say: >I feel badly about not paying more attention to the API specs when >they were first being written. I had hoped that the few discussions >we had during IETF meetings (e.g., the discussions that clarified that >scope boundaries cut through nodes, not links), would have been >sufficient to make clear the consequences of scoped addresses on the >APIs, forwarding rules, routing data structures, user interfaces, etc., >but that was wishful thinking on my part. Clearly some people >understood these issues at the time, but others have had to spend a lot >of time and email discovering them, effort that could have been avoided >if I had delivered on my frequent promises to write up what I understood >about scoped addresses (something I *still* intend to do). We understood the issues with RFC2553 but we were faced with moving forward and there was much discussion about scope_id at that time. The WG agreed to put a field in sockaddr_in6 till we learned more about scope_ids. Any implementer has had to deal with site-local simply because of RFC 2373 in their implementation. It is not an issue of understanding them in that sense at all. It is a matter of how they should be applied to the API semantics so they can be used with a scope_id. It is serendipity that we have an API fallback with getaddrinfo which we all must move to now simply because of this issue. We have Keith Sklower to thank for that all the way back at the Stockholm meeting I think in 1996, who explained this advantage. We all understood but we did not all agree on its use with each other. So don't feel bad about it in that sense we will survive the API debaucle and fix it quickly. Those wheels have already started to turn. >From RFC2553: The sin6_scope_id field is a 32-bit integer that identifies a set of interfaces as appropriate for the scope of the address carried in the sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an interface index. For a site scope sin6_addr, sin6_scope_id would be a site identifier. The mapping of sin6_scope_id to an interface or set of interfaces is left to implementation and future specifications on the subject of site identifiers. Everyone you have been listening too except for a few on this discussion (who are new WG members) saw this in the spec and knew it was there. But we had to move on and it was good we did as the rest of the API parts were able to solidify. It was not because we were clueless, or needed your guidance that we made this engineering trade-off. It was time-to-market for this API. But I would take this issue as caution to you as chair that anything in IPv6 that changes now that affects the API or user applications will get more and more painful as we progress. In 2000 I think we will see more real products with IPv6 stacks and IPv6 APIs; and continuing to break them because it was not perceived important on the WG list of issues, is not a good strategy for the IPv6 work and we must look at the priority as far as work that affects those products. Just saying thats the risk you take is not a very good answer if the IETF expects continued development of IPv6 "products" and not just research or early adopter kit efforts. Likewise IPv6 deployment, which will require "products". >I also don't think the lack of a current agreement on how name >resolution will be done for site-locals represents any sort of major >"flaw" in IPv6. Well put 2373 up for DS and I will make my case to the IESG it is a flaw and we can find out? It is much more than name resolution. But we are not ready for 2373 for DS and I have agreed to move on here and will help fix the issues beyond name resolution, which will hopefully make site-locals work in practice between multiple independent implementations, which is also a test for DS. >The same is true for the notion of embedding a site ID inside a site- >local address I don't agree with this at all. Are you saying we can't work on this during the effort to resolve how to use site-local addresses? It could be a tool we need at the end-of-the-day. Are you saying or mandating we cannot discuss proposals to do this on the IPng list as a WG chair, as we work out site-local address issues or scope-id issues? I hope not!!!! Lastly to believe now that what we have done with IPv6 is just a tweak to the network layer keeping as much of the IP stack in tact may be partically true for implementation in stack kernel space (but that was a lot of work to make it perform well with IPv4), but is not true at all for user space. IPv6 system implementation in user space is far more complex than IPv4. So the theory back in the days of the IPng Directorate that the basis for IPv6 was incremental was not quite true, as it turns out as I see it, as a note. Site-Local addresses contribute to that complexity and against that axiom. /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 --------------------------------------------------------------------