From owner-ipng@sunroof.eng.sun.com Wed Dec 1 04:56:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB1CqoM06153 for ipng-dist; Wed, 1 Dec 1999 04:52:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB1Cqec06146 for ; Wed, 1 Dec 1999 04:52:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA27492 for ; Wed, 1 Dec 1999 04:52:37 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA05795 for ; Wed, 1 Dec 1999 05:52:35 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA23511; Wed, 1 Dec 1999 21:52:26 +0900 (JST) cc: ipng@sunroof.eng.sun.com To: gilligan@freegate.com, set@thumper.bellcore.com, bound@zk3.dec.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: sockaddr_storage issue From: itojun@iijlab.net Date: Wed, 01 Dec 1999 21:52:26 +0900 Message-ID: <23509.944052746@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a question about RFC2553, on struct sockaddr_storage. RFC2553 defines sockaddr_storage like this: >struct sockaddr_storage { > uint8_t __ss_len; /* address length */ > sa_family_t __ss_family; /* address family */ > /* Following fields are implementation specific */ > char __ss_pad1[_SS_PAD1SIZE]; > /* 6 byte pad, this is to make implementation > /* specific pad up to alignment field that */ > /* follows explicit in the data structure */ > int64_t __ss_align; /* field to force desired structure */ > /* storage alignment */ > char __ss_pad2[_SS_PAD2SIZE]; > /* 112 byte pad to achieve desired size, */ > /* _SS_MAXSIZE value minus size of ss_len, */ > /* __ss_family, __ss_pad1, __ss_align fields is 112 */ >}; I remember that that there was last-minute discussion about "ss_len" and "ss_family", rather than "__ss_len". This did not make it to RFC2553, and I am still curious what was the last consensus on this. Do any of you remember it exactly? Just for reference, OpenBSD 2.6 (NRL IPv6) defines it as "ss_len". BSDI4 (NRL IPv6) defines as "__ss_len". KAME currently using "__ss_len". Personally, "ss_len" makes more sense for me. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 1 05:04:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB1D2rB06183 for ipng-dist; Wed, 1 Dec 1999 05:02:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB1D2ic06176 for ; Wed, 1 Dec 1999 05:02:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA00881 for ; Wed, 1 Dec 1999 05:02:43 -0800 (PST) Received: from foo.sics.se (foo.sics.se [193.10.66.234]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08560 for ; Wed, 1 Dec 1999 06:02:41 -0700 (MST) Received: (from assar@localhost) by foo.sics.se (8.9.3/8.9.3) id OAA57647; Wed, 1 Dec 1999 14:02:46 +0100 (CET) (envelope-from assar) To: itojun@iijlab.net Cc: gilligan@freegate.com, set@thumper.bellcore.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: sockaddr_storage issue References: <23509.944052746@coconut.itojun.org> From: Assar Westerlund Date: 01 Dec 1999 14:02:46 +0100 In-Reply-To: itojun@iijlab.net's message of "Wed, 01 Dec 1999 21:52:26 +0900" Message-ID: <5lyabe7r0p.fsf@foo.sics.se> Lines: 21 User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > I have a question about RFC2553, on struct sockaddr_storage. I did re-read RFC2553, and... > RFC2553 defines sockaddr_storage like this: It doesn't actually. It says `An example implementation design...'. As far as I can tell, it doesn't seem to define the names of these fields anywhere. And I didn't find any consensus on this in the mailing list archives either. > Just for reference, OpenBSD 2.6 (NRL IPv6) defines it as "ss_len". > BSDI4 (NRL IPv6) defines as "__ss_len". KAME currently using > "__ss_len". > Personally, "ss_len" makes more sense for me. If it's supposed to be used, I think `ss_len' is a better name, and if it's not, I would vote for `__ss_len'. /assar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 1 05:07:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB1D3h906192 for ipng-dist; Wed, 1 Dec 1999 05:03:43 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB1D3Tc06185 for ; Wed, 1 Dec 1999 05:03:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA11956; Wed, 1 Dec 1999 05:03:27 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04008; Wed, 1 Dec 1999 05:03:25 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id WAA23677; Wed, 1 Dec 1999 22:03:19 +0900 (JST) To: matt@netbsd.org, erik.nordmark@eng.sun.com cc: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: RFC2292 addition for rsh/rlogin From: itojun@iijlab.net Date: Wed, 01 Dec 1999 22:03:19 +0900 Message-ID: <23675.944053399@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 2292bis-01 defines the following functions: >int rresvport_af(int *port, int family); >int rcmd_af(char **ahost, unsigned short rport, const char *locuser, > const char *remuser, const char *cmd, int *fd2p, int af) >int rexec_af(char **ahost, unsigned short rport, const char *name, > const char *pass, const char *cmd, int *fd2p, int af) For the latter two caller needs to pass in6_addr, not sockaddr_in{,6}. there's no chance to pass scope id information to these functions, so they are not scope-boundary aware. It makes more sense if we define them as: >int rcmd_addr(struct sockaddr *host, unsigned short rport, > const char *locuser, const char *remuser, const char *cmd, int *fd2p) >int rexec_addr(struct sockaddr *host, unsigned short rport, > const char *name, const char *pass, const char *cmd, int *fd2p) Also, we need the following as well: >int iruserok_addr(struct sockaddr *sa, int superuser, const char *ruser, > const char *luser) >int ruserok_addr(const struct sockaddr *sa, int superuser, const char *ruser, > const char *luser) I think we would really need to change them to take struct sockaddr. I'm happy with the name changes ("_addr" portion), itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 1 05:10:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB1D8pN06244 for ipng-dist; Wed, 1 Dec 1999 05:08:51 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB1D8bc06229 for ; Wed, 1 Dec 1999 05:08:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA12200 for ; Wed, 1 Dec 1999 05:08:35 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10461 for ; Wed, 1 Dec 1999 06:08:34 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id WAA23765; Wed, 1 Dec 1999 22:06:54 +0900 (JST) To: gilligan@freegate.com, set@thumper.bellcore.com, bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Wed, 01 Dec 1999 21:52:26 JST. <23509.944052746@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: sockaddr_storage issue From: itojun@iijlab.net Date: Wed, 01 Dec 1999 22:06:53 +0900 Message-ID: <23763.944053613@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Just for reference, OpenBSD 2.6 (NRL IPv6) defines it as "ss_len". > BSDI4 (NRL IPv6) defines as "__ss_len". KAME currently using > "__ss_len". correction: it seems vanilla BSDI4 does not have sockaddr_storage. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 1 06:01:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB1DvgI06288 for ipng-dist; Wed, 1 Dec 1999 05:57:42 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB1DvWc06281 for ; Wed, 1 Dec 1999 05:57:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA14492 for ; Wed, 1 Dec 1999 05:57:33 -0800 (PST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24585 for ; Wed, 1 Dec 1999 06:57:32 -0700 (MST) Received: from zrtpd004.us.nortel.com (actually nrtpd004) by smtprtp.ntcom.nortel.net; Wed, 1 Dec 1999 08:56:20 -0500 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id XA91D9GC; Wed, 1 Dec 1999 08:56:20 -0500 Received: from nortelnetworks.com (192.32.225.182 [192.32.225.182]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VZWDXZQ7; Wed, 1 Dec 1999 08:56:20 -0500 Message-ID: <3845286D.6EE47933@nortelnetworks.com> Date: Wed, 01 Dec 1999 08:53:49 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound CC: Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses References: <199912010506.AAA0000001337@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Sorry I have not gotten involved in this discussion earlier. I want to point out that some people have looked at site-local addresses and how they should or could work. Erik's draft is a start from the point of view of DNS and I have a draft that addresses some of the questions in this thread concerning the routing and forwarding of site-local prefixes. However, Erik and I have gotten few comments on the drafts. The idea in Minneapolis was that Steve, Erik, and I were going to use these two existing documents as supporting docs for the architecture that Steve mentions. I believe that implementors can proceed using these docs while Steve works on the architecture doc. Brian Jim Bound wrote: > Steve, > > Per site-locals in DNS: > I did not say there is consensus, if I did I mean't it appears to be > moving in that direction IMO. The issue is still to-be-discussed. > But if you read the mails you will find people saying they don't belong in > DNS. Which is what I was reflecting. > > But site-locals now that we are trying to use them in an interoperable > manner are showing pain that we have not worked out standard details > for their use. We will do that now, whether you get your doc done or not > as time is of the essence as I watch what folks want to do with them. > But your doc would be very timely now and a big help. > > As far as the API issue you say: > > >I feel badly about not paying more attention to the API specs when > >they were first being written. I had hoped that the few discussions > >we had during IETF meetings (e.g., the discussions that clarified that > >scope boundaries cut through nodes, not links), would have been > >sufficient to make clear the consequences of scoped addresses on the > >APIs, forwarding rules, routing data structures, user interfaces, etc., > >but that was wishful thinking on my part. Clearly some people > >understood these issues at the time, but others have had to spend a lot > >of time and email discovering them, effort that could have been avoided > >if I had delivered on my frequent promises to write up what I understood > >about scoped addresses (something I *still* intend to do). > > We understood the issues with RFC2553 but we were faced with moving > forward and there was much discussion about scope_id at that time. The > WG agreed to put a field in sockaddr_in6 till we learned more about > scope_ids. Any implementer has had to deal with site-local simply > because of RFC 2373 in their implementation. It is not an issue of > understanding them in that sense at all. It is a matter of how they > should be applied to the API semantics so they can be used with a > scope_id. It is serendipity that we have an API fallback with > getaddrinfo which we all must move to now simply because of this issue. > We have Keith Sklower to thank for that all the way back at the > Stockholm meeting I think in 1996, who explained this advantage. > We all understood but we did not all agree on its use with each other. > So don't feel bad about it in that sense we will survive the API > debaucle and fix it quickly. Those wheels have already started to turn. > > >From RFC2553: > > The sin6_scope_id field is a 32-bit integer that identifies a set of > interfaces as appropriate for the scope of the address carried in the > sin6_addr field. For a link scope sin6_addr sin6_scope_id would be > an interface index. For a site scope sin6_addr, sin6_scope_id would > be a site identifier. The mapping of sin6_scope_id to an interface > or set of interfaces is left to implementation and future > specifications on the subject of site identifiers. > > Everyone you have been listening too except for a few on this discussion > (who are new WG members) saw this in the spec and knew it was there. But > we had to move on and it was good we did as the rest of the API parts > were able to solidify. It was not because we were clueless, or needed > your guidance that we made this engineering trade-off. It was > time-to-market for this API. > > But I would take this issue as caution to you as chair that anything in > IPv6 that changes now that affects the API or user applications will get > more and more painful as we progress. In 2000 I think we will see > more real products with IPv6 stacks and IPv6 APIs; and continuing to break > them because it was not perceived important on the WG list of issues, > is not a good strategy for the IPv6 work and we must look at the priority > as far as work that affects those products. Just saying thats the risk you > take is not a very good answer if the IETF expects continued development of > IPv6 "products" and not just research or early adopter kit efforts. > Likewise IPv6 deployment, which will require "products". > > >I also don't think the lack of a current agreement on how name > >resolution will be done for site-locals represents any sort of major > >"flaw" in IPv6. > > Well put 2373 up for DS and I will make my case to the IESG it is a flaw > and we can find out? It is much more than name resolution. But we are not > ready for 2373 for DS and I have agreed to move on here and will help fix > the issues beyond name resolution, which will hopefully make site-locals > work in practice between multiple independent implementations, which is > also a test for DS. > > >The same is true for the notion of embedding a site ID inside a site- > >local address > > I don't agree with this at all. Are you saying we can't work on this > during the effort to resolve how to use site-local addresses? It could > be a tool we need at the end-of-the-day. Are you saying or mandating we > cannot discuss proposals to do this on the IPng list as a WG chair, > as we work out site-local address issues or scope-id issues? > > I hope not!!!! > > Lastly to believe now that what we have done with IPv6 is just a tweak > to the network layer keeping as much of the IP stack in tact may be > partically true for implementation in stack kernel space (but that was a lot > of work to make it perform well with IPv4), but is not true at all for > user space. IPv6 system implementation in user space is far more > complex than IPv4. So the theory back in the days of the IPng Directorate > that the basis for IPv6 was incremental was not quite true, as it turns > out as I see it, as a note. Site-Local addresses contribute to that > complexity and against that axiom. > > /jim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Brian Haberman Advanced Network Research Nortel Networks haberman@nortelnetworks.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 1 06:13:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB1EAPA06331 for ipng-dist; Wed, 1 Dec 1999 06:10:25 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB1EAHc06324 for ; Wed, 1 Dec 1999 06:10:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA05457 for ; Wed, 1 Dec 1999 06:10:16 -0800 (PST) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28811 for ; Wed, 1 Dec 1999 07:10:16 -0700 (MST) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id OAA15561 for ; Wed, 1 Dec 1999 14:10:15 GMT Message-Id: <199912011410.OAA15561@orchard.arlington.ma.us> To: ipng@sunroof.eng.sun.com Subject: site-local, DNS, and inverse lookups.. Date: Wed, 01 Dec 1999 09:10:15 -0500 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here's another site-local issue: How are we going to manage dnssec for the 0.c.e.f.ip6.int reverse zone? Each "site" is going to have a different concept of what the authentic truth for the site-local inverse zone is going to be ... - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 1 13:25:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB1LGT306856 for ipng-dist; Wed, 1 Dec 1999 13:16:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB1LGKc06849 for ; Wed, 1 Dec 1999 13:16:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA11133 for ; Wed, 1 Dec 1999 13:16:18 -0800 (PST) Received: from chmls05.mediaone.net (ne.mediaone.net [24.128.1.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08791 for ; Wed, 1 Dec 1999 13:16:17 -0800 (PST) Received: from gateway (h004005a2eb98.ne.mediaone.net [24.128.200.158]) by chmls05.mediaone.net (8.8.7/8.8.7) with SMTP id QAA21778 for ; Wed, 1 Dec 1999 16:16:14 -0500 (EST) Message-Id: <4.1.19991201161153.041ac360@pop.ne.mediaone.net> X-Sender: rapo@mail130.pair.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 01 Dec 1999 16:16:29 -0500 To: ipng@sunroof.eng.sun.com From: Pete Loshin Subject: Re: Novell Netware IPv6 Implementation In-Reply-To: <199911050821.AAA15319@venus.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:21 AM 11/5/99 +0000, tkuiper@tobit.com wrote: >Does anyone know about an IPv6 Implementation for Novell Netware? > >I've send severall mails to Novell but all I get back is a pointer >to some web sites which say its "going to be" built in into Netware 5 >(documents are from this March). However, I didn't find any IPv6 stuff >in the Netware 5 Version. Some real info would be welcome. There's a name and email address (Anand Subramaniam at andy@novell.com) on the playground.sun.com site, but mail to that address comes back as undeliverable. Does anyone know if there is anything happening at Novell? How difficult would it be for Novell to IPv6-enable their LAN software? What about NDS? regards, -pl +-------------------------------------------------------------+ | Pete Loshin http://Internet-Standard.com | | | | _IPv6 Clearly Explained_ Morgan Kaufmann January 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 1 19:25:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB23Hfq07567 for ipng-dist; Wed, 1 Dec 1999 19:17:41 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB23HTc07560 for ; Wed, 1 Dec 1999 19:17:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA21676 for ; Wed, 1 Dec 1999 19:17:28 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA25691 for ; Wed, 1 Dec 1999 20:17:28 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id TAA11018; Wed, 1 Dec 1999 19:17:27 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id TAA11693; Wed, 1 Dec 1999 19:17:28 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.1b+Sun/8.9.1) id TAA07317; Wed, 1 Dec 1999 19:18:23 -0800 (PST) Date: Wed, 1 Dec 1999 19:18:23 -0800 (PST) From: Tim Hartrick Message-Id: <199912020318.TAA07317@feller.mentat.com> To: itojun@iijlab.net Subject: Re: sockaddr_storage issue Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > >struct sockaddr_storage { > > uint8_t __ss_len; /* address length */ > > sa_family_t __ss_family; /* address family */ > > /* Following fields are implementation specific */ > > char __ss_pad1[_SS_PAD1SIZE]; > > /* 6 byte pad, this is to make implementation > > /* specific pad up to alignment field that */ > > /* follows explicit in the data structure */ > > int64_t __ss_align; /* field to force desired structure */ > > /* storage alignment */ > > char __ss_pad2[_SS_PAD2SIZE]; > > /* 112 byte pad to achieve desired size, */ > > /* _SS_MAXSIZE value minus size of ss_len, */ > > /* __ss_family, __ss_pad1, __ss_align fields is 112 */ > >}; > > I remember that that there was last-minute discussion about > "ss_len" and "ss_family", rather than "__ss_len". This did not make > it to RFC2553, and I am still curious what was the last consensus on > this. Do any of you remember it exactly? > I think the consensus was that folks were tired of fighting about it.:-) Seriously, if I remember correctly the discussion was largely concerned with whether the sockaddr_storage members should be referenced directly or whether a pointer to the structure should be casted to a pointer of some real protocol specific sockaddr type like sockaddr_in, sockaddr_in6 or sockaddr_un in order to reference fields. There were strong opinions on both sides. It appears that the latter opinion held the day since the document has __ in front of the field names of the sockaddr_storage structure in order to make them more opaque. I have no opinion on which is "correct". I am just trying to provide some historical context as best I am able. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 1 20:31:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB24PZU07614 for ipng-dist; Wed, 1 Dec 1999 20:25:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB24PPc07607 for ; Wed, 1 Dec 1999 20:25:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA22900 for ; Wed, 1 Dec 1999 20:25:24 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA12067 for ; Wed, 1 Dec 1999 20:25:24 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 93F5557A6D; Wed, 1 Dec 1999 22:25:23 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 9183854602; Wed, 1 Dec 1999 22:25:23 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 20ACE4FB07; Wed, 1 Dec 1999 22:25:17 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 90FAF4C90A; Wed, 1 Dec 1999 22:25:16 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000024400; Wed, 1 Dec 1999 23:25:21 -0500 (EST) From: Jim Bound Message-Id: <199912020425.XAA0000024400@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: gilligan@freegate.com, set@thumper.bellcore.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: sockaddr_storage issue In-reply-to: Your message of "Wed, 01 Dec 1999 21:52:26 +0900." <23509.944052746@coconut.itojun.org> Date: Wed, 01 Dec 1999 23:25:21 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi itojun, this does need to be fixed. xnet uncovered an issue here too. Chris Harding...can you comment for XNET? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 1 20:32:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB24TLa07626 for ipng-dist; Wed, 1 Dec 1999 20:29:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB24T8c07619 for ; Wed, 1 Dec 1999 20:29:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA27304 for ; Wed, 1 Dec 1999 20:29:06 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA13004 for ; Wed, 1 Dec 1999 20:29:07 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id BB513152042; Wed, 1 Dec 1999 22:29:06 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id B6636148506; Wed, 1 Dec 1999 22:29:06 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 231DE4FB07; Wed, 1 Dec 1999 22:29:00 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id A964E4C909; Wed, 1 Dec 1999 22:28:59 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000027474; Wed, 1 Dec 1999 23:29:01 -0500 (EST) From: Jim Bound Message-Id: <199912020429.XAA0000027474@quarry.zk3.dec.com> To: "Brian Haberman" Cc: Jim Bound , Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of "Wed, 01 Dec 1999 08:53:49 EST." <3845286D.6EE47933@nortelnetworks.com> Date: Wed, 01 Dec 1999 23:29:00 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, I recall that you guys were to do this too. Sounds like we still need it. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 02:33:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2AMP307948 for ipng-dist; Thu, 2 Dec 1999 02:22:25 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2ALbc07918 for ; Thu, 2 Dec 1999 02:21:38 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA298320; Thu, 2 Dec 1999 02:21:24 -0800 (PST) Date: Thu, 2 Dec 1999 01:09:34 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: sockaddr_storage issue To: itojun@iijlab.net Cc: gilligan@freegate.com, set@thumper.bellcore.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <23509.944052746@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I remember that that there was last-minute discussion about > "ss_len" and "ss_family", rather than "__ss_len". This did not make > it to RFC2553, and I am still curious what was the last consensus on > this. Do any of you remember it exactly? I recall X/Open wanting to change the names to ss_family etc. I don't know if they decided to go ahead with this or not. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 02:33:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2AMI407944 for ipng-dist; Thu, 2 Dec 1999 02:22:18 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2ALSc07896 for ; Thu, 2 Dec 1999 02:21:28 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA298240; Thu, 2 Dec 1999 02:20:52 -0800 (PST) Date: Wed, 1 Dec 1999 21:27:34 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC2292 addition for rsh/rlogin To: itojun@iijlab.net Cc: matt@netbsd.org, erik.nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <23675.944053399@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 2292bis-01 defines the following functions: > > >int rresvport_af(int *port, int family); > >int rcmd_af(char **ahost, unsigned short rport, const char *locuser, > > const char *remuser, const char *cmd, int *fd2p, int af) > >int rexec_af(char **ahost, unsigned short rport, const char *name, > > const char *pass, const char *cmd, int *fd2p, int af) > > For the latter two caller needs to pass in6_addr, not sockaddr_in{,6}. > there's no chance to pass scope id information to these functions, > so they are not scope-boundary aware. I don't understand your statement. The functions take host names thus they could very well be scope aware internally (and I assume we want to make the implementation of these interfaces scope aware). > It makes more sense if we define them as: > > >int rcmd_addr(struct sockaddr *host, unsigned short rport, > > const char *locuser, const char *remuser, const char *cmd, int *fd2p) > >int rexec_addr(struct sockaddr *host, unsigned short rport, > > const char *name, const char *pass, const char *cmd, int *fd2p) How does your _addr functions handle the case when a FQDN has multiple addresses and we want to try all of them until we find one that works? I don't think we want to put that loop and retry logic in the callers to rcmd/rexec. > Also, we need the following as well: > > >int iruserok_addr(struct sockaddr *sa, int superuser, const char *ruser, > > const char *luser) > >int ruserok_addr(const struct sockaddr *sa, int superuser, const char > *ruser, > const char *luser) > > I think we would really need to change them to take struct sockaddr. > I'm happy with the name changes ("_addr" portion), What problem are you solving by making them take the address instead of the host name? (I can see that it is simpler for the application since it doesn't need to call getipnodebyaddr/getnameinfo.) BTW: What is iruserok()? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 02:34:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2AMOS07947 for ipng-dist; Thu, 2 Dec 1999 02:22:24 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2ALac07914 for ; Thu, 2 Dec 1999 02:21:36 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA298298; Thu, 2 Dec 1999 02:21:17 -0800 (PST) Date: Wed, 1 Dec 1999 23:28:42 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Textual Address Change for Scope-IDs To: Jim Bound Cc: Christian Huitema , Tim Hartrick , sm@bossette.engr.sgi.com, bzill@microsoft.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199911291743.MAA0000016275@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > IPv6 can work but I strongly urge you to help me and anyone else shoot > these site-local addresses in the head. We have enough global address > space with IPv6 that we can re-create a Net-10 within the IPv6 > exponential number of addresses. > > As far as renumbering the only way to solve that is develop further > addrconf and router-renumbering and get folks to stop hard coding > address semantics in configuration files via sys admins. IPv6 can be > extended to do this and this is a wonderful part of our basic > architecture. The problem as I see it is the difference in effort between: 1. porting a socket application to IPv6 2. making an application/system/box not store IP(v4 or v6) addresses in configuration files, memory, or anywhere else for an extended period of time. #1 is trvial for most applications - it can almost be automated by a script in many cases. But #2 I have no idea how to track down - I can't easily search for patterns in the code. So if we think #2 is needed due to IPv6 renumbering being needed as the net grows my concern is that it can't be done and tested well in advance. As a result, the first time a large site renumbers things will fail. Then they might sue to convince the ISPs that they can not be forced to renumbers for any reason. The net effect is that site renumbering will get a bad reputation. This might prevent the renumbering that is needed to have the net continue to grow. That's why I think we need site-local addresses - ensure that communication local to a site is not affected by the site renumbering. (This assumes that the "broken" applications/systems/boxes are onlyused within a site.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 02:34:22 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2AMLA07945 for ipng-dist; Thu, 2 Dec 1999 02:22:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2ALWc07904 for ; Thu, 2 Dec 1999 02:21:32 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA298294; Thu, 2 Dec 1999 02:21:16 -0800 (PST) Date: Wed, 1 Dec 1999 23:12:21 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Textual Address Change for Scope-IDs To: Jim Bound Cc: Robert Elz , itojun@iijlab.net, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199911261400.JAA0000016600@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would like to see us all agree that ONLY global addresses are in the > DNS for sure. That would be progress. Jin and those who agree with the above statement, I'm trying to find out how this relates to draft-ietf-ipngwg-site-prefixes. Could someone please enlighten me what is broken in that draft. Thanks, Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 02:34:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2AMMI07946 for ipng-dist; Thu, 2 Dec 1999 02:22:22 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2ALWc07906 for ; Thu, 2 Dec 1999 02:21:33 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA298302; Thu, 2 Dec 1999 02:21:18 -0800 (PST) Date: Wed, 1 Dec 1999 23:45:40 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Regarding site-local addresses To: Christian Huitema Cc: Matt Crawford , Jim Bound , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4.1.19991129184002.009dc3d0@mailee.research.telcordia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > I tend to believe that the site-local addresses, as currently defined, will > come out to hurt us in the future. I agree with Brian Zill that we have to > provide a solution for the autoconfiguration of non connected sites, e.g. a > home network with a mix of wireless, firewire, IP over the electric mesh, > and what else. I am not sure, however, that the existence of the site > address per se solves the problem. If I am not mistaken, a host will only > start configuring site addresses if a router advertizes a site address > prefix. This router will have to be somehow configured, and prefixes will > have to be allocated to the various LANs. From an operational point of > view, configuring the router with a "uniquely tagged" site local address > would be no harder than using a "zero-tagged" address. The specific > experiment I would like is to insert an optional site-id, or site > signature, in the site-local address format. This has been discussed a tad in the zeroconf WG. I agree that there has to be a router advertising prefixes to get site-local addresses. But it is not infeasible to have the few routers in a home automatically number the links - it is trivial if the home^H^H^H^Hzerconf environment only contains one router (which routes between the wireless link, the Ethernet, and whatever other link-layer technologies are used in the house). But the key difference in having architected a site-local scope has to do with what happens when a zerconf environment gets attached to the Internet. In IPv4 the only choice today is to force all the hosts to renumber (using DHCP?) since the hosts can not know which source address they can use for local communication vs. global communication. This will of course break all local connections when the house is connected and disconnected from the Internet. In IPv6 with site-local scope and the source/dest address selection rules the hosts can handle retaining the site-local address as they acquire global addresses thus local connections will not break. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 02:34:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2APeZ07957 for ipng-dist; Thu, 2 Dec 1999 02:25:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2APGc07950 for ; Thu, 2 Dec 1999 02:25:17 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id CAA13805; Thu, 2 Dec 1999 02:25:12 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA14403; Thu, 2 Dec 1999 02:25:11 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id TAA12951; Thu, 2 Dec 1999 19:25:08 +0900 (JST) To: Erik Nordmark cc: matt@netbsd.org, ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 01 Dec 1999 21:27:34 PST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC2292 addition for rsh/rlogin From: itojun@iijlab.net Date: Thu, 02 Dec 1999 19:25:08 +0900 Message-ID: <12949.944130308@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> For the latter two caller needs to pass in6_addr, not sockaddr_in{,6}. >> there's no chance to pass scope id information to these functions, >> so they are not scope-boundary aware. >I don't understand your statement. The functions take host names thus they >could very well be scope aware internally (and I assume we want to make the >implementation of these interfaces scope aware). I see, I misread the document. I need to revisit it. >> >int iruserok_addr(struct sockaddr *sa, int superuser, const char *ruser, >> > const char *luser) >> >int ruserok_addr(const struct sockaddr *sa, int superuser, const char >> *ruser, > const char *luser) >> I think we would really need to change them to take struct sockaddr. >> I'm happy with the name changes ("_addr" portion), >What problem are you solving by making them take the address instead of the >host name? (I can see that it is simpler for the application since it >doesn't need to call getipnodebyaddr/getnameinfo.) >BTW: What is iruserok()? sorry, ruserok() takes string hostname. iruserok() is 4.2BSD thing, and it takes in_addr (u_int32_t) as address. ignore my previous email, I'll revisit documents. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 07:10:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2F7Fp08339 for ipng-dist; Thu, 2 Dec 1999 07:07:15 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2F74c08332 for ; Thu, 2 Dec 1999 07:07:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA00644 for ; Thu, 2 Dec 1999 07:07:04 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29304 for ; Thu, 2 Dec 1999 08:07:04 -0700 (MST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 960BC57B33; Thu, 2 Dec 1999 09:07:03 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext12.compaq.com (Postfix) with ESMTP id 939A354601; Thu, 2 Dec 1999 09:07:03 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id D74654FB03; Thu, 2 Dec 1999 09:06:56 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 0A3244C908; Thu, 2 Dec 1999 09:06:55 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000003269; Thu, 2 Dec 1999 10:07:00 -0500 (EST) From: Jim Bound Message-Id: <199912021507.KAA0000003269@quarry.zk3.dec.com> To: Erik Nordmark Cc: Jim Bound , Robert Elz , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Wed, 01 Dec 1999 23:12:21 PST." Date: Thu, 02 Dec 1999 10:06:59 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, >> I would like to see us all agree that ONLY global addresses are in the >> DNS for sure. That would be progress. > >Jin and those who agree with the above statement, > >I'm trying to find out how this relates to draft-ietf-ipngwg-site-prefixes. >Could someone please enlighten me what is broken in that draft. In your draft you put or assume site-locals are in the DNS. I sent what section in mail to Itojun in our discussion. Your draft should have its own mail thread. /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 Dec 2 07:33:38 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2FTl308370 for ipng-dist; Thu, 2 Dec 1999 07:29:47 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2FTbc08363 for ; Thu, 2 Dec 1999 07:29:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA02642 for ; Thu, 2 Dec 1999 07:29:37 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08783 for ; Thu, 2 Dec 1999 08:29:29 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id AAA28409; Fri, 3 Dec 1999 00:17:41 +0900 (JST) Date: Fri, 03 Dec 1999 00:29:07 +0900 Message-ID: <14406.36931.745891.37954A@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: In your message of "Sun, 21 Nov 1999 14:32:56 -0500" <199911211932.OAA0000031277@quarry.zk3.dec.com> References: <18252.943174345@coconut.itojun.org> <199911211932.OAA0000031277@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 251 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the long delay, but please let me supplement the discussion. >>>>> On Sun, 21 Nov 1999 14:32:56 -0500, >>>>> Jim Bound said: > Are you saying that a user must need to know the scope-id in > addition to the IPv6 address when it keys in the dst address for ftp, > telnet, ping etc.. If so I strongly disagree with you and if this were > true IPv6 is dead right now in the market. It also completely broke the > key concept of Ipv6 which is simplicity and that it is extensible to the > IPv4 architecture. I agree that a "normal" end user does not (and even should not) care about scoped addresses, especially about link-local addresses. In fact I myself don't use them in daily use as an end user. However, as an administrator of the WIDE IPv6 backbone (called the WIDE 6bone) in Japan, I sometimes have to type link-local addresses for "normal" applications such as telnet, ftp, and ssh. I'll show you a concrete example. This is basically a same example that Francis mentioned in his earlier mail: >>>>> On Sun, 28 Nov 1999 18:19:22 +0100, >>>>> Francis Dupont said: > => this is NOT reasonable and ping/traceroute are not the only example > where scoped & numerical addresses should be allowed. For instance when > you have a major problem in your network you'd like to use a scoped & > numerical address to do a telnet on your router (in this kind of case > the DNS is the first thing which breaks :-). but I'll depict it again more concretely in order to explain that our approach of textual addresses is not based on (just) an architect's complacent but on a request from practical operation. We have many ATM point-to-point links in the WIDE 6bone, and most of the ATM interfaces have link-local addresses only (i.e. usually we don't assign a global address to an ATM p2p interface). Here is a typical configuration: ethernet ethernet |----+----| | | | | (pvc1) ATM | router-A===========router-C-| (pvc0)|| | || ATM || || router-B | |---+----|ethernet Each router assigns its global address to its ethernet interface only. No ATM interface in the above picture has a global address. Router-A has two ATM interfaces; pvc0 and pvc1. The link designated by the interface pvc0 connects router-A and router-B, and the link designated by the interface pvc1 connects router-A and router-C. Now, suppose that the routing daemon on router-B hangs up. I have to reinvoke the daemon, but I have to do it via network since router-B is located far from my office. Apparently I can't use FQDN (resolved to a global address of router-B) nor even a textual global address, because this is a routing trouble. So I have to login router-A first, and then try to login router-B using link-local addresses. The procedure is as follows: 1. Confirming the link-local address assigned to the ATM interface of router-B. router-A% ping ff02::1@pvc0 PING(56=40+8+8 bytes) fe80::a --> ff02::1 16 bytes from fe80::a@lo0, icmp_seq=0 hlim=64 time=0.474 ms 16 bytes from fe80::b@pvc0, icmp_seq=0 hlim=64 time=0.374 ms(DUP!) So the address should be fe80::b. 2. Logging in router-B using the address by the telnet command. % telnet fe80::b@pvc0 Trying fe80::b... Connected to fe80::b@pvc0. Escape character is '^]'. login: root Password: **** (login OK) ... Note that we can't just type % telnet fe80::b here, since router-A has more than one interface(i.e. link) and hence the kernel can't detect which link it should try to connect. Although the kernel could spray neighbor solicitations for fe80::b on all links that router-A attaches in order to detect an appropriate link, we can't completely rely on the result. This is because router-C might also assign fe80::b to its ATM interface and might return a neighbor advertisement faster than router-B. Currently we have no mechanism to (automatically) resolve such conflict. Even if we had one, the administrator of router-C might not accept to change the link-local address especially when he/she belongs to a different organization than ours. 3. Reinvoking the routing daemon router-B# gdc restart(or something) [end of the procedure] Sometimes just reinvoking the daemon is not sufficient. We might have to upgrade the daemon in advance. In such a case, we use the ftp command with a link-local address for example. # ftp fe80::b@pvc0 Connected to fe80::b@pvc0 220 router-B FTP server (Version 6.00) ready. Name (fe80::a@pvc0:jinmei): root 331 Password required for root. Password:XXXX 230 User root logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp> put gated local: gated remote: gated 200 EPRT command successful. 150 Opening BINARY mode data connection for 'gated'. 226 Transfer complete. ... [end of the example] I believe that the above examples show link-local addresses (and our extended format for them) are meaningful at least for network administrators. I admit the number of network administrators is much less than the number of *normal* end users, but we can't ignore administrators to deploy IPv6. I believe that Miyakawa-san, who commented on this issue before, has the same idea as an ISP guy. The followings are my comments on some related issues. As for impacts on existing APIs and applications: I know your position; you don't want *any* modifications to existing APIs and applications. But please let me explain some compatibility issues again. First of all, please note that I don't intend to obsolete the current format for scoped addresses. As others said, we can define a "default scope zone" and just use the current format, and the default zone can be trivially (and automatically) specified for a *normal* end host that has only a single network interface. Also, I don't deny per-application mechanisms (like a command line option) to specify a "scope zone". We can continue to use them, but I'd like to provide a standard way to specify a zone as well by extending the address format. Our approach surely introduces some modifications to existing library functions. But we need no modification to applications. We can just recompile them using the modified library. So the only difference is in library functions. If we use the current library and try to use the current address format: It's just OK, but we need a per-application mechanism to handle scoped addresses. If we use the current library and try to use the extended address format: It will fail with an error, and hence we can't handle scoped addresses. We need a per-application mechanism (and the current address format) to handle scoped addresses. (in any case, we need a per-application mechanism if we want to handle scoped addresses.) If we use the extended library and try to use the current address format: It's just OK, but we need a per-application mechanism to handle scoped addresses. If we use the extended library and try to use the extended address format: We can handle scoped addresses using the extended library. We can also use a per-application mechanism (if provided). As for standardization: Though I presented our approach as an I-D, I didn't necessarily intend to force every vendor to adopt the idea. I submitted the I-D just as a start point for discussion, and was convinced that there was surely an issue about scoped addresses. So far, I'm satisfied the result (though we've not got a consensus of how to solve it). However, I still believe our approach is useful even from a practical point of view, and at least several people agreed with us, e.g. Brian, Francis, and Matt...(if I'm wrong, please correct the list). Even if the idea will not be standardized as an IETF standard (including informational), and I don't mind if not, I'd like to continue to cooperate with the supporters so that we can define a *unified* address format as an implementation characteristic and thus provide a unified (and convenience) way to handle scoped addresses for our (including the supporters') users. Finally, I'd like to comment on the relationship between KAME and commercial products. > Also I appreciate your aggressiveness and your hard work on KAME, but > you are not planning on shipping a product that a customer will use to > my knowledge and KAME is a pub domain code base. I don't see GM or > Toyota using KAME or freebsd to run their manufacturing or business > operations. So please try to see my viewpoint here that is affected by > production quality products as vendors alter the base operating system > and networking subsystem for our customers. I admit that we KAME team tend to be much aggressive to implement something about IPv6. But please do not forget that each implementor of the project comes from a commercial company. We can't provide our code just as a hobby. We have to (and do) consider how to apply the code in a commercial usage. In fact, some Japanese network vendors are trying to port KAME to their (commercial) network products. For example, please see the following URL: http://www.wide.ad.jp/events/199909.ipng-interim/japan-slides/sumikawa/ If the companies we belong to stop us implementing something from their commercial point of view, we can't continue the project. When we try to implement something, we always consider the companies' position and can't implement anything just from implementors' interests. I'd appreciate if you understand the circumstance. Please also note that we recognize and appreciate Jim's great contribution to IPv6 in commercial/market side as well as in technical side. I believe we share the same goal: widely deploying IPv6. I'll never intend (and have never intended, I believe) to propose/implement anything that prevents the goal. > I have to be much more conservative in my thinking than if I was working > on a public domain code base such as KAME. > Somewhere there is a balance that needs to happen I realize but I think > this whole notion of scope-ids needs a lot of discussion, attention, and > review before we change anything in IPv6 like the APIs, DNS, Resolver > code etc.. I am glad KAME is experimenting with this now but please > don't always assume you experiments are going to be the answer to the > standard we all use for IPv6. As for standardization, I already stated my opinion above. Thanks for reading the lengthy text. Regards, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 10:26:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2IMSW08517 for ipng-dist; Thu, 2 Dec 1999 10:22:28 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2IMJc08510 for ; Thu, 2 Dec 1999 10:22:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA24285 for ; Thu, 2 Dec 1999 10:22:18 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03278 for ; Thu, 2 Dec 1999 11:22:17 -0700 (MST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 75DC915216E; Thu, 2 Dec 1999 12:22:16 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 70A01148509; Thu, 2 Dec 1999 12:22:16 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id D089E4FB01; Thu, 2 Dec 1999 12:22:09 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 62ACE4C913; Thu, 2 Dec 1999 12:22:09 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000016795; Thu, 2 Dec 1999 13:22:14 -0500 (EST) From: Jim Bound Message-Id: <199912021822.NAA0000016795@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: bound@zk3.dec.com, itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Fri, 03 Dec 1999 00:29:07 +0900." <14406.36931.745891.37954A@condor.isl.rdc.toshiba.co.jp> Date: Thu, 02 Dec 1999 13:22:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk all good points and I appreciate you taking the time to write them down. We have to figure out scope-ids and site-local addresses. and we will enhance the api spec too working with xnet much closer this time. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 10:47:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2IgdF08543 for ipng-dist; Thu, 2 Dec 1999 10:42:39 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2IgTc08536 for ; Thu, 2 Dec 1999 10:42:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA13598 for ; Thu, 2 Dec 1999 10:42:29 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23672 for ; Thu, 2 Dec 1999 10:42:29 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id E9489152062; Thu, 2 Dec 1999 12:42:28 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id E4280148509; Thu, 2 Dec 1999 12:42:28 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 31D8E4FB01; Thu, 2 Dec 1999 12:42:22 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id BD01D4C90F; Thu, 2 Dec 1999 12:42:21 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000019647; Thu, 2 Dec 1999 13:42:27 -0500 (EST) From: Jim Bound Message-Id: <199912021842.NAA0000019647@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: Michael.Carney@east.sun.com, charliep@iprg.nokia.com, bound@zk3.dec.com Subject: IPv6 Link-Local Address on Mediums that are Glued Together Date: Thu, 02 Dec 1999 13:42:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, This a.m. Mike Carney, Charlie Perkins, and I were discussing DHCPv6 and we came across something that I want to bring to the list. For example: There is an Ethernet Segment ETH1 with nodes: nA - linklocal address fe80::a, and nB - linklocal address fe80::b There is another not connected to ETH1 Ethernet Segment ETH2 with nodes: nX - linklocal address fe80::a, and nY - linklocal address fe80::b Then some admin decides to connect the two Ether segments together with a bridge and make them one segment ETH3 without disrupting in anyway or telling the nodes on ETH1 or ETH2. Once they are connected nA and nX; & nX and nY; have duplicate link-local addresses on the same link now ETH3. This is not good and I don't see anything in Neighbor Discovery or Stateless Addrconf anything to address this problem? I use Ethernet segments as the example but there could be other mediums like joining to cell-device networks together. This has some ramifications we need to discuss and what do we tell users about doing this? Thoughts/Comments? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 11:21:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2JFGM08577 for ipng-dist; Thu, 2 Dec 1999 11:15:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2JF6c08570 for ; Thu, 2 Dec 1999 11:15:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA06534 for ; Thu, 2 Dec 1999 11:15:06 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA09421 for ; Thu, 2 Dec 1999 11:15:06 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Dec 1999 11:13:21 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 11:13:21 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA217A0@RED-MSG-50> From: Richard Draves To: "'Jim Bound'" , ipng@sunroof.eng.sun.com Cc: Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: RE: IPv6 Link-Local Address on Mediums that are Glued Together Date: Thu, 2 Dec 1999 11:06:52 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Surely this observation does not come as a surprise? I think the problem is relatively insignificant and we should just table it in favor of more pressing issues. I can imagine some future modifications/extensions of ND that could notice duplicate addresses after DAD has finished. Eg if you send a multicast NS and get back two NAs with the solicited & override bits both set and different link-layer addresses, there could be a problem with the target address. So you could warn the other nodes. Rich > -----Original Message----- > From: Jim Bound [mailto:bound@zk3.dec.com] > Sent: Thursday, December 02, 1999 10:42 AM > To: ipng@sunroof.eng.sun.com > Cc: Michael.Carney@east.sun.com; charliep@iprg.nokia.com; > bound@zk3.dec.com > Subject: IPv6 Link-Local Address on Mediums that are Glued Together > > > Folks, > > This a.m. Mike Carney, Charlie Perkins, and I were discussing > DHCPv6 and > we came across something that I want to bring to the list. > > For example: > > There is an Ethernet Segment ETH1 with nodes: > > nA - linklocal address fe80::a, and nB - linklocal address fe80::b > > There is another not connected to ETH1 Ethernet Segment ETH2 > with nodes: > > nX - linklocal address fe80::a, and nY - linklocal address fe80::b > > Then some admin decides to connect the two Ether segments > together with > a bridge and make them one segment ETH3 without disrupting in > anyway or > telling the nodes on ETH1 or ETH2. > > Once they are connected nA and nX; & nX and nY; have duplicate > link-local addresses on the same link now ETH3. > > This is not good and I don't see anything in Neighbor Discovery or > Stateless Addrconf anything to address this problem? > > I use Ethernet segments as the example but there could be > other mediums > like joining to cell-device networks together. > > This has some ramifications we need to discuss and what do we > tell users > about doing this? > > Thoughts/Comments? > > thanks > /jim > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 11:44:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2JeKM08604 for ipng-dist; Thu, 2 Dec 1999 11:40:20 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2JeAc08597 for ; Thu, 2 Dec 1999 11:40:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA26822 for ; Thu, 2 Dec 1999 11:40:09 -0800 (PST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21909 for ; Thu, 2 Dec 1999 11:40:08 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 2 Dec 1999 13:39:56 -0600 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id YCVR3QY2; Thu, 2 Dec 1999 13:39:44 -0600 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VZWDX8T0; Thu, 2 Dec 1999 14:39:45 -0500 Message-ID: <3846CA55.F76BF76F@nortelnetworks.com> Date: Thu, 02 Dec 1999 14:36:53 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jim Bound CC: ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together References: <199912021842.NAA0000019647@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't see this as being a pressing issue. In fact, similar problems occur today when people connect running networks with L2 devices. Such an event requires human intervention, especially if those previously separate networks were using administratively configured MAC addresses. My recommendation is that we not concern ourselves with this problem when we have more pressing concerns at hand. Brian Jim Bound wrote: > Folks, > > This a.m. Mike Carney, Charlie Perkins, and I were discussing DHCPv6 and > we came across something that I want to bring to the list. > > For example: > > There is an Ethernet Segment ETH1 with nodes: > > nA - linklocal address fe80::a, and nB - linklocal address fe80::b > > There is another not connected to ETH1 Ethernet Segment ETH2 with nodes: > > nX - linklocal address fe80::a, and nY - linklocal address fe80::b > > Then some admin decides to connect the two Ether segments together with > a bridge and make them one segment ETH3 without disrupting in anyway or > telling the nodes on ETH1 or ETH2. > > Once they are connected nA and nX; & nX and nY; have duplicate > link-local addresses on the same link now ETH3. > > This is not good and I don't see anything in Neighbor Discovery or > Stateless Addrconf anything to address this problem? > > I use Ethernet segments as the example but there could be other mediums > like joining to cell-device networks together. > > This has some ramifications we need to discuss and what do we tell users > about doing this? > > Thoughts/Comments? > > thanks > /jim > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Brian Haberman Advanced Network Research Nortel Networks haberman@nortelnetworks.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 11:49:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2JmJI08622 for ipng-dist; Thu, 2 Dec 1999 11:48:19 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2Jm9c08615 for ; Thu, 2 Dec 1999 11:48:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA28377 for ; Thu, 2 Dec 1999 11:48:09 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14320 for ; Thu, 2 Dec 1999 12:48:08 -0700 (MST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id 47D9C104C91; Thu, 2 Dec 1999 13:48:07 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id 3EFD5FB101; Thu, 2 Dec 1999 13:48:07 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id A3358BC4D0; Thu, 2 Dec 1999 13:48:00 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 2600CB2A47; Thu, 2 Dec 1999 13:48:00 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000032601; Thu, 2 Dec 1999 14:48:05 -0500 (EST) From: Jim Bound Message-Id: <199912021948.OAA0000032601@quarry.zk3.dec.com> To: Richard Draves Cc: "'Jim Bound'" , ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-reply-to: Your message of "Thu, 02 Dec 1999 11:06:52 PST." <4D0A23B3F74DD111ACCD00805F31D8101CA217A0@RED-MSG-50> Date: Thu, 02 Dec 1999 14:48:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Surely this observation does not come as a surprise? No. But it just jumped in my face. >I think the problem is relatively insignificant and we should just table it >in favor of more pressing issues. Not sure I agree with you. There needs to be a health warning for customers. If we want to table it I will send it to the IPv6 Forum and see what members think about this who are trying to deploy IPv6. I have customers that will be using IPv6 in the near future. If they do this I am not clear off top of my head what the ramifications are to them, but intend to figure that out from a product perspective to see if it could cause a support call to our hotline when IPv6 is turned on in production nodes. Which will be very soon. >I can imagine some future modifications/extensions of ND that could notice >duplicate addresses after DAD has finished. Eg if you send a multicast NS >and get back two NAs with the solicited & override bits both set and >different link-layer addresses, there could be a problem with the target >address. So you could warn the other nodes. This will in fact happen. Would like to hear from others on IPng too of course. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 12:05:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2K27E08663 for ipng-dist; Thu, 2 Dec 1999 12:02:07 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2K1wc08656 for ; Thu, 2 Dec 1999 12:01:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA16191 for ; Thu, 2 Dec 1999 12:01:58 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20649; Thu, 2 Dec 1999 13:01:48 -0700 (MST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA07920; Thu, 2 Dec 1999 14:58:38 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA33334; Thu, 2 Dec 1999 14:58:40 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA09005; Thu, 2 Dec 1999 14:59:32 -0500 Message-Id: <199912021959.OAA09005@rotala.raleigh.ibm.com> To: Jim Bound cc: ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-Reply-To: Message from Jim Bound of "Thu, 02 Dec 1999 13:42:27 EST." <199912021842.NAA0000019647@quarry.zk3.dec.com> Date: Thu, 02 Dec 1999 14:59:32 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, This is something that has been talked about over the years. One would certainly hope that it won't be a common occurance, given the IEEE identifiers are used in many cases and they are globally unique. It would also be relatively easy to detect this condition by having a node send out periodic NS's for itself and seeing if anyone else responds. But detecting the situation is the easy part. How do you recover? Bottom line is that two nodes are using the same address and that doesn't work. One of those nodes should stop using the address. But who? How does one decide? Having nodes automatically determine who should give up their address may also open interesting denial of service attacks. Observation: if anonymous addresses (as in draft-ietf-ipngwg-addrconf-privacy-01.txt) take off, this may become more of concern. Address collisions will become more likely, but it remains to be seen I think how much of a problem in practice. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 12:11:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2K97A08682 for ipng-dist; Thu, 2 Dec 1999 12:09:07 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2K8wc08675 for ; Thu, 2 Dec 1999 12:08:59 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA02698 for ; Thu, 2 Dec 1999 12:08:58 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23819 for ; Thu, 2 Dec 1999 13:08:57 -0700 (MST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id E52945795C; Thu, 2 Dec 1999 14:08:55 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id DB65454606; Thu, 2 Dec 1999 14:08:55 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 5ABD3BC4CA; Thu, 2 Dec 1999 14:08:49 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id BB7B8B2A4A; Thu, 2 Dec 1999 14:08:48 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000004976; Thu, 2 Dec 1999 15:08:54 -0500 (EST) From: Jim Bound Message-Id: <199912022008.PAA0000004976@quarry.zk3.dec.com> To: "Brian Haberman" Cc: Jim Bound , ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-reply-to: Your message of "Thu, 02 Dec 1999 14:36:53 EST." <3846CA55.F76BF76F@nortelnetworks.com> Date: Thu, 02 Dec 1999 15:08:54 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >I don't see this as being a pressing issue. In fact, similar problems occur Do you mean a pressing problem given our work load on IPv6 and we should work on it later? Or a pressing problem if a customer really does this and it breaks? Two different issues here. Esp for folks shipping IPv6 products now and ones shipping them very soon. >today when people connect running networks with L2 devices. Such an >event requires human intervention, especially if those previously separate >networks were using administratively configured MAC addresses. My >recommendation is that we not concern ourselves with this problem when >we have more pressing concerns at hand. True. But if today this happened with my example and the nodes on the two segments were connected and using IPv4 Global addresses I believe it would work and keep on ticking if as they each would have different subnet masks. For Net 10 (private addresses) this could happen with IPv4 theoretically but I doubt it (two segments doing there own Net 10). But with IPv6 things whether things keep on ticking is something we should at a minimum add to our testing and interoperability tests. I think it will cause a problem because IPv6 states pretty clearly that any node on the same link will not have the same link-local address. That is broken in this case. It could be we not work on it now in the IETF Standards body but I think it will need to be documented at least "Don't do this for now" in vendors product documentation. I will start a thread with the deployment folks too to see what they think. If both the IETF and the Deployment folks want to ignore it for now then fine, but I doubt that the case. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 12:19:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2KC8p08700 for ipng-dist; Thu, 2 Dec 1999 12:12:08 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2KBvc08693 for ; Thu, 2 Dec 1999 12:11:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA29311 for ; Thu, 2 Dec 1999 12:11:57 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07034 for ; Thu, 2 Dec 1999 12:11:56 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id E5F5E15207F; Thu, 2 Dec 1999 14:11:54 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id DB83E148507; Thu, 2 Dec 1999 14:11:54 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 54C5ABC4CA; Thu, 2 Dec 1999 14:11:48 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id B40F8B2A42; Thu, 2 Dec 1999 14:11:47 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000004869; Thu, 2 Dec 1999 15:11:53 -0500 (EST) From: Jim Bound Message-Id: <199912022011.PAA0000004869@quarry.zk3.dec.com> To: Thomas Narten Cc: Jim Bound , ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-reply-to: Your message of "Thu, 02 Dec 1999 14:59:32 EST." <199912021959.OAA09005@rotala.raleigh.ibm.com> Date: Thu, 02 Dec 1999 15:11:53 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think I read your mail that this is then an issue? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 12:31:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2KReZ08729 for ipng-dist; Thu, 2 Dec 1999 12:27:40 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2KRUc08722 for ; Thu, 2 Dec 1999 12:27:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA00808 for ; Thu, 2 Dec 1999 12:27:30 -0800 (PST) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02066; Thu, 2 Dec 1999 13:27:23 -0700 (MST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA33206; Thu, 2 Dec 1999 15:24:04 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA03516; Thu, 2 Dec 1999 15:24:06 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA09134; Thu, 2 Dec 1999 15:24:57 -0500 Message-Id: <199912022024.PAA09134@rotala.raleigh.ibm.com> To: Jim Bound cc: ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-Reply-To: Message from Jim Bound of "Thu, 02 Dec 1999 15:11:53 EST." <199912022011.PAA0000004869@quarry.zk3.dec.com> Date: Thu, 02 Dec 1999 15:24:57 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think I read your mail that this is then an issue? Yes and no. Yes, it is a potential issue. However, I think this will be a rare event in practice, so it's not clear we should try do address it in a way that requires more protocols be developed, etc. Also, I am not at all sure there is a simply fix (or even a correct one). If two nodes have the same link-local address, and both have been operating happily for some time, and they suddenly find themselves on the same link, one of them MUST be shut down (i.e., it needs to stop using the address). There is no graceful way to do this -- all connections using the address will fail. Moreover, which node should be the one that shuts down? I think this really requires manual intervention if you want one machine to continue operating while the other other one shuts down. Unless we use a simple heuristic like the equivalent of flipping a coin to see which machine shuts down. That would be the right answer, in say, 50% of the cases. I don't know that we can do better than that, and this isn't a very good percentage!! Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 12:38:35 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2KZkd08755 for ipng-dist; Thu, 2 Dec 1999 12:35:46 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2KZac08748 for ; Thu, 2 Dec 1999 12:35:37 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA02205 for ; Thu, 2 Dec 1999 12:35:36 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17607 for ; Thu, 2 Dec 1999 12:35:34 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id 9231C9A82F; Thu, 2 Dec 1999 14:35:29 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id 8567F90D87; Thu, 2 Dec 1999 14:35:29 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id F33B5BC4DA; Thu, 2 Dec 1999 14:35:22 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 5FF8FB2A4A; Thu, 2 Dec 1999 14:35:22 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000009686; Thu, 2 Dec 1999 15:35:28 -0500 (EST) From: Jim Bound Message-Id: <199912022035.PAA0000009686@quarry.zk3.dec.com> To: Thomas Narten Cc: Jim Bound , ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-reply-to: Your message of "Thu, 02 Dec 1999 15:24:57 EST." <199912022024.PAA09134@rotala.raleigh.ibm.com> Date: Thu, 02 Dec 1999 15:35:27 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk if i were king i would put in documentation of Ipv6 don't do this? Is there any reason why its really valid to join to mediums together in this manner? I can see it happening cause someone wants two to become one giant extended LAN. in my docs I would say. if you do this shutdown all machines and reboot. but if there is a real network application need to join two mediums like this it will break without rebooting each node. I am not sure we should fix it either I just want to be sure the users no about it somewhere when implementations rollout. some have rolled out already. /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 Dec 2 12:59:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2KroE08782 for ipng-dist; Thu, 2 Dec 1999 12:53:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2Krec08775 for ; Thu, 2 Dec 1999 12:53:41 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA10228 for ; Thu, 2 Dec 1999 12:53:40 -0800 (PST) Received: from mailext04.compaq.com (mailext04.compaq.com [207.18.199.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25686 for ; Thu, 2 Dec 1999 12:53:39 -0800 (PST) Received: by mailext04.compaq.com (Postfix, from userid 12345) id CDAE2104C56; Thu, 2 Dec 1999 14:53:38 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext04.compaq.com (Postfix) with ESMTP id B4725FB101; Thu, 2 Dec 1999 14:53:38 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 1A89ABC4CA; Thu, 2 Dec 1999 14:53:32 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 5EF63B2A43; Thu, 2 Dec 1999 14:53:31 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000013979; Thu, 2 Dec 1999 15:53:37 -0500 (EST) From: Jim Bound Message-Id: <199912022053.PAA0000013979@quarry.zk3.dec.com> To: Thomas Narten Cc: Jim Bound , ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-reply-to: Your message of "Thu, 02 Dec 1999 15:24:57 EST." <199912022024.PAA09134@rotala.raleigh.ibm.com> Date: Thu, 02 Dec 1999 15:53:36 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, This may be relative to the IETF v6 directorate if it is formed checking out specs across the IETF for IPv6ness ..... I don't think other specs using link-local addresses from Ipv6 should develop work arounds to this bug like routing, snmp, or client/server apps. They should keep the bug in their stuff till we fix it here then its fixed uniformly the same way everywhere when we get around to it. Or as if you said it really may not be fixable without a pretty hacked up heuristic then we all have the same applicability statement or whatever that should be, or the same hack. /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 Dec 2 13:03:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2L0ba08800 for ipng-dist; Thu, 2 Dec 1999 13:00:37 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2L0Pc08793 for ; Thu, 2 Dec 1999 13:00:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA08658 for ; Thu, 2 Dec 1999 13:00:24 -0800 (PST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16468; Thu, 2 Dec 1999 14:00:18 -0700 (MST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id PAA31548; Thu, 2 Dec 1999 15:57:02 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.82.31]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id PAA22744; Thu, 2 Dec 1999 15:56:55 -0500 Received: from rotala.raleigh.ibm.com (localhost [127.0.0.1]) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id PAA09349; Thu, 2 Dec 1999 15:57:46 -0500 Message-Id: <199912022057.PAA09349@rotala.raleigh.ibm.com> To: Jim Bound cc: ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-Reply-To: Message from Jim Bound of "Thu, 02 Dec 1999 15:35:27 EST." <199912022035.PAA0000009686@quarry.zk3.dec.com> Date: Thu, 02 Dec 1999 15:57:46 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there any reason why its really valid to join to mediums together in > this manner? I can see it happening cause someone wants two to become > one giant extended LAN. In today's internet, if it can be done, it will. :-) (But that doesn't mean we should should address all issues either.) FWIW, at least some folks in the zeroconf WG think this is a problem they need to address. Scenario: grampa and gramma have multiple subnets at home and their grandchild comes to visit. While playing, she connects segments together via bridge. Oven, phone, tv and toilet stop working. Not acceptable. But they are thinking of a slightly different problem, where IPv4 link-local addresses are generated via stateless addrconf. Collisions are much more likely there because they can't fit the MAC address inside the remaining two bytes of the 169.254/16 IPv4 address. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 13:13:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2L9f208823 for ipng-dist; Thu, 2 Dec 1999 13:09:41 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2L9Vc08816 for ; Thu, 2 Dec 1999 13:09:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA08375 for ; Thu, 2 Dec 1999 13:09:31 -0800 (PST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA20774; Thu, 2 Dec 1999 14:09:28 -0700 (MST) Received: from lemon (lemon.eg.bucknell.edu [134.82.132.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA23651; Thu, 2 Dec 1999 16:06:50 -0500 (EST) Date: Thu, 2 Dec 1999 16:06:48 -0500 (EST) From: "Ralph E. Droms" X-Sender: droms@lemon To: Jim Bound cc: Thomas Narten , ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-Reply-To: <199912022035.PAA0000009686@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2 Dec 1999, Jim Bound wrote: > if i were king i would put in documentation of Ipv6 don't do this? > > Is there any reason why its really valid to join to mediums together in > this manner? I can see it happening cause someone wants two to become > one giant extended LAN. > > in my docs I would say. if you do this shutdown all machines and > reboot. Can you say "AppleTalk"? - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 14:01:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2Lu5m08855 for ipng-dist; Thu, 2 Dec 1999 13:56:05 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2Lttc08848 for ; Thu, 2 Dec 1999 13:55:56 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA17610 for ; Thu, 2 Dec 1999 13:55:55 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23175 for ; Thu, 2 Dec 1999 13:55:52 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 385D21520FC; Thu, 2 Dec 1999 15:55:52 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 3264D148506; Thu, 2 Dec 1999 15:55:52 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 579934FB01; Thu, 2 Dec 1999 15:55:45 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id BE2334C910; Thu, 2 Dec 1999 15:55:44 -0600 (CST) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000003980; Thu, 2 Dec 1999 16:55:49 -0500 (EST) Date: Thu, 2 Dec 1999 16:55:49 -0500 (EST) From: Sowmini Varadhan Message-Id: <199912022155.QAA0000003980@quarry.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: ND- processing neighbor advertisements Cc: Bill.Simpson@um.cc.umich.edu, narten@raleigh.ibm.com, nordmark@sun.com, varadhan@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 2461, Section 7.2.5 [Page 62-63] has: "[if the entry is not incomplete, and the]... Override flag is clear and the supplied link-layer address differs from that in the cache, then one of two actions takes place: if the state of the entry is REACHABLE, set it to STALE, but do not update the entry in any other way;" This statement (and the text leading up to it) places no requirement on the Solicited flag, for the transition from REACHABLE -> STALE for an NA with Override = 0, when the link-layer address in the NA differs from the cached value. However, in Appendix C [Page 85-86], the relevant transitions are: State Event Action New state REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer address than cached. : : !INCOMPLETE NA, Solicited=0, - unchanged Override=0 which indicate that the REACHABLE -> STALE transition has a dependancy on the Solicited flag. So, which one is more accurate? Should the Solicited flag also be considered along with the conditions on Page 62-63 ? --Sowmini -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 14:16:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2MDNr08877 for ipng-dist; Thu, 2 Dec 1999 14:13:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2MDEc08870 for ; Thu, 2 Dec 1999 14:13:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA21514 for ; Thu, 2 Dec 1999 14:13:15 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01193; Thu, 2 Dec 1999 14:13:13 -0800 (PST) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id OAA09898; Thu, 2 Dec 1999 14:00:18 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199912021842.NAA0000019647@quarry.zk3.dec.com> References: <199912021842.NAA0000019647@quarry.zk3.dec.com> Date: Thu, 2 Dec 1999 14:00:17 -0800 To: Jim Bound From: Steve Deering Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together Cc: ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com, bound@zk3.dec.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, As long as people use stateless addr conf, or configure their DHCPv6 servers to generate IPv6 interface IDs from requestors' MAC addresses, the probability of IPv6 address collisions when two separate LANs are merged ought to be negligible (assuming IEEE 802-style LAN addressing). That would seem to be the prudent thing to do. I suppose nodes could run DAD periodically at some low rate, but if the rate is low enough to ensure that no one will care about the overhead, then it'll be too low to quickly detect the collision; and then there's the problem Thomas pointed out about deciding which of the colliders gets nuked. Better just to use MAC-derived link-locals, so collisions will be extremely unlikely to occur, no matter how much unintentional bridging happens. 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 Dec 2 14:51:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2Mlrl08938 for ipng-dist; Thu, 2 Dec 1999 14:47:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2Mlhc08931 for ; Thu, 2 Dec 1999 14:47:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA16884 for ; Thu, 2 Dec 1999 14:47:44 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04871 for ; Thu, 2 Dec 1999 15:47:44 -0700 (MST) Received: from darkstar.iprg.nokia.com (root@darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id OAA13665 for ; Thu, 2 Dec 1999 14:47:43 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id OAA06327 for ; Thu, 2 Dec 1999 14:47:43 -0800 X-Virus-Scanned: Thu, 2 Dec 1999 14:47:43 -0800 Nokia Silicon Valley Email Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma006159; Thu, 2 Dec 99 14:47:37 -0800 Message-ID: <3846F708.ADCFE701@iprg.nokia.com> Date: Thu, 02 Dec 1999 14:47:36 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together References: <199912021842.NAA0000019647@quarry.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If two different LANs were joined together, with two different prefixes, what might go wrong? - Any protocol that uses link-local addresses - nothing else that I can think of just now. It would suddenly look like two prefixes on the same network link. I can't think of any difficulty right now for NUD or other parts of Neighbor Discovery. So, in order to limit the damage, we would just have to be more careful with anything that uses link-local addresses without re-checking their validity. How can it be fixed? With stateless, one (not me) _could_ mandate that detection of a _new_ Router Advertisement prefix would require running DAD again, and as Thomas notes, some sort of arbitration about which node loses (or maybe both of them do). This wouldn't be so horrible, I don't think. With DHCPv6, almost the same thing can be said. Not much would go wrong, as long as the client uses the same relay address to identify itself to the server for subsequent DHCP Requests. If a node changes its link-local address, then it would also has to issue a DHCP Request and possibly a Release. For DHCPv6, putting the two networks together SHOULD be accompanied by the issuance of a RECONFIGURE message containing a newly created routing prefix. For stateless, putting the two networks together does not trigger any currently mandated behavior. However, one _might_ write vendor code that re-executes DAD whenever a _new_ Router Advertisement prefix is detected. I don't want to be seen as suggesting that we modify a Draft Standard. (!) So, if a link-local address has to be changed (say because of overlap after joining two networks), it can cause protocol problems. It is also possible that a link-local address can change for other reasons. For instance, a node may wish to re-randomize its link-local address. I think that many of the considerations would be the same for that case also. Regards, Charlie 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 Thu Dec 2 15:02:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2MwLM08961 for ipng-dist; Thu, 2 Dec 1999 14:58:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2Mw9c08954 for ; Thu, 2 Dec 1999 14:58:10 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA06369 for ; Thu, 2 Dec 1999 14:58:10 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21071; Thu, 2 Dec 1999 14:58:08 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id QAA12171; Thu, 2 Dec 1999 16:51:14 -0600 (CST) Message-Id: <199912022251.QAA12171@gungnir.fnal.gov> To: Jim Bound Cc: ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com From: "Matt Crawford" Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-reply-to: Your message of Thu, 02 Dec 1999 13:42:27 EST. <199912021842.NAA0000019647@quarry.zk3.dec.com> Date: Thu, 02 Dec 1999 16:51:14 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The selection of MAC/EUI64-derived interface identifiers was the best we could do to address the problem. It was discussed. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 15:24:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2NIbk08980 for ipng-dist; Thu, 2 Dec 1999 15:18:37 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2NI8c08973 for ; Thu, 2 Dec 1999 15:18:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA22670 for ; Thu, 2 Dec 1999 15:18:09 -0800 (PST) Received: from bandito.nexabit.com (d28.nexabit.com [209.6.34.253]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16899 for ; Thu, 2 Dec 1999 16:18:08 -0700 (MST) Received: by bandito.nexabit.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 18:17:33 -0500 Message-ID: From: Dimitry Haskin To: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Link-Local Address on Mediums that are Glued Together Date: Thu, 2 Dec 1999 18:17:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My guess is that the probability of two nodes ending up with the same link-local address on joined LANs is not any higher than the probability of two nodes ending up with the same MAC address under the same circumstances. In theory, the latter can occur in IPv4 networks but I don't believe anyone losing sleep over it. ---------------------------------------------------------------------- Dimitry Haskin Lucent Technologies Internetworking Systems -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 15:59:55 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2Nu9U09009 for ipng-dist; Thu, 2 Dec 1999 15:56:09 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2Ntxc09002 for ; Thu, 2 Dec 1999 15:56:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA18194 for ; Thu, 2 Dec 1999 15:56:00 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA15586 for ; Thu, 2 Dec 1999 15:55:59 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Dec 1999 15:54:18 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 15:54:18 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA217A7@RED-MSG-50> From: Richard Draves To: "'Sowmini Varadhan'" , ipng@sunroof.eng.sun.com Cc: narten@raleigh.ibm.com, nordmark@sun.com Subject: RE: ND- processing neighbor advertisements Date: Thu, 2 Dec 1999 15:53:27 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For what it's worth, here's what MSR IPv6 does: The situation is: - you already have an NCE with a link-layer address (the NCE is not INCOMPLETE). - you receive a neighbor advertisement for the neighbor but with a different address in the target link-layer address option. - the override bit is zero. Then if the NCE is in the REACHABLE state, we set it to STALE, otherwise the NCE is not updated in any way. If the solicited flag is set in this situation, then we log a debugging event (it shouldn't happen in normal operation) but the value of the solicited flag doesn't change what happens to the NCE. Rich > -----Original Message----- > From: Sowmini Varadhan [mailto:varadhan@zk3.dec.com] > Sent: Thursday, December 02, 1999 1:56 PM > To: ipng@sunroof.eng.sun.com > Cc: Bill.Simpson@um.cc.umich.edu; narten@raleigh.ibm.com; > nordmark@sun.com; varadhan@zk3.dec.com > Subject: ND- processing neighbor advertisements > > > > > RFC 2461, Section 7.2.5 [Page 62-63] has: > > "[if the entry is not incomplete, and the]... Override flag > is clear and the > supplied link-layer address differs from that in the > cache, then one > of two actions takes place: if the state of the entry is REACHABLE, > set it to STALE, but do not update the entry in any other way;" > > This statement (and the text leading up to it) places no requirement > on the Solicited flag, for the transition from REACHABLE -> STALE > for an NA with Override = 0, when the link-layer address in the > NA differs from the cached value. > > > However, in Appendix C [Page 85-86], the relevant transitions are: > > > State Event Action > New state > > REACHABLE NA, Solicited=1, - STALE > Override=0 > Different link-layer > address than cached. > : > : > > !INCOMPLETE NA, Solicited=0, - > unchanged > Override=0 > > > which indicate that the REACHABLE -> STALE transition has a > dependancy > on the Solicited flag. > > So, which one is more accurate? Should the Solicited flag also > be considered along with the conditions on Page 62-63 ? > > --Sowmini > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 16:01:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB2NxLL09018 for ipng-dist; Thu, 2 Dec 1999 15:59:21 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2NxBc09011 for ; Thu, 2 Dec 1999 15:59:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA18740 for ; Thu, 2 Dec 1999 15:59:11 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04738 for ; Thu, 2 Dec 1999 16:59:11 -0700 (MST) Received: from [171.71.38.63] (deering-office-mac.cisco.com [171.71.38.63]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id PAA29979; Thu, 2 Dec 1999 15:58:39 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <3846F708.ADCFE701@iprg.nokia.com> References: <199912021842.NAA0000019647@quarry.zk3.dec.com> <3846F708.ADCFE701@iprg.nokia.com> Date: Thu, 2 Dec 1999 15:58:38 -0800 To: "Charles E. Perkins" From: Steve Deering Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:47 PM -0800 12/2/99, Charles E. Perkins wrote: >How can it be fixed? > >With stateless, one (not me) _could_ mandate that detection of a >_new_ Router Advertisement prefix would require running DAD again,... Charlie, There's no assurance that each of the merged segments would have an operational router attached at the time of merge, so that would not be a reliable way to detect such an event. And note that even two routerless segments that were merged could suffer communications problems if the same link-local address were assigned to hosts on different segments. Thus, if it's important to detect, then it's important to be able to detect it without the assistance of router advertisements. (Personally, I don't think it's worth worrying about.) 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 Dec 2 16:50:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB30kon09058 for ipng-dist; Thu, 2 Dec 1999 16:46:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB30kfc09051 for ; Thu, 2 Dec 1999 16:46:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA28962 for ; Thu, 2 Dec 1999 16:46:41 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA22076 for ; Thu, 2 Dec 1999 17:46:41 -0700 (MST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Dec 1999 16:44:59 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 16:44:59 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA217A8@RED-MSG-50> From: Richard Draves To: "'Sowmini Varadhan'" , ipng@sunroof.eng.sun.com Cc: narten@raleigh.ibm.com, nordmark@sun.com Subject: RE: ND- processing neighbor advertisements Date: Thu, 2 Dec 1999 16:44:55 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, I thought about this further and I think MSR IPv6 is doing the wrong thing in this situation. I said below that the solicited flag won't normally be set. Actually it can easily happen: when there are two instances of an anycast address on the link, and you send a NS for the anycast address, you'll receive two NAs. When you process the second NA, you'll be in exactly this situation - your NCE is REACHABLE (because you just processed the first NA), the override flag is clear, the solicited flag is set, and the target link-layer address is different than your cached link-layer address. But I think the appendix has it backwards. In the above situation, you want to leave the NCE in the reachable state. It's when the solicited flag is zero that you want to change reachable -> stale. For example suppose that you are moving anycast addresses around on the link, removing them from some interfaces, adding them to new interfaces, but since it's anycast at any instance the address can be assigned to several interfaces. So when you move the anycast address off an old interface onto a new interface you send an unsolicited NA for it with the new link-layer address. A neighbor should update its NCE from reachable -> stale. Then if the neighbor's cached link-layer address is still good, it will quickly correct back to reachable, and if it's bad then it will quickly resolicit. Rich > -----Original Message----- > From: Richard Draves [mailto:richdr@microsoft.com] > Sent: Thursday, December 02, 1999 3:53 PM > To: 'Sowmini Varadhan'; ipng@sunroof.eng.sun.com > Cc: narten@raleigh.ibm.com; nordmark@sun.com > Subject: RE: ND- processing neighbor advertisements > > > For what it's worth, here's what MSR IPv6 does: > > The situation is: > - you already have an NCE with a link-layer address (the NCE is not > INCOMPLETE). > - you receive a neighbor advertisement for the neighbor but > with a different > address in the target link-layer address option. > - the override bit is zero. > > Then if the NCE is in the REACHABLE state, we set it to > STALE, otherwise the > NCE is not updated in any way. > > If the solicited flag is set in this situation, then we log a > debugging > event (it shouldn't happen in normal operation) but the value of the > solicited flag doesn't change what happens to the NCE. > > Rich > > > -----Original Message----- > > From: Sowmini Varadhan [mailto:varadhan@zk3.dec.com] > > Sent: Thursday, December 02, 1999 1:56 PM > > To: ipng@sunroof.eng.sun.com > > Cc: Bill.Simpson@um.cc.umich.edu; narten@raleigh.ibm.com; > > nordmark@sun.com; varadhan@zk3.dec.com > > Subject: ND- processing neighbor advertisements > > > > > > > > > > RFC 2461, Section 7.2.5 [Page 62-63] has: > > > > "[if the entry is not incomplete, and the]... Override flag > > is clear and the > > supplied link-layer address differs from that in the > > cache, then one > > of two actions takes place: if the state of the entry is > REACHABLE, > > set it to STALE, but do not update the entry in any other way;" > > > > This statement (and the text leading up to it) places no requirement > > on the Solicited flag, for the transition from REACHABLE -> STALE > > for an NA with Override = 0, when the link-layer address in the > > NA differs from the cached value. > > > > > > However, in Appendix C [Page 85-86], the relevant transitions are: > > > > > > State Event Action > > New state > > > > REACHABLE NA, Solicited=1, - > STALE > > Override=0 > > Different link-layer > > address than cached. > > : > > : > > > > !INCOMPLETE NA, Solicited=0, - > > unchanged > > Override=0 > > > > > > which indicate that the REACHABLE -> STALE transition has a > > dependancy > > on the Solicited flag. > > > > So, which one is more accurate? Should the Solicited flag also > > be considered along with the conditions on Page 62-63 ? > > > > --Sowmini > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 17:27:04 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB31Nma09088 for ipng-dist; Thu, 2 Dec 1999 17:23:48 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB31Nhc09081 for ; Thu, 2 Dec 1999 17:23:44 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id RAA10759 for ipng@sunroof.eng.sun.com; Thu, 2 Dec 1999 17:23:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB2Mkgc08919 for ; Thu, 2 Dec 1999 14:46:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA16745 for ; Thu, 2 Dec 1999 14:46:43 -0800 (PST) Received: from redes.unam.mx (cuk.redes.unam.mx [132.248.204.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04437 for ; Thu, 2 Dec 1999 15:46:42 -0700 (MST) Received: from localhost (cesar@localhost) by redes.unam.mx (8.9.3/8.9.3) with SMTP id QAA18584; Thu, 2 Dec 1999 16:47:56 -0600 (CST) Date: Thu, 2 Dec 1999 16:47:56 -0600 (CST) From: Cesar Olvera Morales X-Sender: cesar@cuk To: fink@es.net, latif.ladid@tbit.dk, 6bone@ISI.EDU, ipng@sunroof.eng.sun.com, ipv6@redes.unam.mx cc: cesar@redes.unam.mx Subject: National IPv6 Seminar in Mexico Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The National Autonomous University of Mexico, UNAM, (6Bone pTLA 3FFE:8070::/28) are organizing the First National IPv6 Seminar in Mexico, December 10, 1999, Mexico City. The main goal of this Seminar is to assist in the evolution and deployment of IPv6 in Mexico. World IPv6 Community are Welcome. Further information: Cesar Olvera Interoperability Lab Networks Subdirection Telecommunications Direction DGSCA-UNAM (+52) 56 22 8526 cesar@redes.unam.mx http://www.ipv6.unam.mx/seminario/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 2 19:50:17 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB33kZT09213 for ipng-dist; Thu, 2 Dec 1999 19:46:35 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB33kQc09206 for ; Thu, 2 Dec 1999 19:46:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA23394 for ; Thu, 2 Dec 1999 19:46:25 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA03092 for ; Thu, 2 Dec 1999 19:46:25 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 3D51B151FF0; Thu, 2 Dec 1999 21:46:25 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id 3758A148507; Thu, 2 Dec 1999 21:46:25 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 6B6F84FB01; Thu, 2 Dec 1999 21:46:18 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id E31084C90A; Thu, 2 Dec 1999 21:46:17 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000006069; Thu, 2 Dec 1999 22:46:23 -0500 (EST) From: Jim Bound Message-Id: <199912030346.WAA0000006069@quarry.zk3.dec.com> To: Steve Deering Cc: Jim Bound , ipng@sunroof.eng.sun.com, Michael.Carney@east.sun.com, charliep@iprg.nokia.com Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together In-reply-to: Your message of "Thu, 02 Dec 1999 14:00:17 PST." Date: Thu, 02 Dec 1999 22:46:23 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >As long as people use stateless addr conf, or configure their DHCPv6 >servers to generate IPv6 interface IDs from requestors' MAC addresses, >the probability of IPv6 address collisions when two separate LANs are >merged ought to be negligible (assuming IEEE 802-style LAN addressing). >That would seem to be the prudent thing to do. I suppose nodes could >run DAD periodically at some low rate, but if the rate is low enough to >ensure that no one will care about the overhead, then it'll be too low >to quickly detect the collision; and then there's the problem Thomas >pointed out about deciding which of the colliders gets nuked. Better >just to use MAC-derived link-locals, so collisions will be extremely >unlikely to occur, no matter how much unintentional bridging happens. Nice response on what to tell folks. I don't want us to beat this to death. I know we discussed it just pointing out it popped up again. We may hear from zeroconf folks though. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 21:52:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB35n1o09274 for ipng-dist; Thu, 2 Dec 1999 21:49:01 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB35moc09267 for ; Thu, 2 Dec 1999 21:48:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA26069 for ; Thu, 2 Dec 1999 21:48:49 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA05022 for ; Thu, 2 Dec 1999 21:48:49 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 02 Dec 1999 21:28:21 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 21:28:20 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F4A@RED-MSG-02> From: Brian Zill To: "'Jim Bound'" , Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: RE: IPv6 Link-Local Address on Mediums that are Glued Together Date: Thu, 2 Dec 1999 21:28:19 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Not to add fuel to the flames here, but I just wanted to point out that besides physical links getting glued together, this potential problem also exists for wireless links. (Maybe this was discussed before and I missed it?) It is not uncommon for wireless nodes to think that they are on link when they have actually been shut out due to interference, signal loss or whatever. So DAD could fail to detect a collision here as well. A wireless node might come back from a dead spot to find that another node has taken its link-local address in the meantime. So, if anyone is writing an IPv6 over wireless foo draft, you might want to note that it's even more critical than normal that the interface identifiers used to create the link-local addresses be globally unique (or are at least guaranteed unique for all interfaces on that type of link media). Cheers, --Brian > -----Original Message----- > From: Jim Bound [mailto:bound@zk3.dec.com] > Sent: Thursday, 02 December, 1999 19:46 > To: Steve Deering > Subject: Re: IPv6 Link-Local Address on Mediums that are > Glued Together > > > Steve, > > >As long as people use stateless addr conf, or configure > >their DHCPv6 servers to generate IPv6 interface IDs from > >requestors' MAC addresses, the probability of IPv6 address > >collisions when two separate LANs are merged ought to be > >negligible (assuming IEEE 802-style LAN addressing). > >That would seem to be the prudent thing to do. I suppose > >nodes could run DAD periodically at some low rate, but if > >the rate is low enough to ensure that no one will care > >about the overhead, then it'll be too low to quickly > >detect the collision; and then there's the problem Thomas > >pointed out about deciding which of the colliders gets > >nuked. Better just to use MAC-derived link-locals, so > >collisions will be extremely unlikely to occur, no matter > >how much unintentional bridging happens. > > Nice response on what to tell folks. > > I don't want us to beat this to death. I know we discussed > it just pointing out it popped up again. We may hear from > zeroconf folks though. > > thanks > /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 22:11:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) id dB367x009404 for ipng-dist; Thu, 2 Dec 1999 22:08:00 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB367bc09397 for ; Thu, 2 Dec 1999 22:07:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA02944 for ; Thu, 2 Dec 1999 22:07:33 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA19656 for ; Thu, 2 Dec 1999 23:07:20 -0700 (MST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id RAA06277 for ; Fri, 3 Dec 1999 17:07:06 +1100 (EST) Date: Fri, 3 Dec 1999 17:07:06 +1100 (EST) From: Peter Tattam To: IPNG Mailing List Subject: node local addresses? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In all the discussion about site local & link local addressing, A thought occured to me that another class of addresses might exist that I am not sure has been defined (as far can tell from RFC 2373). The class of addresses is those which are node local, i.e. they don't go out on the wire ever. Ipv6 has restricted the loopback addresses to 1 address so they can't be used anymore. The usage of such addresses is for providing virtual IP services within the host using addresses that won't ever go out on the wire. This may sound unusual, but I have had circumstances which required me to "make up" some addresses in V4 to serve the purpose of demultiplexing V4-V6 address translation at the API level. I can think of applications that might benefit from such a division within a multi user host such as providing each process with it's own local address, each user with their own subnet and so forth. This might also then be a useful tool in the arsenal required in fortifying shared hosts, and could possibly helps resolve problems associated with security attacks where the attacker uses a benign service to get access to a restricted service. The range of applications would be typically those that access IP based client/server system that reside on the same host. (e.g. shared proxy & web server, SQL server on same server as web server etc...) Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 22:37:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB36UJF09560 for ipng-dist; Thu, 2 Dec 1999 22:30:19 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB36U7809552 for ; Thu, 2 Dec 1999 22:30:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA04249 for ; Thu, 2 Dec 1999 22:30:06 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA25232 for ; Thu, 2 Dec 1999 23:30:05 -0700 (MST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id RAA07600; Fri, 3 Dec 1999 17:27:09 +1100 (EST) Date: Fri, 3 Dec 1999 17:27:09 +1100 (EST) From: Peter Tattam To: Brian Zill cc: "'Jim Bound'" , Steve Deering , ipng@sunroof.eng.sun.com Subject: RE: IPv6 Link-Local Address on Mediums that are Glued Together In-Reply-To: <3D2036E25376D31197A100805FEAD892712F4A@RED-MSG-02> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2 Dec 1999, Brian Zill wrote: > Not to add fuel to the flames here, but I just wanted to point out that > besides physical links getting glued together, this potential problem also > exists for wireless links. (Maybe this was discussed before and I missed > it?) It is not uncommon for wireless nodes to think that they are on link > when they have actually been shut out due to interference, signal loss or > whatever. So DAD could fail to detect a collision here as well. A wireless > node might come back from a dead spot to find that another node has taken > its link-local address in the meantime. > > So, if anyone is writing an IPv6 over wireless foo draft, you might want to > note that it's even more critical than normal that the interface identifiers > used to create the link-local addresses be globally unique (or are at least > guaranteed unique for all interfaces on that type of link media). > > Cheers, The key to any situation like this is to come up with mechanisms for determining that the physical topology has changed to force a DAD. With radio, that event is more likely to be visible than with ethernet. Even with DAD, if you have active connections with a duplicate address, these are going to break right away. Classic TCP readdressing scenario again. Give me stateless autoconfig with globally unique addresses any day. As mobile computing & zeroconf computing is going to be the next major growth area, these are issues that are going to turn around to bite us in the b**. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 22:58:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB36qCu09583 for ipng-dist; Thu, 2 Dec 1999 22:52:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB36q1809576 for ; Thu, 2 Dec 1999 22:52:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA05836 for ; Thu, 2 Dec 1999 22:52:00 -0800 (PST) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA00429 for ; Thu, 2 Dec 1999 23:51:59 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id WAA16380; Thu, 2 Dec 1999 22:51:24 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Thu, 2 Dec 1999 22:51:33 -0800 To: Peter Tattam From: Steve Deering Subject: Re: node local addresses? Cc: IPNG Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:07 PM +1100 12/3/99, Peter Tattam wrote: >The class of addresses is those which are node local, i.e. they don't go >out on the wire ever. Ipv6 has restricted the loopback addresses to 1 >address so they can't be used anymore. Peter, What leads you to that conclusion?. If you think of a node's loopback address as simply its link-local address on a phantom interface that goes nowhere (the so-called loopback interface), you might realize you can assign any number of additional addresses to that phantom interface, of any scope (though to be useful for scopes larger than link-local, you'll need to do "forwarding" between the phantom interface and one or more real interfaces). You could also in theory create multiple phantom interfaces, each with its own address(es), if that were useful for some reason. Perhaps this model is a little less elegant than having a class of node-local unicast addresses, but it avoids having to change our definition of an address as an identifier for an interface, and having to deal with the consequences of having interface-less addresses. Besides, it's a a familiar model from IPv4. I certainly don't think we have removed any functionality available in IPv4, which is what your "can't be used anymore" phrase would seem to imply. 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 Dec 2 23:03:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB36vMF09592 for ipng-dist; Thu, 2 Dec 1999 22:57:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB36vB809585 for ; Thu, 2 Dec 1999 22:57:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA26676 for ; Thu, 2 Dec 1999 22:57:10 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA01786 for ; Thu, 2 Dec 1999 23:57:08 -0700 (MST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id RAA09574 for ; Fri, 3 Dec 1999 17:57:08 +1100 (EST) Date: Fri, 3 Dec 1999 17:57:08 +1100 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Session survivability over renumbering, spoofing, address overloading. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just to lighten up the discussion a bit, here's some thoughts that might tickle the brain cells a little.... I was going to add it to the previous message, but thought it warranted its own article. It is not intended to be a serious article, but just food for the grey matter. --- You know, I can't help thinking the session survivability over renumbering issue is probably indirectly a result of having oodles of addresses available and that we are exploring new ways of internetworking that utilize that surplus of address space. Similar thing happened in the CPU industry a couple of decades or so ago resulting in the invention of virtual memory and new ways of using memory that stopped the madness. It's fascinating that there is a strong parallel between NAT and Virtual Memory. The virtual network behind a NAT is the equivalent to the virtual address space of a computer while the real internet is equivalent to the physical address space of a computer. THe NAT box is the equivalent of an MMU and joins the virtual network to the physical world. The parallels start to break down a bit after that, but it's perhaps a new way to look at internetworking. Point to point connectivity between the NAT's then becomes a similar issue to IPC on a computer which is solved in a variety of ways on a shared virtual memory computer system. As much as NAT is a dirty word in the Internet business, perhaps the eventual future of the internet will work out to be some kind of NAT or MMU equivalent system. Heck, perhaps building a NAT based internet using MMU principles might actually be the holy grail that flat internetworking is looking for. As for spoofing & address overloading? Spoofing would be much more difficult to do from behind a NAT - the rough analogy of memory protection in the CPU environment. Address overloading (as in the site local & link local discussions recently) would be a matter of address management at the NAT box, much like multiple processes can share the same address space, but not coincide. To use the virtual memory analogy, you would manage it by using the NAT box for inter segment communication. It should be spelt out that if you plug two subnets together you'll get trouble, much like if you plug two power systems together - sparks will fly. Peter A small NAT joke, "On the NAT, noone knew I wasn't a dog." -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 2 23:51:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB37ikN09648 for ipng-dist; Thu, 2 Dec 1999 23:44:46 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB37iY809641 for ; Thu, 2 Dec 1999 23:44:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA15887 for ; Thu, 2 Dec 1999 23:44:35 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04568 for ; Thu, 2 Dec 1999 23:44:34 -0800 (PST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id SAA12743; Fri, 3 Dec 1999 18:43:49 +1100 (EST) Date: Fri, 3 Dec 1999 18:43:48 +1100 (EST) From: Peter Tattam To: Steve Deering cc: IPNG Mailing List Subject: Re: node local addresses? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2 Dec 1999, Steve Deering wrote: > At 5:07 PM +1100 12/3/99, Peter Tattam wrote: > >The class of addresses is those which are node local, i.e. they don't go > >out on the wire ever. Ipv6 has restricted the loopback addresses to 1 > >address so they can't be used anymore. > > Peter, > > What leads you to that conclusion?. If you think of a node's loopback > address as simply its link-local address on a phantom interface that > goes nowhere (the so-called loopback interface), you might realize you > can assign any number of additional addresses to that phantom interface, > of any scope (though to be useful for scopes larger than link-local, > you'll need to do "forwarding" between the phantom interface and one > or more real interfaces). > > You could also in theory create multiple phantom interfaces, each with > its own address(es), if that were useful for some reason. > > Perhaps this model is a little less elegant than having a class of > node-local unicast addresses, but it avoids having to change our > definition of an address as an identifier for an interface, and > having to deal with the consequences of having interface-less > addresses. Besides, it's a a familiar model from IPv4. > > I certainly don't think we have removed any functionality available in IPv4, > which is what your "can't be used anymore" phrase would seem to imply. That is fine. I didn't know the reason for the change. I'm not arguing for functionality loss, but if you want to split hairs, *if* I had used 127.* addresses for my bump-in-the-api mechanism, and then wanted to reimplement the same strategy for IPv6 but for some as yet undefined protocol in another family, I would be stumped. I currently use part of the reserved for experimental use v4 address space and there is no parallel in the v6 address space. Given your definition that addresses can only be assigned to interfaces, then would it be legal to invent a virtual interface for each entity on the host (be it a process, user, process class, socket, file or whatever)? Then my need for node-local addresses should go away right? I would then need a sure fire way to generate a link-local address that is unique in the domain of the host/node, and I believe this is specified somewhere, but I can't find it. There are added problems in that the EUI-64 component for the virtual interfaces will need to be derived from other sources. It's a kludge but I think I can make it achieve the desired result. I will leave open the issue of whether the interface number of the virtual interfaces is encoded in the address or not. It would simplify transport layer issues if it was, and also make life easier for any applications that might use the addresses in such a way to perform service selection... e.g. proxy web server filter lists. Another issue with my kludge is that the traffic from real interfaces would be indistinguishable from virtual interfaces, and with potential address overloading problems necessitating using an out of band interface ID to work out exactly who the address was from. Not very pretty, especially when trying to set up address matching lists. The concepts might be better dealt with by node local addresses that can be guranteed locally unique by address alone, even if they were still allocated from the current link local address space. I believe computing will be taking two independent directions in the future, one towards more and more mobile computing and nano devices. The other direction I think may happen is the growth of more and more centralized server based computing to manage the needs of the smaller devices being connected. Hence the need for finer grained node local addressing. > > Steve > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 3 07:08:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB3F4ca09835 for ipng-dist; Fri, 3 Dec 1999 07:04:38 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB3F4T809828 for ; Fri, 3 Dec 1999 07:04:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA23533 for ; Fri, 3 Dec 1999 07:04:29 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11757 for ; Fri, 3 Dec 1999 08:04:28 -0700 (MST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id HAA10406; Fri, 3 Dec 1999 07:04:19 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Thu, 2 Dec 1999 23:37:29 -0800 To: Peter Tattam From: Steve Deering Subject: Re: Session survivability over renumbering, spoofing, address overloading. Cc: IPNG Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:57 PM +1100 12/3/99, Peter Tattam wrote: >It's fascinating that there is a strong parallel between NAT and Virtual >Memory. Peter, You're not the first to make this observation. Here's a part of a reply I sent recently to someone else who had the same "insight": >I too have an analogy between NAT and memory systems. When 32-bit >PCs first came to market, there was a large installed base of 16-bit >programs and 16-bit compilers that could not address the new larger >memories. So people invented various techniques like "bank-switching" >to allow 16-bit programs to address more than 64K of memory. Sure, >that sort of trick was important for transition to the larger-address- >space machines, but I think the state of application programming is >much better off that we didn't stop at that point. > >NAT, as an alternative to IPv6, is in the same class of solutions as >bank-switching, useful as a transition technique but, I believe, >crippling in the long run. > >Aside: There *is* something very analogous to virtual memory in IP > addressing and that is Mobile IP, in which a device can be > addressed by its "virtual address" (its home IP address) and > that gets mapped by some magic under the covers to its > current "real address" (the temporary IP address acquired at > the device's current location). Note that, like virtual > memory systems, Mobile IP uses the same size and syntax for > both virtual and real addresses, which allows some of a > program's virtual address space to be mapped directly to the > same values in the real address space and some of the virtual > space to be mapped to different real addresses, without the > assistance or knowledge of the program. 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 Dec 3 07:29:48 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB3FQO409873 for ipng-dist; Fri, 3 Dec 1999 07:26:24 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB3FQD809866 for ; Fri, 3 Dec 1999 07:26:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA25133 for ; Fri, 3 Dec 1999 07:26:13 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00397 for ; Fri, 3 Dec 1999 07:26:12 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA19392; Fri, 3 Dec 1999 09:26:09 -0600 (CST) Message-Id: <199912031526.JAA19392@gungnir.fnal.gov> To: Peter Tattam Cc: IPNG Mailing List From: "Matt Crawford" Subject: Re: node local addresses? In-reply-to: Your message of Fri, 03 Dec 1999 18:43:48 +1100. Date: Fri, 03 Dec 1999 09:26:08 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would then need a sure fire way to generate a link-local address > that is unique in the domain of the host/node, and I believe this > is specified somewhere, but I can't find it. There are added > problems in that the EUI-64 component for the virtual interfaces > will need to be derived from other sources. Then you want a non-EUI64 address (the "globally unique" bit set to 0) and with 63 other bits to play with and all the interfaces created by the same kernel, it should be trivial to generate guaranteed node-unique identifiers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 3 08:15:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB3GBet09915 for ipng-dist; Fri, 3 Dec 1999 08:11:40 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB3GBV809908 for ; Fri, 3 Dec 1999 08:11:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA19140 for ; Fri, 3 Dec 1999 08:11:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08897 for ; Fri, 3 Dec 1999 09:11:30 -0700 (MST) Received: from darkstar.iprg.nokia.com (root@darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id IAA22057; Fri, 3 Dec 1999 08:11:25 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id IAA30043; Fri, 3 Dec 1999 08:11:25 -0800 X-Virus-Scanned: Fri, 3 Dec 1999 08:11:25 -0800 Nokia Silicon Valley Email Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma029965; Fri, 3 Dec 99 08:11:20 -0800 Message-ID: <3847EBA8.EDDA589B@iprg.nokia.com> Date: Fri, 03 Dec 1999 08:11:20 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Peter Tattam CC: IPNG Mailing List Subject: Re: Session survivability over renumbering, spoofing, address overloading. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Tattam wrote: > As much as NAT is a dirty word in the Internet business, perhaps the eventual > future of the internet will work out to be some kind of NAT or MMU equivalent > system. Heck, perhaps building a NAT based internet using MMU principles might > actually be the holy grail that flat internetworking is looking for. I think the analogy breaks down almost immediately, because end-to-end addressability is the cornerstone for peer-to-peer communication in the Internet. Memory_address to memory_address connectivity is not an important concept for inter-process communication between processes using virtual address spaces. Regards, Charlie 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 Dec 3 10:12:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB3I8ut10120 for ipng-dist; Fri, 3 Dec 1999 10:08:57 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB3I8q810113 for ; Fri, 3 Dec 1999 10:08:52 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA13386 for ipng@sunroof.eng.sun.com; Fri, 3 Dec 1999 10:08:23 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta7+Sun/8.10.0.Beta7) with ESMTP id dB35xoc09374 for ; Thu, 2 Dec 1999 21:59:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA26660 for ; Thu, 2 Dec 1999 21:59:49 -0800 (PST) Received: from wizard.nasa.atd.net (wizard.nasa.atd.net [198.119.6.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA17817 for ; Thu, 2 Dec 1999 22:59:48 -0700 (MST) Received: (from bill@localhost) by wizard.nasa.atd.net (8.9.1a/8.8.7) id AAA27598; Fri, 3 Dec 1999 00:59:47 -0500 (EST) From: Bill Fink Message-Id: <199912030559.AAA27598@wizard.nasa.atd.net> Subject: Re: IPv6 Link-Local Address on Mediums that are Glued Together To: dhaskin@nexabit.com (Dimitry Haskin) Date: Fri, 3 Dec 1999 00:59:47 -0500 (EST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Dimitry Haskin" at Dec 02, 1999 06:17:29 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My guess is that the probability of two nodes ending up with the same > link-local > address on joined LANs is not any higher than the probability of two nodes > ending up with the same MAC address under the same circumstances. In > theory, > the latter can occur in IPv4 networks but I don't believe anyone losing > sleep over it. I agree. It should be very rare. And when it does happen, you can just do what is done with IPv4, namely spit out a message to the system console (if you bother checking for duplicates periodically); that is if there is a system console or log file to send it to. I guess in the home environment, your phone could call you and tell you that your home network had detected a duplicate IPv6 address between your toaster and toothbrush. :-) -Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 3 10:16:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB3IEPM10155 for ipng-dist; Fri, 3 Dec 1999 10:14:25 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB3IEK810148 for ; Fri, 3 Dec 1999 10:14:20 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA13458 for ipng@sunroof.eng.sun.com; Fri, 3 Dec 1999 10:13:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB3ETL809809 for ; Fri, 3 Dec 1999 06:29:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA25484 for ; Fri, 3 Dec 1999 06:29:16 -0800 (PST) Received: from arsenic.uunet.lu (arsenic.uunet.lu [194.7.192.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28714 for ; Fri, 3 Dec 1999 07:29:15 -0700 (MST) Received: from compaq (pool352-194-7-204-67.uunet.lu [194.7.204.67]) by arsenic.uunet.lu (8.9.1/8.9.1) with SMTP id PAA13902; Fri, 3 Dec 1999 15:29:01 +0100 (CET) Message-ID: <00a101bf3d9a$8b77b7c0$43cc07c2@compaq> Reply-To: "Latif LADID" From: "Latif LADID" To: "Cesar Olvera Morales" , , <6bone@ISI.EDU>, , Cc: Subject: Re: National IPv6 Seminar in Mexico Date: Fri, 3 Dec 1999 15:22:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Great Initiative Cesar! Next time invite us on time to come and support you! Have a good conference and let us know of outcome! Regards, Latif ****************************************** Latif LADID, President, IPv6 FORUM Vice President, Ericsson Telebit A/S 31, Domaine de Brameschhof L-8290 KEHLEN - LUXEMBOURG Tel: + 352 - 30 71 35 Fax: + 352 - 30 53 64 @-mail: latif.ladid@tbit.dk http://www.tbit.dk ******************** IPv6 Forum************* The New Internet: http://www.ipv6forum.com Internet For EveryOne ------ Security & Quality -------- ****************************************** UPCOMING EVENTS: -- German IPv6 Conference in Berlin, Germany Dec 8-9, run jointly by Deutsche Telekom and DFN -- GLOBAL IPvIPv6 SUMMIT in US, March 13-15, 2000 run jointly by Stardust.com and IPv6 Forum --GLOBAL IPv6 SUMMIT in UK, May 10, 2000 hosted by BT and WTC in Birmingham -- ComNet 2000 - Washington D.C.- Jan 25-27 Joint appearance: ISOC / IPv6 Forum ******************************************** -----Original Message----- From: Cesar Olvera Morales To: fink@es.net ; latif.ladid@tbit.dk ; 6bone@ISI.EDU <6bone@ISI.EDU>; ipng@sunroof.eng.sun.com ; ipv6@redes.unam.mx Cc: cesar@redes.unam.mx Date: Thursday, December 02, 1999 11:46 Subject: National IPv6 Seminar in Mexico : :The National Autonomous University of Mexico, UNAM, (6Bone pTLA :3FFE:8070::/28) are organizing the First National IPv6 Seminar in Mexico, :December 10, 1999, Mexico City. : :The main goal of this Seminar is to assist in the evolution and deployment :of IPv6 in Mexico. : :World IPv6 Community are Welcome. : :Further information: : :Cesar Olvera :Interoperability Lab :Networks Subdirection :Telecommunications Direction :DGSCA-UNAM : :(+52) 56 22 8526 : :cesar@redes.unam.mx :http://www.ipv6.unam.mx/seminario/ : : : -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 3 18:07:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB424G610669 for ipng-dist; Fri, 3 Dec 1999 18:04:16 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB4243810652 for ; Fri, 3 Dec 1999 18:04:03 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA12414 for ; Fri, 3 Dec 1999 18:04:02 -0800 (PST) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA21001 for ; Fri, 3 Dec 1999 18:04:02 -0800 (PST) Received: from amontillado.research.att.com (amontillado.research.att.com [135.207.24.32]) by mail-green.research.att.com (Postfix) with ESMTP id 3632D1E002; Fri, 3 Dec 1999 21:04:01 -0500 (EST) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by amontillado.research.att.com (8.8.7/8.8.7) with ESMTP id VAA04571; Fri, 3 Dec 1999 21:04:20 -0500 (EST) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id EA2AB41F16; Fri, 3 Dec 1999 21:03:59 -0500 (EST) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id DB223400B4; Fri, 3 Dec 1999 21:03:54 -0500 (EST) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Steve Deering Cc: Peter Tattam , IPNG Mailing List Subject: Re: Session survivability over renumbering, spoofing, address overloading. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 03 Dec 1999 21:03:54 -0500 Message-Id: <19991204020359.EA2AB41F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Steve Deering writes: > At 5:57 PM +1100 12/3/99, Peter Tattam wrote: > >It's fascinating that there is a strong parallel between NAT and Virtual > >Memory. > > Peter, > > You're not the first to make this observation. Here's a part of a reply > I sent recently to someone else who had the same "insight": > There's another analogy that I pointed out on the NAT mailing list, one that carries a serious warning -- virtual memory is only useful when the working set is small enough relative the size of physical memory. When there is too much demand for real memory -- by analogy, too much *need* for global addresses -- at any one time, the system thrashes and nothing useful gets done. I've been using virtual memory for a couple of decades now -- and I haven't noticed machines shipping with less memory as a result. Quite the contrary, in fact. --Steve Bellovin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 3 20:45:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB44gED10722 for ipng-dist; Fri, 3 Dec 1999 20:42:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB44g5810715 for ; Fri, 3 Dec 1999 20:42:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA25360 for ; Fri, 3 Dec 1999 20:42:05 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19593 for ; Fri, 3 Dec 1999 20:42:03 -0800 (PST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id PAA03755; Sat, 4 Dec 1999 15:41:52 +1100 (EST) Date: Sat, 4 Dec 1999 15:41:52 +1100 (EST) From: Peter Tattam To: "Steven M. Bellovin" cc: Steve Deering , IPNG Mailing List Subject: The Naked Internet (was Re: Session survivability over renumbering, spoofing, address overloading. ) In-Reply-To: <19991204020359.EA2AB41F16@SIGABA.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 3 Dec 1999, Steven M. Bellovin wrote: > In message , Steve Deering writes: > > At 5:57 PM +1100 12/3/99, Peter Tattam wrote: > > >It's fascinating that there is a strong parallel between NAT and Virtual > > >Memory. > > > > Peter, > > > > You're not the first to make this observation. Here's a part of a reply > > I sent recently to someone else who had the same "insight": > > > There's another analogy that I pointed out on the NAT mailing list, one that > carries a serious warning -- virtual memory is only useful when the working > set is small enough relative the size of physical memory. When there is too > much demand for real memory -- by analogy, too much *need* for global > addresses -- at any one time, the system thrashes and nothing useful gets done. > > I've been using virtual memory for a couple of decades now -- and I haven't > noticed machines shipping with less memory as a result. Quite the contrary, > in fact. > > --Steve Bellovin > > Good points... I agree that NAT is analogous like the bank switching concepts... however, it is *also* analogous to a CPU system where a user process typically loads its program at the same address. There are two reasons for virtual memory. The main one is to use more memory than is available. The secondary one is for protecting processes from each other and the kernel from the users. Much of the problem with spoofing is a result of giving the user the ability to use raw addresses, analagous to the unprotected process having access to unprotected address space. The biggest argument against NAT revolves around the argument of needing end-end connectivity with real addresses. Computer science is littered with instances of where machine mechanisms that are too powerful need to be tamed. Examples: Gotos. have largely been replaced by structured programming raw pointers still in use, but slowly being replaced by structured techniques like classes and languages like Java etc. Unprotected Memory systems. mainly replaced by virtual memory for most(?) OSes. There are still vestiges of unprotected address space on popular desk top OSes. Multitasking synchronization semaphores were invented to help, and are still in wide use, slowly being replaced by better mechanisms like monitors. I know this is right outside the charter of the working group, and I would have to agree with the arguments that NAT is perceived as bad, however, we should not ignore the lessons that the history of computer science has shown us. Given that the internet is far wider reaching than it was originally designed for, and has growing numbers of participants who no longer wish to subscribe to the philosophy of mutual cooperation that founded it, don't you think it's time to start thinking more carefully about some of the issues of protecting the billions of users that will potentially be using it in the next 100 years. We can't simply ignore the fact that thousands of NATs have been grafted into the Internet, and this has already driven protocol development to the point where end-end connectivity is not essential for the bulk of jobs done. Joining the NAT islands obviously needs public addressing to do the job. Perhaps what I am suggesting is that we need to work out techniques that wrestle the control of who can transmit on a public address out of the hands of the potentially hostile attacker. Automatic ingress filters are one solution to the spoofing problem, NAT class solutions are another. I contend that the growing range of network attacks is likely the result of the Naked Internet. Let us hope that Ipv6 does not highlight the problem any more than it is at the moment. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 3 21:11:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB458ZI10742 for ipng-dist; Fri, 3 Dec 1999 21:08:35 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB458Q810735 for ; Fri, 3 Dec 1999 21:08:27 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA12448 for ; Fri, 3 Dec 1999 21:08:25 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA24080 for ; Fri, 3 Dec 1999 21:08:25 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA11369; Fri, 3 Dec 1999 21:07:44 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: Date: Fri, 3 Dec 1999 21:07:57 -0800 To: Peter Tattam From: Steve Deering Subject: Re: The Naked Internet (was Re: Session survivability over renumbering, spoofing, address overloading. ) Cc: "Steven M. Bellovin" , IPNG Mailing List Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:41 PM +1100 12/4/99, Peter Tattam wrote: > ...we should >not ignore the lessons that the history of computer science has shown us. Trouble is, it is possible to come up with a lesson from computer science to support any technical or architectural argument you care to make. I learned this a few years ago in an animated debate over the design of a multicast routing protocol, in which four people were arguing for completely different and conflicting approaches, each supported by a different computer science aphorism. Anyway, I agree with your general point that making the Internet and its users more secure from each other is vitally important, and that ingress filtering is an important step in that direction. However, I don't think that having multiple entities re-using the same address space enhances security at all. (It *would* if there weren't any NATs between them, but as soon as you join "private" address space with address translators, you open a path between them and thus create security vulnerabilities.) In fact, re-use of address space makes it *easier* for undetected leakage to occur between addressing domains, because you can't recognize "foreign" addresses. 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 Dec 3 21:43:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB45ebU10770 for ipng-dist; Fri, 3 Dec 1999 21:40:37 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB45eS810763 for ; Fri, 3 Dec 1999 21:40:28 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA13747 for ; Fri, 3 Dec 1999 21:40:26 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA28586 for ; Fri, 3 Dec 1999 21:40:26 -0800 (PST) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.9.3/8.9.3) with SMTP id QAA07620 for ; Sat, 4 Dec 1999 16:40:25 +1100 (EST) Date: Sat, 4 Dec 1999 16:40:25 +1100 (EST) From: Peter Tattam To: IPNG Mailing List Subject: Re: The Naked Internet (was Re: Session survivability over renumbering, spoofing, address overloading. ) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 3 Dec 1999, Steve Deering wrote: > At 3:41 PM +1100 12/4/99, Peter Tattam wrote: > > ...we should > >not ignore the lessons that the history of computer science has shown us. > > Trouble is, it is possible to come up with a lesson from computer science > to support any technical or architectural argument you care to make. > I learned this a few years ago in an animated debate over the design > of a multicast routing protocol, in which four people were arguing for > completely different and conflicting approaches, each supported by a > different computer science aphorism. > > Anyway, I agree with your general point that making the Internet and its > users more secure from each other is vitally important, and that ingress > filtering is an important step in that direction. However, I don't think > that having multiple entities re-using the same address space enhances > security at all. (It *would* if there weren't any NATs between them, > but as soon as you join "private" address space with address translators, > you open a path between them and thus create security vulnerabilities.) > In fact, re-use of address space makes it *easier* for undetected > leakage to occur between addressing domains, because you can't recognize > "foreign" addresses. > > Steve Ok. I concede defeat on this one. I'd like to explore the possibility of automated ingress filtering though. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Dec 4 09:14:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB4HBM611006 for ipng-dist; Sat, 4 Dec 1999 09:11:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB4HBD810999 for ; Sat, 4 Dec 1999 09:11:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA16801 for ; Sat, 4 Dec 1999 09:11:13 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20418 for ; Sat, 4 Dec 1999 09:11:13 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id JAA04904; Sat, 4 Dec 1999 09:10:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id JAA18511; Sat, 4 Dec 1999 09:10:38 -0800 X-Virus-Scanned: Sat, 4 Dec 1999 09:10:38 -0800 Nokia Silicon Valley Email Scanner Received: from (ihinden-3.iprg.nokia.com [205.226.22.76]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma018430; Sat, 4 Dec 99 09:10:30 -0800 Message-Id: <4.2.2.19991204090421.03feb8d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 04 Dec 1999 09:08:45 -0800 To: Peter Tattam From: Bob Hinden Subject: Re: node local addresses? Cc: IPNG Mailing List In-Reply-To: <199912031526.JAA19392@gungnir.fnal.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk See Appendix A "Creating EUI-64 based Interface Identifiers" in RFC-2373. Bob At 09:26 AM 12/3/99 -0600, Matt Crawford wrote: > > I would then need a sure fire way to generate a link-local address > > that is unique in the domain of the host/node, and I believe this > > is specified somewhere, but I can't find it. There are added > > problems in that the EUI-64 component for the virtual interfaces > > will need to be derived from other sources. > >Then you want a non-EUI64 address (the "globally unique" bit set to >0) and with 63 other bits to play with and all the interfaces created >by the same kernel, it should be trivial to generate guaranteed >node-unique identifiers. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 6 00:21:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB68GPn11509 for ipng-dist; Mon, 6 Dec 1999 00:16:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB68GG811502 for ; Mon, 6 Dec 1999 00:16:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA07708 for ; Mon, 6 Dec 1999 00:16:17 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA20277 for ; Mon, 6 Dec 1999 01:16:13 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id RAA12393; Mon, 6 Dec 1999 17:04:21 +0900 (JST) Date: Mon, 06 Dec 1999 17:13:51 +0900 Message-ID: <14411.28735.639316.36620E@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: varadhan@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: RE: ND- processing neighbor advertisements In-Reply-To: In your message of "Thu, 2 Dec 1999 16:44:55 -0800 " <4D0A23B3F74DD111ACCD00805F31D8101CA217A8@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA217A8@RED-MSG-50> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 82 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 2 Dec 1999 16:44:55 -0800 , >>>>> Richard Draves said: > But I think the appendix has it backwards. In the above situation, you want > to leave the NCE in the reachable state. It's when the solicited flag is > zero that you want to change reachable -> stale. > For example suppose that you are moving anycast addresses around on the > link, removing them from some interfaces, adding them to new interfaces, but > since it's anycast at any instance the address can be assigned to several > interfaces. So when you move the anycast address off an old interface onto a > new interface you send an unsolicited NA for it with the new link-layer > address. A neighbor should update its NCE from reachable -> stale. Then if > the neighbor's cached link-layer address is still good, it will quickly > correct back to reachable, and if it's bad then it will quickly resolicit. I agree with Rich; an implementation should change the state of an NCE from REACHABLE to STALE if - we already have a REACHABLE NCE with a link-layer address, - we receive a neighbor advertisement for the neighbor but with a different address in the target link-layer address option, and - the override bit is zero. regardless of the solicited flag of the NA. I forgot the discussion and the consensus on this point when the RFC was updated, but I suspect that there is a mistake in the appendix. I'll attach a digest of the KAME's implementation for this transition, just FYI. We implemented this part according to Section 7 of the RFC, not the transition table in Appendix C. nd6_na_input() ... /* * This is VERY complex. Look at it with care. * * override solicit lladdr llchange action * (L: record lladdr) * * 0 0 n -- (2c) * 0 0 y n (2b) L * 0 0 y y (1) REACHABLE->STALE * 0 1 n -- (2c) *->REACHABLE * 0 1 y n (2b) L *->REACHABLE * 0 1 y y (1) REACHABLE->STALE * 1 0 n -- (2a) * 1 0 y n (2a) L * 1 0 y y (2a) L *->STALE * 1 1 n -- (2a) *->REACHABLE * 1 1 y n (2a) L *->REACHABLE * 1 1 y y (2a) L *->REACHABLE */ if (!is_override && (lladdr && llchange)) { /* (1) */ /* * If state is REACHABLE, make it STALE. * no other updates should be done. */ if (ln->ln_state == ND6_LLINFO_REACHABLE) ln->ln_state = ND6_LLINFO_STALE; return; } else if (is_override /* (2a) */ || (!is_override && (lladdr && !llchange)) /* (2b) */ || !lladdr) { /* (2c) */ /* * If solicited, make the state REACHABLE. * If not solicited and the link-layer address was * changed, make it STALE. */ if (is_solicited) { ln->ln_state = ND6_LLINFO_REACHABLE; } else { if (lladdr && llchange) ln->ln_state = ND6_LLINFO_STALE; } } JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 6 09:13:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB6H9qG11737 for ipng-dist; Mon, 6 Dec 1999 09:09:52 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB6H9f811730 for ; Mon, 6 Dec 1999 09:09:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA00632 for ; Mon, 6 Dec 1999 09:09:40 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06006 for ; Mon, 6 Dec 1999 10:09:38 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA00732; Tue, 7 Dec 1999 01:56:43 +0900 (JST) Date: Tue, 07 Dec 1999 02:07:42 +0900 Message-ID: <14411.60766.290811.58712V@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: In your message of "Thu, 02 Dec 1999 13:22:13 -0500" <199912021822.NAA0000016795@quarry.zk3.dec.com> References: <14406.36931.745891.37954A@condor.isl.rdc.toshiba.co.jp> <199912021822.NAA0000016795@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 02 Dec 1999 13:22:13 -0500, >>>>> Jim Bound said: > all good points and I appreciate you taking the time to write them down. > We have to figure out scope-ids and site-local addresses. and we will > enhance the api spec too working with xnet much closer this time. Thanks for reading and responding so quickly. I'm willing to join the discussion about the above issues, too. By the way, do you mind if I continue to discuss the extension of textual address representation for scoped address in this list? If so, I'll discuss it in a closer place (maybe a closed list or something which consists of interested people). Otherwise, I'd like to continue here in order to share the idea as many people as possible. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 6 10:29:35 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB6IOtG11895 for ipng-dist; Mon, 6 Dec 1999 10:24:55 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB6IOQ811888 for ; Mon, 6 Dec 1999 10:24:26 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA14620 for ipng@sunroof.eng.sun.com; Mon, 6 Dec 1999 10:23:55 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB6ILw811876 for ; Mon, 6 Dec 1999 10:22:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA05327 for ; Mon, 6 Dec 1999 10:21:57 -0800 (PST) Received: from mailhost.greene.com ([204.254.225.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02978 for ; Mon, 6 Dec 1999 10:21:56 -0800 (PST) Received: from gateway ([24.128.200.158]) by mailhost.greene.com (Post.Office MTA v3.1 release PO203a ID# 0-34903U200L100S0) with SMTP id AAA261; Mon, 6 Dec 1999 13:20:37 -0500 Message-Id: <4.1.19991206132043.00bc7d40@pop.ne.mediaone.net> X-Sender: loshin.pete@mailhost.imdgllc.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 06 Dec 1999 13:21:51 -0500 To: ipng@sunroof.eng.sun.com From: Pete Loshin Subject: A question about centers for IPv6 research Cc: 6bone@ISI.EDU Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been asked where the academic centers for IPv6 work are in the US. Which universities (if any) are considered to be "the place" to go if you're interested in studying/researching IPv6? Thanks! -pl +-------------------------------------------------------------+ | Pete Loshin http://Internet-Standard.com | | | | _IPv6 Clearly Explained_ Morgan Kaufmann January 1999 | | _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 | | | +-------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 6 10:29:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB6IHMH11871 for ipng-dist; Mon, 6 Dec 1999 10:17:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB6IHC811864 for ; Mon, 6 Dec 1999 10:17:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA21746 for ; Mon, 6 Dec 1999 10:17:11 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA06223 for ; Mon, 6 Dec 1999 11:17:10 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 06 Dec 1999 10:14:43 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Dec 1999 10:14:42 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA217C7@RED-MSG-50> From: Richard Draves To: "'JINMEI Tatuya / ????'" Cc: varadhan@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: RE: ND- processing neighbor advertisements Date: Mon, 6 Dec 1999 10:14:42 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree with Rich; an implementation should change the state of an NCE > from REACHABLE to STALE if > > - we already have a REACHABLE NCE with a link-layer address, > - we receive a neighbor advertisement for the neighbor but > with a different > address in the target link-layer address option, and > - the override bit is zero. > > regardless of the solicited flag of the NA. I think we are not in agreement. You describe above the current MSR IPv6 behavior in this case. But the examples in my previous message show (I hope) that it is desirable to do this when the solicited flag is clear, NOT regardless of the solicited flag. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 6 11:09:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB6IxCb11953 for ipng-dist; Mon, 6 Dec 1999 10:59:12 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB6Ix3811946 for ; Mon, 6 Dec 1999 10:59:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA01758 for ; Mon, 6 Dec 1999 10:59:02 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26423 for ; Mon, 6 Dec 1999 11:59:01 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id KAA28188; Mon, 6 Dec 1999 10:58:59 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA23482; Mon, 6 Dec 1999 10:58:58 -0800 X-Virus-Scanned: Mon, 6 Dec 1999 10:58:58 -0800 Nokia Silicon Valley Email Scanner Received: from (charliep.iprg.nokia.com [205.226.2.89]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma022992; Mon, 6 Dec 99 10:58:42 -0800 Message-ID: <384C0762.B4672132@iprg.nokia.com> Date: Mon, 06 Dec 1999 10:58:42 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 2.2.6-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pete Loshin CC: ipng@sunroof.eng.sun.com, 6bone@ISI.EDU Subject: Re: A question about centers for IPv6 research References: <4.1.19991206132043.00bc7d40@pop.ne.mediaone.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Pete, Are research labs considered academic centers for research? If so, the answer to this question might generate multiple advertisements for job openings :-) Regards, Charlie 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 Mon Dec 6 11:25:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB6JMRu12015 for ipng-dist; Mon, 6 Dec 1999 11:22:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB6JMI812008 for ; Mon, 6 Dec 1999 11:22:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08340 for ; Mon, 6 Dec 1999 11:22:17 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07464 for ; Mon, 6 Dec 1999 12:22:15 -0700 (MST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id D1C379A999; Mon, 6 Dec 1999 13:22:14 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext02.compaq.com (Postfix) with ESMTP id C571C90D84; Mon, 6 Dec 1999 13:22:14 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id EE1B3BC4D8; Mon, 6 Dec 1999 13:22:07 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 5ED79B2A46; Mon, 6 Dec 1999 13:22:07 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000004014; Mon, 6 Dec 1999 14:22:12 -0500 (EST) From: Jim Bound Message-Id: <199912061922.OAA0000004014@quarry.zk3.dec.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of "Tue, 07 Dec 1999 02:07:42 +0900." <14411.60766.290811.58712V@condor.isl.rdc.toshiba.co.jp> Date: Mon, 06 Dec 1999 14:22:12 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think thats what this mail thread is for..textual addresses discussion. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 6 17:47:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB71hVt12831 for ipng-dist; Mon, 6 Dec 1999 17:43:31 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB71hL812824 for ; Mon, 6 Dec 1999 17:43:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA21709 for ; Mon, 6 Dec 1999 17:43:22 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA18371 for ; Mon, 6 Dec 1999 18:43:20 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id RAA07348; Mon, 6 Dec 1999 17:43:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id RAA26290; Mon, 6 Dec 1999 17:43:19 -0800 X-Virus-Scanned: Mon, 6 Dec 1999 17:43:19 -0800 Nokia Silicon Valley Email Scanner Received: from (spruce.iprg.nokia.com [205.226.1.63]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma026208; Mon, 6 Dec 99 17:43:07 -0800 Message-Id: <4.2.2.19991206174025.03be1690@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 06 Dec 1999 17:41:17 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft IPng w.g. Minutes for November IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Corrections/changes to me. Thanks, Bob ___________________________________________________________________ IPng Working Group Meeting Minutes November 1999 IETF Meeting Washington, DC USA Bob Hinden / Nokia, Steve Deering / Cisco IPng Chairs Minutes taken by Bob Hinden and Allison Mankin. --------------------------------------------------------------- AGENDA (WEDNESDAY, November 10, 1999) Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) Document Status / R. Hinden (10 min) Summary of Tokyo Interim Meeting / S. Deering (10 min) IPv6 extensions to RPC / S. Majee (15 min) TAHI IPv6 Interoperability Test Report H. Miyata (10 min) IPv6 Socket Scrubber / C. Williams (10 min) IPng Statement on Privacy / S. Deering (5 min) Privacy Issues w/ Addrconf / Anonymous (20 min) AGENDA ( THURSDAY, November 11, 1999) Wireless Telephony / C. Perkins (30) Connection/Link Status Investigation (CSI) / H. Kitamura (10 min) Unidirectional Link Routing / H. Afifi (5 min) Source Address Selection Draft (R. Draves) / S. Deering (30 min) Text Syntax for Scoped Addresses / T. Jinmei (15 min) IPv6 Inverse Neighbor Discovery / A. Conta (10 min) Local Scope IPv6 Networking / R. Hinden (15 min) ---------------------------- Wednesday, November 10, 1999 ---------------------------- Introduction / S. Deering ------------------------- Steve Deering opened the meeting. Review Agenda / S. Deering -------------------------- Reviewed agenda. Document Status / R. Hinden --------------------------- RFC: 2675 Jumbograms, 2710 MLD, 2711 Router Alert IESG approved since last meeting - Router Alert, MLD. Format for Literals - got a good consensus after some pain Still in IESG for DS - RFC2372/2374. Remaining issues - document implementation issues of scope multicast forwarding and how do you know if you have enough experience with an architecture document to go to DS?? Will need to keep working w/IESG to "help them not worry about this too much...no new architectural concepts here..." About 18 sub-TLAs have been assigned by registries. Most have been outside US (except for about 2) - consistent with appearance that ops deployment may be not in US first. With IESG for PS - RR needs updated draft, last set of comments came after draft closing this IETF... DNS extensions - needed new draft, other related DNS docs approved by IESG - a new draft has been issued and short WG last call will start now, along with notice to some place like namedroppers. Should go back to IESG in about a week from now if all well. ACTION: Document editor to start one week w.g. last call for advancing the DNS extensions draft to Proposed Standard. With IESG for Info - GSE - IESG discussing security issues / conclusions. Authors planning new draft, slightly broadened scope, not just security. Bound asks why, if it's just a very good job of minutes, it hasn't come out. Narten : when we first did it, it was minutes of rejection of GSE proposal. Then seemed to us to talk in more detail about separating identifiers from locators, so subsequent drafts downplayed GSE points. People who are reading now don't see the basic reasons GSE shouldn't be moved forward anymore. IPng WG Last Call for Info but not sent to IESG Initial Sub-TLA assignments - action we wanted has happened. Can find the assignments on IANA page. Update draft to match binary justification text to IANA page, then send to IESG for informational, so it can be in permanent form as RFC - IANA can ref it instead of timing out... ACTION: Reissue Initial Sub-TLA Assignment draft, then submit to IESG for informational. Flexible Addr assignments - author owed comments by Hinden. Case for IPv6 - there is a new draft out. Deering is in charge of making it get published ASAP. Comments to Charlie Perkins within next week because doc has been lingering IESG will get then. Not sure if IETF Last Call will be done, maybe not as only Info. IPng WG docs ready for WG Last Call - IPv6 over Ether/FDDI/TR/ARCNET/PPP to Draft - template will come for filling out for implementation/interoperability testing. ACTION: Document editor to create template for IPv6 over Ether/FDDI/TR/ARCNET/PPP w/ input from authors. Once implementation data is collected, start w.g. last call for Draft Standard. ARCNET - Ignatius Souvatlos (?) NetBSD, internal Nokia (used inside machine, but will see if possible to do an interop with NetBSD impl) See what can go forward based on experience we can get. ICMP Name Lookups for Experimental according to plans, but Matt will speak to this. DNS A6 Record, ipng/dnsind / M. Crawford, ----------------------------------------- Recent Changes - No "A" or "AAAA" add. Section processing A6 additional info takes priority over NS - A, then A6, then AAAA - you might end up with a set of addresses but not complete set, resolver can tell, application may or may not know. Guidance for clients about configuration options/default/only if no configurability. Stuff go into transition document Crawford, Recent Changes to ICMPv6 - rev 05 - Added 5th query type for v4 CRC-32 out; MDF5 in. Names to be canonicalized as in DNSSEC before hash Names in DNS wire format, not plain strings - proofs us against future label types that may be the names Multiple names be returned Each returned address has its own TTL. Apologizes to early implementors for shuffling around the flags. Comment received - if ask node for its name, no such thing as TTL for a name, it was asked to allow non-zero TTL for name. Hinden asks why 5th query type - use in mind? Metzger: has clients who may be able to use. Does this document go on experimental or standards track? Polls for existence of strong feeling as to which. Bound feels strongly it should go to standard, but IESG might be prudent to ask for implementation before PS, as is their option. "I'm in a tough place, because I think it's a good idea, man, but I also see the ramifications." So do standards track after some quick hacks out there. Durand: did implementation, not bad match to current draft. Suggests short experimental phase maybe, but not long Metzger: it's working in several stacks, lightweight, probably useful, what downside to stds track. Nordmark: if useful, must also check for gaping holes, e.g. security. Security is IPSEC, not less secure than DNS. I don't see any formal reason not to go to PS. Bound: may be a way to fix some of the scoping issues tomorrow. Would like to defer to Bob Halley because it affects the resolver. If hacks haven't been done by Sun, Compaq, HP etc - want a vendor vetting. Nordmark: we have ways of injecting other names services, like NIS, so no-brainer to add this as another one of them. Some want to integrate in resolver, maybe, but... Durand: How we did it. Hinden: Maybe more work associated because of scope discussion tomorrow, but heard rough consensus for standards track for it. Summary of Tokyo Interim Meeting / S. Deering --------------------------------------------- Chairs summary of Tokyo Meeting. Productive. Concluded that multi-day interim meetings are usually much more productive than these because of lack of time pressure, chance to drill down in depth. Action Items/Decisions IPv6 address scope model Deering to produce a draft, hopefully by DC. Hopefully failed. Invites Brian Zill to collaborate, based on his writing on mailing list. Multihoming overview Suggestion that authors look for more descriptive terms than "multihomed", e.g. multi-addressed, multi-interfaces Had divided MH area into near-term host solutions (soon/host-based), longer-termed host-based with new concepts involved, and router-based approaches (routing system only). Main document for 1 is Rich source addr selection doc and produce new one on dest addr ordering (by DC) - he has succeeded in getting his doc out in time - merged into one Another issue - policy control over MH behavior - no specific action we can't always write ordering of addresses - because external policy may want to influence. How to provide hooks - for this. Rich has good example in doc, others need to think about. Long-term - - continue work started by MH design team on enhanced API (e.g. connect to DNS name, bury the address questions below transport level, protocol independent way. Continue this work - Peter Tattam nice proposal to use TCP to deal with multiple addresses. Simple, surprising not thought of before. During SYN exchange, tell all your addresses. If other addresses are used during connection, can cope. Doesn't deal with arrival of new addresses (as in renumbering) , but does take advantage of multiple addresses available for a machine. Will produce draft before next meeting. Contribute to transport area. - Maybe mobile IP has all mechanisms need for MH - it looks promising but it still has problems that have to be resolved. Mobile IP falls back on home address, this doesn't have that, needs an alternative robustness measure to make up for lack of HA. Ecklund: how about including several addresses in HA option, merging these? Extend to routers for help in load-balancing, in current spec (of what?) Perkins: want mobile to be considered, work out details, or not? Deering: didn't cause us to stop working on other solutions, neutral. If mobile IP people do, that's great, not asking them to especially. Router-only - - 2260/itojn versus Jessica Yu's SMPL - viewed that both could be useful, depending on ISP wishes. Asked both to flesh out and continue both. Not sure if will be stds track or BCP or what. Asked authors to use more descriptive names, e.g. "tunnels for MH site fallback", "prefix prop agreements for MH site fallback" - RR protocol alone is insufficient (using different TTLs for prefixes to give pref). Site-renumbering model was presented by Hinden - Claim is made that we made it easier, but renumbering is actually fairly large problem, e.g. outside IP stack, what is process to go thru to renumber a site. Bob showed steps, time intervals. Pragmatically what it supports, what expectations should be (not to be able to renumber every hour...) Bob is going to produce a doc (Info?) by next IETF. Plug and play architecture holes was presented by Deering - Resolved to present at zeroconf WG and he did so. IPNGWG encourages WG submissions on this topic!!!! Some uncertainty if new work should be coming into this group. Lack of having decision about that should not stop anyone submitting specs. Will work out later if new WG. IPv6 API and user interface issues - Two general areas - making sure you can provide scoping info when using less than global, that API has hooks enough for that - and at user interface level, can we allow user-friendly names for sites, advertised by multicast (e.g. router advertisements). Proposal for extending literal address syntax to afford that will be presented later today. Clarify use of scope id field in Basic API. - Generalize if ID space (numeric and character strings to include zone Ids/name strings) 3 more bullets (get presentation) IPv6 extensions to RPC / S. Majee --------------------------------- Sumandra Majee, Sun, smajee@eng.sun.com, IPv6 Extensions to RPC Extending RPC to IPv6 will help it to be deployed sooner. Design considerations - Backward compatibility for both source and binary - should work without changes over IPv6 - source more able than binary. May add new functions to enhance but no function prototype change. Not tell application it is IPv6 Two problems - ONC+RPC Two different major impls - TI (Transport Independent) and TS (socket-based), popular choice, but present Sun implements only TI. Issues with RPC - Transport selection, IPv6 or IPv4? Application smart enough to - choose, can RPC address lookup and registration service TS-RPC have - to change a lot because actually exposed to sockets. Transport Selection in TI-RPC Two new netids for UDP/IPv6(udp6) and tcp6 - don't' have to name them this - it is local to server. Order of entries in xxx.rc determines which will be picked up first. Example: - udp6 tpi_clts v inet6 udp /dev/udp6 tcp6 tpi_cots_ord v inet6 tcp - /dev/tcp6 Most of users of library used it with IPv6 with no problem at all, no work - a few complicated apps had repercussions. Transport Selection in TS_RPC Use getipnodebyname - no other way to do it. RPC Address Lookup and Registration - 'the fun part' - RPC uses rpcbind or portmapper (more popular). Client side to access gives prog_number, version, proto gets port Only udp/tcp ports are available. Cannot tell which IP, because it doesn't see tha far down. Solving Portmapper - most used - quite a few possible solutions, e.g. use different portmapper port for the IPv6 ones, but it was desirable not to for backward compatibility. So solution that has been proposed, not really implemented yet - - when IPv6 enabled client side comes up it probes remote portmapper with NULL RCP request to find out if there is even IPv6 server. Then probe remote RPC server. UDP-based requests get ICMP port unreachable (not guaranteed, though). Problems of dropped ICMP messages though port could be there. Also service needs to use same port for both 6 and 4 for this to work. Using RPCBIND - When client requests, netids guied reply. Universal address format is literal, presentation format. Only other change, which is if no 6 universal address should fall back to 4. New control options - Enhancements for IPv6 case. Traffic class. But not defined. It would be good to know what should do. Seems like a good time to add some server side control, e.g. bandwidth allocation. RPC API - Don't touch API in TI. TS-API needs to work by looking at sin_family. If ANYSOCK, give a 6. Server side API change in TS - similar Summary - if people are implementing RPC/IPv6, used RPCBIND at least, not portmapper, and best, also go with TI. Deering: in syntax, was it considered to not use address followed by colons? Ans - used a square bracket internally, and actually slide is wrong. Do a draft for this in WG? Tim: what does RPC WG want to do? Ans: draft by him and a guy from SGI. Chair wants it to be in RPC but also covered in IPNGWG. TAHI IPv6 Interoperability Test Report H. Miyata ------------------------------------------------ Hiroshi Miyata, TAHI Objectives / 1st interop event in Tokyo / Tools and scenarios are freely available and are intended to promote quality Interop event - 9/26 - 10/1 - 2.5 test days and 3 days that were overlapped by Interim meeting. 15 groups - 18 impls - France, Japan, US, Denmark, Korea, Japan Menu: conformance/interop test using scenarios/ad hoc network/interpretations. [Pictures of the event.] Ad hoc network topology was made with 14 routers and 10 hosts - BGP4+ E/I, RIPng (ATM backbone among the routers, some also using Ether backbone) Introduced conf tests last time, this time interoperability. Current: Host - 5 scenarios - focusing on basic spec (onlink, offlink...) Router - 13 - basic spec, working with hosts, and routing (BGP4+ and RIPng) Tools - packet analyzer - input tcpdump file, output original format (wire). Traffic generator - Manager/Agent style Mgr controlling scenarios Traffic generator is under test, packet analyzer was just finished this morning. Free 228/32/33 +KAME Showed web results of an output file of a flow (from PA) : stands for solicited node address, * for unspecified address. Table of what available now - will have to ask him for the slide if not clearly at www.tahi.org Future - enhance more and plan next test event. Perkins: plans for tests of mobile IP? Not at this time. Will show tools to people in terminal room. Agenda Change - move CSI and unidirectional link routing to 2nd session if no time today - go from scrubber to Privacy. IPv6 Socket Scrubber / C. Williams ---------------------------------- Carl Williams, Sun, IPv6 Socket Scrubber Comment on mystery of name even to Hinden. A couple of years ago IPv6 program manager in Sun went out to get applications ported internally. To do so, had to make porting tools. Manager/she was previously Y2K manager and based this on y2k code scrubber. Basically this searchers for IPv4 socket API code through recursive directories - uses egrep, important when users extend the set of patterns. It's not a translator. Limitations - not guaranteed to find all* lines that need porting. (For instance, old code that uses ulongs to represent addresses). Example - patterns characterized in 5 different areas - constants like AF_INET, IPv6 functions such as gethostbyname, IPv4 dat structures such as sin_family. Also macros and ioctl constants. Have also included TCP and UDP and IPv4 MIB structures. Would like feedback to add missing patterns. Output of an execution - into a primary.results and secondary.results file - the latter are problem patterns that if searched for would cause too much spurious hits, so separate them out (for less intense inspection, presumably) Show the filenames with no problems as well as those with problems. Show segment of file with problem. Net output is name, lineno. Eric ran on Solaris source base and found lots of AF_INETs not expected. Jim Bound that he had searched his source bases with similar results. Config files - 5 containing patterns. Transcribe info from slide. Has options to substitute for provided pattern files. Summary - ease porting transition. Link to Scrubber source code and man page will be at www.sun.com/solaris/ipv6 within a couple of weeks. Should work in most environments. Doesn't work, run XXX in system file and see what changes needed. Code derived from Y2K scrubber - was written in C. Carpenter: could you publish a list of things with which you found problems, not to expose proprietary. Would help others. Response: use the documentation, porting guide. Example - broken IPv4 applications where Telnet does a gethostbyname and won't go beyond first address - scrubber can't find this itself. Important for v6. Metzger: no restrictions on use? Response: not on download etc. There is a license on it. IPng Statement on Privacy / S. Deering -------------------------------------- Privacy Talks - intro by Deering - a few weeks ago, reports in press about IPv6 addresses carrying MAC addresses and concerns similar to Intel serial numbers in chips that would possibly be sent over net. Had identified issue back in Feb (Grenoble) and had a draft on a method for using random numbers instead of EUIs. Not to forget we support the stateful methods too, DHCP. Was good we had done it, but reporters weren't aware. Chairs put up statement on IPng Web Page. http://playground.sun.com/ipng Expect a lot of browsing won't carry unique serial numbers, though explain good of easy autoconf [is random much less easy] and need for persistent addresses for servers. I'm happy to have a unique phone number so people can call me, but not so happy that my number goes in all my calls for caller-id, similar. Coincidence of megaco wiretapping stuff - reporters view that IPv6 is attempt to make internet wiretappable. Opposite is true - strong e2e encryption mandatory implementation was to make wiretapping not* typical. Privacy Issues w/ Addrconf / Anonymous -------------------------------------- Note: For reasons of privacy, we werent' told in advance who would do the presentation] Privacy Exts. By 00:04:ac:25:6b:83 Narten@raleigh.ibm.com You don't know me, but I'm concerned about privacy. Brief history. Version 00 in Oslo - Simple approach: change interface identifier (and address) at reboot (only) - all addresses use same interface identifier - Draft doesn't distinguish client-initiated communication (where anon addresses make sense) from comms targeted at server (where anon addresses make no sense - Many machines will be both clients and servers: need both simultaneously. October - world takes notice Version 01 appears Current draft - Assume devices are both clients and servers - some addresses be anonymized - Generate link-local and site-local addresses as in RFC2462, only anonymize global. - Generate global server address using rfc 2462 addrconf, but deprecate immediately so it is accepted for incoming but not used for incoming! - Generate temporary, anon addresses - current recommendation is to generate a new address once a day. - Provide configuration knob to allow end user to change time between new address generations (even to once per minute, if desired...). - When you are done with an old one, deprecate it so it won't be unusable, just not used for initiating. If this was very widely deployed, it would be very difficult to do correlations at servers, even if infrequent. [Did not mention address depletion issues...] Details - Generate pseudo random seq of IF identifiers, each iteration gens next id in seq. When device boots first time out of box, gen 64 bit random number, save in stable storage as history value - Combine 2462 interface id with history value Compute MD5 hash Take leftmost 64 bits and create id Form global addr, run DAD, repeat up to 5 times if DAD reports in use Save rightmost 64 bits of md5 has in stable storage for next iteration. - Intended to make it harder to predict - table or precalculated sets might have risk. Also if nodes generating addrs at random with same algorithm and not doing this, collisions might be more likely. Open issues - - Some servers req that client be in DNS (PTR and A) - if not, no access. DNS name is identifier, so random address needs to correspond to random DNS name -n.b. if keep old DNS name, no privacy anyway...DNS server generating randoms not too far along. When should old anon addr by invalidated? - When higher layers no longer use address - not-so-hard for TCP (because can search TCBs), only apps know in UDP case Discussion: Perkins - why do you have serial reuse policy? Might want to be able to use multiple ones, application change to a new one, go back to old. Response - the more we encourage apps to do things, the more risk they don't go here as we need them too. Perkins - not encourage, just make possible. Bound - this is not networks' choice, but business choice. Narten - if we don't act/standardize, we could find no one implements Nordmark - base-level mechanism like this, provide right for application to do other things, but make this the base. Durand - what if you are home and get a delegation of /64? Narten - always-on connections the first /64 id's your house, so this foxes some privacy. Could imagine ISPs randomizing some routing bits for you, if this was viewed as sufficient problem. Bound - what status - mandatory requirement to ship in addrconf? Narten - vendors could elect as optional extension, for instance not particularly compelling to router vendors. Bound -would I be compliant if I gave choice at IPv6 setup whether you want this or not? I don't want my vendor to mandate that I have privacy. Someone - default means you are protected till you turn it off. Concerns that vendors might be worried about liability if you turned it off. Ecklund - to implement, extension to ND to say you must use it and your addresses get deprecated until you start doing it - add RA flag to enable this. Narten - it's in the ID. More about invalidation issues - Anonymous addresses complicate operations/debugging. Should site admin specify policy allowing/disallowing use of anon addresses? Someone else - as a network administrator, this is much harder for statistics, billing information. Deering - most of privacy issues arise in residential, net admins in enterprises where rights are different, control Same someone - users controlling their host os can override policy. Hinden - this falls into security policy of site. Nordmark - social problem. Not technical problem. Stop by firing if people "misuse"... Narten - take hum vote on ability for site admins to disable. Seems to pass. Zill - maybe RA not best way to do it. Awful lot of things in sites have another method, often os specific. They already have bits suitable to it, he agrees with Narten. Someone - brought up at RUN WG. Accumulation of information/caching is policy - limiting isn't something technical. Deering asks him to forward name of draft. Perkins - need for privacy in addressing is not necessarily tied to stateless, should have a way to get a randomized address from DHCP. Narten - yes but that is separate decision. Nordmark - as to where to put knobs, we have knob about whether to use DHCP, good to have knobs together. Deering - one of the press reports seemed to be saying ACLU was against IPv6 deployment. Letter had no reference to IPv6. --------------------------- Thursday, November 11, 1999 --------------------------- Wireless Telephony / C. Perkins ------------------------------- Outline of Presentation - Advantages of IPv6 for Future Telephony - Challenges of Wireless - Header Compression - UDP Lite - AAA - Using DNS for phone numbers - Feature management - Interface with IPv4 Advantages of IPv6 for Future Telephone [figure] - Number of "telephones" will exceed IPv4 address space - Mobility is nicely solved by Mobile IPv6 ... including presumably, smooth handovers - Autoconguration, leading to always on - Mandatory security for voice handsets - Presumed easier routability Challenges of Wireless - Errors leading to lost packets - Bandwidth constraints, requiring spectral efficiency - Base station selection Note that these problems do not necessarily fall within in the jurisdiction of IPv6 Important to be able to move compressing state during a handoff. Not clear how all of these are solved or how to get full spectral efficiency. Solution Components - Header compression - UDP lite - AAAv6 - Key distribution and Management - DNS - Call Control - Integration with WWW (webtone) - Transport friendly IPSEC ESP/AH o Realtime mobile optimized Header Compression - RFC 2507 - ROCCO - robhc BOF on Tuesday Report from M. Degermark on robust header compression BOF. It is likely there will be a w.g. in this area. It should be possible to compress IP,UDP,RTP to two bytes. IPv6 compression should be better than IPv4 due to it's simpler header. UDP Lite - Allows errors to get past UDP checksums, to tolerant applications - Only enable by direct action of application, not the default - Only makes sense with certain tolerant framing protocols M. Degermark added that there might be BOF on UDP lite at the next IETF. AAAv6 - Allows local connectivity to be controlled depending upon validation by trusted remote service - Lack of foreign agent removes IPv4 target for protocol design - IPv6 control must be exerted on destination cache updates at default router - Possible strategies include: o Extensions to Router Solicitation, Advertisement o Requiring DHCPv6 interactions o AAA redirect along with additional router logic - Desirable to perform authorization for network access, not radio link establishment Key Distribution and Management - Does AAA create key between home agent and mobile node? - How does local router get key with mobile node for smooth handover? - Mobility introduces need for local service fulfillment; how is authorization handled? What is Next? - Are relevant work items being worked on in other working groups? - Is there interest for a BOF in Adelaide? - Is their interest for a w.g? - Framework document? - Proposed BOF charter: http://www.iprg.nokia.com/~charliep/txt/ietf46/ip6tel.txt S. Deering wasn't sure that a w.g. need to be formed. This might be too focused on on telephony. Is an important issues. Nordmark: Thought that important to make sure IPv6 can run directly over wireless (instead of PPP over wireless). Also, not sure that new w.g. is not necessary. Perkins thinks it is important that there be a place where overall issues are discussed. Nordmark: Do need to find way to coordinate work in this areal. Comment: Thinks this is good idea and important for IPv6. This is good way to let other people how IPv6 is good way to solve this problem. Brian Z: Not sure new w.g. need to be formed, but need a steering group to help coordinate and prod other groups to do this work. Comment: Boot strap problem in IETF. Need to do system design before one can design components. IETF usually focuses on components. Comment: Thinks problem of cellular telephone are different from normal IP environment. Good to focus on this problem. Christian H: This would be a good job for the IAB. Deering reported that the IAB is planing a workshop in this area. Not sure when it will happen. Bob Hinden has volunteered to help organize IAB workshop. Narten: Thinks it is premature to have w.g. Need to work out more details of work will before we can do this. Some of the work items seem to belong in other working groups. Thinks a framework document would be very valuable. Comment: IAB workshop input would be good. Then address issues in IPng and other w.g.'s. Connection/Link Status Investigation (CSI) / H. Kitamura -------------------------------------------------------- () Generic framework to collect real time status information of nodes along both outgoing and incoming paths efficiently with minimum number of packets. What is new - Simplified header format - One new IPv6 Hop-by-Hop option o CSI option - Three new ICMPv6 messages o Status Request / Status Reply o Status Report [ example slides] What's new 1. Simplify the CSI option header format o Page and Bitmap fields are deleted. (Alignment: 4n+2) o Record format in Data Space is changed o Mandatory component of each Record is introduced 2. Introduce two types of Operation Modes o SPSR (Single-Probe/Single-Reply) for normal environment o SPMR (Single-Probe/Multiple-Reply) for problematic environment. 3. Refine the method to specify Investigation Data Types o Hierarchical method is used to specify acquired data type. o Define the "Basic Investigation Definition Set" o Ideas of "Elementary Investigation Data Components" and "Combined Components Group" are introduced. o Investigation scenarios are clarified. [header format figures] [ example slides] How to specify Investigation Data Types (or Investigation Scenarios) - Use two hierarchical fields [Invest. Class] defines the meanings of [Invest. Type] [Invest. Type] matches with Investigation scenarios - Defines only "Basic Investigation Definition Set" - New definitions of [Invest. Class] can extend the CSI mechanism easily [figures] Where is intelligence or complexity? - To intermediate nodes (routers): o No complex and intelligent operations are required o Only simple data acquisition operations are required o They are not relevant to performance issues - No high processing speed is required. - Reliability of data is not dependent on it - To a utility application on the initiator node: o Intelligent operations are required - to receive Status Reply and Report(s) - to analyze collected data - The CSI mechanism is simple enough and o easy to implement to any IPv6 nodes. - Intermediate nodes Showed results of implementation Conclusive Questions - Do you want to o investigate the "Incoming" path? o investigate by the efficient (minimum packets) method? o execute the "Record Route" operation of the path? o measure the consumed real-time bandwidth? o verify the status of the communication path? - Why not use the CSI mechanism? o Request to accept the CSI mechanism as a WG item Comments/Discussion: Christina H: This is a great denial of service attack. Once packet will generate many packets in response. This is a serious security problem. Narten: Disagrees that this is small amount of overhead in routers. Also, some of the information gathered is considered proprietary by ISP's. SNMP can be used for this. ISP's will not want to have open access for this kind of information. Brian Z: Really dislikes this proposal. Anytime you send one packet out, it is very bad to get multiple packets back. Also doesn't think router owners are going to want this kind of information to be made available. Can accomplish the same thing with a route header in a traceroute. Deering: This proposal has been presented several times before and the same comments have been made. Thinks need to listen to comments. W.G. does not seem to want to adopt this because of technical problems. Chair polled w.g. Result was that working group does not want to adopt this as a working group item. Unidirectional Link Routing / W. Dabbous ---------------------------------------- UDLR v6 - Kame code modification to support UDLR @IRS, COIAS projects - Drivers modification to recognize IPv6 code - Tested with vicv6 over INRIA LAN/satellite link. - The modifications for the receiver code are made available to Kame o URL will be announced soon on ipng and on udlr mailing lists (udlr@sophia.inria.fr) UDLR Architecture [ figure ] Tested w/ multicast. Added code to KAME stack. URL will be announced next week on IPng mailing list. If interested send mail to uldr@sophia.inria.fr Default Address Selection for IPv6 (R. Draves) / S. Deering ----------------------------------------------------------- Source Address Selection and Destination Address Ordering - Minimal requirement for all implementations - Automatically pick "reasonable" source and destination addresses - Configuration/policy is possible but not required (except for default policy) - Complement other approaches Framework getaddrinfo/getipnodebyname: IPv6 network layer: +---------------------+ +----------------------+ | Destination Addr | | Source Address | | Ordering | | Ordering | +---------------------+ +----------------------+ ^ ^ | | | +-----------------------+ | | | Policy Table | | | | | | +-----| Configurable Admin |-----+ | Preferences | +-----------------------+ The algorithms do not override application / upper-layer choices. Default Policy Table - Implementation SHOULD be configurable. If not configured, they MUST operate according the the default policy table: Prefix Precedence Label MatchSrcLabel --------- ---------- --------- ------------- fe80::/10 40 1 1 fec0::/10 30 2 2 ::/0 20 3 3 2002::/16 10 4 4 ::/96 10 5 5 - Use native source address with native destination addresses, 6to4 sources with 6to4 destinations, and v4-compatible sources with v4-compatible destinations - Prefer using native addresses to communications using either 6to4 or v4-compatible, but no preference (by default) for 6to4 addresses over v4-compatible addresses or vice versa. Discussion... Suggestion that IPv4 mapped address should have an entry in this table, but have least precedence. Destination Address Ordering - Prefer dest that have a "matching" src address - Prefer dest that are higher precedence - Prefer dst w/ longer match against src address - Otherwise leave in original (DNS) order Comment that there may be a bug here. Some confusion. Source Address Selection - Prefer sources that "match" the destination - Prefer a source that IS the destination - Avoid deprecated addresses and addresses of different (especially insufficient) scope - Prefer sources with longer match against the destination Examples Scope vs. Deprecated - Site-local destination. Source A is deprecated site-local, source B is preferred global. Choose B. - Global destination. Source A is deprecated site-local or global, source B is preferred link-local. Choose A. Examples - Transition - 6to4 and native destinations, 6to4 source. Choose 6to4 destination. - 6to4 and native destinations, 6to4 and native sources. Choose native destination and source. - 6to4 and native destinations, preferred 6to4 and deprecated native sources. Choose 6to4 destination and source. Example - ISP Preference +---------------------+ +----------------------+ | ISP 1 |-------------| ISP 2 | |2004::/16, 2006::/16 | | 2005::/16 | +---------------------+ +----------------------+ / \ / / \ / +---------------------+ +-------------------------+ | Site A | | Site B | | 2004:A::/48 | | 2005:B::/48,2006:B::/48 | +---------------------+ +-------------------------+ A wants to use IPS 1 to reach B Prefix Precedence Label MatchSrcLabel --------- ---------- --------- ------------- ::/0 25 1 1 2004::/16 25 1 1 2006::/16 20 1 1 Example - ISP Preference +---------------------+ +----------------------+ | ISP 1 |-------------| ISP 2 | |2004::/16, 2006::/16 | | 2005::/16 | +---------------------+ +----------------------+ / \ / / \ / +---------------------+ +-------------------------+ | Site A | | Site B | | 2004:A::/48 | | 2005:B::/48,2006:B::/48 | +---------------------+ +-------------------------+ B wants to use ISP 1 to reach A, but otherwise ISP 2: Prefix Precedence Label MatchSrcLabel --------- ---------- --------- ------------- 2004::/16 25 1 1 2005::/16 25 2 2 2006::/16 25 1 1 ::/0 20 2 2 C. Huitema: Suggestion to only use longest match within one preference. Not between preferences. Controversial Issues - 1 - Is this a proper subject for an IETF standard? If so, can the standard use MUST yet allow application / upper-layer override? - Proposal: Yes & Yes. Comments: Nordmark: Thinks we do need to define the default. Brian C: Thinks the text needs to allow other behavior, but make sure this is the default. Suggestion that contents of default table should be IANA parameters to make it easier to change. Comment: Concern that it might be a lot of cycles to do the address selection procedures. Won't be free. Some applications will want to do this on their own. General consensus on YES, YES, but need to be careful on wording and need implementation experience. Controversial Issues - 2 - Under what circumstances can the IPv6 network layer use a deprecated source address? - Proposal: o When application / upper-layer specifies. o When policy specifies. o When sending to that address. o To avoid insufficiently scoped source address. Comment: What is the purpose of the policy override on this slide? Discussion..... What is meant by Upper layer need to be clearer. Controversial Issues - 3 - Under what circumstances can the IPv6 network layer use a source address not assigned to the outgoing interface? - Proposal: Only in routers or when the application / upper-layer specifies. Discussion. Need complete discussion on mailing list. Not enough time. Open Issues - Interactions with mobility - When to use a home address? - Are home addresses assigned to an interface? Text Syntax for Scoped Addresses / T. Jinmei (15 min) ----------------------------------------------------- Contents - Problems - Our Proposed Solution - Implementation Examples - Related Issues Terminologies - Scope o node-local, link-local, site-local, organization-local, global... - Scope identifier o a particular instance of a scope o "link identifier" will also be used as an identifier of a link- local scope o zone ID, perimeter ID, region ID,... are not used in this presentation Problems - An IPv6 scoped address does not provide sufficient information on a scope boundary. o "ping fe80:: 1" would confuse the ping program if you have 2 links ?? ?? <--- +--------------+ ---> --------|"ping fe80::1"|------ - linkA +--------------+ linkB - an identifier of the link should be provided to the program - same kind of problems arise in site-local addresses o It's hard to reuse scoped addresses using "cut and paste". - e. g: lookup a routing table and telnet to a gateway - a link- local gateway can't be "cut and pasted" without a link ID Approaches so far - Specify a scope ID as a command line option or something o e. g. "ping -S 1 fe80::1" - need extra code for each application - does not help "cut and paste" - you can't always use the same option for this purpose - Introduce a "default" scope ID for each system o Not a complete solution o you should still specify the ID when using a scope other than the default Proposed Solution - Introduce a new format for scoped addresses: o < scope_id> o Example: fe80:: 1- 2 scoped_address = "fe80::1" delimiter = "-" scope_id = "2" o Should be applied to both unicast and multicast - Extend library functions that translate between a hostname and a numeric address o takes a literal address in the extended format o returns a numeric address structure that contains the scope ID o Note: we don't recommend you to use any particular library functions The Benefits - An application can just use the extended library functions o it is not necessary to extend present applications. - A user can easily "cut and paste" scoped addresses o the address format itself has enough information of scope Implementation( 1) Address extension - KAME's extended format for scoped addresses o (currently) for link-local addresses only o interface name as link ID - assuming 1to1 mapping between links and I/Fs o "@" as the delimiter o e.g. fe80::1@ne0=fe80::1 on the link specified by ne0 Implementation( 2) API extension - Use sin6_scope_id to specify a scope (i.e. link) ID o kernel sends a packet to the link specified by sin6_scope_id o kernel sets a link ID of a received packet to sin6_scope_id - KAME's getaddrinfo supports the extended format o takes an address as a hostname in the extended format o sets the according scope ID to the sin6_scope_id field - getnameinfo is also extended o takes sockaddr_in6{} o returns a literal address in the extended format. Implementation: How it works [example slide] Examples - ping command o needs no option to handle link- local addresses % ping6 fe80::290:27ff:fe3c:1817@ef0 PING6(56=40+8+8 bytes) fe80::2a0:24ff:fe66:1350-->fe80::290:27ff:fe3c:1817 16 bytes from fe80::290:27ff:fe3c:1817@ef0,icmp_seq=0 hlim=64 time=0.784 ms - output of netstat -rn command Internet6: Destination Gateway Flags Interface default fe80::5254:ff:fedc:5217@ef0 UG ef0 - telnet command % telnet fe80::5254:ff:fedc:5217@ef0 Trying fe80::5254:ff:fedc:5217... Connected to fe80::5254:ff:fedc:5217@ef0. Escape character is "^]". Related (Open) Issues (1) - We'd better to define specific syntax for portability. - What is the desired delimiter? o KAME's "@" seems not good o other candidates - /
(used in MSR) -
- o are alphabetical characters better? - [S|s]:< scoped_address> - is "S12A:FEC0::123:4567:89AB:CDEF" easy to read? - What is the desired order of
, , and ? o is the most significant part? o if so, should it be placed before
? Related (Open) Issues (2) - What is the desired identifier? o interface name - not so intuitive - (sometimes) even confusing; how to distinguish I/ F, link, site, ... o numerical identifiers - tend to change, not intuitive o should an identifier be unique in a scope? - e. g. a company name for a site - name distribution (or discovery) problem - how to avoid confliction - Scoped Addresses in URL's o http://[ fec0::1234-bar. com]:80/index.html would be better than o http://[ fec0::1234]:80/index.html Related (Open) Issues (3) - Many API issues o extension for getipnodebyname(), getipnodebyaddr() - need another structure? - semantics of sin6_scope_id - should be separately discussed Deering asked w.g. to see if wanted to continue this approach. Result was that group wanted to make this a w.g. item and continue developing it. Question was should these scope identifiers go to the DNS or just be kept locally. Discuss on the list. IPv6 Inverse Neighbor Discovery / A. Conta ------------------------------------------ Goal of presentation to make sure IPng is aware of this work. Would like IPng to do a w.g. last call for Proposed Standard. Inverse Neighbor Discovery - IND - Extension to Neighbor Discovery - inverse discovery o based on known link layer address - request destination IP address - correspond to IPv4 Inverse ARP (RFC 2390) o use the same type of messages as ND o add new option - list of IP addresses - Application o Frame Relay Networks (or other links) - IPv6 similar for IPv4 Inverse ARP - Status o passed ION WG Last Call o with feedback from the IESG: - published new draft (draft-ietf-ion-ipv6-ind-03.txt) o moved Frame Relay specifics info in Appendix section. o aligned the IND option (List of IP addresses) with ND options o allow list of IP option in Solicitation o remove use of O bit Messages - IND Solicitation 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address, Destination Address, Hop Limit, Priority, Authentication Header ICMP Fields: Type, Code, Checksum, Reserved, Required options: Source link-layer address, Target link-layer address Optional: Source IP Address List MTU IND Advertisement 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP Fields: Source Address, Destination Address, Hop Limit, Priority, Authentication Header ICMP Fields: Type, Code, Checksum, Reserved, Required options: Source link-layer address, Target link-layer address, Target IP Address List Optional: MTU IND options The Target Address List option is a TLV (type, length, variable size field) option, with the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - + | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // + IPv6 Address + // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // + IPv6 Address + // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+... Use in Frame Relay Networks [figure] ACTION: IPng document editor will start a two week working group last call of IPv6 Inverse Neighbor Discovery for Proposed Standard. Local Scope IPv6 Networking / R. Hinden --------------------------------------- [Talk not given, due to lack of time] -------------------- Meeting Adjourned -------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 6 18:24:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB72Ksn12895 for ipng-dist; Mon, 6 Dec 1999 18:20:54 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB72Kg812881 for ; Mon, 6 Dec 1999 18:20:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA03720 for ; Mon, 6 Dec 1999 18:20:41 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA28495 for ; Mon, 6 Dec 1999 19:20:40 -0700 (MST) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id LAA02096; Tue, 7 Dec 1999 11:07:51 +0900 (JST) Date: Tue, 07 Dec 1999 11:16:36 +0900 Message-ID: <14412.28164.503602.75679V@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@MICROSOFT.com Cc: varadhan@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: RE: ND- processing neighbor advertisements In-Reply-To: In your message of "Mon, 6 Dec 1999 10:14:42 -0800 " <4D0A23B3F74DD111ACCD00805F31D8101CA217C7@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA217C7@RED-MSG-50> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 80 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 6 Dec 1999 10:14:42 -0800 , >>>>> Richard Draves said: >> I agree with Rich; an implementation should change the state of an NCE >> from REACHABLE to STALE if >> >> - we already have a REACHABLE NCE with a link-layer address, >> - we receive a neighbor advertisement for the neighbor but >> with a different >> address in the target link-layer address option, and >> - the override bit is zero. >> >> regardless of the solicited flag of the NA. > I think we are not in agreement. You describe above the current MSR IPv6 > behavior in this case. But the examples in my previous message show (I hope) > that it is desirable to do this when the solicited flag is clear, NOT > regardless of the solicited flag. I may have jumped to a conclusion when I read your (previous) mail, but my understanding was as follows: 1. You said the appendix was wrong. The appendix specifies that we should change the state of an NCE *only* when receiving a solicited NA: REACHABLE NA, Solicited=1, - STALE Override=0 Different link-layer address than cached. but in fact the trigger by which we should change the state is reception of an *unsolicited* NA. >>>>> On Thu, 2 Dec 1999 16:44:55 -0800 , >>>>> Richard Draves said: > But I think the appendix has it backwards. In the above situation, you want > to leave the NCE in the reachable state. It's when the solicited flag is > zero that you want to change reachable -> stale. 2. (According to Rich's first mail) the current MSR implementation changes the state to STALE when receiving an unsolicited NA. (Actually it changes the state regardless of the solicited flag, but the behavior implies above.) So it is correct. 3. The only thing that you may want to change in the MSR implementation is about logging: >>>>> On Thu, 2 Dec 1999 15:53:27 -0800 , >>>>> Richard Draves said: > If the solicited flag is set in this situation, then we log a debugging > event (it shouldn't happen in normal operation) but the value of the > solicited flag doesn't change what happens to the NCE. As you said in a succeeding mail, you actually don't have to regard this as special, when you have more than one node that assigns an anycast address: >>>>> On Thu, 2 Dec 1999 16:44:55 -0800 , >>>>> Richard Draves said: > Well, I thought about this further and I think MSR IPv6 is doing the wrong > thing in this situation. I said below that the solicited flag won't normally > be set. Actually it can easily happen: when there are two instances of an > anycast address on the link, and you send a NS for the anycast address, > you'll receive two NAs. When you process the second NA, you'll be in exactly > this situation - your NCE is REACHABLE (because you just processed the first > NA), the override flag is clear, the solicited flag is set, and the target > link-layer address is different than your cached link-layer address. Or did you suggest that we *should not change* the NCE state from REACHABLE to STALE when we receive a solicited (and Override=0, different link-layer addr) NA? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 7 08:40:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB7Gb5h13228 for ipng-dist; Tue, 7 Dec 1999 08:37:05 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB7Gau813221 for ; Tue, 7 Dec 1999 08:36:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA01532 for ; Tue, 7 Dec 1999 08:36:56 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA22794 for ; Tue, 7 Dec 1999 09:36:53 -0700 (MST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 07 Dec 1999 08:26:15 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Dec 1999 08:26:15 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA217E2@RED-MSG-50> From: Richard Draves To: "'JINMEI Tatuya / ????'" Cc: varadhan@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: RE: ND- processing neighbor advertisements Date: Tue, 7 Dec 1999 08:26:14 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Or did you suggest that we *should not change* the NCE state from > REACHABLE to STALE when we receive a solicited (and Override=0, > different link-layer addr) NA? Yes, that is what I was trying to suggest. When solicited=1, override=0, and link-layer is different, then the NA is presumably a second response to an NS for an anycast address. So ignoring the NA is best, although transitioning REACHABLE -> STALE should be pretty innocuous. When solicited=0, override=0, and link-layer is different, then the NA is presumably an unsolicited attempt to inform the subnet about a new link-layer address for an anycast address, so give NUD a little nudge by transitioning REACHABLE -> STALE. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 7 08:46:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB7GjPn13253 for ipng-dist; Tue, 7 Dec 1999 08:45:25 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB7GjG813246 for ; Tue, 7 Dec 1999 08:45:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA01747 for ; Tue, 7 Dec 1999 08:45:17 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26643 for ; Tue, 7 Dec 1999 09:45:14 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA05342; Wed, 8 Dec 1999 01:32:36 +0900 (JST) Date: Wed, 08 Dec 1999 01:40:33 +0900 Message-ID: <14413.14465.160961.81364V@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-Reply-To: In your message of "Mon, 06 Dec 1999 14:22:12 -0500" <199912061922.OAA0000004014@quarry.zk3.dec.com> References: <14411.60766.290811.58712V@condor.isl.rdc.toshiba.co.jp> <199912061922.OAA0000004014@quarry.zk3.dec.com> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 12 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 06 Dec 1999 14:22:12 -0500, >>>>> Jim Bound said: > I think thats what this mail thread is for..textual addresses > discussion. Okay, thanks. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 7 09:23:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB7HKTX13332 for ipng-dist; Tue, 7 Dec 1999 09:20:29 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB7HKK813325 for ; Tue, 7 Dec 1999 09:20:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA07795 for ; Tue, 7 Dec 1999 09:20:20 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13897 for ; Tue, 7 Dec 1999 10:20:14 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id CAA05523; Wed, 8 Dec 1999 02:04:26 +0900 (JST) Date: Wed, 08 Dec 1999 02:15:21 +0900 Message-ID: <14413.16553.422461.9765Q@condor.isl.rdc.toshiba.co.jp> From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: ND- processing neighbor advertisements In-Reply-To: In your message of "Tue, 7 Dec 1999 08:26:14 -0800 " <4D0A23B3F74DD111ACCD00805F31D8101CA217E2@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA217E2@RED-MSG-50> User-Agent: Wanderlust/2.2.5 (Come Undone) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 7 Dec 1999 08:26:14 -0800 , >>>>> Richard Draves said: >> Or did you suggest that we *should not change* the NCE state from >> REACHABLE to STALE when we receive a solicited (and Override=0, >> different link-layer addr) NA? > Yes, that is what I was trying to suggest. Okay. > When solicited=1, override=0, and > link-layer is different, then the NA is presumably a second response to an > NS for an anycast address. So ignoring the NA is best, although > transitioning REACHABLE -> STALE should be pretty innocuous. I don't oppose that ignoring the NA is best in such a situation, but the second (or third, forth...) responses would normally appear only in the 1st time (i.e. during the address resolution procedure). Once we resolve a link-layer address for the anycast address, we'll just send succeeding NSes to the link-layer address directly, and thus we won't get additional NAs. So I think there is a tradeoff; - If we adopt the *best* approach, we can avoid redundant NS/NA exchanges in a (link-layer) address resolution procedure. But the code will be a bit more complicated, since we need an additional condition (i.e check if the solicited flag is on or not). - If we don't adopt the apporach, we may encounter the redundant NS/NA exchanges. But the code will remain simple. So far, I don't think that the apporach is reasonable enough to change a draft standard RFC. But I don't mind change our implementation if the ipngwg gets a consensus on this. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 7 18:28:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB82PS114285 for ipng-dist; Tue, 7 Dec 1999 18:25:28 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB82PH814278 for ; Tue, 7 Dec 1999 18:25:17 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA175712; Tue, 7 Dec 1999 18:25:07 -0800 (PST) Date: Tue, 7 Dec 1999 18:25:07 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: FWD: Comments on draft-ietf-svrloc-ipv6-06.txt (Fwd) To: Erik Guttman Cc: srvloc@srvloc.org, ipng@sunroof.eng.sun.com, nordmark@jurassic.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 > > Date: Tue, 21 Sep 1999 18:22:11 -0700 (PDT) > > Subject: Comments on draft-ietf-svrloc-ipv6-06.txt > > BTW: Please refer to draft-ietf-svrloc-ipv6-07.txt - the latest draft. My time machine was broken back in September (in the shop) when I sent these comments so I couldn't read the -07 draft which is dated in October :-) > Routable means not link local. For instance, site local scope > addresses are routable. These addresses would be perfectly > fine to put into a service URL. OK. I don't know of a term that would make sense (routable isn't it - link-local addresses can be forwarded by routers as long as they don't leave the link so they are indeed routable). Perhaps just saying "except link-local"? But this brings up a question on IPv6 in a zeroconf environment. Wouldn't there be cases when there is no router thus the only addresses in use would be link-local? I assume I should be able to use SLP in such a case. > > But the more fundamental question is the need for these > > restrictions. > > Isn't it sufficient to tie the scope of the destination address > > of the packet to the scope of the address in the service: URL? > > You mean service: URL, right? Huh? I said "service: URL" so what is the question? > > Thus the limitation would be that a server: URL can not contain > > a literal IPv6 address which has a scope which is smaller than the > > scope of the IPv6 destination address. > > That is true, but we wanted to be more conservative. It complicates > the protocol to require DAs and SAs to keep track of which interface > a request arrives on and what scope the requester's address has. The > SA or DA would have to answer differently in different situations. > It is worse for a DA, as it may be multihomed. The DA may only forward > service: URLs with link local addresses onto the link where the > advertisement was made. Same complexity applies to site-local addresses for multi-sited nodes. I assume we want to support link-local addresses with SLP so we might as well bite the bullet and figure out how to handle scope zone boundaries. I could be confused but the way the spec is currently written it seems to prohobit me from building an SA or DA that is aware of the scope zone boundaries. I think the document should instead state that if the SA or DA is not aware it needs to do X and Y to be conservative and that aware SAs and DAs need to make sure they get V and W correct. > Alain Durand advised me that this was both too complicated and would > lead to faulty implementations. Thus we decided for very conservative > language in the draft to prevent the possibility of link local addresses > in service URLs leaking beyond their scope. But this is akin to saying "we are not going to tell you what the issues are in building a correct zone aware application but instead mandate that should an implementation must never be built". Or did I get this wrong? > As Jim Kempf points out, we can't really ignore this issue even for > IPv4. If a DA or SA is multihomed it has the potential to release > inappropriate numerical addresses in URLS it sends in SLP messages. Sure. And in IPv4 there is no way for it to tell if an address has limited scope. The best you can do is if sending an SLP message on a given interface make sure you use IP addresses associated with that interface, since IP addresses from another interface might not be reachable. > I therefore agree with you that we should make the change, although > it does add complexity to the protocol. You don't have to mandate zone awareness. Just point out the issues and constraints for being zone aware and the issues/constraints for a conservative and presumably simpler non-zone aware implementation. > If we can require that DAs and SAs MUST NOT respond to a request from > address A with a service: URL which has a numerical address which is > not in the same scope as A, then I agree. That would be fine except the distinction between a scope (such as site-local) and a scope zone (a particular site). You need this check to apply to zones. > Would this imply that a SA would have to advertise multiple times in > different scopes? 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 Dec 7 21:41:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB85cTu14343 for ipng-dist; Tue, 7 Dec 1999 21:38:29 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB85cK814336 for ; Tue, 7 Dec 1999 21:38:21 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA01916 for ; Tue, 7 Dec 1999 21:38:21 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA19317 for ; Tue, 7 Dec 1999 21:38:20 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id VAA29691; Tue, 7 Dec 1999 21:38:19 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id VAA22620; Tue, 7 Dec 1999 21:38:19 -0800 X-Virus-Scanned: Tue, 7 Dec 1999 21:38:19 -0800 Nokia Silicon Valley Email Scanner Received: from (ihinden-3.iprg.nokia.com [205.226.22.76]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma022542; Tue, 7 Dec 99 21:38:12 -0800 Message-Id: <4.2.2.19991207213337.03bb2110@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 07 Dec 1999 21:36:10 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Update to IPng Web Pages Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have updated the IPng web pages at: http://playground.sun.com/ipng Changes include meeting minutes, current RFC and Internet Drafts, updates to the implementation page, and shortcuts on some of the longer pages. Please send changes and corrections to me. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 8 04:40:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB8CaV714636 for ipng-dist; Wed, 8 Dec 1999 04:36:31 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8CaM814629 for ; Wed, 8 Dec 1999 04:36:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA16400 for ; Wed, 8 Dec 1999 04:36:21 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA26217 for ; Wed, 8 Dec 1999 04:36:14 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id MA22495; Wed, 8 Dec 1999 23:34:11 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-site-prefixes In-Reply-To: Your message of "Wed, 01 Dec 1999 23:12:21 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Dec 1999 23:34:10 +1100 Message-Id: <11428.944656450@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 1 Dec 1999 23:12:21 -0800 (PST) From: Erik Nordmark Message-ID: | I'm trying to find out how this relates to draft-ietf-ipngwg-site-prefixes. | Could someone please enlighten me what is broken in that draft. The primary brokenness is the assumption that global prefixes and sites are (more or less) one to one mapping (or many to one - global to site). It is entirely reasonable to have one to many - one global prefix, many different sites for site local purposes, the algorithm in the draft then will allow nodes to use site local addresses that belong to another site (and consequently which might reach some entirely different node in the sender's site). That could be fixed by defining a site to be all that can be reached by any global prefix I guess, but that's broken too, as it is possible to have two global prefixes and three sets of nodes, one set using one prefix, another set using the other prefix, and the third set using both. When you do that, unless you define that to be three different sites, you get definition problems - if you define the whole thing to be one site, then nodes in the first and second sets would fail the definition (remember we are assuming here that a global prefix defines a site) - so they can't be in the same site. If you define it to be two sites, then nodes in the third set all belong to two sites, which is (by the definitions of site local addresses) impossible unless they have multiple interfaces, and no-one is going to require that. So, it must be three sites. Now this means that the algorithms in the draft would need (at least) to change, instead of "If there are no matches" (sect 8.1) for site locals to not be used, it will have to be "Unless every prefix matches". Of course, as soon as we do that, then lots of nodes which could have communicated using site locals fail to be able to communicate that way and have to use globals instead. This is not good. The global prefix -> site assumption simply has to go. Once that is gone, and there is no relationship at all between sites and the global prefixes that they use, then the whole basis for the draft falls apart. More than that, determining what is the prefix of some other node based upon DNS information is not possible (unless we add new information to the DNS). There's a hidden assumption in the draft (well semi-explicit, as it says that the 16 bit "subnet" field must be the same in site locals and globals) that a /64 is the net mask, always. That need not be true - /64 is only important when autoconf is being used, a site choosing to use DHCP to configure its nodes' addresses might easily be using /96 or /120 or something as its netmask for some of its nodes. Assuming that the netmask is the same at the sender and destination (in the same classful address) was a flaw in early IPv4 that took ages to erradicate, let's not start having nodes pretend to know anything at all about any other node's address, other than its 128 bit pattern. There's also the purity problem - the DNS is a global database, available to all, and should only be returning data that is useful to all. I get to pay for all the bytes I receive (someone actually counts them), I really don't want to have DNS packet sizes increased because they're carrying site local addresses that are only useful on the other side of the world. Let's keep global data in the global DNS, and do lookups of site addresses in some local directory (of course, if you have no global addresses - that is, you're not connected to the internet at all, then you can use a DNS that is jus yours and is populated with your site local addresses, that isn't an interesting case). All that is needed is to decide just what kind of local directory should be used for this, and how the lookups should be done, and by whom (ie: where in the stack this all happens). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 8 07:44:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB8FfYb14728 for ipng-dist; Wed, 8 Dec 1999 07:41:34 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8FfP814721 for ; Wed, 8 Dec 1999 07:41:25 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA02574 for ; Wed, 8 Dec 1999 07:41:24 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24031 for ; Wed, 8 Dec 1999 07:41:19 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id QAA14819; Wed, 8 Dec 1999 16:39:58 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id QAA04962; Wed, 8 Dec 1999 16:39:57 +0100 (MET) Message-Id: <199912081539.QAA04962@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: gilligan@freegate.com, set@thumper.bellcore.com, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: Re: sockaddr_storage issue In-reply-to: Your message of Wed, 01 Dec 1999 21:52:26 +0900. <23509.944052746@coconut.itojun.org> Date: Wed, 08 Dec 1999 16:39:41 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Personally, "ss_len" makes more sense for me. => I (for the "INRIA" stack) use ss_len, ss_family, and _ss_... for others (they are not supposed to be used). I am (already :-) in favor of ss_len and ss_family (ie. don't cast to sockaddr only for these two common fields). Regards Francis.Dupont@inria.fr PS: I have some #define __ss_len ss_len for KAME compatibility, I'd like to remove them if possible. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 8 09:43:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB8Hdbg14821 for ipng-dist; Wed, 8 Dec 1999 09:39:37 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8HdW814814 for ; Wed, 8 Dec 1999 09:39:32 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id JAA16523 for ipng@sunroof.eng.sun.com; Wed, 8 Dec 1999 09:39:00 -0800 (PST) Received: from efra05-home.Germany.Sun.COM (efra05-home.Germany.Sun.COM [129.157.43.5]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8AOP814469 for ; Wed, 8 Dec 1999 02:24:25 -0800 (PST) Received: from vayne (muc-isdn-4 [129.157.164.104]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.7) with SMTP id LAA06548; Wed, 8 Dec 1999 11:24:14 +0100 (MET) Date: Wed, 8 Dec 1999 11:31:39 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: FWD: Comments on draft-ietf-svrloc-ipv6-06.txt (Fwd) To: Erik Nordmark Cc: Erik Guttman , srvloc@srvloc.org, 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 > > Routable means not link local. For instance, site local scope > > addresses are routable. These addresses would be perfectly > > fine to put into a service URL. > > OK. I don't know of a term that would make sense (routable isn't it - > link-local addresses can be forwarded by routers as long as > they don't leave the link so they are indeed routable). > Perhaps just saying "except link-local"? How about 'non-link-local addresses'? > > But this brings up a question on IPv6 in a zeroconf environment. > Wouldn't there be cases when there is no router thus the only > addresses in use would be link-local? I assume I should be able to use > SLP in such a case. I believe the answer here is that SAs and DAs must always advertise on the link local scope whether or not they have non-link-local addresses assigned to their interfaces. > > > Thus the limitation would be that a server: URL can not contain > > > a literal IPv6 address which has a scope which is smaller than the > > > scope of the IPv6 destination address. > > > > That is true, but we wanted to be more conservative. It complicates > > the protocol to require DAs and SAs to keep track of which interface > > a request arrives on and what scope the requester's address has. The > > SA or DA would have to answer differently in different situations. > > It is worse for a DA, as it may be multihomed. The DA may only forward > > service: URLs with link local addresses onto the link where the > > advertisement was made. > > Same complexity applies to site-local addresses for multi-sited nodes. > I assume we want to support link-local addresses with SLP so we might as > well bite the bullet and figure out how to handle scope zone boundaries. > > I could be confused but the way the spec is currently written it seems to > prohobit me from building an SA or DA that is aware of the scope zone > boundaries. I think the document should instead state that if > the SA or DA is not aware it needs to do X and Y to be conservative and > that aware SAs and DAs need to make sure they get V and W correct. OK - let's try to do this. > > Alain Durand advised me that this was both too complicated and would > > lead to faulty implementations. Thus we decided for very conservative > > language in the draft to prevent the possibility of link local addresses > > in service URLs leaking beyond their scope. > > But this is akin to saying "we are not going to tell you what the issues > are in building a correct zone aware application but instead mandate > that should an implementation must never be built". Or did I get this > wrong? No you aren't. You've persuaded me it is worth while (as it removes restrictions, though it adds complexity and risk of propogating addresses beyond their scope). > You don't have to mandate zone awareness. Just point out the issues > and constraints for being zone aware and the issues/constraints for a > conservative and presumably simpler non-zone aware implementation. I'll give it a try. I'll count on you to help me get it right :-) 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 Dec 8 12:29:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB8KOdO14965 for ipng-dist; Wed, 8 Dec 1999 12:24:39 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8KOU814958 for ; Wed, 8 Dec 1999 12:24:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA01498; Wed, 8 Dec 1999 12:24:28 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25972; Wed, 8 Dec 1999 13:24:22 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA00556; Wed, 8 Dec 1999 21:24:21 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA11865; Wed, 8 Dec 1999 21:24:19 +0100 (MET) Message-Id: <199912082024.VAA11865@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: Erik Nordmark , Robert Elz , itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Thu, 02 Dec 1999 10:06:59 EST. <199912021507.KAA0000003269@quarry.zk3.dec.com> Date: Wed, 08 Dec 1999 21:24:17 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: In your draft you put or assume site-locals are in the DNS. => I believe Erik's idea is to put only globals in the DNS and to use the knowledge of local site prefixes (given by prefix info extensions in router advertisements) in order to replace globals by site-locals in name to address translations when possible. This should work but if Erik promotes site-locals as a way to keep local (ie. inside the site) connectivity during renumbering personally I don't like site-locals for other purposes than net 10 (ie. never get both site-locals and globals) and I think a multi-sited node will be a terrible monster... Regards Francis.Dupont@inria.fr PS: two precisions: - I believe we can restrict the scope of this thread to textual addresses (ie. no DNS or other name to address translation) - even if we nuke site-locals we have still a problem with other scoped addresses like link-local and multicasts (but in these cases scope IDs can be interface indexes which are defined beasts :-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 8 12:50:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB8KilI15006 for ipng-dist; Wed, 8 Dec 1999 12:44:47 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8KiQ814995 for ; Wed, 8 Dec 1999 12:44:26 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA02205 for ; Wed, 8 Dec 1999 12:44:25 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25959 for ; Wed, 8 Dec 1999 12:44:23 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id VAA00767; Wed, 8 Dec 1999 21:44:22 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id VAA14768; Wed, 8 Dec 1999 21:44:20 +0100 (MET) Message-Id: <199912082044.VAA14768@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: Textual Address Change for Scope-IDs In-reply-to: Your message of Mon, 29 Nov 1999 23:42:26 EST. <199911300442.XAA0000024545@quarry.zk3.dec.com> Date: Wed, 08 Dec 1999 21:43:56 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > - when user specifies numeric IPv6 address, (1) user must specify > scope id explicitly, or (2) system default setting (like routing > table) must pick single scope id. Agree with you. => the problem is getipnodebyname() (my favorite API) cannot cope with (1) then we can shoot it down or fix it. > - sending NDs to multiple interfaces is a bad idea. => It is. I tried it and it was exactly the perfect example of a bad idea: it seemed to work but it didn't work in every cases and of course when it didn't work you couldn't understand why... The introduction of scope ID and discussions about weak/strong models have given the way to correctly deal with scopes, the only remaining problem is with textual addresses. > There are specs that use site-locals. To name a few: > - router renumbering > - DHCPv6 => if DHCPv6 is done per interface and if a site-boundary must be at the right place (as in last proposals) then DHCPv6 site-local multicasts will be like link-local (ie. there is no new problem). Regards Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 8 13:46:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB8Lgti15059 for ipng-dist; Wed, 8 Dec 1999 13:42:55 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8Lgk815052 for ; Wed, 8 Dec 1999 13:42:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA14219 for ; Wed, 8 Dec 1999 13:42:45 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA28263 for ; Wed, 8 Dec 1999 14:42:44 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA01591; Wed, 8 Dec 1999 22:42:40 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA02255; Wed, 8 Dec 1999 22:42:38 +0100 (MET) Message-Id: <199912082142.WAA02255@givry.inria.fr> From: Francis Dupont To: Brian Zill cc: "'Jim Bound'" , Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of Mon, 29 Nov 1999 13:46:26 PST. <3D2036E25376D31197A100805FEAD892712F37@RED-MSG-02> Date: Wed, 08 Dec 1999 22:42:33 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I changed the subject line to better reflect the issue. => thanks I think site-local addresses, or something very much like them, is useful and will work fine. => I believe they are useful (ie. there are some needs for them) but I have a concern about multi-sited nodes because sites and site-IDs are not fully defined (but this was worse in the past) and because of the current intrinsic ambiguity of a site-local address in a multi-sited context. In most cases there is no multi-sited monster then I vote yes for site-locals. I believe that if we do not specify site-local addresses specifically, we will end up with the equivalent of IPv4's net 10 anyway, due to marketplace pressures. => we need net 10 because it is too long, too expensive, ... to get a global prefix in every cases and net 10/site-locals have the good property they will *not* be routed across the site boundary. (again the same argument I'm afraid :-) No, a single-sited end node doesn't need to know anything about site identifiers. => it is a reason to avoid multi-sited nodes until we fully understand them. No, a site-specific directory can hold site-local addresses. => I'll answer to Steve about this because I disagree. > >3) It should not be routed, but then it has > > to be propagated for the needs of mobile nodes, > > Exactly. I don't claim to be a mobile-IP expert, but I thought this was a solved problem in the mobile-IP draft. => I am afraid this is today the main problem with site-locals because a mobile node will become a multi-sited node in the worst conditions you can imagine... There are some parts of a solution (without running code?) and it is not a surprise than mobility and scope/zone idea don't fit well together. > >4) It is very hard to handle in multisited nodes. > > Exactly. => I agree. I don't see this either, but I guess it depends upon your definition of "very hard". => "very hard": there is no consensus about how to do it nor running codes which can show what are good solutions. Tagging every interface in a routing node with a node-specific site-id and then only forwarding between like site-ids seems pretty straight-forward. => this seems reasonable but restricts possible topologies: I am trying to show that there still are some problems. So does only allowing end node originated packets to go out via interfaces with a site-id that matches the one in the sin6_scope_id field. Our implementation does both of these today. => this is a working solution of a host (ie. end node) but in fact this is exactly the strong model which is not very user friendly (ie. without a scope ID you'll reject packets). Everything else is UI/API. => the whole problem is UI/API... Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 8 14:03:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB8Lxjg15097 for ipng-dist; Wed, 8 Dec 1999 13:59:45 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8Lxa815090 for ; Wed, 8 Dec 1999 13:59:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA29264 for ; Wed, 8 Dec 1999 13:59:35 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05198 for ; Wed, 8 Dec 1999 14:59:34 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id WAA01911; Wed, 8 Dec 1999 22:59:33 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id WAA30140; Wed, 8 Dec 1999 22:59:31 +0100 (MET) Message-Id: <199912082159.WAA30140@givry.inria.fr> From: Francis Dupont To: Steve Deering cc: ipng@sunroof.eng.sun.com Subject: Re: Regarding site-local addresses In-reply-to: Your message of Tue, 30 Nov 1999 09:02:28 PST. Date: Wed, 08 Dec 1999 22:59:30 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The same is true for the notion of embedding a site ID inside a site- local address. => I don't know if Christian's idea is good or bad. Current specs give something like the net 10 in space (same number of subnet than the 10 class A split into class C chuncks) but there are these *unused* bits which can reduce collisions (I believe some users won't resist temptation, perhaps we should give them? :-) if I had delivered on my frequent promises to write up what I understood about scoped addresses (something I *still* intend to do). => still a good idea to do it (mieux vaut tard que jamais :-) I must disagree with Jim that there is WG consensus that site-local addresses must never appear in (any part of) the DNS. Too few people have commented on that, and there is insufficient agreement among those who have commented, to conclude that there is any such consensus. => I agree there is no consensus today for a "must not" but I don't know if we can get one soon for a "should not". I can well imagine that name resolution for site-locals would best be handled by DNS servers within each site, and I think it is far too premature to rule that out. => I am for a "should not" because: - it is simpler to have only globals in DNS and there is no real needs for site-locals in DNS (ie. this part of Erik's proposal seems to work without major issue). - DNS is always the wrong tool when location (here be in/outside a site) is involved. I strongly dislike two headed animals! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 8 14:22:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB8MG2B15159 for ipng-dist; Wed, 8 Dec 1999 14:16:02 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB8MFr815152 for ; Wed, 8 Dec 1999 14:15:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA22172; Wed, 8 Dec 1999 14:15:53 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA12718; Wed, 8 Dec 1999 15:15:52 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id XAA02278; Wed, 8 Dec 1999 23:15:51 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id XAA03945; Wed, 8 Dec 1999 23:15:49 +0100 (MET) Message-Id: <199912082215.XAA03945@givry.inria.fr> From: Francis Dupont To: Carl Williams cc: ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-reply-to: Your message of Tue, 30 Nov 1999 00:06:43 PST. <199911300806.AAA12803@antley.eng.sun.com> Date: Wed, 08 Dec 1999 23:15:48 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: APIs that are effected by the scope id issue -------------------------------------------- o getipnodebyname(), getipnodebyaddr() o inet_ntop(), inet_pton() o INET6_ADDRSTRLEN o ifindex APIs => in fact only getipnodebyname() has a real problem. inet_ntop() and inet_pton() can be (ie. should be!) replaced by higher level/more powerful functions (as in your recommendations), INET6_ADDRSTRLEN is bound to inet_ntop() (ie. same point applies). An ifindex() clone for sites will be useful (ie. I'd like to get this ASAP). The group identified possible options to dealing with scope addresses and the getipnodebyname()/getipnodebyaddr() APIs: (a) Extend the getipnodebyname() interface to work with scoped addresses. (b) Standard compile flag fix (c) Deprecate getipnodebyname()/getipnodebyaddr() (d) Define function to cut out scope id and pass it into a yet to be defined function. The other address portion would be passed into getipnodebyaddress() (e) Simply use getaddrinfo()/getnameinfo() as scopes are transparent to these interfaces. => I think (e) and (c) are in fact the same thing... The only exception I can see is the URL stuff where it was so hard to get a syntax for textual addresses than we wouldn't like to extend it for scopes (:-)! NI_NUMREICHOST host is numeric (46 digits maximum) NI_NUMREICSCOPE scope is numeric (2^32 => 10 max digits) NI_NUMREICPORT port is numeric (2^16 => 5 digits) => NI_NUMERICxxx, isn't it? Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 8 16:56:00 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB90mWN15399 for ipng-dist; Wed, 8 Dec 1999 16:48:32 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB90mM815392 for ; Wed, 8 Dec 1999 16:48:22 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA340792; Wed, 8 Dec 1999 16:48:07 -0800 (PST) Date: Wed, 8 Dec 1999 16:47:52 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-site-prefixes To: Robert Elz Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <11428.944656450@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The primary brokenness is the assumption that global prefixes and > sites are (more or less) one to one mapping (or many to one - global to > site). Perhaps the draft is unclear but there aren't any frivolous assumptions as far as I know. Maybe it is just the examples that are too simplistic assuming that there are some number of /48 global prefixes assigned to the site? A site must have some finite (and presumably small) number of global prefixes. Is this number is too large there will be routing scaling issues. Thus if an entity (e.g. a company) has been assigned A/48 prefix they might want to split that across different sites. If all those sites are connected to the same ISP that might get away with that - the ISP will need to carry longer than /48 prefixes for A. But I don't think it is realistic that these longer prefixes visible outside their ISP. But even with their ISP the number will be small. I expect the ISP to be unhappy (i.e. wanting more money) if they have to carry all the 65536 /64 prefixes for A (i.e. all the subnet routes). Thus there has to be some hirarchy so that the prefixes are shorter than /64's. In such a scenario all it takes it additional longer site-prefixes being advertised in the router advertisement. Of course, if you need to advertise lots of /64 prefixes as site-prefixes we will have both a traffic problem due to the size of the logically fragmented Router Advertisements, and also a storage problem on the hosts. > It is entirely reasonable to have one to many - one global prefix, > many different sites for site local purposes, the algorithm in the > draft then will allow nodes to use site local addresses that belong > to another site (and consequently which might reach some entirely > different node in the sender's site). No, you just need to correctly configure things. If a site border router is injecting routes for A::1/56 and A::17/51 it can use router renumbering (once that protocol passes the site prefixes) to configure A::1/56 and A::17/51 as site-prefixes in the router advertisements. Thus this can be automated. What am I missing? > More than that, determining what is the prefix of some other node based > upon DNS information is not possible (unless we add new information to > the DNS). There's a hidden assumption in the draft (well semi-explicit, > as it says that the 16 bit "subnet" field must be the same in site locals > and globals) that a /64 is the net mask, always. Where do you see the /64 assumption? The only assumption is The protocol assumes that the site uses a consistent subnet numbering scheme across all its global addresses and its site-local addresses. This means that if a subnet uses e.g. a /120 (with the part between /97 and /120 being the 23 bit subnet number) that the site-local and global addresses for that subnet must both have a /120 with a 23 bit subnet number that is the same in the two spaces. > There's also the purity problem - the DNS is a global database, available > to all, and should only be returning data that is useful to all. We have a few choices: 1. Don't do site-local addresses (or only have them apply to unconnected sites). 2. Make sure they don't appear in the global DNS. As far as I can tell this means they'll be in a local DNS i.e. we will need two-faced DNS in places where it isn't used today. 3. Put them in the global DNS but make sure that they are never used outside of their intended scope. > Let's keep global data in the global DNS, and do lookups of site addresses > in some local directory (of course, if you have no global addresses - that > is, you're not connected to the internet at all, then you can use a DNS > that is jus yours and is populated with your site local addresses, that isn't > an interesting case). Won't this effectively mandate the use of two-faced DNS. I thought we wanted to try to keep (or at least not move further away) from a global DNS name space. Saying that the architecture mandates a two-faced DNS seems impure as well. Thus we can argue about which is more impure - shades of grey. And it is my impression that a two-faced DNS is non-trivial to setup and operate. As an aside, we seem to have enough extensibility in the DNS to put information in there that is not globally significant. How about SIG records with algorithm = 254 that some random site is allowed to use. When you ask for the SIG RRset you'll have to pay for receiving those (presumably useless to you) SIG records. But as with site-local addresses in this draft, you can tell what they are and not get confused by them. > All that is needed is to decide just what kind of local directory should > be used for this, and how the lookups should be done, and by whom (ie: > where in the stack this all happens). If we go that path, do you seriously think that the local directory will be anything other than DNS? I'm having a hard time understanding why anybody would build a completely new local directory just for this. And it would be slower since applications/OSs would need to look in both the local directory and the DNS since they can't know where the addresses will be stored. 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 Dec 8 17:53:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) id dB91mEC15436 for ipng-dist; Wed, 8 Dec 1999 17:48:14 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta8+Sun/8.10.0.Beta8) with ESMTP id dB91m3815429 for ; Wed, 8 Dec 1999 17:48:03 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA350549; Wed, 8 Dec 1999 17:47:47 -0800 (PST) Date: Wed, 8 Dec 1999 17:47:32 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Textual Address Change for Scope-IDs To: Francis Dupont Cc: Jim Bound , Erik Nordmark , Robert Elz , itojun@iijlab.net, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199912082024.VAA11865@givry.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => I believe Erik's idea is to put only globals in the DNS and to > use the knowledge of local site prefixes (given by prefix info > extensions in router advertisements) in order to replace globals > by site-locals in name to address translations when possible. Sounds like you should read the draft. -00 of the draft did the above. What that has the downside that every node in your site-prefix(es) need to be configured with site-local addresses. The new (well, about 2 years old?) scheme provides flexibility by controlling what goes in the DNS. For instance, a node that is likely to be mobile might choose not to have site-local addresses in the DNS. 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 Dec 8 23:08:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dB9731Q15615 for ipng-dist; Wed, 8 Dec 1999 23:03:01 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dB972q815608 for ; Wed, 8 Dec 1999 23:02:53 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA05077 for ; Wed, 8 Dec 1999 23:02:52 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA09868 for ; Wed, 8 Dec 1999 23:02:51 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Dec 1999 23:00:06 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Dec 1999 23:00:06 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21819@RED-MSG-50> From: Richard Draves To: "'Robert Elz'" , Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-site-prefixes Date: Wed, 8 Dec 1999 23:00:04 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There's also the purity problem - the DNS is a global > database, available > to all, and should only be returning data that is useful to > all. I get > to pay for all the bytes I receive (someone actually counts > them), I really > don't want to have DNS packet sizes increased because they're carrying > site local addresses that are only useful on the other side > of the world. > Let's keep global data in the global DNS, and do lookups of > site addresses > in some local directory (of course, if you have no global > addresses - that > is, you're not connected to the internet at all, then you can > use a DNS > that is jus yours and is populated with your site local > addresses, that isn't > an interesting case). Besides Erik's answer (what else would you use besides DNS, and requiring two-faced DNS is not good), here's another thought: Consider the interaction of site-local addressing with mobility. The way we'll probably implement it, the home addresses will be assigned to a pseudo-interface that logically is part of the home site. It will be possible to use site-local addresses for communication with nodes back in the home site. So it actually will be useful to have site-local addresses returned by DNS, when the lookup is done by this mobile node that is ostensibly outside the site. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 07:10:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dB9F2QX15796 for ipng-dist; Thu, 9 Dec 1999 07:02:26 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dB9F2E815789 for ; Thu, 9 Dec 1999 07:02:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA22904 for ; Thu, 9 Dec 1999 07:02:15 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03651 for ; Thu, 9 Dec 1999 07:02:13 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA04109 for ; Thu, 9 Dec 1999 09:02:12 -0600 (CST) Message-Id: <199912091502.JAA04109@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-site-prefixes In-reply-to: Your message of Wed, 08 Dec 1999 16:47:52 PST. Date: Thu, 09 Dec 1999 09:02:12 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A site must have some finite (and presumably small) number of global > prefixes. Is this number is too large there will be routing scaling issues. No, I don't think so, as long as the global prefixes correspond to the topology of their global connections. If topological aggregation is respected but the number of prefixes is truly pathological (order of 100) I think the site is more likely to run into limits in the DNS lookups for its own nodes. A6 helps there, but only by a factor ~ 2. > Thus if an entity (e.g. a company) has been assigned A/48 prefix > they might want to split that across different sites. If all those > sites are connected to the same ISP that might get away with that - > the ISP will need to carry longer than /48 prefixes for A. Or they could hide the structure even from the ISP by tunneling between the different locations. This is one of the cool things about the elevated status of tunnels in v6 that is going to take a while for the customer-at-large to grasp the possibilities of. 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 Dec 9 17:09:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA147h16437 for ipng-dist; Thu, 9 Dec 1999 17:04:07 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA13u816430 for ; Thu, 9 Dec 1999 17:03:56 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA514505; Thu, 9 Dec 1999 17:03:17 -0800 (PST) Date: Thu, 9 Dec 1999 17:03:03 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Scope ID secret Cabal (minutes) To: Francis Dupont Cc: Carl Williams , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199912082215.XAA03945@givry.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > An ifindex() clone for sites will be useful (ie. I'd like to get this ASAP). I agree. One question is whether we need a clone for link ids as well. (It is becoming more and more common to have multiple NICs connected to a subnet for high availability and load balancing.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 17:14:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA1DEN16484 for ipng-dist; Thu, 9 Dec 1999 17:13:14 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA1D2816475 for ; Thu, 9 Dec 1999 17:13:03 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA515869; Thu, 9 Dec 1999 17:12:24 -0800 (PST) Date: Thu, 9 Dec 1999 17:12:10 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-site-prefixes To: Matt Crawford Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199912091502.JAA04109@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > A site must have some finite (and presumably small) number of global > > prefixes. Is this number is too large there will be routing scaling issues. > > No, I don't think so, as long as the global prefixes correspond to > the topology of their global connections. If topological aggregation > is respected but the number of prefixes is truly pathological (order > of 100) I think the site is more likely to run into limits in the DNS > lookups for its own nodes. A6 helps there, but only by a factor ~ 2. I assume your are arguing about the (undefined) "small" above. I can see there being on the order of 10 global prefixes for a site. That means 10*24=240 bytes worth of prefix options in router advertisements to carry the site-prefixes to the hosts. I agree that 100 global prefixes would make life difficult but that difficulty appears not only in the site-prefixes mechanism. BTW: If a site has 100 global prefixes I don't think each host will have 100 addresses. A possible way such a thing could happen is that a site starts of with a single Internet connection and a /48. They assign /64 subnet prefixes out of this space. Later they decide to outsource the connectivity between their buildings to their ISP. In some weird case they might actually want their ISP to carry the /64 routes, which are randomly spread between the buildings. Thus each building could now be viewed as a site with a set of /64 site prefixes. But for various reasons (firewalls being one of them) I find such a scenario unlikely. > Or they could hide the structure even from the ISP by tunneling > between the different locations. This is one of the cool things > about the elevated status of tunnels in v6 that is going to take a > while for the customer-at-large to grasp the possibilities of. Sure. I can't see a case where a site would have more than one prefix (or a few once they consume a full /48) per ISP they connect to. Does anybody else have a case where this would make sense? I'd like to understand if requiring scalability to 100's of prefixes per site is reasonable. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 17:42:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA1aex16524 for ipng-dist; Thu, 9 Dec 1999 17:36:40 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA1aS816517 for ; Thu, 9 Dec 1999 17:36:29 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA00970 for ; Thu, 9 Dec 1999 17:36:28 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA26479 for ; Thu, 9 Dec 1999 17:36:28 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Dec 1999 17:33:04 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Dec 1999 17:33:04 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21836@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" , Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-site-prefixes Date: Thu, 9 Dec 1999 17:33:00 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I can't see a case where a site would have more than one > prefix (or a few once > they consume a full /48) per ISP they connect to. > Does anybody else have a case where this would make sense? > I'd like to understand if requiring scalability to 100's of > prefixes per > site is reasonable. What if the ISP has more than one prefix because the ISP in turn is multi-homed to multiple bigger ISPs? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 17:58:35 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA1rCB16563 for ipng-dist; Thu, 9 Dec 1999 17:53:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA1r4816556 for ; Thu, 9 Dec 1999 17:53:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA13057 for ; Thu, 9 Dec 1999 17:53:04 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA01962 for ; Thu, 9 Dec 1999 17:53:03 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Dec 1999 17:52:51 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Dec 1999 17:50:29 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21837@RED-MSG-50> From: Richard Draves To: ipng@sunroof.eng.sun.com Subject: RE: Scope ID secret Cabal (minutes) Date: Thu, 9 Dec 1999 17:50:24 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One question is whether we need a clone for link ids as well. > (It is becoming more and more common to have multiple NICs connected > to a subnet for high availability and load balancing.) A related thought... Whenever Steve would point out that interface ids and link ids are different things, I would think - absolutely correct in principle but a moot distinction for our implementation. But recently we thought of something that might make the distinction more interesting. If you implement home addresses for mobility by assigning the home address to a pseudo-interface, you want the pseudo-interface to belong to the original home subnet link. For example suppose you have ethernet interface id#1 attached to a home link id#2. Then unplug the ethernet and plug it in somewhere else. Now ethernet interface id#1 is connected to link id#3 and there is a pseudo-interface id#4 attached to the home link id#2. Then if a someone is using the address 2/fe80::1 (fe80::1 with link id#2), the right thing can happen whether the node is at home or moves away. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 17:58:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA1uM716579 for ipng-dist; Thu, 9 Dec 1999 17:56:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA1uD816572 for ; Thu, 9 Dec 1999 17:56:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA03529 for ; Thu, 9 Dec 1999 17:56:13 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA13240 for ; Thu, 9 Dec 1999 18:56:09 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id BA00872; Fri, 10 Dec 1999 12:55:59 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-site-prefixes In-Reply-To: Your message of "Wed, 08 Dec 1999 16:47:52 -0800." Date: Fri, 10 Dec 1999 12:55:58 +1100 Message-Id: <15091.944790958@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 8 Dec 1999 16:47:52 -0800 (PST) From: Erik Nordmark Message-ID: | > The primary brokenness is the assumption that global prefixes and | > sites are (more or less) one to one mapping (or many to one - global to | > site). | | Perhaps the draft is unclear but there aren't any frivolous assumptions | as far as I know. I don't think I said "frivolous". As I understand the draft, you use equivalence of global prefix (I have this one, you have the same one) to mean "we are in the same site". That's the assumption that I don't think can be maintained. | A site must have some finite (and presumably small) number of global | prefixes. Why? If you replace "site" there with "node" (and for now ignoring "small" and nodes that actually get no global prefixes for one reason or other) then yes, but for "site", why? I have always considered a site to be an administrative object, not necessarily related to external topology any way at all (though "internally connected" is reasonable). On the other hand, global prefixes relate to connectivity and routing (the way they are intended to be used in IPv6, as distinct from the original IPv4 model). I don't see any specific relationship between the two at all. All the rest of the stuff in your message about advertising of prefixes, etc, is not immediately relevant. | > It is entirely reasonable to have one to many - one global prefix, | > many different sites for site local purposes, the algorithm in the | > draft then will allow nodes to use site local addresses that belong | > to another site (and consequently which might reach some entirely | > different node in the sender's site). | | No, you just need to correctly configure things. If a site | border router is injecting routes for A::1/56 and A::17/51 it can | use router renumbering (once that protocol passes the site prefixes) | to configure A::1/56 and A::17/51 as site-prefixes in the router | advertisements. Thus this can be automated. | | What am I missing? You're assuming that "correctly configure" means "configure so that site locals will work the way that the draft assume". That isn't my definition of correctly configuring global addresses. My definition of a correctly configyured global address is one that makes the routing work the way I expect it to work, and has no relationship at all with what I choose to define as my site for site local addressing purposes. That is, I see no relationship at all between what global prefixes might exist, and how they are advertised on the various links, and what is a "site". My definition of a site is more along the lines of "all those nodes and links configured to route packets for using site local addresses" - where there's a block, site locals don't pass from this link to that one, then there is a site boundary, where there is no block, then the same site continues. No more, and no less, restrictions than that. As I said in an earlier message on another topic (which sort of led to this one) I don't think we yet really know enough about how we want to make use of sites, and site local addresses, to start laying down the rules for how they have to be used. | Where do you see the /64 assumption? Not the precise number, but that there is a number. | The only assumption is | The protocol assumes that the site uses a consistent subnet numbering | scheme across all its global addresses and its site-local addresses. No, more than that. | This means that if a subnet uses e.g. a /120 (with the part between /97 and | /120 being the 23 bit subnet number) that the site-local and global addresses | for that subnet must both have a /120 with a 23 bit subnet number that is | the same in the two spaces. Yes. It also means, I believe, for the draft to work, that all the nodes have to understand at least the /120 number. If that node over there is /64 and I am /120 am I going to recignise it as being in the same site as I am? | We have a few choices: | 1. Don't do site-local addresses (or only have them apply to unconnected | sites). | 2. Make sure they don't appear in the global DNS. As far as I can tell | this | means they'll be in a local DNS i.e. we will need two-faced DNS in | places where it isn't used today. | 3. Put them in the global DNS but make sure that they are never used outside | of their intended scope. Those are options, I don't see them as the only options. In my previous message I deliberately didn't attempt to suggest a solution, as no solution is likely to be perfect - they all have some drawback or other. Suggesting a solution now would focus discussion on pulling apart that suggestion, rather than on whether or not the current one will work. | Won't this effectively mandate the use of two-faced DNS. No. | I thought we wanted to try to keep (or at least not move further away) | from a global DNS name space. Saying that the architecture mandates | a two-faced DNS seems impure as well. Yes, That is not at all what I would like to see. | And it is my impression that a two-faced DNS is non-trivial to setup and | operate. Yes, horrible. But irrelevant, as that is not what we want (not what I want anyway). | As an aside, we seem to have enough extensibility in the DNS to put | information in there that is not globally significant. | How about SIG records with algorithm = 254 that some random site | is allowed to use. That is global information - available equally to everyone, and entirely possibly meaningful to everyone. The only issue there is whether the node that receives the information just happens to know how to interpret it - the DNS isn't deliberatey returning information that cannot possibly be of any use to you. Further, note that I am not saying that the DNS is unable to carry the information that you are considering putting there - aside from the extra data volume to lug around, of course it can. The DNS can hold almost anything. That doesn't mean that it should. | If we go that path, do you seriously think that the local directory will | be anything other than DNS? Yes. | I'm having a hard time understanding why | anybody would build a completely new local directory just for this. Perhaps because nothing else will work sensibly, and flexibly, enough. | And it would be slower since applications/OSs would need to look | in both the local directory and the DNS since they can't know where | the addresses will be stored. Even leaving aside the assumption that exists there about the nature of this new directory (I didn't suggest that it would be anything like the DNS at all = "directory" just means a place from which information is obtained) "slower" would not be correct. More overhead yes, but it is hard to imagine a site local directory that would actually be slower than the global DNS, and nothing at all would suggest that the two lookups (again, assuming that there are two lookups this way) need to be serialised. But, for now, let's not just say "we must do this because we cannot think of anything else right now that will work", and instead analyse the proposal on its own merits. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 18:13:47 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA28Rw16639 for ipng-dist; Thu, 9 Dec 1999 18:08:27 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA28G816632 for ; Thu, 9 Dec 1999 18:08:16 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA524916; Thu, 9 Dec 1999 18:07:22 -0800 (PST) Date: Thu, 9 Dec 1999 18:07:08 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-ietf-ipngwg-site-prefixes To: Richard Draves Cc: "'Erik Nordmark'" , Matt Crawford , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8101CA21836@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I can't see a case where a site would have more than one > > prefix (or a few once > > they consume a full /48) per ISP they connect to. > > Does anybody else have a case where this would make sense? > > I'd like to understand if requiring scalability to 100's of > > prefixes per > > site is reasonable. > > What if the ISP has more than one prefix because the ISP in turn is > multi-homed to multiple bigger ISPs? I guess my question was inexact. If the ISPs (one or more) hand a site multiple prefixes (because there are multiple ISPs or the ISP(s) are multihomed themselves) this is likely to result in each subnet having N subnet prefixes when the site has N site prefixes. (At least that is the assumption we've made for the ipv6 multihoming work - every node gets an address from every prefix.) Such a scenario doesn't put any additional "strain" on the site-prefixes mechanism of advertising prefixes in the Router Advertisements, since the site-prefix info will be included in the subnet-prefix info i.e. the packets do not get any larger. What I'm explicitly looking for is the case when we can't do this piggyback. This happens when the site has N prefixes (of some length - could be longer than /48) but many subnets have less than N subnet prefixes. In this case, in the site-prefixes draft mechanism, there will be N prefix options needed to carry the site information to every host. If N = 100 or so this will consume some bandwith since the router advertisement size is about 48 bytes per prefix. Is there a case where the site has e.g. 100 prefixes but the subnets only have say 3 prefixes? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 18:25:26 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA2Hcq16682 for ipng-dist; Thu, 9 Dec 1999 18:17:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA2HU816675 for ; Thu, 9 Dec 1999 18:17:30 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA06489 for ; Thu, 9 Dec 1999 18:17:30 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id SAA09593 for ; Thu, 9 Dec 1999 18:17:30 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Dec 1999 18:16:00 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Dec 1999 18:16:00 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21838@RED-MSG-50> From: Richard Draves To: "'Robert Elz'" , Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-site-prefixes Date: Thu, 9 Dec 1999 18:15:51 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That is, I see no relationship at all between what global prefixes > might exist, and how they are advertised on the various links, and > what is a "site". My definition of a site is more along the lines of > "all those nodes and links configured to route packets for using > site local addresses" - where there's a block, site locals don't pass > from this link to that one, then there is a site boundary, where there > is no block, then the same site continues. No more, and no less, > restrictions than that. > > As I said in an earlier message on another topic (which sort of led to > this one) I don't think we yet really know enough about how we want to > make use of sites, and site local addresses, to start laying down the > rules for how they have to be used. Maybe it's too early to lay down rules, but it's not too early to start experimenting with different options and at least Erik's draft is a good start for exploring one option. Can you flesh out an alternative option? Erik's draft assumes that there is a "site prefix" and you can compare a global destination address against the site prefix to determine if it is within the site. Yes this restricts things but it sounds like a reasonable assumption to me. In particular, if the reason you have nodes with both global addresses and site-local addresses is to protect against renumbering (local communication using the site-local addresses), then this assumption makes a lot of sense. The site prefix is the prefix you got from your ISP and that might get renumbered - it doesn't have to relate to other meanings of the word site like administrative/protection boundaries. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 18:58:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA2pt516727 for ipng-dist; Thu, 9 Dec 1999 18:51:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA2pi816720 for ; Thu, 9 Dec 1999 18:51:44 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA528844; Thu, 9 Dec 1999 18:51:05 -0800 (PST) Date: Thu, 9 Dec 1999 18:50:51 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-site-prefixes To: Robert Elz Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <15091.944790958@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't think I said "frivolous". Correct. My bad. > As I understand the draft, you use equivalence of global prefix (I have > this one, you have the same one) to mean "we are in the same site". > That's the assumption that I don't think can be maintained. If you are talking about the addresses/prefixes assigned to me and you, then the answer is no. I check the global addresses I get from the DNS (for your name) against the set of prefixes the routers have told me are part of my site. (I may or may not have addresses in all those prefixes.) Assume A:1/48 and B:2/48 are advertised as site prefixes. When the DNS returns A:1:16:9 and fec0:16:9 for your name I will (independent of my own addresses) prefer communicating with the site-local address. If the DNS returns something that doesn't fall in A:1/48 or B:2/48 I will ignore any site-local address returned. Since the site border router typically knows all prefixes assigned to the site (it advertises them externally) it can use yet-to-be-specified extensions to router renumbering to carry this information to all the routers, which will use the specified mechanism to carry this to the hosts. Thus no extra configuration. > | A site must have some finite (and presumably small) number of global > | prefixes. > > Why? > > If you replace "site" there with "node" (and for now ignoring "small" > and nodes that actually get no global prefixes for one reason or other) > then yes, but for "site", why? I have always considered a site to > be an administrative object, not necessarily related to external topology > any way at all (though "internally connected" is reasonable). On the other > hand, global prefixes relate to connectivity and routing (the way they are > intended to be used in IPv6, as distinct from the original IPv4 model). I think I'm starting to understand where you are comming from. My assumption is "a site is a site". Thus the region where are site-local address is unique and routable is the same region that is assigned some length prefix (possibly multiple) from each of the ISPs it connects to. You seem to be saying that this might not be the case - that the internal view of the site (the scope over which a site-local applies) might be larger than the external view of the site (the global prefixes assigned to the site). Is this the case? As an aside, one can avoid the introduction of "external view" and "internal view" of a "site" by instead stating that the site is where a site-local address is unique and routable, but that various parts of the site use different global prefixes - presumably those that are associated with closeby border routers. I'd prefer using that terminology to avoid introducing different views of a "site". The site-prefixes draft handles this case. The prefixes used in the region I'm in will be advertised with the L (onlink), A (addrconf), and S (site prefix) flags set and the Site Plength set. Thus for efficiency reasons the site prefix information is piggybacked on the subnet prefixes in the same option. The site-prefixes that have no corresponding subnet prefix in my region will be advertised with just the S flag and Site Plength set. The only issue is the total size of the advertisement. If there will be 15 site prefixes and 3 subnet prefixes each router advertisement would have 15*64=832 bytes of prefix options. But if there are 100 site prefixes each logical router advertisement would be split over 6 packets each carrying a subset of the prefix options. This seems obsessive. In any case, the adminstrator has full freedom to designate both what constitutes a site (the area where site-locals are unique and routable) and what addresses are assigned in the various regions of the site. > That is, I see no relationship at all between what global prefixes > might exist, and how they are advertised on the various links, and > what is a "site". My definition of a site is more along the lines of > "all those nodes and links configured to route packets for using > site local addresses" - where there's a block, site locals don't pass > from this link to that one, then there is a site boundary, where there > is no block, then the same site continues. No more, and no less, > restrictions than that. And the draft handles that as far as I can tell. > | This means that if a subnet uses e.g. a /120 (with the part between /97 > and > | /120 being the 23 bit subnet number) that the site-local and global > addresses > | for that subnet must both have a /120 with a 23 bit subnet number that is > | the same in the two spaces. > > Yes. It also means, I believe, for the draft to work, that all the nodes > have to understand at least the /120 number. If that node over there is > /64 and I am /120 am I going to recignise it as being in the same site as > I am? No. The nodes use the Site Plength sent in the prefix options. Doesn't require any knowledge of bit boundaries. Doesn't assume the same bit boundaries are used for all site prefixes. Doesn't assume my addresses have the same bit boundaries as your addresses. Hopefully this has clarified how the protocol works so I won't respond to your other comments at this point in time. And if I haven't clarified how the protocol works we need to get over that hump first. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 18:58:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA2rsq16736 for ipng-dist; Thu, 9 Dec 1999 18:53:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA2rh816729 for ; Thu, 9 Dec 1999 18:53:43 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA528979; Thu, 9 Dec 1999 18:52:53 -0800 (PST) Date: Thu, 9 Dec 1999 18:52:39 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Scope ID secret Cabal (minutes) To: Richard Draves Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8101CA21837@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For example suppose you have ethernet interface id#1 attached to a home link > id#2. Then unplug the ethernet and plug it in somewhere else. Now ethernet > interface id#1 is connected to link id#3 and there is a pseudo-interface > id#4 attached to the home link id#2. Then if a someone is using the address > 2/fe80::1 (fe80::1 with link id#2), the right thing can happen whether the > node is at home or moves away. Sure. But I though the Mobile Ipv6 spec states that link local packets should/must not be tunneled to/from the mobile node when it is away from home. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 19:15:51 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA3Ase16822 for ipng-dist; Thu, 9 Dec 1999 19:10:54 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA3Ai816815 for ; Thu, 9 Dec 1999 19:10:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA29196 for ; Thu, 9 Dec 1999 19:10:22 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA25895 for ; Thu, 9 Dec 1999 19:10:21 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 09 Dec 1999 19:10:19 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Dec 1999 19:10:18 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA21840@RED-MSG-50> From: Richard Draves To: "'Erik Nordmark'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-site-prefixes Date: Thu, 9 Dec 1999 19:10:08 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've been sitting for a while on some comments based on implementing (all but reverse dns lookup) the 03 draft: Should there be a validation for S-bit processing of Prefix Information Options that the site prefix length is <= prefix length? It's a bit unclear when a node auto-configures site-local addresses. I assume that a Prefix Information Option with A bit and fec0 prefix is used? (The alternative being that a Prefix Information Option with S and A bits and global prefix results in configuring both a global address and a site-local address.) The description of the S bit in section 4 ("used to create site-local addresses") is confusing me on this point. In section 8.1 - I'd rather keep both site-local and global addresses in the returned address list and let the destination address ordering algorithm apply. I think there needs to be more in section 8.1 about site scope-ids. When a site-local address is returned it needs a site scope-id value. I think this can be derived by keeping track of what interface learned what Site Prefixes, and using the site scope-id value associated with the interface of the relevant Site Prefix. It was enough code that I think it should be optional. So allow simple implementations, when looking at an address list with both site-local and global addresses, to just remove the site-local addresses without keeping track of Site Prefixes. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 22:55:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA6qcb16929 for ipng-dist; Thu, 9 Dec 1999 22:52:38 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA6qS816922 for ; Thu, 9 Dec 1999 22:52:28 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA554549; Thu, 9 Dec 1999 22:52:25 -0800 (PST) Date: Thu, 9 Dec 1999 22:52:10 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-ietf-ipngwg-site-prefixes To: Richard Draves Cc: "'Erik Nordmark'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8101CA21840@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Should there be a validation for S-bit processing of Prefix Information > Options that the site prefix length is <= prefix length? Well, if neither the L or the A bit are set then Prefix Length doesn't make sense. Thus the check would be a bit complex. And it seems better to keep things orthogonal. > It's a bit unclear when a node auto-configures site-local addresses. I > assume that a Prefix Information Option with A bit and fec0 prefix is used? Correct. Nothing new here. Is this something that it would make sense to clarify in the draft? > (The alternative being that a Prefix Information Option with S and A bits > and global prefix results in configuring both a global address and a > site-local address.) The description of the S bit in section 4 ("used to > create site-local addresses") is confusing me on this point. Ah - that "create" would have made sense in -00.txt but is both incorrect and confusing now. Something like "used to determine when to accept and prefer site-local addresses over global addresses" is the intent. > In section 8.1 - I'd rather keep both site-local and global addresses in the > returned address list and let the destination address ordering algorithm > apply. The disadvantage of doing that is that you can't ensure that site-local communication uses site-local addresses. For instance if a router is broken when the application tries to connect the application might fail to connect using the site-local address. When it tries to connect using the global address the router might be back up. > I think there needs to be more in section 8.1 about site scope-ids. When a > site-local address is returned it needs a site scope-id value. I think this > can be derived by keeping track of what interface learned what Site > Prefixes, and using the site scope-id value associated with the interface of > the relevant Site Prefix. Hmm - I wonder if this is the right document to wander into API land which is where scope-ids appear. Perhaps it can be phrased without using the term scope id. Something along the lines of In multi-sited nodes the site-local addresses need to be associated with the set of interfaces that are connected to a site. [Some APIs do this using a scope-id concept - see XXX] This identification can be done by tracking the interface for which the site prefix matched in step 3) and use that interface to determine the associated attached site. > It was enough code that I think it should be optional. So allow simple > implementations, when looking at an address list with both site-local and > global addresses, to just remove the site-local addresses without keeping > track of Site Prefixes. Sorry, what was enough code? Yes, simple implementations might want to ignore site-local addresses unless the RRset contains only site-local addresses i.e. the case when the site is not connected to the Internet. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 9 22:57:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA6tiA16947 for ipng-dist; Thu, 9 Dec 1999 22:55:44 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA6tW816940 for ; Thu, 9 Dec 1999 22:55:32 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA554766 for ; Thu, 9 Dec 1999 22:55:30 -0800 (PST) Date: Thu, 9 Dec 1999 22:55:15 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-site-prefixes (Fwd) To: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <17258.944799269@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert accidentally left off the ipng list. >----------------Begin Forwarded Message----------------< Date: Fri, 10 Dec 1999 15:14:29 +1100 From: "Robert Elz" Subject: Re: draft-ietf-ipngwg-site-prefixes To: "Erik Nordmark" Date: Thu, 9 Dec 1999 18:50:51 -0800 (PST) From: Erik Nordmark Message-ID: | You seem to be saying that this might not be the case - that the internal | view of the site (the scope over which a site-local applies) might be larger | than the external view of the site (the global prefixes assigned to the site). | Is this the case? Yes. Or smaller, or just not related in any way that you can rationally discern from looking at global addresses assigned. | As an aside, one can avoid the introduction of "external view" and "internal | view" of a "site" by instead stating that the site is where a site-local | address is unique and routable, Sure. | but that various parts of the site use different global prefixes Yes. | I'd prefer using that terminology to avoid introducing | different views of a "site". Fine. | The only issue is the total size of the advertisement. | If there will be 15 site prefixes and 3 subnet prefixes each router | advertisement would have 15*64=832 bytes of prefix options. | But if there are 100 site prefixes each logical router advertisement would be | split over 6 packets each carrying a subset of the prefix options. This | seems obsessive. And if, regardless of the number of global prefixes, the only way to specify what is the site is to enumerate the prefix of every subnet in the site? (maybe 10's of thousands of them) (And then aggregate where that works, making note of there not being any kind of hole punching mechanism, so you cannot say "all but") kre >----------------End Forwarded Message----------------< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 9 22:57:50 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA6uIm16956 for ipng-dist; Thu, 9 Dec 1999 22:56:18 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA6u2816949 for ; Thu, 9 Dec 1999 22:56:02 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA554828 for ; Thu, 9 Dec 1999 22:56:00 -0800 (PST) Date: Thu, 9 Dec 1999 22:55:46 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-site-prefixes (Fwd) To: 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 >----------------Begin Forwarded Message----------------< Date: Thu, 9 Dec 1999 22:32:41 -0800 (PST) From: "Erik Nordmark" Subject: Re: draft-ietf-ipngwg-site-prefixes To: "Robert Elz" Cc: "Erik Nordmark" > And if, regardless of the number of global prefixes, the only way to > specify what is the site is to enumerate the prefix of every subnet in the > site? (maybe 10's of thousands of them) (And then aggregate where that > works, making note of there not being any kind of hole punching mechanism, > so you cannot say "all but") Do you have a case where this might actually be useful? While solving that problem might be interesting I don't have any information to tell me that it would be relevant. In practise I expect a site to be representable to the outside world using aggregatable routes. This same aggregation can be used internally when advertising the site prefixes. Erik >----------------End Forwarded Message----------------< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 9 22:58:28 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA6ukh16965 for ipng-dist; Thu, 9 Dec 1999 22:56:46 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA6uO816958 for ; Thu, 9 Dec 1999 22:56:24 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA554863 for ; Thu, 9 Dec 1999 22:56:22 -0800 (PST) Date: Thu, 9 Dec 1999 22:56:08 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-site-prefixes (Fwd) To: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <19539.944808442@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >----------------Begin Forwarded Message----------------< Date: Fri, 10 Dec 1999 17:47:22 +1100 From: "Robert Elz" Subject: Re: draft-ietf-ipngwg-site-prefixes To: "Erik Nordmark" Date: Thu, 9 Dec 1999 22:32:41 -0800 (PST) From: Erik Nordmark Message-ID: | Do you have a case where this might actually be useful? Not immediately, but since I have no idea how site addressing might end up being useful, I don't want anything to restrict it. | In practise I expect a site to be representable to the outside world | using aggregatable routes. I expect "objects" (not sites any more, as you defined site in a particular way) to be representable that way. | This same aggregation can be used internally | when advertising the site prefixes. Only if there is some kind of correspondence between the external connectivity (giving the global addresing) and the internal notion of the site. I don't know that there will necessarily be any such thing (though I wouldn't be surprised if it was often the case), and don't want to start defining things now which depend upon that. kre ps: if I didn't send my previous message to the list, that was not intentional. I don't have a copy, so if I left out the cc header, and you feel inclined, please forward it - your Reply-To header kills me every time, my mailer will generally send only to addresses in a Reply-To when such a header exists. >----------------End Forwarded Message----------------< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 10 01:47:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBA9iS117100 for ipng-dist; Fri, 10 Dec 1999 01:44:28 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBA9iK817093 for ; Fri, 10 Dec 1999 01:44:20 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA22194; Fri, 10 Dec 1999 01:44:18 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA28622; Fri, 10 Dec 1999 01:44:12 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA05948; Fri, 10 Dec 1999 10:44:11 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id KAA24477; Fri, 10 Dec 1999 10:44:09 +0100 (MET) Message-Id: <199912100944.KAA24477@givry.inria.fr> From: Francis Dupont To: Erik Nordmark cc: Carl Williams , ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-reply-to: Your message of Thu, 09 Dec 1999 17:03:03 PST. Date: Fri, 10 Dec 1999 10:44:04 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > An ifindex() clone for sites will be useful (ie. I'd like to get > this ASAP). I agree. One question is whether we need a clone for link ids as well. (It is becoming more and more common to have multiple NICs connected to a subnet for high availability and load balancing.) => in such case it is very common to have a virtual interface which hides all the (nasty) details and brings us back to the one link-one interface case. Carl, I believe Sun has such things, can you help us? Regards Francis.Dupont@inria.fr PS: the textual address thread has not yet reached a concensus about the exact syntax... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 10 03:15:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBABDCY17141 for ipng-dist; Fri, 10 Dec 1999 03:13:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBABD2817134 for ; Fri, 10 Dec 1999 03:13:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA17884; Fri, 10 Dec 1999 03:12:58 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA25833; Fri, 10 Dec 1999 04:12:57 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id UAA17722; Fri, 10 Dec 1999 20:01:49 +0900 (JST) Date: Fri, 10 Dec 1999 20:13:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: Erik.Nordmark@eng.sun.com, carlw@antley.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-Reply-To: In your message of "Fri, 10 Dec 1999 10:44:04 +0100" <199912100944.KAA24477@givry.inria.fr> References: <199912100944.KAA24477@givry.inria.fr> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.4 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 13 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 10 Dec 1999 10:44:04 +0100, >>>>> Francis Dupont said: > PS: the textual address thread has not yet reached a concensus about > the exact syntax... I know. Sorry for the delay, but we're now locally discussing the syntax in KAME and will soon propose a (new) one in this list. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 10 06:37:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBAEXI317247 for ipng-dist; Fri, 10 Dec 1999 06:33:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBAEX6817240 for ; Fri, 10 Dec 1999 06:33:07 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA06503 for ; Fri, 10 Dec 1999 06:33:06 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11987 for ; Fri, 10 Dec 1999 06:33:05 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA10790 for ; Fri, 10 Dec 1999 08:33:04 -0600 (CST) Message-Id: <199912101433.IAA10790@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-site-prefixes In-reply-to: Your message of Thu, 09 Dec 1999 17:12:10 PST. Date: Fri, 10 Dec 1999 08:33:03 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'd like to understand if requiring scalability to 100's of prefixes per > site is reasonable. Leaving aside the question of whether it's a reasonable requirement, I don't think intra-site routing and ND have a problem at that level. The first crunch I can see will be in DNS replies, and the next one in source/destination address selection. 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 Fri Dec 10 06:38:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBAEbpY17265 for ipng-dist; Fri, 10 Dec 1999 06:37:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBAEbd817258 for ; Fri, 10 Dec 1999 06:37:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA18673 for ; Fri, 10 Dec 1999 06:37:39 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14264 for ; Fri, 10 Dec 1999 06:37:38 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA10819 for ; Fri, 10 Dec 1999 08:37:37 -0600 (CST) Message-Id: <199912101437.IAA10819@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-site-prefixes In-reply-to: Your message of Thu, 09 Dec 1999 17:33:00 PST. <4D0A23B3F74DD111ACCD00805F31D8101CA21836@RED-MSG-50> Date: Fri, 10 Dec 1999 08:37:37 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I'd like to understand if requiring scalability to 100's of > > prefixes per site is reasonable. > > What if the ISP has more than one prefix because the ISP in turn is > multi-homed to multiple bigger ISPs? site -> 4 ISPs, each ISP -> 4 upstreams gives <= 16 global prefixes, which I think nears, but does not quite reach, the DNS truncation threshold. And if a "retail" ISP is connected to multiple upper-level ISP's which belong to a single TLA, they may use the same prefix with all of them (at the discretion of all parties, of course). This would reduce the prefix-multiplication at the lowest two levels. 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 Fri Dec 10 08:49:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) id dBAGlRi17666 for ipng-dist; Fri, 10 Dec 1999 08:47:27 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta9+Sun/8.10.0.Beta9) with ESMTP id dBAGlI817659 for ; Fri, 10 Dec 1999 08:47:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA10094 for ; Fri, 10 Dec 1999 08:47:18 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20147 for ; Fri, 10 Dec 1999 08:47:17 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 0B90D5782C; Fri, 10 Dec 1999 10:47:17 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 043DD54602; Fri, 10 Dec 1999 10:47:16 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 14FECBC4C8; Fri, 10 Dec 1999 10:47:10 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 9F1C2B2A44; Fri, 10 Dec 1999 10:47:09 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000031827; Fri, 10 Dec 1999 11:47:16 -0500 (EST) From: Jim Bound Message-Id: <199912101647.LAA0000031827@quarry.zk3.dec.com> To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-site-prefixes In-reply-to: Your message of "Thu, 09 Dec 1999 22:52:10 PST." Date: Fri, 10 Dec 1999 11:47:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, None of this should be mandatory. In other words the user should have a choice to not use your draft and it should not be the default. The default should be to use global addresses? Do you agree? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 13 10:09:16 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBDI6ET20697 for ipng-dist; Mon, 13 Dec 1999 10:06:14 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBDI5MY20659 for ; Mon, 13 Dec 1999 10:05:23 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA18998 for ; Sun, 12 Dec 1999 04:44:21 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05921 for ; Sun, 12 Dec 1999 04:44:21 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id VAA05673; Sun, 12 Dec 1999 21:44:13 +0900 (JST) To: Francis Dupont cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Wed, 08 Dec 1999 16:39:41 +0100. <199912081539.QAA04962@givry.inria.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: sockaddr_storage issue From: itojun@iijlab.net Date: Sun, 12 Dec 1999 21:44:13 +0900 Message-ID: <5671.945002653@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In your previous mail you wrote: > Personally, "ss_len" makes more sense for me. >=> I (for the "INRIA" stack) use ss_len, ss_family, and _ss_... for >others (they are not supposed to be used). I am (already :-) in favor >of ss_len and ss_family (ie. don't cast to sockaddr only for these >two common fields). I'm also favor of ss_{len,family}. I would really like to see it declared in RFC2553. The reason why KAME does not have this is RFC2553 does not have this (KAME used to have s6_addr{8,16,32} for in6_addr, but we have commented them out for more strict RFC2553-ism). >PS: I have some #define __ss_len ss_len for KAME compatibility, >I'd like to remove them if possible. I don't think you need to supply this, as __ss_len should NOT be touched directly. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 13 10:34:06 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBDIUkh21129 for ipng-dist; Mon, 13 Dec 1999 10:30:46 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBDIUgY21122 for ; Mon, 13 Dec 1999 10:30:42 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA19947 for ipng@sunroof.eng.sun.com; Mon, 13 Dec 1999 10:30:05 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBDIHtY21016 for ; Mon, 13 Dec 1999 10:17:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA26487 for ; Mon, 13 Dec 1999 06:57:50 -0800 (PST) From: core@kame.net Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15106 for ; Mon, 13 Dec 1999 06:57:48 -0800 (PST) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id XAA07585 for ; Mon, 13 Dec 1999 23:57:43 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id XAA27653 for ; Mon, 13 Dec 1999 23:57:42 +0900 (JST) Received: from Mew.org (mine.iij.ad.jp [192.168.10.205]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with SMTP id XAA02513 for ; Mon, 13 Dec 1999 23:57:42 +0900 (JST) Date: Mon, 13 Dec 1999 23:58:40 +0900 (JST) Message-Id: <19991213.235840.41718565.kazu@Mew.org> To: ipng@sunroof.eng.sun.com Subject: (6bone-jp 1253) KAME stable package 19991213 X-Mailer: Mew version 1.95b12 on Emacs 20.5 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As usual, KAME Project has released "stable" packages of IPv6/IPsec network code for BSD/OS 3.1, FreeBSD 2.2.8/3.3, NetBSD 1.4.1, and OpenBSD 2.6. These packages have been tested by the TAHI team(http://www.tahi.org). They are free of charge but absolutely no warranty. They are avaiable from the following web site: http://www.kame.net/ NOTE: IF YOU GAIN ACCESS TO THIS WEB PAGE OVER IPv6, THE TURTLE WILL DANCE. To know the changes from the previous stable package, please refer to the CHANGELOG file. --KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 13 12:10:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBDK6We21348 for ipng-dist; Mon, 13 Dec 1999 12:06:32 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBDK6NY21341 for ; Mon, 13 Dec 1999 12:06:24 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA08053 for ; Mon, 13 Dec 1999 12:06:22 -0800 (PST) Received: from mailext02.compaq.com (mailext02.compaq.com [207.18.199.33]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07669 for ; Mon, 13 Dec 1999 12:06:21 -0800 (PST) Received: by mailext02.compaq.com (Postfix, from userid 12345) id C3F3D9A823; Mon, 13 Dec 1999 14:06:20 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext02.compaq.com (Postfix) with ESMTP id BC13B90D84; Mon, 13 Dec 1999 14:06:20 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 9BA874FB03; Mon, 13 Dec 1999 14:06:13 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id 240764C902; Mon, 13 Dec 1999 14:06:13 -0600 (CST) Received: by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000028020; Mon, 13 Dec 1999 15:06:19 -0500 (EST) Date: Mon, 13 Dec 1999 15:06:19 -0500 (EST) From: Jack McCann Message-Id: <199912132006.PAA0000028020@quarry.zk3.dec.com> To: Francis.Dupont@inria.fr, itojun@iijlab.net Subject: Re: sockaddr_storage issue Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, xnet has dropped the leading underscores and will use "ss_family". - 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 Dec 13 17:01:31 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBE0wm521682 for ipng-dist; Mon, 13 Dec 1999 16:58:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBE0wcY21675 for ; Mon, 13 Dec 1999 16:58:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA28691 for ; Mon, 13 Dec 1999 16:58:37 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA18168 for ; Mon, 13 Dec 1999 17:58:35 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA26513; Tue, 14 Dec 1999 09:56:29 +0900 (JST) To: Jack McCann cc: ipng@sunroof.eng.sun.com In-reply-to: mccann's message of Mon, 13 Dec 1999 15:06:19 EST. <199912132006.PAA0000028020@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: sockaddr_storage issue From: itojun@iijlab.net Date: Tue, 14 Dec 1999 09:56:29 +0900 Message-ID: <26511.945132989@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >FYI, xnet has dropped the leading underscores and will use "ss_family". great. I hope RFC2553bis to synchronize with it... a problem I see here is synchronization between X/Open specs and RFCs. we briefly seen it in get{addr,name}info, and sockaddr_storage. we need to see more synchronization between the two, or make one of them refer to the other. which one should an implementer consider authoritative for now? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 13 22:07:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBE65N921883 for ipng-dist; Mon, 13 Dec 1999 22:05:23 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBE65DY21876 for ; Mon, 13 Dec 1999 22:05:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA03241 for ; Mon, 13 Dec 1999 22:05:11 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA17461 for ; Mon, 13 Dec 1999 22:05:11 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Dec 1999 22:03:40 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Dec 1999 22:03:40 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101DB1B27A@RED-MSG-50> From: Richard Draves To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: RE: Scope ID secret Cabal (minutes) Date: Mon, 13 Dec 1999 22:03:38 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Sure. But I though the Mobile Ipv6 spec states that link local packets > should/must not be tunneled to/from the mobile node when it is away > from home. Well, sure enough it does: However, packets addressed to the mobile node's link-local address MUST NOT be tunneled to the mobile node. Instead, such a packet MUST be discarded, and the home agent SHOULD return an ICMP Destination Unreachable, Code 3, message to the packet's Source Address (unless this Source Address is a multicast address). Packets addressed to the mobile node's site-local address SHOULD be tunneled to the mobile node by default, but this behavior MUST be configurable to disable it; currently, the exact definition and semantics of a "site" and a site-local address are undefined in IPv6, and this default behavior might change at some point in the future. I think it could work; there are certainly tricky aspects but it is quite similar to the site-local case. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 13 22:07:43 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBE660k21892 for ipng-dist; Mon, 13 Dec 1999 22:06:00 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBE65jY21885 for ; Mon, 13 Dec 1999 22:05:45 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA03256 for ; Mon, 13 Dec 1999 22:05:43 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA17583 for ; Mon, 13 Dec 1999 22:05:43 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Dec 1999 22:03:45 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Dec 1999 22:03:45 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101DB1B27B@RED-MSG-50> From: Richard Draves To: Erik Nordmark Cc: Matt Crawford , ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-site-prefixes Date: Mon, 13 Dec 1999 22:03:42 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there a case where the site has e.g. 100 prefixes but the > subnets only > have say 3 prefixes? This gets back to the definition of a site... suppose you have a company with 100 branch offices scattered across the globe. Each branch office is connected to a local ISP. Each branch office has subnets with just one global site prefix allocated from the local ISP. But there is a common subnet numbering across the entire company and there is a desire to use site-local addressing across the entire company. The branch offices are all connected via VPN tunnels. So in this example, the site has 100 global prefixes but each subnet has only one global prefix. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 13 22:08:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBE65DZ21874 for ipng-dist; Mon, 13 Dec 1999 22:05:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBE654Y21867 for ; Mon, 13 Dec 1999 22:05:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA28312 for ; Mon, 13 Dec 1999 22:05:04 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA17435 for ; Mon, 13 Dec 1999 22:05:03 -0800 (PST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Dec 1999 22:03:37 -0800 (Pacific Standard Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Dec 1999 22:03:37 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101DB1B279@RED-MSG-50> From: Richard Draves To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-site-prefixes Date: Mon, 13 Dec 1999 22:03:37 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Should there be a validation for S-bit processing of Prefix > Information > > Options that the site prefix length is <= prefix length? > > Well, if neither the L or the A bit are set then Prefix > Length doesn't make > sense. Thus the check would be a bit complex. > And it seems better to keep things orthogonal. OK. > > In section 8.1 - I'd rather keep both site-local and global > addresses in the > > returned address list and let the destination address > ordering algorithm > > apply. > > The disadvantage of doing that is that you can't ensure that > site-local > communication uses site-local addresses. For instance if a > router is broken > when the application tries to connect the application might > fail to connect > using the site-local address. When it tries to connect using > the global > address the router might be back up. If for some reason the site-local address is not working but the global address does, won't it almost always be better to use the global address? Using the global address will only be a problem if there is a renumbering or some other event that effects the global prefix. So it seems best to risk a small chance of a future failure to prevent otherwise certain failure in the present. > > I think there needs to be more in section 8.1 about site > scope-ids. When a > > site-local address is returned it needs a site scope-id > value. I think this > > can be derived by keeping track of what interface learned what Site > > Prefixes, and using the site scope-id value associated with > the interface of > > the relevant Site Prefix. > > Hmm - I wonder if this is the right document to wander into > API land which > is where scope-ids appear. > Perhaps it can be phrased without using the term scope id. > Something along the lines of > In multi-sited nodes the site-local addresses need to > be associated > with the set of interfaces that are connected to a site. > [Some APIs do this using a scope-id concept - see XXX] > This identification can be done by tracking the > interface for which > the site prefix matched in step 3) and use that interface > to determine the associated attached site. Well, the document already has a toe into API land because it's effectively talking about what getaddrinfo/getipnodebyname implementations should do. Keeping the phrasing less API-specific would be good but something is needed. > > It was enough code that I think it should be optional. So > allow simple > > implementations, when looking at an address list with both > site-local and > > global addresses, to just remove the site-local addresses > without keeping > > track of Site Prefixes. > > Sorry, what was enough code? > > Yes, simple implementations might want to > ignore site-local addresses unless the RRset contains only site-local > addresses i.e. the case when the site is not connected to the > Internet. The code to maintain and use the Site Prefix Table, allow for the new type of Prefix Information option when sending & receiving RAs, etc. It was probably 100-200 lines of code (guesstimate). Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 13 22:08:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBE66mg21901 for ipng-dist; Mon, 13 Dec 1999 22:06:48 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBE66WY21894 for ; Mon, 13 Dec 1999 22:06:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id WAA03320 for ; Mon, 13 Dec 1999 22:06:31 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA17838 for ; Mon, 13 Dec 1999 22:06:30 -0800 (PST) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 13 Dec 1999 22:03:30 -0800 (Pacific Standard Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Dec 1999 22:03:30 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101DB1B277@RED-MSG-50> From: Richard Draves To: Jim Bound , Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-site-prefixes Date: Mon, 13 Dec 1999 22:03:29 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > None of this should be mandatory. In other words the user should have > a choice to not use your draft and it should not be the default. The > default should be to use global addresses? There is one thing that should be mandatory - if a name resolves to both site-local and global addresses, and you are not implementing draft-ietf-ipngwg-site-prefixes in its fullness, then you should discard the site-local addresses. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 14 06:55:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBEEqFQ22384 for ipng-dist; Tue, 14 Dec 1999 06:52:15 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBEEpnY22377 for ; Tue, 14 Dec 1999 06:52:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA00474 for ; Tue, 14 Dec 1999 06:51:48 -0800 (PST) Received: from basil.cdt.luth.se (basil.cdt.luth.se [130.240.64.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14412 for ; Tue, 14 Dec 1999 06:51:47 -0800 (PST) Received: from tua.cdt.luth.se (tua.cdt.luth.se [130.240.64.43]) by basil.cdt.luth.se (8.9.3/8.7.3) with SMTP id PAA10911; Tue, 14 Dec 1999 15:50:43 +0100 (MET) Message-Id: <3.0.6.32.19991214155247.00a05a50@basil.cdt.luth.se> X-Sender: micke@basil.cdt.luth.se X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 14 Dec 1999 15:52:47 +0100 To: PILC Mailing List , AVT Mailing List , IPNG Mailing List From: Mikael Degermark Subject: ROBHC mailing list Cc: micke@cdt.luth.se Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, This is an announcement of the mailing list to be used for issues concerning robust header compression as outlined by the robhc BOF held in Washington. Please take a look at the tentative WG charter http://www.cdt.luth.se/~micke/robhc-charter.txt The mailing list is robhc@cdt.luth.se Subscribe by sending an email to: majordomo@cdt.luth.se where the body of the email contains the single line subscribe robhc@cdt.luth.se Let's talk about whether additional TCP header compression is needed and specifically what TCP headers we should aim to compress. Seems to me that as a first approximation, compression of SACK options, TIMESTAMP options, and T/TCP headers might be worthwhile over low-bandwidth and high-latency links. Cheers, Mikael Degermark -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 14 09:38:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBEHZLm22521 for ipng-dist; Tue, 14 Dec 1999 09:35:21 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBEHZAY22514 for ; Tue, 14 Dec 1999 09:35:10 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA165805; Tue, 14 Dec 1999 09:35:08 -0800 (PST) Date: Tue, 14 Dec 1999 09:35:08 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-ietf-ipngwg-site-prefixes To: Richard Draves Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8101DB1B279@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If for some reason the site-local address is not working but the global > address does, won't it almost always be better to use the global address? > Using the global address will only be a problem if there is a renumbering or > some other event that effects the global prefix. So it seems best to risk a > small chance of a future failure to prevent otherwise certain failure in the > present. I don't know. It has to do with the users' perception of the viability of site renumbering. If we can make a statement that says "if you configure things this way then all site-internal communication will be unaffected by site renumbering since it will always of site-local addresses" would that be helpful in convincing users that the risks associated with planned renumbering (with overlap when both prefixes are valid) are acceptable? Or will the users' perception be that an IPv6-IPv6 NAT box is the best way to deal with site renumbering. (I hope not.) Or is exchange based addresses the way to avoid this all together when switching ISPs? Will such addresses come into use? How will the users be educated so that they can ask their ISPs for exchange based IPv6 addresses? > Well, the document already has a toe into API land because it's effectively > talking about what getaddrinfo/getipnodebyname implementations should do. > Keeping the phrasing less API-specific would be good but something is > needed. Will do. 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 Dec 14 09:42:05 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBEHetg22543 for ipng-dist; Tue, 14 Dec 1999 09:40:55 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBEHejY22536 for ; Tue, 14 Dec 1999 09:40:45 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA166662; Tue, 14 Dec 1999 09:40:43 -0800 (PST) Date: Tue, 14 Dec 1999 09:40:43 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Scope ID secret Cabal (minutes) To: Richard Draves Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8101DB1B27A@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well, sure enough it does: > > However, packets addressed to the mobile node's link-local address > MUST NOT be tunneled to the mobile node. [...] > > I think it could work; there are certainly tricky aspects but it is quite > similar to the site-local case. Yes, I think it could be made to work. But that would raise some security issues as well as traffic issues. For instance, if you tunnel the router advertisements (which are sent to link-local addresses) does that mean that the mobile host away from home should trust the unauthenticated router advertisement just because it has an encapsulating IP header? The current scheme in the mobile ipv6 spec is to explicitly relay important changes in router advertisements but those packets must be authenticated. Also, folks have raised the issues that when away from home you probably don't want to receive every link-local packet (like the "beacon" router advertisements which are sent every second or so, and presumably the random DAD packets etc) when you are far away on a potentially slow link. Instead the home agent will proxy for the mobile. 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 Dec 14 09:51:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBEHmRu22579 for ipng-dist; Tue, 14 Dec 1999 09:48:27 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBEHmHY22572 for ; Tue, 14 Dec 1999 09:48:17 -0800 (PST) Received: from bobo (bobo.Eng.Sun.COM [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA167811; Tue, 14 Dec 1999 09:48:14 -0800 (PST) Date: Tue, 14 Dec 1999 09:48:13 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-ietf-ipngwg-site-prefixes To: Richard Draves Cc: Erik Nordmark , Matt Crawford , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8101DB1B27B@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This gets back to the definition of a site... suppose you have a company > with 100 branch offices scattered across the globe. Each branch office is > connected to a local ISP. Each branch office has subnets with just one > global site prefix allocated from the local ISP. But there is a common > subnet numbering across the entire company and there is a desire to use > site-local addressing across the entire company. The branch offices are all > connected via VPN tunnels. > > So in this example, the site has 100 global prefixes but each subnet has > only one global prefix. Agreed. I think Steve would argue that they are actually different sites but that wouldn't prevent users from actually deploying the above type of scenario. I just don't know how common place this will be. Today I suspect that major corporations will not have direct Internet access at all 100 branch offices since each access point requires a firewall complex of some sort plus real people to watch over the firewalls, upgrade them, etc. For that reason today the number of access points will be limited. (Yes, the branch offices can still be on the inside of the corporate firewalls by having a VPN over the public Internet - but they will not have direct access to the Internet over that wire.) For the future we can only speculate. If you believe in the motivations for distributed firewalls (see [Bellovin] Distributed Firewalls, S. Bellovin, available at http://www.research.att.com/~smb/papers/distfw.pdf or http://www.research.att.com/~smb/papers/distfw.ps (work in progress). you might get your above example. 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 Dec 14 20:01:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBF3xEb23304 for ipng-dist; Tue, 14 Dec 1999 19:59:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBF3x5Y23297 for ; Tue, 14 Dec 1999 19:59:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA12338 for ; Tue, 14 Dec 1999 19:59:03 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA18048 for ; Tue, 14 Dec 1999 20:59:03 -0700 (MST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id C054C91E; Tue, 14 Dec 1999 22:59:02 -0500 (EST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id 837C9834; Tue, 14 Dec 1999 22:59:02 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000021915; Tue, 14 Dec 1999 22:59:02 -0500 (EST) From: Jim Bound Message-Id: <199912150359.WAA0000021915@quarry.zk3.dec.com> To: Richard Draves Cc: Jim Bound , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-site-prefixes In-reply-to: Your message of "Mon, 13 Dec 1999 22:03:29 PST." <4D0A23B3F74DD111ACCD00805F31D8101DB1B277@RED-MSG-50> Date: Tue, 14 Dec 1999 22:59:01 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> None of this should be mandatory. In other words the user should have >> a choice to not use your draft and it should not be the default. The >> default should be to use global addresses? >There is one thing that should be mandatory - if a name resolves to both >site-local and global addresses, and you are not implementing >draft-ietf-ipngwg-site-prefixes in its fullness, then you should discard the >site-local addresses. But there is no consensus that users should be putting site-locals in DNS at this point and that is still a point of contention on the WG list as I see it. p.s. This is a real issue for products shipping in year-2000. Do we permit site-local in DNS? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 14 20:11:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBF49MP23322 for ipng-dist; Tue, 14 Dec 1999 20:09:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBF49DY23315 for ; Tue, 14 Dec 1999 20:09:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA13208 for ; Tue, 14 Dec 1999 20:09:11 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA09522 for ; Tue, 14 Dec 1999 20:09:11 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 32A875797D; Tue, 14 Dec 1999 22:09:11 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 2DC6754601; Tue, 14 Dec 1999 22:09:11 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id B9E8BBC881; Tue, 14 Dec 1999 21:56:40 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 5D02DB2A42; Tue, 14 Dec 1999 21:56:40 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000021215; Tue, 14 Dec 1999 22:56:46 -0500 (EST) From: Jim Bound Message-Id: <199912150356.WAA0000021215@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jack McCann , ipng@sunroof.eng.sun.com Subject: Re: sockaddr_storage issue In-reply-to: Your message of "Tue, 14 Dec 1999 09:56:29 +0900." <26511.945132989@coconut.itojun.org> Date: Tue, 14 Dec 1999 22:56:46 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>FYI, xnet has dropped the leading underscores and will use "ss_family". > great. I hope RFC2553bis to synchronize with it... Absolutely. a problem I see here is synchronization between X/Open specs and RFCs. we briefly seen it in get{addr,name}info, and sockaddr_storage. we need to see more synchronization between the two, or make one of them refer to the other. which one should an implementer consider authoritative for now? My hope is XNET gets on the list here and I think are here. But we need an Internet DOC in this space or I would suggest we defer all this to XNET. I believe the only think I hear consensus on thus far is: 1. Deprecate getipnodebyname and friends. 2. Make sure functionality and flags from getipnodebyname are supported in getaddrinfo. Do we have consensus on dropping the underscores i.e. make is ss_family? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 03:37:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFBYed23473 for ipng-dist; Wed, 15 Dec 1999 03:34:40 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFBYUY23466 for ; Wed, 15 Dec 1999 03:34:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA09574 for ; Wed, 15 Dec 1999 03:34:29 -0800 (PST) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20933 for ; Wed, 15 Dec 1999 04:34:28 -0700 (MST) Received: from hygro.adsl.duke.edu (localhost [127.0.0.1]) by hygro.adsl.duke.edu (8.8.7/8.8.7) with ESMTP id GAA00593; Wed, 15 Dec 1999 06:33:39 -0500 Message-Id: <199912151133.GAA00593@hygro.adsl.duke.edu> To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-site-prefixes In-Reply-To: Message from Jim Bound of "Tue, 14 Dec 1999 22:59:01 EST." <199912150359.WAA0000021915@quarry.zk3.dec.com> Date: Wed, 15 Dec 1999 06:33:39 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But there is no consensus that users should be putting site-locals in > DNS at this point and that is still a point of contention on the WG list > as I see it. Folks will put site-locals in the DNS. Saying they should not won't stop them. What would be useful is some documentation discussing the issues of doing so (like two-faced DNS so that the outside world doesn't see such addresses), etc., and of course any specific recommendations we think are in order. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 03:53:12 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFBoov23492 for ipng-dist; Wed, 15 Dec 1999 03:50:51 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFBogY23485 for ; Wed, 15 Dec 1999 03:50:42 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA03923 for ; Wed, 15 Dec 1999 03:50:41 -0800 (PST) Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [130.155.191.233]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11994 for ; Wed, 15 Dec 1999 03:50:38 -0800 (PST) Received: from isc.org (marka@localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.8.5/8.8.5) with ESMTP id WAA19793; Wed, 15 Dec 1999 22:49:19 +1100 (EST) Message-Id: <199912151149.WAA19793@bsdi.dv.isc.org> To: Jim Bound cc: itojun@iijlab.net, Jack McCann , ipng@sunroof.eng.sun.com, marka@isc.org From: Mark.Andrews@iengines.com Subject: Re: sockaddr_storage issue In-reply-to: Your message of "Tue, 14 Dec 1999 22:56:46 CDT." <199912150356.WAA0000021215@quarry.zk3.dec.com> Date: Wed, 15 Dec 1999 22:49:10 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Do we have consensus on dropping the underscores i.e. make is ss_family? > > thanks > /jim I think that was what I was seeing from the list. Mark -- Mark Andrews, Internet Engines Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@iengines.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 08:11:20 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFG8RU23639 for ipng-dist; Wed, 15 Dec 1999 08:08:27 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFG8IY23632 for ; Wed, 15 Dec 1999 08:08:18 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA05788 for ; Wed, 15 Dec 1999 08:08:17 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA18772 for ; Wed, 15 Dec 1999 08:08:14 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA20578; Wed, 15 Dec 1999 17:08:04 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id RAA30593; Wed, 15 Dec 1999 17:07:57 +0100 (MET) Message-Id: <199912151607.RAA30593@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: sockaddr_storage issue In-reply-to: Your message of Sun, 12 Dec 1999 21:44:13 +0900. <5671.945002653@coconut.itojun.org> Date: Wed, 15 Dec 1999 17:07:50 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >PS: I have some #define __ss_len ss_len for KAME compatibility, >I'd like to remove them if possible. I don't think you need to supply this, as __ss_len should NOT be touched directly. % grep __ss_len ../sys/netinet6/ipsec.c | wc -l 13 Francis.Dupont@inria.fr PS: then we are in favor of the __ removal! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 15 08:12:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFGB1p23648 for ipng-dist; Wed, 15 Dec 1999 08:11:01 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFGAnY23641 for ; Wed, 15 Dec 1999 08:10:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA25496 for ; Wed, 15 Dec 1999 08:10:49 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13141 for ; Wed, 15 Dec 1999 09:10:47 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA21276; Thu, 16 Dec 1999 01:10:18 +0900 (JST) To: Francis Dupont cc: ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Wed, 15 Dec 1999 17:07:50 +0100. <199912151607.RAA30593@givry.inria.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: sockaddr_storage issue From: itojun@iijlab.net Date: Thu, 16 Dec 1999 01:10:18 +0900 Message-ID: <21274.945274218@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't think you need to supply this, as __ss_len should NOT be > touched directly. >% grep __ss_len ../sys/netinet6/ipsec.c | wc -l > 13 >PS: then we are in favor of the __ removal! we've removed those (and some other references) already, a week or two ago :-) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 08:56:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFGrUc23703 for ipng-dist; Wed, 15 Dec 1999 08:53:30 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFGrMY23696 for ; Wed, 15 Dec 1999 08:53:22 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA27139 for ; Wed, 15 Dec 1999 08:53:21 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11511 for ; Wed, 15 Dec 1999 08:53:19 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id RAA22229; Wed, 15 Dec 1999 17:53:16 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id RAA25691; Wed, 15 Dec 1999 17:53:16 +0100 (MET) Message-Id: <199912151653.RAA25691@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: sockaddr_storage issue In-reply-to: Your message of Thu, 16 Dec 1999 01:10:18 +0900. <21274.945274218@coconut.itojun.org> Date: Wed, 15 Dec 1999 17:53:02 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I don't think you need to supply this, as __ss_len should NOT be > touched directly. >% grep __ss_len ../sys/netinet6/ipsec.c | wc -l > 13 >PS: then we are in favor of the __ removal! we've removed those (and some other references) already, a week or two ago :-) => I have done it on the 19991122 snapshot (ie. I am a bit late and I needed to freeze things for an important demo yesterday). The important thing is we have a consensus and an already done action by XNET: no more issue? Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 10:07:57 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFI5GG23894 for ipng-dist; Wed, 15 Dec 1999 10:05:16 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFI5CY23887 for ; Wed, 15 Dec 1999 10:05:12 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA21529 for ipng@sunroof.eng.sun.com; Wed, 15 Dec 1999 10:04:33 -0800 (PST) Received: from antley.eng.sun.com (antley [129.146.86.225]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with SMTP id dBF7THY23363 for ; Tue, 14 Dec 1999 23:29:17 -0800 (PST) Received: from antley by antley.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA18029; Tue, 14 Dec 1999 23:28:17 -0800 Message-Id: <199912150728.XAA18029@antley.eng.sun.com> Date: Tue, 14 Dec 1999 23:28:17 -0800 (PST) From: Carl Williams Reply-To: Carl Williams Subject: Re: sockaddr_storage issue To: bound@zk3.dec.com, mccann@zk3.dec.com, itojun@iijlab.net Cc: carlw@antley.eng.sun.com, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 5zHGO0jvrOsq5SVkuQOssA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >Do we have consensus on dropping the underscores i.e. make is ss_family? > As was pointed out the XNET document already has this change and those vendors belonging to the Open Group already implement this change. The XNET document has other changes that we should also adopt with RFC2553bis (e.g., dealing with error codes returned by getnameinfo()). If the documents are not in sync, then we will have varying implementations (not good for IPv6 adoption). The KAME folks don't have access to the XNET documents and have no idea what changes we made to getaddrinfo() a few months back. Indeed, there were a number of substantial changes made to the IPv6 socket API within the Open Group. >> 1. Deprecate getipnodebyname What about an applicability statement instead. Unlike gethostbyname2() there is alot more code and porting documents making use of getipnodebyname(). I am not sure it is a good idea to banish it from the RFC as we did for gethostbyname2()? >> 2. Make sure functionality and flags from getipnodebyname are supported >> in getaddrinfo. I have given this thought (e.g., support of AI_ADDRCONFIG, AI_DEFAULT, AI_ALL and AI_V4MAPPED as new flag settings for getaddrinfo()). We need to detail the behavior when any of these flags are specified with the various ai_family definitions (PF_UNSPEC, PF_INET, PF_INET6,...). All the possible return error values need to be documented as well. I can send out a proposed specification. Finally, it was noted that the sin6_scope_id is under specified (RFC2553). For example, Erik raised the issue of what should the semantics be when sin6_scope_id is set in a bind()? (and other issues). Should these clarifications be a separate I-D and then XNET could take the new RFC into account when clarifying their specifications? Carl -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 10:09:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFI8CL23912 for ipng-dist; Wed, 15 Dec 1999 10:08:12 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFI88Y23903 for ; Wed, 15 Dec 1999 10:08:08 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA21559 for ipng@sunroof.eng.sun.com; Wed, 15 Dec 1999 10:07:29 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBF8R9Y23381 for ; Wed, 15 Dec 1999 00:27:09 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA25198 for ; Wed, 15 Dec 1999 00:27:10 -0800 (PST) From: tkuiper@tobit.com Received: from mail.tobit.com (tobit.com [62.52.80.126]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA15450 for ; Wed, 15 Dec 1999 00:27:08 -0800 (PST) Message-Id: <199912150827.AAA15450@venus.Sun.COM> Subject: Tunelling with Solaris 8 <-> Linux To: ipng@sunroof.eng.sun.com Date: 15 Dec 99 08:27:10 UT X-Priority: 3 (Normal) Importance: normal X-Mailer: David by Tobit Software, Germany (PM-6.00a (0163)) X-David-Sym: 0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1DD2510B41FE" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------1DD2510B41FE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I tryed to link a Solaris 8 box (with buildin IPv6) to my Linux tunnel. However its not working correctly (I see data on the interface but there is nothing coming back if I send a ping and stuff). Solaris 8 box config: $> cat /etc/hostname6.iprb0 addif 3ffe:400:380:1234::1/128 up $> cat /etc/hostname6.ip.tun0 tsrc 206.191.192.57 tdst 62.52.79.1 up $> /usr/sbin/route add -inet6 2000::/3 fe80::3e34:4f01 add net 2000::/3 $> $> cat /etc/inet/ndpd.conf if ip.tun0 AdvSendAdvertisements 1 prefix 3ffe:400:380:1234::/64 ip.tun0 Linux system script: #!/bin/sh PATH=3D/sbin:$PATH case "$1" in start) echo "Starting v6..." insmod ipv6 ifconfig eth1 add 3ffe:400:380::1 iptunnel add v6_6bone remote 128.176.191.66 mode sit ttl 64 ifconfig v6_6bone up route add -A inet6 2000::/3 dev v6_6bone iptunnel add v6_sol8 remote 206.191.192.57 mode sit ttl 64 ifconfig v6_sol8 up route add -A inet6 3ffe:400:380:1234::1 dev v6_sol8 echo 1 >/proc/sys/net/ipv4/ip_forward echo 1 >/proc/sys/net/ipv6/conf/all/forwarding ;; stop) echo -n "Stopping v6:" ifconfig v6_6bone down ifconfig v6_sol8 down ifconfig eth1 del 3ffe:400:380::1 ;; status) iptunnel /usr/inet6/bin/ping -q -c 1 -a inet6 3ffe:400:380::1 /usr/inet6/bin/ping -q -c 1 -a inet6 3ffe:400:380:1234::1 ;; *) echo "Usage: (start|stop|status)" esac what I see on this interface of data: proto src-addr src-port dest-addr dest-port size if IPV6 206.191.192.57 0 62.52.79.1 0 112 v6_sol8 The linux configuration of the tunnel works with 3 other tunnels not mentioned above. Any ideas or advices what's wrong? Gruss/Regards, Thomas Thomas Kuiper | tkuiper@tobit.com | www.tobit.com __ Core Development | TK3680-RIPE | /__/\ Tobit Software GmbH | ICQ #8345483 | ask your server. \__\/ To: ipng@sunroof.eng.sun.com 6bone@isi.edu --------------1DD2510B41FE-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 12:25:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFKLhS24081 for ipng-dist; Wed, 15 Dec 1999 12:21:43 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFKLTY24071 for ; Wed, 15 Dec 1999 12:21:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA12990 for ; Wed, 15 Dec 1999 12:21:27 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01757 for ; Wed, 15 Dec 1999 13:21:25 -0700 (MST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id 3C3D4151FE5; Wed, 15 Dec 1999 14:21:25 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id F2DD1148506; Wed, 15 Dec 1999 14:21:24 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id BCF7BBC4CB; Wed, 15 Dec 1999 14:21:17 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id 50846B2A42; Wed, 15 Dec 1999 14:21:17 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000012510; Wed, 15 Dec 1999 15:21:23 -0500 (EST) From: Jim Bound Message-Id: <199912152021.PAA0000012510@quarry.zk3.dec.com> To: Carl Williams Cc: bound@zk3.dec.com, mccann@zk3.dec.com, itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: sockaddr_storage issue In-reply-to: Your message of "Tue, 14 Dec 1999 23:28:17 PST." <199912150728.XAA18029@antley.eng.sun.com> Date: Wed, 15 Dec 1999 15:21:22 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Carl, >The XNET document has other changes that we should >also adopt with RFC2553bis (e.g., dealing with error codes >returned by getnameinfo()). If the documents are not in sync, >then we will have varying implementations (not good for IPv6 >adoption). The KAME folks don't have access to the XNET documents >and have no idea what changes we made to getaddrinfo() a few months >back. Indeed, there were a number of substantial changes made to the >IPv6 socket API within the Open Group. Yes we have to pick up the continued work from the xnet docs. Also you give the exact reason why we must have an RFC2553bis. So I for one agree with you. >>> 1. Deprecate getipnodebyname > > >What about an applicability statement instead. Unlike gethostbyname2() >there is alot more code and porting documents making use of >getipnodebyname(). I am not sure it is a good idea to banish it >from the RFC as we did for gethostbyname2()? Sure and I think we all agreed to do that. I am using slang here by saying its shot in the head. Bottom line is I know of no ISV that will use getipnodebyname if I also tell them that it won't work with scope_ids. >>> 2. Make sure functionality and flags from getipnodebyname are supported >>> in getaddrinfo. > >I have given this thought (e.g., support of AI_ADDRCONFIG, AI_DEFAULT, AI_ALL >and AI_V4MAPPED as new flag settings for getaddrinfo()). >We need to detail the behavior when any of these flags are specified >with the various ai_family definitions (PF_UNSPEC, PF_INET, PF_INET6,...). >All the possible return error values need to be documented as well. >I can send out a proposed specification. That would be great carl. Do you wan to take a stab at the applicability statement above too? >Finally, it was noted that the sin6_scope_id is under specified (RFC2553). >For example, Erik raised the issue of what should the semantics be when >sin6_scope_id is set in a bind()? (and other issues). Should these >clarifications be a separate I-D and then XNET could take the new RFC into >account when clarifying their specifications? The reason we are in trouble now with getipnodebyname is because we left it as an exercise for later to deal with scope_ids. I don't think we should do that again. Yes we need to specify all cases we can think of now. I also believe XNET should be very much part of the update to this next iteration. So my plan is to include them in the review and input period and they are part of consensus for this effort. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 12:27:49 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBFKQTw24124 for ipng-dist; Wed, 15 Dec 1999 12:26:29 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBFKQJY24117 for ; Wed, 15 Dec 1999 12:26:19 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA24133 for ; Wed, 15 Dec 1999 12:26:17 -0800 (PST) Received: from mailext12.compaq.com (mailext12.compaq.com [207.18.199.188]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28222 for ; Wed, 15 Dec 1999 12:26:17 -0800 (PST) Received: by mailext12.compaq.com (Postfix, from userid 12345) id 7BB1757830; Wed, 15 Dec 1999 14:26:16 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext12.compaq.com (Postfix) with ESMTP id 76CF754601; Wed, 15 Dec 1999 14:26:16 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 566A0BC4C8; Wed, 15 Dec 1999 14:26:09 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id EAD7EB2A43; Wed, 15 Dec 1999 14:26:08 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id PAA0000012827; Wed, 15 Dec 1999 15:26:15 -0500 (EST) From: Jim Bound Message-Id: <199912152026.PAA0000012827@quarry.zk3.dec.com> To: Thomas Narten Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-site-prefixes In-reply-to: Your message of "Wed, 15 Dec 1999 06:33:39 EST." <199912151133.GAA00593@hygro.adsl.duke.edu> Date: Wed, 15 Dec 1999 15:26:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> But there is no consensus that users should be putting site-locals in >> DNS at this point and that is still a point of contention on the WG list >> as I see it. >Folks will put site-locals in the DNS. Saying they should not won't >stop them. What would be useful is some documentation discussing the >issues of doing so (like two-faced DNS so that the outside world >doesn't see such addresses), etc., and of course any specific >recommendations we think are in order. Agreed. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Dec 15 23:05:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBG72wn24635 for ipng-dist; Wed, 15 Dec 1999 23:02:58 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBG72nY24628 for ; Wed, 15 Dec 1999 23:02:50 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA23726 for ; Wed, 15 Dec 1999 23:02:47 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA13466 for ; Thu, 16 Dec 1999 00:02:46 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id PAA10087 for ; Thu, 16 Dec 1999 15:52:09 +0900 (JST) Date: Thu, 16 Dec 1999 16:04:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-Reply-To: In your message of "Fri, 10 Dec 1999 20:13:29 +0900" References: <199912100944.KAA24477@givry.inria.fr> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 108 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 10 Dec 1999 20:13:29 +0900, >>>>> JINMEI Tatuya said: >> PS: the textual address thread has not yet reached a concensus about >> the exact syntax... > I know. Sorry for the delay, but we're now locally discussing the > syntax in KAME and will soon propose a (new) one in this list. Here is our current consensus. (Note: in the following text, I'll use the term "a zone ID" as the identifier of a specific instance of a scope. But I don't have a strong opinion about the name of the ID. Maybe we should define an appropriate standard term in another place.) 1. Should the delimiter be placed before an address or after an address? We prefer "after an address", because - we'd like to allow a user to omit a zone ID (and the delimiter) if it is obvious (e.g. in a single-interface host). If this makes sense, a textual address would be more readable if the address always begins with "address part". (But we may be biassed in this point due to our own implementation experience.) - As I said in my earlier mail, I'm not sure if zone IDs should be considered as the most significant part of scoped addresses. I'll cite the mail. >>>>> On Thu, 28 Oct 1999 01:26:49 +0900, >>>>> JINMEI Tatuya said: > Is it so obvious that the scope_id part is the most significant part? > I'm not sure. It seems to me that we could recognize (for example) a > link-local address as follows: > 1. Look at the 1st 16 (or at least 10) bits of the address (fe80) and > recognize that this is a link-local address. i.e. this is the most > significant part. > 2. Then look at the scope identifier and recognize to which link the > address should belong. (In this scenario, the scope id is the 2nd > significant part) > 3. Finally use the host id part of the address (i.e. the last 64 bits) > to identify the node that the address specifies in the link. > So I feel the appropriate portion for the scope_id is subtle. However, > I don't stick to the idea that the scope id should be after an > address. I'd respect others' opinions. Though I stated our opinion, we won't stick to the idea. We're willing to follow a consensus when we implementors get one. 2. Which charater (or strings) is the best as the delimiter? We prefer a symbol character (i.e. not an alphabet character or a word) for readability, and have considered several characters. However, (as you can easily imagine:-), we've not got a consensus on a specific character or a strings suitable to the delimiter. Each character has its pros and cons. So I'll just show our current consideration. The following characters may need be escaped, especially in UNIX-like systems (so they're not suitable as the delimiter). !$&*(){}[];'\"<>?` As for other characters... #: used as the start symbol of a comment line in some script languages and configuration files (e.g. /etc/hosts in UNIX-like systems). =: used as the reserved symbol for variable substitution in some script languages. @: used as the delimiter in contexts like "user_name@host_name". used to show source routing in the (traditional) telnet command. .^+: maybe used in a regular expression. -: used in DNS labels (but Do we have to care about DNS labels?). %: used in an e-mail address to specifiy source-routing. (But it would be very rare...do we have to care about such cases?) _~,: maybe safe to avoid conflicts, but does not look "like the delimiter"(?) :(itself): used in IPv6 textual addresses. I personally feel "%" is not so bad, but I'd like to know other implementors' opinions for now. Maybe we need a compromise on this point; there'll be no "perfect" character. 3. What is the appropriate synatx for zone IDs? Numeric identifiers must be provided. Also, if the system provide interface names (like `le0' or `etherne1'), the names may be used as (non-numeric) identifiers. Interface names In any case, zone IDs should be composed by numbers and alphabetical characters only (i.e. without special characters). So for example, my current preferred format is as follows: fe80::1234%1 (which specifies a link-local address whose link identifier is 1.) fe80::abcd%ne0 (which specifies a link-local address whose link identifer is designated by the interface "ne0".) That's all. I'd appreciate any comments or suggestions and be glad if we'd be able to make a consensus and define a standard (unified) format. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 16 01:08:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBG94uT24679 for ipng-dist; Thu, 16 Dec 1999 01:04:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBG94mY24672 for ; Thu, 16 Dec 1999 01:04:48 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA00503; Thu, 16 Dec 1999 01:04:46 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA12698; Thu, 16 Dec 1999 01:04:45 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA20167; Thu, 16 Dec 1999 10:04:40 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id KAA00921; Thu, 16 Dec 1999 10:04:39 +0100 (MET) Message-Id: <199912160904.KAA00921@givry.inria.fr> From: Francis Dupont To: Erik Nordmark cc: Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-reply-to: Your message of Tue, 14 Dec 1999 09:40:43 PST. Date: Thu, 16 Dec 1999 10:04:37 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Well, sure enough it does: > > However, packets addressed to the mobile node's link-local address > MUST NOT be tunneled to the mobile node. [...] > > I think it could work; there are certainly tricky aspects but it is quite > similar to the site-local case. Yes, I think it could be made to work. => I don't believe it is reasonnable because this will make mobility and ND interaction very hairy, for instance when the mobile comes back at home it needs to send a home deregistration to the home agent which is a neighbor but doesn't know this fact. In current specs the simplest way to solve this issue is to send the home deregistration packet from a link-local source with a CoA extension. But that would raise some security issues as well as traffic issues. For instance, if you tunnel the router advertisements (which are sent to link-local addresses) does that mean that the mobile host away from home should trust the unauthenticated router advertisement just because it has an encapsulating IP header? The current scheme in the mobile ipv6 spec is to explicitly relay important changes in router advertisements but those packets must be authenticated. => I agree, the issue is attacks can come from everywhere, not only from a node connected directly on the link (ie. mobility can defeat the protection from 255 hop limit and forwarding rules). Also, folks have raised the issues that when away from home you probably don't want to receive every link-local packet (like the "beacon" router advertisements which are sent every second or so, and presumably the random DAD packets etc) when you are far away on a potentially slow link. Instead the home agent will proxy for the mobile. => I think most of us would like to restrict link-local addresses to special usages like ND and there is not proposal to add a trick in the API in order to implement the draft-ietf-ipngwg-site-prefixes ideas for link-locals then I can't see a good reason to change the current "MUST NOT" in the mobility draft. Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 16 05:54:36 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBGDpoj24905 for ipng-dist; Thu, 16 Dec 1999 05:51:50 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBGDpfY24898 for ; Thu, 16 Dec 1999 05:51:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA12301 for ; Thu, 16 Dec 1999 05:51:41 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18853 for ; Thu, 16 Dec 1999 06:51:38 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id OAA00697; Thu, 16 Dec 1999 14:51:28 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id OAA01904; Thu, 16 Dec 1999 14:51:28 +0100 (MET) Message-Id: <199912161351.OAA01904@givry.inria.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-reply-to: Your message of Thu, 16 Dec 1999 16:04:43 +0900. Date: Thu, 16 Dec 1999 14:51:11 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1. Should the delimiter be placed before an address or after an address? We prefer "after an address", because ... => I agree 2. Which charater (or strings) is the best as the delimiter? I personally feel "%" is not so bad, but I'd like to know other implementors' opinions for now. => % is used by Cshell for job control and must be quoted... My favorite list is in order ~ (no known problem), % then @ (@ is the more "natural" but is too overloaded yet: @ is too good :-). Maybe we need a compromise on this point; there'll be no "perfect" character. => none is the ASCII character set (:-). 3. What is the appropriate synatx for zone IDs? Numeric identifiers must be provided. Also, if the system provide interface names (like `le0' or `etherne1'), the names may be used as (non-numeric) identifiers. => I agree. We should have a standard name for the name to value tool (function(s), DB file, ...) if we add other names than interface names (which will be a good thing for links or sites). That's all. I'd appreciate any comments or suggestions and be glad if we'd be able to make a consensus and define a standard (unified) format. => we should have one soon (your Christmas gift?) Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 16 08:23:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBGGLAD24965 for ipng-dist; Thu, 16 Dec 1999 08:21:10 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBGGL0Y24958 for ; Thu, 16 Dec 1999 08:21:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA08317 for ; Thu, 16 Dec 1999 08:21:00 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02752 for ; Thu, 16 Dec 1999 09:20:54 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA11639; Fri, 17 Dec 1999 01:09:56 +0900 (JST) Date: Fri, 17 Dec 1999 01:22:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: snap-users@kame.net, 6bone-jp@wide.ad.jp, v6@wide.ad.jp, IPv6-jp@jp.freebsd.org Cc: ipng@sunroof.eng.sun.com Subject: transition from RFC2292 to 2292bis User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 56 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To KAME users, especially to those who develop applications on the KAME kernel: (I cc'ed this mail to the ipng ML for those who are intersted in implementing rfc2292bis, but I apologize in advance if it's too noisy.) I've started implementing the new advanced API in KAME according to . Though the specification is still an internet-draft (i.e. not an RFC yet), I believe we should eventually move to the new API since it reflects recent changes and operational experiences of IPv6. However, one big problem of 2292bis is that it does not ensure complete backward compatibility with RFC2292. For example, the semantics of the IPV6_PKTINFO socket option is changed: In RFC2292, the option takes an integer as an argument, and its value is a switch of whether or not the kernel should pass the receiving interface and the destination address of incoming packets to the application. In 2292bis, the option takes an in6_pktinfo strucutre as an argument, and the structure specifies the source address and/or the outgoing interface of outgoing packets. The option does not have any meaning for incoming packets. If you need information of incoming packets, you should use a separate option IPV6_RECVPKTINFO. (Unfortunately) it doesn't seem (at least to me) very easy to support both semantics in a single code base. Although we could introduce a trick like `#ifdef COMPAT_RFC2292', the result would make the kernel code very complicated and we would have hard time to maintain the code. So my question to developers is: Basically I'd like to discard the old API and concentrate on the new one, but it may force you to adjust your applications to 2292bis. Do you mind if we take such an approach? If so, which part of the old API do you want to remain? If there is some parts of the old API that several people want to keep, I'll try to keep them. Otherwise, I'll discard the entire old API if it conflicts with new one. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. FYI: The semantics of (at least) the following socket options is changed in 2292bis: IPV6_PKTINFO, IPV6_HOPLIMIT, IPV6_RTHDR, IPV6_HOPOPTS, and IPV6_DSTOPTS. If you use these options according to the semantics of RFC2292, you'll have to adjust your code when we discard the old (RFC2292) behavior. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 16 09:11:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBGH84W25036 for ipng-dist; Thu, 16 Dec 1999 09:08:04 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBGH7tY25029 for ; Thu, 16 Dec 1999 09:07:55 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA05911 for ; Thu, 16 Dec 1999 09:07:54 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28313 for ; Thu, 16 Dec 1999 09:07:54 -0800 (PST) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA10266; Thu, 16 Dec 1999 09:07:03 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: References: <199912100944.KAA24477@givry.inria.fr> Date: Thu, 16 Dec 1999 09:07:41 -0800 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: Scope ID secret Cabal (minutes) Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:04 PM +0900 12/16/99, JINMEI Tatuya wrote: >1. Should the delimiter be placed before an address or after an > address? > >We prefer "after an address", because... That is my preference too, but not a strongly held one. >2. Which charater (or strings) is the best as the delimiter? Of the single character. non-alphanumeric choices you listed, I think I prefer "-" or "_". How about a double-character approach, like: fe80::1234//3 or fe80::1234//ether1 It's too bad all the bracketing characters are off limits, because something like: fe80::1234(3) or fe80::1234(ether1) or fe80::1234<3> or fe80::1234 would be a nice way to add the zone number/name qualifier. Are "<" and ">" really a problem if they appear within a token and not at the beginning of a token? Or maybe the "/" character could be used in a bracketing way, like: fe80::1234/3/ or fe80::1234/ether1/ >3. What is the appropriate synatx for zone IDs? > >In any case, zone IDs should be composed by numbers and alphabetical >characters only (i.e. without special characters). Sounds right, though you may want to allow ".", "-", and/or "_" as part of the zone name. 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 Dec 16 09:55:45 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBGHppd25087 for ipng-dist; Thu, 16 Dec 1999 09:51:52 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBGHpfY25080 for ; Thu, 16 Dec 1999 09:51:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA13515 for ; Thu, 16 Dec 1999 09:51:39 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA29827 for ; Thu, 16 Dec 1999 10:51:37 -0700 (MST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 Dec 1999 09:51:35 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Dec 1999 09:51:34 -0800 Message-ID: <3D2036E25376D31197A100805FEAD892712F80@RED-MSG-02> From: Brian Zill To: "'JINMEI Tatuya / ????'" , ipng@sunroof.eng.sun.com Subject: RE: Scope ID secret Cabal (minutes) Date: Thu, 16 Dec 1999 09:51:26 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. Should the delimiter be placed before an address or after an > address? > > We prefer "after an address", because We prefer before an address because: 1) People already put other things after an address, like "/64" to indicate that it's a prefix of some length, or @23 to indicate a port number. 2) I believe a scope id is logically the most significant part of an address, and IPv6 addresses are inherently big-endian. As for your reasons for putting it before: > - we'd like to allow a user to omit a zone ID (and the delimiter) if > it is obvious (e.g. in a single-interface host). You can do this just fine regardless of where the scope id is. It's just as readable either way. I don't think this matters. > - As I said in my earlier mail, I'm not sure if zone IDs should be > considered as the most significant part of scoped addresses. We'll just have to disagree on that one. > 2. Which charater (or strings) is the best as the delimiter? > > We prefer a symbol character (i.e. not an alphabet character > or a word) for readability, and have considered several > characters. I think the important conflicts to worry about are the ones where something using one of those characters is a legal value for an address, or a common string that contains an address. So I think ":", "@", and "-" are out. Personally, I like "/", since it is already used (when placed at the end of an address) to indicate a prefix length, so people are already familiar with the situations in which they need to quote it. Thus 3/fe80::200:86ff:fe39:40e9 would be interface #3 on my laptop here. > 3. What is the appropriate synatx for zone IDs? > > Numeric identifiers must be provided. Also, if the system provide > interface names (like `le0' or `etherne1'), the names may be used as > (non-numeric) identifiers. > In any case, zone IDs should be composed by numbers and alphabetical > characters only (i.e. without special characters). Works for me. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 16 10:22:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBGIHNO25134 for ipng-dist; Thu, 16 Dec 1999 10:17:23 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBGIHCY25127 for ; Thu, 16 Dec 1999 10:17:13 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA313429; Thu, 16 Dec 1999 10:17:10 -0800 (PST) Date: Thu, 16 Dec 1999 10:16:52 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Scope ID secret Cabal (minutes) To: Francis Dupont Cc: Erik Nordmark , Richard Draves , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199912160904.KAA00921@givry.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, I think it could be made to work. > > => I don't believe it is reasonnable because this will make mobility and I don't think it is reasonable either for the security reasons if nothing else. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 17 13:08:40 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBHL48C26216 for ipng-dist; Fri, 17 Dec 1999 13:04:08 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBHL43Y26209 for ; Fri, 17 Dec 1999 13:04:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA23781 for ipng@sunroof.eng.sun.com; Fri, 17 Dec 1999 13:03:22 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBHJM1Y26138 for ; Fri, 17 Dec 1999 11:22:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA26379 for ; Fri, 17 Dec 1999 11:22:00 -0800 (PST) From: thomas.kuiper@tobit.com Received: from mail.tobit.com (tobit.com [62.52.80.126]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA17403 for ; Fri, 17 Dec 1999 11:21:58 -0800 (PST) Message-Id: <199912171921.LAA17403@venus.Sun.COM> Subject: FYI: IRCNet IPv6 IRC-server (eu.irc6.net) via 6bone To: ipng@sunroof.eng.sun.com Date: 17 Dec 99 19:21:59 UT X-Priority: 3 (Normal) Importance: normal X-Mailer: David by Tobit Software, Germany (PM-6.00a (0163)) X-David-Sym: 0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1DD2510B41FE" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------1DD2510B41FE Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable for your information. -------- Original Message -------- Subject: New IPv6 IRC-server (irc6.net) (16-DEC-1999 17:44) From: viha@populo.vip.fi To: ircnet@irc.org Okay. Time to celebrate (or at least a darn good excuse to do so): eu.irc6.net has finally been linked. The server is open to everyone participating on the 6BONE (IPv6). Most of the initial trouble seem to be over, but I'd never be surprised of a little down- time. Routes available (from /MOTD *.irc6.net): - irc6.net (6667, 7777) via 6BONE - eu-fi <-> 3ffe:2610:1:ff10:0:0:0:2 (Primary) - eu-de <-> 3ffe:400:380:c001:0:0:0:1 (Backup) - eu-f6 <-> 3ffe:b00:c18:1fff:0:0:0:4f (Backup) Maybe we'll some day move about to the real ARIN/RIPE-allocations. Regards, - Ville/viha@ircnet.org (The IRC6 Project) --------------1DD2510B41FE-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 17 17:08:46 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBI12mD26467 for ipng-dist; Fri, 17 Dec 1999 17:02:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBI12dY26460 for ; Fri, 17 Dec 1999 17:02:40 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA19002 for ; Fri, 17 Dec 1999 17:02:39 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA26975 for ; Fri, 17 Dec 1999 17:02:39 -0800 (PST) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 17 Dec 1999 17:02:37 -0800 (Pacific Standard Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2650.21) id ; Fri, 17 Dec 1999 17:02:17 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA2187E@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: API suggestion Date: Fri, 17 Dec 1999 17:02:09 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since there's been some mail recently about getaddrinfo and new flags... based on some recent experience porting code to use getaddrinfo, I'd suggest adding a flag that says return only IP addresses, either AF_INET or AF_INET6 but not other address families. And ideally there would also be a "sockaddr_ip" that was a union of sockaddr_in and sockaddr_in6 and in particular gave easy access to the port field. The reason being, that is was easier to port code to getaddrinfo while maintaining the assumption that addresses have a port field, instead of truly making the code address/protocol-independent. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Dec 19 18:53:10 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBK2lfe27451 for ipng-dist; Sun, 19 Dec 1999 18:47:41 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBK2lWY27444 for ; Sun, 19 Dec 1999 18:47:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA21199 for ; Sun, 19 Dec 1999 18:47:32 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA10582 for ; Sun, 19 Dec 1999 19:47:31 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id LAA21885; Mon, 20 Dec 1999 11:37:01 +0900 (JST) Date: Mon, 20 Dec 1999 11:50:42 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-Reply-To: In your message of "Thu, 16 Dec 1999 09:07:41 -0800" References: <199912100944.KAA24477@givry.inria.fr> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 58 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Dec 1999 09:07:41 -0800, >>>>> Steve Deering said: >> 2. Which charater (or strings) is the best as the delimiter? > Of the single character. non-alphanumeric choices you listed, > I think I prefer "-" or "_". Okay. > How about a double-character approach, like: > fe80::1234//3 or fe80::1234//ether1 It would be a possible way. In fact, we discussed possibility of using ":::" or ".." as delimiter. I didn't mentioned them in my previous mail just for simplicity, but we may have to consider them as well. (However, I don't think '/' is a good character even if it was used as a double-character, since '/' is used for a preifix.) > It's too bad all the bracketing characters are off limits, because > something like: > fe80::1234(3) or fe80::1234(ether1) > or > fe80::1234<3> or fe80::1234 > would be a nice way to add the zone number/name qualifier. Are "<" > and ">" really a problem if they appear within a token and not at the > beginning of a token? Okay, there is no reason to eliminate bracketing characters. > Or maybe the "/" character could be used in a bracketing way, like: > fe80::1234/3/ or fe80::1234/ether1/ Yes, it could, though I still suspect '/' isn't a good character for this purpose. >> 3. What is the appropriate synatx for zone IDs? >> >> In any case, zone IDs should be composed by numbers and alphabetical >> characters only (i.e. without special characters). > Sounds right, though you may want to allow ".", "-", and/or "_" as part > of the zone name. Okay, it seems reasonable. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Dec 19 18:56:23 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBK2svU27469 for ipng-dist; Sun, 19 Dec 1999 18:54:57 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBK2sXY27462 for ; Sun, 19 Dec 1999 18:54:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA28066 for ; Sun, 19 Dec 1999 18:53:47 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA12785 for ; Sun, 19 Dec 1999 19:53:30 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id LAA21901; Mon, 20 Dec 1999 11:42:51 +0900 (JST) Date: Mon, 20 Dec 1999 11:56:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis.Dupont@inria.fr Cc: ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-Reply-To: In your message of "Thu, 16 Dec 1999 14:51:11 +0100" <199912161351.OAA01904@givry.inria.fr> References: <199912161351.OAA01904@givry.inria.fr> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Dec 1999 14:51:11 +0100, >>>>> Francis Dupont said: > 2. Which charater (or strings) is the best as the delimiter? > I personally feel "%" is not so bad, but I'd like to know other > implementors' opinions for now. > => % is used by Cshell for job control and must be quoted... Yes, but only few commands use the character for job control (e.g. 'fg', 'bg' and 'kill'). I don't think it practically matters... > My favorite list is in order ~ (no known problem), % then @ > (@ is the more "natural" but is too overloaded yet: @ is too good :-). Okay. > That's all. I'd appreciate any comments or suggestions and be glad if > we'd be able to make a consensus and define a standard (unified) format. > => we should have one soon (your Christmas gift?) I hope so. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Dec 19 21:42:18 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBK5aoq27566 for ipng-dist; Sun, 19 Dec 1999 21:36:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBK5aeY27559 for ; Sun, 19 Dec 1999 21:36:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA26225 for ; Sun, 19 Dec 1999 21:36:39 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA07805 for ; Sun, 19 Dec 1999 22:36:36 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id OAA22523; Mon, 20 Dec 1999 14:25:49 +0900 (JST) Date: Mon, 20 Dec 1999 14:39:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Scope ID secret Cabal (minutes) In-Reply-To: In your message of "Mon, 20 Dec 1999 11:50:42 +0900" References: <199912100944.KAA24477@givry.inria.fr> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 35 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 20 Dec 1999 11:50:42 +0900, >>>>> JINMEI Tatuya said: > It would be a possible way. In fact, we discussed possibility of using > ":::" or ".." as delimiter. I didn't mentioned them in my previous > mail just for simplicity, but we may have to consider them as well. > (However, I don't think '/' is a good character even if it was used as > a double-character, since '/' is used for a preifix.) >> It's too bad all the bracketing characters are off limits, because >> something like: >> fe80::1234(3) or fe80::1234(ether1) >> or >> fe80::1234<3> or fe80::1234 >> would be a nice way to add the zone number/name qualifier. Are "<" >> and ">" really a problem if they appear within a token and not at the >> beginning of a token? > Okay, there is no reason to eliminate bracketing characters. I'd like to supplement the above line, since a colleague of mine cares. I just meant that we could consider the notion of bracketing characters as the delimiter. As for specific pairs, "()" or "<>" might not be suitable, because they have special meaning in UNIX shells. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Dec 19 23:28:27 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBK7NRb27628 for ipng-dist; Sun, 19 Dec 1999 23:23:27 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBK7N3Y27621 for ; Sun, 19 Dec 1999 23:23:04 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA20808 for ; Sun, 19 Dec 1999 23:22:15 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA23757 for ; Sun, 19 Dec 1999 23:22:08 -0800 (PST) Received: from localhost ([3ffe:501:100f:1048:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id QAA22874; Mon, 20 Dec 1999 16:11:24 +0900 (JST) Date: Mon, 20 Dec 1999 16:25:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bzill@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Scope ID secret Cabal (minutes) In-Reply-To: In your message of "Thu, 16 Dec 1999 09:51:26 -0800" <3D2036E25376D31197A100805FEAD892712F80@RED-MSG-02> References: <3D2036E25376D31197A100805FEAD892712F80@RED-MSG-02> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 84 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 16 Dec 1999 09:51:26 -0800, >>>>> Brian Zill said: >> 1. Should the delimiter be placed before an address or after an >> address? > We prefer before an address because: > 1) People already put other things after an address, like "/64" to indicate > that it's a prefix of some length, or @23 to indicate a port number. > 2) I believe a scope id is logically the most significant part of an > address, and IPv6 addresses are inherently big-endian. Okay. > As for your reasons for putting it before: >> - we'd like to allow a user to omit a zone ID (and the delimiter) if >> it is obvious (e.g. in a single-interface host). > You can do this just fine regardless of where the scope id is. It's just as > readable either way. I don't think this matters. Okay, "readable" may be a subjective (and inappropriate) word. >> - As I said in my earlier mail, I'm not sure if zone IDs should be >> considered as the most significant part of scoped addresses. > We'll just have to disagree on that one. Okay. I don't mind changing our implementation on this point, but I'd listen to others for a while. By the way, do you mind if we decide this by majority? Or do you think this is essential (and you can't compromise on this point in any way)? >> 2. Which charater (or strings) is the best as the delimiter? >> >> We prefer a symbol character (i.e. not an alphabet character >> or a word) for readability, and have considered several >> characters. > I think the important conflicts to worry about are the ones where something > using one of those characters is a legal value for an address, or a common > string that contains an address. So I think ":", "@", and "-" are out. (I'm not sure what conflict '-' has...DNS labels?, but) Okay, sounds reasonable. > Personally, I like "/", since it is already used (when placed at the end of > an address) to indicate a prefix length, so people are already familiar with > the situations in which they need to quote it. Is this really true and a merit? I can imagine that some applications have the following code: if ((c = strchr(ipv6prefix, '/')) == NULL) return(error); prefixlen = atoi(c + 1); *c = '\0'; prefixaddr = ipv6prefix; ... The execution of the code would fail when we give "4/fec0::/64" as the variable "ipv6prefix". Of course we could change such applications to accommodate them to the new syntax, but I'd personally prefer to avoid such overhead as much as possible. What do you think? >> 3. What is the appropriate syntax for zone IDs? >> >> Numeric identifiers must be provided. Also, if the system provide >> interface names (like `le0' or `etherne1'), the names may be used as >> (non-numeric) identifiers. >> In any case, zone IDs should be composed by numbers and alphabetical >> characters only (i.e. without special characters). > Works for me. Okay, thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 20 10:52:19 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBKImE627916 for ipng-dist; Mon, 20 Dec 1999 10:48:14 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBKIjTY27886; Mon, 20 Dec 1999 10:45:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA04500; Mon, 20 Dec 1999 10:45:28 -0800 (PST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10325; Mon, 20 Dec 1999 11:45:26 -0700 (MST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id KAA29238; Mon, 20 Dec 1999 10:45:19 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id KAA11406; Mon, 20 Dec 1999 10:45:18 -0800 (PST) Received: from tellurium (lan-isdn-cmj3.nsd.3com.com [129.213.207.235]) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id KAA12262; Mon, 20 Dec 1999 10:45:16 -0800 (PST) Message-Id: <3.0.2.32.19991220104003.00909580@mailhost.ewd.3com.com> X-Sender: cmj@mailhost.ewd.3com.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Mon, 20 Dec 1999 10:40:03 -0800 To: 6bone@isi.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU, deployment@ipv6.org From: Cyndi Jung Subject: UNH test in Telluride in March Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 implementors - The IPv6 Forum is having a series of conferences in various places around the world. The first was in Paris in October, the second one in Berlin in December, and the next one is in the US in March, and you can blame me that we are having it in Telluride, Colorado. I want very much to have a UNH test period in conjunction with the US Summit in Telluride, Colorado, March 13-15 - the test period would be March 15-17. I need to work this out with whatever testing is happening in Connect-a-thon - I need to start this NOW. Anyone that is interested should contact me via e-mail as soon as possible. I have been working with Bill Lenharth on this for a couple of months now, but I need you guys to show a measureable interest NOW - committment can come at a later date, but an initial head count for interest is a critical thing NOW - just respond to this if you even just think it could happen. Also, IPv6 has been selected as a showcase technology for the iLabs booth in the Las Vegas 2000 Networld+Interop. Perhaps this can drive the focus of the UNH testing in Telluride. Cyndi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 20 16:34:15 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBL0Umn28447 for ipng-dist; Mon, 20 Dec 1999 16:30:48 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBL0UiY28440 for ; Mon, 20 Dec 1999 16:30:44 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id QAA25304 for ipng@sunroof.eng.sun.com; Mon, 20 Dec 1999 16:30:02 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBKNjVY28392 for ; Mon, 20 Dec 1999 15:45:32 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA01165 for ; Mon, 20 Dec 1999 15:45:31 -0800 (PST) Received: from fep02-svc.mail.telepac.pt (fep02-svc.mail.telepac.pt [194.65.5.201]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25587 for ; Mon, 20 Dec 1999 15:45:26 -0800 (PST) Received: from mop35705 ([212.55.168.89]) by fep02-svc.mail.telepac.pt (InterMail v4.01.01.02 201-229-111-106) with SMTP id <19991220234120.VZMS10720.fep02-svc@mop35705> for ; Mon, 20 Dec 1999 23:41:20 +0000 Message-ID: <001101bf4b44$01018780$59a837d4@mop35705.telepac.pt> From: "Jorge Sa' Silva" To: Subject: IPv6 multicast address Date: Mon, 20 Dec 1999 23:43:22 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01BF4B44.0062D680" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01BF4B44.0062D680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know how IPv6 manages an IP multicast addresses. Does it = send the message using a broadcast process? Does it use a translation = table? Thaks in advance Jorge ------=_NextPart_000_000E_01BF4B44.0062D680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I would like to know how IPv6 = manages an IP=20 multicast addresses. Does it send the message using a broadcast process? = Does it=20 use a translation table?
 
Thaks in advance
 
Jorge
------=_NextPart_000_000E_01BF4B44.0062D680-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 20 18:25:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBL2Mum28532 for ipng-dist; Mon, 20 Dec 1999 18:22:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBL2MlY28525 for ; Mon, 20 Dec 1999 18:22:47 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA18082 for ; Mon, 20 Dec 1999 18:22:46 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA09010 for ; Mon, 20 Dec 1999 18:22:45 -0800 (PST) Received: from localhost (condor.v6.kame.net [3ffe:501:4819:2000:2a0:24ff:fe66:1350]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id LAA25816; Tue, 21 Dec 1999 11:12:12 +0900 (JST) Date: Tue, 21 Dec 1999 11:25:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: jfsasilva@mail.telepac.pt Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 multicast address In-Reply-To: In your message of "Mon, 20 Dec 1999 23:43:22 -0000" <001101bf4b44$01018780$59a837d4@mop35705.telepac.pt> References: <001101bf4b44$01018780$59a837d4@mop35705.telepac.pt> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 20 Dec 1999 23:43:22 -0000, >>>>> "Jorge Sa' Silva" said: >
I would like to know how IPv6 manages an IP > multicast addresses. Does it send the message using a broadcast process? Does it > use a translation table?
IPv6 has a separate address block for multicasting (see RFC 2373). If you mean transmission of IPv6 multicast packets over specific media (e.g. Ethernet), you may want to see documentations of "IPv6 over XXX" like RFC2464 and RFC2467. For example, RFC2464 defines the mapping from IPv6 multicast addresses to ethernet addresses: 7. Address Mapping -- Multicast An IPv6 packet with a multicast destination address DST, consisting of the sixteen octets DST[1] through DST[16], is transmitted to the Ethernet multicast address whose first two octets are the value 3333 hexadecimal and whose last four octets are the last four octets of DST. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 1 1 0 0 1 1|0 0 1 1 0 0 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[13] | DST[14] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DST[15] | DST[16] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Dec 20 23:52:01 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBL7ng728645 for ipng-dist; Mon, 20 Dec 1999 23:49:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBL7nUY28638 for ; Mon, 20 Dec 1999 23:49:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id XAA26079 for ; Mon, 20 Dec 1999 23:49:31 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA14155 for ; Tue, 21 Dec 1999 00:49:29 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id QAA05757 for ; Tue, 21 Dec 1999 16:49:22 +0900 (JST) To: "'IPng List'" X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion References: <4D0A23B3F74DD111ACCD00805F31D8101CA2187E@RED-MSG-50> From: itojun@iijlab.net Date: Tue, 21 Dec 1999 16:49:22 +0900 Message-ID: <5755.945762562@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Since there's been some mail recently about getaddrinfo and new flags... >based on some recent experience porting code to use getaddrinfo, I'd suggest >adding a flag that says return only IP addresses, either AF_INET or AF_INET6 >but not other address families. And ideally there would also be a >"sockaddr_ip" that was a union of sockaddr_in and sockaddr_in6 and in >particular gave easy access to the port field. > >The reason being, that is was easier to port code to getaddrinfo while >maintaining the assumption that addresses have a port field, instead of >truly making the code address/protocol-independent. At least for 4.4BSD derived systems, "port" portion is located at same bits for sockaddr_in6 and sockaddr_in. I do not get why you need sockaddr_ip. struct addrinfo is tagged correctly with ai_family so there should be no trouble. Separately, we may need some function/macro that manipulates sockaddr, for: - comparing two sockaddrs at ease. family and length must match. i can think of: - address (and scope) match - port match - address (and scope) and port match - address (and scope) with certain prefix length match only. - masking address with prefix length. cmetz and francis wanted these. Does this solve your problem? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 07:09:39 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBLF79t28806 for ipng-dist; Tue, 21 Dec 1999 07:07:09 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBLF70Y28799 for ; Tue, 21 Dec 1999 07:07:00 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA26990 for ; Tue, 21 Dec 1999 07:07:00 -0800 (PST) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04249 for ; Tue, 21 Dec 1999 07:06:59 -0800 (PST) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-6) with ESMTP id AAA27443 for ; Wed, 22 Dec 1999 00:06:52 +0900 To: ipng@sunroof.eng.sun.com Subject: Re: API suggestion From: Hideaki YOSHIFUJI In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101CA2187E@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA2187E@RED-MSG-50> X-Mailer: Mew version 1.94 on XEmacs 20.4 (Emerald) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19991222000650Z.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Wed, 22 Dec 1999 00:06:50 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 70 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <4D0A23B3F74DD111ACCD00805F31D8101CA2187E@RED-MSG-50> (at Fri, 17 Dec 1999 17:02:09 -0800), Richard Draves says: > based on some recent experience porting code to use getaddrinfo, I'd suggest > adding a flag that says return only IP addresses, either AF_INET or AF_INET6 > but not other address families. ... Your suggestion (that you want to add new flag) is not generic solution and has drawbacks in 2 points at least: 1. you cannot specify other set of families. ex) IPv6 and IPv7 addresses are wanted, but I hate IPv4. 2. you cannot specify the order of items in answered list. ex) I want to get IPv4 first because throughputs of IPv4 connections are much better than that of IPv6 ones. Another aproach that I suggest, is to use multiple-hints that can query for multiple-families, multiple-socktypes and even multiple-flags answers like this: /* Sample code */ #include #include #include int main(int argc, char *argv[]){ struct addrinfo hints[2], *res0, *res; int gai; char *host, *serv; char buff[NI_MAXHOST]; host = (argc > 1) ? argv[1] : "localhost"; serv = (argc > 2) ? argv[2] : "80"; printf("host='%s', serv='%s'\n", host, serv); memset(&hints[0], 0, sizeof(hints[0])); hints[0].ai_family = PF_INET6 ; hints[0].ai_socktype = SOCK_STREAM; hints[0].ai_next = &hints[1]; memset(&hints[1], 0, sizeof(hints[1])); hints[1].ai_family = PF_INET; hints[1].ai_socktype = SOCK_STREAM; hints[1].ai_next = NULL; res = res0 = NULL; /* the order of items in the result list (res0) should be PF_INET6 -> PF_INET */ gai = getaddrinfo(host, serv, &hints[0], &res0); printf ("gai=%d (%s), res0=0x%X\n", gai, (gai ? gai_strerror(gai) : "OK"), res0); if (!gai){ for (res=res0; res; res=res->ai_next){ buff[0] = '\0'; getnameinfo(res->ai_addr, res->ai_addrlen, buff, sizeof(buff), NULL, 0, NI_NUMERICHOST); printf ("family=%d, socktype=%d, addr=%s\n", res->ai_family, res->ai_socktype, buff); } } if (res0) freeaddrinfo(res0); return (0); } -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 21 08:42:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBLGdlW29195 for ipng-dist; Tue, 21 Dec 1999 08:39:47 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBLGdcY29188 for ; Tue, 21 Dec 1999 08:39:38 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA28208 for ; Tue, 21 Dec 1999 08:39:38 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27187 for ; Tue, 21 Dec 1999 08:39:36 -0800 (PST) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.0) with ESMTP id BAA28946; Wed, 22 Dec 1999 01:25:54 +0900 (JST) Date: Wed, 22 Dec 1999 01:39:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: haberman@nortelnetworks.com Cc: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: updated PIM for IPv6 draft In-Reply-To: In your message of "Fri, 19 Nov 1999 16:07:05 -0500" <3835BBF9.1CCC1D9F@nortelnetworks.com> References: <3835BBF9.1CCC1D9F@nortelnetworks.com> User-Agent: Wanderlust/2.2.12 (Joyride) Emacs/20.5 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 42 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 19 Nov 1999 16:07:05 -0500, >>>>> "Brian Haberman" said: > The following was just submitted to the I-D editor. Comments to > the authors > or the mailing list. I have a question (comment) about PIM for IPv6. I'd apologize in advance since the question is not directly related to the draft, but I think it is important for the specification of IPv6 PIM and its interoperability. (Actually I sent the question to the PIM mailing list two months ago, but unfortunately I could get few answers and the issue was not clear. So I'll resend this here, but if there's more appropriate place to discuss it, please let me know.) The comment is about the checksum field of IPv6 PIM packets. The PIM specification in draft-ietf-pim-v2-sm-01 defines how to calculate the checksum as follows: Checksum The checksum is the 16-bit one's complement of the one's complement sum of the entire PIM message, (excluding the data portion in the Register message). For computing the checksum, the checksum field is zeroed. i.e. the checksum is calculated without a pseudo-IP header. However, I believe it should be calculated *with* a pseudo-IP header for IPv6 PIM packets, because IPv6 does not have an IP layer checksum and because PIM depends on some fileds of received IP packets (e.g. the source address field). If it's reasonable, I hope it will be described in a future version of the pim-ipv6 draft and/or the pim-v2 draft. What do you think? I'd appreciate any answers. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 09:50:44 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBLHmM529279 for ipng-dist; Tue, 21 Dec 1999 09:48:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBLHmDY29272 for ; Tue, 21 Dec 1999 09:48:13 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA09210 for ; Tue, 21 Dec 1999 09:48:12 -0800 (PST) Received: from smtprtp.ntcom.nortel.net (smtprtp.ntcom.nortel.net [137.118.22.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09808 for ; Tue, 21 Dec 1999 09:48:11 -0800 (PST) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Tue, 21 Dec 1999 12:47:36 -0500 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y695Y9JT; Tue, 21 Dec 1999 12:47:36 -0500 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id VZWDY8ZC; Tue, 21 Dec 1999 12:47:36 -0500 Message-ID: <385FBC94.F5B27045@nortelnetworks.com> Date: Tue, 21 Dec 1999 12:44:53 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: JINMEI@isl.rdc.toshiba.co.jp CC: pim@catarina.usc.edu, ipng@sunroof.eng.sun.com Subject: Re: updated PIM for IPv6 draft References: <3835BBF9.1CCC1D9F@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Your approach would be consistent with what OSPF for IPv6 does. The draft could be changed to require that change, but I would like some input from the working groups. Brian JINMEI Tatuya wrote: > >>>>> On Fri, 19 Nov 1999 16:07:05 -0500, > >>>>> "Brian Haberman" said: > > > The following was just submitted to the I-D editor. Comments to > > the authors > > or the mailing list. > > I have a question (comment) about PIM for IPv6. I'd apologize in > advance since the question is not directly related to the draft, but I > think it is important for the specification of IPv6 PIM and its > interoperability. > > (Actually I sent the question to the PIM mailing list two months ago, > but unfortunately I could get few answers and the issue was not > clear. So I'll resend this here, but if there's more appropriate > place to discuss it, please let me know.) > > The comment is about the checksum field of IPv6 PIM > packets. The PIM specification in draft-ietf-pim-v2-sm-01 defines how > to calculate the checksum as follows: > > Checksum > The checksum is the 16-bit one's complement of the one's > complement sum of the entire PIM message, (excluding the > data portion in the Register message). For computing the > checksum, the checksum field is zeroed. > > i.e. the checksum is calculated without a pseudo-IP header. However, I > believe it should be calculated *with* a pseudo-IP header for IPv6 PIM > packets, because IPv6 does not have an IP layer checksum and because > PIM depends on some fileds of received IP packets (e.g. the source > address field). > > If it's reasonable, I hope it will be described in a future version of > the pim-ipv6 draft and/or the pim-v2 draft. > > What do you think? I'd appreciate any answers. Thanks, > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -- Brian Haberman Advanced Network Research Nortel Networks haberman@nortelnetworks.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 Dec 21 10:36:29 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBLIYBC29386 for ipng-dist; Tue, 21 Dec 1999 10:34:11 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBLIY2Y29379 for ; Tue, 21 Dec 1999 10:34:02 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA22512 for ; Tue, 21 Dec 1999 10:34:02 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA08348 for ; Tue, 21 Dec 1999 10:34:00 -0800 (PST) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Dec 1999 10:33:59 -0800 (Pacific Standard Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Dec 1999 10:33:58 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA2188E@RED-MSG-50> From: Richard Draves To: "'Hideaki YOSHIFUJI'" Cc: ipng@sunroof.eng.sun.com Subject: RE: API suggestion Date: Tue, 21 Dec 1999 10:33:56 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > based on some recent experience porting code to use > getaddrinfo, I'd suggest > > adding a flag that says return only IP addresses, either > AF_INET or AF_INET6 > > but not other address families. ... > > Your suggestion (that you want to add new flag) is not > generic solution > and has drawbacks in 2 points at least: > > 1. you cannot specify other set of families. > ex) IPv6 and IPv7 addresses are wanted, but I hate IPv4. > 2. you cannot specify the order of items in answered list. > ex) I want to get IPv4 first because throughputs of IPv4 > connections > are much better than that of IPv6 ones. > > Another aproach that I suggest, is to use multiple-hints that > can query > for multiple-families, multiple-socktypes and even multiple-flags > answers like this: A problem with your suggestion is that the application is specifying whether it wants to get IPv4 addresses before IPv6 or vice-versa. This should not be up to the application, it should be controlled via some policy external to the application. But if you just allow multiple hints and not have the hint order constrain the returned address order... sounds like a promising idea. It's certainly general. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 11:06:53 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBLJ3o429436 for ipng-dist; Tue, 21 Dec 1999 11:03:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBLJ3cY29429 for ; Tue, 21 Dec 1999 11:03:39 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA29225 for ; Tue, 21 Dec 1999 11:03:33 -0800 (PST) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27162 for ; Tue, 21 Dec 1999 11:03:32 -0800 (PST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id NAA11296; Tue, 21 Dec 1999 13:03:26 -0600 (CST) Message-Id: <199912211903.NAA11296@gungnir.fnal.gov> To: "Jorge Sa' Silva" Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: IPv6 multicast address In-reply-to: Your message of Mon, 20 Dec 1999 23:43:22 GMT. <001101bf4b44$01018780$59a837d4@mop35705.telepac.pt> Date: Tue, 21 Dec 1999 13:03:22 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would like to know how IPv6 manages an IP multicast addresses. Does it > send the message using a broadcast process? Does it use a translation > table? If I understand your question correctly, you can find the answer in each document for "Transmission of IPv6 over ". For example, RFC 2464 for = Ethernet. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 21 11:27:24 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBLJP6H29465 for ipng-dist; Tue, 21 Dec 1999 11:25:06 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBLJOvY29458 for ; Tue, 21 Dec 1999 11:24:58 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA11402 for ; Tue, 21 Dec 1999 11:24:52 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA09420 for ; Tue, 21 Dec 1999 11:24:36 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id F3C4355C; Tue, 21 Dec 1999 14:22:51 -0500 (EST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id C36AB573; Tue, 21 Dec 1999 14:22:51 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000020851; Tue, 21 Dec 1999 14:22:51 -0500 (EST) From: Jim Bound Message-Id: <199912211922.OAA0000020851@quarry.zk3.dec.com> To: Richard Draves Cc: "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com Subject: Re: API suggestion In-reply-to: Your message of "Tue, 21 Dec 1999 10:33:56 PST." <4D0A23B3F74DD111ACCD00805F31D8101CA2188E@RED-MSG-50> Date: Tue, 21 Dec 1999 14:22:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >A problem with your suggestion is that the application is specifying whether >it wants to get IPv4 addresses before IPv6 or vice-versa. This should not be >up to the application, it should be controlled via some policy external to >the application. I don't agree. Applications moving to IPv6 should be able to have control over how they begin adopting IPv6. >But if you just allow multiple hints and not have the hint order constrain >the returned address order... sounds like a promising idea. It's certainly >general. Again I don't agree. Applications should be able to say I want all Mapped Addresses first, then I want pure IPv6 and then I want IPv4. Another application can reverse the order etc... This is the spirit of the present API and what we have implemented for ISVs now. My ISVs like this flexibility. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 11:46:52 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBLJiGH29511 for ipng-dist; Tue, 21 Dec 1999 11:44:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBLJi7Y29504 for ; Tue, 21 Dec 1999 11:44:08 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA03529 for ; Tue, 21 Dec 1999 11:44:06 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA22930 for ; Tue, 21 Dec 1999 11:44:06 -0800 (PST) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Dec 1999 10:28:09 -0800 (Pacific Standard Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Dec 1999 10:28:08 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA2188D@RED-MSG-50> From: Richard Draves To: "'itojun@iijlab.net'" Cc: "'IPng List'" Subject: RE: API suggestion Date: Tue, 21 Dec 1999 10:28:05 -0800 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At least for 4.4BSD derived systems, "port" portion is located > at same bits for sockaddr_in6 and sockaddr_in. > I do not get why you need sockaddr_ip. struct addrinfo > is tagged > correctly with ai_family so there should be no trouble. I was using sockaddr_storage variables that were holding either AF_INET or AF_INET6 addresses and I wanted to fetch/store the port field. So my choices were a) look at the family and cast to the right structure -> unnecessary code b) just cast to sockaddr_in without looking at family -> unpleasant assumptions I would have been happier using sockaddr_ip variables where I could directly access the port field without casting. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 17:08:34 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM161Q29777 for ipng-dist; Tue, 21 Dec 1999 17:06:01 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM15nY29770 for ; Tue, 21 Dec 1999 17:05:49 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA00361 for ; Tue, 21 Dec 1999 17:05:48 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01669 for ; Tue, 21 Dec 1999 17:05:47 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA20604; Wed, 22 Dec 1999 10:05:38 +0900 (JST) To: Richard Draves cc: "'IPng List'" In-reply-to: richdr's message of Tue, 21 Dec 1999 10:28:05 PST. <4D0A23B3F74DD111ACCD00805F31D8101CA2188D@RED-MSG-50> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion From: itojun@iijlab.net Date: Wed, 22 Dec 1999 10:05:38 +0900 Message-ID: <20602.945824738@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I was using sockaddr_storage variables that were holding either AF_INET or >AF_INET6 addresses and I wanted to fetch/store the port field. So my choices >were >a) look at the family and cast to the right structure -> unnecessary code >b) just cast to sockaddr_in without looking at family -> unpleasant >assumptions first of all you sholud not assume AF_INET or AF_INET6 in the above.... you should check family every time you make use of the sockaddr_storage. You can always define a union like: union sockaddr_union { struct sockaddr sa; struct sockaddr_in sin; struct sockaddr_in6 sin6; }; or, if port field is known to be on the same offset on your system: union sockaddr_union { struct { u_int8_t _len; u_int8_t _family; u_int16_t _port; } _su; #define su_port _su._port struct sockaddr sa; struct sockaddr_in sin; struct sockaddr_in6 sin6; }; to avoid casting. >I would have been happier using sockaddr_ip variables where I could directly >access the port field without casting. which API should return this structure, or which structure will convert normal sockaddr_{in,in6} to sockaddr_ip? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 18:05:54 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM23FO29802 for ipng-dist; Tue, 21 Dec 1999 18:03:15 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM234Y29795 for ; Tue, 21 Dec 1999 18:03:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA21637 for ; Tue, 21 Dec 1999 18:03:03 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27966 for ; Tue, 21 Dec 1999 19:03:01 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA21743; Wed, 22 Dec 1999 11:01:22 +0900 (JST) To: Jim Bound cc: Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Tue, 21 Dec 1999 14:22:51 EST. <199912211922.OAA0000020851@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion From: itojun@iijlab.net Date: Wed, 22 Dec 1999 11:01:22 +0900 Message-ID: <21741.945828082@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>A problem with your suggestion is that the application is specifying whether >>it wants to get IPv4 addresses before IPv6 or vice-versa. This should not be >>up to the application, it should be controlled via some policy external to >>the application. >I don't agree. Applications moving to IPv6 should be able to have >control over how they begin adopting IPv6. >>But if you just allow multiple hints and not have the hint order constrain >>the returned address order... sounds like a promising idea. It's certainly >>general. >Again I don't agree. >Applications should be able to say I want all Mapped Addresses first, >then I want pure IPv6 and then I want IPv4. Another application can >reverse the order etc... Could you tell me how your "flexibility" argument interact with src/dst address selection algorithm in getaddrinfo(3) (rich's draft)? What happens if they conflict with each other? Or, on certain platform, AI_PASSIVE lookup should return struct addrinfo in certain order to make sense, as the platform does not allow AF_INET bind after AF_INET6 bind, or vice versa. In my personal opinion putting policy-ish item in two or more places is not a good idea. I vote against hideaki's idea. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 18:11:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM2Aoi29820 for ipng-dist; Tue, 21 Dec 1999 18:10:50 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM2AeY29813 for ; Tue, 21 Dec 1999 18:10:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id SAA22439 for ; Tue, 21 Dec 1999 18:10:38 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA00071 for ; Tue, 21 Dec 1999 19:10:37 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA21925; Wed, 22 Dec 1999 11:09:00 +0900 (JST) To: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Wed, 22 Dec 1999 11:01:22 JST. <21741.945828082@coconut.itojun.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion From: itojun@iijlab.net Date: Wed, 22 Dec 1999 11:09:00 +0900 Message-ID: <21923.945828540@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Or, on certain platform, AI_PASSIVE lookup should return struct > addrinfo in certain order to make sense, as the platform does not > allow AF_INET bind after AF_INET6 bind, or vice versa. Note that there exists commercial product which does this behavior. (i.e. I'm not placing academic example) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 19:39:42 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM3bCr29900 for ipng-dist; Tue, 21 Dec 1999 19:37:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM3b2Y29893 for ; Tue, 21 Dec 1999 19:37:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA15494 for ; Tue, 21 Dec 1999 19:36:54 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA19675 for ; Tue, 21 Dec 1999 20:36:53 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA23437; Wed, 22 Dec 1999 12:36:41 +0900 (JST) To: Hideaki YOSHIFUJI cc: ipng@sunroof.eng.sun.com In-reply-to: yoshfuji's message of Wed, 22 Dec 1999 00:06:50 JST. <19991222000650Z.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion From: itojun@iijlab.net Date: Wed, 22 Dec 1999 12:36:41 +0900 Message-ID: <23435.945833801@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Another aproach that I suggest, is to use multiple-hints that can query >for multiple-families, multiple-socktypes and even multiple-flags >answers like this: If the granurality of flexibility is address family (i.e. you do not try to tweak about v4 mapped address, for example), you can always perform two lookup (two calls to getaddrinfo) to get the same result (you just need to append two lists). what is wrong with it? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 19:45:59 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM3j5B29923 for ipng-dist; Tue, 21 Dec 1999 19:45:05 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM3iuY29916 for ; Tue, 21 Dec 1999 19:44:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA29269 for ; Tue, 21 Dec 1999 19:44:56 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA21059 for ; Tue, 21 Dec 1999 20:44:55 -0700 (MST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id E0E73151F87; Tue, 21 Dec 1999 21:44:54 -0600 (CST) Received: from mailint12.im.hou.compaq.com (mailint12.compaq.com [207.18.199.190]) by mailext03.compaq.com (Postfix) with ESMTP id DBE33148506; Tue, 21 Dec 1999 21:44:54 -0600 (CST) Received: by mailint12.im.hou.compaq.com (Postfix, from userid 12345) id 53E694FB02; Tue, 21 Dec 1999 21:44:47 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint12.im.hou.compaq.com (Postfix) with ESMTP id D54B94C901; Tue, 21 Dec 1999 21:44:46 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000000100; Tue, 21 Dec 1999 22:44:53 -0500 (EST) From: Jim Bound Message-Id: <199912220344.WAA0000000100@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com Subject: Re: API suggestion In-reply-to: Your message of "Wed, 22 Dec 1999 11:01:22 +0900." <21741.945828082@coconut.itojun.org> Date: Tue, 21 Dec 1999 22:44:52 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > Could you tell me how your "flexibility" argument interact with > src/dst address selection algorithm in getaddrinfo(3) (rich's draft)? > What happens if they conflict with each other? Good question. How I view it as a product engineer is I will provide ISVs with the ability to directly request the exact address or set of addresses they want if the application requests that. So in a sense I would permit applications to shut off the defaults from src/dst addr selection and matching, of course with the health warnings that go with that decision. I will not force the market or applications to adopt our policies around APIs regardless what the IETF or XNET or anyone mandates there will always be an API back door. I also believe that is what we did with the flags in getipnodebyname. All we need to do is add the flags to getaddrinfo and there is no need for further discussion. How I get it to work with the src/dst algorithms we define is my problem and how I handle the conflict. Nothing we define should prevent this behavior and we have not at this time. All I have to say on this issue really. Call it added value. I assume your not against moving the flags from getipnodebyname to getaddrinfo from our API cabal meeting at Wash D.C.? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 19:52:37 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM3oMj29945 for ipng-dist; Tue, 21 Dec 1999 19:50:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM3oEY29938 for ; Tue, 21 Dec 1999 19:50:14 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA29627 for ; Tue, 21 Dec 1999 19:50:13 -0800 (PST) Received: from mailext03.compaq.com (mailext03.compaq.com [207.18.199.41]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA05289 for ; Tue, 21 Dec 1999 19:50:13 -0800 (PST) Received: by mailext03.compaq.com (Postfix, from userid 12345) id DFC28151FAC; Tue, 21 Dec 1999 21:50:12 -0600 (CST) Received: from mailint02.im.hou.compaq.com (mailint02.compaq.com [207.18.199.35]) by mailext03.compaq.com (Postfix) with ESMTP id D8FC2148506; Tue, 21 Dec 1999 21:50:12 -0600 (CST) Received: by mailint02.im.hou.compaq.com (Postfix, from userid 12345) id 4E90DBC4CE; Tue, 21 Dec 1999 21:50:05 -0600 (CST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by mailint02.im.hou.compaq.com (Postfix) with ESMTP id D63AEB2A43; Tue, 21 Dec 1999 21:50:04 -0600 (CST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000005687; Tue, 21 Dec 1999 22:50:11 -0500 (EST) From: Jim Bound Message-Id: <199912220350.WAA0000005687@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Hideaki YOSHIFUJI , ipng@sunroof.eng.sun.com Subject: Re: API suggestion In-reply-to: Your message of "Wed, 22 Dec 1999 12:36:41 +0900." <23435.945833801@coconut.itojun.org> Date: Tue, 21 Dec 1999 22:50:10 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, >>Another aproach that I suggest, is to use multiple-hints that can query >>for multiple-families, multiple-socktypes and even multiple-flags >>answers like this: > If the granurality of flexibility is address family (i.e. you do not > try to tweak about v4 mapped address, for example), > you can always perform two lookup (two calls to getaddrinfo) to > get the same result (you just need to append two lists). what is > wrong with it? I don't want my ISV apps to have to do two getaddrinfo queries. Just one and one big list with both families. This is pretty easy to implement and it works now with getipnodebyname as one example its AI_ALL. This functionality has been deployed already we must support it in the update to getaddrinfo. I know apps that use it now for IPv6. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 19:56:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM3tYA29967 for ipng-dist; Tue, 21 Dec 1999 19:55:34 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM3tOY29960 for ; Tue, 21 Dec 1999 19:55:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA07776 for ; Tue, 21 Dec 1999 19:55:23 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23236 for ; Tue, 21 Dec 1999 20:55:22 -0700 (MST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA23788; Wed, 22 Dec 1999 12:53:35 +0900 (JST) To: Jim Bound cc: Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Tue, 21 Dec 1999 22:44:52 EST. <199912220344.WAA0000000100@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion From: itojun@iijlab.net Date: Wed, 22 Dec 1999 12:53:35 +0900 Message-ID: <23786.945834815@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Good question. How I view it as a product engineer is I will provide >ISVs with the ability to directly request the exact address or set of >addresses they want if the application requests that. So in a sense I >would permit applications to shut off the defaults from src/dst addr >selection and matching, of course with the health warnings that go with >that decision. I will not force the market or applications to adopt our >policies around APIs regardless what the IETF or XNET or anyone >mandates there will always be an API back door. I also believe that is >what we did with the flags in getipnodebyname. All we need to do is add >the flags to getaddrinfo and there is no need for further discussion. >How I get it to work with the src/dst algorithms we define is my problem >and how I handle the conflict. Nothing we define should prevent this >behavior and we have not at this time. > >All I have to say on this issue really. Call it added value. Hmm, I see. Please be sure to state the backdoor as "this is backdoor, not standard". >I assume your not against moving the flags from getipnodebyname to >getaddrinfo from our API cabal meeting at Wash D.C.? correct. I'm okay with addition of AI_ADDRCONFIG and such (carl's proposal). Separate issue: AI_ADDRCONFIG does not seem very useful for me, as AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) configured on my host. In this case I will not be able to reach anyone outside via IPv6. We'd better have more text in 2553bis, that describes background/goal of AI_ADDRCONFIG. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 19:57:56 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM3v3b29985 for ipng-dist; Tue, 21 Dec 1999 19:57:03 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM3uoY29978 for ; Tue, 21 Dec 1999 19:56:50 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id TAA00080 for ; Tue, 21 Dec 1999 19:56:49 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA07514 for ; Tue, 21 Dec 1999 19:56:48 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id MAA23826; Wed, 22 Dec 1999 12:55:09 +0900 (JST) To: Jim Bound cc: Hideaki YOSHIFUJI , ipng@sunroof.eng.sun.com In-reply-to: bound's message of Tue, 21 Dec 1999 22:50:10 EST. <199912220350.WAA0000005687@quarry.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: API suggestion From: itojun@iijlab.net Date: Wed, 22 Dec 1999 12:55:09 +0900 Message-ID: <23824.945834909@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> If the granurality of flexibility is address family (i.e. you do not >> try to tweak about v4 mapped address, for example), >> you can always perform two lookup (two calls to getaddrinfo) to >> get the same result (you just need to append two lists). what is >> wrong with it? > >I don't want my ISV apps to have to do two getaddrinfo queries. Just >one and one big list with both families. This is pretty easy to >implement and it works now with getipnodebyname as one example its >AI_ALL. This functionality has been deployed already we must support it >in the update to getaddrinfo. I know apps that use it now for IPv6. I'm not sure I got your point... AI_ALL and Hideaki's proposal looks to be very separate for me. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 20:07:13 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM44TI00008 for ipng-dist; Tue, 21 Dec 1999 20:04:29 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM44KY29997 for ; Tue, 21 Dec 1999 20:04:21 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA20825 for ; Tue, 21 Dec 1999 20:04:20 -0800 (PST) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA10137 for ; Tue, 21 Dec 1999 20:04:18 -0800 (PST) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id 0345473E; Tue, 21 Dec 1999 23:04:17 -0500 (EST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id DF5AD474; Tue, 21 Dec 1999 23:04:17 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000006918; Tue, 21 Dec 1999 23:04:17 -0500 (EST) From: Jim Bound Message-Id: <199912220404.XAA0000006918@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com Subject: Re: API suggestion In-reply-to: Your message of "Wed, 22 Dec 1999 12:53:35 +0900." <23786.945834815@coconut.itojun.org> Date: Tue, 21 Dec 1999 23:04:15 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > Hmm, I see. Please be sure to state the backdoor as "this is > backdoor, not standard". The APIs are not "standards" but informational. But I agree, when the defaults are not used what happens must be documented. >>I assume your not against moving the flags from getipnodebyname to >>getaddrinfo from our API cabal meeting at Wash D.C.? > correct. I'm okay with addition of AI_ADDRCONFIG and such (carl's > proposal). OK thats cool. > Separate issue: AI_ADDRCONFIG does not seem very useful for me, as > AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) > configured on my host. In this case I will not be able to reach > anyone outside via IPv6. We'd better have more text in 2553bis, that > describes background/goal of AI_ADDRCONFIG. Agreed. Can you keep track of this one for us when we start re-writing the API? So we don't loose it in the flurry of email. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 20:10:30 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM48s300026 for ipng-dist; Tue, 21 Dec 1999 20:08:54 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM48jY00019 for ; Tue, 21 Dec 1999 20:08:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA08650 for ; Tue, 21 Dec 1999 20:08:44 -0800 (PST) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA26555 for ; Tue, 21 Dec 1999 21:08:44 -0700 (MST) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id ED30A436; Tue, 21 Dec 1999 23:08:33 -0500 (EST) Received: from quarry.zk3.dec.com (bryquarry.zk3.dec.com [16.141.40.15]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id D4A75728; Tue, 21 Dec 1999 23:08:33 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000007848; Tue, 21 Dec 1999 23:08:33 -0500 (EST) From: Jim Bound Message-Id: <199912220408.XAA0000007848@quarry.zk3.dec.com> To: itojun@iijlab.net Cc: Jim Bound , Hideaki YOSHIFUJI , ipng@sunroof.eng.sun.com Subject: Re: API suggestion In-reply-to: Your message of "Wed, 22 Dec 1999 12:55:09 +0900." <23824.945834909@coconut.itojun.org> Date: Tue, 21 Dec 1999 23:08:32 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm not sure I got your point... AI_ALL and Hideaki's proposal > looks to be very separate for me. Yes my mistake. I just want all addresses back from AI_ALL for AF_INET6 so I will get all native IPv6 addresses and all IPv4 addresses as Mapped. So do we need to discuss it further? But what about PF_UNSPEC ???? We did get input during base API discussion to return both families and that was rejected as a historical note. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 20:38:25 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM4aAN00046 for ipng-dist; Tue, 21 Dec 1999 20:36:10 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM4a1Y00039 for ; Tue, 21 Dec 1999 20:36:01 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id UAA10493 for ; Tue, 21 Dec 1999 20:36:00 -0800 (PST) Received: from bsdi.dv.isc.org (bsdi.dv.isc.org [130.155.191.233]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA20497 for ; Tue, 21 Dec 1999 20:35:58 -0800 (PST) Received: from isc.org (marka@localhost.dv.isc.org [127.0.0.1]) by bsdi.dv.isc.org (8.8.5/8.8.5) with ESMTP id PAA22627; Wed, 22 Dec 1999 15:33:39 +1100 (EST) Message-Id: <199912220433.PAA22627@bsdi.dv.isc.org> To: itojun@iijlab.net cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com From: Mark.Andrews@iengines.com Subject: Re: API suggestion In-reply-to: Your message of "Wed, 22 Dec 1999 12:53:35 +0900." <23786.945834815@coconut.itojun.org> Date: Wed, 22 Dec 1999 15:33:27 +1100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Separate issue: AI_ADDRCONFIG does not seem very useful for me, as > AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) > configured on my host. In this case I will not be able to reach > anyone outside via IPv6. We'd better have more text in 2553bis, that > describes background/goal of AI_ADDRCONFIG. Why isn't it useful? You may be looking up "localhost". The worst that will happen is you will get network unreachable when you try to connect / send. AI_ADDRCONFIG is an optimisation. I do however agree that AI_ADDRCONFIG and the error states than can result need to be better documented. Mark -- Mark Andrews, Internet Engines Inc. / Internet Software Consortium 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@iengines.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 Dec 21 21:38:08 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM5Zja00071 for ipng-dist; Tue, 21 Dec 1999 21:35:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM5ZZY00064 for ; Tue, 21 Dec 1999 21:35:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id VAA21915 for ; Tue, 21 Dec 1999 21:35:33 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA08673 for ; Tue, 21 Dec 1999 21:35:32 -0800 (PST) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id OAA25279; Wed, 22 Dec 1999 14:35:20 +0900 (JST) To: Mark.Andrews@iengines.com cc: ipng@sunroof.eng.sun.com In-reply-to: Mark.Andrews's message of Wed, 22 Dec 1999 15:33:27 +1100. <199912220433.PAA22627@bsdi.dv.isc.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: AI_ADDRCONFIG From: itojun@iijlab.net Date: Wed, 22 Dec 1999 14:35:20 +0900 Message-ID: <25277.945840920@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Separate issue: AI_ADDRCONFIG does not seem very useful for me, as >> AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) >> configured on my host. In this case I will not be able to reach >> anyone outside via IPv6. We'd better have more text in 2553bis, that >> describes background/goal of AI_ADDRCONFIG. > Why isn't it useful? You may be looking up "localhost". > The worst that will happen is you will get network unreachable > when you try to connect / send. AI_ADDRCONFIG is an optimisation. AI_ADDRCONFIG checks list of local addresses to determine which family to return. I'm not sure if it optimizes it. It highly depends on what kind of behavior the OS kernel takes. There can be several choices in design principle level: - getaddrinfo(3) is name resolution function, this should not change behavior based on what kernel supports, what configured onto my interfaces. getaddrinfo(3) can simply return anything it have resolved via DNS. socket(2) or connect(2) may fail, user application should make a loop over whatever getaddrinfo(3) returned. - getaddrinfo(3) should mask address families that are not supported by kernel, to save from unnecessary socket(2) in user code. - getaddrinfo(3) should mask address families that are not configured onto my interfaces. this is what AI_ADDRCONFIG does. rfc2553 does not really state which is the intended behavior. I'm not sure which is the best one. I'm not sure which is the way to go. Actually kame getaddrinfo(3) implements 2nd case, but I don't really think it to be a good solution. > I do however agree that AI_ADDRCONFIG and the error states than > can result need to be better documented. agreed. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 21 23:05:02 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBM72lr00122 for ipng-dist; Tue, 21 Dec 1999 23:02:47 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBM72aY00115 for ; Tue, 21 Dec 1999 23:02:37 -0800 (PST) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA10129; Tue, 21 Dec 1999 23:02:34 -0800 (PST) Date: Tue, 21 Dec 1999 21:58:16 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: API suggestion To: itojun@iijlab.net Cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <23786.945834815@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Separate issue: AI_ADDRCONFIG does not seem very useful for me, as > AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) > configured on my host. In this case I will not be able to reach > anyone outside via IPv6. We'd better have more text in 2553bis, that > describes background/goal of AI_ADDRCONFIG. We actually had the opportunity to play with this exact issue at Sun a while back. For a while we thought we should really make AI_ADDRCONFIG mean "have addresses that can be used to communicate outside the box" but this is a bit tricky to clearly define. So instead we took the path of not configuring the IPv6 loopback address unless there is some other interface being configured for IPv6. That seems to solve the ::1 issue. But keep in mind that AI_ADDRCONFIG should really be viewed as an optimization and nothing more - avoid returning addresses to the application which we know are useless. A robust application should try all addresses that are returned from getipnodebyname/getaddrinfo. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 23 00:43:14 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBN8eLI02127 for ipng-dist; Thu, 23 Dec 1999 00:40:21 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBN8eCY02120 for ; Thu, 23 Dec 1999 00:40:12 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA18373 for ; Thu, 23 Dec 1999 00:40:12 -0800 (PST) Received: from experteach.de (Mail.Experteach.de [193.22.120.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA01561 for ; Thu, 23 Dec 1999 00:39:43 -0800 (PST) Received: from experteach.de (195.27.89.118) by experteach.de with SMTP (Eudora Internet Mail Server 2.2.2); Thu, 23 Dec 1999 08:38:26 +0100 Received: from DE#u#ET-Message_Server by experteach.de with Novell_GroupWise; Thu, 23 Dec 1999 08:38:41 +0100 Message-Id: X-Mailer: Novell GroupWise 5.2 Date: Thu, 23 Dec 1999 08:36:44 +0100 From: "Christopher Balzereit" To: ipng@sunroof.eng.sun.com Subject: dynamic dns Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id dBN8eDY02121 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello IPng, I apologize for the following (maybe stupid) question: If an IPv6 host is allowed to autoconfigure its machine with an arbitrary Interface ID learnig the network prefixes via ND-Router Advertisements, is there any mechanism foreseen to adjust the corresponding A6/AAAA-RR in the hosts NS (similar to DNS-Update in IPv4)? Thanks in advance, Christopher Balzereit. ####################### Dr. Christopher Balzereit, ExperTeach Gesellschaft für Netzwerkkompetenz mbH, Waldstraße 92, 63128 Dietzenbach, Tel.: 06074/858-918, Email: cbalzere@experteach.de ####################### -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 23 13:33:32 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBNLU9b02586 for ipng-dist; Thu, 23 Dec 1999 13:30:09 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBNLU4Y02579 for ; Thu, 23 Dec 1999 13:30:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id NAA27823 for ipng@sunroof.eng.sun.com; Thu, 23 Dec 1999 13:29:18 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBNL8ZY02549 for ; Thu, 23 Dec 1999 13:08:36 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA19683 for ; Thu, 23 Dec 1999 13:08:35 -0800 (PST) Received: from hare.cpd.ufjf.br (hare.cpd.ufjf.br [200.131.17.70]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20991 for ; Thu, 23 Dec 1999 13:08:31 -0800 (PST) Received: from marcelo ([200.251.165.225]) by hare.cpd.ufjf.br (8.9.3/8.8.7) with SMTP id TAA06691 for ; Thu, 23 Dec 1999 19:05:33 -0200 (EDT) Message-ID: <001301bf4d8a$08cf6b60$e1a5fbc8@marcelo> From: "Marcelo Santos" To: Subject: Performance Date: Thu, 23 Dec 1999 19:06:55 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BF4D78.E0E6CE60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BF4D78.E0E6CE60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I'm looking for any study about IPng Performance (delay, packet = loss,...) thanks, Marcelo. ------=_NextPart_000_000D_01BF4D78.E0E6CE60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'm looking for any study about IPng = Performance=20 (delay, packet loss,...)
 
thanks,
Marcelo.
------=_NextPart_000_000D_01BF4D78.E0E6CE60-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Dec 23 16:05:41 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBO03E402721 for ipng-dist; Thu, 23 Dec 1999 16:03:14 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBO035Y02714 for ; Thu, 23 Dec 1999 16:03:06 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA01267 for ; Thu, 23 Dec 1999 16:03:05 -0800 (PST) Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06829 for ; Thu, 23 Dec 1999 16:03:04 -0800 (PST) Received: from ix.netcom.com (user-33qscij.dialup.mindspring.com [199.174.50.83]) by smtp7.atl.mindspring.net (8.9.3/8.8.5) with ESMTP id TAA10829; Thu, 23 Dec 1999 19:02:52 -0500 (EST) Message-ID: <3862D206.EBB787CD@ix.netcom.com> Date: Thu, 23 Dec 1999 17:53:11 -0800 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Karl Auerbach CC: DOMAIN-POLICY@LISTS.INTERNIC.NET, IFWP , "ipng@sunroof.eng.sun.com" , ISI IPv6 list <6bone@ISI.EDU>, ietf@ietf.org Subject: Re: RRP Specs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karl and all, Karl Auerbach wrote: > > NSI has made an I-D of the RRP Protocol. > > > > http://www.ietf.cnri.reston.va.us/internet-drafts/draft-hollenbeck-rrp-00.txt > > Am I missing something? I looked through that and I see neither > transaction identifiers nor timestamps. That alone could make > reconcilation of logs and post-mortem review of race conditions nearly > impossible. Precisely correct here Karl, and one of many deficiencies in this design document. But of course this is one of several I had pointed our some time ago before this document was published. To no avail of course. It reminds me of the lame leading the blind. And I believe I amongst a few others made this reference before as well. > > > And given the absence of a clear exchange between an existing registrar > and a new one I see a HUGE door in the transfer mechanism for registrars > to engage in what the long distance folks call "slamming" - the silent > transfer of customers from one long-distance company or registry to > another. And we have already seen this with respect to Register.com in this context already. More to come I am sure. > > > And text based? Wow, that's an open inviation to attacks based on buffer > overrun and packets split at cr-lf boundaries. Not to mention several other text based security attacks. The hack in these instances is child's play really. > > > And it is text based without any concern for internationalization. Good point here also. And one that slipped my mind... >;) > > > And its expiration date representation, although it is measured to the > millisecond, fails to include a reference to any time zone. Tisk, tisk, indeed this is a good point as well. > > > Nor does it handle IPv6. How true. > > > Seems like a rather deficient design. Looks like a design by committee, and a very poorly technically informed or knowledgeable one at that. > > > --karl-- Regards, -- Jeffrey A. Williams Spokesman INEGroup (Over 95k members strong!) CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Dec 24 01:16:07 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBO9DC502859 for ipng-dist; Fri, 24 Dec 1999 01:13:12 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBO9D2Y02852 for ; Fri, 24 Dec 1999 01:13:02 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA09586 for ; Fri, 24 Dec 1999 01:12:59 -0800 (PST) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id CAA06757 for ; Fri, 24 Dec 1999 02:12:56 -0700 (MST) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id JA32718; Fri, 24 Dec 1999 20:12:37 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: "Christopher Balzereit" Cc: ipng@sunroof.eng.sun.com Subject: Re: dynamic dns In-Reply-To: Your message of "Thu, 23 Dec 1999 08:36:44 BST." Date: Fri, 24 Dec 1999 20:12:37 +1100 Message-Id: <27365.946026757@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 23 Dec 1999 08:36:44 +0100 From: "Christopher Balzereit" Message-ID: | is there any mechanism foreseen to adjust the corresponding A6/AAAA-RR | in the hosts NS (similar to DNS-Update in IPv4)? DNS-Update isn't in IPv4, it is in the DNS. The DNS will run over both IPv6 and IPv4 in essentially the same way. DNS Update should work just as well with IPv6 as it does with IPv4. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 28 11:03:33 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBSIxun04720 for ipng-dist; Tue, 28 Dec 1999 10:59:56 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBSIxmY04713 for ; Tue, 28 Dec 1999 10:59:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA09053 for ; Tue, 28 Dec 1999 10:59:46 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11156 for ; Tue, 28 Dec 1999 11:59:46 -0700 (MST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id TAA14339; Tue, 28 Dec 1999 19:59:43 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id TAA06529; Tue, 28 Dec 1999 19:59:42 +0100 (MET) Message-Id: <199912281859.TAA06529@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: "'IPng List'" Subject: Re: API suggestion In-reply-to: Your message of Tue, 21 Dec 1999 16:49:22 +0900. <5755.945762562@coconut.itojun.org> Date: Tue, 28 Dec 1999 19:59:41 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Separately, => I'd like to get standard function/macros to set/get the port field too (I already have some but they are not (yet?) standardized). we may need some function/macro that manipulates sockaddr, for: - comparing two sockaddrs at ease. family and length must match. i can think of: - address (and scope) match - port match - address (and scope) and port match - address (and scope) with certain prefix length match only. - masking address with prefix length. cmetz and francis wanted these. => I still want these (:-)! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Dec 28 11:08:09 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBSJ71p04754 for ipng-dist; Tue, 28 Dec 1999 11:07:01 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBSJ6qY04747 for ; Tue, 28 Dec 1999 11:06:52 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA09606 for ; Tue, 28 Dec 1999 11:06:51 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07254 for ; Tue, 28 Dec 1999 11:06:50 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id UAA14654; Tue, 28 Dec 1999 20:06:46 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id UAA15878; Tue, 28 Dec 1999 20:06:42 +0100 (MET) Message-Id: <199912281906.UAA15878@givry.inria.fr> From: Francis Dupont To: itojun@iijlab.net cc: Jim Bound , Richard Draves , "'Hideaki YOSHIFUJI'" , ipng@sunroof.eng.sun.com Subject: Re: API suggestion In-reply-to: Your message of Wed, 22 Dec 1999 12:53:35 +0900. <23786.945834815@coconut.itojun.org> Date: Tue, 28 Dec 1999 20:06:27 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Separate issue: AI_ADDRCONFIG does not seem very useful for me, as AI_ADDRCONFIG can return IPv6 address if I have ::1 (and only ::1) configured on my host. In this case I will not be able to reach anyone outside via IPv6. => Jean-Luc Richier has asked how to implement this and our current solution is to say IPv6 is available when the IPv6 routing table is not empty. Another solution was to use to use something like in6_interfaces (which counts non-loopback interfaces with an IPv6 address) but it was more complex and the whole issue not very clear... We'd better have more text in 2553bis, that describes background/goal of AI_ADDRCONFIG. => I *agree*! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Dec 30 03:52:58 1999 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id dBUBnRo05391 for ipng-dist; Thu, 30 Dec 1999 03:49:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id dBUBnFY05384 for ; Thu, 30 Dec 1999 03:49:15 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA08467 for ; Thu, 30 Dec 1999 03:49:15 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA09589 for ; Thu, 30 Dec 1999 03:49:14 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23177; Thu, 30 Dec 1999 06:49:13 -0500 (EST) Message-Id: <199912301149.GAA23177@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-iana-tla-02.txt Date: Thu, 30 Dec 1999 06:49:12 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Initial IPv6 Sub-TLA ID Assignments Author(s) : B. Hinden, S. Deering, B. Fink, T. Hain Filename : draft-ietf-ipngwg-iana-tla-02.txt Pages : 6 Date : 29-Dec-99 This document defines initial assignments of IPv6 Sub-TLA Aggregation Identifiers (Sub-TLA ID) to the Address Registries and continued management of the IP6.INT domain. It is intended as technical input to the IANA from the IETF IP Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses. The IAB and IESG have authorized the Internet Assigned Numbers Authority (IANA) as the appropriate entity to have the responsibility for the management of the IPv6 address space as defined in [ALLOC]. The proposed initial assignment described in the document is consistent with: - RFC 2373,'IP Version 6 Addressing Architecture' [ARCH] - RFC 2374 'An Aggregatable Global Unicast Address Format' [AGGR] - RFC 2450 'Proposed TLA and NLA Assignment Rules' [TLA-RULES]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-iana-tla-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991229111810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iana-tla-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iana-tla-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991229111810.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 --------------------------------------------------------------------