From owner-ipng@sunroof.eng.sun.com Thu May 1 01:28:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA03684; Thu, 1 May 1997 01:20:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA03677; Thu, 1 May 1997 01:20:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA05320; Thu, 1 May 1997 01:21:38 -0700 Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA26134 for ; Thu, 1 May 1997 01:21:54 -0700 Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id KAA03675; Thu, 1 May 1997 10:21:34 +0200 Received: from smtprelay.nl.cis.philips.com(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma003580; Thu May 1 10:21:04 1997 Received: from hades.mpn.cp.philips.com (hades.mpn.cp.philips.com [130.139.64.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970402) with ESMTP id KAA25046; Thu, 1 May 1997 10:21:02 +0200 Received: from pc239.nwm.wan.philips.com (pc239.nwm.wan.philips.com [161.89.1.239]) by hades.mpn.cp.philips.com (8.6.10/8.6.10-1.2a-960910) with SMTP id KAA08315; Thu, 1 May 1997 10:19:34 +0200 Message-Id: <3.0.1.32.19970501101803.006a8bf8@hades.mpn.cp.philips.com> X-Sender: rhunter@hades.mpn.cp.philips.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 01 May 1997 10:18:03 +0200 To: ipng@sunroof.eng.sun.com From: Ray Hunter Subject: (IPng 3607) Re: Router Alert Option..... Cc: "Steven M. Bellovin" In-Reply-To: <3.0.32.19970501014539.0079fdb0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3651 >At 01:55 AM 5/1/97 +0000, Steve Bellovin wrote: >>At 09:44 AM 4/30/97 -0400, Christian Huitema wrote: >>>On Apr 29, 3:53pm, Mike O'Dell wrote: >>> Subject: (IPng 3592) re: Router Alert Option..... >>> >>> nobody has yet explained to me how this "Router Alert Option" >>> isn't a denial-of-service attack just waiting to happen. >> >>Not anymore than any other hop by hop option, in fact. Clearly, access to >>any slow resource such as a "slow path" has to be rate limited. But I >>would think we know how to do that. I think "_should_ know how to do it" is more accurate. > >"Not anymore than any other hop by hop option" scares me. Clearly, we >should know how to do that. Demonstrably, router vendors either don't >or choose not to. I agree. Let's face it, most router vendors I've seen put the console bottom of the priority list for the scheduler. Getting high numbers in Bradner tests is more important for marketing. :-) Ever tried to turn off debug options when you turned on the wrong one and are generating a debug packet for every packet? It takes forever to get single characters in there. >> >>Also, the option affects the next hop, and the buck probably stops there. >> That makes it a poor vehicle for attacks -- tracing one hop back is not >>rocket science... > >In a world with IP tunneling, this is far from clear. (It also pays to >wonder if your router's CPU scheduler is smart enough to give the console >or other management processes priority over these numerous annoying packets.) What if these smart packets _are_ the management processes? It's unlike you (Steve) to make throw away remarks, but I can't understand what you mean when you alude to the extra risk in the presence of tunnels. IMHO even if you have a tunnel, then the next hop is _always_ clear: they are statically configured by network managers. No network manager in their right mind would allow a dynamically configured tunnel (with all the implications on routing updates/loops) Intermediate routers should not be processing the contents of IP packets in the tunnel anyway, so where's the issue with tunnels? Mike: Turning around your question asking why it is a not a risk: What's the real _additional_ problem here with denial of service attacks that we don't have today? It's an _option_ the routers can _choose_ to process. What's the difference here between a command that generates a routing table output for a management station via a smart packet, and receiving multiple SNMP walk on the ip routing table, or an 'snmp reload command' packet, or for that matter _any_ snmp write command? All can deny service to other users of the router by simply injecting a _single_ packet(s) that needs no return route. They can hog resources, reboot the router, or reconfigure it to give root equivalent access. As long as the authentication is in place and configurable I see no problem: Paranoid people say trust no-one, naive people trust everyone. Other people trust some people. It's the router manager's choice. best regards, Ray Hunter on contract to Origin Building VA-130, Postbus 218, 5600MD Eindhoven, The Netherlands. email: Ray.Hunter@mpn.cp.philips.com email: Ray.Hunter@globis.net www: http://www.globis.net/~rhunter phone: +31 40 2787988 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 1 10:28:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04351; Thu, 1 May 1997 10:20:48 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04344; Thu, 1 May 1997 10:20:43 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA06994; Thu, 1 May 1997 10:22:05 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15905; Thu, 1 May 1997 10:21:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA03237; Wed, 30 Apr 1997 19:12:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA04102; Wed, 30 Apr 1997 19:14:07 -0700 Received: from precept.com (hydra.precept.com [204.162.119.8]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA10827 for ; Wed, 30 Apr 1997 19:14:25 -0700 Received: from oak.precept.com by precept.com (SMI-8.6/SMI-SVR4) id SAA07841; Wed, 30 Apr 1997 18:54:02 -0700 Date: Wed, 30 Apr 1997 18:52:59 -0700 () From: Stephen Casner To: ietf-ppp@merit.edu cc: issll@mercury.lcs.mit.edu, ipng@sunroof.eng.sun.com, rem-conf@es.net Subject: (IPng 3608) Request PPPEXT review of draft-engan-ip-compress-00.txt In-Reply-To: Message-ID: X-X-Sender: casner@little-bear.precept.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2000 During IETF in Memphis, I sent a message to the PPPEXT working group that included a draft updated the night before on extending PPP to include the IPv6 and RTP header compression schemes. After further discussions during IETF, that draft has been revised and was just posted: draft-engan-ip-compress-00.txt This draft poses two questions that we need the PPPEXT WG to answer: 1. The current IPCP spec (RFC 1332) does not provide a means to enable more than one header compression protocol at a time, e.g., for both TCP and RTP. This new draft proposes three options for extending the compression option to accommodate the additional compression schemes. We need to know which should be chosen. 2. PPP protocol identifiers need to be assigned for the uncompressed and compressed packet formats used in these compression schemes. Four of these should be 8-bit identifiers so as not to impose a significant overhead on the compressed headers; considering that these header compression schemes cover multiple protocols, we think this is a fair allocation. We need to get PPPEXT concurrence so IANA can make those assignments. Those of us working on these compression schemes hope to get these questions answered as soon as possible so that the draft can be published as an RFC and waiting implementations can be deployed. Therefore your prompt consideration of this draft would be most heartily appreciated. These compression schemes are the result of efforts in the IPNG, ISSLL and AVT working groups. -- Steve Casner for Mathias Engan and Carsten Bormann -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 4 07:59:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA07369; Sun, 4 May 1997 07:51:51 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA07362; Sun, 4 May 1997 07:51:41 -0700 From: bound@zk3.dec.com Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA15412; Sun, 4 May 1997 07:53:03 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA03659 for ; Sun, 4 May 1997 07:53:02 -0700 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA15511; Sun, 4 May 1997 10:45:24 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18146; Sun, 4 May 1997 10:45:19 -0400 Message-Id: <9705041445.AA18146@wasted.zk3.dec.com> To: Rob Austein Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 3609) Re: DNS RG + aAA extensions and ICMP "who are you?" message In-Reply-To: Your message of "Wed, 30 Apr 97 01:37:11 EDT." <9704300137.aa25328@rurha-pente.epilogue.com> Date: Sun, 04 May 97 10:45:19 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 10012 Rob, >I have serious reservations about the proposed RG+aAA RR synthesis >mechanism. I also have reservations about relying on the proposed >ICMP "who are you?" message as the sole method of doing inverse >mappings from addresses to DNS names. The two issues are somewhat >related, which is why I'm dragging them both into the same message. My response here does not include "who are you" response. I have reservations on both too. But the WG seems to want to pursue the discussion. ALso at one of our interim meetings we had strong consensus to proceed in the WG and then at Memphis. We had at least 6 DNS product implementors present and various experts on DNS. So it is not a lack of expertise but possibly an appeasement to the future with an honest attempt to do the right thing. >While I can certainly understand with the goal of constructing AAAA >RRs from multiple data sources to support renumbering, etcetera, I >don't think that this is the way to go about it. The proposal adds a >burden to the DNS, without a real compensating benefit that I can see. The benefit is a clear distinction btw routing topology and interface identification for the future. See IPng WG Memphis minutes and Palo ALto GSE interim meeting minutes. Also my draft is null and void. The WG will see a new draft using an approach that will scale better, work with DNSSEC and DYNUPDS to DNS. The translation will be done by the resolvers. The authors will be Karen Tracy, Olafur Gudmundsson, and myself. >There are three times/places that the RR synthesis could take place: > >1) When RRs are added to the zone, whether by writing a new zone file > or by dynamic update >2) When an authoritative name server receives a query >3) When an application calls gethostbymumble() [or its equivalent on > non-BSD systems]. Or by the resolver. If that is what you mean by gethostbymumble(). >I agree with Jim that (3) is probably not a good idea in this case. >The current proposal is for (2). I think the right place is (1). Karen and Olafur changed my mind. But I think your right for the creation of the records for routing topology. machine.comp.com KA rg.comp.com 800:5afc:1263 KA is a new record type. rg.comp.com RG 10 5f00:1234::/ RG 20 5a00:3214::/ RG is new type and supports a preference and routing prefix. The resolver gets the KA and RG back and creates: machine.comp.com AAAA 5f00:1234::800:5afc:1263 AAAA 5a00:3214::800:5afc:1263 This will scale and support DNSSEC well. It appears the path of least resistence is at the resolver which we will explain in the draft. ALso you can change the RG records and its transparent to machine.comp.com now. >In order for the current proposal to work, the aAA and the RG RRs must >be at the same node in the DNS tree (the one indexed by the hostname). >Thus, the two RRs must be in the same zone, and are under the same >administrative control even with secure dynamic update, so the AAAA >could equally well have been synthesized when the zone was updated. >The only benefit I see here is that the update tools become a little >simpler, at the expense of the name server itself. This seems like a >bad trade, particularly if the name server really is supposed to do >this synthesis every time it receives a query (optimizing "compile >time" at the expense of "run time", basicly). Thats why we changed the synthesis to the resolver. >Furthermore, this business of having the "master server" do the >synthesis is, um, broken. DNS queries don't just go to the master. >Contrary to folk myth, there's no requirement that there even BE a >single master server, except in the DNS dynamic update protocol, which >isn't a required part of the DNS architecture. So is it every >authoritative server that's doing the synthesis, or the ones that >happen to find RG and aAA RRs in their zone files, or is the propsal >imposing a new restriction on the DNS, or what? How about the DNSSEC >implications? Who signs these synthesized AAAA RRs? How can this be >reconciled this with the DNSSEC recommendation that highly secure >zones be signed offline and conveyed to the name servers via >sneakernet, so that the zone private key will never be on the network? The update by the master was a temporary word fix to avoid the caching updates for machine.comp.com in the first draft. That will be removed. By giving the RG record its own type and not having to do synthesis of RG, DNSSEC will be able to sign the RG records. >I'm pretty sure that last one is a show stopper. Thats why we made the changes. >In short, I think the RG+aAA proposal opens up a large barrel of worms >with little compensating benefit, since there are other ways of >accomplishing the high-level goal. Exactly. We will get a new draft out to the WG. >Last, a pedantic nit: DNS type names are case-insensitive and by >convention have always been named in upper case, so that's "AAA". When I wrote the first draft I was trying to incorporate the suggestions and words from the WG into the draft. A suggestion was made that we call the "token" aAA for clarity. That will not be the case in the next draft. It was not that I did not know the common-case syntax but traded it off to have it jump out at the WG in the draft. >Regarding the ICMP "who are you?" message: I'm aware of three >principle motivations for this mechanism: I will not comment on this part and leave it to Matt Crawford. But will comment on the history as I was part of that history too and the trade-off issues. >The DNSIND WG discussed this at some length several years ago (Danvers >IETF, if I recall correctly, in any case it should be in the minutes). >Our conclusion was that there is no one right answer to this problem. >For either the ICMP "who are you?" query or the DNS inverse tree, the >question is "who do you trust?". Who do you trust to be: available? >configured correctly? truthful? At some sites the hosts are better >informed/more likely to be available/more truthful than the DNS >reverse tree, but at other sites the opposite is true. Our guess was >that the there were enough cases of each kind of site that both >mechanisms are useful. Since, in theory, it's possible to populate >either mechanism from the other, the net result of having both should >be an overall improvement in the reliability of the reverse mapping >data. The WG's conclusion at that meeting was that the only real >answer would be to implement both mechanisms and let the market decide >which one, if either, should be deprecated. I was at this meeting too. It was also discussed at an interim DNSIND (before it was called that) at Stanford University and presented by Bill Simpson where Sue Thomson and I attended. I think this was Oct 94 and the same week as one of our IPng interim meetings at XEROX PARC. I got the impression folks did not want to give up the inverse tree. That is what I think killed it. Implementing both was too much work per the implementors. Also the BIND forces thought it was not a good idea and still think its a bad idea as of last week when I discussed this with them in person on the left coast. Scaling being the issue. >Given this conclusion, we weren't sure whether it was worth doing the >ICMP message at all, given the potential implementation headaches >involved in stuffing a relatively high-level function like name >translation into the implementation of a low-level protocol like ICMP, >but we decided to leave that up to the folks who'd proposed the ICMP >message to decide. One thing I thought missed by the DNSIND WG was that ICMPv6 has been moved to the Internet Layer so it was not as low-level in IPv6. One of the reasons I think "who are you" got trashed was because DNSIND insisted on doing this for both IPv4 and IPv6. I think in this go-around we are "suggesting" it only be used for IPv6 NOT IPv4. ICMPv6 messages in IPv6 can be absorbed by IPv6 applications much easier now using raw sockets and the mechanisms for "filtering" in the Stevens/Thomas IPv6 BSD Advanced API spec. Also the IPng WG almost has unamious consensus on doing "who are you". Thats a pretty strong statement in the IETF. >Since that meeting, DNSSEC has progressed, and there's been some >interest in using DNSSEC and the reverse mapping tree to validate >addresses. I don't know a lot about this one (ask Bill Manning), but >the point is that if we throw out the reverse tree, we lose this >capability, which may upset current plans outside the IPng WG. There >have also been proposals to use the DNS reverse mapping tree for >things like policy routing information; the first of these (for IDPR) >went under due to a circular dependency problem, but later ones with >more limited goals were quite feasible, if perhaps controversial. So >that's another community that probably would not let the reverse >mapping tree go away without a fight. Well IPv6 int.domain is a new beast and this is not for IPv4. So I wonder how much of an issue it is for deployment for IPv6 if we leave IPv4 alone? Also the "who are you" does not eliminate the reverse tree necessarily. >So, in summary, my recommendations: > >- Scrap aAA and RG, instead build better tools for synthesising AAAA > RRs when inserting new data into the DNS. Agreed. See next draft. >- ICMP "who are you?" should go forward if enough people think it's > worth doing, but keep the IP6.INT tree too. I personally agree with you. But would like more examples in the "who are you" draft. thanks for coming on the list for this stuff Rob, /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 May 5 12:01:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08142; Mon, 5 May 1997 11:52:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08135; Mon, 5 May 1997 11:52:28 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA01912; Mon, 5 May 1997 11:53:49 -0700 Received: from gta.ufrj.br ([146.164.53.71]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA01363 for ; Mon, 5 May 1997 11:54:03 -0700 Received: (from emerson@localhost) by gta.ufrj.br (8.7.4/8.7.3) id PAA27350 for ipng@sunroof.eng.sun.com; Mon, 5 May 1997 15:53:36 -0300 (EST) From: Emerson Carli Message-Id: <199705051853.PAA27350@gta.ufrj.br> Subject: (IPng 3610) Informations To: ipng@sunroof.eng.sun.com Date: Mon, 5 May 1997 15:53:36 -0300 (EST) X-Mailer: ELM [version 2.4ME+ PL14 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 843 Hi, I'd like to receive informations about finite state machine of the IPng protocol. Does anyone know how I can obtain them? I need them to continue my M.Sc. thesis. Thanks in advance, -- -- Emerson Carli Phone: Universidade Federal do Rio de Janeiro +55 21 260-5010 R.239 (COPPE) COPPE/UFRJ +55 21 589-3470 (Home) e-mail: emerson@gta.ufrj.br http://www.gta.ufrj.br/~emerson Research interests: IPng over ATM and Formal Specification -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 8 14:36:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA12084; Thu, 8 May 1997 14:28:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA12077; Thu, 8 May 1997 14:28:00 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA00727; Thu, 8 May 1997 14:29:23 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA17456 for ; Thu, 8 May 1997 14:29:41 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.5/8.7.3) with ESMTP id XAA21686; Thu, 8 May 1997 23:29:05 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id XAA23277; Thu, 8 May 1997 23:29:04 +0200 (MET DST) Message-Id: <199705082129.XAA23277@givry.inria.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: (IPng 3611) Re: W.G. Last Call on "Advanced Sockets API for IPv6" In-reply-to: Your message of Fri, 25 Apr 1997 16:39:17 PDT. <3.0.1.32.19970425163917.00bfe8c8@mailhost.ipsilon.com> Date: Thu, 08 May 1997 23:28:41 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1603 I have some comments about the advanced sockets API for IPv6: - some section 2 defines can (will) collide with other implementation defines then I propose to add a standard flag for the inclusion of the defines. - the packet information stuff is rather good but has some flawns (most of them are inherited from the BSD API): * interaction between sticky and packet options is unclear for UDP (setsockopt IPV6_PKTOPTIONS or sendmsg IPV6_PKTINFO) * interaction between ancillary data and multicast setsockopt is unclear and the default values are not the same (both should be merged ?) * in6_pktinfo structure must include a full sockaddr_in6 structure (with port and flowinfo) in place of only the address (in6_addr) because it can be used for send-one-packet rebinding - the packet information triggers the scope problem (source address with a too narrow or on an other interface scope for the destination) Unfortunately this issue is not yet solved... - there is nothing for AH or ESP headers. - the API is not yet widely implemented then perhaps it is too soon for a RFC (but it should become an informational document then it is not a strong argument). 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 Fri May 9 07:50:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12666; Fri, 9 May 1997 07:42:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA12659; Fri, 9 May 1997 07:42:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06234; Fri, 9 May 1997 07:43:24 -0700 Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [129.35.208.96]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA17027 for ; Fri, 9 May 1997 07:43:46 -0700 Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [9.53.150.115]) by netmail1.austin.ibm.com (8.6.12/8.6.11) with ESMTP id JAA45754; Fri, 9 May 1997 09:43:23 -0500 Received: from mojave.austin.ibm.com (loopback [127.0.0.1]) by mojave.austin.ibm.com (AIX4.2/UCB 8.7/8.7-client1.01) with ESMTP id JAA48156; Fri, 9 May 1997 09:43:18 -0500 (CDT) Message-Id: <199705091443.JAA48156@mojave.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 3612) Re: W.G. Last Call on "Advanced Sockets API for IPv6" In-reply-to: (Your message of Thu, 08 May 1997 23:28:41 +0200.) <199705082129.XAA23277@givry.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 09 May 1997 09:43:18 -0500 From: Steve Wise Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 770 Francis Dupont says: | - the API is not yet widely implemented then perhaps it is too soon | for a RFC (but it should become an informational document then | it is not a strong argument). Can we get a show of e-hands on who has implemented this? We probably shouldn't make this an RFC (even if informational only) unless there are implementations to prove the API. Stevo. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 9 11:13:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12952; Fri, 9 May 1997 11:04:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12945; Fri, 9 May 1997 11:04:35 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA27034; Fri, 9 May 1997 11:05:59 -0700 Received: from hammer.thor.cam.ac.uk (hammer.thor.cam.ac.uk [131.111.8.39]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA19171 for ; Fri, 9 May 1997 11:06:21 -0700 Received: from pjb27 by hammer.thor.cam.ac.uk with smtp (Exim 1.622 #1) id 0wPu39-0004yu-00; Fri, 9 May 1997 19:05:47 +0100 Date: Fri, 9 May 1997 19:05:47 +0100 (BST) From: Philip Blundell X-Sender: pjb27@hammer.thor.cam.ac.uk To: Steve Wise cc: ipng@sunroof.eng.sun.com Subject: (IPng 3613) Re: W.G. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <199705091443.JAA48156@mojave.austin.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 920 On Fri, 9 May 1997, Steve Wise wrote: > Francis Dupont says: > > | - the API is not yet widely implemented then perhaps it is too soon > | for a RFC (but it should become an informational document then > | it is not a strong argument). > > Can we get a show of e-hands on who has implemented this? We probably > shouldn't make this an RFC (even if informational only) unless there are > implementations to prove the API. I'm in the process of implementing it for the GNU libc and Linux, but the work isn't finished yet. p. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 9 13:42:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13815; Fri, 9 May 1997 13:34:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13808; Fri, 9 May 1997 13:34:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA00320; Fri, 9 May 1997 13:35:26 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA01590 for ; Fri, 9 May 1997 13:35:47 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id NAA05117; Fri, 9 May 1997 13:34:34 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.2) with ESMTP id NAA04260; Fri, 9 May 1997 13:29:38 -0700 (PDT) Received: from bridge2.NSD.3Com.COM (bridge2.NSD.3Com.COM [129.213.96.3]) by chicago.nsd.3com.com (8.8.2/8.8.2) with ESMTP id NAA09093; Fri, 9 May 1997 13:33:06 -0700 (PDT) Received: from lookout.NSD.3Com.COM (lookout.NSD.3Com.COM [129.213.48.28]) by bridge2.NSD.3Com.COM (8.8.2/8.8.2) with SMTP id NAA01666; Fri, 9 May 1997 13:34:25 -0700 (PDT) Received: by lookout.NSD.3Com.COM id AA20498 (5.65c/IDA-1.4.4-910730); Fri, 9 May 1997 13:29:26 -0700 From: Quaizar Vohra Message-Id: <199705092029.AA20498@lookout.NSD.3Com.COM> Subject: (IPng 3614) Re: W.G. Last Call on "Advanced Sockets API for IPv6" To: swise@austin.ibm.com (Steve Wise) Date: Fri, 9 May 1997 13:29:26 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com (ipng) In-Reply-To: <199705091443.JAA48156@mojave.austin.ibm.com> from "Steve Wise" at May 9, 97 09:43:18 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1389 UNH/NetBSD implementation covers most part of the Advanced API. We have a couple of test applications too. Quaizar > > >Francis Dupont says: > > >| - the API is not yet widely implemented then perhaps it is too soon >| for a RFC (but it should become an informational document then >| it is not a strong argument). > >Can we get a show of e-hands on who has implemented this? We probably >shouldn't make this an RFC (even if informational only) unless there are >implementations to prove the API. > > >Stevo. > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > -- ------------------------------------------------------ Quaizar Vohra E-mail : qv@3com.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 10 03:39:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA14321; Sat, 10 May 1997 03:32:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA14314; Sat, 10 May 1997 03:31:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA21779; Sat, 10 May 1997 03:33:22 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA24962 for ; Sat, 10 May 1997 03:33:46 -0700 Received: (roque@localhost) by trix.cisco.com (8.6.12/8.6.5) id DAA28814; Sat, 10 May 1997 03:32:46 -0700 Date: Sat, 10 May 1997 03:32:46 -0700 Message-Id: <199705101032.DAA28814@trix.cisco.com> From: Pedro Marques To: Francis Dupont Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: (IPng 3616) Re: W.G. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <199705082129.XAA23277@givry.inria.fr> References: <3.0.1.32.19970425163917.00bfe8c8@mailhost.ipsilon.com> <199705082129.XAA23277@givry.inria.fr> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2585 >>>>> "Francis" == Francis Dupont writes: Francis> * interaction between sticky and packet options is unclear Francis> for UDP (setsockopt IPV6_PKTOPTIONS or sendmsg Francis> IPV6_PKTINFO) The "natural" thing to do is to have the per packet option override the sticky options. Francis> * interaction between ancillary data and Francis> multicast setsockopt is unclear and the default values Francis> are not the same (both should be merged ?) Actually it would be nice to deprecate the multicast setsockopts, specially the MULTICAST_IF option. Francis> * in6_pktinfo Francis> structure must include a full sockaddr_in6 structure Francis> (with port and flowinfo) in place of only the address Francis> (in6_addr) Francis> because it can be used for send-one-packet Francis> rebinding pktinfo is used in sendmsg / recvmsg which already include a sockaddr_in6 (with port and flowinfo). The whole idea of pktinfo is, as far as i see it, to identify an interface (and to select the adddress of the interface). port and flowinfo don't fit into interface related information. Francis> - the packet information triggers the scope Francis> problem (source address with a too narrow or on an other Francis> interface scope for the destination) Unfortunately this Francis> issue is not yet solved... The system must do sanity checking... Francis> - there is nothing for AH or ESP headers. Francis> - the API is not yet widely implemented Francis> then perhaps it is too soon for a RFC (but it should Francis> become an informational document then it is not a strong Francis> argument). The pktinfo structure should be "widely" implemented by now... actually people are starting to use it for the ipv4 API also. Some application kits in use by some of the unix implementations do use pktinfo extensively. The draft is in general pretty good IMHO and i would like to see it advance into informational before we get trapped into "how should we name this" kind of discussions. As far as i remember this won't be standards track because of the "we don't do APIs" policy. regards, ./Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 10 13:22:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14549; Sat, 10 May 1997 13:14:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14542; Sat, 10 May 1997 13:14:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA25601; Sat, 10 May 1997 13:16:00 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA07284 for ; Sat, 10 May 1997 13:16:26 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04427; Sat, 10 May 97 13:13:28 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA14649; Sat, 10 May 1997 13:16:33 -0700 Date: Sat, 10 May 1997 13:16:33 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705102016.NAA14649@feller.mentat.com> To: roque@cisco.com Subject: (IPng 3617) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3684 Pedro, > > The "natural" thing to do is to have the per packet option override the > sticky options. > Agreed. Ancillary data should override any values set via setsockopt. > Francis> * interaction between ancillary data and > Francis> multicast setsockopt is unclear and the default values > Francis> are not the same (both should be merged ?) > > Actually it would be nice to deprecate the multicast setsockopts, > specially the MULTICAST_IF option. > I disagree. We should not force multicast applications to always pay the performance penalty of using ancillary data. Many existing multicast applications set the IP_MULTICAST_IF once and never change it. I believe that ancillary data should override IP_MULTICAST_IF setting. > Francis> * in6_pktinfo > Francis> structure must include a full sockaddr_in6 structure > Francis> (with port and flowinfo) in place of only the address > Francis> (in6_addr) > Francis> because it can be used for send-one-packet > Francis> rebinding > > pktinfo is used in sendmsg / recvmsg which already include a sockaddr_in6 > (with port and flowinfo). The whole idea of pktinfo is, as far as i see it, > to identify an interface (and to select the adddress of the interface). > port and flowinfo don't fit into interface related information. > Agreed. > Francis> - the packet information triggers the scope > Francis> problem (source address with a too narrow or on an other > Francis> interface scope for the destination) Unfortunately this > Francis> issue is not yet solved... > > The system must do sanity checking... > I think I agree. In general I have always thought the interface selection ancillary data item should only apply to link-local unicast destinations or multicast destinations. For site-local or global unicast addresses the interface selection option should be a no-op. The routing tables should take precedence. Maybe Richard can provide some input on the intent of the interface selection ancillary data item. Are you out there Richard? > Francis> - there is nothing for AH or ESP headers. > > Francis> - the API is not yet widely implemented > Francis> then perhaps it is too soon for a RFC (but it should > Francis> become an informational document then it is not a strong > Francis> argument). > > The pktinfo structure should be "widely" implemented by now... actually > people are starting to use it for the ipv4 API also. Some application > kits in use by some of the unix implementations do use pktinfo > extensively. > > The draft is in general pretty good IMHO and i would like to see it > advance into informational before we get trapped into "how should we > name this" kind of discussions. > > As far as i remember this won't be standards track because of the "we > don't do APIs" policy. > Ultimately POSIX and/or X/Open are going to have the final say about Unix IPv6 APIs. This document should, and I believe does, provide a good starting point for that work. It does not have to be perfect to be an informational RFC. The current draft is definately better than the X/Open documents I have sitting under my desk. Unless there are major showstoppers I agree with Pedro that this document should move forward. 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 Sat May 10 14:34:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14626; Sat, 10 May 1997 14:26:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14619; Sat, 10 May 1997 14:26:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA28382; Sat, 10 May 1997 14:28:08 -0700 Received: from pita.cisco.com (pita.cisco.com [161.44.132.3]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA12431 for ; Sat, 10 May 1997 14:28:31 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by pita.cisco.com (8.6.12/8.6.5) with ESMTP id OAA27578; Sat, 10 May 1997 14:28:08 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA05283; Sat, 10 May 1997 14:24:50 -0700 (PDT) Date: Sat, 10 May 1997 14:24:50 -0700 (PDT) Message-Id: <199705102124.OAA05283@pedrom-ultra.cisco.com> From: Pedro Marques To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3618) Re: W.G. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <199705102016.NAA14649@feller.mentat.com> References: <199705102016.NAA14649@feller.mentat.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2876 >>>>> "Tim" == Tim Hartrick writes: Hi Tim, Francis> * interaction between ancillary data and multicast Francis> setsockopt is unclear and the default values are not the Francis> same (both should be merged ?) >> Actually it would be nice to deprecate the multicast >> setsockopts, specially the MULTICAST_IF option. >> Tim> I disagree. We should not force multicast applications to Tim> always pay the performance penalty of using ancillary data. Tim, few applications do care about the outgoing interface... in my experience only "system management/support" style applications do and those tipically perform something like this: while (TRUE) { for (all_interfaces) { setsockopt(sk, MULTICAST_IF, this_if); sendmsg(sk, data); } } For this a setsockopt is very ill suited as you get to do 1 unnecessary system call for each sendmsg. I always do prefer to have just one way to do things... it usually reduces the likehood of bugs by both the user and provider of the API. Tim> Many existing multicast applications set the IP_MULTICAST_IF Tim> once and never change it. I think all those applications would be better just accepting the system definition for default multicast interface... they don't usually know or care about the interface configuration on the system. Francis> - the packet information triggers the scope problem Francis> (source address with a too narrow or on an other Francis> interface scope for the destination) Unfortunately this Francis> issue is not yet solved... >> The system must do sanity checking... >> Tim> I think I agree. In general I have always thought the Tim> interface selection ancillary data item should only apply to Tim> link-local unicast destinations or multicast destinations. Tim> For site-local or global unicast addresses the interface Tim> selection option should be a no-op. The routing tables Tim> should take precedence. Hum... i think i disagree, if a system as more than one global address on an interface for instance and it is a plain vanila host with only routes to the prefixes it has configured and a list of default routers i do believe it makes sense for the application to be able to pick the souce address via pktinfo. Tim> Ultimately POSIX and/or X/Open are going to have the final Tim> say about Unix IPv6 APIs. That is what some of us are afraid of ;-) regards, ./Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 10 15:21:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14712; Sat, 10 May 1997 15:13:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14705; Sat, 10 May 1997 15:13:18 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA00341; Sat, 10 May 1997 15:14:42 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA15485 for ; Sat, 10 May 1997 15:15:05 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA04837; Sat, 10 May 97 15:12:09 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA14777; Sat, 10 May 1997 15:15:12 -0700 Date: Sat, 10 May 1997 15:15:12 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705102215.PAA14777@feller.mentat.com> To: roque@cisco.com Subject: (IPng 3619) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 820 Pedro, > > Hum... i think i disagree, if a system as more than one global address > on an interface for instance and it is a plain vanila host with only > routes to the prefixes it has configured and a list of default routers > i do believe it makes sense for the application to be able to pick > the souce address via pktinfo. > You are correct. I was not correctly remembering the contents and usage of the pktinfo structure. 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 Sat May 10 15:35:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14744; Sat, 10 May 1997 15:27:42 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14737; Sat, 10 May 1997 15:27:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA00942; Sat, 10 May 1997 15:28:52 -0700 Received: from kalae.kohala.com ([206.62.226.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA16470 for ; Sat, 10 May 1997 15:29:12 -0700 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id PAA09552; Sat, 10 May 1997 15:28:48 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id PAA09473; Sat, 10 May 1997 15:28:48 -0700 (MST) Message-Id: <199705102228.PAA09473@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Sat, 10 May 1997 15:28:48 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: thartric@mentat.com (Tim Hartrick), roque@cisco.com Subject: (IPng 3620) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1944 [In your message of May 10, 1:16pm you write:] > > > Francis> - the packet information triggers the scope > > Francis> problem (source address with a too narrow or on an other > > Francis> interface scope for the destination) Unfortunately this > > Francis> issue is not yet solved... > > > > The system must do sanity checking... > > I think I agree. In general I have always thought the interface selection > ancillary data item should only apply to link-local unicast destinations > or multicast destinations. For site-local or global unicast addresses > the interface selection option should be a no-op. The routing tables should > take precedence. > > Maybe Richard can provide some input on the intent of the interface selection > ancillary data item. Are you out there Richard? As one data point, I note that the Digital IPv6 implementation has the following feature: - The kernel routing table search key has been expanded to include the interface and gateway. This is in addition to the destination and netmask. This allows multiple routing table entries for a given destination/netmask provided that either the gateway and/or interface differ. so there might be a use for the interface selection. I wouldn't think many applications would use this, however. Perhaps Matt has some more input? > > Francis> - there is nothing for AH or ESP headers. The Introduction section (p. 6) explicitly states that this is not covered. Others are working on this (I think). Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 10 17:26:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14899; Sat, 10 May 1997 17:19:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA14892; Sat, 10 May 1997 17:18:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA05888; Sat, 10 May 1997 17:20:17 -0700 Received: from wachusett.altavista-software.com (wachusett.altavista-software.com [205.181.164.11]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA23847 for ; Sat, 10 May 1997 17:20:43 -0700 Received: by wachusett.altavista-software.com; (5.65v3.2/1.3/10May95) id AA00189; Sat, 10 May 1997 20:20:12 -0400 Message-Id: <3.0.1.32.19970510175540.006bf964@nntpd.lkg.dec.com> X-Sender: altamatt@nntpd.lkg.dec.com (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 10 May 1997 17:55:40 -0400 To: Francis Dupont Received: from 1Cust42.Max3.Boston.MA.MS.UU.NET by wachusett.altavista-software.com (smtpxd); id XA18244 From: Matt Thomas Subject: (IPng 3621) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199705082129.XAA23277@givry.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2186 At 11:28 PM 5/8/97 +0200, Francis Dupont wrote: >I have some comments about the advanced sockets API for IPv6: > - some section 2 defines can (will) collide with other implementation > defines then I propose to add a standard flag for the inclusion > of the defines. > - the packet information stuff is rather good but has some flawns > (most of them are inherited from the BSD API): > * interaction between sticky and packet options is unclear for UDP > (setsockopt IPV6_PKTOPTIONS or sendmsg IPV6_PKTINFO) PKTINFO overrides (as a one shot) PKOPTIONS. > * interaction between ancillary data and multicast setsockopt is unclear > and the default values are not the same (both should be merged ?) ancillary data will override multicast options. > * in6_pktinfo structure must include a full sockaddr_in6 structure > (with port and flowinfo) in place of only the address (in6_addr) > because it can be used for send-one-packet rebinding No! Port and flowinfo will be in the sockaddr_in6 passed to sendto/sendmsg /recvfrom/recvmsg. > - the packet information triggers the scope problem (source address > with a too narrow or on an other interface scope for the destination) > Unfortunately this issue is not yet solved... So do other things (such as source routes). I don't see this as a problem in the draft (it exists independently). > - there is nothing for AH or ESP headers. Since this is being specifically left out so that it can be dealt with by the IPSEC working group (by their request). -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 10:25:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16012; Mon, 12 May 1997 10:16:25 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA16005; Mon, 12 May 1997 10:16:20 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA26583; Mon, 12 May 1997 10:17:54 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05505; Mon, 12 May 1997 10:16:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA14209; Fri, 9 May 1997 22:02:44 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA08000; Fri, 9 May 1997 22:04:07 -0700 Received: from ceres.backyard.wide.toshiba.co.jp (ceres.wide.toshiba.co.jp [202.249.10.113]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA03038 for ; Fri, 9 May 1997 22:04:31 -0700 Received: (from mailer@localhost) by ceres.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) id OAA06985; Sat, 10 May 1997 14:12:57 +0900 (JST) Received: from samber.backyard.wide.toshiba.co.jp(133.196.2.11) by ceres.backyard.wide.toshiba.co.jp via smap (V1.3) id sma006983; Sat May 10 14:12:40 1997 Received: from brian.backyard.wide.toshiba.co.jp (root@brian.backyard.wide.toshiba.co.jp [133.196.2.32]) by samber.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) with ESMTP id OAA04575; Sat, 10 May 1997 14:03:50 +0900 (JST) Message-Id: <199705100503.OAA04575@samber.backyard.wide.toshiba.co.jp> To: swise@austin.ibm.com Cc: hinden@ipsilon.com, ipng@sunroof.eng.sun.com Subject: (IPng 3622) Re: W.G. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: Your message of "Fri, 09 May 1997 09:43:18 -0500" References: <199705091443.JAA48156@mojave.austin.ibm.com> X-Mailer: Mew version 1.55 on Emacs 19.34.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 10 May 1997 14:01:57 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1026 >>>>> On Fri, 09 May 1997 09:43:18 -0500, >>>>> Steve Wise said: > Can we get a show of e-hands on who has implemented this? We probably > shouldn't make this an RFC (even if informational only) unless there are > implementations to prove the API. Our IPv6 implementaion (which is based on BSD/OS 2.1) supports a part of the advanced API. Some applications such as ping and routed already use it. We have not yet supported all the functions of the API, but we'll fully support it soon. JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.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 May 12 14:12:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA16269; Mon, 12 May 1997 14:03:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA16262; Mon, 12 May 1997 14:03:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA18671; Mon, 12 May 1997 14:04:18 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA01582 for ; Mon, 12 May 1997 14:04:44 -0700 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA32413; Mon, 12 May 1997 16:51:50 -0400 (EDT) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17994; Mon, 12 May 1997 16:51:39 -0400 Date: Mon, 12 May 1997 16:51:39 -0400 From: Jack McCann Message-Id: <9705122051.AA17994@wasted.zk3.dec.com> To: rstevens@kohala.com Subject: (IPng 3623) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2907 Someone in this thread wrote: >> >> > Francis> - the packet information triggers the scope >> > Francis> problem (source address with a too narrow or on an other >> > Francis> interface scope for the destination) Unfortunately this >> > Francis> issue is not yet solved... >> > >> > The system must do sanity checking... >> >> I think I agree. In general I have always thought the interface selection >> ancillary data item should only apply to link-local unicast destinations >> or multicast destinations. For site-local or global unicast addresses >> the interface selection option should be a no-op. The routing tables should >> take precedence. I disagree with the idea of limiting interface selection to a particular subset of IPv6 addresses, this is an artificial constraint on an otherwise generic API. One usage that comes to mind is network troubleshooting (I can ping over interface A but not over interface B). Such a constraint should be left to the implementation, not dictated by the spec. Nor should the routing tables take precedence. If I wanted to use the routing tables, I would not have bothered to specify the interface. On the topic of site-local addresses, I offer the following thoughts. Site-local addresses have the same problem as link-local when a host has interfaces in multiple sites, e.g. interface A belongs to site X and interface B belongs to site Y. In this case we may need to specify which site a site-local address belongs to, similar to the way we would specify which link (interface) a link-local address belongs to. We probably need some API extensions to deal with the notion of a "site". - define the notion of a site identifier; we can use small positive integers similar to interface identifiers - provide a set of routines for mapping site names to site identifiers, similar to the if_nametoindex, if_indextoname, etc. routines in rfc2133 - extend the in6_pktinfo structure to include a field for "site", e.g. struct in6_pktinfo { struct in6_addr ipi6_addr; /* src/dst IPv6 address */ int ipi6_ifindex; /* send/recv interface index */ int ipi6_site; /* send/recv site identifier */ }; (we can't simply map a site identifier to an interface index because there may be multiple interfaces belonging to a given site, and we'd like to use the routing tables to decide which interface within the given site) Some thoughts for a Monday... - 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 May 12 15:53:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16443; Mon, 12 May 1997 15:45:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16436; Mon, 12 May 1997 15:45:33 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA13225; Mon, 12 May 1997 15:46:53 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA02018 for ; Mon, 12 May 1997 15:47:25 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id PAA03110 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id PAA00204 Posted-Date: Mon, 12 May 1997 15:46:51 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com ([192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id SAA15715; Mon, 12 May 1997 18:46:51 -0400 for Message-Id: <3.0.32.19970512184555.0069c074@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 12 May 1997 18:45:57 -0400 To: Margaret Forsythe From: Dimitry Haskin Subject: (IPng 3624) Re: ICMPv6 mib q.. Cc: solensky@ftp.com, dhaskin@BayNetworks.COM, sonishi@BayNetworks.COM, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7040 Margaret, I copied this to the ipng list as you suggested. At 05:13 AM 5/10/97 -0400, Margaret Forsythe wrote: > >Hi Dimitry, Frank & Steve, > >I am finally back-on-track and ready to discuss the IPv6 MIB(s). > >I would be happy to copy any/all of this discussion to the IPv6 >mailing list (or you can do so), if you think there should be WG >discussion on any of these issues. > >I have organized my discussion per MIB document. The only general >comment I have it that you may wish to break-up these documents even >further, to better reflect the division of MIB-II in SNMPv2. > For the time being, unless there is a strong objection, I'd like to keep it down to three documents according to the major functional areas of IPv6 covered by these mibs. >ICMPv6 Group: > >To start with the easy one, I think this MIB is fine. I understand >your justification for separate aggregate and per-interface statistics, >and think this MIB is ready to move to an experimental RFC. > Ok. >Textual Conventions & General Group: > >As presented in Memphis, I think you should add an additional textual >convention to this MIB. --Actually, I think an SMI Application Type >would be preferrable, but that is probably politically unfeasible.-- > >The textual convention would allow a MIB to represent an IP address >when that address could either be IPv4 or IPv6. I would suggest >something along the following lines: > >UnifiedIPAddress ::= TEXTUAL CONVENTION >DISPLAY HINT "x" >STATUS current >DESCRIPTION > "IP Address (v4 or v6). The version number can be > determined from the length (4 = IPv4, 16 = IPv6)." >SYNTAX OCTET STRING (size (4 | 16)) > >Although, I am fairly flexible about the actual representation. > Ok with me if we find a good use for it. I understand you want to use it for the "unified" UDP and TCP mibs but I'm not quite sure that this will be sufficient. Btw, DISPLAY HINT is different for IPv6 and IPv4 - "2x: and "d." respectively. >I also have a few other comments about this MIB which I feel should >be resolved (or dismissed) before the MIB is advanced to an experimental >RFC. > >First, I believe that the Ipv6NetToMediaTable should be modified to >better reflect what a Neighbor Discovery Cache will actually look >like. For example, including the expiration time, status, etc. of >each entry. If this is unclear, would be happy to write up an >example of what I think it could/should look like (although I have >not completed my ND implementation, so it would require comment from >people who have). > An example would help. The Ipv6NetToMediaTable is not ND specific. The purpose of this simple table to provide the current v6 address to L2 address mapping which can be derived by a number of means (should we get NHRP related information into this table too?). Of cause, a mapping can become invalid for many reasons. As far as the expiration time, I believe that you're asking for the information that is more appropriate in the ipv6AddrPrefixTable which already defines attributes for the preferred and valid lifetimes. On a side note, I think it would be nice to have a separate ND mib and I hope that someone would volunteer to write it up. Naturally, your example may change my mind. >The Ipv6RouteTable also requires some changes. Specifically, I think >it should be modified to be more like the IpForwardTable (RFC1354, which >supersedes the MIB-II IpRouteTable). I would suggest the following >specific changes: > >- Add 4 more metrics. What routing protocol uses more than one metric for a route in context of a particular policy? I know that the ipForwardTable has 4 alternate metric attributes but I've never seen them used except for the vendor internally calculated route metric (weight) (in addition to the primary metric advertised by a routing protocol). This is why I added ipv6RouteWeight attribute. Said that, I'll be happy to add more metrics (why 4? :) if people feel that they are needed. >- Add an AS Number. It is what the ipv6RouteNextHopRDI (the Routing Domain ID of the Next Hop) is for. >- Remove the artificial ipv6RouteIndex object. With this index it is possible to have multiple routes to a particular destination without requiring too many indexes. Otherwise you would need at minimum the following indexes: Prefix, Prefix length, Protocol, Policy, IfIndex, and Next Hop Address. And there is no guaranty that an additional index will not be required at some point to uniquely qualify a route (e.g. was considering the address if the router that advertised the routes since it may not be the same as the NextHop). I thought a generic route index made it much simpler. >- Do not use IfIndex as an index in this table. Well.. if we keep ipv6RouteIndex as an index, IfIndex can be removed. But I thought it simplified retrieval of all routes through a given interface - a quite common operation. If ipv6RouteIndex is abolished as you suggested, it will be necessary to use IfIndex along with the Next Hop Address as an index since the Next Hop Address is usually a link-local address. >- Add the routing protocol and policy as indices. You'll would need IfIndex and NextHop too. > >I think you should keep the Prefix Length as an index. The ipForwardTable >should have included the mask as an index, and it makes sense not to repeat >the same mistake in this MIB. > I didn't. And tried to avoid other mistakes too. >UDP & TCP Groups: > >These tables should be modified to use the UnifiedIPAddress, as >described above. The MIB should also indicate that these tables are >intended to deprecate the MIB-II UDP and TCP tables (which are for >IPv4 only). > >ifIndex should not be used as an index in the UDP and TCP tables, >as it could certainly change throughout the lifetime of a connection. >In fact, I would argue that it should not be included as an object >at all, since the UDP and TCP layers should not know (or care) what >interface is being used to send their packets. > And what would you do with tcp/udp to link-local addresses? IfIndex is necessary to qualify link-local and, possibly, site-local addresses. Are you proposing that link-local addresses are not used in the UDP and TCP context? >If any of this is unclear, I'd be happy to elaborate. Also, if there >is significant disagreement on any of these points, I would be happy >to move the discussion to a wider list. > >Margaret > >Margaret Forsythe mrf@epilogue.com >Director of IP Development (617) 245-0804 >Epilogue Technology Corp. FAX: (617) 245-8122 >333 North Ave, 4th Floor http://www.epilogue.com >Wakefield, MA 01880, USA Sales: info@epilogue.com > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 17:51:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA16694; Mon, 12 May 1997 17:43:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA16687; Mon, 12 May 1997 17:42:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA06872; Mon, 12 May 1997 17:44:15 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA02157 for ; Mon, 12 May 1997 17:44:37 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA17125; Mon, 12 May 97 17:41:30 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA17596; Mon, 12 May 1997 17:44:42 -0700 Date: Mon, 12 May 1997 17:44:42 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705130044.RAA17596@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3625) Re: ICMPv6 mib q.. X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2929 Folks, > > >ICMPv6 Group: > > > >To start with the easy one, I think this MIB is fine. I understand > >your justification for separate aggregate and per-interface statistics, > >and think this MIB is ready to move to an experimental RFC. > > Maybe I missed something but in the 01 draft I do not see the aggregate ICMPv6 statistics only the per-interface statistics. What did I miss? I had one question about this MIB. Since ICMPv6 now includes IGMP messages should an IGMP membership table be part of the ICMPv6 MIB? It would be unfortunate if we had to invent yet another MIB to handle this case at some later time. > > > >First, I believe that the Ipv6NetToMediaTable should be modified to > >better reflect what a Neighbor Discovery Cache will actually look > >like. For example, including the expiration time, status, etc. of > >each entry. If this is unclear, would be happy to write up an > >example of what I think it could/should look like (although I have > >not completed my ND implementation, so it would require comment from > >people who have). > > > > An example would help. The Ipv6NetToMediaTable is not ND specific. The > purpose of this simple table to provide the current v6 address to L2 > address mapping which can be derived by a number of means (should we get > NHRP related information into this table too?). Of cause, a mapping can > become invalid for many reasons. As far as the expiration time, I believe > that you're asking for the information that is more appropriate in the > ipv6AddrPrefixTable which already defines attributes for the preferred and > valid lifetimes. On a side note, I think it would be nice to have a > separate ND mib and I hope that someone would volunteer to write it up. > > Naturally, your example may change my mind. > > I believe it would be useful to have the reachability state (STALE, PROBE, DELAY, REACHABLE) as part of the Ipv6NetToMediaEntry. Even if NHRP or some other L2 protocol is being used for resolution, reachability will be deter- mined by NUD. It would also be useful to have the reachability time available as part of the entry. In general I don't think we should event new MIBs for ND unless there is no way that we can augment the existing drafts to cover ND. The existing Ipv6NetToMediaTable maps very nicely onto the ND neighbor cache. I don't see the upside in defining another Ipv6NdNeighborCacheTable which simply repeats all the information of the Ipv6NetToMediaTable along with reachability state and reachability times. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 07:51:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA17438; Tue, 13 May 1997 07:43:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA17431; Tue, 13 May 1997 07:43:20 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA01994; Tue, 13 May 1997 07:44:38 -0700 Received: from mailhost1.BayNetworks.COM ([134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA25253 for ; Tue, 13 May 1997 07:45:12 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id HAA28372 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id HAA21426 Posted-Date: Tue, 13 May 1997 07:44:38 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com ([192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA07995; Tue, 13 May 1997 10:44:34 -0400 for Message-Id: <3.0.32.19970513104339.006aa34c@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 May 1997 10:43:44 -0400 To: thartric@mentat.com (Tim Hartrick) From: Dimitry Haskin Subject: (IPng 3626) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4413 At 05:44 PM 5/12/97 -0700, Tim Hartrick wrote: > > >Folks, > >> >> >ICMPv6 Group: >> > >> >To start with the easy one, I think this MIB is fine. I understand >> >your justification for separate aggregate and per-interface statistics, >> >and think this MIB is ready to move to an experimental RFC. >> > > >Maybe I missed something but in the 01 draft I do not see the aggregate >ICMPv6 statistics only the per-interface statistics. What did I miss? > Aggregated statistics were removed per a WG request. A number of people considered them redundant and there was no opposition for removing them from mib. >I had one question about this MIB. Since ICMPv6 now includes IGMP messages >should an IGMP membership table be part of the ICMPv6 MIB? It would be >unfortunate if we had to invent yet another MIB to handle this case at >some later time. Even though ICMPv6 is used for the IGMP messaging I don't think that the ICMPv6 group is the right place for an IGMP membership table. I'm not familiar with all details of the mib logistics, but I believe that an implementation of a mib group must support all objects of such a group. It is not clear that we can require any system that implemented ICMPv6 to support IGMP also. As a reference point, v4 has a separate IGMP mib (draft-ietf-idmr-igmp-mib-04.txt) which is produced by the IDMR WG and where I think IGMPv6 mib belongs too. > >> > >> >First, I believe that the Ipv6NetToMediaTable should be modified to >> >better reflect what a Neighbor Discovery Cache will actually look >> >like. For example, including the expiration time, status, etc. of >> >each entry. If this is unclear, would be happy to write up an >> >example of what I think it could/should look like (although I have >> >not completed my ND implementation, so it would require comment from >> >people who have). >> > >> >> An example would help. The Ipv6NetToMediaTable is not ND specific. The >> purpose of this simple table to provide the current v6 address to L2 >> address mapping which can be derived by a number of means (should we get >> NHRP related information into this table too?). Of cause, a mapping can >> become invalid for many reasons. As far as the expiration time, I believe >> that you're asking for the information that is more appropriate in the >> ipv6AddrPrefixTable which already defines attributes for the preferred and >> valid lifetimes. On a side note, I think it would be nice to have a >> separate ND mib and I hope that someone would volunteer to write it up. >> >> Naturally, your example may change my mind. >> >> > >I believe it would be useful to have the reachability state (STALE, PROBE, >DELAY, REACHABLE) as part of the Ipv6NetToMediaEntry. Even if NHRP or some >other L2 protocol is being used for resolution, reachability will be deter- >mined by NUD. It would also be useful to have the reachability time available >as part of the entry. > I see.. I'll add the reachability state to the Ipv6NetToMediaTable. I am not clear on the reachability time. Is it a parameter that can be advertised in Router Advertisements? If so, then I think this is an ND parameter that is not specific to each Ipv6NetToMediaEntry and therefore is more appropriate in a general ND table which I believe need to be defined any way -- there are other ND parameters (e.g. Retransmit Timer, Max Hop Limit) that can be supplied in RA and need to be represented in some mib. Said that, I think the age a particular net-to-media mapping (i.e. a number of seconds since the mapping was last updated) would be useful. Would it be sufficient? >In general I don't think we should event new MIBs for ND unless there is >no way that we can augment the existing drafts to cover ND. The existing >Ipv6NetToMediaTable maps very nicely onto the ND neighbor cache. I don't >see the upside in defining another Ipv6NdNeighborCacheTable which simply >repeats all the information of the Ipv6NetToMediaTable along with reachability >state and reachability times. > > > >Tim Hartrick Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 08:35:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17632; Tue, 13 May 1997 08:27:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17625; Tue, 13 May 1997 08:27:06 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA11722; Tue, 13 May 1997 08:28:24 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA24100 for ; Tue, 13 May 1997 08:28:26 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA28660; Tue, 13 May 1997 11:25:42 -0400 Date: Tue, 13 May 1997 11:25:42 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9705131125.ZM28658@seawind.bellcore.com> In-Reply-To: Jack McCann "(IPng 3623) Re: W.G. Last Call on "Advanced Sockets API for IPv6"" (May 12, 4:51pm) References: <9705122051.AA17994@wasted.zk3.dec.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: Jack McCann , rstevens@kohala.com Subject: (IPng 3627) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1254 > Site-local addresses have the same problem as link-local when a > host has interfaces in multiple sites, e.g. interface A belongs to > site X and interface B belongs to site Y. In fact, site local addresses have all the problems related to non unique addresses, which are well known and documented in e.g. RFC 1627. This may be late in the game, but we should really consider a way to somehow avoid or minimize the problems related to that non-uniqueness. Did we ever consider inserting some site identifier, e.g. a random value, in the site local prefix ? I know that this would not make the problem disappear entirely, I know that randomness leads to unhappy birthdays, specially when the random number is not actually random (albeit the site manager could actually trow dices, it is a one time operation). But we could still go a long way... -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 09:37:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17702; Tue, 13 May 1997 09:29:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17695; Tue, 13 May 1997 09:29:07 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA24778; Tue, 13 May 1997 09:30:26 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA16980 for ; Tue, 13 May 1997 09:30:27 -0700 Received: from quarry.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA24824; Tue, 13 May 1997 12:24:48 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA29504; Tue, 13 May 1997 12:24:45 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA26780; Tue, 13 May 1997 12:20:50 -0400 Message-Id: <9705131620.AA26780@bernie.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 3628) Re: ICMPv6 mib q.. Date: Tue, 13 May 97 12:20:49 -0400 From: Mike Daniele X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3127 >The Ipv6RouteTable also requires some changes. Specifically, I think >it should be modified to be more like the IpForwardTable (RFC1354, which >supersedes the MIB-II IpRouteTable). I would suggest the following >specific changes: Shouldn't the concern be about similarity to RFC2096, which supercedes ipForwardingTable? (This ipCidrRouteTable's index is INDEX { ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos, ipCidrRouteNextHop } ) >>- Do not use IfIndex as an index in this table. >Well.. if we keep ipv6RouteIndex as an index, IfIndex can be removed. But I >thought it simplified retrieval of all routes through a given interface - a >quite common operation. It seems like indexing first by IfIndex would add a lot of processing overhead in the agent, since it couldn't use the system's "natural" route ordering/lookup abilities. I have to read every route to find all the ones that point to interface n... >UDP & TCP Groups: > >These tables should be modified to use the UnifiedIPAddress, as >described above. The MIB should also indicate that these tables are >intended to deprecate the MIB-II UDP and TCP tables (which are for >IPv4 only). Margaret, I see your point, but I'm not sure it's a good idea. The net effect is that all ipv4 addresses would sort before all ipv6 addresses, due to being indexed by a variable-length octet string. Not very much different than accessing two different tables... The mib-2 atTable was broken, there was good reason to deprecate it in favor of ipNetToMediaTable. I don't think the UDP or TCP MIBs are in the same condition. There is no valid reason to deprecate them, is there? The entire installed base isn't going to implement this new MIB simply to be able to return ipv4 addresses as octet strings. So it seems like we'll have to live with both MIBs forever anyway. Is your issue that it's harder for agents, for managers, both? My 2 cents... >>ifIndex should not be used as an index in the UDP and TCP tables, >>as it could certainly change throughout the lifetime of a connection. >>In fact, I would argue that it should not be included as an object >>at all, since the UDP and TCP layers should not know (or care) what >>interface is being used to send their packets. >> >And what would you do with tcp/udp to link-local addresses? IfIndex is >necessary to qualify link-local and, possibly, site-local addresses. Are >you proposing that link-local addresses are not used in the UDP and TCP >context? Are you saying a TCP implementation will require more than {local addr, local port, remote addr, remote port} to uniquely identify a connection? An example of why we need IfIndex here would help (me). Thanks, Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 13:00:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00256; Tue, 13 May 1997 11:41:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00247; Tue, 13 May 1997 11:41:07 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA27886; Tue, 13 May 1997 11:42:25 -0700 Received: from akita.cisco.com (akita.cisco.com [171.69.223.72]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA07614 for ; Tue, 13 May 1997 11:42:26 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by akita.cisco.com (8.6.12/8.6.5) with ESMTP id LAA22183; Tue, 13 May 1997 11:42:17 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA06730; Tue, 13 May 1997 11:38:03 -0700 (PDT) Date: Tue, 13 May 1997 11:38:03 -0700 (PDT) Message-Id: <199705131838.LAA06730@pedrom-ultra.cisco.com> From: Pedro Marques To: Jack McCann Cc: rstevens@kohala.com, ipng@sunroof.eng.sun.com Subject: (IPng 3629) Re: W.G. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <9705122051.AA17994@wasted.zk3.dec.com> References: <9705122051.AA17994@wasted.zk3.dec.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1860 >>>>> "Jack" == Jack McCann writes: Jack> On the topic of site-local addresses, I offer the following Jack> thoughts. Site-local addresses have the same problem as Jack> link-local when a host has interfaces in multiple sites, Jack> e.g. interface A belongs to site X and interface B belongs Jack> to site Y. In this case we may need to specify which site a Jack> site-local address belongs to, similar to the way we would Jack> specify which link (interface) a link-local address belongs Jack> to. Jack> We probably need some API extensions to deal with the notion Jack> of a "site". I don't think so. An interface cannot belong to more than a site. If you have a multihomed host (the only way you can be in two sites) you can use the interface id to specify the "site" you which to talk to. Jack> (we can't simply map a site identifier to an interface Jack> index because there may be multiple interfaces belonging to Jack> a given site, and we'd like to use the routing tables to True. But since there can't be an interface belonging to two sites an interface uniquely identifies a site. Jack> decide which interface within the given site) Site ids would have even further complexity and they require full manual configuration. i.e. tag all interfaces with a site id... it would mainly be a level of indirection. Besides, how common will this scenario be in the "real world". ? ./Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 13:03:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00263; Tue, 13 May 1997 11:41:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA00250; Tue, 13 May 1997 11:41:08 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA27892; Tue, 13 May 1997 11:42:26 -0700 Received: from mailhost2.BayNetworks.COM ([134.177.3.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA07649 for ; Tue, 13 May 1997 11:42:29 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id LAA16101 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id LAA02530 Posted-Date: Tue, 13 May 1997 11:36:08 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com ([192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id OAA16062; Tue, 13 May 1997 14:36:09 -0400 for Message-Id: <3.0.32.19970513143515.006b08d0@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 13 May 1997 14:35:16 -0400 To: Mike Daniele From: Dimitry Haskin Subject: (IPng 3630) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2784 At 12:20 PM 5/13/97 -0400, Mike Daniele wrote: > >>>- Do not use IfIndex as an index in this table. >>Well.. if we keep ipv6RouteIndex as an index, IfIndex can be removed. But I >>thought it simplified retrieval of all routes through a given interface - a >>quite common operation. > >It seems like indexing first by IfIndex would add a lot of processing >overhead in the agent, since it couldn't use the system's "natural" >route ordering/lookup abilities. > >I have to read every route to find all the ones that point to >interface n... > You're right, SNMP sucks.. IfIndex can be removed as an index without much impact. It can't be the first index since finding all routes to a given destination is a much more common operation. >>>ifIndex should not be used as an index in the UDP and TCP tables, >>>as it could certainly change throughout the lifetime of a connection. >>>In fact, I would argue that it should not be included as an object >>>at all, since the UDP and TCP layers should not know (or care) what >>>interface is being used to send their packets. >>> >>And what would you do with tcp/udp to link-local addresses? IfIndex is >>necessary to qualify link-local and, possibly, site-local addresses. Are >>you proposing that link-local addresses are not used in the UDP and TCP >>context? > >Are you saying a TCP implementation will require more than >{local addr, local port, remote addr, remote port} to uniquely >identify a connection? An example of why we need IfIndex here would help >(me). > Welcome to IPv6. If the local address is a link-local scope address, it is possible to have more than one interface with the same link-local address. It is also possible to have the same adjacent link-local address out of different interfaces. The same theoretically possible with site-local addresses if a system has interfaces connected to different sites. The only way to absolutely insure that a connection is always uniquely identified is to add IfIndex as an index. >Thanks, >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 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 15:43:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00628; Tue, 13 May 1997 14:40:09 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00616; Tue, 13 May 1997 14:39:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04646; Tue, 13 May 1997 14:41:07 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA23565 for ; Tue, 13 May 1997 14:41:41 -0700 Received: from ftp.com by ftp.com ; Tue, 13 May 1997 17:41:14 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 13 May 1997 17:41:14 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id RAA07140; Tue, 13 May 1997 17:37:51 -0400 Message-Id: <199705132137.RAA07140@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: daniele@zk3.dec.com, ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 3631) Re: ICMPv6 mib q.. Date: Tue, 13 May 1997 17:41:14 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1264 >>Reply to your message of 5/13/97 12:45 PM > >>UDP & TCP Groups: >> >>These tables should be modified to use the UnifiedIPAddress... > >The net effect is that all ipv4 addresses would sort before=20 >all ipv6 addresses, due to being indexed by a variable-length octet string= . >Not very much different than accessing two different tables... >.. >Is your issue that it's harder for agents, for managers, both? In a word, yes: if it's kept the way it's currently described, you have to remember that when the agent/manager asked for "the TCP connection table= ", what they've really gotten is "the TCP connection table where IPv4 is the transport protocol" and then have to make a separate request for IPv6-based connections. That seems clumsy, esp. since the rest of the standard TCP/UD= P mibs don't do anything that's specific to the network layer being used. -- Frank -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 16:12:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00691; Tue, 13 May 1997 14:56:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00684; Tue, 13 May 1997 14:56:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA07892; Tue, 13 May 1997 14:57:42 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA28056 for ; Tue, 13 May 1997 14:58:12 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA23706; Tue, 13 May 97 14:54:57 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA00966; Tue, 13 May 1997 14:58:08 -0700 Date: Tue, 13 May 1997 14:58:08 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705132158.OAA00966@feller.mentat.com> To: dhaskin@BayNetworks.COM Subject: (IPng 3632) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1062 Dimitry, > > > >Maybe I missed something but in the 01 draft I do not see the aggregate > >ICMPv6 statistics only the per-interface statistics. What did I miss? > > > Aggregated statistics were removed per a WG request. A number of people > considered them redundant and there was no opposition for removing them > from mib. > Good. This is what I remembered. > > Said that, I think the age a particular net-to-media mapping (i.e. a number > of seconds since the mapping was last updated) would be useful. Would it be > sufficient? > Either the time of last update or the amount of time before the next expiration is fine. The later would seem more useful. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 14 04:23:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA01728; Wed, 14 May 1997 03:39:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA01721; Wed, 14 May 1997 03:38:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA05039; Wed, 14 May 1997 03:40:07 -0700 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA14387 for ; Wed, 14 May 1997 03:40:43 -0700 Received: by mail.noris.net id <35316-12124>; Wed, 14 May 1997 12:40:08 +0200 Path: noris.net!not-for-mail From: smurf@work.smurf.noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3633) Re: ICMPv6 mib q.. Date: 14 May 1997 12:39:55 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 24 Message-ID: <5lc4pr$6cs$1@work.smurf.noris.de> References: <3.0.32.19970513143515.006b08d0@pobox> <863558726.20155@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1861 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1526 Dimitry Haskin writes: > > You're right, SNMP sucks.. IfIndex can be removed as an index without much > impact. It can't be the first index since finding all routes to a given > destination is a much more common operation. > In my experience, finding all routes to a given interface is more common. Specifically, when I remove or update a customer from my dialup router I need to update/delete all their routes, which all go through a common interface. If we need both, then there obviously needs to be a read-only secondary table which gives the OID of a routing entry indexed by interface.arbitrary. SNMP management otherwise becomes a rather dull (slow) experience. -- You will emerge from the gutter, only to trip and land in the sewer. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 14 06:42:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA01931; Wed, 14 May 1997 05:42:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA01924; Wed, 14 May 1997 05:42:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA13350; Wed, 14 May 1997 05:43:31 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA02958 for ; Wed, 14 May 1997 05:44:08 -0700 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id IAA22758; Wed, 14 May 1997 08:37:49 -0400 (EDT) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14156; Wed, 14 May 1997 08:37:45 -0400 Date: Wed, 14 May 1997 08:37:45 -0400 From: Jack McCann Message-Id: <9705141237.AA14156@wasted.zk3.dec.com> To: roque@cisco.com Subject: (IPng 3634) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1547 Hi Pedro. Jack> We probably need some API extensions to deal with the notion Jack> of a "site". Pedro>I don't think so. Pedro>An interface cannot belong to more than a site. If you have a multihomed Pedro>host (the only way you can be in two sites) you can use the interface Pedro>id to specify the "site" you which to talk to. No, you can use the interface id to specify one of the interfaces in the "site". This is different from specifying the "site". If I have multiple interfaces belonging to a site, and I want to send a packet to that site, I don't care which interface it uses, I'll want the routing table to decide that. Hence I must be able to specify the site. Pedro>Site ids would have even further complexity and they require full manual Pedro>configuration. i.e. tag all interfaces with a site id... it would mainly Pedro>be a level of indirection. Yes, someone needs to specify which interfaces belong to which sites. Of course there will be a "default" site that all interfaces belong to unless otherwise configured. Pedro> Besides, how common will this scenario be in the "real world". ? Not very, would be my guess. - 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 May 14 07:48:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02026; Wed, 14 May 1997 06:34:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02019; Wed, 14 May 1997 06:34:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA20797; Wed, 14 May 1997 06:35:30 -0700 Received: from SOLARIX1.UNI-MUENSTER.DE (SOLARIX1.UNI-MUENSTER.DE [128.176.191.83]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA14659 for ; Wed, 14 May 1997 06:36:07 -0700 Received: from localhost (ipng@localhost) by SOLARIX1.UNI-MUENSTER.DE (8.8.5/8.8.4) with SMTP id MAA26598; Wed, 14 May 1997 12:35:05 -0100 (GMT) X-Authentication-Warning: SOLARIX1.UNI-MUENSTER.DE: ipng owned process doing -bs Date: Wed, 14 May 1997 15:35:05 +0200 (MEZ) From: JOIN Project Team Reply-To: JOIN Project Team To: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU cc: IPv6-JOIN-Liste Subject: (IPng 3636) IPv6 Demo at JENC8 in Edinburgh Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1547 Hi, We would like to inform you about our IPv6 demo at the 8th Joint European Networking Conference in Edinburgh: We set up two routers interconnected via ATM running IPv6 and OSPFv6 over it. One of these routers has tunnels to UNI-C and Telebit in Denmark, with whom we have collaborated, and JOIN in Germany. These tunnels are running BGP4+ and IDRPv6 as routing protocols to connect to the global 6bone. You can also look at: http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/edinburgh.html and http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/edinburgh-demo.html Greetings from Scotland - Guido ------------------------------------------------------------------------------ JOIN -- IP Version 6 in the WiN Guido Wessendorf A project of DFN Westfaelische Wilhelms-Universitaet Muenster Project Team email: Universitaetsrechenzentrum join@uni-muenster.de Einsteinstrasse 60 http://www.join.uni-muenster.de D-48149 Muenster / Germany phone: +49 251 83 31639, fax: +49 251 83 31653, email: wessend@uni-muenster.de ------------------------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 14 07:43:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02017; Wed, 14 May 1997 06:25:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA02010; Wed, 14 May 1997 06:24:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA18920; Wed, 14 May 1997 06:26:10 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA12559 for ; Wed, 14 May 1997 06:26:48 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id GAA11527 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id GAA18738 Posted-Date: Wed, 14 May 1997 06:26:15 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com ([192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id JAA04342; Wed, 14 May 1997 09:26:18 -0400 for Message-Id: <3.0.32.19970514092526.006ae5c0@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 14 May 1997 09:25:26 -0400 To: thartric@mentat.com (Tim Hartrick) From: Dimitry Haskin Subject: (IPng 3635) Re: ICMPv6 mib q.. Cc: dhaskin@BayNetworks.COM, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 912 Tim, >> Said that, I think the age a particular net-to-media mapping (i.e. a number >> of seconds since the mapping was last updated) would be useful. Would it be >> sufficient? >> > >Either the time of last update or the amount of time before the next >expiration is fine. The later would seem more useful. > There can be some mapping that never expire, e.g. statically configured, for which the last update time would be far more informative. Hence, if no objection, I'll go with the last update time. > >Tim Hartrick > Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 14 10:30:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02180; Wed, 14 May 1997 09:15:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02173; Wed, 14 May 1997 09:15:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA28713; Wed, 14 May 1997 09:16:42 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA29137 for ; Wed, 14 May 1997 09:17:19 -0700 Received: from spruce.betham.org (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA09178 for ; Wed, 14 May 1997 09:16:52 -0700 Message-Id: <3.0.1.32.19970514091744.006f02f4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 14 May 1997 09:17:44 -0700 To: ipng@sunroof.eng.sun.com From: The IESG (by way of Bob Hinden ) Subject: (IPng 3637) Protocol Action: TCP and UDP over IPv6 Jumbograms to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1318 The IESG has approved the Internet-Draft "TCP and UDP over IPv6 Jumbograms" as a Proposed Standard. This document is not the product of an IETF Working Group. The IESG contact person is Jeff Burgan . Technical Summary IPv6 supports datagrams larger than 65535 bytes long (often referred to as "jumbograms") through use of the IPv6 Jumbo Payload hop-by-hop option. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. Working Group Summary The Working Group last call produced no issues with this document. Protocol Quality This document has been reviewed by Jeffrey Burgan and Thomas Narten -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 14 15:20:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA02976; Wed, 14 May 1997 14:26:56 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA02969; Wed, 14 May 1997 14:26:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA10144; Wed, 14 May 1997 14:27:54 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA06261 for ; Wed, 14 May 1997 14:28:31 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA00601; Wed, 14 May 97 14:25:14 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA02090; Wed, 14 May 1997 14:28:28 -0700 Date: Wed, 14 May 1997 14:28:28 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705142128.OAA02090@feller.mentat.com> To: dhaskin@BayNetworks.COM Subject: (IPng 3638) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 942 Dimitry, > > > >Either the time of last update or the amount of time before the next > >expiration is fine. The later would seem more useful. > > > There can be some mapping that never expire, e.g. statically configured, > for which the last update time would be far more informative. Hence, if no > objection, I'll go with the last update time. > > Then we can define a value of 2^32 - 1 to be infinity as we do with prefix and address lifetimes. The time remaining until expiration has more utility I my opinion than the last update time. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 07:07:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03745; Thu, 15 May 1997 06:15:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03738; Thu, 15 May 1997 06:14:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA21170; Thu, 15 May 1997 06:15:58 -0700 Received: from durandal.ibp.fr (durandal.ibp.fr [132.227.60.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA18890 for ; Thu, 15 May 1997 06:16:38 -0700 Received: from masi.ibp.fr (masi.ibp.fr [132.227.64.100]) by durandal.ibp.fr (8.8.5/jtpda-5.2) with ESMTP id PAA22899 for ; Thu, 15 May 1997 15:16:09 +0200 (MET DST) Received: from hera.ibp.fr (hera-gw.ibp.fr [132.227.60.32]) by masi.ibp.fr (8.6.11/jtpda-5.0) with ESMTP id PAA03159 for ; Thu, 15 May 1997 15:13:36 +0200 Received: from oreste.ibp.fr (pan@oreste.ipv6.ibp.fr [132.227.61.23]) by hera.ibp.fr (8.8.5/jtpda-5.0) with ESMTP id PAA27402 for ; Thu, 15 May 1997 15:13:13 +0200 (MET DST) Received: from (pan@localhost) by oreste.ibp.fr (8.6.12/jtpda-5.0) id PAA11023 ; Thu, 15 May 1997 15:13:11 +0200 Date: Thu, 15 May 1997 15:13:05 +0200 (MET DST) From: Pascal Anelli To: ipng@sunroof.eng.sun.com Subject: (IPng 3639) Comment on "Advanced Sockets API for IPv6" In-Reply-To: <9705141237.AA14156@wasted.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 content-length: 1086 page 32, about the inet6_flow_free, we can read: -------- int inet6_flow_free(int fd, const struct sockaddr_in6 *sin6); A previously assigned flow label can be explicitly freed. If this function is not called, the flow label is automatically freed on the last close of the socket. The flow label field in the socket address structure specifies the flow label that is being freed. --------- I think we must add, the flow label is freed only for that socket, in case of one or more previous inet6_flow_reuse for this flow label, the flow label is shared and it is still used by others sockets. It is not raisonnable to free a flow label that to be used moreover. Pascal, -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 08:23:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03785; Thu, 15 May 1997 07:23:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03778; Thu, 15 May 1997 07:23:39 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04898; Thu, 15 May 1997 07:24:55 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA05935 for ; Thu, 15 May 1997 07:25:33 -0700 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost3.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id KAA12901 Posted-Date: Thu, 15 May 1997 10:32:43 -0400 (EDT) Received: from andover.engeast (andover [192.32.174.201]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA16121; Thu, 15 May 1997 10:25:01 -0400 for Date: Thu, 15 May 1997 10:25:01 -0400 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199705151425.KAA16121@pobox.engeast.BayNetworks.COM> To: dhaskin@BayNetworks.COM, thartric@mentat.com Subject: (IPng 3640) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1535 Tim, > > >Either the time of last update or the amount of time before the next > > >expiration is fine. The later would seem more useful. > > > > > There can be some mapping that never expire, e.g. statically configured, > > for which the last update time would be far more informative. Hence, if no > > objection, I'll go with the last update time. > > > > > Then we can define a value of 2^32 - 1 to be infinity as we do with > prefix and address lifetimes. The time remaining until expiration has > more utility I my opinion than the last update time. > > Yes, we can.. but the point is that there would be no way to figure out when the mapping was last updated. Even if there is a finite expiration time, in my experience, the last update time is more useful. I'll give you a real life example based on the forwarding table mib: when I see a 5 hours old RIP entry I know right away that there is a problem (sh.. happens ;) since it should have been updated within 90 seconds or expire. But if I had the same stale RIP entry and all I get is that it should expire in 90 seconds determining that there is a problem would be a challenge. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 09:13:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03817; Thu, 15 May 1997 08:07:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03810; Thu, 15 May 1997 08:06:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15575; Thu, 15 May 1997 08:07:53 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA18088 for ; Thu, 15 May 1997 08:08:29 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id IAA29580; Thu, 15 May 1997 08:08:00 -0700 (PDT) for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id IAA04720; Thu, 15 May 1997 08:07:59 -0700 (PDT) for Posted-Date: Thu, 15 May 1997 08:07:59 -0700 (PDT) Received: from andover.engeast (andover [192.32.174.201]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id LAA22327; Thu, 15 May 1997 11:07:59 -0400 for Date: Thu, 15 May 1997 11:07:59 -0400 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199705151507.LAA22327@pobox.engeast.BayNetworks.COM> To: ipng@sunroof.eng.sun.com Subject: (IPng 3641) address token Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 705 Falks, The current IPv6 mib assumes that the address token can be of different size in the 0 to 64 bit range. Is it still true with the new addressing scheme? It seems that now all tokens must be 64 bit long, right? Is there a possibility for other addressing schemes with a different token size in the future? Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 12:16:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04093; Thu, 15 May 1997 11:04:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04086; Thu, 15 May 1997 11:04:35 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA27414; Thu, 15 May 1997 11:05:51 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA17625 for ; Thu, 15 May 1997 11:06:28 -0700 Received: from quarry.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA03955; Thu, 15 May 1997 13:56:19 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA11791; Thu, 15 May 1997 13:56:16 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA28495; Thu, 15 May 1997 13:52:15 -0400 Message-Id: <9705151752.AA28495@bernie.zk3.dec.com> To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3643) Re: ICMPv6 mib q.. In-Reply-To: Your message of "Tue, 13 May 97 14:35:16 EDT." <3.0.32.19970513143515.006b08d0@pobox> Date: Thu, 15 May 97 13:52:14 -0400 From: Mike Daniele X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3311 Dimitry, >Welcome to IPv6. If the local address is a link-local scope address, it is >possible to have more than one interface with the same link-local address. >It is also possible to have the same adjacent link-local address out of >different interfaces. The same theoretically possible with site-local >addresses if a system has interfaces connected to different sites. The >only way to absolutely insure that a connection is always uniquely >identified is to add IfIndex as an index. I'm going to try and state the MIB problems succinctly. (Hopefully this will help the discussion... :-) 1) A managed system with multiple interfaces may have the same (link-local) address configured on multiple interfaces. 2) Such a system may communicate (and maintain TCP connections) with multiple remote systems that have the same (remote, link-local) address. The combination of 1) and 2) means the {local-addr, local-port, remote-addr, remote-port} tuple is not guaranteed to be unique on such managed systems. Hence we need some mechanism in the MIB for disambiguating these "duplicate" connections. The current spec solves this by adding ipv6IfIndex to the INDEX: INDEX { ipv6IfIndex, ipv6TcpConnLocalAddress, ipv6TcpConnLocalPort, ipv6TcpConnRemAddress, ipv6TcpConnRemPort } The things I'm worried about are o forcing ifindex to be looked up for every TCP connection (in the agent) the interface we're talking about is the one on which the local address is configured, right? (The spec is not clear on this.) The interface typically "available" for a connection is the one associated with the route used to reach the remote address. For link-local addresses they are the same interface. For all others they are not guaranteed to be the same interface. For 99.9% of all connections ifindex is not required (since the tuple is already unique). o indexing first by ifindex seems wrong. Again, it removes any chance of using optimized lookups. Also, it seems like it would lessen the usefulness from a manager's perspective. (Find all connections to this socket...) We'd be changing the "semantics" of the table. Would you consider something like this? INDEX { ipv6TcpConnLocalAddress, ipv6TcpConnLocalPort, ipv6TcpConnRemAddress, ipv6TcpConnRemPort, ipv6TcpConnIndex } where TcpConnIndex is a non-accessible object used only to disambiguate otherwise duplicate connections. A value of 0 should be returned if there are no duplicates. Otherwise, the value must be the ipv6IfIndex value corresponding to the interface on which ipv6TcpConnLocalAddress is configured. (Or it could be made to disambiguate LocalAddress only, if that makes more sense.) Same for ipv6UdpTable. Thanks, Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 12:37:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04312; Thu, 15 May 1997 11:29:36 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04305; Thu, 15 May 1997 11:29:31 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06492; Thu, 15 May 1997 11:31:02 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA11538; Thu, 15 May 1997 11:29:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04019; Thu, 15 May 1997 10:33:46 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA19130; Thu, 15 May 1997 10:34:50 -0700 Received: from network-services.uoregon.edu (network-services.uoregon.edu [128.223.60.21]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA07126 for ; Thu, 15 May 1997 10:35:31 -0700 Received: (from meyer@localhost) by network-services.uoregon.edu (8.8.5/8.8.5) id KAA21025; Thu, 15 May 1997 10:35:03 -0700 (PDT) Date: Thu, 15 May 1997 10:35:03 -0700 (PDT) Message-Id: <199705151735.KAA21025@network-services.uoregon.edu> From: "David M. Meyer" To: ipng@sunroof.eng.sun.com cc: meyer@antc.uoregon.edu Subject: (IPng 3644) RFC 1884 multicast scope naming Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 15478 The Administratively Scoped IP Multicast draft (produced in the MBONED WG) is attempting to create a loose mapping between the SCOPs and the IPv4 multicast scope classes. We currently have the table IPv6 SCOP RFC 1884 Description IPv4 Prefix ================================================================== 0 reserved 1 node-local scope 2 link-local scope 224.0.0.0/24 3 (unassigned) 239.255.0.0/16 4 (unassigned) 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 239.192.0.0/14 A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope 224.0.1.0-238.255.255.255 F reserved [the entire draft is included below] Many people have expressed concern over confusion which may result from the naming of the "smallest enclosing scope larger than link local". In RFC 1884, it is left unnamed. In the IPv4 context, we've been calling this scope the "IPv4 Local Scope". On the other hand, RFC 1884 defines the site-local scope, which isn't semantically equivalent (that is, it isn't the smallest enclosing scope, but contains the word local). One possible solution would be to amend RFC 1884 to give SCOP 3 the name "Local" scope. Another possibility would be to devise a reasonable name for "smallest enclosing scope larger than link local" and change the names of SCOP 3 and the IPv4 Local scope to this (although constructing a good name for this has proven elusive. Comments? Thanks, Dave ------ MBONED Working Group David Meyer Internet Draft University of Oregon Category Best Current Practice draft-ietf-mboned-admin-ip-space-04.txt May 1997 Administratively Scoped IP Multicast 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to or the author. David Meyer FORMFEED[Page 1] Internet Draft draft-ietf-mboned-admin-ip-space-04.txt May 1997 3. Acknowledgments Much of this memo is taken from "Administratively Scoped IP Multicast", Van Jacobson and Steve Deering, presented at the 30th IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and Dave Thaler have also provided insightful comments on earlier versions of this document. 4. Introduction Most current IP multicast implementations achieve some level of scoping by using the TTL field in the IP header. Typical MBONE (Multicast Backbone) usage has been to engineer TTL thresholds that confine traffic to some administratively defined topological region. The basic forwarding rule for interfaces with configured TTL thresholds is that a packet is not forwarded across the interface unless its remaining TTL greater than the threshold. TTL scoping has been used to control the distribution of multicast traffic with the objective of easing stress on scarce resources (e.g., bandwidth), or to achieve some kind of improved privacy or scaling properties. In addition, the TTL is also used in its traditional role to limit datagram lifetime. Given these often conflicting roles, TTL scoping has proven difficult to implement reliably, and the resulting schemes have often been complex and difficult to understand. A more serious architectural problem concerns the interaction of TTL scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The particular problem is that in many common cases, TTL scoping can prevent pruning from being effective. Consider the case in which a packet has either had its TTL expire or failed a TTL threshold. The router which discards the packet will not be capable of pruning any upstream sources, and thus will sink all multicast traffic (whether or not there are downstream receivers). Note that while it might seem possible to send prunes upstream from the point at which a packet is discarded, this strategy can result in legitimate traffic being discarded, since subsequent packets could take a different path and arrive at the same point with a larger TTL. On the other hand, administratively scoped IP multicast can provide clear and simple semantics for scoped IP multicast. The key properties of administratively scoped IP multicast are that (i). packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries, and (ii). administratively scoped multicast addresses are locally assigned, and hence are not required to be unique across administrative boundaries. David Meyer FORMFEED[Page 2] Internet Draft draft-ietf-mboned-admin-ip-space-04.txt May 1997 5. Definition of the Administratively Scoped IPv4 Multicast Space The administratively scoped IPv4 multicast address space is defined to be the range 239.0.0.0 to 239.255.255.255. 6. Discussion In order to support administratively scoped IP multicast, a router should support the configuration of per-interface scoped IP multicast boundaries. Such a router, called a boundary router, does not forward packets matching an interface's boundary definition in either direction (the bi-directional check prevents problems with multi- access networks). In addition, a boundary router always prunes the boundary for dense-mode groups [PIMDM], and doesn't accept joins for sparse-mode groups [PIMSM] in the administratively scoped range. 7. The Structure of the Administratively Scoped Multicast Space The structure of the IP version 4 administratively scoped multicast space is loosely based on the IP Version 6 Addressing Architecture described in RFC 1884 [RFC1884]. This document defines two important scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These scopes are described below. 7.1. The IPv4 Local Scope -- 239.255.0.0/16 239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope is the minimal enclosing scope, and hence is not further divisible. Although the exact extent of a Local Scope is site dependent, locally scoped regions must obey certain topological constraints. In particular, a Local Scope must not span any other scope boundary. Further, a Local Scope must be completely contained within or equal to any larger scope. In the event that scope regions overlap in area, the area of overlap must be in its own local scope. This implies that any scope boundary is also a boundary for the Local Scope. The more general topological requirements for administratively scoped regions are discussed below. 7.1.1. Expansion of the IPv4 Local Scope The IPv4 Local Scope space grows "downward". As such, the IPv4 Local Scope may grow downward from 239.255.0.0/16 into the reserved ranges 239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not be utilized until the 239.255.0.0/16 space is no longer sufficient. David Meyer FORMFEED[Page 3] Internet Draft draft-ietf-mboned-admin-ip-space-04.txt May 1997 7.2. The IPv4 Organization Local Scope -- 239.192.0.0/14 239.192.0.0/14 is defined to be the IPv4 Organization Local Scope, and is the space from which an organization should allocate sub- ranges when defining scopes for private use. 7.2.1. Expansion of the IPv4 Organization Local Scope The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are unassigned and available for expansion of this space. These ranges should be left unassigned until the 239.192.0.0/14 space is no longer sufficient. This is to allow for the possibility that future revisions of this document may define additional scopes on a scale larger than organizations. 7.3. Other IPv4 Scopes of Interest The other two scope classes of interest, statically assigned link- local scope and global scope already exist in IPv4 multicast space. The statically assigned link-local scope is 224.0.0.0/24. The existing static global scope allocations are somewhat more granular, and include 224.1.0.0-224.1.255.255 ST Multicast Groups 224.2.0.0-224.2.127.253 Multimedia Conference Calls 224.2.127.254 SAPv1 Announcements 224.2.127.255 SAPv0 Announcements (deprecated) 224.2.128.0-224.2.255.255 SAP Dynamic Assignments 224.252.0.0-224.255.255.255 DIS transient groups 232.0.0.0-232.255.255.255 VMTP transient groups See [RFC1700] for current multicast address assignments (this list can also be found, possibly in a more current form, on ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses). David Meyer FORMFEED[Page 4] Internet Draft draft-ietf-mboned-admin-ip-space-04.txt May 1997 8. Topological Requirements for Administrative Boundaries An administratively scoped IP multicast region is defined to be a topological region in which there are one or more boundary routers with common boundary definitions. Such a router is said to be a boundary for scoped addresses in the range defined in its configuration. Network administrators may configure a scope region whenever constrained multicast scope is required. In addition, an administrator may configure overlapping scope regions (networks can be in multiple scope regions) where convenient, with the only limitations being that a scope region must be connected (there must be a path between any two nodes within a scope region that doesn't leave that region), and convex (i.e., no path between any two points in the region can cross a region boundary). Finally, note that any scope boundary is a boundary for the Local Scope. This implies that packets sent to groups covered by 239.255.0.0/16 must not be forwarded across any link for which a scoped boundary is defined. 9. Partitioning of the Administratively Scoped Multicast Space The following table outlines the partitioning of the IPv4 multicast space, and gives the mapping from IPv4 multicast prefixes to IPv6 SCOP values: IPv6 SCOP RFC 1884 Description IPv4 Prefix ================================================================== 0 reserved 1 node-local scope 2 link-local scope 224.0.0.0/24 3 (unassigned) 239.255.0.0/16 4 (unassigned) 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 239.192.0.0/14 A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope 224.0.1.0-238.255.255.255 F reserved David Meyer FORMFEED[Page 5] Internet Draft draft-ietf-mboned-admin-ip-space-04.txt May 1997 (unassigned) 239.0.0.0/10 (unassigned) 239.64.0.0/10 (unassigned) 239.128.0.0/10 10. Security Considerations While security considerations are not explicitly discussed in this memo, it is important to note that a boundary router as described here should not be considered to provide any kind of firewall functionality. 11. References [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP Multicast", , presented at the 30th IETF, Toronto, Canada, 25 July 1994. [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-03.txt, September, 1996. [PIMDM] Deering, S, et. al., "Protocol Independent Multicast Version 2, Dense Mode Specification", draft-ietf-idmr-pim-dm-05.txt, April, 1997. [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1997. [RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October, 1994. [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing Architecture", RFC1884, December 1995. David Meyer FORMFEED[Page 6] Internet Draft draft-ietf-mboned-admin-ip-space-04.txt May 1997 12. Author's Address David Meyer Advanced Network Technology Center University of Oregon 1225 Kincaid St. Eugene, OR 97403 phone: +1 541.346.1747 email: meyer@antc.uoregon.edu David Meyer FORMFEED[Page 7] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 14:11:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04549; Thu, 15 May 1997 13:13:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04542; Thu, 15 May 1997 13:13:39 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA24620; Thu, 15 May 1997 13:14:55 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA25305 for ; Thu, 15 May 1997 13:15:35 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id NAA13140 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id NAA02899 Posted-Date: Thu, 15 May 1997 13:07:36 -0700 (PDT) Received: from andover.engeast (andover [192.32.174.201]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA08069; Thu, 15 May 1997 16:07:32 -0400 for Date: Thu, 15 May 1997 16:07:32 -0400 From: dhaskin@BayNetworks.COM (Dimitry Haskin) Message-Id: <199705152007.QAA08069@pobox.engeast.BayNetworks.COM> To: daniele@zk3.dec.com Subject: (IPng 3645) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4396 Mike, > > Dimitry, > > > I'm going to try and state the MIB problems succinctly. > (Hopefully this will help the discussion... :-) > > 1) A managed system with multiple interfaces may have the same > (link-local) address configured on multiple interfaces. > > 2) Such a system may communicate (and maintain TCP connections) with > multiple remote systems that have the same (remote, link-local) address. > > The combination of 1) and 2) means the {local-addr, local-port, remote-addr, remote-port} > tuple is not guaranteed to be unique on such managed systems. Hence we need some > mechanism in the MIB for disambiguating these "duplicate" connections. The current spec > solves this by adding ipv6IfIndex to the INDEX: > > INDEX { ipv6IfIndex, > ipv6TcpConnLocalAddress, > ipv6TcpConnLocalPort, > ipv6TcpConnRemAddress, > ipv6TcpConnRemPort } > > The things I'm worried about are > > o forcing ifindex to be looked up for every TCP connection (in the agent) > > the interface we're talking about is the one on which the local > address is configured, right? (The spec is not clear on this.) It is also theoretically possible with site-local addresses. > The interface typically "available" for a connection is the one > associated with the route used to reach the remote address. > For link-local addresses they are the same interface. > For all others they are not guaranteed to be the same interface. > > For 99.9% of all connections ifindex is not required > (since the tuple is already unique). > > o indexing first by ifindex > > seems wrong. Again, it removes any chance of using optimized > lookups. Also, it seems like it would lessen the usefulness > from a manager's perspective. (Find all connections to this socket...) > We'd be changing the "semantics" of the table. > > Would you consider something like this? > > INDEX { ipv6TcpConnLocalAddress, > ipv6TcpConnLocalPort, > ipv6TcpConnRemAddress, > ipv6TcpConnRemPort, > ipv6TcpConnIndex } > > where TcpConnIndex is a non-accessible object used only to > disambiguate otherwise duplicate connections. > > A value of 0 should be returned if there are no duplicates. > Otherwise, the value must be the ipv6IfIndex value corresponding to > the interface on which ipv6TcpConnLocalAddress is configured. > > (Or it could be made to disambiguate LocalAddress only, if that makes > more sense.) > Why would it be better than simply using the Ipv6IfIndex of the LocalAddress as the last index for all connections? INDEX { ipv6TcpConnLocalAddress, ipv6TcpConnLocalPort, ipv6TcpConnRemAddress, ipv6TcpConnRemPort, ipv6IfIndex } It seems that this is more straightforward and it makes the mib agent work simpler. > Same for ipv6UdpTable. > Dito. Btw, the probability of duplicate ipv6UdpLocalAddress/ipv6UdpLocalPort pair is much higher for UDP. The following is a snapshot of udp table indexes from a 6bone router: $ list -i wfIpv6UdpEntry inst_ids = 1.254.128.0.0.0.0.0.0.0.0.0.0.192.32.29.62.521 1.255.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.521 4.254.128.0.0.0.0.0.0.0.0.0.0.192.32.29.62.521 4.255.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.521 5.254.128.0.0.0.0.0.0.0.0.0.0.192.32.29.62.521 5.255.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.521 6.254.128.0.0.0.0.0.0.0.0.0.0.192.32.29.62.521 6.255.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.521 7.254.128.0.0.0.0.0.0.0.0.0.0.192.32.29.62.521 7.255.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.521 8.254.128.0.0.0.0.0.0.0.0.0.0.192.32.29.62.521 8.255.2.0.0.0.0.0.0.0.0.0.0.0.0.0.9.521 ... They are RIPng ports on IPv6-in-IPv4 tunnels. > Thanks, > Mike Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 15:10:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04765; Thu, 15 May 1997 14:16:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04758; Thu, 15 May 1997 14:16:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA07161; Thu, 15 May 1997 14:17:21 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA11198 for ; Thu, 15 May 1997 14:18:02 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA07605; Thu, 15 May 97 14:14:03 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA03370; Thu, 15 May 1997 14:17:22 -0700 Date: Thu, 15 May 1997 14:17:22 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705152117.OAA03370@feller.mentat.com> To: dhaskin@BayNetworks.COM Subject: (IPng 3646) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1173 Dimitry, > Yes, we can.. but the point is that there would be no way to figure out when > the mapping was last updated. Even if there is a finite expiration time, in > my experience, the last update time is more useful. I'll give you a real life > example based on the forwarding table mib: when I see a 5 hours old RIP entry > I know right away that there is a problem (sh.. happens ;) since it should > have been updated within 90 seconds or expire. But if I had the same stale > RIP entry and all I get is that it should expire in 90 seconds determining that > there is a problem would be a challenge. > Ok, I understand why you want the last update time. Do you understand why I want the next expiration? How about a field for each of the last update and the next expiration? 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 Thu May 15 15:47:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04875; Thu, 15 May 1997 14:58:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04868; Thu, 15 May 1997 14:58:03 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA16478; Thu, 15 May 1997 14:59:20 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA22762 for ; Thu, 15 May 1997 15:00:00 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA07836; Thu, 15 May 97 14:56:33 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA03397; Thu, 15 May 1997 14:59:52 -0700 Date: Thu, 15 May 1997 14:59:52 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705152159.OAA03397@feller.mentat.com> To: daniele@zk3.dec.com Subject: (IPng 3647) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1310 Mike, > > Would you consider something like this? > > INDEX { ipv6TcpConnLocalAddress, > ipv6TcpConnLocalPort, > ipv6TcpConnRemAddress, > ipv6TcpConnRemPort, > ipv6TcpConnIndex } > > where TcpConnIndex is a non-accessible object used only to > disambiguate otherwise duplicate connections. > > A value of 0 should be returned if there are no duplicates. > Otherwise, the value must be the ipv6IfIndex value corresponding to > the interface on which ipv6TcpConnLocalAddress is configured. > I would suggest simply using the ipv6IfIndex for all connections which have a link-local ipv6TcpConnLocalAddress. Otherwise the field is returned as 0. > (Or it could be made to disambiguate LocalAddress only, if that makes > more sense.) > > Same for ipv6UdpTable. > With the minor nit above I support this proposal. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 16 05:13:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA05626; Fri, 16 May 1997 04:18:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA05619; Fri, 16 May 1997 04:18:34 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA18758; Fri, 16 May 1997 04:19:47 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA02737 for ; Fri, 16 May 1997 04:19:49 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.5/8.7.3) with ESMTP id NAA04943; Fri, 16 May 1997 13:19:26 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id NAA03797; Fri, 16 May 1997 13:19:24 +0200 (MET DST) Message-Id: <199705161119.NAA03797@givry.inria.fr> From: Francis Dupont To: "David M. Meyer" cc: ipng@sunroof.eng.sun.com, meyer@antc.uoregon.edu Subject: (IPng 3648) Re: RFC 1884 multicast scope naming In-reply-to: Your message of Thu, 15 May 1997 10:35:03 PDT. <199705151735.KAA21025@network-services.uoregon.edu> Date: Fri, 16 May 1997 13:19:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1725 In your previous mail you wrote: The Administratively Scoped IP Multicast draft (produced in the MBONED WG) is attempting to create a loose mapping between the SCOPs and the IPv4 multicast scope classes. We currently have the table IPv6 SCOP RFC 1884 Description IPv4 Prefix ================================================================== 0 reserved 1 node-local scope 2 link-local scope 224.0.0.0/24 3 (unassigned) 239.255.0.0/16 4 (unassigned) 5 site-local scope 6 (unassigned) 7 (unassigned) 8 organization-local scope 239.192.0.0/14 A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope 224.0.1.0-238.255.255.255 F reserved => I believe you should add a scope for large-structures (cf the GSE proposal (the new one is not yet available) and draft-dupont-ipv6-gse-multicast-00.txt). 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 Fri May 16 09:34:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06069; Fri, 16 May 1997 09:25:59 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06062; Fri, 16 May 1997 09:25:52 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05182; Fri, 16 May 1997 09:27:21 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12943; Fri, 16 May 1997 09:26:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06037; Fri, 16 May 1997 09:22:06 -0700 Received: from mars.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA10549; Fri, 16 May 1997 09:23:19 -0700 Received: from incog.com (ns.incog.com [199.190.177.251]) by mars.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA25530 for ; Fri, 16 May 1997 09:25:37 -0700 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id JAA21313; Fri, 16 May 1997 09:25:56 -0700 Received: from frob.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id JAA24824; Fri, 16 May 1997 09:23:37 -0700 Message-Id: <3.0.32.19970516135431.006ffc0c@osmosys.incog.com> X-Sender: eguttman@osmosys.incog.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 16 May 1997 18:23:09 -0700 To: ipng@sunroof.eng.sun.com From: Erik Guttman Subject: (IPng 3650) WG Last call on draft-ietf-svrloc-ipv6-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1410 I am cross posting this message on the IPv6 mailing list as it should really be reviewed by that community. I am not on this list so please reply to the WG last call with comments to the Service Location mailing list. >To: srvloc@corp.home.net From: Erik Guttman >Subject: WG Last call on draft-ietf-svrloc-ipv6-01.txt > > >The draft: > > Service Location Modifications for IPv6 > draft-ietf-svrloc-IPv6-01.txt > >Is now in Working Group last call. If you have any comments on this >draft, or concerns why it should not be submitted to the IESG to be >considered as a proposed standard RFC document, please respond to the >service location mailing list (srvloc@corp.home.net) by May 30, 1997. > If you have any questions about the Service Location Protocol itself, please refer to the SLP spec (draft-ietf-svrloc-protocol-17.txt) and if they are still unanswered please feel free to send me mail directly. Erik Guttman SVRLOC WG Chair Sun Microsystems, 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 May 16 13:52:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA06282; Fri, 16 May 1997 13:43:54 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA06275; Fri, 16 May 1997 13:43:50 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26989; Fri, 16 May 1997 13:45:21 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13303; Fri, 16 May 1997 13:44:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA06228; Fri, 16 May 1997 12:59:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA00639; Fri, 16 May 1997 13:00:15 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA21440 for ; Fri, 16 May 1997 13:01:01 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id NAA25133 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id NAA00997 Posted-Date: Fri, 16 May 1997 13:00:27 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA05776; Fri, 16 May 1997 16:00:28 -0400 for Message-Id: <3.0.32.19970516155908.006b4f28@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 16 May 1997 15:59:08 -0400 To: thartric@mentat.com (Tim Hartrick) From: Dimitry Haskin Subject: (IPng 3652) Re: ICMPv6 mib q.. Cc: dhaskin@BayNetworks.COM, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1833 At 02:17 PM 5/15/97 -0700, Tim Hartrick wrote: > > >Dimitry, > >> Yes, we can.. but the point is that there would be no way to figure out when >> the mapping was last updated. Even if there is a finite expiration time, in >> my experience, the last update time is more useful. I'll give you a real life >> example based on the forwarding table mib: when I see a 5 hours old RIP entry >> I know right away that there is a problem (sh.. happens ;) since it should >> have been updated within 90 seconds or expire. But if I had the same stale >> RIP entry and all I get is that it should expire in 90 seconds determining that >> there is a problem would be a challenge. >> > >Ok, I understand why you want the last update time. Do you understand why >I want the next expiration? How about a field for each of the last update >and the next expiration? > Ok, if you think that both are needed. I thought it would be easy to figure out the expiration time if the last update was known and therefore having both attribute would be somewhat redundant. >tim Dimitry >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 16 13:56:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA06291; Fri, 16 May 1997 13:46:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA06284; Fri, 16 May 1997 13:46:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA10034; Fri, 16 May 1997 13:47:31 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA04141 for ; Fri, 16 May 1997 13:48:15 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA14439; Fri, 16 May 97 13:44:49 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA04622; Fri, 16 May 1997 13:48:13 -0700 Date: Fri, 16 May 1997 13:48:13 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705162048.NAA04622@feller.mentat.com> To: ddinelli@BayNetworks.COM Subject: (IPng 3653) Re: ICMPv6 mib q.. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 757 Dimitry, > Ok, if you think that both are needed. I thought it would be easy to > figure out the expiration time if the last update was known and therefore > having both attribute would be somewhat redundant. > Frankly, I have become a little nauseous discussing all this MIB stuff.:-) I will leave this one to your discretion. Either value should suffice I think. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 16 18:11:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA00295; Fri, 16 May 1997 18:03:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA00288; Fri, 16 May 1997 18:03:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA26694; Fri, 16 May 1997 18:04:40 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA04791 for ; Fri, 16 May 1997 18:05:26 -0700 Received: from spruce.betham.org (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA00585; Fri, 16 May 1997 18:04:57 -0700 Message-Id: <3.0.1.32.19970516180547.0077b6e0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 16 May 1997 18:05:47 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3654) New IPv6 Addressing Drafts Cc: Bob Hinden Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1584 I just submitted three new IPv6 addressing related internet drafts. They should appear next week. In general these drafts reflect the changes agreed to at the last IPng meeting. The drafts are: "IP Version 6 Addressing Architecture" Changes include adding IPv6 prefix notation, change to solicited node multicast address definition, added site scope all routers multicast address, defined FP for Aggregatable Unicast address, removed provider and geographic FP's, added EUI-64 interface id definition rules, and a number of smaller changes. Complete list of changes at end of draft. "An IPv6 Aggregatable Global Unicast Address Format" New draft which defines Aggregatable Global Unicast address format to replace RFC 2073. "IPv6 Multicast Address Assignments" Minor update to reflect solicited multicast address definition change. Bob p.s. If you can't wait for the internet drafts to come out via the normal channel, you can find them at: ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-addr-arch-00.txt ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-unicast-aggr-00.txt ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-multicast-assgn-02.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 Fri May 16 18:50:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA00345; Fri, 16 May 1997 18:42:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA00338; Fri, 16 May 1997 18:41:54 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA00510; Fri, 16 May 1997 18:43:08 -0700 Received: from brittany.cisco.com (brittany.cisco.com [171.69.1.168]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA10344 for ; Fri, 16 May 1997 18:43:54 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by brittany.cisco.com (8.6.12/8.6.5) with ESMTP id SAA27542; Fri, 16 May 1997 18:43:25 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id SAA10908; Fri, 16 May 1997 18:38:07 -0700 (PDT) Date: Fri, 16 May 1997 18:38:07 -0700 (PDT) Message-Id: <199705170138.SAA10908@pedrom-ultra.cisco.com> From: Pedro Marques To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3655) New IPv6 Addressing Drafts In-Reply-To: <3.0.1.32.19970516180547.0077b6e0@mailhost.ipsilon.com> References: <3.0.1.32.19970516180547.0077b6e0@mailhost.ipsilon.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1379 >>>>> "Bob" == Bob Hinden writes: Bob> I just submitted three new IPv6 addressing related internet Bob> drafts. They should appear next week. In general these Bob> drafts reflect the changes agreed to at the last IPng Bob> meeting. The drafts are: Bob> "IP Version 6 Addressing Architecture" Bob> Changes include adding IPv6 prefix notation, change to Bob> solicited node multicast address definition, added site scope Bob> all routers multicast address, defined FP for Aggregatable Bob> Unicast address, removed provider and geographic FP's, added Bob> EUI-64 interface id definition rules, and a number of smaller Bob> changes. Complete list of changes at end of draft. Bob, can we have Provider Based Addresses back ? It would be nice to keep an addresses space without EUI-64. It would also probably encorage people not to use non globally unique addresses in the "Aggregatable Unicast" address space. thanks, ./Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 18 10:50:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01427; Sun, 18 May 1997 10:42:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01420; Sun, 18 May 1997 10:42:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA25872; Sun, 18 May 1997 10:44:09 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA17068 for ; Sun, 18 May 1997 10:44:45 -0700 Received: from spruce.betham.org (maxdialin5.Ipsilon.COM [205.226.20.235]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA15379; Sun, 18 May 1997 10:43:43 -0700 Message-Id: <3.0.1.32.19970518104147.00701174@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sun, 18 May 1997 10:41:47 -0700 To: Pedro Marques From: Bob Hinden Subject: (IPng 3656) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199705170138.SAA10908@pedrom-ultra.cisco.com> References: <3.0.1.32.19970516180547.0077b6e0@mailhost.ipsilon.com> <3.0.1.32.19970516180547.0077b6e0@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 840 Pedro, >can we have Provider Based Addresses back ? It would be nice to keep an >addresses space without EUI-64. It would also probably encorage people >not to use non globally unique addresses in the "Aggregatable Unicast" >address space. That was not what was agreed to at the Palo Alto (interim) and Memphis meetings. I think the new (aggregatable) format is a big improvement over the provider format and it would be very confusing to have both. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 18 13:57:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA01568; Sun, 18 May 1997 13:50:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA01561; Sun, 18 May 1997 13:50:00 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA05557; Sun, 18 May 1997 13:51:26 -0700 Received: from relay6.UU.NET (relay6.UU.NET [192.48.96.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA01570 for ; Sun, 18 May 1997 13:52:02 -0700 Received: from rodan.UU.NET by relay6.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQcqcp00797; Sun, 18 May 1997 16:51:45 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcqcp28129; Sun, 18 May 1997 16:51:29 -0400 (EDT) Message-Id: To: Bob Hinden cc: Pedro Marques , ipng@sunroof.eng.sun.com Subject: (IPng 3657) Re: New IPv6 Addressing Drafts In-reply-to: Your message of "Sun, 18 May 1997 10:41:47 PDT." <3.0.1.32.19970518104147.00701174@mailhost.ipsilon.com> Date: Sun, 18 May 1997 16:51:29 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 464 it would be worse than confusing to have both; it would be a Bad Idea to have both. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 07:15:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02090; Mon, 19 May 1997 07:07:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02083; Mon, 19 May 1997 07:07:30 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA02953; Mon, 19 May 1997 07:08:56 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA19761 for ; Mon, 19 May 1997 07:09:32 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id KAA02589; Mon, 19 May 1997 10:08:48 -0400 Date: Mon, 19 May 1997 10:08:48 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9705191008.ZM2587@seawind.bellcore.com> In-Reply-To: "Mike O'Dell" "(IPng 3657) Re: New IPv6 Addressing Drafts" (May 18, 4:51pm) References: X-Mailer: Z-Mail (3.2.1 10oct95) To: "Mike O'Dell" , Bob Hinden Subject: (IPng 3658) Re: New IPv6 Addressing Drafts Cc: Pedro Marques , ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 884 I think the "aggregatable" denomination is more adequate than the "provider based" one. I have however a practical concern with the EUI-64 interface id. This is a brand new numbering space. What happens for old computers and boards that do not enjoy the priviledge of having one ? I suspect there is some way to derive a valid EUI-64 ID from an existing IEEE 802 48 bit address. Could we make it explicit in the documentation, perhaps in an appendix to the addr arch document ? -- 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 May 19 09:07:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02229; Mon, 19 May 1997 08:59:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA02222; Mon, 19 May 1997 08:59:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA27380; Mon, 19 May 1997 09:00:34 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA18907 for ; Mon, 19 May 1997 09:01:08 -0700 Received: from gungnir.fnal.gov ("port 42530"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IJ1UAYOKF20005AO@FNAL.FNAL.GOV>; Mon, 19 May 1997 10:38:21 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA28321; Mon, 19 May 1997 10:36:28 -0500 Date: Mon, 19 May 1997 10:36:28 -0500 From: Matt Crawford Subject: (IPng 3659) Re: New IPv6 Addressing Drafts In-reply-to: "18 May 1997 16:51:29 EDT." <"QQcqcp28129.199705182051"@rodan.UU.NET> To: Pedro Marques , ipng@sunroof.eng.sun.com Message-id: <199705191536.KAA28321@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ It would be nice to keep an addresses space without EUI-64. Do you dislike EUI-64, or do you just want more topology bits? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 09:28:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02282; Mon, 19 May 1997 09:18:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02275; Mon, 19 May 1997 09:18:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA01340; Mon, 19 May 1997 09:20:19 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA24663 for ; Mon, 19 May 1997 09:20:53 -0700 Received: from spruce.betham.org (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA13374; Mon, 19 May 1997 09:19:48 -0700 Message-Id: <3.0.1.32.19970519092036.00762054@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 19 May 1997 09:20:36 -0700 To: huitema@bellcore.com (Christian Huitema) From: Bob Hinden Subject: (IPng 3661) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9705191008.ZM2587@seawind.bellcore.com> References: <"Mike O'Dell" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1516 Christian, >I think the "aggregatable" denomination is more adequate than the >"provider based" one. I have however a practical concern with the EUI-64 >interface id. This is a brand new numbering space. What happens for old >computers and boards that do not enjoy the priviledge of having one ? The procedure to create an EUI-64 from an IEEE 48bit MAC address is defined in the reference to EUI-64: [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. >I suspect there is some way to derive a valid EUI-64 ID from an existing >IEEE 802 48 bit address. Could we make it explicit in the documentation, >perhaps in an appendix to the addr arch document ? I think it is better to not duplicate the definition, but will expand the text to mention that the reference includes this case. It might also be useful to have an appendix which provides some examples including creating them for interfaces which do not have hardware identifiers (tunnels, serial interfaces, local talk, etc.). Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 10:04:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02414; Mon, 19 May 1997 09:55:46 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02403; Mon, 19 May 1997 09:55:40 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA12124; Mon, 19 May 1997 09:57:15 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17657; Mon, 19 May 1997 09:56:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02231; Mon, 19 May 1997 09:06:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA28985; Mon, 19 May 1997 09:08:16 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA21171 for ; Mon, 19 May 1997 09:08:50 -0700 Received: from gungnir.fnal.gov ("port 42534"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IJ1UWG494O0005AO@FNAL.FNAL.GOV>; Mon, 19 May 1997 10:55:42 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA28380; Mon, 19 May 1997 10:53:46 -0500 Date: Mon, 19 May 1997 10:53:46 -0500 From: Matt Crawford Subject: (IPng 3662) Re: New IPv6 Addressing Drafts In-reply-to: "19 May 1997 10:08:48 EDT." <"9705191008.ZM2587"@seawind.bellcore.com> To: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com Message-id: <199705191553.KAA28380@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ EUI64 mapping. Since the IETF doesn't have change control over those address formats, this and the v6-over-foo documents may be all the material we should properly include. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 13:12:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA02740; Mon, 19 May 1997 13:02:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA02733; Mon, 19 May 1997 13:02:46 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA28386; Mon, 19 May 1997 13:04:12 -0700 Received: from mailhost2.BayNetworks.COM ([134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA02759 for ; Mon, 19 May 1997 13:04:46 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id MAA21939 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id NAA01820 Posted-Date: Mon, 19 May 1997 13:03:38 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA29795; Mon, 19 May 1997 16:03:41 -0400 for Message-Id: <3.0.32.19970519160227.006c562c@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 19 May 1997 16:02:28 -0400 To: Bob Hinden From: Dimitry Haskin Subject: (IPng 3663) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1182 Bob, Steve, I'd like see a clarification on how the scope of an interface id is affected when the same unique L2 address is used to derive IDs for multiple interfaces of the same node. In a strict interpretation of the draft, if more than one interface of the same node use the same build-in IEEE address to form their interface IDs (e.g., a serial interface "borrows" an IEEE address of a Ethernet interface), all such interfaces except one should be treated as of local scope. On the other hand it may appear that for the purpose of the "future technology that can take advantage of identifiers with global scope" it may be sufficient that such interfaces belong to the same node (I don't have any prove to support such a claim) -- in which case they all can be treated as of global scope. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 20 02:03:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA00428; Tue, 20 May 1997 01:55:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA00421; Tue, 20 May 1997 01:55:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA11853; Tue, 20 May 1997 01:57:11 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA29538 for ; Tue, 20 May 1997 01:57:44 -0700 From: Masataka Ohta Message-Id: <199705200852.RAA07363@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA07363; Tue, 20 May 1997 17:52:37 +0900 Subject: (IPng 3664) Re: New IPv6 Addressing Drafts To: dhaskin@BayNetworks.COM (Dimitry Haskin) Date: Tue, 20 May 97 17:52:35 JST Cc: hinden@Ipsilon.COM, ipng@sunroof.eng.sun.com In-Reply-To: <3.0.32.19970519160227.006c562c@pobox>; from "Dimitry Haskin" at May 19, 97 4:02 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1007 Dimitry; > I'd like see a clarification on how the scope of an interface id is > affected when the same unique L2 address is used to derive IDs for multiple > interfaces of the same node. In a strict interpretation of the draft, if > more than one interface of the same node use the same build-in IEEE address > to form their interface IDs (e.g., a serial interface "borrows" an IEEE > address of a Ethernet interface), all such interfaces except one should be > treated as of local scope. No, it is not necessary. Your observation merely means that what you call an interface id is actually a host id. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 20 07:21:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00696; Tue, 20 May 1997 07:10:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00681; Tue, 20 May 1997 07:09:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA12392; Tue, 20 May 1997 07:11:15 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA27280 for ; Tue, 20 May 1997 07:11:54 -0700 Received: from ietf.ietf.org by ietf.org id aa28623; 20 May 97 9:47 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3665) I-D ACTION:draft-ietf-ipngwg-unicast-aggr-00.txt Date: Tue, 20 May 1997 09:47:19 -0400 Message-ID: <9705200947.aa28623@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4205 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : An IPv6 Aggregatable Global Unicast Address Format Author(s) : R. Hinden, M. O'Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-00.txt Pages : 9 Date : 05/19/1997 This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing Architecture" [ARCH]. It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast Address Format". RFC 2073 will become historic. 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]. Internet-Drafts are 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-unicast-aggr-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-aggr-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970519133343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-aggr-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970519133343.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 20 07:21:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00697; Tue, 20 May 1997 07:10:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA00685; Tue, 20 May 1997 07:09:54 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA12384; Tue, 20 May 1997 07:11:14 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA27273 for ; Tue, 20 May 1997 07:11:52 -0700 Received: from ietf.ietf.org by ietf.org id aa28622; 20 May 97 9:47 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3666) I-D ACTION:draft-ietf-ipngwg-multicast-assgn-02.txt Date: Tue, 20 May 1997 09:47:29 -0400 Message-ID: <9705200947.aa28622@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4418 --NextPart A Revised 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 Multicast Address Assignments Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-multicast-assgn-02.txt Pages : 9 Date : 05/19/1997 This document defines the initial assignment of IPv6 multicast addresses. It is based on the "IP Version 6 Addressing Architecture" [ADDARCH] and current IPv4 multicast address assignment found in . It adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4 assignments that were not relevant were not converted into IPv6 assignments. Comments are solicited on this conversion. All other IPv6 multicast addresses are reserved. Sections 2 and 3 specify reserved and preassigned IPv6 multicast addresses. Section 4 defines guidelines for assigning new IPv6 multicast 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]. Internet-Drafts are 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-multicast-assgn-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-02.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970519133845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-multicast-assgn-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970519133845.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 07:54:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02261; Wed, 21 May 1997 07:45:51 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA02254; Wed, 21 May 1997 07:45:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA05346; Wed, 21 May 1997 07:47:02 -0700 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA19796 for ; Wed, 21 May 1997 07:47:43 -0700 Received: by mail.noris.net id <34981-3718>; Wed, 21 May 1997 16:47:06 +0200 Path: noris.net!not-for-mail From: smurf@work.smurf.noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 3668) Re: New IPv6 Addressing Drafts Date: 21 May 1997 16:46:45 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 28 Message-ID: <5lv1sl$abf$1@work.smurf.noris.de> References: <9705191008.ZM2587@seawind.bellcore.com> <3.0.1.32.19970519092036.00762054@mailhost.ipsilon.com> <864060006.17538@noris.de> NNTP-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Xref: noris.net dist.ipng:1893 To: unlisted-recipients:;@mail.noris.net (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1711 Bob Hinden writes: > > >IEEE 802 48 bit address. Could we make it explicit in the documentation, > >perhaps in an appendix to the addr arch document ? > > I think it is better to not duplicate the definition, but will expand the > text to mention that the reference includes this case. It might also be For the record, I dislike references in RFCs which happen to point to documents that are not, or may not be, available online from the same place where the RFCs themselves are kept. > useful to have an appendix which provides some examples including creating > them for interfaces which do not have hardware identifiers (tunnels, serial > interfaces, local talk, etc.). > Make that an informational/BCP/whatever RFC which also happens to discuss how to build an EID from an 48-bit MAC address. -- A Lisp programmer knows the value of everything, but the cost of nothing. -- Alan Perlis -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 09:48:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02523; Wed, 21 May 1997 09:35:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02516; Wed, 21 May 1997 09:35:18 -0700 From: zazoo@step.polymtl.ca Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA00982; Wed, 21 May 1997 09:36:40 -0700 Received: from step.polymtl.ca (step.polymtl.ca [132.207.4.32]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA23301 for ; Wed, 21 May 1997 09:37:21 -0700 Received: from slip01.slip.polymtl.ca (Cloclo@ts-2-12.slip.polymtl.ca [132.207.14.12]) by step.polymtl.ca (8.8.5/8.6.10) with SMTP id MAA21534 for ; Wed, 21 May 1997 12:35:23 -0400 (EDT) Message-ID: <338333FB.5F3B@step.polymtl.ca> Date: Wed, 21 May 1997 12:42:19 -0500 X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 3669) RFCs and standards Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1117 Hello For all....i m new at this....i m a student finnishing my baccalaureate degree in electrical engineering..and my final project is a research about everything related to IPv6. My FIRST question is : are the RFCs 1884 (IPv6 addressing architecture), 1886(DNS extensions to support IPv6) and 1887(An architecture for Ipv6 Unicast address allocation ) standards or just RFCs ? My SECOND question : plz...can someone tell me which RFCs related to IPv6 are standards...and which are not ? I hope someone can help me with this..cause i m totally new at this..and i m confused...i dont know which documents are standards..and wich arent :( and thanks a bunch..for everyone ou will help me :) have a nice day..and thanks in advance Zack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 11:21:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02772; Wed, 21 May 1997 11:13:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02765; Wed, 21 May 1997 11:12:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA26501; Wed, 21 May 1997 11:14:12 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA23995 for ; Wed, 21 May 1997 11:14:56 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id LAA29390 for ; Wed, 21 May 1997 11:14:24 -0700 Message-Id: <3.0.1.32.19970521111506.00eefeac@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 11:15:06 -0700 To: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org (by way of Bob Hinden ) Subject: (IPng 3670) I-D ACTION:draft-ietf-ipngwg-addr-arch-v2-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3176 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-00.txt Pages : 21 Date : 05/19/1997 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 nodes required addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v2-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 12:05:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02810; Wed, 21 May 1997 11:57:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02803; Wed, 21 May 1997 11:56:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA06943; Wed, 21 May 1997 11:58:19 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA08190 for ; Wed, 21 May 1997 11:59:01 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 21 May 1997 14:56:57 -0400 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Cc: "'zazoo@step.polymtl.ca'" Subject: (IPng 3671) RE: RFCs and standards Date: Wed, 21 May 1997 14:56:54 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1974 Hi Zack, > My FIRST question is : are the RFCs 1884 (IPv6 addressing architecture), > 1886(DNS extensions to support IPv6) and 1887(An architecture for Ipv6 > Unicast address allocation ) standards or just RFCs ? One way to answer to your question is: yes and no. The RFC's you reference are "Standards Track" documents at the first level of the process, Proposed Standard. This indicates that the working group and IESG have agreed that they have been well reviewed, and need further work before moving to the next level, which would be Draft Standard. A document which becomes a Draft Standard may be worked upon further, and may eventually become an Internet Standard. But there is no guarantee that any work which starts off down the standards track will come out at the end as an Internet Standard. You might want to check out RFC 2026, which I believe is the most recent compilation of the IETF processes. Also, the Tao of the IETF (RFC 1718) is good background info. You can find all this and much more at http://www.ietf.org. > My SECOND question : plz...can someone tell me which RFCs related to > IPv6 are standards...and which are not ? None are Internet Standards (yet). Several are Proposed Standards, some are Informational, and I think there are a couple of Experimental RFC's out there as well. You can check the status in the current RFC index file, ftp://ds.internic.net/rfc/rfc-index.txt, although for your focus you might want to check the IPng home page (the link is automatically appended to all mail messages to this list, so look down below.) Good luck, Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 15:29:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03116; Wed, 21 May 1997 15:19:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03109; Wed, 21 May 1997 15:18:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA22069; Wed, 21 May 1997 15:20:16 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA08856 for ; Wed, 21 May 1997 15:21:00 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA11908; Wed, 21 May 1997 15:19:56 -0700 Message-Id: <3.0.1.32.19970521152042.00b294c4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 21 May 1997 15:20:42 -0700 To: Dimitry Haskin From: Bob Hinden Subject: (IPng 3672) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.32.19970519160227.006c562c@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1681 Dimitry, >I'd like see a clarification on how the scope of an interface id is >affected when the same unique L2 address is used to derive IDs for multiple >interfaces of the same node. In a strict interpretation of the draft, if >more than one interface of the same node use the same build-in IEEE address >to form their interface IDs (e.g., a serial interface "borrows" an IEEE >address of a Ethernet interface), all such interfaces except one should be >treated as of local scope. On the other hand it may appear that for the >purpose of the "future technology that can take advantage of identifiers >with global scope" it may be sufficient that such interfaces belong to the >same node (I don't have any prove to support such a claim) -- in which case >they all can be treated as of global scope. Assuming I understand your question, I think that as long as it is allowed by the IPv6 over PPP specification (in the case you mention), I don't think there should be any problem treating all of the interfaces formed this way to have global scope. With current transport protocols the whole address is used and are treated separately. In future transports I would think this is just the behavior that is desired (e.g., look at the interface IDs and be able to tell it all on the same node). 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 Wed May 21 18:08:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA03516; Wed, 21 May 1997 17:58:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA03509; Wed, 21 May 1997 17:58:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA26436; Wed, 21 May 1997 18:00:04 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA19398 for ; Wed, 21 May 1997 18:00:28 -0700 Received: from mailhost.BayNetworks.COM (ns1.baynetworks.com [134.177.1.107]) by mailhost3.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id VAA24722 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id RAA00872 Posted-Date: Wed, 21 May 1997 17:52:03 -0700 (PDT) Received: from dhaskin.baynetworks.com (eng_ppp22 [192.32.171.162]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA16231; Wed, 21 May 1997 20:52:02 -0400 for Message-Id: <3.0.32.19970521205306.006a90b0@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 21 May 1997 20:53:08 -0400 To: Bob Hinden , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 3673) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1188 Bob, > >Assuming I understand your question, I think that as long as it is allowed >by the IPv6 over PPP specification (in the case you mention), I don't think >there should be any problem treating all of the interfaces formed this way >to have global scope. With current transport protocols the whole address >is used and are treated separately. In future transports I would think >this is just the behavior that is desired (e.g., look at the interface IDs >and be able to tell it all on the same node). > Ok, let me reiterate: the same global scope interface id can be assigned to multiple interfaces on the same node. I think this is an important architectural point that should be clearly stated in the addressing spec. >Bob Dimitry P.S. The IPv6/PPP spec will allow what I'll make it to allow ;) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 18:55:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA03587; Wed, 21 May 1997 18:46:01 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA03580; Wed, 21 May 1997 18:45:50 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA14472; Wed, 21 May 1997 18:47:28 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA04803; Wed, 21 May 1997 18:47:27 -0700 Date: Wed, 21 May 1997 18:47:27 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199705220147.SAA04803@bobo.eng.sun.com> To: rstevens@kohala.com, mattthomas@earthlink.net Subject: (IPng 3674) Comments on advance API draft Cc: nordmark@jurassic, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 14914 Here are a few :-) long overdue comments on the advanced API draft. The issues range from the scope (should it support tcpdump applications?), security issues with source addresses, and nits like names and name space issues. Finally (for those that get to the end) there are some rough suggestions for APIs for UDP path mtu discovery and NUD reachability confirmations. The scope: ---------- I think it would be good to extend the draft to provide enough header definitions so that a tcpdump like program could be portable to the systems that implement the API. I *think* the only thing that is missing is a definition of the fragmentation extension headers (unless you also want to include AH and ESP headers for the benefit of tcpdump portability.) It is not clear to me what to intended scope is for raw sockets. Raw sockets are used by two types of applications: - Non-TCP/UDP protocols like ICMP, OSPF, etc. These typically use socket(,SOCK_RAW, IPPROTO_something) and expect a "not so raw socket". - Testing applications like traceroute that want to control every piece of the packet. These typilcally use socket(,SOCK_RAW, IPPROTO_RAW) or set the IP_HDRINCL option in IPv4. Does the document intend to cover both of them? The text in section 3 (5th paragraph) seems to imply that the scope is only the former while pointing out that the socket options plus the ancillary data can be used to reimplement tools like traceroute. Is my understanding correct? If this is the intended scope it might make sense to clarify that section to state that "All fields in the IPv6 ... can be modified *using ancillary data and/or socket options* by the application." Also, it would make sense to point out that is either not supported on IPv6 or that it just uses payload type = 255. Finally, does a raw socket automatically insert fragmentation headers when the application sends something larger than the path MTU? I assume (although it is not stated anywhere to my knowledge) that UDP does this. But the raw socket case needs to be stated since different implementors and different users might have different perspectives on how raw a raw socket really is. Security: --------- In IPv4 an application can not use UDP or TCP sockets to send packets with a bogus source address. The mechanism specified in section 5.2 allows an application to specify any source address when sending data. Thus I think we need to require in section 5.2 that the kernel verify that the source address is indeed a unicast address assigned to the machine. (Folks might argue if it should also verify that it is assigned to the outgoing interface but let's avoid that rat hole for now.) Unclear things: --------------- Section 3.1 specifies how a raw socket can be told to compute checksums on transmit but it does not state if the kernel will verify checksums on receipt. Please clarify in the document. The ping filter example in section 3.2 is probably confusing since a ping program would be interested in seeing various ICMP error messages in addition to the ICMP echo responses. How about using an example that only receives router advertisement messages as an example instead or "fix" the ping example? What is the ND6_OPT_ENDOFLIST=256 in section 2.2.2? A comment in the declaration might be useful. When using raw sockets I assume the application receives the IP header as part of the data just like in IPv4. But how does it receive any extension headers? As part of the data (i.e. the data is the packet as it arrived on the wire) or as ancillary data with recvmsg subject to enabling the socket options (like for UDP)? Section 4.4 and 4.5 specifies how I can set options (either per send or for the socket). If I've set options with IPV6_PKTOPTIONS how can I clear them? (For instance, I've used a routing header with TCP but no longer want to use it.) I've seen various option specific rules (in6_addrany for the source address, 0 for the interface index, -1 for the hoplimit) but I don't see how to turn off hop-by-hop options, destination options, or routing headers. Should there be a generic mechanism for turning things off? For instance, if I send down a IPV6_DSTOPTS with zero length of data in a IPV6_PKTOPTIONS it could remove whatever destination option was previously set. Section 4.5 states that the most recently received options can be retrieved using IPV6_PKTOPTIONS. For performance reasons I don't want TCP to always store away this info from every segment if nobody is interested in it. Thus shouldn't the document state that IPV6_PKTOPTIONS only retrieves the components that TCP has been enabled to receive (using setsockopt) prior to the segment arrives? The use of ancillary data with TCP to send options/extensions in section 4.5 strikes me as odd since there is not a one-to-one correspondence between sendmsg calls and tcp segments on the wire. Furthermore, a TCP implementation might packetize the data differently when retransmitting data than the first time it was transmitted. This could be the case e.g. if the receiver decreases the right window edge. How about simplifying things to only have TCP handle a setsockopt with IPv6_PKTOPTIONS? I think it would remove a bunch of extra checks and make TCP faster. The rules for "sticky" options are specified in section 4.5. Does this mean that IPV6_PKTOPTIONS and "sticky" options only apply to TCP? If they apply to UDP then the text is in the wrong section. In any case, the rules for "sticky" options version the ancillary data options seem complex. What is the motivation for these rules? Can we get away with something simpler? (both simpler to explain to the poor socket programmer and simpler to implement.) Section 5.5 specifies new errors for sendmsg. Presumably they also apply to setsockopt(IPV6_PKTOPTIONS). But, more importantly there is a class of implementations (such as STREAMS based implementations) where sendmsg can not return any errors from the IP layer. Thus it might make sense to point out that "additional errors might occur on some implementations" or something like it. The document talks about priority (and this is also a "feature" of RFC 2133). Should we remove any mention of priority? The second (and 4th) bullet in section 6 talks about uniqueness of flow labels. Don't they also have to be unique for a given routing header and hop-by-hop options header? It is not clear to me how to implement inet6_flow_free (section 6.2). Do I have to avoid reusing the flow label for an additional 6 seconds? If so it would make sense to state that in the document. In section 6, 7.3 and 9 the specification states that inet6_* functions have prototypes in . Is this intentional? The inet_* functions for IPv4 have their prototypes in . In section 9.5 it claims that inet6_srcrt_reverse() returns either zero or an errno. None of the standard socket functions have this behavior of returning an errno - they return -1 (or perhaps NULL in some cases) and sets the errno variable to the error number. The same is true for inet6_srcrt_add. Can we make them (and any others) a little more consistent in this respect? Missing things: -------------- Would it be useful to declare an ND option header structure in section 2.2.2 containing just the type and the length. It could then be used for the defined prefix and mtu options but also for the link-layer address option which currently does not have a structure definition. In section 2.4 you only define names for "ipv6" and "icmpv6". How about fragmentation, "no extension hdr" and all the other extension headers? (Just make sure that the names match with what is registered with the IANA.) Name space issues: ------------------ When this document goes to Posix there are likely to be some name space constraints added e.g. when including it defines only names that start with the prefixes "icmp6_", "ICMPv6_", etc. The reason this is done to the standards is so that the applications know what part of the name space they can use. For instance, an application might want to have #define data "test" #include However, the example icmp6_filter definition in section 3.2 uses the "data" part of the name space. Thus in order to avoid multiple versions of these definitions as it moves though some API standards body it would make sense to think about these issues up front. One approach to resolving these issues is to add an "_" to the front of the name since that part of the name space is reserved for the implementation. (This might be appropriate for the icmp6_filter definition.) Another approach is to make sure that all declarations have reasonable prefixes as part of their name. For example the fields in the nd6_opt_prefix_info and nd6_opt_mtu structures currently start with opt_ and it would make sense to instead name them something like nd6_pi_ and nd6_mtu_ (or nd6_opt_pi_ and nd6_opt_mtu). Other cases are not so clear such as the "internal" field names starting with ctl6_ and un_ in the ip6_hdr definition. They could either get an "_" added to the front or an "ip6_" added. The set of prefixes I've seen that can cause name space problems are: data ctl6_ un_ rsol_ (how about nd6_rs_ ?) radv_ (how about nd6_ra_ ?) nsol6_ (how about nd6_ns_ ?) nadv6_ (how about nd6_na_ ?) redirect_ (how about nd6_rd_ ?) opt_ (see above) opt_ in section 7.3.7 example Choice of names: ---------------- If a novice socket programmer reads this document I'm concerned that they will be confused by the choice of names. For instance, some names have a "6" appended whereas others have a "V6" appended. A grep through RFC 2133 shows that the "V6" convention is only used for IPv6 options (IPPROTO_IPV6 level and IPV6_* option names). What is the convention for the advanced API that can help un-confuse my novice programmer? The document uses "ND6" and "nd6" (although not consistently - there is an rsol_hdr and a nsol6_header). Since there is no ND for IPv4 wouldn't it be simpler to just drop the "6"? Also, while we are on the subject of ND I notice that the type name is e.g. ND6_ROUTER_ADVERTISEMENT and the structure name is nd6_router_advert. How about using the shorter "advert" and "solicit" throughout? The neighbor advert/solicit are called nd6_nadvertisement and nd6_nsolicitation which again is inconsistent with the ICMP type name. How about nd_neighbor_advert/solicit? Or if you want really short names you could use nd_{na,ns,ra,rs,rd} for the packet format structures. The IGMP type names in IPv4 are IGMP_MEMBERSHIP_REPORT. In the specification this is called ICMPV6_MGM_REPORT. Do we really need the new "MGM" acronym just to make IPv6 look more different than IPv4? Or could we handle an ICMP6_MEMBERSHIP_REPORT name? (It is only one character longer than the IPv4 name.) There are some abbreviated names which do not (in my eyes) match the full name. I realize that there is a tradeoff between short and clear names but I think we can do a little better. (Please ignore my presumption that "V6" gets changed to "6" in the suggestions below.) Examples: Full name Current definition Proposal ICMP packet too big ICMPV6_PACKET_TOOBIG ICMP6_PACKET_TOO_BIG ICMP parameter problem ICMPV6_PARAMPROB ICMP6_PARAM_PROB ICMP echo request ICMPV6_ECHOREQUEST ICMP6_ECHO_REQUEST ICMP echo reply ICMPV6_ECHOREPLY ICMP6_ECHO_REPLY ICMP hop limit exceeded in transit ICMPV6_TIME_EXCEEDED_HOPS ICMP6_TIME_EXCEEDED_TRANSIT Hop-by-hop options IPV6_HOPOPTS IPV6_HOPBYHOP_OPTS or IPV6_HBH_OPTS Routing (header) IPV6_SRCRT IPV6_ROUTING Editorial: ---------- In section 3.2 is talks about "Six functions" for the filter. Since their names are upper case shouldn't you really say that they are macros? In section 4.4 it talks about returning ancillary data with recvmsg and later insection 4.5 it says that this only applies to UDP and not TCP. At least section 4.4 has to say that the recvmsg only applies to UDP, or perhaps better, have section 4.4 state how 1) the stack is configured to receive options and 2) how options are formatted for transmission and then separately state that for UDP recvmsg returns them as ancillary data and with TCP one can use getsockopt(IPV6_PKTOPTIONS) to retrieve them. Based on what we do with sendmsg and TCP the same might apply to sendmsg. In section 4.4 (and elsewhere) it might be good to note the overloading of the option names. When e.g. IPV6_HOPLIMIT is used in a setsockopt it only enables the receipt of the hoplimit information. When it is used in ancillary data or as part of a IPV6_PKTOPTIONS set/getsockopt it contains the actual hop limit. The text in section 5.2 and 5.3 talk in terms of ancillary data and sendmsg/recvmsg only. It fails to mention setting and retriving the info with IPV6_PKTOPTIONS. In section 5.4 it says "This is a priviledged option." but I can't find anything in the document that defines what a priviledged option is. The title for section 9 is "source routing option". No such thing exists in IPv6. IPv6 does have a "routing header" so perhaps that is a better name. (In general it might make sense to scan the document for "source routing" - source routing is a feature that is provided by the routing header.) I wonder if the inet6_srcrt_* function (for the same reason) should be renamed to inet6_routing_* (or inet6_rthdr_*?). Finally some suggestions for the unfinished items in section 13. ---------------------------------------------------------------- Path mtu discovery. How about defining a IPV6_PMTU (or IPV6_PMTU_NOTIFICATION) socket option? When it is enabled and udp receives a packet too big message for that port number it will queue a message with no data but only ancillary data on the socket. The ancillary data will contain an IPV6_PMTU option that carries both the mtu and the remote address. (The address is needed since the UDP socket might be used to send to multiple destinations thus it would need the address to match things up.) NUD reachability confirmations. If we define a IPV6_REACHABILITY_CONF it could be used both as ancillary data with sendmsg (when the application just received a request and is responding) and also as a setsockopt. In the ancillary data case it doesn't need to carry any data since it would apply to the destination address in the sendmsg. In the setsockopt case it would need a sockaddr_in6 to specify the address that is reachable. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 19:12:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA03606; Wed, 21 May 1997 19:00:49 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA03599; Wed, 21 May 1997 19:00:35 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA15617; Wed, 21 May 1997 19:02:14 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA04814; Wed, 21 May 1997 19:02:14 -0700 Date: Wed, 21 May 1997 19:02:14 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199705220202.TAA04814@bobo.eng.sun.com> To: huitema@bellcore.com Subject: (IPng 3675) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1279 > Did we ever consider inserting some site identifier, e.g. a random value, > in the site local prefix ? I know that this would not make the problem > disappear entirely, I know that randomness leads to unhappy birthdays, > specially when the random number is not actually random (albeit the site > manager could actually trow dices, it is a one time operation). But we > could still go a long way... I haven't heard such a proposal. If there is one I'd just like to point out that the site-prefixes proposal I made in Memphis assumes that there is a single site local prefix. If you have completely random values in the site-local prefix the only solution might be to put the site-local addresses in the (two-faced) DNS. It is a lot easier to handle this by requiring that the site boundaries lie on links instead of inside a router. I don't know if this is a reasonable constraint. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 19:49:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA03644; Wed, 21 May 1997 19:39:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA03637; Wed, 21 May 1997 19:38:54 -0700 From: zazoo@step.polymtl.ca Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA08612; Wed, 21 May 1997 19:40:16 -0700 Received: from step.polymtl.ca (step.polymtl.ca [132.207.4.32]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA08292 for ; Wed, 21 May 1997 19:41:02 -0700 Received: from slip01.slip.polymtl.ca (Cloclo@ts-2-13.slip.polymtl.ca [132.207.14.13]) by step.polymtl.ca (8.8.5/8.6.10) with SMTP id WAA28565 for ; Wed, 21 May 1997 22:39:03 -0400 (EDT) Message-ID: <3383C17D.73AD@step.polymtl.ca> Date: Wed, 21 May 1997 22:46:05 -0500 X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 3676) about RFCs and standards :) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 793 Hello First of all, i wanna thank Dan Harrington and Barbara Denny for their precious help, i appreciate that really,thanks again. Now if i understood well,for a document to be a standard...he must pass by several levels: first level : an internet draft second level : a rfc third level : a proposed standard fourth level : a draft standard final level : a standard is it correct? thanks in advance :) Zack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 20:48:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA03699; Wed, 21 May 1997 20:37:56 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA03692; Wed, 21 May 1997 20:37:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA13933; Wed, 21 May 1997 20:39:12 -0700 Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA17479 for ; Wed, 21 May 1997 20:39:55 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id XAA07734; Wed, 21 May 1997 23:37:28 -0400 (EDT) Date: Wed, 21 May 1997 23:37:28 -0400 (EDT) From: Scott Bradner Message-Id: <199705220337.XAA07734@newdev.harvard.edu> To: zazoo@step.polymtl.ca Subject: (IPng 3677) Re: about RFCs and standards :) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 546 Zack, > is it correct? not quite you can drop your 2nd level - most standards track documents go directly from an Internet-Draft to Proposed Standard RFC Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 07:05:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA04141; Thu, 22 May 1997 06:54:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA04134; Thu, 22 May 1997 06:54:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00702; Thu, 22 May 1997 06:55:46 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA18290 for ; Thu, 22 May 1997 06:56:34 -0700 Received: from gungnir.fnal.gov ("port 44198"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IJ5XL4FSZE0008TI@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Thu, 22 May 1997 08:56:00 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA05492; Thu, 22 May 1997 08:54:02 -0500 Date: Thu, 22 May 1997 08:54:02 -0500 From: Matt Crawford Subject: (IPng 3678) Re: New IPv6 Addressing Drafts In-reply-to: "21 May 1997 20:53:08 EDT." <"3.0.32.19970521205306.006a90b0"@pobox> To: ipng@sunroof.eng.sun.com Message-id: <199705221354.IAA05492@gungnir.fnal.gov> Content-transfer-encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Ok, let me reiterate: the same global scope interface id can be assigned to > multiple interfaces on the same node. I think this is an important > architectural point that should be clearly stated in the addressing spec. I agree with both points. Question: will everything about interface ids be in the address architecture? Will there be no need for a separate document, and no need to expound such details as the U/L bit in ipv6-over-{various IEEE media}? That would be good. 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 Thu May 22 08:14:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04295; Thu, 22 May 1997 08:04:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04288; Thu, 22 May 1997 08:04:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA18712; Thu, 22 May 1997 08:05:25 -0700 Received: from mailhost2.BayNetworks.COM ([134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA06173 for ; Thu, 22 May 1997 08:06:11 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id IAA16459 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id IAA09302 Posted-Date: Thu, 22 May 1997 08:04:18 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id LAA09863; Thu, 22 May 1997 11:04:17 -0400 for Message-Id: <3.0.32.19970522110311.0068b2e4@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 22 May 1997 11:03:12 -0400 To: Matt Crawford From: Dimitry Haskin Subject: (IPng 3679) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1261 At 08:54 AM 5/22/97 -0500, Matt Crawford wrote: >> Ok, let me reiterate: the same global scope interface id can be assigned to >> multiple interfaces on the same node. I think this is an important >> architectural point that should be clearly stated in the addressing spec. > >I agree with both points. > >Question: will everything about interface ids be in the address >architecture? Will there be no need for a separate document, and no >need to expound such details as the U/L bit in ipv6-over-{various >IEEE media}? That would be good. > Matt I don't think it can be avoided to have media specific documents that deals with media specific details and options. However, it would be nice if all such documents can follow clearly defined architectural guidelines/rules specified in a single document such that there is not much room for different interpretations. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 09:03:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04350; Thu, 22 May 1997 08:53:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04343; Thu, 22 May 1997 08:52:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA27990; Thu, 22 May 1997 08:54:15 -0700 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA21147; Thu, 22 May 1997 08:54:56 -0700 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id IAA29738; Thu, 22 May 1997 08:54:23 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id IAA13453; Thu, 22 May 1997 08:54:22 -0700 (MST) Message-Id: <199705221554.IAA13453@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Thu, 22 May 1997 08:54:22 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Erik.Nordmark@Eng (Erik Nordmark), matt.thomas@altavista-software.com Subject: (IPng 3680) Re: Comments on advance API draft Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 17191 [In your message of May 21, 6:47pm you write:] > > The scope: > ---------- > > I think it would be good to extend the draft to provide enough header > definitions so that a tcpdump like program could be portable to the systems > that implement the API. I *think* the only thing that is missing is > a definition of the fragmentation extension headers (unless you also want to > include AH and ESP headers for the benefit of tcpdump portability.) Yes, tcpdump portability would be nice. Adding more header definitions is fine with me. > It is not clear to me what to intended scope is for raw sockets. > Raw sockets are used by two types of applications: > - Non-TCP/UDP protocols like ICMP, OSPF, etc. These typically use > socket(,SOCK_RAW, IPPROTO_something) and expect a "not so raw socket". > - Testing applications like traceroute that want to control every piece of > the packet. These typilcally use socket(,SOCK_RAW, IPPROTO_RAW) or > set the IP_HDRINCL option in IPv4. > Does the document intend to cover both of them? > > The text in section 3 (5th paragraph) seems to imply that the scope is only > the former while pointing out that the socket options plus the ancillary data > can be used to reimplement tools like traceroute. Is my understanding correct? Yes. I believe there are numerous versions of traceroute out there for IPv6 (I have written one). traceroute for IPv4 only uses IP_HDRINCL for historical reasons to get at the TTL field, before the IP_TTL socket option was added. You don't need the IP_HDRINCL option for traceroute today (my version works with IPv4 and IPv6 and uses a plain old UDP socket for all output). And the only IP option it uses is for a source route (if your version supports the -g option) and with the IPv6 API you can get at that with the routing header functions. What the API does not provide, and I think it says so clearly, is a completely raw packet with all the extension headers intact. The extension headers are all pulled out and returned as ancillary data. > If this is the intended scope it might make sense to clarify that section > to state that > "All fields in the IPv6 ... can be modified *using ancillary data and/or socket > options* by the application." Fine. > Also, it would make sense to point out that is > either not supported on IPv6 or that it just uses payload type = 255. Fine. > Finally, does a raw socket automatically insert fragmentation headers > when the application sends something larger than the path MTU? > I assume (although it is not stated anywhere to my knowledge) that UDP > does this. But the raw socket case needs to be stated since different > implementors and different users might have different perspectives > on how raw a raw socket really is. I would assume so. > Security: > --------- > In IPv4 an application can not use UDP or TCP sockets to send packets > with a bogus source address. The mechanism specified in section 5.2 > allows an application to specify any source address when sending data. > Thus I think we need to require in section 5.2 that the kernel verify > that the source address is indeed a unicast address assigned to the machine. Fine. > Unclear things: > --------------- > > Section 3.1 specifies how a raw socket can be told to compute > checksums on transmit but it does not state if the kernel will > verify checksums on receipt. Please clarify in the document. Fine. The kernel should verify the received checksum. > The ping filter example in section 3.2 is probably confusing since > a ping program would be interested in seeing various ICMP error > messages in addition to the ICMP echo responses. How about using > an example that only receives router advertisement messages as > an example Fine. > What is the ND6_OPT_ENDOFLIST=256 in section 2.2.2? A comment > in the declaration might be useful. I'll let Matt comment on this. > When using raw sockets I assume the application receives the IP header > as part of the data just like in IPv4. But how does it receive any extension > headers? As part of the data (i.e. the data is the packet as it arrived on the > wire) or as ancillary data with recvmsg subject to enabling the socket > options (like for UDP)? I think the 4th paragraph in Section 3 (that we already discussed above) is clear on this: you do not get the actual IP header like IPv4. Everything other than the version number is available as ancillary data or as part of the returned socket address structure. > Section 4.4 and 4.5 specifies how I can set options (either per send or > for the socket). If I've set options with IPV6_PKTOPTIONS how can I clear > them? I'd think by setting the length argument to setsockopt() to 0, but we should explicitly say this. This would zap all sticky options. > Section 4.5 states that the most recently received options can be > retrieved using IPV6_PKTOPTIONS. For performance reasons I don't want > TCP to always store away this info from every segment if nobody is > interested in it. Thus shouldn't the document state that > IPV6_PKTOPTIONS only retrieves the components that TCP has been > enabled to receive (using setsockopt) prior to the segment arrives? Yes, that makes sense. > The use of ancillary data with TCP to send options/extensions in > section 4.5 strikes me as odd since there is not a one-to-one correspondence > between sendmsg calls and tcp segments on the wire. Furthermore, > a TCP implementation might packetize the data differently when retransmitting > data than the first time it was transmitted. This could be the case > e.g. if the receiver decreases the right window edge. > How about simplifying things to only have TCP handle a setsockopt > with IPv6_PKTOPTIONS? I think it would remove a bunch of extra checks and make > TCP faster. That's fine with me--any other opinions? > The rules for "sticky" options are specified in section 4.5. Does this > mean that IPV6_PKTOPTIONS and "sticky" options only apply to TCP? > If they apply to UDP then the text is in the wrong section. I think the section title is wrong: instead of "TCP Access to Ancillary Data" it should be "Sticky Options", since IPV6_PKTOPTIONS applies to all sockets (as stated in the 3rd paragraph of the section). > In any case, the rules for "sticky" options version the ancillary data options > seem complex. What is the motivation for these rules? > Can we get away with something simpler? (both simpler to explain to the poor > socket programmer and simpler to implement.) I'll defer to Matt on this. > Section 5.5 specifies new errors for sendmsg. Presumably they also > apply to setsockopt(IPV6_PKTOPTIONS). But, more importantly > there is a class of implementations (such as STREAMS based implementations) > where sendmsg can not return any errors from the IP layer. > Thus it might make sense to point out that "additional errors > might occur on some implementations" or something like it. I think the introductory paragraph on p. 6 covers this ("We note ... may have error returns that are not defined in this document. ..."). > The document talks about priority (and this is also a "feature" of RFC 2133). > Should we remove any mention of priority? We talk about it with regard to the flow label, because that's what Section 6 of RFC 1883 does. I think the note on top of p. 30 says it all: "Note: The use of the priority field in the IPv6 header is still subject to change. The basic API spec [2] removed all references to this field for this reason. Therefore it is unspecified how a process specifies a nonzero priority field." [The 2nd sentence in this quote is not quite accurate, because the word "priority" is still in RFC 2133, but what was removed was any description of what the field means along with all the (previously defined) constants for its values.] I don't think the mention of the field in the description of the flow label functions in the Advanced API is inappropriate, given the qualifier above. > The second (and 4th) bullet in section 6 talks about uniqueness of flow labels. > Don't they also have to be unique for a given routing header and hop-by-hop > options header? Yes, as stated in the first paragraph of Section 6. The purpose of this introductory discussion in Section 6 is *not* to define the flow label (RFC 1883 does that) but to give some motivation as to why the functions that are described were designed the way they were. > It is not clear to me how to implement inet6_flow_free (section 6.2). > Do I have to avoid reusing the flow label for an additional 6 seconds? > If so it would make sense to state that in the document. We can add it, but obviously what's in RFC 1883 (or any successor) takes precedence from an implementation perspective. > In section 6, 7.3 and 9 the specification states that inet6_* functions > have prototypes in . Is this intentional? > The inet_* functions for IPv4 have their prototypes in > . Yes, it was intentional, as the inet_ functions from IPv4 are just address manipulation functions, provided by the resolver. The inet6_ functions are quite different. Perhaps the name prefix was bad (more about this below). > In section 9.5 it claims that inet6_srcrt_reverse() returns either zero > or an errno. None of the standard socket functions have this behavior > of returning an errno - they return -1 (or perhaps NULL in some cases) > and sets the errno variable to the error number. > The same is true for inet6_srcrt_add. > Can we make them (and any others) a little more consistent in this respect? Fine with me. Matt? > Missing things: > -------------- > Would it be useful to declare an ND option header structure in section > 2.2.2 containing just the type and the length. It could then be used > for the defined prefix and mtu options but also for the link-layer address > option which currently does not have a structure definition. Fine with me. > In section 2.4 you only define names for "ipv6" and "icmpv6". > How about fragmentation, "no extension hdr" and all the other extension > headers? (Just make sure that the names match with what is registered > with the IANA.) I did this yesterday, from an updated ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers. Here are the names and values: hopopt 0 # hop-by-hop options for ipv6 ipv6 41 # ipv6 ipv6-route 43 # routing header for ipv6 ipv6-frag 44 # fragment header for ipv6 esp 50 # encapsulating security payload for ipv6 ah 51 # authentication header for ipv6 ipv6-icmp 58 # icmp for ipv6 ipv6-nonxt 59 # no next header for ipv6 ipv6-opts 60 # destination options for ipv6 > Name space issues: > ------------------ > When this document goes to Posix there are likely to be some name space > constraints added e.g. when including it defines only names > that start with the prefixes "icmp6_", "ICMPv6_", etc. > > The reason this is done to the standards is so that the applications > know what part of the name space they can use. For instance, an > application might want to have > #define data "test" > #include > > However, the example icmp6_filter definition in section 3.2 uses > the "data" part of the name space. That icmp6_filter example, is explicitly noted as an example. No one should be using the contents of the structure, and that's why the six macros are defined. > ... > > Choice of names: > ---------------- Erik: why are you bringing this up seven months after the names were first proposed, and almost two weeks after the last call ended? Yes, some of the names are not "perfect" but there have been few complaints. Craig Metz didn't like some last Fall and he and Matt worked out some changes that went into the -01 draft. That's been it for the complaints. For what it's worth, I really don't care about the names at all, as long as all the implementations use the same names for the same things. My interest is in using this API to write applications; I don't have a vested interest in any one implementation. Is there a consensus with others to go back and revisit all the names in here and make them more consistent? > Editorial: > ---------- > > In section 3.2 is talks about "Six functions" for the filter. > Since their names are upper case shouldn't you really say that they > are macros? We can call them macros if you'd like. I tend to call everything a function these days, trying not to avoid "system call" and "macro", since the distinction is often an implementation detail. Just look at the numer of all-lower-case macros in most headers. If we say "macro" then we're forcing it to be implemented as a macro, aren't we? > In section 4.4 it talks about returning ancillary data with recvmsg and > later insection 4.5 it says that this only applies to UDP and not TCP. > At least section 4.4 has to say that the recvmsg only applies to UDP, > or perhaps better, have section 4.4 state how 1) the stack is configured > to receive options and 2) how options are formatted for transmission > and then separately state that for UDP recvmsg returns them as ancillary data > and with TCP one can use getsockopt(IPV6_PKTOPTIONS) to retrieve them. > Based on what we do with sendmsg and TCP the same might apply to sendmsg. I'm not sure what you're stating here. > In section 4.4 (and elsewhere) it might be good to note the overloading > of the option names. > When e.g. IPV6_HOPLIMIT is used in a setsockopt it only enables > the receipt of the hoplimit information. When it is used in ancillary data > or as part of a IPV6_PKTOPTIONS set/getsockopt it contains the actual hop > limit. I think p. 23 sums this up adequately: in one case it's the option name for [sg]etsockopt(), and it's also used as the cmsg_type value. > The text in section 5.2 and 5.3 talk in terms of ancillary data and > sendmsg/recvmsg only. It fails to mention setting and retriving the info > with IPV6_PKTOPTIONS. We don't mention IPV6_PKTOPTIONS in Sections 7, 8, or 9 either. Perhaps in Section 4.5 we should be more explicit that it applies to the six types of ancillary data mentioned at the top of p. 23. > In section 5.4 it says "This is a priviledged option." but I can't find > anything in the document that defines what a priviledged option is. Correct, and I think that's out of the scope of this document. I think anyone implementing this will know how it applies to their system. > The title for section 9 is "source routing option". No such thing > exists in IPv6. IPv6 does have a "routing header" so perhaps that > is a better name. > ... > I wonder if the inet6_srcrt_* function (for the same reason) should be > renamed to inet6_routing_* (or inet6_rthdr_*?). Well, we were using the commonly-used term, realizing that this document is not the authoritative spec for the protocol. I also notice that all of the drafts leading to RFC 2133, when they specified this capability, all used "source route". In the Advanced API draft there are 15 references to "source route" (and 91 to "routing header") but if there's a consensus that our use of "source route" is a no-no, I'll gladly change them. (Humm, I just found an index entry in Christian's book for "source routes". :-) ) > Finally some suggestions for the unfinished items in section 13. > ---------------------------------------------------------------- > Path mtu discovery. > ... > NUD reachability confirmations. > ... I am going to pass on these for now, as you are the first to make a proposal in these two areas. Yes, something will be needed here, but the goal now is to get the Advanced API out, so vendors can start using it. Francis Dupont and Steve Wise both asked a few weeks ago (when the last call was sent out) if finishing this draft right now was premature, and the consensus (100% of the four replies :-) ) was that the draft should be finished and published as an informational RFC and that implementations are underway of significant portions of the draft. There are already some features in RFC 2133 that are out-of-date, with Draft 6.6 of Posix.1g passing ballot this week. (The changes from D6.5 to D6.6 were not even published when 2133 was finished.) And I hear that XNET will be looking at both 2133 and the Advanced API in the next month or two, and then give their comments as to what they see needs to be changed for these informational documents to move into their standards process. So what I envision is a later document that corrects any known deficiencies in 2133 and the Advanced API spec, and in there we can also address the unspecified issues such as PMTU and ND reachability. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 10:08:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04569; Thu, 22 May 1997 09:57:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04561; Thu, 22 May 1997 09:57:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA12725; Thu, 22 May 1997 09:58:26 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA12872 for ; Thu, 22 May 1997 09:59:11 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA15986; Thu, 22 May 1997 09:58:08 -0700 Message-Id: <3.0.1.32.19970522095809.006dc4e4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 09:58:09 -0700 To: Dimitry Haskin From: Bob Hinden Subject: (IPng 3681) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.32.19970521205306.006a90b0@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 888 Dimitry, >Ok, let me reiterate: the same global scope interface id can be assigned to >multiple interfaces on the same node. I think this is an important >architectural point that should be clearly stated in the addressing spec. I agree. I will add the following to section 2.5.1 on Interface Identifiers: "The same interface identifier may be assigned to more than one interface on the same node" >P.S. The IPv6/PPP spec will allow what I'll make it to allow ;) So what is it going to be? 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 May 22 10:21:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04683; Thu, 22 May 1997 10:07:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04676; Thu, 22 May 1997 10:07:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA15264; Thu, 22 May 1997 10:08:59 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA16350 for ; Thu, 22 May 1997 10:09:45 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA16488; Thu, 22 May 1997 10:07:55 -0700 Message-Id: <3.0.1.32.19970522100842.00b14934@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 10:08:42 -0700 To: Matt Crawford From: Bob Hinden Subject: (IPng 3682) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199705221354.IAA05492@gungnir.fnal.gov> References: <"21 May 1997 20:53:08 EDT." <"3.0.32.19970521205306.006a90b0"@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1153 Matt, >Question: will everything about interface ids be in the address >architecture? Will there be no need for a separate document, and no >need to expound such details as the U/L bit in ipv6-over-{various >IEEE media}? That would be good. I agree it would be good to add to the addressing architecture more detail on how to form interface ID's using EUI-64 formats. I think the two important cases to add are: - EUI-64 from 48bit IEEE 802 - EUI-64 when no hardware token is available (e.g., for serial links, tunnels, local talk, etc.) Are there any others? I think the specifics for how to do this on a specific media type still needs to be described in the appropriate IPv6 over document to deal with the particularities of each media type. 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 May 22 11:11:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04820; Thu, 22 May 1997 10:58:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04812; Thu, 22 May 1997 10:58:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA28601; Thu, 22 May 1997 10:59:57 -0700 Received: from wachusett.altavista-software.com (wachusett.altavista-software.com [205.181.164.11]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA03101 for ; Thu, 22 May 1997 11:00:42 -0700 Received: by wachusett.altavista-software.com; (5.65v3.2/1.3/10May95) id AA11262; Thu, 22 May 1997 14:00:04 -0400 Message-Id: <3.0.1.32.19970522135914.0072da80@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 13:59:14 -0400 To: Erik.Nordmark@Eng (Erik Nordmark) Received: from shasta.altavista-software.com by wachusett.altavista-software.com (smtpxd); id XA01857 From: Matt Thomas Subject: (IPng 3683) Re: Comments on advance API draft Cc: ipng@sunroof.eng.sun.com, "W. Richard Stevens" In-Reply-To: <199705221554.IAA13453@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3325 At 08:54 AM 5/22/97 -0700, W. Richard Stevens wrote: I agree with Richard about everything he said.. >[In your message of May 21, 6:47pm you write:] >> What is the ND6_OPT_ENDOFLIST=256 in section 2.2.2? A comment >> in the declaration might be useful. >I'll let Matt comment on this. Opps. it should be nuked (it's used as an argument to a stdargs routine to extract options from neighbor discovery messages in the Digital UNIX implementation). Actually, I was think of switching these back to #define's to be consistent with the rest of the specifaction. >> In any case, the rules for "sticky" options version the ancillary data >> options seem complex. What is the motivation for these rules? >> Can we get away with something simpler? (both simpler to explain to >> the poor socket programmer and simpler to implement.) > >I'll defer to Matt on this. The rule is "ancillary data overrides sticky options". This is actually simplier otherwise we have to discuss how to merge options specified via setsockopt with those by sendmsg(). Which go first, etc.? It seemed simplier to me to simple have ancillary occlude the setsockopt options. >> In section 9.5 it claims that inet6_srcrt_reverse() returns either zero >> or an errno. None of the standard socket functions have this behavior >> of returning an errno - they return -1 (or perhaps NULL in some cases) >> and sets the errno variable to the error number. >> The same is true for inet6_srcrt_add. >> Can we make them (and any others) a little more consistent in this respect? > >Fine with me. Matt? I defined them to return errors (instead of setting errno) to make them more thread-friendly. 1003.1d uses the convention of returning error codes and since we have the benefit of their work, I decided to follow their lead. And I did not have backwards compatibility to worry about. >> ... >> >> Choice of names: >> ---------------- > >Erik: why are you bringing this up seven months after the names were >first proposed, and almost two weeks after the last call ended? >Yes, some of the names are not "perfect" but there have been few >complaints. Craig Metz didn't like some last Fall and he and Matt >worked out some changes that went into the -01 draft. That's been it >for the complaints. > >For what it's worth, I really don't care about the names at all, as >long as all the implementations use the same names for the same things. >My interest is in using this API to write applications; I don't have a >vested interest in any one implementation. > >Is there a consensus with others to go back and revisit all the names >in here and make them more consistent? Not from me. -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 11:30:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04857; Thu, 22 May 1997 11:18:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04850; Thu, 22 May 1997 11:18:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA03955; Thu, 22 May 1997 11:19:28 -0700 Received: from rottweiler.cisco.com (rottweiler.cisco.com [171.69.1.237]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA09512 for ; Thu, 22 May 1997 11:20:15 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by rottweiler.cisco.com (8.6.12/8.6.5) with ESMTP id LAA23822; Thu, 22 May 1997 11:19:11 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA12938; Thu, 22 May 1997 11:19:11 -0700 (PDT) Date: Thu, 22 May 1997 11:19:11 -0700 (PDT) Message-Id: <199705221819.LAA12938@pedrom-ultra.cisco.com> From: Pedro Marques To: Bob Hinden Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com Subject: (IPng 3684) Re: New IPv6 Addressing Drafts In-Reply-To: <3.0.1.32.19970522095809.006dc4e4@mailhost.ipsilon.com> References: <3.0.32.19970521205306.006a90b0@pobox> <3.0.1.32.19970522095809.006dc4e4@mailhost.ipsilon.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1378 >>>>> "Bob" == Bob Hinden writes: Bob> Dimitry, >> Ok, let me reiterate: the same global scope interface id can be >> assigned to multiple interfaces on the same node. I think this >> is an important architectural point that should be clearly >> stated in the addressing spec. Bob, Bob> I agree. I will add the following to section 2.5.1 on Bob> Interface Identifiers: Bob> "The same interface identifier may be assigned to more I assume that interface indentifier here should really be "global EUI-64", to make it clear. I think that there is no issue with non globally unique identifiers. Bob> than one interface on the same node" Is this a MAY or a SHOULD ? I.e. if a node can build different globally unique EUI-64s what should the behaviour be ? >From your previous answer to Dimitry i was under the impression that you consider that there are advantages in all interfaces in a node to use the same EUI-64. regards, Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 12:14:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA04930; Thu, 22 May 1997 12:02:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA04923; Thu, 22 May 1997 12:02:33 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA16336; Thu, 22 May 1997 12:03:51 -0700 Received: from eamail1.unisys.com (eamail1.unisys.com [192.61.103.80]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA23810 for ; Thu, 22 May 1997 12:04:38 -0700 Received: from unislc.slc.unisys.com ([192.60.224.1]) by eamail1.unisys.com (8.8.5/8.6.12) with SMTP id TAA26053 for ; Thu, 22 May 1997 19:04:04 GMT Received: from slc-exchange-1 by unislc.slc.unisys.com (5.61/1.35) id AA16736; Thu, 22 May 97 13:02:12 -0600 Received: by slc-exchange-1.slc.unisys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC66AF.EB85B690@slc-exchange-1.slc.unisys.com>; Thu, 22 May 1997 12:59:01 -0600 Message-Id: From: "Harsch, Tom" To: "'Bob Hinden'" Cc: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 3685) Re: New IPv6 Addressing Drafts Date: Thu, 22 May 1997 12:58:59 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1397 Bob, > >>Question: will everything about interface ids be in the address >>architecture? Will there be no need for a separate document, and no >>need to expound such details as the U/L bit in ipv6-over-{various >>IEEE media}? That would be good. > >I agree it would be good to add to the addressing architecture more detail >on how to form interface ID's using EUI-64 formats. I think the two >important cases to add are: > > - EUI-64 from 48bit IEEE 802 > - EUI-64 when no hardware token is available (e.g., for serial links, > tunnels, local talk, etc.) > >Are there any others? I work with some LAN interface cards (Ethernet, FDDI, etc.) that have no universally administered MAC address. Their MAC addresses must always be locally configured. Would these be covered by the second case above? > >I think the specifics for how to do this on a specific media type still >needs to be described in the appropriate IPv6 over document to deal >with the particularities of each media type. > -- Tom Harsch -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 13:07:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA05061; Thu, 22 May 1997 12:56:32 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA05054; Thu, 22 May 1997 12:56:24 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA27143; Thu, 22 May 1997 12:57:44 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA07944 for ; Thu, 22 May 1997 12:58:32 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id MAA23697; Thu, 22 May 1997 12:57:27 -0700 Message-Id: <3.0.1.32.19970522125814.00bcdd68@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 12:58:14 -0700 To: "Harsch, Tom" From: Bob Hinden Subject: (IPng 3686) Re: New IPv6 Addressing Drafts Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 933 Tom, >I work with some LAN interface cards (Ethernet, FDDI, >etc.) that have no universally administered MAC address. >Their MAC addresses must always be locally configured. >Would these be covered by the second case above? What do you do for MAC addresses with IPv4 (e.g., how are they created)? Also, curious why these LAN interfaces choose to not include MAC addresses. I would think that they would be covered by the second case, but it is a bit harder to generate unique link identifiers on a shared media than for serial links or tunnels. 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 May 22 14:18:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05330; Thu, 22 May 1997 14:05:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05323; Thu, 22 May 1997 14:04:54 -0700 From: zazoo@step.polymtl.ca Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA10874; Thu, 22 May 1997 14:06:16 -0700 Received: from step.polymtl.ca (step.polymtl.ca [132.207.4.32]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA27163 for ; Thu, 22 May 1997 14:07:00 -0700 Received: from slip01.slip.polymtl.ca (Cloclo@ts-4-05.slip.polymtl.ca [132.207.16.5]) by step.polymtl.ca (8.8.5/8.6.10) with SMTP id RAA18234 for ; Thu, 22 May 1997 17:04:56 -0400 (EDT) Message-ID: <3384C328.4CDD@step.polymtl.ca> Date: Thu, 22 May 1997 17:05:28 -0500 X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ipng Subject: (IPng 3687) about RFCs, internet standars and IETF standards Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1085 Hello I have 2 questions : FIRST question : In his article published in the magazine "communications of the ACM", Juin 96, Robert M.Hinden said that the RCFs,1883, 1884,1885,1886,1825,1826,1827 and 1933 are IETF standards.I thought that these RFCs were a proposed standards for internet.So what's the difference between an IETF standard and an INTERNET standard ? and is there any other IETF standards than the RFCs i mentionned ? SECOND question : i consulted the RFCs 2073, 1971, 1981, 2080, and they are mentionned under the category : STANDARDS TRACK, but they arent mentionned under PROPOSED STANDARDS at http://www.isi.edu/rfc-editor/status.html , can someone explain me why? Thanks in advance :) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 14:25:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05348; Thu, 22 May 1997 14:12:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05341; Thu, 22 May 1997 14:12:28 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA12530; Thu, 22 May 1997 14:13:50 -0700 Received: from eamail1.unisys.com (eamail1.unisys.com [192.61.103.80]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA29269 for ; Thu, 22 May 1997 14:14:35 -0700 Received: from unislc.slc.unisys.com ([192.60.224.1]) by eamail1.unisys.com (8.8.5/8.6.12) with SMTP id VAA21632 for ; Thu, 22 May 1997 21:14:02 GMT Received: from slc-exchange-1 by unislc.slc.unisys.com (5.61/1.35) id AA20167; Thu, 22 May 97 15:12:09 -0600 Received: by slc-exchange-1.slc.unisys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC66C2.1325BC60@slc-exchange-1.slc.unisys.com>; Thu, 22 May 1997 15:08:59 -0600 Message-Id: From: "Harsch, Tom" To: "'Bob Hinden'" Cc: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 3688) Re: New IPv6 Addressing Drafts Date: Thu, 22 May 1997 15:08:57 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1491 Bob, > >Tom, > >>I work with some LAN interface cards (Ethernet, FDDI, >>etc.) that have no universally administered MAC address. >>Their MAC addresses must always be locally configured. >>Would these be covered by the second case above? > >What do you do for MAC addresses with IPv4 (e.g., how are they created)? A network administrator must specify a MAC address in a configuration file. Vendor (unnamed) recommends use of their IEEE 802 OUI and a one octet address block number they've assigned to their product line, leaving two octets to be assigned locally. The administrator must ensure uniqueness on shared media. Since few of these devices attach to a given LAN, uniqueness isn't much of a problem - just a nuisance. >Also, curious why these LAN interfaces choose to not include MAC addresses. So am I. Maybe a manufacturing cost or administration issue? I hesitate to suggest simple ignorance. > >I would think that they would be covered by the second case, but it is a >bit harder to generate unique link identifiers on a shared media than for >serial links or tunnels. > >Bob -- Tom Harsch > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 15:26:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05491; Thu, 22 May 1997 15:14:27 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05484; Thu, 22 May 1997 15:14:23 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03801; Thu, 22 May 1997 15:16:02 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA24345; Thu, 22 May 1997 15:14:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05397; Thu, 22 May 1997 14:39:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA18997; Thu, 22 May 1997 14:40:24 -0700 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA06868 for ; Thu, 22 May 1997 14:41:04 -0700 Received: from fleck.iol.unh.edu by iol.unh.edu (4.1/SMI-4.1) id AA15639; Thu, 22 May 97 17:31:12 EDT Received: by fleck.iol.unh.edu (SMI-8.6/SMI-SVR4) id RAA20896; Thu, 22 May 1997 17:39:32 -0400 Date: Thu, 22 May 1997 17:39:32 -0400 Message-Id: <199705222139.RAA20896@fleck.iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipv6imp@munnari.oz.au, ipng@sunroof.eng.sun.com Cc: whl@unh.edu, emf@iol.unh.edu Subject: (IPng 3690) UNH IPv6 Testing Event X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremy McCooey Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1429 The UNH InterOperability Lab ( IOL ) will conduct an IPv6 "interoperability" testing period the week of July 28 - August 1, 1997. Unlike previous testing periods, this event will focus upon the "interoperability" of participating vendors' IPv6 implementations. For members of the IOL's IPv6 Consortium, conformance-like testing using the IOL's IPv6 test suite will be performed after the completion of the interoperability testing. For those attendees who are not members of the IOL's IPv6 Consortium, the conformance-like testing will be conducted solely on a "time-available" basis. As before, the cost of the testing event for non-members is $1250.00US for two attendees. The cost for additional attendees is $100 per person. The testing event is free for consortium members. To make reservations for testing: Contact W. H. Lenharth by email ( whl@unh.edu ) or by phone (603-862-4492) for a reservation form. For hotel reservations / general information: Please check the IOL's web page ( http://www.iol.unh.edu/general/about.html ). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 15:31:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05502; Thu, 22 May 1997 15:18:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05495; Thu, 22 May 1997 15:18:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA27407; Thu, 22 May 1997 15:19:26 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA16868 for ; Thu, 22 May 1997 15:20:12 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA00260; Thu, 22 May 1997 15:19:09 -0700 Message-Id: <3.0.1.32.19970522151955.007319a8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 15:19:55 -0700 To: Pedro Marques From: Bob Hinden Subject: (IPng 3691) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199705221819.LAA12938@pedrom-ultra.cisco.com> References: <3.0.1.32.19970522095809.006dc4e4@mailhost.ipsilon.com> <3.0.32.19970521205306.006a90b0@pobox> <3.0.1.32.19970522095809.006dc4e4@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1536 Pedro, > Bob> "The same interface identifier may be assigned to more > >I assume that interface indentifier here should really be "global EUI-64", to >make it clear. I think that there is no issue with non globally unique >identifiers. I belive it is fine with either kind (global or local) of interfaces identifier. All interface identifiers are still required to be unique on the link. Any interface identifier combined with the prefix for it's link results in a globally unique IPv6 address. > Bob> than one interface on the same node" > >Is this a MAY or a SHOULD ? I.e. if a node can build different globally >unique EUI-64s what should the behaviour be ? I think it should be a MAY. It is something we should allow, but I don't think we know enough about this yet to require or even recommend (e.g. SHOULD) it. >>From your previous answer to Dimitry i was under the impression that you >consider that there are advantages in all interfaces in a node to use >the same EUI-64. I think that given some future transport protocol, there could be an advantage. But I don't think it is concrete enough to require this behavior. 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 May 22 15:45:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05529; Thu, 22 May 1997 15:29:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05522; Thu, 22 May 1997 15:29:10 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA29432; Thu, 22 May 1997 15:30:31 -0700 Received: from cheerios.cisco.com (cheerios.Cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA19554 for ; Thu, 22 May 1997 15:31:18 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id PAA28025; Thu, 22 May 1997 15:30:12 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 1997 15:30:24 -0700 To: "Harsch, Tom" From: Steve Deering Subject: (IPng 3692) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1223 > A network administrator must specify a MAC address in a configuration > file. Vendor (unnamed) recommends use of their IEEE 802 OUI and a > one octet address block number they've assigned to their product line, > leaving two octets to be assigned locally. The administrator must > ensure uniqueness on shared media. Does the recommended OUI have the universal-admin/local-admin bit (the second lowest order bit of the high-order byte, in canonical bit order) set to Universal (0) or Local (1)? If it is set to Universal, and if the vendor of those devices has more than one customer, then autoconfiguring IPv6 addresses from such MAC addresses will result in IPv6 addresses with interface IDs that appear to be globally unique but are very likely not globally unique. Sigh. I hope you didn't pay much for those LAN interfaces. 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 Thu May 22 16:07:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05586; Thu, 22 May 1997 15:56:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05579; Thu, 22 May 1997 15:56:42 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA04889; Thu, 22 May 1997 15:58:01 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA26430 for ; Thu, 22 May 1997 15:58:49 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA02103; Thu, 22 May 1997 15:57:44 -0700 Message-Id: <3.0.1.32.19970522155830.00771578@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 22 May 1997 15:58:30 -0700 To: "Harsch, Tom" From: Bob Hinden Subject: (IPng 3693) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 976 Tom, >>What do you do for MAC addresses with IPv4 (e.g., how are they created)? > >A network administrator must specify a MAC address in a configuration >file. Vendor (unnamed) recommends use of their IEEE 802 OUI and a >one octet address block number they've assigned to their product line, >leaving two octets to be assigned locally. The administrator must >ensure >uniqueness on shared media. Since few of these devices attach to a >given LAN, uniqueness isn't much of a problem - just a nuisance. This should be fine to create an EUI-64 based interface identifier with local scope. 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 May 22 17:28:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA05920; Thu, 22 May 1997 17:15:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA05913; Thu, 22 May 1997 17:15:34 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA20930; Thu, 22 May 1997 17:16:54 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA16501 for ; Thu, 22 May 1997 17:17:42 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id RAA05833 for ; Thu, 22 May 1997 17:17:08 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 22 May 1997 17:17:20 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 3694) indicating globicity Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2215 I wish to propose the following small change to the rules for manufacturing IPv6 addresses out of EUI-64 addresses: that the "u" (universal/local) bit in the EUI-64 address be *inverted* when forming the interface ID part of an IPv6 address, so that a bit value of 1 would indicate that the interface ID field can be used as globally-unique node ID, and a bit value of 0 would indicate that the interface ID cannot be considered globally unique. That is, a globally-unique EUI-64 unicast address of the canonical form: eeeeee00 eeeeeeee eeeeeeee eeeeeeee eeeeeeee eeeeeeee eeeeeeee eeeeeeee ^ | "u" bit would yield an IPv6 unicast address of the form: 001ttttt tttttttt nnnnnnnn nnnnnnnn nnnnnnnn nnnnnnnn ssssssss ssssssss eeeeee10 eeeeeeee eeeeeeee eeeeeeee eeeeeeee eeeeeeee eeeeeeee eeeeeeee ^ | global node ID indicator where t = TLA bits, n = NLA* bits, s = SLA* bits, e = interface ID bits The motivation for this proposal is to make IPv6 addresses with *non*- globally-unique interface IDs a little easier to read, write, and manage. For example, on links that do not have factory assigned IEEE 802 or EUI-64 addresses, and on tunnel endpoints and other kinds of virtual interfaces, one could could assign small-integer interface IDs (e.g., 1, 2, ...), rather than having to remember to assign interface IDs that have a special "local" bit set (e.g., [hex] 0300000000000001, 0300000000000002, ...). This change would also restore the ability to use a subnet prefix with a zero-valued interface-id as the well-known anycast address for the set of routers attached to a subnet. (Note that the interface ID field of an IPv6 anycast address that is intended to be assigned to more than one node must not be interpretable as a unique node ID!) Comments? 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 Thu May 22 17:34:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA05935; Thu, 22 May 1997 17:21:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA05928; Thu, 22 May 1997 17:21:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA22022; Thu, 22 May 1997 17:22:39 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA17846 for ; Thu, 22 May 1997 17:23:27 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id RAA00887 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id RAA19261 Posted-Date: Thu, 22 May 1997 17:22:19 -0700 (PDT) Received: from dhaskin.baynetworks.com (eng_ppp16 [192.32.171.156]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA22660; Thu, 22 May 1997 20:22:19 -0400 for Message-Id: <3.0.32.19970522202327.006a6fd4@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 22 May 1997 20:23:28 -0400 To: Bob Hinden , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 3695) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 709 Bob, >>P.S. The IPv6/PPP spec will allow what I'll make it to allow ;) > >So what is it going to be? > >Bob > If an unique build-in MAC address is available on the node, it will be used to form ID of a PPP interface using an EUI-64 format. Otherwise a random number will be used to generate a local scope interface id. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 23 09:26:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06737; Fri, 23 May 1997 09:18:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06730; Fri, 23 May 1997 09:18:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA06277; Fri, 23 May 1997 09:19:57 -0700 Received: from eamail1.unisys.com (eamail1.unisys.com [192.61.103.80]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA05872 for ; Fri, 23 May 1997 09:20:45 -0700 Received: from unislc.slc.unisys.com ([192.60.224.1]) by eamail1.unisys.com (8.8.5/8.6.12) with SMTP id QAA25212 for ; Fri, 23 May 1997 16:20:10 GMT Received: from slc-exchange-1 by unislc.slc.unisys.com (5.61/1.35) id AA08960; Fri, 23 May 97 09:37:00 -0600 Received: by slc-exchange-1.slc.unisys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC675C.69C5BCB0@slc-exchange-1.slc.unisys.com>; Fri, 23 May 1997 09:33:46 -0600 Message-Id: From: "Harsch, Tom" To: "'Steve Deering'" Cc: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 3696) Re: New IPv6 Addressing Drafts Date: Fri, 23 May 1997 09:33:44 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1371 Steve, > >> A network administrator must specify a MAC address in a configuration >> file. Vendor (unnamed) recommends use of their IEEE 802 OUI and a >> one octet address block number they've assigned to their product line, >> leaving two octets to be assigned locally. The administrator must >> ensure uniqueness on shared media. > >Does the recommended OUI have the universal-admin/local-admin bit (the >second lowest order bit of the high-order byte, in canonical bit order) >set to Universal (0) or Local (1)? Universal (0). Oops! > >If it is set to Universal, and if the vendor of those devices has more than >one customer, then autoconfiguring IPv6 addresses from such MAC addresses >will result in IPv6 addresses with interface IDs that appear to be globally >unique but are very likely not globally unique. Sigh. Any serious (pre-IPv6) consequences if bit setting is wrong? I've never seen any. > >I hope you didn't pay much for those LAN interfaces. > >Steve -- Tom Harsch -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 23 10:01:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06797; Fri, 23 May 1997 09:52:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06790; Fri, 23 May 1997 09:52:10 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA13677; Fri, 23 May 1997 09:53:30 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA16077 for ; Fri, 23 May 1997 09:54:19 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id JAA12633; Fri, 23 May 1997 09:53:11 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 09:53:33 -0700 To: "Harsch, Tom" From: Steve Deering Subject: (IPng 3697) Re: New IPv6 Addressing Drafts Cc: "'ipng@sunroof.Eng.Sun.COM'" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 890 > >Does the recommended OUI have the universal-admin/local-admin bit (the > >second lowest order bit of the high-order byte, in canonical bit order) > >set to Universal (0) or Local (1)? > > Universal (0). Oops! > > Any serious (pre-IPv6) consequences if bit setting is wrong? I've never > seen any. Presumably, the only prior hazard would be the possibility of duplicate addresses when two or more separately-adminstered LANs are joined by MAC layer bridging (including by such means as ATM LANE). 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 Fri May 23 10:15:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA06931; Fri, 23 May 1997 10:04:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA06924; Fri, 23 May 1997 10:04:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA16622; Fri, 23 May 1997 10:06:05 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA20077 for ; Fri, 23 May 1997 10:06:52 -0700 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA50157; Fri, 23 May 1997 18:06:16 +0100 Date: Fri, 23 May 1997 18:06:16 +0100 Message-Id: <9705231706.AA50157@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3698) Re: indicating globicity To: ipng@sunroof.eng.sun.com In-Reply-To: from "Steve Deering" at May 22, 97 05:17:20 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 925 >- Steve Deering said: > > I wish to propose the following small change to the rules for manufacturing > IPv6 addresses out of EUI-64 addresses: that the "u" (universal/local) bit > in the EUI-64 address be *inverted* when forming the interface ID part of > an IPv6 address, I really think this would cause so much confusion and so many coding errors over the next 50 years or so that we should definitely not do it. I do understand the convenience argument, but imagine the confusion it would cause in low level debugging. Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 23 11:52:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06993; Fri, 23 May 1997 11:44:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06986; Fri, 23 May 1997 11:44:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA11800; Fri, 23 May 1997 11:45:35 -0700 Received: from akita.cisco.com (akita.cisco.com [171.69.223.72]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA22181 for ; Fri, 23 May 1997 11:46:23 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by akita.cisco.com (8.6.12/8.6.5) with ESMTP id LAA24597; Fri, 23 May 1997 11:45:50 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA13653; Fri, 23 May 1997 11:45:49 -0700 (PDT) Date: Fri, 23 May 1997 11:45:49 -0700 (PDT) Message-Id: <199705231845.LAA13653@pedrom-ultra.cisco.com> From: Pedro Marques To: brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3699) Re: indicating globicity In-Reply-To: <9705231706.AA50157@hursley.ibm.com> References: <9705231706.AA50157@hursley.ibm.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1817 >>>>> "Brian" == (Brian E Carpenter) writes: >> - Steve Deering said: >> >> I wish to propose the following small change to the rules for >> manufacturing IPv6 addresses out of EUI-64 addresses: that the >> "u" (universal/local) bit in the EUI-64 address be *inverted* >> when forming the interface ID part of an IPv6 address, Brian> I really think this would cause so much confusion and so Brian> many coding errors over the next 50 years or so that we Brian> should definitely not do it. Brian, I think that is quite ok compared to the cost of teaching every user that he must make sure to lit the 'local' bit when configuring an address. Most people just won't know that they should do it and we will end up with an incredible number of globally unique '1's and '2's. Better spend the time explaining things to a few programmers than to users. Granted, some times we are not that clever, but i think we can manage to invert a bit in a word. Brian> I do understand the Brian> convenience argument, but imagine the confusion it would Brian> cause in low level debugging. I really don't see the problem. After you get the token and generate the lower part of the address you don't ever need to care about the interface linklayer address. Anyone that goes comparing IPv6 addresses to interface layer 2 addresses deserves to be shot anyway. regards, Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 23 12:29:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07061; Fri, 23 May 1997 12:20:56 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07054; Fri, 23 May 1997 12:20:44 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA19447; Fri, 23 May 1997 12:22:03 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA03231 for ; Fri, 23 May 1997 12:22:54 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id MAA24380 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id MAA16630 Posted-Date: Fri, 23 May 1997 12:22:10 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA18874; Fri, 23 May 1997 15:22:05 -0400 for Message-Id: <3.0.32.19970523152102.006c7d30@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 23 May 1997 15:21:07 -0400 To: brian@hursley.ibm.com From: Dimitry Haskin Subject: (IPng 3700) Re: indicating globicity Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1429 At 06:06 PM 5/23/97 +0100, (Brian E Carpenter) wrote: >>- Steve Deering said: >> >> I wish to propose the following small change to the rules for manufacturing >> IPv6 addresses out of EUI-64 addresses: that the "u" (universal/local) bit >> in the EUI-64 address be *inverted* when forming the interface ID part of >> an IPv6 address, > >I really think this would cause so much confusion and so many >coding errors over the next 50 years or so that we should >definitely not do it. I do understand the convenience argument, >but imagine the confusion it would cause in low level debugging. > I think a lot of confusion and coding errors bound to happen in either case. I easily can see non-global IDs that appears as global because implementations "forget" to set the bit on (actually, the opposite error would be less problematic). The future protocols that want to take advantage of the "u" bit are better be prepared to deal with this. Therefore I'd vote to do what is more convenient and sensible with what we already have. My $0.02. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 23 12:56:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07104; Fri, 23 May 1997 12:47:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07097; Fri, 23 May 1997 12:47:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA24244; Fri, 23 May 1997 12:48:59 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA10175 for ; Fri, 23 May 1997 12:49:50 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA01868; Fri, 23 May 97 12:45:32 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA14262; Fri, 23 May 1997 12:49:25 -0700 Date: Fri, 23 May 1997 12:49:25 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199705231949.MAA14262@feller.mentat.com> To: deering@cisco.com Subject: (IPng 3701) Re: indicating globicity Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 523 Steve, I see no problem with this modification. I agree with Pedro that the implementors should be able to get this right. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 23 14:01:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07315; Fri, 23 May 1997 13:51:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07308; Fri, 23 May 1997 13:51:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA07461; Fri, 23 May 1997 13:52:59 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA27554 for ; Fri, 23 May 1997 13:53:48 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id NAA26932; Fri, 23 May 1997 13:52:38 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <3.0.32.19970523152102.006c7d30@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 May 1997 13:52:50 -0700 To: Dimitry Haskin From: Steve Deering Subject: (IPng 3702) Re: indicating globicity Cc: brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 549 At 12:21 PM -0700 5/23/97, Dimitry Haskin wrote: > Therefore I'd vote to do what is more convenient and sensible with what we > already have. And what is that? 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 Fri May 23 15:07:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA07423; Fri, 23 May 1997 14:57:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA07416; Fri, 23 May 1997 14:57:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA21222; Fri, 23 May 1997 14:59:07 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA15727 for ; Fri, 23 May 1997 14:59:57 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id OAA29898 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id OAA14896 Posted-Date: Fri, 23 May 1997 14:58:47 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA06278; Fri, 23 May 1997 17:58:47 -0400 for Message-Id: <3.0.32.19970523175744.00687984@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 23 May 1997 17:57:44 -0400 To: Steve Deering From: Dimitry Haskin Subject: (IPng 3703) Re: indicating globicity Cc: Dimitry Haskin , brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 723 At 01:52 PM 5/23/97 -0700, Steve Deering wrote: >At 12:21 PM -0700 5/23/97, Dimitry Haskin wrote: >> Therefore I'd vote to do what is more convenient and sensible with what we >> already have. > >And what is that? > >Steve I guess I become a politician :) Well.. If you insist to know what I really think -- I support your proposal. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 26 11:19:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09500; Mon, 26 May 1997 11:11:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09493; Mon, 26 May 1997 11:11:14 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA18681; Mon, 26 May 1997 11:12:28 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA01591 for ; Mon, 26 May 1997 11:13:27 -0700 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA41747; Mon, 26 May 1997 19:12:50 +0100 Date: Mon, 26 May 1997 19:12:50 +0100 Message-Id: <9705261812.AA41747@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3705) Re: indicating globicity To: ipng@sunroof.eng.sun.com In-Reply-To: <199705231845.LAA13653@pedrom-ultra.cisco.com> from "Pedro Marques" at May 23, 97 11:45:49 am Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1162 > I really don't see the problem. After you get the token and generate the > lower part of the address you don't ever need to care about the interface > linklayer address. Anyone that goes comparing IPv6 addresses to interface > layer 2 addresses deserves to be shot anyway. Huh? Never had to resolve problems with LAN hardware that was inverting bits? I'm thinking about a poor service technician who has one bit pattern on a logic state analyser, a different one on a network analyser, and thinks that a bit has got flipped somehow. Don't say this won't happen; it will. That's the trade-off against users not setting the bit when they should - if they ever actually have to do it manually anyway. Oh well, I'm a lone voice it seems... 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 May 27 04:00:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA09975; Tue, 27 May 1997 03:52:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA09968; Tue, 27 May 1997 03:52:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA14388; Tue, 27 May 1997 03:53:19 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA22212 for ; Tue, 27 May 1997 03:54:20 -0700 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA22764; Tue, 27 May 1997 11:53:41 +0100 Date: Tue, 27 May 1997 11:53:41 +0100 Message-Id: <9705271053.AA22764@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3706) comments on To: ipng@sunroof.eng.sun.com Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7202 Hi, Some comments on Firstly it's a significant step forward... I am concerned that in one respect part of the baby was lost with the bathwater - to do with multihoming & renumbering; there are specific comments about this later. There are also two places where the material is much more appropriate for BCP than standards-track; I think the document has to be split in two for that reason; again there are specific comments about this. .... > addresses. Organizations who connect to these exchanges will also > subscribe (directly, indirectly via the exchange, etc.) for long- > haul service from one or more long-haul providers. Doing so, they > will achieve addressing independence from long-haul transit > providers. They will be able to change long-haul providers without > having to renumber their organization. They can also be multihomed > via the exchange to more than one long-haul provider without having > to have address prefixes from each long-haul provider. yes but - this leaves open the whole question of provider selection. That cannot be resolved in this document but at least you need to say: The way in which provider selection will be achieved for multihomed organizations is not discussed in this document. > IPv6 unicast addresses are designed assuming that the internet > routing system makes forwarding decisions based on a "longest prefix > match" algorithm on arbitrary bit boundaries and does not have any > knowledge of the internal structure of IPv6 addresses. The structure > in IPv6 addresses is for assignment and allocation. Not so. Assignment hierarchy has to match topology and renumbering is required when changing either exchange or upstream provider. These IPv6 addresses are *not* portable and this has to be nailed up very solidly in the spec. Add: However, aggregatable addresses as defined in this document are also designed to be topologically significant such that they can be scalably aggregated for routing purposes. For this reason, addresses are only portable as long as the organization concerned stays attached directly or indirectly to the same mid-level aggregator such as P2, P4 or X1 in the above example. .... > 3.2 Top-Level Aggregator > > Top-Level Aggregators (TLA) are the top level in the routing > hierarchy. Default-free routers will, at a minimum, have a routing > table entry for every active TLA. Again, you lost something in the bathwater. I'd suggest: hierarchy. Default-free routers MUST have a routing table entry for every active TLA. They MAY have additional entries, but routing topology at all levels MUST be designed to minimize the number of additional entries fed into the default-free routing tables. .... <> > The IANA will assign small blocks of TLAs to IPv6 registries. The > registries will assign the TLAs to organizations meeting the > requirements for TLAs. When the registries have assigned all of > their TLAs they can request that the IANA to give them another block. > The blocks do not have to be contiguous. The IANA may also assign > TLAs to organizations directly. > > TLA assignment requirements are as follows: > > - Must have a plan to offer public native IPv6 service within 6 > months from assignment. Plan must include plan for NLA > allocation. > > - Plan or track record providing public internet transit service to ***** on fair, reasonable and non-discriminatory terms^ > other providers. TLAs should not be assigned to organization that ^MUST NOT^ > are only providing leaf service even if multihomed. > - Must provide registry services for the NLA address space it is ***** on fair, reasonable and non-discriminatory terms^ > responsible for under its TLA. This must include both sites and > next level providers. > > - Must provide transit routing and forwarding to all assigned TLAs. ***** on fair, reasonable and non-discriminatory terms^ > Organization is not allowed to filter out any specific TLA's > (except temporarily for diagnostic purposes). or for emergency repair to services or emergency security protection. > - Periodically (interval set by registry) provide to registry > utilization statistics of the TLA it has custody of. The ^allocation > organization must also provide traffic statistics on amounts of > traffic for transit TLA traffic. You can't include that - it's illegal in some countries. > Organizations which are given custody of a TLA and fail to continue > to meet these (or other future requirements defined by the IANA) may > have the TLA custody revoked. Delete "future". You can't retrofit conditions to contracts <> .... > The NLA delegation works the the same manner as CIDR delegation in > IPv4 [CIDR]. ***** and MUST correspond to the routing topology as closely as possible. .... > of the previous level NLA. It is recommended that organizations > assigning NLA address space use "slow start" allocation procedures as > is currently done with IPV4 CIDR blocks. This is also BCP material, and it should be spelt out in a stand-alone way for IPv6, rather than a back-reference to a hopefully obsolete world. .... > The approach chosen for how to the structure of an SLA* field is the > responsibility of the individual organization. A large organization SHOULD use a hierarchical design corresponding as closely as possible to its routing topology. .... > serial links, tunnel end-points, etc.). Where EUI-64 identifiers are > used it is required that the "u" bit (universal/local bit in IEEE > EUI-64 terminology) be set correctly. Define "correctly" (especially if the consensus is to flip the bit). > The construction of Interface Identifiers constructed in EUI-64 > format is defined in [ARCH]. The details on forming interface > identifiers is defined in the appropriate "IPv6 over " > specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" > [FDDI], etc. I'd add as an FYI item that EUI-64 is a superset of 48-bit MAC space (and BTW does that mean that the "u" bit occurs twice?) > 6.0 Security Considerations > Documents of this type do not directly impact the security of the > Internet infrastructure or its applications. Hmm. Not sure that you can say as little as this. For example where in the IPv6 document set do we discuss address spoofing atacks? At least I'd be tempted to say (most everywhere, not just in this document) that IPv6 is intrinsically insecure unless IPSEC is switched on, and specifically that IPSEC can be used to mitigate address spoofing. Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 09:17:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10321; Tue, 27 May 1997 09:08:58 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10314; Tue, 27 May 1997 09:08:54 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA27010; Tue, 27 May 1997 09:10:39 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01646; Tue, 27 May 1997 09:09:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA07773; Fri, 23 May 1997 16:49:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA15242; Fri, 23 May 1997 16:50:27 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA11164 for ; Fri, 23 May 1997 16:51:17 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA21390 for ; Fri, 23 May 1997 16:50:44 -0700 Message-Id: <3.0.1.32.19970523160055.00756914@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 23 May 1997 16:00:55 -0700 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 3707) RFC 2147 on TCP and UDP over IPv6 Jumbograms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2515 A new Request for Comments is now available in online RFC libraries. RFC 2147: Title: TCP and UDP over IPv6 Jumbograms Author: D. Borman Date: May 1997 Mailbox: dab@bsdi.com Pages: 3 Characters: 6383 Updates: 1883 URL: ftp://ds.internic.net/rfc/rfc2147.txt This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. This document is a product of the IPng Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@CNRI.RESTON.VA.US. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Mary Kennedy USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 11:10:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10599; Tue, 27 May 1997 11:01:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10589; Tue, 27 May 1997 11:00:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA29605; Tue, 27 May 1997 11:02:07 -0700 Received: from muenster.westfalen.de (ns.westfalen.de [195.52.199.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA10660 for ; Tue, 27 May 1997 11:03:06 -0700 Received: from khms.westfalen.de by muenster.westfalen.de via rsmtp with bsmtp id for ; Tue, 27 May 1997 20:01:02 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #1 built 1996-Nov-13) Received: by khms.westfalen.de (CrossPoint v3.11 R/C435); 27 May 1997 19:57:33 +0200 Date: 27 May 1997 18:57:00 +0200 From: kai@khms.westfalen.de (Kai Henningsen) To: ipng@sunroof.eng.sun.com Message-ID: <6Xf3i1vjcsB@khms.westfalen.de> In-Reply-To: <3.0.32.19970522202327.006a6fd4@pobox> Subject: (IPng 3708) Re: New IPv6 Addressing Drafts X-Mailer: CrossPoint v3.11 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? References: <3.0.32.19970522202327.006a6fd4@pobox> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1639 dhaskin@BayNetworks.COM (Dimitry Haskin) wrote on 22.05.97 in <3.0.32.19970522202327.006a6fd4@pobox>: > >>P.S. The IPv6/PPP spec will allow what I'll make it to allow ;) > > > >So what is it going to be? > > > >Bob > > > > If an unique build-in MAC address is available on the node, it will be used > to form ID of a PPP interface using an EUI-64 format. Otherwise a random > number will be used to generate a local scope interface id. Hmm. This looks as if it will continue dynamic IP addresses into IPv6, even in cases where there are more than enough address bits available for static addresses (which should be most cases). Can we not do better? Dynamic IP numbers are evil. The way I understand the addressing draft, you MUST have an EUI-64, even for PPP. So someone would have to offer a block to choose random numbers from. Correct? It would be nice if people could get a fixed EUI-64 assignment for their box from somewhere. Since these numbers don't really mean anything, simply giving them out serially should be good enough. IIRC, one EUI-64 block has 2^40 (ca. 10^12) Ids, while we currently have under 10^10 people, which means around 100 ids per person un one block. Which means one block should last a long time. MfG Kai -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 11:23:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10617; Tue, 27 May 1997 11:14:33 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10610; Tue, 27 May 1997 11:14:20 -0700 Received: from bobo by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17316; Tue, 27 May 1997 11:16:04 -0700 Date: Tue, 27 May 1997 11:16:04 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 3709) Re: indicating globicity To: Steve Deering Cc: ipng@sunroof.eng.sun.com, nordmark@jurassic In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1876 > I wish to propose the following small change to the rules for manufacturing > IPv6 addresses out of EUI-64 addresses: that the "u" (universal/local) bit > in the EUI-64 address be *inverted* when forming the interface ID part of > an IPv6 address, so that a bit value of 1 would indicate that the > interface ID field can be used as globally-unique node ID, and a bit value > of 0 would indicate that the interface ID cannot be considered globally > unique. > > [...] > > This change would also restore the ability to use a subnet prefix with > a zero-valued interface-id as the well-known anycast address for the set > of routers attached to a subnet. (Note that the interface ID field of > an IPv6 anycast address that is intended to be assigned to more than one > node must not be interpretable as a unique node ID!) Don't we still need some way of providing per-link uniqueness for the local interface IDs? The organization that owns the all-zeros OUI might very well decide to use its part of the EUI-64 space with the local bit set for some other purpose that might cause collisions with the all-zeros subnet anycast address. I think there is a fundamental problem that IEEE owns the number space for IEEE 802 and EUI-64 addresses thus if we want to assign anything from this space (universal or local) we need to do it from a properly acquired part of the IEEE number space. Assuming that nobody will be using IEEE addresses with the local bit set seems fragile to me. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 12:07:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10698; Tue, 27 May 1997 11:58:20 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10689; Tue, 27 May 1997 11:58:09 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA13891; Tue, 27 May 1997 11:59:21 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA29081; Tue, 27 May 1997 12:00:23 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id LAA27817; Tue, 27 May 1997 11:59:46 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: References: "Your message with ID" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 May 1997 11:59:56 -0700 To: Erik Nordmark From: Steve Deering Subject: (IPng 3710) Re: indicating globicity Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2222 Erik, > The organization that owns the all-zeros OUI might very well decide to use > its part of the EUI-64 space with the local bit set for some other purpose > that might cause collisions with the all-zeros subnet anycast address. There's no required relationship between the "interface ID" field of an IPv6 anycast address and any MAC-layer address. > I think there is a fundamental problem that IEEE owns the number space > for IEEE 802 and EUI-64 addresses thus if we want to assign anything from > this space (universal or local) we need to do it from a properly acquired > part of the IEEE number space. But we're talking about the IPv6 address space. IPv6 addresses with the global bit set (as proposed) take their interface IDs from the universal EUI-64 space; IPv6 addresses with the global bit cleared do *not* necessarily take their interface IDs from the non-universal EUI-64 space, but rather from the space of the IPv6 subnet in which they are allocated. > Assuming that nobody will be using IEEE addresses with the local bit set > seems fragile to me. I am not assuming that. Rather, I am assuming that on a link that uses non-universal IEEE 802 or EUI-64 MAC address with an all-zeroes OUI, IPv6 interface IDs are *not* autoconfigured from those MAC address. At worst, that may inconvenience whichever organization it is that owns the all- zeroes OUI. (I wonder if that organization is my previous employer? :-) (Question: when IEEE assigns an OUI, is that understood to include both the universal space and the local space containing that OUI, or is it an assignment of some universal space only?? Or, in other words, is the purpose of the IEEE registry solely to allocate the universal space? Why would you need a global registry for local address space, given that it its use is a local concern only?) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 12:25:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10718; Tue, 27 May 1997 12:17:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA10711; Tue, 27 May 1997 12:16:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA18434; Tue, 27 May 1997 12:18:02 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA05043 for ; Tue, 27 May 1997 12:19:04 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id MAA16534 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id MAA02935 Posted-Date: Tue, 27 May 1997 12:18:18 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA15535; Tue, 27 May 1997 15:18:18 -0400 for Message-Id: <3.0.32.19970527151724.006a1c74@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 27 May 1997 15:17:25 -0400 To: kai@khms.westfalen.de (Kai Henningsen) From: Dimitry Haskin Subject: (IPng 3711) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2127 At 06:57 PM 5/27/97 +0200, Kai Henningsen wrote: >dhaskin@BayNetworks.COM (Dimitry Haskin) wrote on 22.05.97 in <3.0.32.19970522202327.006a6fd4@pobox>: > >> >>P.S. The IPv6/PPP spec will allow what I'll make it to allow ;) >> > >> >So what is it going to be? >> > >> >Bob >> > >> >> If an unique build-in MAC address is available on the node, it will be used >> to form ID of a PPP interface using an EUI-64 format. Otherwise a random >> number will be used to generate a local scope interface id. > >Hmm. This looks as if it will continue dynamic IP addresses into IPv6, >even in cases where there are more than enough address bits available for >static addresses (which should be most cases). > >Can we not do better? Dynamic IP numbers are evil. > >The way I understand the addressing draft, you MUST have an EUI-64, even >for PPP. So someone would have to offer a block to choose random numbers >from. Correct? > Incorrect. This is only true for global scope interface ids. A local scope interface id can be any number that is unique on the link. >It would be nice if people could get a fixed EUI-64 assignment for their >box from somewhere. Since these numbers don't really mean anything, simply >giving them out serially should be good enough. > You always have the option to use manual configuration, DHCP or some other stateful configuration tools to get ids for your box. Random numbers are only for those cases where there is no build-in mac address and stateless address autoconfiguration is desirable. >IIRC, one EUI-64 block has 2^40 (ca. 10^12) Ids, while we currently have >under 10^10 people, which means around 100 ids per person un one block. >Which means one block should last a long time. > >MfG Kai Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 13:22:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10802; Tue, 27 May 1997 13:12:25 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10795; Tue, 27 May 1997 13:12:15 -0700 Received: from bobo by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04547; Tue, 27 May 1997 13:14:00 -0700 Date: Tue, 27 May 1997 13:13:59 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 3712) Site-level aggregators in draft-ietf-ipngwg-unicast-aggr-00.txt To: ipng@sunroof.eng.sun.com Cc: nordmark@jurassic Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1281 In the draft-ietf-ipngwg-unicast-aggr-00.txt the Site-Level Aggregator(s) are described. Would it make sense to add a reference to RFC-1219 as a possible technique for partitioning this field in a hierahical fashion while allowing for growth? It would be good it we could add some recommendations so that large sites can make informed decisions about how to address their internal topology. Without some more concrete examples I'm concerned that sites will start off with a flat "subnet" number space for IPv6 (subnet 0, 1, 2, ...). For some (many?) large sites such a scheme will scale a lot less than internal IPv4 subnetting which does provide a two-level internal hierarchy today in those sites. Thus should we issue a variant of RFC-1219 that describes how to do a two-level hiearchy in the site-level aggregator field? Erik RFC-1219 P. Tsuchiya "On the assignment of subnet numbers" -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 13:23:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10811; Tue, 27 May 1997 13:13:01 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10804; Tue, 27 May 1997 13:12:47 -0700 Received: from bobo by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04618; Tue, 27 May 1997 13:14:29 -0700 Date: Tue, 27 May 1997 13:14:29 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 3713) Re: indicating globicity To: Steve Deering Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1190 > There's no required relationship between the "interface ID" field of an > IPv6 anycast address and any MAC-layer address. I think we are in violent agreement. The issue is how to ensure that an IPv6 address, formed using stateless addrconf using the token for any link layer, is never identical to any well-defined IPv6 anycast address. > But we're talking about the IPv6 address space. IPv6 addresses with the > global bit set (as proposed) take their interface IDs from the universal > EUI-64 space; IPv6 addresses with the global bit cleared do *not* > necessarily take their interface IDs from the non-universal EUI-64 space, > but rather from the space of the IPv6 subnet in which they are allocated. Ah. The last part of the sentence was not clear and obvious to me hence the confusion. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 13:45:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10896; Tue, 27 May 1997 13:36:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10889; Tue, 27 May 1997 13:36:35 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA05488; Tue, 27 May 1997 13:37:49 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA27443 for ; Tue, 27 May 1997 13:38:48 -0700 Received: from ftp.com by ftp.com ; Tue, 27 May 1997 16:38:12 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 27 May 1997 16:38:12 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id QAA12384; Tue, 27 May 1997 16:34:38 -0400 Message-Id: <199705272034.QAA12384@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 3714) proposal for RFC-1897 update Date: Tue, 27 May 1997 16:38:11 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1844 Folks -- In order to support a 64-bit End System Designator, we'll have to modify the way that we're generating IPv6 test addresses. We also want to renumber the addresses on the 6bone soon so that we can realize better rout= e aggregation on the nodes which are providing the backbone service to the re= st of the net. The address format I'd like to propose is the following: 5FFC:vvvv:nnnn:nnnn:eeee:eeee:eeee:eeee "5f": from RFC-1897, "fc": Guidelines for Creation of an AS (RFC-1930) states that AS numbers 0xFC00-0xFFFF are reserved, so we can avoid colliding with addresses generated by RFC-1897 by using a value out of the reserved space. The values 'fd'-'ff' can be used for a future IPv6 address generation procedure we may need to use in the future without falling out of the '5f' address space. vvvv: 16-bit virtual AS number. The sites that are acting as IPv6 ISPs would be assigned a constant value, nodes connecting though the ISP would use the same virtual AS number as the IPv6 ISP instead of the AS number used for IPv4 connectivity. Should a site become dual- connected relative to the 6-backbone, it would then have addresses under both virtual AS number. nnnn:nnnn: 32-bit IPv4 network number. The site's left-justified IPv4 (sub)network number, allows networks smaller than /24 to define their IPv6 address. eeee:eeee:eeee:eeee: 64-bit End System Designator. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 14:25:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11023; Tue, 27 May 1997 14:15:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11016; Tue, 27 May 1997 14:15:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA15137; Tue, 27 May 1997 14:16:50 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA10048 for ; Tue, 27 May 1997 14:17:50 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA11985; Tue, 27 May 1997 14:17:13 -0700 Message-Id: <3.0.1.32.19970527141743.007698ec@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 27 May 1997 14:17:43 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 3715) New Version of "IPv6 Testing Address Allocation" Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 672 A new version of "IPv6 Testing Address Allocation" was submitted to be an internet draft. Until it is out as an internet draft it can be found at: ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-test-addr-alloc-01.txt This draft is based on the new aggregatable address format. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 14:30:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11032; Tue, 27 May 1997 14:20:09 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11025; Tue, 27 May 1997 14:19:55 -0700 Received: from bobo by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA17586; Tue, 27 May 1997 14:21:39 -0700 Date: Tue, 27 May 1997 14:21:13 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 3716) Re: Comments on advance API draft To: rstevens@kohala.com Cc: ipng@sunroof.eng.sun.com, matt.thomas@altavista-software.com, nordmark@jurassic In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 14167 > [In your message of May 21, 6:47pm Richard wrote:] > What the API does not provide, and I think it says so clearly, is a > completely raw packet with all the extension headers intact. The > extension headers are all pulled out and returned as ancillary data. I think it said it clearly for receive but not so clearly for transmit. > > Finally, does a raw socket automatically insert fragmentation headers > > when the application sends something larger than the path MTU? > > I assume (although it is not stated anywhere to my knowledge) that UDP > > does this. But the raw socket case needs to be stated since different > > implementors and different users might have different perspectives > > on how raw a raw socket really is. > > I would assume so. So perhaps the document should state that a raw AF_INET6 socket will insert fragmentation headers when they are needed. > > Security: > > --------- > > In IPv4 an application can not use UDP or TCP sockets to send packets > > with a bogus source address. The mechanism specified in section 5.2 > > allows an application to specify any source address when sending data. > > Thus I think we need to require in section 5.2 that the kernel verify > > that the source address is indeed a unicast address assigned to the machine. > > Fine. > > > Unclear things: > > --------------- > > > > Section 3.1 specifies how a raw socket can be told to compute > > checksums on transmit but it does not state if the kernel will > > verify checksums on receipt. Please clarify in the document. > > Fine. The kernel should verify the received checksum. Are you saying (just to make sure) that the checksum option will have the combined effect of specifing the location of the checksum field on transmit and also tell the kernel to drop all packets that do not have a correct checksum? > I think the 4th paragraph in Section 3 (that we already discussed > above) is clear on this: you do not get the actual IP header like > IPv4. Everything other than the version number is available as > ancillary data or as part of the returned socket address structure. What about a packet that contained a frag extension? Does the document need to state that the fragmentation extension hdr is removed before passing a packet to a raw socket? > > Section 5.5 specifies new errors for sendmsg. Presumably they also > > apply to setsockopt(IPV6_PKTOPTIONS). But, more importantly > > there is a class of implementations (such as STREAMS based implementations) > > where sendmsg can not return any errors from the IP layer. > > Thus it might make sense to point out that "additional errors > > might occur on some implementations" or something like it. > > I think the introductory paragraph on p. 6 covers this ("We note ... may > have error returns that are not defined in this document. ..."). To me that says something completely different namely that an implementation might return additional error codes. I didn't see that the text said that the specified errors were completely optional. > > The second (and 4th) bullet in section 6 talks about uniqueness of flow labels. > > Don't they also have to be unique for a given routing header and hop-by-hop > > options header? > > Yes, as stated in the first paragraph of Section 6. The purpose of this > introductory discussion in Section 6 is *not* to define the flow label > (RFC 1883 does that) but to give some motivation as to why the functions > that are described were designed the way they were. Then I'm confused by the destination address is included in some of the flow lable APIs but the source route isn't included. I think we either need an API that allows me to ask for a flow label that it uniq for a given source address and it is up to the application to follow the rules (keep dest and routing header identical etc) or we need an API where you specify all the parts of the header that has to be constant for the flow label you want to allocate. But as far as I understand the "specify everything" isn't needed since the kernel still has to allocate uniq flow labels per source address. > That icmp6_filter example, is explicitly noted as an example. No one > should be using the contents of the structure, and that's why the six > macros are defined. The problem is not with applications using the contents of the structure (they shouldn't). The problem is if implementors use the example code in their implementation. Then if they want to conform to some X/Open or Posix standard they will have to make their headers files even more unreadable. We currently have lots of header files that read for example: #if !defined(_XPG4_2) || defined(__EXTENSIONS__) typedef struct fd_set { #else typedef struct __fd_set { #endif I'd like to avoid such ugliness in the future by making sure that the example has the needed underscores for the name space issues. > > Choice of names: > > ---------------- > > Erik: why are you bringing this up seven months after the names were > first proposed, and almost two weeks after the last call ended? > Yes, some of the names are not "perfect" but there have been few > complaints. Craig Metz didn't like some last Fall and he and Matt > worked out some changes that went into the -01 draft. That's been it > for the complaints. I agree that it would have been better to bring up this (actually, all my comments) many months ago. But if there is a good reason for contemplating some of these changes it is a lot better to do it now that later. So it is all a judgement call on the cost/benefit tradeoffs of doing the changes. On the cost side I think the number of implementations of this API as specified in -07 are relatively limited at the moment thus, just like with the basic API specification over the last year, we have the opportunity to come up with an API specification that folks are confortable with and that we feel would be a good document to pass to the appropriate API standards body. > For what it's worth, I really don't care about the names at all, as > long as all the implementations use the same names for the same things. > My interest is in using this API to write applications; I don't have a > vested interest in any one implementation. > > Is there a consensus with others to go back and revisit all the names > in here and make them more consistent? Me need to do some cleanup of some of the names to deal with name space issues in any case so at least for those we'll end up revisiting this. > We can call them macros if you'd like. I tend to call everything a > function these days, trying not to avoid "system call" and "macro", > since the distinction is often an implementation detail. Just look > at the numer of all-lower-case macros in most headers. > If we say "macro" then we're forcing it to be implemented as a macro, > aren't we? Yes, I think we are forcing it to be a macro. But an implementation can always say #define FOO(x, y) __foo(x, y) and it will have implemented the FOO macro. The standards body that will look at this document does make the distinction between macros and functions and macros tend to be upper case. For instance the Posix P1103.1g draft states that CMSG_DATA(cmsg) is a macro. However, this type of standards allow implementations to use macros instead of functions. For example, the X/Open sock speification states that "The following are declared as functions, and may also be defined as macros:" and goes on with the function prototypes for accept, bind etc. > > In section 4.4 it talks about returning ancillary data with recvmsg and > > later insection 4.5 it says that this only applies to UDP and not TCP. > > At least section 4.4 has to say that the recvmsg only applies to UDP, > > or perhaps better, have section 4.4 state how 1) the stack is configured > > to receive options and 2) how options are formatted for transmission > > and then separately state that for UDP recvmsg returns them as ancillary data > > and with TCP one can use getsockopt(IPV6_PKTOPTIONS) to retrieve them. > > Based on what we do with sendmsg and TCP the same might apply to sendmsg. > > I'm not sure what you're stating here. I'll try again. I section 4.4 you state: When any of these options are enabled, the corresponding data is returned as control information by recvmsg(), as one or more ancillary data objects. Then in section 4.5 you say: The summary in the previous section assumes a UDP socket. Sending and receiving ancillary data is easy with UDP: the application calls sendmsg() and recvmsg() instead of sendto() and recvfrom(). This "by the way the text above was incorrect" style of writing makes the document hard to read in my opinion. At a minumum the text in section 4.4 should have a "for UDP sockets" added. But to make it easier to read it would make sense to have section 4.4 be generic to UDP and TCP by e.g. using text like: When any of these options are enabled, the corresponding data is returned. Depending on the type of socket it can be returned either as control information by recvmsg(), as one or more ancillary data objects, or with getsockopt() using the IPV6_PKTOPTIONS. Then you can have specific sections (perhaps with examples) on how to receive the information with UDP and TCP. > > In section 4.4 (and elsewhere) it might be good to note the overloading > > of the option names. > > When e.g. IPV6_HOPLIMIT is used in a setsockopt it only enables > > the receipt of the hoplimit information. When it is used in ancillary data > > or as part of a IPV6_PKTOPTIONS set/getsockopt it contains the actual hop > > limit. > > I think p. 23 sums this up adequately: in one case it's the option name > for [sg]etsockopt(), and it's also used as the cmsg_type value. It wasn't immediately obvious to me in reading the document thus it might make sense to add some redundancy to make this more clear to the naive socket programmer. > > The text in section 5.2 and 5.3 talk in terms of ancillary data and > > sendmsg/recvmsg only. It fails to mention setting and retriving the info > > with IPV6_PKTOPTIONS. > > We don't mention IPV6_PKTOPTIONS in Sections 7, 8, or 9 either. Perhaps > in Section 4.5 we should be more explicit that it applies to the six types > of ancillary data mentioned at the top of p. 23. That doesn't help the reader that looks for e.g. how to use hop-by-hop options and finds that section 7 says to use ancillary data with sendmsg and recvmsg. I think it would make sense to state section 5.2, 5.3, 7, 8, 9 in general terms of how to send and receive the info perhaps with references to section 4.* for how to do this for UDP and TCP. > > In section 5.4 it says "This is a priviledged option." but I can't find > > anything in the document that defines what a priviledged option is. > > Correct, and I think that's out of the scope of this document. I think > anyone implementing this will know how it applies to their system. I agree. But I'd like the document be well-written enough that some API standards body can pick it up and more or less bless it thus it would be good if there aren't undefined terms. I guess we can leave this one for now. > > The title for section 9 is "source routing option". No such thing > > exists in IPv6. IPv6 does have a "routing header" so perhaps that > > is a better name. > > ... > > I wonder if the inet6_srcrt_* function (for the same reason) should be > > renamed to inet6_routing_* (or inet6_rthdr_*?). > > Well, we were using the commonly-used term, realizing that this document > is not the authoritative spec for the protocol. I also notice that all > of the drafts leading to RFC 2133, when they specified this capability, > all used "source route". I don't have old enough drafts around to verify. But RFC 2133 doesn't mention source routing. Looking at RCC 1883 it is careful to never mention source routing in the IPv6 context. Thus even if this isn't a protocol specification it would make sense to use the same terminology as the protocol specification to reduce any confusion. BTW: I think although this might be viewed as nit-picking, this kind of review is needed to produce good specifications. > In the Advanced API draft there are 15 references to "source route" > (and 91 to "routing header") but if there's a consensus that our use > of "source route" is a no-no, I'll gladly change them. (Humm, I just > found an index entry in Christian's book for "source routes". :-) ) If we really want two terms (and it is better to only have one) you could view "source routing" as a feature provided by the IPv6 "routing header". But I think the routines that manipulate the routing header should still have a name tied to "routing header". > > Finally some suggestions for the unfinished items in section 13. > > ---------------------------------------------------------------- > > Path mtu discovery. > > ... > > NUD reachability confirmations. > > ... > > I am going to pass on these for now, as you are the first to make a > proposal in these two areas. Yes, something will be needed here, but > the goal now is to get the Advanced API out, so vendors can start > using it. Francis Dupont and Steve Wise both asked a few weeks ago > (when the last call was sent out) if finishing this draft right now > was premature, and the consensus (100% of the four replies :-) ) was > that the draft should be finished and published as an informational > RFC and that implementations are underway of significant portions > of the draft. Well, in the ietf tradition it might make more sense to implement the draft before making it to an informational RFC. But I agree that while the above missing pieces need to be addressed they are not critical at the moment. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 14:47:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11090; Tue, 27 May 1997 14:38:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11083; Tue, 27 May 1997 14:37:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA20647; Tue, 27 May 1997 14:39:07 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA17060 for ; Tue, 27 May 1997 14:40:09 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id OAA13642; Tue, 27 May 1997 14:39:28 -0700 Message-Id: <3.0.1.32.19970527144011.0077b118@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 27 May 1997 14:40:11 -0700 To: Frank T Solensky From: Bob Hinden Subject: (IPng 3717) Re: proposal for RFC-1897 update Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199705272034.QAA12384@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 659 Frank, I just submitted a new version of "IPv6 Testing Address Allocation" which allows test address to be formed based on the new aggregatable address formats and 64bit identifiers. If the 6bone folks wish to do something more short term, your proposal looks fine to me. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 15:03:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11153; Tue, 27 May 1997 14:55:29 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11141; Tue, 27 May 1997 14:55:15 -0700 Received: from bobo by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA23108; Tue, 27 May 1997 14:56:59 -0700 Date: Tue, 27 May 1997 14:56:59 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 3718) Re: Comments on advance API draft To: Matt Thomas Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, "W. Richard Stevens" In-Reply-To: "Your message with ID" <3.0.1.32.19970522135914.0072da80@ranier.altavista-software.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2696 > The rule is "ancillary data overrides sticky options". This is actually > simplier otherwise we have to discuss how to merge options specified via > setsockopt with those by sendmsg(). Which go first, etc.? It seemed > simplier to me to simple have ancillary occlude the setsockopt options. The document doesn't seem to say that. The last paragraph in section 4.5 (to the extent I can parse it) seems to say that hop-by-hop, destination and routing headers are different. Could you clarify this in the spec? Your proposal makes sense to me as long as you carefully specify what "override" means. For example I think the document should answer questions like: - If I set a routing header with setsockopt and pass down some ancillary data with sendmsg but then ancillary data does not include the an IPV6_SRCRT option is the setsockopt overridden? (I assume the answer is no but the document needs to be clear on this point.) - The IPV6_PKTINFO contains both interface and and source address info. How does "override" work in that case? If there is an IPV6_PKTINFO in sendmsg override both the interface and source address set with setsockopt? Or can I set the interface with setsockopt (leaving ipi6_addr as in6addr_any) and orthogonally specify the source address with sendmsg (specifying the ipi6_ifindex as zero)? The above level of detail needs to be specified in the document to make it possible for portable programs to use the "override" feature. > I defined them to return errors (instead of setting errno) to make > them more thread-friendly. 1003.1d uses the convention of returning > error codes and since we have the benefit of their work, I decided to > follow their lead. And I did not have backwards compatibility to > worry about. I'm more concerned about internal consistency among the inet6_* functions defined in the document. As far as I can tell none of them update the errno variable which is good. However, a followon question is why only inet6_srcrt_add and inet6_srcrt_reverse use the E* error returns. For instance, inet6_srcrt_space can fail either due to "unsupported type of routing header" or "too large number of segments" but it doesn't distinguish between the two. The same is true for inet6_srcrt_segments. This seems incomplete. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 28 05:05:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA12076; Wed, 28 May 1997 04:56:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA12069; Wed, 28 May 1997 04:56:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA02805; Wed, 28 May 1997 04:57:40 -0700 Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA24106 for ; Wed, 28 May 1997 04:58:40 -0700 Received: from rama.imag.fr (rama.imag.fr [129.88.30.9]) by imag.imag.fr (8.8.1/8.6.9) with ESMTP id NAA18178; Wed, 28 May 1997 13:57:54 +0200 (MET DST) Received: (from durand@localhost) by rama.imag.fr (8.8.5/8.8.5) id NAA02558; Wed, 28 May 1997 13:57:53 +0200 (MET DST) From: "Alain Durand" Message-Id: <970528135753.ZM2552@rama.imag.fr> Date: Wed, 28 May 1997 13:57:53 +0200 In-Reply-To: Bob Hinden "(IPng 3717) Re: proposal for RFC-1897 update" (May 27, 2:40pm) References: <3.0.1.32.19970527144011.0077b118@mailhost.ipsilon.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: 6bone@isi.edu, Bob Hinden , Frank T Solensky Subject: (IPng 3719) Re: proposal for RFC-1897 update Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2665 On May 27, 4:38pm, Frank T Solensky wrote: > Subject: (IPng 3714) proposal for RFC-1897 update > Folks -- > In order to support a 64-bit End System Designator, we'll have to > modify the way that we're generating IPv6 test addresses. We also want to > renumber the addresses on the 6bone soon so that we can realize better route > aggregation on the nodes which are providing the backbone service to the rest > of the net. > The address format I'd like to propose is the following: > > 5FFC:vvvv:nnnn:nnnn:eeee:eeee:eeee:eeee > > "5f": from RFC-1897, > "fc": Guidelines for Creation of an AS (RFC-1930) states that AS numbers > 0xFC00-0xFFFF are reserved, so we can avoid colliding with addresses > generated by RFC-1897 by using a value out of the reserved space. > The values 'fd'-'ff' can be used for a future IPv6 address generation > procedure we may need to use in the future without falling out of the > '5f' address space. > vvvv: 16-bit virtual AS number. The sites that are acting as IPv6 ISPs > would be assigned a constant value, nodes connecting though the ISP > would use the same virtual AS number as the IPv6 ISP instead of the > AS number used for IPv4 connectivity. Should a site become dual- > connected relative to the 6-backbone, it would then have addresses > under both virtual AS number. > nnnn:nnnn: 32-bit IPv4 network number. The site's left-justified IPv4 > (sub)network number, allows networks smaller than /24 to define their > IPv6 address. > eeee:eeee:eeee:eeee: 64-bit End System Designator. On May 27, 2:40pm, Bob Hinden wrote: > Subject: (IPng 3717) Re: proposal for RFC-1897 update > Frank, > > I just submitted a new version of "IPv6 Testing Address Allocation" which > allows test address to be formed based on the new aggregatable address > formats and 64bit identifiers. If the 6bone folks wish to do something > more short term, your proposal looks fine to me. I've just read Bob proposal (draft-ietf-ipngwg-test-addr-alloc-01.txt). Sounds like a very good start to me for the new addressing plan of the 6-bone. If our registry can allocate NLAs (possibly to core 6bone sites), I think we can move very quickly to this new addressing plan. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 28 06:56:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA12195; Wed, 28 May 1997 06:48:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA12188; Wed, 28 May 1997 06:48:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA16404; Wed, 28 May 1997 06:49:18 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA17660 for ; Wed, 28 May 1997 06:50:24 -0700 Received: from ietf.ietf.org by ietf.org id aa10771; 28 May 97 9:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3720) I-D ACTION:draft-ietf-ipngwg-testv2-addralloc-00.txt Date: Wed, 28 May 1997 09:49:34 -0400 Message-ID: <9705280949.aa10771@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4018 --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 Testing Address Allocation Author(s) : R. Hinden, R. Fink, J. Postel Filename : draft-ietf-ipngwg-testv2-addralloc-00.txt Pages : 4 Date : 05/27/1997 This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. This document is intended to replace RFC1897 "IPv6 Testing Address Allocation", January 1996. RFC1897 will become historic. Internet-Drafts are 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-testv2-addralloc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970527174021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-testv2-addralloc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970527174021.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 28 08:08:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12293; Wed, 28 May 1997 08:01:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12286; Wed, 28 May 1997 08:00:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA06077; Wed, 28 May 1997 08:02:02 -0700 Received: from milan.doe.ernet.in ([202.41.99.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09086 for ; Wed, 28 May 1997 08:03:00 -0700 Received: from cdacb.ernet.in by milan.doe.ernet.in (4.1/SMI-4.1) id AA29227; Wed, 28 May 97 20:34:14+050 Received: from mail-relay-BLR.ernet.in ([202.141.1.4]) by cdacb.ernet.in (5.x/SMI-SVR4) id AA04583; Wed, 28 May 1997 20:24:34 -0500 Received: from ietf.org (ietf.org [132.151.1.19]) by mail-relay-BLR.ernet.in (8.6.11/8.6.9) with SMTP id SAA21207 for ; Wed, 28 May 1997 18:58:50 +0530 Received: from ietf.org by ietf.org id aa10953; 28 May 97 9:52 EDT Received: from ietf.ietf.org by ietf.org id aa10771; 28 May 97 9:49 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 3721) I-D ACTION:draft-ietf-ipngwg-testv2-addralloc-00.txt Date: Wed, 28 May 1997 09:49:34 -0400 X-Orig-Sender: cclark@ietf.org Message-Id: <9705280949.aa10771@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4018 --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 Testing Address Allocation Author(s) : R. Hinden, R. Fink, J. Postel Filename : draft-ietf-ipngwg-testv2-addralloc-00.txt Pages : 4 Date : 05/27/1997 This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. This document is intended to replace RFC1897 "IPv6 Testing Address Allocation", January 1996. RFC1897 will become historic. Internet-Drafts are 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-testv2-addralloc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19970527174021.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-testv2-addralloc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-testv2-addralloc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970527174021.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 28 16:25:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA12933; Wed, 28 May 1997 15:00:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA12926; Wed, 28 May 1997 14:59:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA17042; Wed, 28 May 1997 15:01:03 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA21057 for ; Wed, 28 May 1997 15:02:08 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA03236; Wed, 28 May 1997 15:01:27 -0700 Message-Id: <3.0.1.32.19970528150211.007666a8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 28 May 1997 15:02:11 -0700 To: brian@hursley.ibm.com From: Bob Hinden Subject: (IPng 3722) Re: comments on Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 8587 Brain, Thanks for the thoughtful comments. >I am concerned that in one respect part of the baby was lost >with the bathwater - to do with multihoming & renumbering; >there are specific comments about this later. > >There are also two places where the material is much more >appropriate for BCP than standards-track; I think the document >has to be split in two for that reason; again there are >specific comments about this. I came to the same conclusion, but thought it best to initially keep it together for ease of review. One the content is a bit more settled, I would be happy to split it into two documents. >.... >> addresses. Organizations who connect to these exchanges will also >> subscribe (directly, indirectly via the exchange, etc.) for long- >> haul service from one or more long-haul providers. Doing so, they >> will achieve addressing independence from long-haul transit >> providers. They will be able to change long-haul providers without >> having to renumber their organization. They can also be multihomed >> via the exchange to more than one long-haul provider without having >> to have address prefixes from each long-haul provider. > >yes but - this leaves open the whole question of provider selection. >That cannot be resolved in this document but at least you need to say: > > The way in which provider selection will be achieved for multihomed > organizations is not discussed in this document. OK. >> IPv6 unicast addresses are designed assuming that the internet >> routing system makes forwarding decisions based on a "longest prefix >> match" algorithm on arbitrary bit boundaries and does not have any >> knowledge of the internal structure of IPv6 addresses. The structure >> in IPv6 addresses is for assignment and allocation. > >Not so. Assignment hierarchy has to match topology and renumbering >is required when changing either exchange or upstream provider. These >IPv6 addresses are *not* portable and this has to be nailed up >very solidly in the spec. Add: This paragraph is saying that implementations (e.g., code) are not aware of the boundaries. The boundaries are there for address allocation. The routing system works on addresses and masks. Yes, the assignment does have to match the topology. > However, aggregatable addresses as defined in this document are > also designed to be topologically significant such that they can > be scalably aggregated for routing purposes. For this reason, addresses > are only portable as long as the organization concerned stays attached > directly or indirectly to the same mid-level aggregator such as > P2, P4 or X1 in the above example. I can add more detail on portability, etc. >.... >> 3.2 Top-Level Aggregator >> >> Top-Level Aggregators (TLA) are the top level in the routing >> hierarchy. Default-free routers will, at a minimum, have a routing >> table entry for every active TLA. > >Again, you lost something in the bathwater. I'd suggest: > > hierarchy. Default-free routers MUST have a routing > table entry for every active TLA. They MAY have additional > entries, but routing topology at all levels MUST be designed > to minimize the number of additional entries fed into the > default-free routing tables. I will add the elaboration as you suggest. >> TLA assignment requirements are as follows: >> >> - Must have a plan to offer public native IPv6 service within 6 >> months from assignment. Plan must include plan for NLA >> allocation. >> >> - Plan or track record providing public internet transit service to >***** on fair, reasonable and non-discriminatory terms^ Good idea. >> other providers. TLAs should not be assigned to organization that > ^MUST NOT^ Good. >> are only providing leaf service even if multihomed. > >> - Must provide registry services for the NLA address space it is >***** on fair, reasonable and non-discriminatory terms^ >> responsible for under its TLA. This must include both sites and >> next level providers. >> >> - Must provide transit routing and forwarding to all assigned TLAs. >***** on fair, reasonable and non-discriminatory terms^ >> Organization is not allowed to filter out any specific TLA's >> (except temporarily for diagnostic purposes). >or for emergency repair to services or emergency security protection. Good on all of above. >> - Periodically (interval set by registry) provide to registry >> utilization statistics of the TLA it has custody of. The > ^allocation >> organization must also provide traffic statistics on amounts of >> traffic for transit TLA traffic. > >You can't include that - it's illegal in some countries. What is illegal in some countries? Utilization statistics or traffic statistics, or both? Why? >> Organizations which are given custody of a TLA and fail to continue >> to meet these (or other future requirements defined by the IANA) may >> have the TLA custody revoked. > >Delete "future". You can't retrofit conditions to contracts I can try can't I :-) ><> > >.... >> The NLA delegation works the the same manner as CIDR delegation in >> IPv4 [CIDR]. >***** and MUST correspond to the routing topology as closely > as possible. I think that at this level in the routing hierarchy it is a tradeoff of routing aggregation v.s. routing/assignment flexibility. As long as the NLA routing does not propagate to the top level, then this is a tradeoff which belongs to the organization responsible for the specific NLA. I could add some words to that effect. >.... >> of the previous level NLA. It is recommended that organizations >> assigning NLA address space use "slow start" allocation procedures as >> is currently done with IPV4 CIDR blocks. > >This is also BCP material, and it should be spelt out in a stand-alone >way for IPv6, rather than a back-reference to a hopefully obsolete world. Does the NLA stuff have to be in a separate BCP from the TLA or could they be combined? >> The approach chosen for how to the structure of an SLA* field is the >> responsibility of the individual organization. > > A large organization SHOULD use a hierarchical design > corresponding as closely as possible to its routing > topology. As above, there is a tradeoff which should be left to the site. How much do you think needs to be said? >> serial links, tunnel end-points, etc.). Where EUI-64 identifiers are >> used it is required that the "u" bit (universal/local bit in IEEE >> EUI-64 terminology) be set correctly. > >Define "correctly" (especially if the consensus is to flip the bit). Correctly as defined in [ARCH] (as below). I will clarify this. >> The construction of Interface Identifiers constructed in EUI-64 >> format is defined in [ARCH]. The details on forming interface >> identifiers is defined in the appropriate "IPv6 over " >> specification such as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" >> [FDDI], etc. > >I'd add as an FYI item that EUI-64 is a superset of 48-bit MAC space >(and BTW does that mean that the "u" bit occurs twice?) OK, but this document assume knowledge of the rules in [ARCH]. I am working on an appendix to [ARCH] which describes the mapping of 48-bit => EUI-64 and alternatives for creating local scope interface identifiers. >> 6.0 Security Considerations > >> Documents of this type do not directly impact the security of the >> Internet infrastructure or its applications. > >Hmm. Not sure that you can say as little as this. For example where >in the IPv6 document set do we discuss address spoofing atacks? >At least I'd be tempted to say (most everywhere, not just in this >document) that IPv6 is intrinsically insecure unless IPSEC is switched >on, and specifically that IPSEC can be used to mitigate address spoofing. I was given this text by an IESG member (who can identify him/herself if he/she wishes). I think it is sufficient for this document given it's content. Some of the other IPv6 specifications do need more on this topic. Thanks again for the comments. 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 Wed May 28 16:30:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA12946; Wed, 28 May 1997 15:00:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA12937; Wed, 28 May 1997 15:00:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA17119; Wed, 28 May 1997 15:01:22 -0700 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA21120 for ; Wed, 28 May 1997 15:02:26 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.5/8.7.3) with ESMTP id AAA13362; Thu, 29 May 1997 00:01:49 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id AAA23312; Thu, 29 May 1997 00:01:47 +0200 (MET DST) Message-Id: <199705282201.AAA23312@givry.inria.fr> From: Francis Dupont To: thartric@mentat.com (Tim Hartrick) cc: deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 3723) Re: indicating globicity In-reply-to: Your message of Fri, 23 May 1997 12:49:25 PDT. <199705231949.MAA14262@feller.mentat.com> Date: Thu, 29 May 1997 00:01:31 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 784 In your previous mail you wrote: I see no problem with this modification. I agree with Pedro that the implementors should be able to get this right. => I agree but perhaps we can use the next bit (previous in the Ethernet wire order), aka the multicast bit because it has *no* usage (global/local is used when you assign (for any reason) a MAC address to a board) ? 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 May 29 11:11:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14034; Thu, 29 May 1997 11:02:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14027; Thu, 29 May 1997 11:02:11 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA27719; Thu, 29 May 1997 11:02:54 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA28091 for ; Thu, 29 May 1997 11:03:32 -0700 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA21378; Thu, 29 May 1997 13:53:57 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25127; Thu, 29 May 1997 13:53:50 -0400 Message-Id: <9705291753.AA25127@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3724) Re: indicating globicity In-Reply-To: Your message of "Thu, 22 May 97 17:17:20 PDT." Date: Thu, 29 May 97 13:53:49 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 593 Steve, This makes a lot of sense to me. I think its a good idea. I have read ahead and have seen no arguments that would be strong enough to not do as you suggest for inversion. Good thinking and catch, /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 May 29 11:39:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14071; Thu, 29 May 1997 11:31:07 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14064; Thu, 29 May 1997 11:31:02 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06221; Thu, 29 May 1997 11:32:48 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06079; Thu, 29 May 1997 11:31:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14036; Thu, 29 May 1997 11:04:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA28585; Thu, 29 May 1997 11:05:22 -0700 Received: from netscape.com (h-205-217-237-47.netscape.com [205.217.237.47]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA29082 for ; Thu, 29 May 1997 11:06:24 -0700 Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA15381 for ; Thu, 29 May 1997 11:05:45 -0700 (PDT) Received: from fionavar ([207.1.142.56]) by dredd.mcom.com (Netscape Mail Server v2.02) with SMTP id AAA14748 for ; Thu, 29 May 1997 11:05:46 -0700 Message-ID: <338DC689.7A5F@netscape.com> Date: Thu, 29 May 1997 11:10:17 -0700 From: John Francis Stracke X-Mailer: Mozilla 3.0GoldC (X11; U; IRIX 5.3 IP22) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 3726) Re: comments on References: <3.0.1.32.19970528150211.007666a8@mailhost.ipsilon.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1909 Bob Hinden wrote: > Brain, > >> - Plan or track record providing public internet transit service to > >***** on fair, reasonable and non-discriminatory terms^ > > Good idea. Mmm, yes, but not necessarily feasible. "Fair, reasonable, and non-discriminatory" is a good goal; but will the IANA have the ability to enforce it? Say, what do you do when the government of Freedonia, where they discriminate systematically against left-handed weasels, wants to be a TLA? "We want to put Freedonia on the Net, and the only way it's going to happen is if we're a TLA, so we can control it, and make sure no left-handed weasels start ISPs." Do you refuse, and leave all of Freedonia off the Net (including the left-handed weasels)? Or what if Big Backbone Carrier, who hauls 90% of the bits for Continent X, starts getting arbitrary about who it sells access to? Are you going to pull BBC's TLA and leave Continent X without a backbone? If you try, do you think BBC will (a) fold up meekly, or (b) sue you back to the Stone Age? I'm afraid I don't have a better solution, though. :-( /====================================================================\ |John (Francis) Stracke |My opinions are my own.|PGP key available| |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. | "Where's your sense of adventure?" | |francis@netscape.com | "Hiding under the bed." | \====================================================================/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 29 12:18:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA14288; Thu, 29 May 1997 12:04:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA14275; Thu, 29 May 1997 12:03:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA15426; Thu, 29 May 1997 12:04:34 -0700 Received: from yorktown.paranet.com (yorktown.paranet.com [199.164.131.34]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA18695 for ; Thu, 29 May 1997 12:05:44 -0700 Received: by yorktown.paranet.com; id OAA15872; Thu, 29 May 1997 14:05:00 -0500 (CDT) Received: from intrepid.srv.paranet.com(172.16.3.36) by yorktown.paranet.com via smap (V3.1) id xma015848; Thu, 29 May 97 14:04:37 -0500 Received: from paranoid.dfw.paranet.com (paranoid.dfw.paranet.com [172.16.33.50]) by Intrepid.srv.paranet.com (8.7.1/8.7.1) with ESMTP id OAA14662; Thu, 29 May 1997 14:04:36 -0500 (CDT) Received: (from vgreddy@localhost) by paranoid.dfw.paranet.com (8.7.1/8.7.1) id OAA20745; Thu, 29 May 1997 14:04:33 -0500 (CDT) Date: Thu, 29 May 1997 14:04:33 -0500 (CDT) From: "Vijay G. Reddy" Message-Id: <199705291904.OAA20745@paranoid.dfw.paranet.com> To: bound@zk3.dec.com, deering@cisco.com Subject: (IPng 3727) Re: indicating globicity Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 728 I'm new to this list. I've a very simple question. At a Cisco class, we were told that of the 128 bits the last 48 are used for the MAC address while the first 80 bits indicate the network address. This was a couple of months ago. Since then any material I read on IPv6 has no mention of this. What's the correct answer? Thanks in advance, Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 29 13:39:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14604; Thu, 29 May 1997 13:30:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14597; Thu, 29 May 1997 13:30:09 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA01956; Thu, 29 May 1997 13:31:18 -0700 Received: from muenster.westfalen.de (ns.westfalen.de [195.52.199.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA14108 for ; Thu, 29 May 1997 13:32:23 -0700 Received: from khms.westfalen.de by muenster.westfalen.de via rsmtp with bsmtp id for ; Thu, 29 May 1997 22:31:10 +0200 (MET DST) (Smail-3.2 1996-Jul-4 #1 built 1996-Nov-13) Received: by khms.westfalen.de (CrossPoint v3.11 R/C435); 29 May 1997 22:30:30 +0200 Date: 29 May 1997 19:05:00 +0200 From: kai@khms.westfalen.de (Kai Henningsen) To: ipng@sunroof.eng.sun.com Message-ID: <6XnwoLRjcsB@khms.westfalen.de> In-Reply-To: <3.0.32.19970527151724.006a1c74@pobox> Subject: (IPng 3728) Re: New IPv6 Addressing Drafts X-Mailer: CrossPoint v3.11 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? References: <3.0.32.19970527151724.006a1c74@pobox> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2602 dhaskin@BayNetworks.COM (Dimitry Haskin) wrote on 27.05.97 in <3.0.32.19970527151724.006a1c74@pobox>: > At 06:57 PM 5/27/97 +0200, Kai Henningsen wrote: > >dhaskin@BayNetworks.COM (Dimitry Haskin) wrote on 22.05.97 in > <3.0.32.19970522202327.006a6fd4@pobox>: > > > >> >>P.S. The IPv6/PPP spec will allow what I'll make it to allow ;) > >> > > >> >So what is it going to be? > >> > > >> >Bob > >> > > >> > >> If an unique build-in MAC address is available on the node, it will be > >> used to form ID of a PPP interface using an EUI-64 format. Otherwise a > >> random number will be used to generate a local scope interface id. > > > >Hmm. This looks as if it will continue dynamic IP addresses into IPv6, > >even in cases where there are more than enough address bits available for > >static addresses (which should be most cases). > > > >Can we not do better? Dynamic IP numbers are evil. > > > >The way I understand the addressing draft, you MUST have an EUI-64, even > >for PPP. So someone would have to offer a block to choose random numbers > >from. Correct? > > > Incorrect. This is only true for global scope interface ids. A local scope > interface id can be any number that is unique on the link. Well, I'm thinking about the typical ISP client. The PPP interface is the only interface he has, and he can't do much without a global address. Link- local Ids are completely uninteresting in that context. > >It would be nice if people could get a fixed EUI-64 assignment for their > >box from somewhere. Since these numbers don't really mean anything, simply > >giving them out serially should be good enough. > > > You always have the option to use manual configuration, DHCP or some other > stateful configuration tools to get ids for your box. Random numbers are > only for those cases where there is no build-in mac address and stateless > address autoconfiguration is desirable. I'm not talking about how to get this configured, I'm talking about getting assigned a useable number to put in that field - that is, the administrative, not the technical side. It seems you pay $1000 for an EUI-64 block. That's far too much for anything smaller than a really large ISP to do, of course. MfG Kai -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 30 14:43:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA16023; Fri, 30 May 1997 14:34:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA16013; Fri, 30 May 1997 14:34:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA13259; Fri, 30 May 1997 14:35:10 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA08686 for ; Fri, 30 May 1997 14:36:22 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id OAA26772 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-%D%-I) with ESMTP id OAA18636 Posted-Date: Fri, 30 May 1997 14:35:27 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA22780; Fri, 30 May 1997 17:35:28 -0400 for Message-Id: <3.0.32.19970530173440.0068fe9c@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 30 May 1997 17:34:42 -0400 To: kai@khms.westfalen.de (Kai Henningsen) From: Dimitry Haskin Subject: (IPng 3729) Re: New IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2668 At 07:05 PM 5/29/97 +0200, Kai Henningsen wrote: >> >> >> >> If an unique build-in MAC address is available on the node, it will be >> >> used to form ID of a PPP interface using an EUI-64 format. Otherwise a >> >> random number will be used to generate a local scope interface id. >> > >> >Hmm. This looks as if it will continue dynamic IP addresses into IPv6, >> >even in cases where there are more than enough address bits available for >> >static addresses (which should be most cases). >> > >> >Can we not do better? Dynamic IP numbers are evil. >> > >> >The way I understand the addressing draft, you MUST have an EUI-64, even >> >for PPP. So someone would have to offer a block to choose random numbers >> >from. Correct? >> > >> Incorrect. This is only true for global scope interface ids. A local scope >> interface id can be any number that is unique on the link. > >Well, I'm thinking about the typical ISP client. The PPP interface is the >only interface he has, and he can't do much without a global address. Link- >local Ids are completely uninteresting in that context. Local scope IDs can be used for global addresses. Until a new transport protocol which can get any benefit from global scope ids comes along (which I doubt will happen any soon), there is no difference whether your global address has a local or global scope interface id. > >> >It would be nice if people could get a fixed EUI-64 assignment for their >> >box from somewhere. Since these numbers don't really mean anything, simply >> >giving them out serially should be good enough. >> > >> You always have the option to use manual configuration, DHCP or some other >> stateful configuration tools to get ids for your box. Random numbers are >> only for those cases where there is no build-in mac address and stateless >> address autoconfiguration is desirable. > >I'm not talking about how to get this configured, I'm talking about >getting assigned a useable number to put in that field - that is, the >administrative, not the technical side. > >It seems you pay $1000 for an EUI-64 block. That's far too much for >anything smaller than a really large ISP to do, of course. > Or an ISP client may get an EUI-64 address from his ISP the same way he'd get a v4 address now. >MfG Kai Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 31 06:34:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA16854; Sat, 31 May 1997 06:25:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA16847; Sat, 31 May 1997 06:24:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA02179; Sat, 31 May 1997 06:26:00 -0700 Received: from wachusett.altavista-software.com (wachusett.altavista-software.com [205.181.164.11]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA00815 for ; Sat, 31 May 1997 06:27:17 -0700 Received: by wachusett.altavista-software.com; (5.65v3.2/1.3/10May95) id AB26236; Sat, 31 May 1997 09:26:23 -0400 Message-Id: <3.0.1.32.19970531092527.009531bc@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 31 May 1997 09:25:27 -0400 To: Karen Seo , ipsec@tis.com Received: from 1Cust47.Max3.Boston.MA.MS.UU.NET by wachusett.altavista-software.com (smtpxd); id XA14758 From: Matt Thomas Subject: (IPng 3730) Re: New draft -- IPSEC AH Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199705302208.SAA15535@relay.hq.tis.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1597 >3.2.3.1.2 ICV Computation for IPv6 > > In IPv6, the "Hop Limit" field in the IPv6 base header is zeroed > prior to performing the ICV calculation. IPv6 options contain a bit > that indicates whether the option might change (unpredictably) during > transit. For any option for which contents may change en-route, the > entire "Option Data" field must be treated as zero-valued octets when > computing or verifying the ICV. The Option Type and Opt Data Len are > included in the ICV calculation. All other options are also included > in the ICV calculation. See the IPv6 specification [DH95] for more > information. I think that we need to exclude (e.g. treat as zero) the flow-label and priority/reserved bits as well, especially if they are allowed to be changed inflight. [Since the version field is constant I'd exclude that as well so the first 32 bits of the IPv6 header are treated as zeroes.] Comments? -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------