From owner-ipng Tue Sep 3 15:42:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25098; Tue, 3 Sep 96 15:42:08 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25092; Tue, 3 Sep 96 15:41:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA12101; Tue, 3 Sep 1996 15:36:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA22883; Tue, 3 Sep 1996 15:35:37 -0700 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.7.5/42) with ESMTP id VAA03322 for ; Wed, 4 Sep 1996 21:45:24 GMT Message-Id: <199609042145.VAA03322@inner.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 2064) IPv6 BSD API spec X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Tue, 03 Sep 1996 18:33:08 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few things that I came across porting some apps from one IPv6 stack to another: 1. IMO, inet6_isipv4addr should instead be named inet6_isipv4mapped to reduce potential for confusion with IPv6-compatible addresses. 2. Should IPv6 symbols be in , or should they be defined somewhere else? ( or ) The BSD API spec says they should be in , but I'm not so sure that this is good. It creates a whole slew of new things (symbols, structures, and prototypes) that programs will get by including , and they may not expect some of these. (All implementations I've seen put the IPv6 things in a separate file; enough people concluded that this was the right thing to do independently that I think should be reconsidered). 3. Section 3.2 says: >3.2. IPv6 Address Data Structure > > A new data structure to hold a single IPv6 address is defined as > follows: > > struct in6_addr { > u_char s6_addr[16]; /* IPv6 address */ > } Are we strictly bound to this definition, or can we do something like: struct in6_addr { union { u_int8_t s6_addr8[16]; u_int32_t s6_addr32[4]; } in6_addru; }; #define s6_addr8 s6_addr This does make a difference in a few places, so (IMO) it should be explicitly allowed or disallowed. (PERSONALLY, I'd define in6_addr officially the second way -- access to the address as a group of 32-bit quantities is implementation-proven to be useful). 4. Is there any reason why we don't use POSIX bit types for data structures? IMO, "u_int32_t" is clearer than u_long for many of the structures defined (for instance, I'd expect that people coding on the Alpha are sick and tired of 32-bit vs. 64-bit "long" confusion). -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 3 19:38:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25346; Tue, 3 Sep 96 19:38:14 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25340; Tue, 3 Sep 96 19:38:01 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA04661; Tue, 3 Sep 1996 19:32:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA05416; Tue, 3 Sep 1996 19:32:32 -0700 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id TAA06083; Tue, 3 Sep 1996 19:30:54 -0700 Message-Id: <199609040230.TAA06083@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2065) Re: IPv6 BSD API spec In-Reply-To: Your message of "Tue, 03 Sep 1996 18:33:08 EDT." <199609042145.VAA03322@inner.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Sep 1996 19:30:54 -0700 From: Peter Grehan Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >2. Should IPv6 symbols be in My vote is >It creates a whole slew of new things (symbols, structures, and prototypes) >that programs will get by including , and they may not expect >some of these. But, this doesn't matter if it still compiles. >(All implementations I've seen put the IPv6 things in a separate file) I could say that all the implementations I have seen, excepting public domains ones where customer base and ease of porting application s/w are not an issue, put it in . (DEC, Sun, even Ipsilon :-) It is just one less thing that people have to change when porting, and that can only be a good thing. >Are we strictly bound to this definition, or can we do something like I think you will find this issue discussed in the IPng archives - look for contributions by Dave Borman. later, Peter. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 3 22:12:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25459; Tue, 3 Sep 96 22:12:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25453; Tue, 3 Sep 96 22:11:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA18615; Tue, 3 Sep 1996 22:06:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA04351; Tue, 3 Sep 1996 22:06:22 -0700 Received: by taliesin.cs.ucla.edu via sendmail with stdio id for ipng@sunroof.eng.sun.com; Tue, 3 Sep 96 21:59:38 -0700 (PDT) (Smail-3.1.93 1996-May-30 #2 built 1996-Jun-25) Message-Id: From: scottm@taliesin.cs.ucla.edu (Scott Michel) Subject: (IPng 2066) Re: IPv6 BSD API spec To: grehan@Ipsilon.COM (Peter Grehan) Date: Tue, 3 Sep 1996 21:59:38 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199609040230.TAA06083@mailhost.Ipsilon.COM> from "Peter Grehan" at Sep 3, 96 07:30:54 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Grehan says: > I could say that all the implementations I have seen, excepting public > domains ones where customer base and ease of porting application s/w > are not an issue, put it in . (DEC, Sun, even Ipsilon :-) > > It is just one less thing that people have to change when porting, and > that can only be a good thing. FWIW: I'd vote on putting structs, defs, consts, etc. in *but* use conditional compilation (i.e. -DIPNG or -DIPV6) to get the IPv6 stuff, and w/o the "right" macro defined get IPv4. Even with this approach, you could conceivably put the IPv6 stuff in a seperate header file, with the only impact of cluttering CFLAGS a bit. -scottm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 4 03:57:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25642; Wed, 4 Sep 96 03:57:11 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25636; Wed, 4 Sep 96 03:56:56 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA10327; Wed, 4 Sep 1996 03:51:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA24571; Wed, 4 Sep 1996 03:51:27 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id MAA25287; Wed, 4 Sep 1996 12:51:25 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id MAA27476; Wed, 4 Sep 1996 12:51:23 +0200 (MET DST) Message-Id: <199609041051.MAA27476@givry.inria.fr> From: Francis Dupont To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2067) Re: IPv6 BSD API spec In-Reply-To: Your message of Tue, 03 Sep 1996 18:33:08 EDT. <199609042145.VAA03322@inner.net> Date: Wed, 04 Sep 1996 12:50:59 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: A few things that I came across porting some apps from one IPv6 stack to another: 1. IMO, inet6_isipv4addr should instead be named inet6_isipv4mapped to reduce potential for confusion with IPv6-compatible addresses. => I agree. The name is terrible and can't be made more terrible... 2. Should IPv6 symbols be in , or should they be defined somewhere else? ( or ) The BSD API spec says they should be in , but I'm not so sure that this is good. It creates a whole slew of new things (symbols, structures, and prototypes) that programs will get by including , and they may not expect some of these. (All implementations I've seen put the IPv6 things in a separate file; enough people concluded that this was the right thing to do independently that I think should be reconsidered). => only the symbols useful for an application must be in (or included by ). I believe it is a good choice because this idea avoids the problem between and (which is an implementation choice). 3. Section 3.2 says: >3.2. IPv6 Address Data Structure > > A new data structure to hold a single IPv6 address is defined as > follows: > > struct in6_addr { > u_char s6_addr[16]; /* IPv6 address */ > } Are we strictly bound to this definition, or can we do something like: struct in6_addr { union { u_int8_t s6_addr8[16]; u_int32_t s6_addr32[4]; } in6_addru; }; #define s6_addr8 s6_addr This does make a difference in a few places, so (IMO) it should be explicitly allowed or disallowed. (PERSONALLY, I'd define in6_addr officially the second way -- access to the address as a group of 32-bit quantities is implementation-proven to be useful). => it must be allowed (I use it too :-) ! 4. Is there any reason why we don't use POSIX bit types for data structures? IMO, "u_int32_t" is clearer than u_long for many of the structures defined (for instance, I'd expect that people coding on the Alpha are sick and tired of 32-bit vs. 64-bit "long" confusion). => I believed this problem was solved in the last draft but all the u_long must be replaced. Thanks Francis.Dupont@inria.fr PS: is the new API draft ready ? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 4 05:34:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25739; Wed, 4 Sep 96 05:34:56 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25733; Wed, 4 Sep 96 05:34:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA14966; Wed, 4 Sep 1996 05:29:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA09117; Wed, 4 Sep 1996 05:29:07 -0700 Received: from office.ripe.net by ncc.ripe.net with SMTP id AA09662 (5.65a/NCC-2.36); Wed, 4 Sep 1996 14:29:05 +0200 Received: from office.ripe.net by office.ripe.net with ESMTP id MAA00270 (8.7.4/$Revision: 1.2 $); Wed, 4 Sep 1996 12:29:04 GMT Message-Id: <199609041229.MAA00270@office.ripe.net> To: Francis Dupont Cc: Craig Metz , ipng@sunroof.eng.sun.com From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 2068) Re: IPv6 BSD API spec In-Reply-To: Your message of "Wed, 04 Sep 1996 12:50:59 +0200." <199609041051.MAA27476@givry.inria.fr> Date: Wed, 04 Sep 1996 14:28:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 04 Sep 1996 12:50:59 +0200 Francis Dupont wrote: > => only the symbols useful for an application must be in > (or included by ). I believe it is a good choice because > this idea avoids the problem between and > (which is an implementation choice). With gcc, this has the disadvantage that you have to *replace* /usr/include/netinet/in.h instead of making a separate tree (say, /usr/inet6/include/netinet/in.h), and putting all changed header files there (this is much easier for experimental setups). The reason is that -I _appends_ a directory to an include path but not prepends it; thus resolves in /usr/include/netinet/in.h and /usr/inet6/include/netinet/in.h is never used. Has anybody found a fix for that? I'm not too fond of -nostdinc and -I-. Separately, I have been playing with another idea that might be worth including in the API spec. BSD systems historically have something special with ports < 1024. First, they will not be used if you just do a socket() (ports > 1024 will be used), and second, only root can bind to the 'privileged' ports. This gives a problem to daemons that need to bind to unprivileged ports; a daemon may find that 'his' port is occupied (by an outgoing telnet session, perhaps). The end result is that these daemons pick a semi-random high number, and just pray that it isn't occupied at startup. A possible improvement is to split this up. 'privileged' ports remain <= 1023, but allocation of port numbers for outgoing connections start at port 4096. This allows a range of ports (1024-4095) that isn't occupied by outgoing sessions, and thus can safely be taken by nonprivileged daemons without being stepped on. This also would make firewalling easier, as the range of 'incoming' and 'outgoing' ports is easier determined. Geert Jan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 4 08:49:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25831; Wed, 4 Sep 96 08:49:13 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25825; Wed, 4 Sep 96 08:49:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08207; Wed, 4 Sep 1996 08:43:31 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA05047; Wed, 4 Sep 1996 08:43:17 -0700 Received: (from pansiot@localhost) by crc.u-strasbg.fr (8.6.11/8.6.9) id RAA28814; Wed, 4 Sep 1996 17:42:58 +0200 Date: Wed, 4 Sep 1996 17:42:58 +0200 From: PANSIOT Jean Jacques - Centre Reseau Communication - Universite Louis Pasteur Message-Id: <199609041542.RAA28814@crc.u-strasbg.fr> To: ipng@sunroof.eng.sun.com Subject: (IPng 2069) Priority and flow label Cc: pansiot@crc.u-strasbg.fr X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, RFC 1883 indicates that " The 4-bit Priority field in the IPv6 header enables a source to identify the desired delivery priority of its packets, relative to other packets from the same source. " I wonder if "source" means sending host, or is it restricted to a flow label if there is one? That is, is it allowed for a router to compare priorities of packets - in the same flow ? - in different flows ? - both ? Thanks Jean-Jacques -- Jean-Jacques Pansiot, Universite Louis Pasteur Departement d'Informatique, et LSIIT CNRS URA 1871 7, rue Descartes 67084 STRASBOURG CEDEX FRANCE Email: pansiot@dpt-info.u-strasbg.fr Tel: (33) 88 41 64 28 Fax: (33) 88 61 90 69 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 4 12:45:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26029; Wed, 4 Sep 96 12:45:32 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26023; Wed, 4 Sep 96 12:45:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA09199; Wed, 4 Sep 1996 12:39:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA11602; Wed, 4 Sep 1996 12:39:14 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA05522; Wed, 4 Sep 96 12:38:50 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA14125; Wed, 4 Sep 1996 12:38:58 -0700 Date: Wed, 4 Sep 1996 12:38:58 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199609041938.MAA14125@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2070) Re: IPv6 BSD API spec X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Peter on all counts. We do not need another header. I do not believe that we need #ifdef IPNG and #ifdef IPv4 either. If you have browsed the header files of any of the major commercial UNIX operating systems recently you will know that they have become an almost intractable maze of preprocessor conditionals. We should avoid adding to that maze if possible. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 4 13:00:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26082; Wed, 4 Sep 96 13:00:19 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26068; Wed, 4 Sep 96 12:59:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA13016; Wed, 4 Sep 1996 12:54:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA16343; Wed, 4 Sep 1996 12:53:28 -0700 Received: from munin.fnal.gov ("port 2962"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I932B9220I0029JQ@FNAL.FNAL.GOV>; Wed, 04 Sep 1996 14:53:16 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id OAA23027; Wed, 04 Sep 1996 14:51:18 -0500 (CDT) Date: Wed, 04 Sep 1996 14:51:09 -0500 From: Matt Crawford Subject: (IPng 2071) RFC 1897 vagueness To: ipng@sunroof.eng.sun.com Cc: hinden@ipsilon.com, postel@isi.edu Message-Id: <199609041951.OAA23027@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26175; Wed, 4 Sep 96 13:40:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26169; Wed, 4 Sep 96 13:40:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA23330; Wed, 4 Sep 1996 13:34:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA00288; Wed, 4 Sep 1996 13:33:12 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id QAA27107; Wed, 4 Sep 1996 16:31:52 -0400 (EDT) Message-Id: <199609042031.QAA27107@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Geert Jan de Groot Cc: Francis Dupont , Craig Metz , ipng@sunroof.eng.sun.com Subject: (IPng 2072) Re: IPv6 BSD API spec In-Reply-To: Your message of "Wed, 04 Sep 1996 14:28:23 +0200." <199609041229.MAA00270@office.ripe.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 04 Sep 1996 16:31:46 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geert Jan de Groot writes: > Separately, I have been playing with another idea that might be worth > including in the API spec. BSD systems historically have something special > with ports < 1024. First, they will not be used if you just do a socket() > (ports > 1024 will be used), and second, only root can bind to > the 'privileged' ports. Privileged ports are a cause of substantial grief. Among other things, they force perfectly ordinary daemons that do not do anything privileged on the system to run as root, and not as an unprivileged process. I've gained substantial security on some machines by yanking the priv port code out of the BSD kernel -- there is no longer even a stub process running as root needed to open the port. On a non-multiuser machine used for something like a firewall, this is a win. The privileged port notion largely a historical leftover from the days of the Berkeley r-commands, when machines were big and their administrators could be trusted -- if you got a connection from a low port, you could assume that root on the other machine had a hand in setting up the connection. Of course, nowadays thats useless for security, and everyone rational uses encryption in the form of tools like ssh or encrypted telnet or what have you. The only continued excuse for the privileged port mechanism is to prevent users from spoofing system daemons (like telnetd) by somehow binding those ports (presumably after crashing the legitimate daemon through some bug). I prefer that we not do much more to embed the notion of privileged ports into the API. Its an artifact, and a bad one. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 4 18:12:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26866; Wed, 4 Sep 96 18:12:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26860; Wed, 4 Sep 96 18:12:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA23510; Wed, 4 Sep 1996 18:07:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA17821; Wed, 4 Sep 1996 10:29:50 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) id SAA03130; Wed, 4 Sep 1996 18:27:43 +0100 Date: Wed, 4 Sep 1996 18:27:43 +0100 Message-Id: <199609041727.SAA03130@oberon.di.fc.ul.pt> From: Pedro Roque Marques To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2073) IPv6 BSD API spec In-Reply-To: <199609042145.VAA03322@inner.net> References: <199609042145.VAA03322@inner.net> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Craig" == Craig Metz writes: Craig> 2. Should IPv6 symbols be in , or should Craig> they be defined somewhere else? ( or Craig> ) The BSD API spec says they should be in Craig> , but I'm not so sure that this is good. It Craig> creates a whole slew of new things (symbols, structures, Craig> and prototypes) that programs will get by including Craig> , and they may not expect some of these. (All Craig> implementations I've seen put the IPv6 things in a separate Craig> file; enough people concluded that this was the right thing Craig> to do independently that I think should be Craig> reconsidered). I would favor (or as a second choice). This definitions are relevant to the AF_INET6 family and seam irelevant to an application that only uses the AF_INET protocol family. Craig> 3. Section 3.2 says: >> 3.2. IPv6 Address Data Structure >> >> A new data structure to hold a single IPv6 address is defined >> as follows: >> >> struct in6_addr { u_char s6_addr[16]; /* IPv6 address */ } Craig> Are we strictly bound to this definition, or can we do Craig> something like: Craig> struct in6_addr { union { u_int8_t s6_addr8[16]; Craig> u_int32_t s6_addr32[4]; } in6_addru; }; #define s6_addr8 Craig> s6_addr Craig> This does make a difference in a few places, so (IMO) Craig> it should be explicitly allowed or disallowed. (PERSONALLY, Craig> I'd define in6_addr officially the second way -- access to Craig> the address as a group of 32-bit quantities is Craig> implementation-proven to be useful). I think it should not be disallowed. Accessing as 32-bit quantities (or 64-bit on 64-bit processors) is a significatively more performant on any modern processor. I think it would force people to have a struct in6_addr for kernel code and other for userland code which seams bound to create problems. One example where this is significative is a test for the address type. I intend to use an union with the 8, 32 and 64 bit quantities. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 03:05:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27168; Thu, 5 Sep 96 03:05:11 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27162; Thu, 5 Sep 96 03:04:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA23950; Thu, 5 Sep 1996 02:59:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id CAA21340; Thu, 5 Sep 1996 02:59:19 -0700 Received: from office.ripe.net by ncc.ripe.net with SMTP id AA03073 (5.65a/NCC-2.36); Thu, 5 Sep 1996 11:59:17 +0200 Received: from office.ripe.net by office.ripe.net with ESMTP id JAA01633 (8.7.4/$Revision: 1.2 $); Thu, 5 Sep 1996 09:59:17 GMT Message-Id: <199609050959.JAA01633@office.ripe.net> To: perry@piermont.com Cc: ipng@sunroof.eng.sun.com From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 2074) Re: IPv6 BSD API spec In-Reply-To: Your message of "Wed, 04 Sep 1996 16:31:46 EDT." <199609042031.QAA27107@jekyll.piermont.com> Date: Thu, 05 Sep 1996 11:59:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 04 Sep 1996 16:31:46 -0400 "Perry E. Metzger" wrote: > Privileged ports are a cause of substantial grief. Among other things, > they force perfectly ordinary daemons that do not do anything > privileged on the system to run as root, and not as an unprivileged > process. I've gained substantial security on some machines by yanking > the priv port code out of the BSD kernel -- there is no longer even a > stub process running as root needed to open the port. On a > non-multiuser machine used for something like a firewall, this is a > win. Perry, I agree with you. However, a case can be made that migration would be easier if the privileged port thing stays for a little longer; it would dualstack machines (where the IPv4-apps expect BSD behaviour) make easier. There are still too many protocols for which no wide-spread non-r* equivalent exists (such as lpd). My proposal allows both: classic behaviour for those apps that still need it, a reserved range for non-root apps that is 'safe' to bind, and clearer distiction between outgoing and incoming ports, making firewalls easier. Geert Jan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 08:49:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27273; Thu, 5 Sep 96 08:49:38 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27267; Thu, 5 Sep 96 08:49:17 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA20268; Thu, 5 Sep 1996 08:43:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA04574; Thu, 5 Sep 1996 08:43:40 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id LAA06511; Thu, 5 Sep 1996 11:40:39 -0400 (EDT) Message-Id: <199609051540.LAA06511@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Geert Jan de Groot Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2075) Re: IPv6 BSD API spec In-Reply-To: Your message of "Thu, 05 Sep 1996 11:59:16 +0200." <199609050959.JAA01633@office.ripe.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 05 Sep 1996 11:40:33 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geert Jan de Groot writes: > Perry, I agree with you [that priv'ed ports are bad]. However, a > case can be made that migration would be easier if the privileged > port thing stays for a little longer; it would dualstack machines > (where the IPv4-apps expect BSD behaviour) make easier. I'm not arguing for yanking the mechanism out just yet. However, you are arguing for extending it somewhat, and I would rather that we not do that. The incoming-outgoing ports thing you propose, for example, isn't really needed (today's firewalls happily deal with the situation already) and only extends the kludge we would like to see die. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 09:14:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27304; Thu, 5 Sep 96 09:14:02 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27297; Thu, 5 Sep 96 09:13:42 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25367; Thu, 5 Sep 1996 09:08:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA12886; Thu, 5 Sep 1996 09:08:02 -0700 Received: from office.ripe.net by ncc.ripe.net with SMTP id AA13521 (5.65a/NCC-2.36); Thu, 5 Sep 1996 18:07:53 +0200 Received: from office.ripe.net by office.ripe.net with ESMTP id QAA03185 (8.7.4/$Revision: 1.2 $); Thu, 5 Sep 1996 16:07:52 GMT Message-Id: <199609051607.QAA03185@office.ripe.net> To: perry@piermont.com Cc: ipng@sunroof.eng.sun.com From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: (IPng 2076) Re: IPv6 BSD API spec In-Reply-To: Your message of "Thu, 05 Sep 1996 11:40:33 EDT." <199609051540.LAA06511@jekyll.piermont.com> Date: Thu, 05 Sep 1996 18:07:48 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 05 Sep 1996 11:40:33 -0400 "Perry E. Metzger" wrote: > I'm not arguing for yanking the mechanism out just yet. However, you > are arguing for extending it somewhat, and I would rather that we not > do that. The incoming-outgoing ports thing you propose, for example, > isn't really needed (today's firewalls happily deal with the situation > already) and only extends the kludge we would like to see die. I think I'm missing something. When you make an outgoing connection on a freshly started machine, it will probably allocate port 1024 as local port for you. The next one will be 1025, etc. This means that it is probably not a good idea to design a daemon that listens on port 1024, because it's likely that that port is taken. Currently, there is no good mechanism to defend against that. BSD defined port numbers that are not allocated if you just want to connect; the ports <= 1023. I.e., if you want to make a daemon, picking a port under 1023 is a much better choice because it's at least not taken by a random session. As additional feature, in BSD you need to be root to bind() to a port <1023. That is a problem for non-root daemons, as they can't pick one of the 'guaranteed-free' ports and just have to pick a higher port and prey it isn't taken already. Extending the range of ports that aren't allocated randomly therefore allows for a much safer choice: 1-1023: must bind(), must be root 1024-4095: must bind(), any user 4096&up: allocated at random If you would remove the reservation mechanism altogether, wouldn't that give much more problems? Therefore, splitting the 'reserved' and the 'privileged' ports seems like a win to me, and allows the possibility to yank out the 'privileged port' concept altogether in the future if so desired, but allows non-root daemons to pick a safe port _today_ which they can't do in BSD/IPv4. Geert Jan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 09:30:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27379; Thu, 5 Sep 96 09:30:52 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27373; Thu, 5 Sep 96 09:30:37 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA29264; Thu, 5 Sep 1996 09:24:58 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA18563; Thu, 5 Sep 1996 09:24:27 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA29665; Thu, 5 Sep 96 12:18:54 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9609051618.AA29665@iol.unh.edu> Subject: (IPng 2077) Some questions. To: ipng@sunroof.eng.sun.com (ipng) Date: Thu, 5 Sep 1996 12:18:53 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have a few qustions regarding the transition. 1) IPv6 headers have been designed with 8-byte alignment in mind. But in case of tunneled packets, IPv4 headers preceding the IPv6 header makes the v6 header unaligned. This causes an extra copy of the entire packet, which is pretty expensive, and I don't think transition would be short lived. An obvious remedy is to include 4 byte worth of NOP IPv4 options after the v4-header. Any comments ? 2) Another question regarding socket API is, should it allow two server applications say serverv4 and serverv6 two open a socket on the same port and the unspecified v4 address and the unspecified v6 address, unless explicitly specified by both application via the SO_REUSEPORT option. I personally don't think so. An argument to allow such a scenario I have heard is that it would be useful in case if someone is debugging a serverv6 which is not stable and might want a serverv4 still up. But the current BSD based code doesnot guarantee if the packet would be delivered to the correct server in case both are running. 3)Is there a document on source address selection in IPv6. I have some concerns regarding this issue. I think we should have atleast a set of guidelines regarding this. For example : Consider the scenario of a dual node A which has a tunneling interface with a v4-compatible address ::A and a global IPv6 address G. Now consider an isolated host B with a v4-compatible ::B. Now A has a UDP server application running which is bound to a well known port and the wildcard address i.e. all zeros IPv6 addresss. Now a client application on B sends a packet to the server appl. on A using A's global address G (which it got via DNS) as destination. When the server application replies, it will use ::A as source address if source address selection is done in the same fashion as is being done for v4, as I can see on BSD based code, i.e use the address of the outgoing interface address as source unless specified by the user explicitly. Now this problem existed in IPv4 too, on multihomed host. This may or may not be more common in IPv6 depending on how frequently we use the tunneling interface. If it is restricted to routers and isolated host (with only one IPv6 interface, which is the tunneling interface), then this problem is only on routers. Or should we consider this as the user application's onus to provide the source address explicitly. Quaizar ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 09:37:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27391; Thu, 5 Sep 96 09:37:19 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27385; Thu, 5 Sep 96 09:36:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA00868; Thu, 5 Sep 1996 09:31:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA20730; Thu, 5 Sep 1996 09:30:29 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id MAA11079; Thu, 5 Sep 1996 12:29:59 -0400 (EDT) Message-Id: <199609051629.MAA11079@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Geert Jan de Groot Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2078) Re: IPv6 BSD API spec In-Reply-To: Your message of "Thu, 05 Sep 1996 18:07:48 +0200." <199609051607.QAA03185@office.ripe.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 05 Sep 1996 12:29:58 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geert Jan de Groot writes: > I think I'm missing something. When you make an outgoing connection > on a freshly started machine, it will probably allocate port 1024 > as local port for you. Yes, but thats an OUTGOING port, not an INCOMING port. You aren't listening on that port. > This means that it is probably not a good idea to design a daemon > that listens on port 1024, because it's likely that that port is taken. I don't see this is a problem -- it doesn't crop up in practice. Remember, its an OUTGOING port -- you aren't listening for connections on that port. Some implementations may have problems with this, but there is no underlying problem with it. (Well, there might be in the extraordinarily odd circumstance that you are using some port for an outgoing connection to a server on a machine that attempts to open a connection from that server's port number to the server running on your machine on the port you are using -- however, with 64k ports to pick for your connection to a given service thats unusual and in any case can be corrected by retrying on another port.) > As additional feature, in BSD you need to be root to bind() to > a port <1023. That is a problem for non-root daemons, Yeah. I have patches to fix that for NetBSD if you want them :) Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 10:32:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27569; Thu, 5 Sep 96 10:32:38 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27563; Thu, 5 Sep 96 10:32:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14198; Thu, 5 Sep 1996 10:26:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA09030; Thu, 5 Sep 1996 10:26:05 -0700 Received: from munin.fnal.gov ("port 3238"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I94BFE817E0027W3@FNAL.FNAL.GOV>; Thu, 05 Sep 1996 12:25:29 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id MAA26975; Thu, 05 Sep 1996 12:23:31 -0500 (CDT) Date: Thu, 05 Sep 1996 12:23:30 -0500 From: Matt Crawford Subject: (IPng 2079) Re: IPv6 BSD API spec In-Reply-To: "05 Sep 1996 18:07:48 +0200." <"199609051607.QAA03185"@office.ripe.net> To: Geert Jan de Groot Cc: perry@piermont.com, ipng@sunroof.eng.sun.com Message-Id: <199609051723.MAA26975@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Extending the range of ports that aren't allocated randomly > therefore allows for a much safer choice: > 1-1023: must bind(), must be root > 1024-4095: must bind(), any user > 4096&up: allocated at random I had a vague recollection, and I checked it by RTFS: some BSD derived IP stacks will allocate only ports between 1024 and 5000 to sockets which don't explicitly bind(). I've been told that some other kernels use 50000 as the upper limit. If this holds true more widely than the cases I checked, then changing your ranges to 1-1023; 50001-65535; 1024-50000 respectively would pretty much just codify existing practice. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 10:54:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27606; Thu, 5 Sep 96 10:54:41 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27600; Thu, 5 Sep 96 10:54:26 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA19582; Thu, 5 Sep 1996 10:48:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA19793; Thu, 5 Sep 1996 10:48:03 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14791(3)>; Thu, 5 Sep 1996 10:47:07 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 5 Sep 1996 10:46:47 PDT To: qv@iol.unh.edu (Quaizar Vohra) Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2080) Re: Some questions. In-Reply-To: qv's message of Thu, 05 Sep 96 09:18:53 -0800. <9609051618.AA29665@iol.unh.edu> Date: Thu, 5 Sep 1996 10:46:46 PDT From: Steve Deering Message-Id: <96Sep5.104647pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quaizar, > 1) IPv6 headers have been designed with 8-byte alignment in mind. > But in case of tunneled packets, IPv4 headers preceding the IPv6 > header makes the v6 header unaligned. This causes an extra copy > of the entire packet, which is pretty expensive, and I don't think > transition would be short lived. An obvious remedy is to include > 4 byte worth of NOP IPv4 options after the v4-header. Any comments ? Yeah, I brought this up several times during the development of IPAE and ngtrans, but for some reason no one else seemed bothered by it. Maybe the folks who dismissed it were concerned only with 32-bit architectures in which there is no particular advantage to 64-bit alignment, relative to 32-bit alignment. If this issue were to be addressed, I suggest that using IPv4 NOP options would be a poor choice, because of the performance impact of carrying any options in an IPv4 packet. A better approach would be to specify that a specific IPv4 protocol number is used to indicate that the IPv4 payload consists of 32 bits of padding followed by an IPv6 packet. I don't have any useful comment to make on your API question, regarding a v6 and v4 server sharing the same port number. > 3)Is there a document on source address selection in IPv6. I have > some concerns regarding this issue. I think we should have atleast a > set of guidelines regarding this. The WIDE folks have been working on a draft on source address selection; Kazu mentioned it on the ipng list a few weeks ago. I think there are definitely some aspects of that issue that cannot just be left as local implementation choices, if we are going to be able to get maximum benefit from IPv6 addressing, and I am looking forward to Kazu's draft as a starting point to getting agreement on that. By the way, it should not be necessary to post the same message to both the ngtrans list and the ipng list, since everyone on ngtrans ought to also be on ipng. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 11:15:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27704; Thu, 5 Sep 96 11:15:01 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27695; Thu, 5 Sep 96 11:14:41 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA24615; Thu, 5 Sep 1996 11:08:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA26480; Thu, 5 Sep 1996 11:07:54 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id OAA12804; Thu, 5 Sep 1996 14:10:41 -0400 Received: from maggie.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA06686; Thu, 5 Sep 96 14:07:22 EDT Date: Thu, 5 Sep 96 14:07:22 EDT Message-Id: <9609051807.AA06686@pobox.BayNetworks.com> Received: by maggie.engeast (4.1/SMI-4.1) id AA04091; Thu, 5 Sep 96 14:06:46 EDT From: John Krawczyk To: qv@iol.unh.edu (Quaizar Vohra) Cc: ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 2081) Re: Some questions. In-Reply-To: <9609051618.AA29665@iol.unh.edu> References: <9609051618.AA29665@iol.unh.edu> Reply-To: jkrawczy@BayNetworks.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 5 September, Quaizar Vohra (qv@iol.unh.edu) wrote: 1) IPv6 headers have been designed with 8-byte alignment in mind. But in case of tunneled packets, IPv4 headers preceding the IPv6 header makes the v6 header unaligned. This causes an extra copy of the entire packet, which is pretty expensive, and I don't think transition would be short lived. An obvious remedy is to include 4 byte worth of NOP IPv4 options after the v4-header. Any comments ? On IPv4 routers from at least two popular vendors, any options in the IPv4 header kicks you out of the "fast-path" forwarding code. This would mean lower throughput and higher latency for your tunneled IPv6 packets than you would see without the options. -jj ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 17:46:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28197; Thu, 5 Sep 96 17:46:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27975; Thu, 5 Sep 96 15:07:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA12486; Thu, 5 Sep 1996 15:01:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA11592; Thu, 5 Sep 1996 14:59:42 -0700 Received: (qmail-queue invoked from smtpd); 5 Sep 1996 21:58:20 -0000 Received: from h99.free-gate.com (HELO kandinsky.freegate.net) (205.178.11.99) by freegate.net with SMTP; 5 Sep 1996 21:58:19 -0000 Message-Id: <322F4D31.3E90@freegate.net> Date: Thu, 05 Sep 1996 14:59:13 -0700 From: Bob Gilligan Organization: Freegate Corporation X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2082) Re: IPv6 BSD API spec References: <199609042145.VAA03322@inner.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig Metz wrote: > > A few things that I came across porting some apps from one IPv6 > stack to another: > > 1. IMO, inet6_isipv4addr should instead be named inet6_isipv4mapped to > reduce potential for confusion with IPv6-compatible addresses. Your proposed change sounds reasonable to me, but I'm a little reluctant to change a function name at this late date unless there is a real compelling reason. At this point, we do have some implementations running, so every time we make a change like this, those implementations have to be revised. > 2. Should IPv6 symbols be in , or should they be defined > somewhere else? ( or ) I don't see any value in defining a new header file. Doing so would just confuse application writers, I think (Should I include or or both?). It was our explicit goal that the new items we added to should not break any applications. Assuming that's the case, there's no need for another header file. > 3. Section 3.2 says: > > >3.2. IPv6 Address Data Structure > > > > A new data structure to hold a single IPv6 address is defined as > > follows: > > > > struct in6_addr { > > u_char s6_addr[16]; /* IPv6 address */ > > } > > Are we strictly bound to this definition, or can we do something like: > > struct in6_addr { > union { > u_int8_t s6_addr8[16]; > u_int32_t s6_addr32[4]; > } in6_addru; > }; > #define s6_addr8 s6_addr > > This does make a difference in a few places, so (IMO) it should be > explicitly allowed or disallowed. (PERSONALLY, I'd define in6_addr officially > the second way -- access to the address as a group of 32-bit quantities is > implementation-proven to be useful). Dave Borman has pointed out that a structure packed with an array of 32-bit elements does not work on a machine that does not have an addressable 32-bit word, such as the Cray. The definition we made for struct in6_addr was explicitly designed so that IPv6 applications would be portable across all architctures. So I do not think we should adopt the change you propose. > 4. Is there any reason why we don't use POSIX bit types for data > structures? IMO, "u_int32_t" is clearer than u_long for many of the structures > defined (for instance, I'd expect that people coding on the Alpha are sick > and tired of 32-bit vs. 64-bit "long" confusion). I believe we have changed all instances of u_long and u_short to u_int32m_t and u_int16m_t respectively. Have a look at the latest version of the API spec (version 5, dated 18 April 96) and let me know if I missed any! Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 18:33:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28353; Thu, 5 Sep 96 18:33:43 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28333; Thu, 5 Sep 96 18:33:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA11232; Thu, 5 Sep 1996 18:27:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA10018; Thu, 5 Sep 1996 18:27:36 -0700 Received: (qmail-queue invoked from smtpd); 6 Sep 1996 01:27:21 -0000 Received: from h99.free-gate.com (HELO kandinsky.freegate.net) (205.178.11.99) by freegate.net with SMTP; 6 Sep 1996 01:27:20 -0000 Message-Id: <322F7E2E.4BB0@freegate.net> Date: Thu, 05 Sep 1996 18:28:14 -0700 From: Bob Gilligan Organization: Freegate Corporation X-Mailer: Mozilla 2.0 (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 2083) Re: IPv6 BSD API spec Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig Metz wrote: > > A few things that I came across porting some apps from one IPv6 > stack to another: > > 1. IMO, inet6_isipv4addr should instead be named inet6_isipv4mapped to > reduce potential for confusion with IPv6-compatible addresses. Your proposed change sounds reasonable to me, but I'm a little reluctant to change a function name at this late date unless there is a real compelling reason. At this point, we do have some implementations running, so every time we make a change like this, those implementations have to be revised. > 2. Should IPv6 symbols be in , or should they be defined > somewhere else? ( or ) I don't see any value in defining a new header file. Doing so would just confuse application writers, I think (Should I include or or both?). It was our explicit goal that the new items we added to should not break any applications. Assuming that's the case, there's no need for another header file. > 3. Section 3.2 says: > > >3.2. IPv6 Address Data Structure > > > > A new data structure to hold a single IPv6 address is defined as > > follows: > > > > struct in6_addr { > > u_char s6_addr[16]; /* IPv6 address */ > > } > > Are we strictly bound to this definition, or can we do something like: > > struct in6_addr { > union { > u_int8_t s6_addr8[16]; > u_int32_t s6_addr32[4]; > } in6_addru; > }; > #define s6_addr8 s6_addr > > This does make a difference in a few places, so (IMO) it should be > explicitly allowed or disallowed. (PERSONALLY, I'd define in6_addr officially > the second way -- access to the address as a group of 32-bit quantities is > implementation-proven to be useful). Dave Borman has pointed out that a structure packed with an array of 32-bit elements does not work on a machine that does not have an addressable 32-bit word, such as the Cray. The definition we made for struct in6_addr was explicitly designed so that IPv6 applications would be portable across all architctures. So I do not think we should adopt the change you propose. > 4. Is there any reason why we don't use POSIX bit types for data > structures? IMO, "u_int32_t" is clearer than u_long for many of the structures > defined (for instance, I'd expect that people coding on the Alpha are sick > and tired of 32-bit vs. 64-bit "long" confusion). I believe we have changed all instances of u_long and u_short to u_int32m_t and u_int16m_t respectively. Have a look at the latest version of the API spec (version 5, dated 18 April 96) and let me know if I missed any! Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 5 18:43:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28384; Thu, 5 Sep 96 18:43:44 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28378; Thu, 5 Sep 96 18:43:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA13640; Thu, 5 Sep 1996 18:37:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA12405; Thu, 5 Sep 1996 18:37:42 -0700 Received: from onoe2 by onoe2.sm.sony.co.jp (8.7.5/Sony6.1MX) with ESMTP id KAA24882; Fri, 6 Sep 1996 10:37:14 +0900 (JST) Message-Id: <199609060137.KAA24882@onoe2.sm.sony.co.jp> To: deering@parc.xerox.com Cc: qv@iol.unh.edu, ipng@sunroof.eng.sun.com Subject: (IPng 2084) Re: Some questions. In-Reply-To: Your message of "Thu, 5 Sep 1996 10:46:46 PDT" References: <96Sep5.104647pdt."75270"@digit.parc.xerox.com> X-Mailer: Mew version 1.03 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Fri, 06 Sep 96 10:37:13 +0900 From: Atsushi Onoe Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > The WIDE folks have been working on a draft on source address selection; > Kazu mentioned it on the ipng list a few weeks ago. I think there are > definitely some aspects of that issue that cannot just be left as local > implementation choices, if we are going to be able to get maximum benefit > from IPv6 addressing, and I am looking forward to Kazu's draft as a > starting point to getting agreement on that. We WIDE had some meetings about address scope and achieved a rough consensus. Kazu is hesitating to submit ID because it is a proposal of modification to RFCs, not a separated draft. (1) The source address of every packet destined for node-local address or node-local multicast address MUST be the loopback address. (2) The source address of every packet destined for link-local address or link-local multicast address MUST be a link-local address. (3) For other type of destination, the source address MUST has "wider" or same scope of the destination. ex.) destination source site-local unicast global or site-local site-local multicast global or site-local (*) organization-local multicast global (*) global unicast global global multicast global Implementation MAY use global address as its source address whenever available. (*) The source address selection for multicast has not discussed. It is confused when site-local, organization-local, global multicast trees coexist. DISCUSSION: There might be a case that site-local source address is preferred for site-local destination address. For example, a WWW server can refuse connections without site-local source address. But using global address and prefixlen pair, the same effect will be obtained. The source address selection mechanism is essential and every node must implement it. So we choose the simple solution: the only one address can be used in any case. We also discussed on related issues. (a) NDP and RIPng draft state that sending to the link-local multicast address with HLIM=255, and discard input packet with HLIM != 255 to guarantee that the packet is not forwarded. It should not defined in every spec. using link-local addresses. IPv6 spec should define either: i) A node must set HLIM to 255 for link-local addresses and must discard packets whose destination address is link-local and HLIM is not equals to 255. ii) A router must not forward packets destined to link-local unicast address or link-local multicast address. And link-local addresses are not allowed in Routing Header. (b) BSD-Spec Applications like routed6 sending to link-local destination addresses need to specify a destination interface. Interface notification mechanism is also needed in packet reception. We propose adding a sin6_ifid member to struct sockaddr_in6. sin6_ifid is a interface index or iid. Atsushi Onoe, WIDE Project ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 6 06:18:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28908; Fri, 6 Sep 96 06:18:33 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28902; Fri, 6 Sep 96 06:18:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA20904; Fri, 6 Sep 1996 06:12:44 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA29776; Fri, 6 Sep 1996 06:12:41 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) id MAA06353; Fri, 6 Sep 1996 12:09:17 +0100 Date: Fri, 6 Sep 1996 12:09:17 +0100 Message-Id: <199609061109.MAA06353@oberon.di.fc.ul.pt> From: Pedro Roque Marques To: Bob Gilligan Cc: Craig Metz , ipng@sunroof.eng.sun.com Subject: (IPng 2085) Re: IPv6 BSD API spec In-Reply-To: <322F4D31.3E90@freegate.net> References: <199609042145.VAA03322@inner.net> <322F4D31.3E90@freegate.net> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Bob" == Bob Gilligan writes: Bob> Craig Metz wrote: >> A few things that I came across porting some apps from one >> IPv6 stack to another: >> >> 1. IMO, inet6_isipv4addr should instead be named >> inet6_isipv4mapped to reduce potential for confusion with >> IPv6-compatible addresses. Bob> Your proposed change sounds reasonable to me, but I'm a Bob> little reluctant to change a function name at this late date Bob> unless there is a real compelling reason. At this point, we Bob> do have some implementations running, so every time we make a Bob> change like this, those implementations have to be revised. isipv4addr is a bit misleading, specially for application writers that might confuse v4-compatible with v4-mapped. >> 2. Should IPv6 symbols be in , or should they be >> defined somewhere else? ( or ) Bob> I don't see any value in defining a new header file. For pratical reasons it would be very helpfull for some people. In Linux, /usr/include/netinet files are distributed with the libc which is distributed indenpedently of the kernels. The definitions to support the AF_INET6 family include part of kernel headers and libc headers. To be able to have a libc that supports both kernels with and without INET6 we cannot make changes to netinet/in.h. I've been distributing a netinet6 directory with extra include files along with our applications that people can stick into /usr/include or even use a symbolic link. We won't really be able to comply with this requirement in the short term. You may argue that this is a problem caused by the way we maintain and distribute code. Personally i would prefet if INET6 extensions would not to afect at all the base API. Bob> Doing Bob> so would just confuse application writers, I think (Should I Bob> include or or both?). I think application writers should include header files relevant to the protocol families they intend to use: un.h for AF_UNIX, in.h for AF_INET, iso.h for AF_ISO, ns.h for AF_NS. Except for un.h, in 4.4 BSD, these all apear as net/.h So by the least surprise principle seams to me the more apropriate choice for AF_INET6 definitions. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 6 06:49:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29001; Fri, 6 Sep 96 06:49:20 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28995; Fri, 6 Sep 96 06:49:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA24402; Fri, 6 Sep 1996 06:43:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA07910; Fri, 6 Sep 1996 06:43:29 -0700 Received: by kro.amtp.cam.ac.uk (Smail-3.1.28.1 #6) id m0uz17g-00024uC; Fri, 6 Sep 96 14:39 BST Message-Id: X-Mailer: exmh version 1.5.1 12/2/94 To: Pedro Roque Marques Cc: jp107@damtp.cam.ac.uk, Subject: (IPng 2086) Re: IPv6 BSD API spec In-Reply-To: Your message of "Fri, 06 Sep 1996 12:09:17 BST." <199609061109.MAA06353@oberon.di.fc.ul.pt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Sep 1996 14:39:04 +0100 From: Jon Peatfield Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For pratical reasons it would be very helpfull for some people. > In Linux, /usr/include/netinet files are distributed with the libc > which is distributed indenpedently of the kernels. The definitions to > support the AF_INET6 family include part of kernel headers and libc > headers. To be able to have a libc that supports both kernels with and > without INET6 we cannot make changes to netinet/in.h. > I've been distributing a netinet6 directory with extra include files > along with our applications that people can stick into /usr/include or > even use a symbolic link. Don't use Linux as a stick to beat this with. Linux's netinet/in.h #includes the kernel specific for this type of thing. You may want a new file for other reasons but Linux doesn't *need* it. -- Jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 6 07:00:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29021; Fri, 6 Sep 96 07:00:09 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29012; Fri, 6 Sep 96 06:59:55 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25609; Fri, 6 Sep 1996 06:54:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA10792; Fri, 6 Sep 1996 06:54:16 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) id OAA06516; Fri, 6 Sep 1996 14:52:10 +0100 Date: Fri, 6 Sep 1996 14:52:10 +0100 Message-Id: <199609061352.OAA06516@oberon.di.fc.ul.pt> From: Pedro Roque Marques To: Jon Peatfield Cc: Subject: (IPng 2087) Re: IPv6 BSD API spec In-Reply-To: References: <199609061109.MAA06353@oberon.di.fc.ul.pt> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Jon" == Jon Peatfield writes: >> For pratical reasons it would be very helpfull for some people. >> In Linux, /usr/include/netinet files are distributed with the >> libc which is distributed indenpedently of the kernels. The >> definitions to support the AF_INET6 family include part of >> kernel headers and libc headers. To be able to have a libc that >> supports both kernels with and without INET6 we cannot make >> changes to netinet/in.h. I've been distributing a netinet6 >> directory with extra include files along with our applications >> that people can stick into /usr/include or even use a symbolic >> link. Jon> Don't use Linux as a stick to beat this with. I'm trying to give an example on where this is an advantage. Jon> Linux's Jon> netinet/in.h #includes the kernel specific for Jon> this type of thing. Yes, that is preciselly my point. It includes . To support INET6 definitions it would need to include (or those defs would need to be in linux/in.h) *and* define things that depend on the presence of those kernel includes. Jon> You may want a new file for other reasons but Linux doesn't Jon> *need* it. I maintain that it would be extremely useful on this particular case. I don't know other implementations well enought to comment. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 6 07:24:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29099; Fri, 6 Sep 96 07:24:54 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29090; Fri, 6 Sep 96 07:24:35 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA28228; Fri, 6 Sep 1996 07:16:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA16466; Fri, 6 Sep 1996 07:16:13 -0700 Received: by kro.amtp.cam.ac.uk (Smail-3.1.28.1 #6) id m0uz1YG-00024uC; Fri, 6 Sep 96 15:06 BST Message-Id: X-Mailer: exmh version 1.5.1 12/2/94 To: Pedro Roque Marques Cc: jp107@damtp.cam.ac.uk, Subject: (IPng 2088) Re: IPv6 BSD API spec In-Reply-To: Your message of "Fri, 06 Sep 1996 14:52:10 BST." <199609061352.OAA06516@oberon.di.fc.ul.pt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Sep 1996 15:06:31 +0100 From: Jon Peatfield Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, that is preciselly my point. It includes . > To support INET6 definitions it would need to include > (or those defs would need to be in linux/in.h) *and* define things > that depend on the presence of those kernel includes. Ahem is a *kernel* header, not a libc one. It does know what is in the kernel, and can define AF_INET6 stuff all it wants. I'm sure that this is getting away from the initial discussion about whether there _should_ be 2 include files or not. -- Jon ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 6 09:11:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29195; Fri, 6 Sep 96 09:11:15 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29189; Fri, 6 Sep 96 09:11:01 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA17627; Fri, 6 Sep 1996 09:05:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA22439; Fri, 6 Sep 1996 09:04:49 -0700 Received: from tott.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id SAA23813; Fri, 6 Sep 1996 18:03:54 +0200 (MET DST) Message-Id: <199609061603.SAA23813@brahma.sics.se> X-Mailer: exmh version 1.6.7 5/3/96 To: qv@iol.unh.edu (Quaizar Vohra) Cc: ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 2089) Re: Some questions. In-Reply-To: Your message of "Thu, 05 Sep 1996 12:18:53 EDT." <9609051618.AA29665@iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 Sep 1996 18:03:52 +0200 From: Peter Sjodin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Quaizar, > 3)Is there a document on source address selection in IPv6. I have > some concerns regarding this issue. I think we should have atleast a > set of guidelines regarding this. For example : > > Consider the scenario of a dual node A which has a tunneling interface > with a v4-compatible address ::A and a global IPv6 address G. Now > consider an isolated host B with a v4-compatible ::B. Now A has a UDP > server application running which is bound to a well known port and the > wildcard address i.e. all zeros IPv6 addresss. Now a client > application on B sends a packet to the server appl. on A using A's > global address G (which it got via DNS) as destination. When the > server application replies, it will use ::A as source address if > source address selection is done in the same fashion as is being done > for v4, as I can see on BSD based code, i.e use the address of the > outgoing interface address as source unless specified by the user > explicitly. I don't see anything wrong with this. It seems like a reasonable source address selection algorithm to pick an IPv4-compatible source address when the destination address is IPv4-compatible. There is no such thing as a "reply" in UDP, so if you want a request/reply protocol, you need to do that on top of UDP. So I think in this case the application should have provided the source address. I am, however, not comfortable with the view that a tunnel interface is a real interface with an IPv6 address. To me, a tunnel interface (or *pseudo*-interface, really) is just an implementation trick, and I don't see why it would need any particular kind of address. If you don't want node A to use ::A as source address, then A shouldn't have an interface with that address! (A could still tunnel to B, since it has an IPv4 address.) Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 9 10:44:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01070; Mon, 9 Sep 96 10:44:53 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00803; Mon, 9 Sep 96 08:40:22 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA13017; Mon, 9 Sep 1996 08:34:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA05431; Mon, 9 Sep 1996 08:34:24 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA07921; Mon, 9 Sep 96 11:28:40 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id LAA11554; Mon, 9 Sep 1996 11:35:43 -0400 Date: Mon, 9 Sep 1996 11:35:43 -0400 Message-Id: <199609091535.LAA11554@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: Peter Sjodin Cc: qv@iol.unh.edu (Quaizar Vohra), ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 2090) Re: Some questions. In-Reply-To: <199609061603.SAA23813@brahma.sics.se> References: <9609051618.AA29665@iol.unh.edu> <199609061603.SAA23813@brahma.sics.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Peter, > Hi Quaizar, > > > 3)Is there a document on source address selection in IPv6. I have > > some concerns regarding this issue. I think we should have atleast a > > set of guidelines regarding this. For example : > > > > Consider the scenario of a dual node A which has a tunneling interface > > with a v4-compatible address ::A and a global IPv6 address G. Now > > consider an isolated host B with a v4-compatible ::B. Now A has a UDP > > server application running which is bound to a well known port and the > > wildcard address i.e. all zeros IPv6 addresss. Now a client > > application on B sends a packet to the server appl. on A using A's > > global address G (which it got via DNS) as destination. When the > > server application replies, it will use ::A as source address if > > source address selection is done in the same fashion as is being done > > for v4, as I can see on BSD based code, i.e use the address of the > > outgoing interface address as source unless specified by the user > > explicitly. > > I don't see anything wrong with this. It seems like a reasonable source > address selection algorithm to pick an IPv4-compatible source address when the > destination address is IPv4-compatible. There is no such thing as a "reply" in > UDP, so if you want a request/reply protocol, you need to do that on top of > UDP. So I think in this case the application should have provided the source > address. I agree with you here. My purpose was to find out what is the consensus on correct behaviour. > > I am, however, not comfortable with the view that a tunnel interface is a real > interface with an IPv6 address. To me, a tunnel interface (or > *pseudo*-interface, really) is just an implementation trick, and I don't see > why it would need any particular kind of address. If you don't want node A to > use ::A as source address, then A shouldn't have an interface with that > address! (A could still tunnel to B, since it has an IPv4 address.) > > Peter > Well a while ago I argued that we don't need v4-compatible addresses (though now I agree that they are useful on isolated nodes) for similar reasons. My real worry is that do we move away from the IPv4 BSDish behaviour of using an address on the outgoing interface and how ? Obviously in IPv4 there was no notion of scopes and uncomfortable addresses like v4-compatible, but now since such notions exists we need to have a different algorithm for source address selection. If we still follow the old way, we will end up choosing link-local address as source in most cases. Now my concern is should we use source address, other than any address on the outgoing interface if forced. For example, if I have a node with 2 interfaces X & Y. X is assigned a global address G while Y doesn't have a global address but a site-local address S. But my default route is thru Y. If I am sending a packet to an off-link global address which matches the default route, I should be using G rather than S. Though common-sense suggests that such cases should not occur, but still I want input from people with more experience. It makes one feel that these global addresses were more anycastish with one per node as a whole ;-). Also I feel that nodes with global addresses e.g. ISP based should keep away form using v4-compatible address as source. I think it is time that someone defines clearly the role of v4-comptible addresses. Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 9 11:29:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01129; Mon, 9 Sep 96 11:29:17 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01123; Mon, 9 Sep 96 11:29:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA23901; Mon, 9 Sep 1996 11:23:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA15352; Mon, 9 Sep 1996 11:22:25 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA09219; Mon, 9 Sep 96 14:16:50 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9609091816.AA09219@iol.unh.edu> Subject: (IPng 2091) Re: Some questions To: ipng@sunroof.eng.sun.com (ipng) Date: Mon, 9 Sep 1996 14:16:49 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Peter, > Hi Quaizar, > > > 3)Is there a document on source address selection in IPv6. I have > > some concerns regarding this issue. I think we should have atleast a > > set of guidelines regarding this. For example : > > > > Consider the scenario of a dual node A which has a tunneling interface > > with a v4-compatible address ::A and a global IPv6 address G. Now > > consider an isolated host B with a v4-compatible ::B. Now A has a UDP > > server application running which is bound to a well known port and the > > wildcard address i.e. all zeros IPv6 addresss. Now a client > > application on B sends a packet to the server appl. on A using A's > > global address G (which it got via DNS) as destination. When the > > server application replies, it will use ::A as source address if > > source address selection is done in the same fashion as is being done > > for v4, as I can see on BSD based code, i.e use the address of the > > outgoing interface address as source unless specified by the user > > explicitly. > > I don't see anything wrong with this. It seems like a reasonable source > address selection algorithm to pick an IPv4-compatible source address when the > destination address is IPv4-compatible. There is no such thing as a "reply" in > UDP, so if you want a request/reply protocol, you need to do that on top of > UDP. So I think in this case the application should have provided the source > address. I agree with you here. My purpose was to find out what is the consensus on correct behaviour. > > I am, however, not comfortable with the view that a tunnel interface is a real > interface with an IPv6 address. To me, a tunnel interface (or > *pseudo*-interface, really) is just an implementation trick, and I don't see > why it would need any particular kind of address. If you don't want node A to > use ::A as source address, then A shouldn't have an interface with that > address! (A could still tunnel to B, since it has an IPv4 address.) > > Peter > Well a while ago I argued that we don't need v4-compatible addresses (though now I agree that they are useful on isolated nodes) for similar reasons. My real worry is that do we move away from the IPv4 BSDish behaviour of using an address on the outgoing interface and how ? Obviously in IPv4 there was no notion of scopes and uncomfortable addresses like v4-compatible, but now since such notions exists we need to have a different algorithm for source address selection. If we still follow the old way, we will end up choosing link-local address as source in most cases. Now my concern is should we use source address, other than any address on the outgoing interface if forced. For example, if I have a node with 2 interfaces X & Y. X is assigned a global address G while Y doesn't have a global address but a site-local address S. But my default route is thru Y. If I am sending a packet to an off-link global address which matches the default route, I should be using G rather than S. Though common-sense suggests that such cases should not occur, but still I want input from people with more experience. It makes one feel that these global addresses were more anycastish with one per node as a whole ;-). Also I feel that nodes with global addresses e.g. ISP based should keep away form using v4-compatible address as source. I think it is time that someone defines clearly the role of v4-comptible addresses. Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 9 12:10:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01175; Mon, 9 Sep 96 12:10:33 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01169; Mon, 9 Sep 96 12:10:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03851; Mon, 9 Sep 1996 12:04:36 -0700 From: bound@ZK3.DEC.COM Received: by mercury.Sun.COM (Sun.COM) id MAA00728; Mon, 9 Sep 1996 12:04:06 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA26225; Mon, 9 Sep 1996 14:58:32 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA07419; Mon, 9 Sep 1996 14:58:32 -0400 Message-Id: <9609091858.AA07419@fwasted.zk3.dec.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 2092) Re: Some questions. In-Reply-To: Your message of "Mon, 09 Sep 96 11:35:43 EDT." <199609091535.LAA11554@sparky.IOL.UNH.EDU> Date: Mon, 09 Sep 96 14:58:31 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Get rid of v4 compatible addresses as far as ISP and NAPs are concerned. After that its just a transition tool that should not be used on the real Internet. I am going to connect with several ISPs and NAPs and get their thoughts in person I can't take this guessing game anymore. This should be discussed on NGTRANS I think NOT IPng.... /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 10 06:46:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01896; Tue, 10 Sep 96 06:46:41 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01890; Tue, 10 Sep 96 06:46:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA02089; Tue, 10 Sep 1996 06:40:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA08687; Tue, 10 Sep 1996 06:40:50 -0700 Received: from tott.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id PAA26428; Tue, 10 Sep 1996 15:40:08 +0200 (MET DST) Message-Id: <199609101340.PAA26428@brahma.sics.se> X-Mailer: exmh version 1.6.7 5/3/96 To: qv@iol.unh.edu (Quaizar Vohra) Cc: ipng@sunroof.eng.sun.com (ipng), peter@sics.se Subject: (IPng 2093) Re: Some questions In-Reply-To: Your message of "Mon, 09 Sep 1996 14:16:49 EDT." <9609091816.AA09219@iol.unh.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Sep 1996 15:40:02 +0200 From: Peter Sjodin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Quaizar, > Well a while ago I argued that we don't need v4-compatible addresses > (though now I agree that they are useful on isolated nodes) for > similar reasons. > > My real worry is that do we move away from the IPv4 BSDish behaviour > of using an address on the outgoing interface and how ? > > Obviously in IPv4 there was no notion of scopes and uncomfortable > addresses like v4-compatible, but now since such notions exists > we need to have a different algorithm for source address selection. > > If we still follow the old way, we will end up choosing link-local > address as source in most cases. > > Now my concern is should we use source address, other than > any address on the outgoing interface if forced. For example, > if I have a node with 2 interfaces X & Y. X is assigned a global > address G while Y doesn't have a global address but a site-local > address S. But my default route is thru Y. If I am sending a packet > to an off-link global address which matches the default route, I > should be using G rather than S. Though common-sense suggests that > such cases should not occur, but still I want input from people with > more experience. It shouldn't matter if you are tunneling or not, you could still take the source address from the outgoing interface: The outgoing interface of a tunnel is one of the node's physical interfaces, and not the tunnel pseudo-interface (so if a node has an IPv4-compatible address, it belongs to the physical interface). The source address selection algorithm locates the outgoing physical interface and picks the most suitable address from there. But I don't think BSD-based implementations typically require that the source address is an address of the outgoing interface. The default is to pick an address of the outgoing interface, but it can be overridden by higher levels, and then the only check is that the source address is one of the node's addresses. This is what our implementation does for IPv6 too, and for the moment I don't see any reason to change it. Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 10 09:28:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02147; Tue, 10 Sep 96 09:28:55 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02110; Tue, 10 Sep 96 09:28:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26890; Tue, 10 Sep 1996 09:21:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA08145; Tue, 10 Sep 1996 09:20:58 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA21693; Tue, 10 Sep 96 12:15:23 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id MAA12866; Tue, 10 Sep 1996 12:22:38 -0400 Date: Tue, 10 Sep 1996 12:22:38 -0400 Message-Id: <199609101622.MAA12866@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: Peter Sjodin Cc: qv@iol.unh.edu (Quaizar Vohra), ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 2094) Re: Some questions In-Reply-To: <199609101340.PAA26428@brahma.sics.se> References: <9609091816.AA09219@iol.unh.edu> <199609101340.PAA26428@brahma.sics.se> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Peter, > Hi Quaizar, > > > Well a while ago I argued that we don't need v4-compatible addresses > > (though now I agree that they are useful on isolated nodes) for > > similar reasons. > > > > My real worry is that do we move away from the IPv4 BSDish behaviour > > of using an address on the outgoing interface and how ? > > > > Obviously in IPv4 there was no notion of scopes and uncomfortable > > addresses like v4-compatible, but now since such notions exists > > we need to have a different algorithm for source address selection. > > > > If we still follow the old way, we will end up choosing link-local > > address as source in most cases. > > > > Now my concern is should we use source address, other than > > any address on the outgoing interface if forced. For example, > > if I have a node with 2 interfaces X & Y. X is assigned a global > > address G while Y doesn't have a global address but a site-local > > address S. But my default route is thru Y. If I am sending a packet > > to an off-link global address which matches the default route, I > > should be using G rather than S. Though common-sense suggests that > > such cases should not occur, but still I want input from people with > > more experience. > > It shouldn't matter if you are tunneling or not, you could still take the > source address from the outgoing interface: The outgoing interface of a tunnel > is one of the node's physical interfaces, and not the tunnel pseudo-interface > (so if a node has an IPv4-compatible address, it belongs to the physical > interface). The source address selection algorithm locates the outgoing > physical interface and picks the most suitable address from there. > I think we have argued a lot about whether to have or not to have v4-compatible addresses on physical interfaces. Most discussions I have had leads me to the conclusion that we should not have v4-compatible addresses on physical interfaces. The reason is : If we start having v4-compatible addresses on physical interfaces, then we'll have to have tunneling enabled on all such nodes because isolated nodes might tunnel packets directly to such nodes. This means that either all nodes in the world have tunneling enabled and this means slow transition. Or only nodes who do tunneling have the v4-compatible address assigned to the physical interface. Such nodes would be dual routers on boundaries of IPv6 domains like on the current 6-bone. In that case the v4-compatible address on the physical interface is of not much use. I don't see what purpose v4-compatible address on physical interfaces serve ? Link-local addresses and rfc1897 addresses are out there to be used on physical interfaces. Should we have a kind of informal vote on this on the list. Or are we waiting for some more experience ? On the subject of source address selection I would agree that if the packet is being sent via a tunnel, an appropraite address might be selected from the outgoing physical interface. But if that physical interface lacks a suitable v6 address then in that case v4-compatible address from the tunnel interface can be choosen. But as we have v4-compatible addresses for transition, i.e. connecting distant v6 clouds over v4-infrastructure, let us limit their scope to that functionality. I would suggest that the source address selection algorithm should choose the best matching address on the node, irrespective of the outgoing interface unless explicitly told by upper layers. Even if we forget the v4-compatible address for the time being and consider my above example about a multihomed node with interfaces X and Y, the question still persists wether we chose the site-local address S as the source or the global address G when sending packets to a distant global address, when nothing has been specified by the upper layer. > But I don't think BSD-based implementations typically require that the source > address is an address of the outgoing interface. The default is to pick an > address of the outgoing interface, but it can be overridden by higher levels, > and then the only check is that the source address is one of the node's > addresses. This is what our implementation does for IPv6 too, and for the > moment I don't see any reason to change it. > > Peter > I apologize for the last mail which I duplicated by mistake on the list. Regards Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 10 11:06:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02333; Tue, 10 Sep 96 11:06:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02327; Tue, 10 Sep 96 11:06:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA00684; Tue, 10 Sep 1996 11:00:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA18699; Tue, 10 Sep 1996 10:59:38 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0v0X4U-000ZBkC; Tue, 10 Sep 96 10:58 PDT Message-Id: Date: Tue, 10 Sep 96 10:58 PDT From: Michael Gersten To: ipng@sunroof.eng.sun.com, peter@sics.se, qv@iol.unh.edu Subject: (IPng 2095) Re: Some questions. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My thoughts on the outgoing address question: The address used as 'source' on any given link SHOULD be a configurable option. It MAY default to the link's address (or more specifically, the incoming address of the port associated with that link), but SHOULD be resettable by the administrator to any address. AND Administrators SHOULD set the address to an address actually used by the machine, or by one of its interfaces. Why would you want to play games? I can imagine a virtual firewall software system, where one machine acts as both firewall, and runs software behind the firewall. Such a machine would want some addresses for "behind" the firewall that are not the addresses of any of the physical ports on the machine. Michael ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 11 09:59:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03204; Wed, 11 Sep 96 09:59:38 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03198; Wed, 11 Sep 96 09:59:25 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA24103; Wed, 11 Sep 1996 09:53:45 -0700 Received: from brahma.sics.se by venus.Sun.COM (Sun.COM) id JAA03761; Wed, 11 Sep 1996 09:53:45 -0700 Received: from tott.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id SAA19661; Wed, 11 Sep 1996 18:53:29 +0200 (MET DST) Message-Id: <199609111653.SAA19661@brahma.sics.se> X-Mailer: exmh version 1.6.7 5/3/96 To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com (ipng), peter@sics.se Subject: (IPng 2096) Re: Some questions In-Reply-To: Your message of "Tue, 10 Sep 1996 12:22:38 EDT." <199609101622.MAA12866@sparky.IOL.UNH.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 11 Sep 1996 18:53:27 +0200 From: Peter Sjodin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Quaizar, > I don't see what purpose v4-compatible address on physical interfaces > serve ? Link-local addresses and rfc1897 addresses are out there to > be used on physical interfaces. > > Should we have a kind of informal vote on this on the list. Or are > we waiting for some more experience ? I don't want to reiterate an old discussion, the point I wanted to make is that addresses belong to physical interfaces, not pseudo-interfaces. Your argument seems to be against using IPv4-compatible addresses; I see your point, but we should probably move that discussion to the ngtrans list. > On the subject of source address selection I would agree that if the > packet is being sent via a tunnel, an appropraite address might be > selected from the outgoing physical interface. But if that > physical interface lacks a suitable v6 address then in that case > v4-compatible address from the tunnel interface can be choosen. > But as we have v4-compatible addresses for transition, i.e. connecting > distant v6 clouds over v4-infrastructure, let us limit their scope > to that functionality. I would suggest that the source address > selection algorithm should choose the best matching address on the > node, irrespective of the outgoing interface unless explicitly told > by upper layers. That would go against the Host Requirements RFC, which suggests that the source address should be taken from the outgoing interface. Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 11 12:43:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03342; Wed, 11 Sep 96 12:43:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03336; Wed, 11 Sep 96 12:42:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA04451; Wed, 11 Sep 1996 12:36:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA10518; Wed, 11 Sep 1996 12:36:30 -0700 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id MAA20699; Wed, 11 Sep 1996 12:36:19 -0700 Date: Wed, 11 Sep 1996 12:36:19 -0700 From: Ran Atkinson Message-Id: <199609111936.MAA20699@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2097) Source Address selection In-Reply-To: <199609111653.SAA19661@brahma.sics.se> References: <199609101622.MAA12866@sparky.IOL.UNH.EDU> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In an earlier article, someone wrote: > I would suggest that the source address selection algorithm should choose > the best matching address on the node, irrespective of the outgoing > interface unless explicitly told by upper layers. This is sensible, though I would soften the words "the best" to "a reasonable". In the case where an outbound interface had a global IPv6 address, that would usually be the best selection. However, this allows for cases where that might not be true or where the outbound interface might not have its own global IPv6 address. Folks familiar with point-to-point interfaces or sub-interfaces on existing IPv4 cisco routers will recall the notion of an "unnumbered" interface. Existing IPv4 and IPv6 cisco routers support this concept, in which the router admin configures a tunnel or point-to-point interface to use another specified (numbered) interface's addresses for packets originating on that tunnel/point-to-point interface where the upper-layers have not explicitly set a Source Address for the outbound packet. Note that each tunnel/point-to-point interface has its own IPv6 link-local address even if the "unnumbered" configuration is in use. We have this feature in direct response to customer demand for it. I am using it for my tunnels on 6bone-router.cisco.com because it simplifies configuration of the router. In article <199609111653.SAA19661@brahma.sics.se> Peter wrote: >That would go against the Host Requirements RFC, which suggests that the >source address should be taken from the outgoing interface. I'm not aware of _any_ IPv4 implementation that fully conforms with the IPv4 Host Requirements document. In any event, that document doesn't necessarily apply to IPv6. Best regards, Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 12 13:31:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04349; Thu, 12 Sep 96 13:31:44 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04343; Thu, 12 Sep 96 13:31:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA21518; Thu, 12 Sep 1996 13:24:37 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA06832; Thu, 12 Sep 1996 13:24:37 -0700 Received: from [193.10.66.186] by brahma.sics.se (8.7.3/SICS) with SMTP id WAA21238; Thu, 12 Sep 1996 22:23:00 +0200 (MET DST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Sep 1996 22:23:23 +0200 To: Ran Atkinson , ipng@sunroof.eng.sun.com From: peter@sics.se (Peter Sjodin) Subject: (IPng 2098) Re: Source Address selection Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran Atkinson wrote: >In an earlier article, someone wrote: >> I would suggest that the source address selection algorithm should choose >> the best matching address on the node, irrespective of the outgoing >> interface unless explicitly told by upper layers. > >This is sensible, though I would soften the words "the best" to "a >reasonable". In the case where an outbound interface had a global >IPv6 address, that would usually be the best selection. However, >this allows for cases where that might not be true or where the >outbound interface might not have its own global IPv6 address. Is it desirable in those cases that the source address is taken from some other interface? I'm not so sure. What happens with discovery for instance? Assume a node sends a packet to its default router via interface A, using an address of another interface B as source address. If the default router needs to send a redirect message back to the node, it can't do that, since it can't figure out that the packet comes from a neighbor. Is the solution to modify neighbor discovery so that a multihomed node does neighbor discovery for all its global addresses on every interface? The more conservative approach is to restrict automatic address selection to the outgoing interface. This gives a simpler algorithm, and neighbor discovery will work for auto-selected addresses. And if you are sending a packet out through an interface that doesn't have an address with sufficient scope, you will find that you are trying to do something which, for some reason, your node is not configured to support. Perhaps that kind of control is useful to have. >I'm not aware of _any_ IPv4 implementation that fully conforms with >the IPv4 Host Requirements document. In any event, that document >doesn't necessarily apply to IPv6. With a source address selection algorithm that can take the address from any interface, the Internet Host Requirements RFC definitely needs to be revised for IPv6 (if that document should have any significance). Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 12 14:03:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04387; Thu, 12 Sep 96 14:03:35 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04381; Thu, 12 Sep 96 14:03:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA28538; Thu, 12 Sep 1996 13:57:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA17797; Thu, 12 Sep 1996 13:56:50 -0700 Received: (rja@localhost) by puli.cisco.com (8.6.12/8.6.5) id NAA01444; Thu, 12 Sep 1996 13:56:14 -0700 Message-Id: <199609122056.NAA01444@puli.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Thu, 12 Sep 1996 13:56:14 PDT In-Reply-To: peter@sics.se (Peter Sjodin) "Re: (IPng 2097) Source Address selection" (Sep 12, 10:23pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: peter@sics.se (Peter Sjodin), Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 2099) Re: Source Address selection Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, There is no adverse impact on ND. It works fine. ND packets are always onlink and hence can always use a link-local source address if one is worried about that. This is how 6bone-router.cisco.com has been working for over 2 months now and there are no problems seen relating in any way to this. Regards, Ran rja@cisco.com -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 12 19:43:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04677; Thu, 12 Sep 96 19:43:43 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04671; Thu, 12 Sep 96 19:43:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA21618; Thu, 12 Sep 1996 19:37:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA25523; Thu, 12 Sep 1996 19:37:48 -0700 Received: from rtpdce02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA372734; Thu, 12 Sep 1996 22:35:20 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce02.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id WAA37890; Thu, 12 Sep 1996 22:35:18 -0400 Received: from [10.32.57.70] by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA20131; Thu, 12 Sep 1996 22:37:40 -0400 Received: from hygro.raleigh.ibm.com (narten@loopback [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id KAA00224; Thu, 12 Sep 1996 10:38:03 -0400 Message-Id: <199609121438.KAA00224@hygro.raleigh.ibm.com> To: peter@sics.se (Peter Sjodin) Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 2100) Re: Source Address selection In-Reply-To: Your message of "Thu, 12 Sep 1996 22:23:23 +0200." Date: Thu, 12 Sep 1996 10:38:03 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, >Is it desirable in those cases that the source address is taken from some >other interface? I'm not so sure. What happens with discovery for instance? >Assume a node sends a packet to its default router via interface A, using >an address of another interface B as source address. If the default router >needs to send a redirect message back to the node, it can't do that, since >it can't figure out that the packet comes from a neighbor. Though your point is valid, I think you are arguing a point that can't be won. :-). There are a few pages on this issue in the Host Requirements RFC, under the "strong" and "weak" ES-ES models. Both are allowed because folks could never agree which one was "right". The strict model (which is what you seem to be advocating) has disadvantages too, in some circumstances. >Is the solution >to modify neighbor discovery so that a multihomed node does neighbor >discovery for all its global addresses on every interface? No. The consequence is suboptimal routing, which isn't the end of the world. Better suboptimal than no path at all. Those folks that don't like a suboptimal first-hop should have properly scoped addresses on all their interfaces. To be fair, you are talking specifically about the case of source address selection when selection is needed (e.g., on outgoing connection setup). The more general issue is what to do with packets that must be sent out the "wrong" interface, but whose source address has already been set to that of another interface. The latter is what the Host Requirements document addresses, but I don't think you can reasonably separate the two issues. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 04:51:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04950; Fri, 13 Sep 96 04:51:34 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04944; Fri, 13 Sep 96 04:51:21 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA25099; Fri, 13 Sep 1996 04:45:38 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA09972; Fri, 13 Sep 1996 04:45:39 -0700 Received: from whitec.sr.unh.edu by unh.edu with SMTP id AA26524 (5.67b+/IDA-1.5 for <@unh.edu:ipng@sunroof.Eng.Sun.COM>); Fri, 13 Sep 1996 07:45:36 -0400 Received: by whitec.sr.unh.edu (940816.SGI.8.6.9/921111.SGI) for ipng@sunroof.Eng.Sun.COM id HAA28006; Fri, 13 Sep 1996 07:49:12 -0400 Date: Fri, 13 Sep 1996 07:49:12 -0400 From: Bill.Lenharth@unh.edu (William Lenharth) Message-Id: <199609131149.HAA28006@whitec.sr.unh.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 2101) Dec '96 - IPv6 test period X-Status: N X-Mailer: Applixware 4.0(429.85) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk UNH will hold it's third IPv6 test Period on Dec 1 - 5, 1996 at the New England Center in Durham, NH. Due to space restrictions that test period will be held at the New England Center for Continuing Education with setup to on Sunday the first of December and teardown to complete at 6pm on Thursday. We are sorry for any inconvience that this may cause and UNH personnel will be available to prestage your equipment on Sunday. The test period will cost $1250.00 for non-members and there will be a nominal charge for members to cover the increased food costs at the New England Center. Please check our Web page for updates and advisory information. We advise reserving rooms at the NEC early. We look foreward to seeing you here in sunny New Hampshire. William Lenharth ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 05:33:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04967; Fri, 13 Sep 96 05:33:42 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04961; Fri, 13 Sep 96 05:33:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA27246; Fri, 13 Sep 1996 05:27:44 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA16012; Fri, 13 Sep 1996 05:27:00 -0700 Received: from tott.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id OAA13245; Fri, 13 Sep 1996 14:26:23 +0200 (MET DST) Message-Id: <199609131226.OAA13245@brahma.sics.se> X-Mailer: exmh version 1.6.9 8/22/96 To: rja@Cisco.COM (Ran Atkinson) Cc: peter@sics.se (Peter Sjodin), ipng@sunroof.eng.sun.com Subject: (IPng 2102) Re: Source Address selection In-Reply-To: Your message of "Thu, 12 Sep 1996 13:56:14 PDT." <199609122056.NAA01444@puli.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Sep 1996 14:26:22 +0200 From: Peter Sjodin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Ran, > Peter, > > There is no adverse impact on ND. It works fine. ND packets are > always onlink and hence can always use a link-local source address > if one is worried about that. This is how 6bone-router.cisco.com has > been working for over 2 months now and there are no problems > seen relating in any way to this. In this case I think it would have consequences for ND. If a node uses an off-link address as source address, there is no way for its neighbors to detect that the packet really comes from a neighbor. This means, for instance, that the first-hop router can't send redirects back to the node. Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 05:47:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04987; Fri, 13 Sep 96 05:47:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04981; Fri, 13 Sep 96 05:46:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA28182; Fri, 13 Sep 1996 05:41:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA18864; Fri, 13 Sep 1996 05:41:08 -0700 Received: from tott.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id OAA14545; Fri, 13 Sep 1996 14:41:00 +0200 (MET DST) Message-Id: <199609131241.OAA14545@brahma.sics.se> X-Mailer: exmh version 1.6.9 8/22/96 To: Thomas Narten Cc: Ran Atkinson , ipng@sunroof.eng.sun.com Subject: (IPng 2103) Re: Source Address selection In-Reply-To: Your message of "Thu, 12 Sep 1996 10:38:03 EDT." <199609121438.KAA00224@hygro.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Sep 1996 14:40:58 +0200 From: Peter Sjodin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, > To be fair, you are talking specifically about the case of source > address selection when selection is needed (e.g., on outgoing > connection setup). The more general issue is what to do with packets > that must be sent out the "wrong" interface, but whose source address > has already been set to that of another interface. The latter is what > the Host Requirements document addresses, but I don't think you can > reasonably separate the two issues. Strong vs Weak ES and automatic source address selection are separate issues in the RFC, and yes, my argument concerned only the latter. I was trying to argue that the algorithm in the RFC would be a good one also for IPv6: it's a simple, conservative algorithm that would do the right thing when there are no scope conflicts, and otherwise most likely trigger an error notification. However, if the priority is to always try to deliver the packet, then of course the algorithm shouldn't worry about which interface it is. But then the RFC needs to be revised. Regarding Strong vs. Weak ES, since you brought it up. :-) I guess the main problem here is that protocols like TCP use addresses to identify connections, which may force a node to send packets with "wrong" source address. But given the dynamic nature of address assignment in IPv6, this is something that needs to be fixed anyway, and my understanding is that work is in progress on this. So that particular argument for sending packets with the "wrong" address will hopefully go away (yes, I guess I'm in favour of the Strong ES Model!). Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 06:06:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05004; Fri, 13 Sep 96 06:06:03 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04998; Fri, 13 Sep 96 06:05:50 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29660; Fri, 13 Sep 1996 06:00:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA23019; Fri, 13 Sep 1996 06:00:09 -0700 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA75008; Fri, 13 Sep 1996 08:57:40 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id IAA60094 for ; Fri, 13 Sep 1996 08:57:41 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA20461; Fri, 13 Sep 1996 08:59:55 -0400 Message-Id: <9609131259.AA20461@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2104) Re: Source Address selection In-Reply-To: Your message of "Wed, 11 Sep 1996 12:36:19 PDT." <199609111936.MAA20699@puli.cisco.com> Date: Fri, 13 Sep 1996 08:59:54 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >In article <199609111653.SAA19661@brahma.sics.se> Peter wrote: >>That would go against the Host Requirements RFC, which suggests that the >>source address should be taken from the outgoing interface. Actually, a quick search of the HR RFC leads me to no such conclusion, though this is probably an issue of poor word choice rather than lack of intent. For example: > (b) The route cache may be consulted, to see if there > is an active route to the specified destination > network through any network interface; if so, a > local IP address corresponding to that interface > may be chosen. One would have to intepret "may" as "should" in order to draw the original conclusion. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 07:17:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05028; Fri, 13 Sep 96 07:17:33 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05022; Fri, 13 Sep 96 07:17:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06009; Fri, 13 Sep 1996 07:11:38 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA11996; Fri, 13 Sep 1996 07:11:38 -0700 Received: from tott.sics.se by brahma.sics.se (8.7.3/SICS) with ESMTP id QAA22926; Fri, 13 Sep 1996 16:11:34 +0200 (MET DST) Message-Id: <199609131411.QAA22926@brahma.sics.se> X-Mailer: exmh version 1.6.9 8/22/96 To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2105) Re: Source Address selection In-Reply-To: Your message of "Fri, 13 Sep 1996 08:59:54 -0300." <9609131259.AA20461@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Sep 1996 16:11:33 +0200 From: Peter Sjodin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Thomas, > >In article <199609111653.SAA19661@brahma.sics.se> Peter wrote: > >>That would go against the Host Requirements RFC, which suggests that the > >>source address should be taken from the outgoing interface. > > Actually, a quick search of the HR RFC leads me to no such conclusion, > though this is probably an issue of poor word choice rather than lack > of intent. For example: > > > (b) The route cache may be consulted, to see if there > > is an active route to the specified destination > > network through any network interface; if so, a > > local IP address corresponding to that interface > > may be chosen. > > One would have to intepret "may" as "should" in order to draw the > original conclusion. Note though that the RFC does not suggest that the address "may" be taken from an interface that would not be the outgoing interface. Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 08:33:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05089; Fri, 13 Sep 96 08:33:43 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05083; Fri, 13 Sep 96 08:33:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA16426; Fri, 13 Sep 1996 08:27:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA05425; Fri, 13 Sep 1996 08:27:47 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA27429; Fri, 13 Sep 96 11:22:29 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id LAA07155; Fri, 13 Sep 1996 11:29:46 -0400 Date: Fri, 13 Sep 1996 11:29:46 -0400 Message-Id: <199609131529.LAA07155@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: ipng@sunroof.eng.sun.com Subject: (IPng 2106) Re: Source Address selection Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think a higher priority needs to be given to delivery of a packet and that is what leads us to move towards weak ES model in case of multihomed hosts. And with scoped addresses this becomes even more important. A good example where a node might be forced to originate a packet thru with a source address different from outgoing interface is a node with two interfaces X & Y and each receiving RAs from router RX & RY respectively. Say RX advertises a prefix G with global scope while RY advertises a prefix S with site-local scope. Also both routers advertise themselves as default routers. Now if RX dies, then the only default router for the node is RY, which is on interface Y. If the node has to originate packet for a dest. address with global scope should it drop the packet returning icmp error 'dest. unreachable' or should it use G as source address and route it thru interface Y. I think later is a better option. Then the question is should router RY claim to be a default router. After all the network administrator would have some purpose in configuring his network so. Probably he wants RY to do routing for the site only but in case of failure of RX, RY might have a suboptimal default route to outside. Another interesting scenario is when both RX and RY are up and the node wants to send a packet to a sitelocal (offlink) address which has a better match with S, but the default router selection algorithm as per ND draft has chosen RX as a default router. Wouldn't it be more interesting for routers to advertise prefixes for which they route instead of just claiming that they are default routers. Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 08:39:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05101; Fri, 13 Sep 96 08:39:30 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05095; Fri, 13 Sep 96 08:39:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17527; Fri, 13 Sep 1996 08:33:36 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id IAA07619; Fri, 13 Sep 1996 08:33:36 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA04472; Fri, 13 Sep 1996 11:22:53 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24565; Fri, 13 Sep 1996 11:22:51 -0400 Message-Id: <9609131522.AA24565@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2107) Re: Source Address selection In-Reply-To: Your message of "Thu, 12 Sep 96 10:38:03 EDT." <199609121438.KAA00224@hygro.raleigh.ibm.com> Date: Fri, 13 Sep 96 11:22:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 1122 don't apply in most places anymore. RFC 1123 don't in many cases because of IPv6 effect on Sockets, Bigger Addresses, and several new enhancements from IPv6 that can be used by applications once they are ported to take advantage of IPv6 features (as opposed to just port them to use bigger addresses) e.g. flows, source routing, security... As far as specifying a source address I thought the memo from Atushi Onoe (WIDE Project) had the beginnings of the problem and some decisions correct. I think multihoming is an entire different issue. We need to understand how to select a source address for "an" interface. In the Mike Shand multihoming spec we need to ask Mike to address this issue and we should discuss at San Jose IMHO as another agenda item to the Chairs. Another issue thats bothering me that I would like to start a discussion on as its confusing me: Why is selecting a source address a Standards issue (in this case IETF) and not just an implementation issue? At the UNH bake-off a lot of us have been interoperating and doing this for some time (well over a year in many cases) I don't see the problem as a standards issue but an engineering issue (barring the Multihome case). ????? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 08:59:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05129; Fri, 13 Sep 96 08:59:42 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05119; Fri, 13 Sep 96 08:59:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA21449; Fri, 13 Sep 1996 08:53:43 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA15490; Fri, 13 Sep 1996 08:53:43 -0700 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA938084; Fri, 13 Sep 1996 11:51:03 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id LAA27028; Fri, 13 Sep 1996 11:51:04 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA17491; Fri, 13 Sep 1996 11:53:27 -0400 Message-Id: <9609131553.AA17491@cichlid.raleigh.ibm.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2108) Re: Source Address selection In-Reply-To: Your message of "Fri, 13 Sep 1996 11:29:46 EDT." <199609131529.LAA07155@sparky.IOL.UNH.EDU> Date: Fri, 13 Sep 1996 11:53:27 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quaizar, >Wouldn't it be more interesting for routers to advertise prefixes for >which they route instead of just claiming that they are default >routers. Interesting? Yes. Benefits? Yes. Worth the hassle? Not at all clear. You are not proposing a new idea; this has been discussed many times in the past. You are essentially turning a host into more of a router. This has many ramifications, not all of which are positive. For singly-homed hosts, there is very little benefit to doing this (but a lot of complexity is added!). The benefit would be for multihomed hosts, which are a completely different problem. While I think a mechanism is needed, I would argue that ND is not the place to fix this. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 09:12:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05170; Fri, 13 Sep 96 09:12:32 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05164; Fri, 13 Sep 96 09:12:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA24251; Fri, 13 Sep 1996 09:06:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA20642; Fri, 13 Sep 1996 09:06:36 -0700 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA33428; Fri, 13 Sep 1996 12:01:34 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id MAA47818; Fri, 13 Sep 1996 12:01:35 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA19813; Fri, 13 Sep 1996 12:03:58 -0400 Message-Id: <9609131603.AA19813@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2109) Re: Source Address selection In-Reply-To: Your message of "Fri, 13 Sep 1996 11:22:51 EDT." <9609131522.AA24565@fwasted.zk3.dec.com> Date: Fri, 13 Sep 1996 12:03:58 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com writes: >RFC 1122 don't apply in most places anymore. Whether it applies are not is a somewhat silly discussion. Of course it still applies, in the sense that many of the issues that resulted in items in 1122 still apply. Any v6 requirements document would start with 1122 as a base. The "weak" vs "strong" model is a good example. My citing of it was not intended to imply that because the spec says so, we're stuck with it. Rather, 1122 says either model is OK precisely because there were proponents for both sides and there was no way to compromise. I'd bet $$ that is still the case today. The basic arguments haven't changed with IPv6, from what I can see. >RFC 1123 don't in many cases because of IPv6 effect on Sockets, Bigger >Addresses, and several new enhancements from IPv6 that can be used by >applications once they are ported to take advantage of IPv6 features (as >opposed to just port them to use bigger addresses) e.g. flows, source >routing, security... But that doesn't automatically obsolete every recommendation. >I think multihoming is an entire different issue. I agree 100% here. We need to be careful not to confuse issues that are multihoming issues (and may require special mechanisms) from those that are not an issue with singly-homed machines. >Why is selecting a source address a Standards issue (in this case IETF) >and not just an implementation issue? To say it is an implementation issue suggests that it doesn't matter at all (from an architecture/interoperability perspective) what folks do. This is not the case, since it is highly desirable to have packets sent on an interface have a source address on that interface. I think the topic needs to be *discussed* precisely because the issues/solutions are not entirely understood. Whether they get written up and made a standard is a secondary issue. I don't think we are quite at that point yet. >At the UNH bake-off a lot of us >have been interoperating and doing this for some time (well over a year >in many cases) I don't see the problem as a standards issue but an >engineering issue (barring the Multihome case). Just because systems interoperated doesn't mean that all issues are understood. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 09:58:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05227; Fri, 13 Sep 96 09:58:02 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05221; Fri, 13 Sep 96 09:57:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA05447; Fri, 13 Sep 1996 09:51:40 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id JAA09384; Fri, 13 Sep 1996 09:51:25 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA20356; Fri, 13 Sep 1996 12:38:57 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00609; Fri, 13 Sep 1996 12:38:57 -0400 Message-Id: <9609131638.AA00609@fwasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2110) Re: Source Address selection In-Reply-To: Your message of "Fri, 13 Sep 96 12:03:58 -0300." <9609131603.AA19813@cichlid.raleigh.ibm.com> Date: Fri, 13 Sep 96 12:38:56 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >>RFC 1122 don't apply in most places anymore. > >Whether it applies are not is a somewhat silly discussion. Of course >it still applies, in the sense that many of the issues that resulted >in items in 1122 still apply. Any v6 requirements document would start >with 1122 as a base. The "weak" vs "strong" model is a good >example. My citing of it was not intended to imply that because the >spec says so, we're stuck with it. Rather, 1122 says either model is >OK precisely because there were proponents for both sides and there >was no way to compromise. I'd bet $$ that is still the case today. The >basic arguments haven't changed with IPv6, from what I can see. First I think silly was an extreme word. Talk to the folks doing AIX implementing the kernel and IPv6 and figure out why I said what I said from an implementation perspective as I was speaking as an implementor not a standards person or wearing my architecture hat. As far as using 1122 or 1123 as a base I disagree as I recall what it took to implement it on our product for the market and the spec is completely bogus as far as readability to understand the test assertions to build a product for the market. I don't agree. You and Eric did a good job on ND and just compare the two specs and what I am driving at I think will be obvious. As far as a table of functions to address in IPv6 from 1122 and 1123 that is about all its good for. >>RFC 1123 don't in many cases because of IPv6 effect on Sockets, Bigger >>Addresses, and several new enhancements from IPv6 that can be used by >>applications once they are ported to take advantage of IPv6 features (as >>opposed to just port them to use bigger addresses) e.g. flows, source >>routing, security... >But that doesn't automatically obsolete every recommendation. Note I used "in many cases" so I agree. >>I think multihoming is an entire different issue. >I agree 100% here. We need to be careful not to confuse issues that >are multihoming issues (and may require special mechanisms) from those >that are not an issue with singly-homed machines. I think you stated that very well. Can we all please use this to focus the discussion. >>Why is selecting a source address a Standards issue (in this case IETF) >>and not just an implementation issue? > >To say it is an implementation issue suggests that it doesn't matter >at all (from an architecture/interoperability perspective) what folks >do. This is not the case, since it is highly desirable to have packets >sent on an interface have a source address on that interface. Of course thats true and I don't know why anyone would argue otherwise. But how I make that happen is not a standards issue. >I think the topic needs to be *discussed* precisely because the >issues/solutions are not entirely understood. Whether they get written >up and made a standard is a secondary issue. I don't think we are >quite at that point yet. Well if I patented how I did source address selection in my kernel I am not going to discuss it right now. But clearly I agree with a discussion if its focused though. >>At the UNH bake-off a lot of us >>have been interoperating and doing this for some time (well over a year >>in many cases) I don't see the problem as a standards issue but an >>engineering issue (barring the Multihome case). > >Just because systems interoperated doesn't mean that all issues are >understood. Well I think its a lot better of a test than a vague and not well focused architecture discussion. Keeping Multihoming out of it would be a good start though. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 10:00:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05240; Fri, 13 Sep 96 10:00:37 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05234; Fri, 13 Sep 96 10:00:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA06237; Fri, 13 Sep 1996 09:54:09 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id JAA10431; Fri, 13 Sep 1996 09:53:50 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA26949; Fri, 13 Sep 1996 12:44:09 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16404; Fri, 13 Sep 1996 12:44:06 -0400 Message-Id: <9609131644.AA16404@fwasted.zk3.dec.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2111) Re: Source Address selection In-Reply-To: Your message of "Fri, 13 Sep 96 11:29:46 EDT." <199609131529.LAA07155@sparky.IOL.UNH.EDU> Date: Fri, 13 Sep 96 12:44:06 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quaizar, I asked exactly for this and with preferences and the answer was no. Could you define where your seeing a multihome issue and where you do not think its a multihome issue. I think we need to separate the two discussions. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 13 20:55:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05921; Fri, 13 Sep 96 20:55:13 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05914; Fri, 13 Sep 96 20:54:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA25693; Fri, 13 Sep 1996 20:49:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA09689; Fri, 13 Sep 1996 20:49:16 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id DA27124; Sat, 14 Sep 1996 13:49:13 +1000 (from kre@munnari.OZ.AU) To: ipng@sunroof.eng.sun.com Subject: (IPng 2112) Re: Source Address selection In-Reply-To: Your message of "Fri, 13 Sep 1996 16:11:33 +0200." <199609131411.QAA22926@brahma.sics.se> Date: Sat, 14 Sep 1996 13:48:46 +1000 Message-Id: <22243.842672926@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 13 Sep 1996 16:11:33 +0200 From: Peter Sjodin Message-ID: <199609131411.QAA22926@brahma.sics.se> Note though that the RFC does not suggest that the address "may" be taken from an interface that would not be the outgoing interface. I find it hard to believe that this issue is being taken very seriously. There's absolutely no way that the source address of a packet can be bound to the interface it is sent through in any way at all. Where the host has the freedom to choose the address it will use, it obviously makes sense to choose an address that is (what it believes) closest to the destination - which will be one from its sending interface. But there are so many cases where this freedom doesn't exist that this is a meaningless discussion (everyone has to cope with all possibilities). I also find it a little hard to believe that Jim Bound really can see a way to hold this discussion at all, and rule out discussion of multi-homed hosts, which is the only situation that this is really a hard problem in the context it was raised. Sure there are issues as to which of several global, site local, and link local, addresses available on an interface should be used for any particular packet - but that choice has no effect whatever on the ability of a first hop router to send a redirect (or similar). Multi-homed hosts are squarely where this problem sits. I would also guess that it is fast becoming time when the questions related to multi-homed hosts need some serious discussion. There hasn't been a lot else of substance discussed here recently. We can't pretend that multi-homed hosts are going to vanish when IPv6 starts being deployed (Jim - I have a whole bunch of multi-homed, non routing, alphas sitting around here right now, with up to 6 interfaces, somehow those things are going to have to work!) kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 15 10:38:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06367; Sun, 15 Sep 96 10:38:02 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA06361; Sun, 15 Sep 96 10:37:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA23080; Sun, 15 Sep 1996 10:32:03 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id KAA16416; Sun, 15 Sep 1996 10:32:05 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id NAA29864; Sun, 15 Sep 1996 13:29:05 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11550; Sun, 15 Sep 1996 13:29:17 -0400 Message-Id: <9609151729.AA11550@fwasted.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2113) Re: Source Address selection In-Reply-To: Your message of "Sat, 14 Sep 96 13:48:46 +1000." <22243.842672926@munnari.OZ.AU> Date: Sun, 15 Sep 96 13:29:16 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I also find it a little hard to believe that Jim Bound really can >see a way to hold this discussion at all, and rule out discussion >of multi-homed hosts, which is the only situation that this is >really a hard problem in the context it was raised. Sure there >are issues as to which of several global, site local, and link >local, addresses available on an interface should be used for >any particular packet - but that choice has no effect whatever on >the ability of a first hop router to send a redirect (or similar). I never said to rule out Multihoming. Differentiate the case for Multihoming and non-Multihoming. If the problem is that we need to address multihoming fine. But lets not discuss it just as a source address selection topic, multihoming is a complete topic. >Multi-homed hosts are squarely where this problem sits. > >I would also guess that it is fast becoming time when the questions >related to multi-homed hosts need some serious discussion. There >hasn't been a lot else of substance discussed here recently. >We can't pretend that multi-homed hosts are going to vanish when >IPv6 starts being deployed (Jim - I have a whole bunch of >multi-homed, non routing, alphas sitting around here right now, with >up to 6 interfaces, somehow those things are going to have to >work!) Fine there is a draft for Multihoming and I think the next release will be a valid IPng working group draft. See attached. If its time to discuss this lets start --->>>>>>>>> "Multi-homed Host Support in IPv6", M. Shand, M. Thomas, 06/11/1996, This document defines various forms of host multihoming, identifies the requirements associated with each and suggests means by which they could be supported in the IPv6 environment. The intention is to provoke discussion, leading to a general consensus as to which scenarios and requirements are important, and which potential solutions are appropriate for further study. It is an update to the previous draft posted in February 1996. We will get those alphas to work with multihoming too for IPv6 you can count on it. So if we want to start this discussion lets do it. Mike and Matt have had this draft out for some time I think now its time to get it into a detailed solution to the problem and a review of this draft. Would someone else change the subject line?????? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 16 08:53:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06945; Mon, 16 Sep 96 08:53:49 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA06938; Mon, 16 Sep 96 08:53:35 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA14317; Mon, 16 Sep 1996 08:47:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA02017; Mon, 16 Sep 1996 08:47:40 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA23414; Mon, 16 Sep 96 11:42:12 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id LAA03465; Mon, 16 Sep 1996 11:49:32 -0400 Date: Mon, 16 Sep 1996 11:49:32 -0400 Message-Id: <199609161549.LAA03465@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: bound@zk3.dec.com Cc: Quaizar Vohra , ipng@sunroof.eng.sun.com Subject: (IPng 2114) Re: Source Address selection In-Reply-To: <9609131644.AA16404@fwasted.zk3.dec.com> References: <199609131529.LAA07155@sparky.IOL.UNH.EDU> <9609131644.AA16404@fwasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > Quaizar, > > I asked exactly for this and with preferences and the answer was no. > > Could you define where your seeing a multihome issue and where you do > not think its a multihome issue. I think we need to separate the two > discussions. > > thanks > /jim Source address selection is not very interesting on single-homed hosts. It degenerates to choosing a best matching prefix. There might be instances when a network administrator might want nodes to drop packets if the interface has no address equivalent in scope to the outgoing packet. But source address selction is not just an important thing for multi-homed hosts, but also routers and nodes with tunneling interfaces. I have been asked to move discussion regarding v4-compatible addresses to the ngtrans list, but as they will affect source address seelction, I think that they be discussed on this list in the source-address selection context. Source address selection issue is born out of v6 scoped addresses and is a more imminent problem then entire multihoming. We have found from IPv4 that it is not such an easy thing to solve, and mutliple models exist which will treat it in different ways as per the needs. And even then let's not just fight our where to solve what. Rather lets concentrate on the problem and come to a consensus. And at the same time lets go on to discuss other things in multihoming. Also another note on Router Advertisemnts : I will agree to Thomas Narten's remark that advertising prefixes which a router can route to moght add complexity to a strong ES model. But then the redirect mechanism also does that and the way it is currently implemented in terms of treating all redirects as host redirects might increase kernel routing tables on hosts, if a host is talking to more than one host on a redirected subnet. Though I will concede that this might be a rare case. This becomes more interesting for multi-homed hosts who prefer weak ES model and I will agree that ND is not the place to solve it. But I think if there are multiple routers on a subnet, they might agree upon advertising themselves as routers for prefixes for which they have the best routes, instead of eventually doing redirects (or not at all doing, but doing sub-optimal forwarding if the originating node used a source address not on the outgoing interface). This might afterall be not such an expensive thing on hosts as compared to running named. Though if we think of a typical subnet with a single router, this mechanism is not needed. If this has been discussed earlier, then my apologies. Regards, Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 16 14:48:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07360; Mon, 16 Sep 96 14:48:47 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07354; Mon, 16 Sep 96 14:48:33 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA08998; Mon, 16 Sep 1996 14:42:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA23500; Mon, 16 Sep 1996 14:42:24 -0700 Received: from [193.10.66.186] by brahma.sics.se (8.7.3/SICS) with SMTP id XAA27984; Mon, 16 Sep 1996 23:39:43 +0200 (MET DST) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Sep 1996 23:40:17 +0200 To: bound@zk3.dec.com From: peter@sics.se (Peter Sjodin) Subject: (IPng 2115) Re: Source Address selection Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, The recent discussions have been about source address selection in the context of multihomed hosts. That's where the real problems are. I fully agree though that source address selection is just one aspect of multihoming, and that source address selection needs to be considered in relation to ND, routing, TCP connection identification, etc., so they all fit together nicely on multihomed hosts. Peter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 16 15:30:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07421; Mon, 16 Sep 96 15:30:10 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07255; Mon, 16 Sep 96 12:28:45 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA06283; Mon, 16 Sep 1996 12:22:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA02030; Mon, 16 Sep 1996 12:22:01 -0700 Received: by mail.noris.net id <35038-6686>; Mon, 16 Sep 1996 21:21:22 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2116) Re: IPv6 BSD API spec Date: 16 Sep 1996 21:20:59 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 21 Message-Id: <51k9ar$dcs@work.smurf.noris.de> References: <199609051540.LAA06511@jekyll.piermont.com> <199609051607.QAA03185@office.ripe.net> <841977784.27763@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: unlisted-recipients:;@mercury (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In dist.ipng, article <841977784.27763@noris.de>, Geert Jan de Groot writes: > > This means that it is probably not a good idea to design a daemon > that listens on port 1024, because it's likely that that port is taken. > Currently, there is no good mechanism to defend against that. > There is. It's called SO_REUSEADDR. > 4096&up: allocated at random Port numbers above 50000(?) are reserved for local protocols. -- When a woman says "No!" she really means "Yes!" -- except, of course, when she means "NO!" -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 16 19:33:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07533; Mon, 16 Sep 96 19:33:15 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07527; Mon, 16 Sep 96 19:33:02 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA10279; Mon, 16 Sep 1996 19:27:09 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id TAA12601; Mon, 16 Sep 1996 19:27:01 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id WAA02785; Mon, 16 Sep 1996 22:15:13 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14826; Mon, 16 Sep 1996 22:15:20 -0400 Message-Id: <9609170215.AA14826@fwasted.zk3.dec.com> To: peter@sics.se (Peter Sjodin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2117) Re: Source Address selection In-Reply-To: Your message of "Mon, 16 Sep 96 23:40:17 +0200." Date: Mon, 16 Sep 96 22:15:20 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Other than the problems of discovery and determining multihome interfaces and the API extraction of interfaces (which will be put forth out shortly) please define for me the actual "STANDARDS" issues for interoperability for: 1) Hosts 2) Routers 3) Relationship to Neighbor Discovery 4) Selection during transport setup connect (udp or tcp) I don't see where anything we can work on will solve a STANDARDS interoperability issue. As far as how "one" implements their source address selection is left to pure engineering ingenuity and let the best implementation win. It has nothing absolutely nothing to do with interoperability. If an implementation cannot select a source address then it has a basic architecture problem in its design. Not a standards problem. Like Quaizar saying that if the admin don't want that scope for that address then the implementation should not send the packet. Thats completely upto the admin and the vendor or implementation they deal with not an IETF issue. Another issue I have is people keep talking about scope of addresses for unicast. RFC 1884 only speaks of scope for Multicast addresses. Not unicast addresses. Now if someone wants to define in a draft: 1. Scopes for Unicast addresses (I think thats not going to fly but go ahead). 2. Where the standards interoperability issues are for source address selection (that would be worthwhile). But in the meantime the Shand draft has depicted many real problems that will affect interoperability for multihome hosts and source address selection. That is real work we can use to discuss and get figured out instead of this conversation. I just feel like we are beating this to death to invent yet another spec for IPv6 and quite frankly unless someone can answer the basic question in detail why its a waste of the WG time IMHO. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 16 20:47:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07595; Mon, 16 Sep 96 20:47:49 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07589; Mon, 16 Sep 96 20:47:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA21492; Mon, 16 Sep 1996 20:41:49 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id UAA27444; Mon, 16 Sep 1996 20:41:49 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id XAA19722; Mon, 16 Sep 1996 23:38:18 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18798; Mon, 16 Sep 1996 23:38:22 -0400 Message-Id: <9609170338.AA18798@fwasted.zk3.dec.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2118) Re: Source Address selection In-Reply-To: Your message of "Mon, 16 Sep 96 11:49:32 EDT." <199609161549.LAA03465@sparky.IOL.UNH.EDU> Date: Mon, 16 Sep 96 23:38:22 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Source address selection is not very interesting on single-homed >hosts. It degenerates to choosing a best matching prefix. There might >be instances when a network administrator might want nodes to drop >packets if the interface has no address equivalent in scope to the >outgoing packet. Thats not an IETF Standards issue that I can see. How do you see it that way? >But source address selction is not just an important thing for >multi-homed hosts, but also routers and nodes with tunneling >interfaces. I have been asked to move discussion regarding >v4-compatible addresses to the ngtrans list, but as they will affect >source address seelction, I think that they be discussed on this list >in the source-address selection context. I don't agree. I think we first better see if the IPv4-Compatible address is even to exist and if so how for transition. I believe it will be brought up as an agenda item at the ngtrans Dec 96 IETF. So you may be discussing a moot point. But lets say your not. Why is this address for source selection an IETF STANDARDS issue? Why is it an interoperability issue? >Source address selection issue is born out of v6 scoped addresses and >is a more imminent problem then entire multihoming. We have found from >IPv4 that it is not such an easy thing to solve, and mutliple models >exist which will treat it in different ways as per the needs. Unicast addresses are not scoped only multicast per RFC 1884? Do you want to propose scoping for Unicast addresses? Why? >And even then let's not just fight our where to solve what. Rather >lets concentrate on the problem and come to a consensus. But I don't think you have defined the problem so I am asking? You have given us implementation problems and maybe you should take those to the ipv6imp list? Which is not an IETF list. >And at the same time lets go on to discuss other things in >multihoming. Well Multihoming is defined much better than this conversation. I feel like I am shooting a shotgun in the dark trying to hit a fly that I can only hear but cannot see. Given that I believe only STANDARDS issues should be discussed in the IETF and then to see if they can be implemented as a proof point. Are you saying you cannot figure out how to implement source address selection to interoperate with other nodes? >Also another note on Router Advertisemnts : I will agree to Thomas >Narten's remark that advertising prefixes which a router can route to >moght add complexity to a strong ES model. But then the redirect >mechanism also does that and the way it is currently implemented in >terms of treating all redirects as host redirects might increase >kernel routing tables on hosts, if a host is talking to more than one >host on a redirected subnet. Though I will concede that this might be >a rare case. Yes its a rare case and why we don't address it. ND does not prevent me from hearing multiple routers. But it says I can only have one default router. From the ND spec I can implement a mechanism which permits me to send the packet to the best router given two of them or more send me RAs. As an option. >This becomes more interesting for multi-homed hosts who prefer weak ES >model and I will agree that ND is not the place to solve it. The trick is to make sure ND does not prevent multihoming and the test case IMHO for us to verify in the IETF for ND before it goes to Draft Standard. Thats what was not done in the existing IP suite of protocols for address resolution and discovery (e.g. arp, rfc 1256). >But I think if there are multiple routers on a subnet, they might >agree upon advertising themselves as routers for prefixes for which >they have the best routes, instead of eventually doing redirects (or >not at all doing, but doing sub-optimal forwarding if the originating >node used a source address not on the outgoing interface). This might >afterall be not such an expensive thing on hosts as compared to >running named. Though if we think of a typical subnet with a single >router, this mechanism is not needed. If this has been discussed >earlier, then my apologies. It has. And I acutually proposed at a Wash D.C. Oct 95 meeting we use preferences to permit these different scenarios. But Steve Deering walked us through the case of redirects using the present ND model and proved to all of us no savings or performance was gained from preferences. Now I am sure there are other schemes but they will gain no benefit. It can still be argued that it makes administration easier but that is not a technical argument. Not sure why your bringing up named in this context? Now for the case of multihomed nodes to the same router on different links thats one of the cases in the Shand multihome draft and clearly requires a solution. Two solutions on the table is the huitema draft on tcp and the bound/roque draft on using the anycast address or that previous work on tcp/udp identifiers. But this gets complex real quick and I assume we will have other discussions in San Jose. There is that lurking EID locator+identifier discussion but that just opens up a can of smelly rotten worms. If you look at the Shand draft you will see this case and others and its even more of a problem for routers I think than hosts. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 17 05:17:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07798; Tue, 17 Sep 96 05:17:18 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07792; Tue, 17 Sep 96 05:16:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA22651; Tue, 17 Sep 1996 05:11:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA16881; Tue, 17 Sep 1996 05:11:11 -0700 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA435620; Tue, 17 Sep 1996 08:08:25 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id IAA61720; Tue, 17 Sep 1996 08:08:27 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA20248; Tue, 17 Sep 1996 08:10:57 -0400 Message-Id: <9609171210.AA20248@cichlid.raleigh.ibm.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2119) Re: Source Address selection In-Reply-To: Your message of "Mon, 16 Sep 1996 11:49:32 EDT." <199609161549.LAA03465@sparky.IOL.UNH.EDU> Date: Tue, 17 Sep 1996 08:10:57 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quaizar Vohra writes: >But source address selction is not just an important thing for >multi-homed hosts, but also routers and nodes with tunneling >interfaces. I would argue that the above are all "multihomed hosts", so it's probably best not to get too hung up on terminology. A router is a host, when one views it as an entity originating packets (other than ICMP anyway). Whether it's a host or router depends on what aspect of its behavior one is looking at. >Also another note on Router Advertisemnts : I will agree to Thomas >Narten's remark that advertising prefixes which a router can route to >moght add complexity to a strong ES model. I'd argue that it adds complexity independent of the weak and strong ES model. Having routers advertise prefixes adds complexity to both hosts and routers. There are a lot of details that have to be worked out to make all the pieces work correctly. > But then the redirect mechanism also does that Having routers advertise prefixes doesn't necessarily do away with the utility of redirects. Suppose you have two routers, R1 and R2. R1 advertises a prefix that is the "best" route. Sometime later, R1 decides that going thorugh R2 is actually the better path for that prefix. How will the host learn that? If not via a redirect from R1, then how? Do we rely on hosts timing out prefixes? If so, we then are forced to have short timeouts so routing is responsive to topology changes, but that also means prefixes would have to be advertised frequently (more overhead). > and the way it is currently implemented in terms of treating all > redirects as host redirects might increase kernel routing tables on > hosts, if a host is talking to more than one host on a redirected > subnet. I don't entirely agree with the statement that per-destination routes on hosts necessariy increase the size of host routing tables. Where do you keep PMTU information? Certainly not on a per-prefix basis. Ditto for RTT estimates. Given that hosts already maintain per-destination caches, adding the next-hop router to that cache isn't going to increase table size significantly. Besides, aren't routing tables at many sites *HUGE* these days? For many hosts, the per-destination route cache will likely be smaller than the routing table found on neighboring routers. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 17 05:31:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07810; Tue, 17 Sep 96 05:31:24 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07804; Tue, 17 Sep 96 05:31:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA23338; Tue, 17 Sep 1996 05:25:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA19233; Tue, 17 Sep 1996 05:25:24 -0700 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA428194; Tue, 17 Sep 1996 08:20:09 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id IAA05460; Tue, 17 Sep 1996 08:20:07 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA20578; Tue, 17 Sep 1996 08:22:36 -0400 Message-Id: <9609171222.AA20578@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2120) Re: Source Address selection In-Reply-To: Your message of "Mon, 16 Sep 1996 23:38:22 EDT." <9609170338.AA18798@fwasted.zk3.dec.com> Date: Tue, 17 Sep 1996 08:22:36 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com writes: >>Source address selection is not very interesting on single-homed >>Source address selection issue is born out of v6 scoped addresses and >>is a more imminent problem then entire multihoming. We have found from >>IPv4 that it is not such an easy thing to solve, and mutliple models >>exist which will treat it in different ways as per the needs. >Unicast addresses are not scoped only multicast per RFC 1884? Link-local, site-local and global addresses are examples of unicast addresses that are scoped. Only the latter has unique scope across all the internet. Site-local unicast addresses are scoped just as much as site-local multicast addresses. >Yes its a rare case and why we don't address it. ND does not prevent me >from hearing multiple routers. But it says I can only have one default >router. From the ND spec I can implement a mechanism which permits me >to send the packet to the best router given two of them or more send me >RAs. As an option. The last two sentences seem to contradict each other. If there is specfic wording in the ND spec that says you can "only have one default router", it needs to be fixed. Section 6.3.6 (Default Router Selection makes it pretty clear that one can have more than one default router. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 17 08:07:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07906; Tue, 17 Sep 96 08:07:27 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07900; Tue, 17 Sep 96 08:07:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA09143; Tue, 17 Sep 1996 08:01:26 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA00775; Tue, 17 Sep 1996 08:01:22 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <19964(7)>; Tue, 17 Sep 1996 07:51:50 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 17 Sep 1996 07:51:38 PDT To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2121) Re: Source Address selection In-Reply-To: bound's message of Mon, 16 Sep 96 20:38:22 -0800. <9609170338.AA18798@fwasted.zk3.dec.com> Date: Tue, 17 Sep 1996 07:51:38 PDT From: Steve Deering Message-Id: <96Sep17.075138pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, In my role as co-chair of the ipngwg, I must ask you to stop trying to stifle discussion on the ipng mailing list. Discussions like the current ones on source-address selection, multihoming, tunneling, and address scoping are exactly what this list is intended for -- they help to *discover* whether or not there are any "STANDARDS" consequences of particular IPv6 implementation choices. Without hearing -- and encouraging -- such discussions, you have no grounds for declaring unilaterally that there are no standardization issues in, say, source address selection; rather, it sounds like you *hope* there are no such issues, and you wish to prevent discussion that would reveal any such issues. Aside: there are indeed standardization issues in source-address selection. One example is the need to prohibit hosts from originating a packet on one link whose source address is a link- local address that belongs to the host only on a different link. That prohibition is an architectural requirement of IPv6 link-local addressing; violating it can cause communication failures for other nodes and other, hard-to-diagnose problems. One of the most important factors in the success of IETF standards is the fact that the people writing the standards take into account issues not just of interoperability, but also of implementability, complexity, performance, and so on. Moving discussion of those concerns off to private non-IETF mailing lists is likely to harm, rather than help, the quality of IETF standards. I appreciate and share your concern that the standards we write not unnecessarily constrain implementation choices. It is legitimate and important that you point out any such perceived constraints when they appear in our draft standards. It is *not* legitimate for you to declare mailing list discussions off-limits just because they happen to cross your own imaginary dividing line between those topics that have standards consequences and those that do not. As long as other participants believe that the topics of discussion are relevant to producing high-quality IPv6 standards and the chairs concur, then the mailing list is serving its intended purpose. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 17 08:19:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07941; Tue, 17 Sep 96 08:19:14 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07935; Tue, 17 Sep 96 08:19:01 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA10872; Tue, 17 Sep 1996 08:13:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA05324; Tue, 17 Sep 1996 08:13:12 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA04332; Tue, 17 Sep 96 11:07:49 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id LAA04691; Tue, 17 Sep 1996 11:15:10 -0400 Date: Tue, 17 Sep 1996 11:15:10 -0400 Message-Id: <199609171515.LAA04691@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: bound@zk3.dec.com Cc: Quaizar Vohra , ipng@sunroof.eng.sun.com Subject: (IPng 2122) Re: Source Address selection In-Reply-To: <9609170338.AA18798@fwasted.zk3.dec.com> References: <199609161549.LAA03465@sparky.IOL.UNH.EDU> <9609170338.AA18798@fwasted.zk3.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com writes: > > >Source address selection is not very interesting on single-homed > >hosts. It degenerates to choosing a best matching prefix. There might > >be instances when a network administrator might want nodes to drop > >packets if the interface has no address equivalent in scope to the > >outgoing packet. > > Thats not an IETF Standards issue that I can see. How do you see it > that way? Probably not. > > >But source address selction is not just an important thing for > >multi-homed hosts, but also routers and nodes with tunneling > >interfaces. I have been asked to move discussion regarding > >v4-compatible addresses to the ngtrans list, but as they will affect > >source address seelction, I think that they be discussed on this list > >in the source-address selection context. > > I don't agree. I think we first better see if the IPv4-Compatible > address is even to exist and if so how for transition. I believe it > will be brought up as an agenda item at the ngtrans Dec 96 IETF. So you > may be discussing a moot point. But lets say your not. Why is this > address for source selection an IETF STANDARDS issue? Why is it an > interoperability issue? Please refer to examples in my earlier mails and some of the replies. > > >Source address selection issue is born out of v6 scoped addresses and > >is a more imminent problem then entire multihoming. We have found from > >IPv4 that it is not such an easy thing to solve, and mutliple models > >exist which will treat it in different ways as per the needs. > > Unicast addresses are not scoped only multicast per RFC 1884? Do you > want to propose scoping for Unicast addresses? Why? Please check RFC 1884 again. > > Are you saying you cannot figure out how to implement source address > selection to interoperate with other nodes? Are we discussing my capabilities here ? > Not sure why your bringing up named in this context? Sorry, I meant routed and not named. Regards, Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 17 08:29:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07961; Tue, 17 Sep 96 08:29:17 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07955; Tue, 17 Sep 96 08:29:03 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12441; Tue, 17 Sep 1996 08:23:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA09075; Tue, 17 Sep 1996 08:23:16 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA13396; Tue, 17 Sep 1996 11:12:06 -0400 (EDT) Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA07777; Tue, 17 Sep 1996 11:12:05 -0400 Received: by netrix.lkg.dec.com; (5.65v3.2/1.1.8.2/28May95-0415PM) id AA03651; Tue, 17 Sep 1996 11:12:23 -0400 Date: Tue, 17 Sep 1996 11:12:23 -0400 From: Dan Harrington Message-Id: <9609171512.AA03651@netrix.lkg.dec.com> To: narten@raleigh.ibm.com Subject: (IPng 2123) Re: Source Address selection Cc: ipng@sunroof.eng.sun.com, qv@sparky.iol.unh.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten writes: > Having routers advertise prefixes doesn't necessarily do away with the > utility of redirects. Suppose you have two routers, R1 and R2. R1 > advertises a prefix that is the "best" route. Sometime later, R1 > decides that going thorugh R2 is actually the better path for that > prefix. How will the host learn that? If not via a redirect from R1, > then how? Do we rely on hosts timing out prefixes? If so, we then are > forced to have short timeouts so routing is responsive to topology > changes, but that also means prefixes would have to be advertised > frequently (more overhead). Hmmm...reminds me of the discussion we had just about a year ago at the Washington interim meeting, regarding Prefix Redirects (i.e. add a prefix length to the Redirect packet, such that the host learns that all traffic to a particular off-link prefix should be sent via the target router). It had the advantage of communicating routes from routers to hosts without the need for snooping any routing protocols, or for dealing with advertisements and timeouts...as I recall, the downside involved deciding what to do for A) any extant host routes matching the prefix (should they be switched over as well?), and B) what happens if/when NUD determines that the target router has disappeared. While there was not a lot of enthusiasm for the idea at the time, it was left open to future discussion. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 17 12:09:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08230; Tue, 17 Sep 96 12:09:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08224; Tue, 17 Sep 96 12:09:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA19340; Tue, 17 Sep 1996 12:03:37 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA13115; Tue, 17 Sep 1996 12:03:26 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA21548; Tue, 17 Sep 96 12:02:45 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA12208; Tue, 17 Sep 1996 12:03:03 -0700 Date: Tue, 17 Sep 1996 12:03:03 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199609171903.MAA12208@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2124) Montreal - Leftovers X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPNG Folks, Since the working group mailing list seems to need some spicing up,:-) I thought I would remind the group that there were a couple of topics that were discussed at Montreal but were left undecided for lack of time and clear consensus. The co-chairs urged folks to discuss the issues on the mailing list. From memory the two items were: 1) KRE's interface identification proposal. This draft proposed a method for a node to add extra bits to its link-local addresses in order to make each interface's link-local address unique. These extra bits are necessary because some systems automatically give the same MAC address to all the interfaces attached to the system. As a result the link-local addresses of all the interfaces are also identical. Please read the draft for a more complete description of the problem and solution (draft-ietf-ipngwg-iid-02.txt). There were a number of arguments for and against this proposal. I will not attempt to summarize those arguments. I will just note that the author of the proposal did not intend for his draft to survive as a separate document. The document was merely a request to make changes to other IPNG documents (ND, ADDRCONF, ADDR-ARCH?, BASE?) in order to make the proposed scheme legal. With that in mind I think that the mailing list should decide this issue soon so that the authors of the relevent drafts will have sufficient time before San Jose to make the necessary changes to the documents. This is probably an impossible goal, but what the heck, if it shortens the agenda by one contentious item it will have been worth the effort. -- Opinion On -- Given that this proposal enforces no additional restrictions or requirements on nodes which do not assign the same MAC address to all their interfaces, I see no reason that the changes described in KRE's draft should not be made. -- Opinion Off -- 2) There was a discussion about solutions for the following neighbor discovery scenario. - We have a router which is periodically multicasting a router advertisement. This router advertisement is abbreviated in that it contains no information other than a router lifetime and a source link-layer address option. - A host reboots. As per the ND spec it sends out a multicast router solicitation and waits for a response. The solicitation gets dropped. - After the hosts router solicitation gets dropped the router sends one of its periodic abbreviated router advertisements. The host receives this advertisement processes it and as per the ND spec ceases transmission of any further router solicitations. We now have a host which has booted, has a default router, but has no prefix information and possibly no addresses (maybe DHCP, maybe not). This situation would persist until some other node sends a router solicitation which does not get dropped or the router sends an advertisement updating prefix and address lifetimes. Note that the later may never arrive if the router is always advertising infinite prefix lifetimes. There were a number of proposals about how to correct this problem. I don't remember all of the proposals but I believe they are in the minutes. -- Opinion On -- The one proposal I do remember was one that I had discussed with Steve Deering during the last bake-off. That proposal was to add a solicited bit to the router advertisement. This bit would allow the host to know that a router advertisement was transmitted as a result of a solicitation rather than just being a periodic and possibly abbreviated advertisement. Router advertisements lacking the new solicited bit would be processed normally but the host would continue sending router solicitations until it received a solicited router advertisement or it had sent its limit of router solicitations. -- Opinion Off -- Let the discussion begin. Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 17 13:37:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08324; Tue, 17 Sep 96 13:37:48 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08318; Tue, 17 Sep 96 13:37:35 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA27951; Tue, 17 Sep 1996 13:31:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA04114; Tue, 17 Sep 1996 09:24:05 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA04744; Tue, 17 Sep 96 12:17:56 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id MAA04766; Tue, 17 Sep 1996 12:25:07 -0400 Date: Tue, 17 Sep 1996 12:25:07 -0400 Message-Id: <199609171625.MAA04766@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: Thomas Narten , Dan Harrington Cc: Quaizar Vohra , ipng@sunroof.eng.sun.com Subject: (IPng 2125) Re: Source Address selection In-Reply-To: <9609171210.AA20248@cichlid.raleigh.ibm.com> References: <9609171512.AA03651@netrix.lkg.dec.com> <199609161549.LAA03465@sparky.IOL.UNH.EDU> <9609171210.AA20248@cichlid.raleigh.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tom, Dan, > > > But then the redirect mechanism also does that > > Having routers advertise prefixes doesn't necessarily do away with the > utility of redirects. Suppose you have two routers, R1 and R2. R1 > advertises a prefix that is the "best" route. Sometime later, R1 > decides that going thorugh R2 is actually the better path for that > prefix. How will the host learn that? If not via a redirect from R1, > then how? Do we rely on hosts timing out prefixes? If so, we then are > forced to have short timeouts so routing is responsive to topology > changes, but that also means prefixes would have to be advertised > frequently (more overhead). > > > and the way it is currently implemented in terms of treating all > > redirects as host redirects might increase kernel routing tables on > > hosts, if a host is talking to more than one host on a redirected > > subnet. > > I don't entirely agree with the statement that per-destination routes > on hosts necessariy increase the size of host routing tables. Where do > you keep PMTU information? Certainly not on a per-prefix basis. Ditto > for RTT estimates. Given that hosts already maintain per-destination > caches, adding the next-hop router to that cache isn't going to > increase table size significantly. > > Besides, aren't routing tables at many sites *HUGE* these days? For > many hosts, the per-destination route cache will likely be smaller > than the routing table found on neighboring routers. > Currenlty as per the BSD code RTT is stored in tcp control block. It is stored in the routing table at the end of a connection if the route is not a default route. It is saved even if the route is a network route. One would expect most dest. to match the default route. So a host specific cache is not created in case the dest. matches a default route. As far as PMTU is concerned it might be stored in the internet protocol control block. Or a very light weight data structure could be created for PMTU specifically. I think creating routes for each remote destination is not a good thing. As far as redirects are concerned, host specific routes are created when a node receives a redirect. I agree that prefixes will have to be advertised as frequently as topology changes, but it is difficult to clearly state whether a node will see more redirects or more prefix advertisements. Also redirect mechanism has a problem regarding multi-homed hosts as Peter pointed out earlier. If we were to use prefix advertisements we won't have this problem. Clearly the mechanism of routers advertising prefixes for which they can route is useful on typical subnet with a single router. It might be more useful on subnets with multiple routers and multihomed hosts. We can have an option which might contain prefixes a router routes for, hosts can ignore the option if they want, or heed to it otherwise. Dan Harrington writes: > > Hmmm...reminds me of the discussion we had just about a year ago > at the Washington interim meeting, regarding Prefix Redirects > (i.e. add a prefix length to the Redirect packet, such that the > host learns that all traffic to a particular off-link prefix should be > sent via the target router). It had the advantage of communicating > routes from routers to hosts without the need for snooping any routing > protocols, or for dealing with advertisements and timeouts...as I > recall, the downside involved deciding what to do for > A) any extant host routes matching the prefix (should they be > switched over as well?), and B) what happens if/when NUD determines > that the target router has disappeared. As I see it on BSD based code, routes which are formed from redirects are not switched over in either case. I think it should be done. The problem of not switching routes has some adverse effects on sockets, as implemented in BSD. I don't want to discuss it here till I make sure it is not an implementation issue. BSD has left us a legacy which has been incorporated in many other systems. It has been a good design with a few minor problems which I think a lot of people will be interested in even though it is more of an implementation problem. Regards, Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 18 09:40:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08951; Wed, 18 Sep 96 09:40:56 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08945; Wed, 18 Sep 96 09:40:43 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA02038; Wed, 18 Sep 1996 09:34:24 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id JAA17953; Wed, 18 Sep 1996 09:34:00 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA05391; Wed, 18 Sep 1996 12:29:55 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13745; Wed, 18 Sep 1996 12:29:52 -0400 Message-Id: <9609181629.AA13745@fwasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2126) Re: Source Address selection In-Reply-To: Your message of "Tue, 17 Sep 96 07:51:38 PDT." <96Sep17.075138pdt."75270"@digit.parc.xerox.com> Date: Wed, 18 Sep 96 12:29:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Your mail is making assumptions about my motives and doing so incorrectly I think we need to talk off line as you just really ticked me off. I am just an engineer on this list. I cannot by definition declare anything off limits and no one has to listen to me. Your inuendo is very bogus and you should have addressed this with me privately. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 18 15:00:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09278; Wed, 18 Sep 96 15:00:59 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09272; Wed, 18 Sep 96 15:00:45 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA13124; Wed, 18 Sep 1996 14:54:37 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id OAA18888; Wed, 18 Sep 1996 14:54:23 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA12606; Wed, 18 Sep 1996 17:49:25 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA22728; Wed, 18 Sep 1996 17:49:24 -0400 Message-Id: <9609182149.AA22728@fwasted.zk3.dec.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2127) Re: Source Address selection In-Reply-To: Your message of "Tue, 17 Sep 96 11:15:10 EDT." <199609171515.LAA04691@sparky.IOL.UNH.EDU> Date: Wed, 18 Sep 96 17:49:23 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >But source address selction is not just an important thing for > >multi-homed hosts, but also routers and nodes with tunneling > >interfaces. I have been asked to move discussion regarding > >v4-compatible addresses to the ngtrans list, but as they will affect > >source address seelction, I think that they be discussed on this list > >in the source-address selection context. > > I don't agree. I think we first better see if the IPv4-Compatible > address is even to exist and if so how for transition. I believe it > will be brought up as an agenda item at the ngtrans Dec 96 IETF. So you > may be discussing a moot point. But lets say your not. Why is this > address for source selection an IETF STANDARDS issue? Why is it an > interoperability issue? >Please refer to examples in my earlier mails and some of the replies. OK lets discuss. I think its a transiton issue but we can figure that out. > > >Source address selection issue is born out of v6 scoped addresses and > >is a more imminent problem then entire multihoming. We have found from > >IPv4 that it is not such an easy thing to solve, and mutliple models > >exist which will treat it in different ways as per the needs. > > Unicast addresses are not scoped only multicast per RFC 1884? Do you > want to propose scoping for Unicast addresses? Why? >Please check RFC 1884 again. I view the site-local address as a reservered address and unicast as a reserved set of addresses. I view Multicast being able to be scoped F1-F15. So I don;t consider it the same. But thats fine we can move on. > > Are you saying you cannot figure out how to implement source address > selection to interoperate with other nodes? >Are we discussing my capabilities here ? No. Asking a question? If there is an interoperability issue you have found while implementing then we need to know that. Steve has requested we discuss such issues here. So .......OK........ /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 19 17:28:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09934; Thu, 19 Sep 96 17:28:54 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09649; Thu, 19 Sep 96 03:50:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA18793; Thu, 19 Sep 1996 03:45:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA01953; Thu, 19 Sep 1996 03:45:00 -0700 Received: by mail.noris.net id <35065-17999>; Thu, 19 Sep 1996 12:44:56 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2128) Re: Some questions Date: 19 Sep 1996 12:44:30 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 40 Message-Id: <51r86e$hu8@work.smurf.noris.de> References: <199609101622.MAA12866@sparky.IOL.UNH.EDU> <199609111653.SAA19661@brahma.sics.se> <842486487.15096@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: unlisted-recipients:;@mercury (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Peter Sjodin writes: > > I don't want to reiterate an old discussion, the point I wanted to make is > that addresses belong to physical interfaces, not pseudo-interfaces. > Addresses, strictly speaking, belong to hosts. They're associated with zero or more interfaces for which the address is good when you're using the interface to send a packet and you haven't specified the local address yet. There are enough IPv4 implementations where interfaces can have zero or more addresses and addresses can be associated with zero or more interfaces that it's rather pointless to try to rule them out. My idea of a selection algorithm would be to use the source address which most closely matches the destination you send to and which is valid for that particular interface. If there is no such address, then the sending should either fail because you're routing to the wrong interface. IMHO, interfaces without any address shouldn't exist. What for? You can associate the same global-scope address to all those otherwise-unnumbered interfaces just as easily, and the kernel's job becomes a whole lot simpler. Programs may of course specify a different local address which is preferred (unless it's out of scope -- then you return an error. The host MUST NOT send packets with a site-local source address to an off-site system, IMHO. Note that each interface may have a different idea about what site-local actually means). -- Whenever you set out to do something, something else must be done first. -- Murphy's Sixth Corollary -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 19 17:31:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09946; Thu, 19 Sep 96 17:31:23 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09664; Thu, 19 Sep 96 04:17:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA19931; Thu, 19 Sep 1996 04:12:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA05542; Thu, 19 Sep 1996 04:12:07 -0700 Received: by mail.noris.net id <35066-17999>; Thu, 19 Sep 1996 13:12:02 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2129) Re: Montreal - Leftovers Date: 19 Sep 1996 13:11:30 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 36 Message-Id: <51r9p2$i0v@work.smurf.noris.de> References: <199609171903.MAA12208@feller.mentat.com> <842990382.25872@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: unlisted-recipients:;@mercury (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, thartric@mentat.com (Tim Hartrick) writes: > [ KRE's proposal ] > Given that this proposal enforces no additional restrictions or > requirements on nodes which do not assign the same MAC address to > all their interfaces, I see no reason that the changes described in > KRE's draft should not be made. > Seconded. Besides, I'd like to see his placement option 1 because then FE80:XXX:: would be a good prefix for interface number (hex) XXX, which would make searching for the correct interface very easy. Besides^2, his idea to drop the requirement to actually name the interfaces, with all the software hassle that entails, is a Very Good Thing. > 2) There was a discussion about solutions for the following neighbor > discovery scenario. > [ scenario, "solicited" bit ] I'd replace "solicited" with "abbreviated", with the requirement that all solicited packets be unabbreviated. I'd also suggest that the router transmits nonabbreviated packets once in a while so that systems which don't actually send anything, such as network traffic analyzers, still get complete information. -- Pseudo-Judeo-Christian horror was no match for genuinely hypoglycemic hunger. -- Peni R. Griffin, "The Goat Man" (IASFM, 5/89) -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 21 13:03:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11298; Sat, 21 Sep 96 13:03:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11292; Sat, 21 Sep 96 13:02:42 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA26722; Sat, 21 Sep 1996 12:56:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA28358; Sat, 21 Sep 1996 12:53:29 -0700 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id MAA25815 for ipng@sunroof.eng.sun.com; Sat, 21 Sep 1996 12:53:28 -0700 Message-Id: <199609211953.MAA25815@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Sat, 21 Sep 1996 12:53:28 PDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 2130) [Forwarded] Security AD Statement on IPSEC Key Management Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Forwarded for information since this relates to IPv6. The copy I'm forwarding is second-hand from Dorian Kim who kindly emailed it to me. Any questions about the statement should be directed at the Security AD and not at the IPsec WG chairs. Ran rja@cisco.com ---------- Forwarded message ---------- Date: Thu, 19 Sep 1996 22:58:32 -0400 From: "Jeffrey I. Schiller" To: ipsec@tis.com, ietf@ietf.org Subject: Security AD Statement on IPSEC Key Management -----BEGIN PGP SIGNED MESSAGE----- Introduction Standardized security technology is urgently needed on the Internet today. The IPSEC Working Group has been working to provide solutions applicable to the IP Layer of the protocol stack. Over a year ago, consensus was reached on the packet formats necessary to provide data authentication, integrity and confidentiality. However the mechanism to exchange required cryptographic material was not yet ready for standardization. Since then the IPSEC Working Group has been struggling with several competing key management proposals. To have competing proposals within an IETF working group is neither new nor novel. However the time comes when either the proponents of the various proposals come to consensus (along with the rest of the working group) or a decision among them has to be made. That time is now. In Montreal (at the June IETF meeting) I saw several factions at work in the IPSEC working group. There were people supporting each of the proposed key management solutions and a larger number of people who were looking for a single solution to emerge, but who themselves were not in a position to have a technical opinion one way or the other. But one thing was clear, they wanted a solution and they wanted it then. Shortly after the meeting I was approached by several people offering to have a "design team" meeting with the principals behind the various proposals. The goal of the team was to come up with a compromise that all could live with. I considered this very good news, but I was also cautious. The last thing I wanted was to have a working group meeting at the December 1996 IETF and still be where we were in Montreal, namely without a solution! To this end I established a time limit. The charge to the design team was to come up with a compromise solution (or enough progress on a compromise) by September 1. After September 1, if the working group could not decide upon a course of action, then I would step in as Security Area Director and propose one myself. As those of you on the IPSEC list already know, the design team failed in their effort to come up with a compromise. I am both saddened and disappointed by this outcome. The purpose of this document is to end the controversy and establish a productive direction for future work. History To understand the situation requires a bit of history and explanation. Although most Internet problems can be solved by a single protocol, this doesn't always have to be the case. For example, we have TCP and UDP which both provide a transport service, but with very different characteristics to address different problem domains. Similarly we have both the RIP and OSPF routing protocols. Each protocol has features different from the other, and each has its appropriate domain of applicability. Why is IPSEC different? To understand this we have to go back to the original decision reached by the IETF in the IPv6 selection process. Specifically the IETF decided that security, namely IPSEC, was a mandatory requirement for a compliant implementation of IPv6. This was decided upon because the community felt that without such a mandatory feature, security would not be implemented in a lot of products, even though there is a pressing need for security on the Internet. The reasons for this belief are many and varied and beyond the scope of this document. Suffice it to say that IPSEC technology is mandatory in IPv6. The mandatory nature of IPSEC means that for its various protocols, several variants may exist, but one of each class of protocol will need to be designated as mandatory to provide guidance to vendors wishing to build IPv6 compliant versions of products. The mandatory to implement protocols may not necessarily be the ideal solution for any particular problem. Instead they are selected to provide two basic requirements: o Strong Security o Interoperability The goal is for two compliant implementations of IPSEC to be able to communicate securely because they, at a minimum, have the mandatory to implement protocols common between them. They may have other protocols, such as other Authentication Header (AH) and Encapsulated Security Protocol (ESP) transforms, in common which they may negotiate the use of instead of the mandatory protocols. The mandatory transforms may not always be the ideal approach for a particular network application. For example, the mandatory ESP transform involves the use of the U.S. Data Encryption Standard (DES). This encryption algorithm is widely regarded as being secure enough for most applications. It is also commonly recognized that DES is a slow algorithm and applications requiring high speed data transfer (in the absence of high speed DES hardware) may elect to use a faster cipher such as the International Data Encryption Algorithm (IDEA) or RSA Data Security's RC2 or RC4 ciphers. Analysis Keeping in mind that the primary goal of the mandatory protocols is to provide strong security and interoperability, I have read and evaluated the approaches in the two main contenders for the IPSEC key management mandatory standard, SKIP and ISAKMP/Oakley. ISAKMP/Oakley ISAKMP defines a Security Association management protocol for establishing security contexts and keys between a pair of hosts on the Internet. By itself it does not define a key management function. Oakley provides a key management function which can operate within the ISAKMP protocol. The combination provides for complete security association and cryptographic key material management. Oakley itself provides several protocol variations which trade-off between protocol overhead (the number of messages sent between communicating hosts) and services provided (such as identity confidentiality). ISAKMP/Oakley imposes a cost of several packet exchanges between host pairs before secure communication can take place. There is no per-packet overhead to use ISAKMP/Oakley (other then the AH and ESP header overhead itself) once associations are in place. For a set of hosts which communicate with each other on a frequent basis, it is expected that associations will remain in place and the overhead of setting new ones up will not be a significant factor. The primary disadvantage of the ISAKMP/Oakley approach is that it imposes significant overhead in the case where hosts communicate infrequently as it is likely that associations will not exist when needed and will have to be setup. If either party to a security association looses or changes state, so that existing associations are no longer operative, then a new set of security associations can be established. Messages, protected by the new associations, can communicate the demise of the failed associations. SKIP The SKIP proposal is based on in-line keying. Each packet is encrypted in a key which is provided in the packet itself, encrypted in a key that is setup between the communicating host pair. SKIP's advantage is that the protocol for setting up inter-host keys is fairly lightweight. If both hosts already have the other hosts public key certificate, no packet exchanges are required as the arriving data packet will contain sufficient information for the receiving host to compute the shared key and respond accordingly. Computing the shared key requires significant computation (exponentiation). However a communicating host pair can choose to cache their shared keys to avoid this computational overhead. There is a trade-off between computation of shared keys and secure storage to hold already computed keys. In SKIP if a received packet cannot be decrypted, there is little fallback available as SKIP does not naturally support multiple security associations. Put another way, the lightweight key management does not have a heavyweight fallback in the event that key management fails for any reason. The result is that messages must be sent without security enhancements to indicate the failure. However such messages will be indistinguishable from forged messages originated by an attacker for the purpose of disrupting communication. The implication of the lightweight approach of SKIP is that no significant negotiation of algorithms, certificates and other options are possible. The assumption is that certain parameters, such as the Diffie Hellman prime and generator will be constant among members of a community of hosts using SKIP. Among a small community of hosts, e.g., within an autonomous system (AS), such parameters need not be negotiated in real-time, but rather can be configured in advance in the hosts. If at some future point they need to be changed, the amount of management overhead necessary is bounded by the size of the AS. SKIP will also likely be faster at recovery from normal system failure (reboot) when a host communicates with a significant number of peers. In this situation the lightweight approach provides for faster re-establishment of secure communication. Note: Some features of SKIP, including Certificate Discovery and Algorithm Discovery improve its ability to cope with some classes of failures. However this additional mechanism comes at the cost of additional packet exchanges and protocol complexity. It is my opinion that SKIP could be further modified to deal with these issues as well as ISAKMP/Oakley does. However I believe such a modified protocol will be as complicated if not more so then the ISAKMP/Oakley protocol combination. Conclusion I had hoped that the design team would have recognized that each of the two proposals above have domains where they are particularly well suited. It is conceivable to this author that a merged mechanism could exist that provides the benefits of SKIP within an AS (or similar community) and ISAKMP/Oakley when more protocol negotiation is required. A simple (from my point of view) solution would be to require both SKIP and ISAKMP/Oakley be implemented in a compliant IPv6 protocol stack. However it is clear to me that there is significant overlap of functionality between these two protocols and without a compromise (presumably a compromise protocol would result in a lot of shared mechanism and code in implementations) implementors would have to write a lot of excess code. Therefore we have to pick one approach as the mandatory solution. This does not mean that the other approach cannot become an ELECTIVE Internet Standard. Going back to my original view of the goal behind the "mandatory" approach leads me to conclude that if we must pick between ISAKMP/Oakley and SKIP, then ISAKMP/Oakley should be the mandatory standard. My rationale is simple. It is my belief that given an arbitrarily chosen pair of hosts, it is likelier that an ISAKMP/Oakley approach will result in a working security association than SKIP. Furthermore going back to the original working group charter, the ISAKMP/Oakley approach more closely follows the goals established in the charter to the IKMP portion of the IPSEC work. I would like to see the IPSEC working group create three sets of RFCs. o A Set of RFCs which fully define the ISAKMP/Oakley approach. These RFCs will follow the normal IETF standards track ultimately resulting in a protocol that is ELECTIVE for IPv4 and is MANDATORY for IPv6. o A Set of RFCs which fully define the SKIP approach. These RFCs will follow the normal IETF standards tack ultimately resulting in a protocol that is ELECTIVE for IPv4 and is ELECTIVE for IPv6. o One or more RFCs that describe the application domain for ISAKMP/Oakley and SKIP. Although I believe that ISAKMP/Oakley should become the IPv6 Mandatory protocol, I also believe that there exist significant domains of application where the SKIP approach makes more sense. I would like the working group to address this. Recommendation I formally recommend, as Security Area Director, that the charter for the IPSEC working group be amended to charge the working group with the tasks above. The arguments between the ISAKMP/Oakley and SKIP factions should no longer be considered appropriate discussion for the working group, either at its in person meetings or on the working group mailing list. If some people would like to continue that line of discussion they are welcome to form a separate mailing list, not part of the IETF. Proposed New Charter (with change bars) IP Security Protocol (ipsec) Charter Chair(s) * Ran Atkinson * Paul Lambert Security Area Director(s): * Jeffrey Schiller Mailing List Information * General Discussion:ipsec@tis.com * To Subscribe: ipsec-request@tis.com * Archive: ftp://ftp.tis.com/pub/lists/ipsec Description of Working Group Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the | lower layer security protocol. The protocol will be based on the | ISAKMP/Oakley work begun in: | | , | and | . | | A follow on work item may incorporate mechanisms based on SKIP as | defined in: | | | | and related documents. Flexibility in the protocol will allow | eventual support of Key Distribution Centers (KDC), such as are used | by Kerberos. Goals and Milestones Done Submit Internet-Draft of Internet Key Management Protocol to the IESG for consideration as a Proposed Standard. Done Post as an Internet-Draft the IP Security Protocol. Done Post as an Internet-Draft the specification for Internet key management. Done Conduct initial interoperability testing of Encapsulating Security payload (ESP) and Authentication Header (AH). | Done Submit revised Internet-Drafts for ESP, AH, and IP Security Architecture. | Dec 96 Submit revised Internet-Drafts of IP Security Architecture, ESP, and AH to the IESG for consideration as Draft Standards. | Jan 97 | Submit Internet-Draft of the Internet Key Management Protocol (IKMP). | based on ISAKMP/Oakley to the IESG for consideration as a Proposed | Standard. | Jul 97 | Submit IKMP to IESG for consideration as a Draft Standard. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMkHj78UtR20Nv5BtAQEiAgP/XTqrl8Wn4jFpOgtukCbIgDUrsqzKiMDy HCl6pX4BbXGpdiHlayCdhS1g5zbdwRa4J4TQg8sESbDkD49Zcs4a9bIDjY31gIB4 HnP7twW1/sEls5Rp/j9vBHTDHQIMJFVWluuJOrQQfPxcLAEFjH+3enfFRAJXQVmo SOwHCHPmW7I= =mr47 -----END PGP SIGNATURE----- --- End of forwarded message ---------------------------------------- -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 21 18:02:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11360; Sat, 21 Sep 96 18:02:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11354; Sat, 21 Sep 96 18:02:42 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA12172; Sat, 21 Sep 1996 17:56:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA17466; Sat, 21 Sep 1996 17:56:02 -0700 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id KAA07108 (8.7.6/IDA-1.6); Sun, 22 Sep 1996 10:55:53 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: rja@cisco.com (Ran Atkinson) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2131) Re: [Forwarded] Security AD Statement on IPSEC Key Management In-Reply-To: Your message of "Sat, 21 Sep 1996 12:53:28 PDT." <199609211953.MAA25815@cornpuffs.cisco.com> Date: Sun, 22 Sep 1996 10:55:52 +1000 Message-Id: <7106.843353752@connect.com.au> From: George Michaelson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At risk of causing death by boredom, Can somebody comment on the likelyhood of non-US sources coding to this standard so we can see global coverage for conformant systems? I don't care that much if in deployment run-time actions enforce cripple-key when data transits US owned infrastructure as long as thats ALL it is: a runtime enforcement. When we can make the US federal system (and others) wake up to itself and disable that requirement, we won't have a total re-deployment on our hands. I know that this kind of thing is preferred to be left out of a standards process, but this one context appears to me to have overwhelming reasons to ensure we account for a political problem RIGHT NOW so that when we have political resolution, we have clean upwards migration. Even sillier suggestion: Why not make a non-US sourced codebase be a reference implementation? Is it impossible we could try to achieve that? cheers -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Sep 21 18:53:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11397; Sat, 21 Sep 96 18:53:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11391; Sat, 21 Sep 96 18:52:55 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA16805; Sat, 21 Sep 1996 18:47:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA20873; Sat, 21 Sep 1996 18:47:03 -0700 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id SAA26709; Sat, 21 Sep 1996 18:46:30 -0700 Message-Id: <199609220146.SAA26709@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Sat, 21 Sep 1996 18:46:30 PDT In-Reply-To: George Michaelson "Re: (IPng 2130) [Forwarded] Security AD Statement on IPSEC Key Management" (Sep 22, 10:55am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: George Michaelson , rja@cisco.com (Ran Atkinson) Subject: (IPng 2132) Re: [Forwarded] Security AD Statement on IPSEC Key Management Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk George, You raise an interesting point. There are non-US implementations of ISAKMP already. For example, DRA/Malvern (UK) has an implementation of ISAKMP for UNIX. Dan Harkins of cisco has done some interoperability testing with DRA/Malvern already, more interoperability testing is planned. If vendors implement the "PF_KEY Key Management API version 2" (I-D should be coming out soon), then anyone can build any key management daemon they want and drop it on top of that API without needing kernel sources. PF_KEY is a lot like PF_ROUTE, but it is for Key Management data rather than routing table data. A paper on PF_KEY appeared at INET'96 that describes it in more detail. The NRL reference implementation of PF_KEY v1 is online at ftp://ftp.ripe.net/ipv6/nrl/ and NRL will probably implement a reference implementation of PF_KEY v2 once the I-D comes out. PF_KEY and the supporting infrastructure an IPsec AH are all easily exported from the US. IMHO, a larger problem than US export controls is the significant number of countries (e.g. France) where __use__ of encryption is heavily regulated as well as having export controls. Ran rja@cisco.com -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 22 04:35:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11519; Sun, 22 Sep 96 04:35:16 PDT Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11513; Sun, 22 Sep 96 04:35:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA11542; Sun, 22 Sep 1996 04:28:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA18663; Sun, 22 Sep 1996 04:29:06 -0700 Received: from connect.com.au (ggm@localhost) by broon.off.connect.com.au with ESMTP id VAA08373 (8.7.6/IDA-1.6); Sun, 22 Sep 1996 21:28:56 +1000 (EST) X-Authentication-Warning: broon.off.connect.com.au: ggm owned process doing -bs To: rja@cisco.com (Ran Atkinson) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2133) Re: [Forwarded] Security AD Statement on IPSEC Key Management In-Reply-To: Your message of "Sat, 21 Sep 1996 18:46:30 PDT." <199609220146.SAA26709@cornpuffs.cisco.com> Date: Sun, 22 Sep 1996 21:28:55 +1000 Message-Id: <8371.843391735@connect.com.au> From: George Michaelson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are non-US implementations of ISAKMP already. For example, DRA/Malvern (UK) has an implementation of ISAKMP for UNIX. Dan Harkins of cisco has done some interoperability testing with DRA/Malvern already, more interoperability testing is planned. This is extremely good news. Well partially, since the Defence Research People and Malvern are hardly your usual free code under GNU source terms bunch, but at least we know some conformant code is being done offshore. IMHO, a larger problem than US export controls is the significant number of countries (e.g. France) where __use__ of encryption is heavily regulated as well as having export controls. Oh absolutely. I don't for a minute think its all honey and roses beyond the US border. I just think that for cisco and everyone elses peace of mind, having a drop-in module from your local source of crypto sure as hell beats being told its cripple key or nothing. I already tried to sucker Eric Young (of ssleay) at some SPKI issues, maybe its time to try again... -George -- George Michaelson | connect.com.au pty/ltd Email: ggm@connect.com.au | c/o AAPT, Phone: +61 7 3834 9976 | level 8, the Riverside Centre, Fax: +61 7 3834 9908 | 123 Eagle St, Brisbane QLD 4000 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 23 00:20:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11800; Mon, 23 Sep 96 00:20:48 PDT Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11794; Mon, 23 Sep 96 00:20:34 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA09321; Mon, 23 Sep 1996 00:14:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA18269; Mon, 23 Sep 1996 00:14:41 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.6/8.7.1) with ESMTP id JAA02699; Mon, 23 Sep 1996 09:14:37 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id MAA25142; Sun, 22 Sep 1996 12:49:15 +0200 (MET DST) Message-Id: <199609221049.MAA25142@givry.inria.fr> From: Francis Dupont To: rja@cisco.com (Ran Atkinson) Cc: George Michaelson , ipng@sunroof.eng.sun.com Subject: (IPng 2134) Re: [Forwarded] Security AD Statement on IPSEC Key Management In-Reply-To: Your message of Sat, 21 Sep 1996 18:46:30 PDT. <199609220146.SAA26709@cornpuffs.cisco.com> Date: Sun, 22 Sep 1996 12:49:14 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: IMHO, a larger problem than US export controls is the significant number of countries (e.g. France) where __use__ of encryption is heavily regulated as well as having export controls. => I agree! For instance the NRL PF_KEY implementation is not officially available outside the USA then it can't be a reference implementation. Even if you make (or put) a reference implementation in a free country you may not import it in the USA and in some months in France (we'll get a new law with new restrictions here). I am afraid the idea to make IPSEC mandatory for IPv6 is only a way to put the pressure on the bad persons (ie software vendors and not governments). The situation will become worse when paranoiac countries spends their ideas to others, for instance if French laws become an European rule... Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 23 09:16:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12073; Mon, 23 Sep 96 09:16:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12067; Mon, 23 Sep 96 09:16:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA00562; Mon, 23 Sep 1996 09:10:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA20746; Mon, 23 Sep 1996 09:06:38 -0700 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id JAA02020 for ipng@sunroof.eng.sun.com; Mon, 23 Sep 1996 09:06:32 -0700 Message-Id: <199609231606.JAA02020@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Mon, 23 Sep 1996 09:06:32 PDT In-Reply-To: Francis Dupont "Re: (IPng 2132) Re: [Forwarded] Security AD Statement on IPSEC Key Management" (Sep 22, 12:49pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 2135) Re: availability of PF_KEY Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, The IETF does not formally have the concept of a "reference implementation", as one IESG has recently asked me to remind everyone. The IETF does have a requirement that standards-track protocols must demonstrate interoperability between multiple implementations before proceeding to Draft Standard, but there is no formal IETF requirement for a freely distributable or published reference implementation. DHCP did not initially have a freely distributable implementation, for example, though it now does have one. % I agree! For instance the NRL PF_KEY implementation is not % officially available outside the USA then it can't be a reference % implementation. The NRL PF_KEY implementation is available at ftp://ftp.ripe.net/ipv6/nrl. PF_KEY _IS_ fully exportable according to cisco's export control experts. If PF_KEY were not, cisco would not make PF_KEY available on cisco's web site to non-US parties as has been done for some time now. % Even if you make (or put) a reference implementation % in a free country you may not import it in the USA and in some months % in France (we'll get a new law with new restrictions here). I do not understand. Will the new law be less difficult for French users of cryptography or more difficult for French users of cryptography ? % I am afraid % the idea to make IPSEC mandatory for IPv6 is only a way to put the % pressure on the bad persons (ie software vendors and not governments). I actually believe that in time vendors will be able to convince the US Government to adopt a more realistic stance on the export of commercial-grade cryptography. I also believe that it is important for the IAB and IESG to operate in a trans-national matter with whatever the best technology happens to be for The Internet. % The situation will become worse when paranoiac countries spends % their ideas to others, for instance if French laws become an European % rule... I hope this does not happen. Ran rja@cisco.com -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 23 09:44:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12104; Mon, 23 Sep 96 09:44:00 PDT Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12098; Mon, 23 Sep 96 09:43:47 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA06976; Mon, 23 Sep 1996 09:37:27 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id JAA04478; Mon, 23 Sep 1996 09:37:22 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA31839; Mon, 23 Sep 1996 12:28:40 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA09157; Mon, 23 Sep 1996 12:28:34 -0400 Message-Id: <9609231628.AA09157@fwasted.zk3.dec.com> To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2136) Re: [Forwarded] Security AD Statement on IPSEC Key Management In-Reply-To: Your message of "Sun, 22 Sep 96 12:49:14 +0200." <199609221049.MAA25142@givry.inria.fr> Date: Mon, 23 Sep 96 12:28:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, >=> I agree! For instance the NRL PF_KEY implementation is not >officially available outside the USA then it can't be a reference >implementation. Even if you make (or put) a reference implementation >in a free country you may not import it in the USA and in some months >in France (we'll get a new law with new restrictions here). I am afraid >the idea to make IPSEC mandatory for IPv6 is only a way to put the >pressure on the bad persons (ie software vendors and not governments). >The situation will become worse when paranoiac countries spends >their ideas to others, for instance if French laws become an European >rule... This is an implementation focus OK. >From your mail above are you saying you cannot use PF_KEY API legally in France? I hope not as I would like to see IPSEC interoperability testing at UNH Dec 1-5 for AH and ESP and hopefully some ISAKMP-OAKLEY. If the API as a spec is not implementable outside of the U.S. then we need to fix that. But if its just a reference implementation issue then I understand that completely. But we can all do AH right? I am hoping that through some manner of key-escrow the world can agree to do ESP across the planet Earth. I know CSPP is working very hard with all the world governments to address this problem technologically and from a business perspective. p.s. if anyone does not know CSPP is a consortia of world wide company CEO's addressing issues with international governments and focusing on security and other technologies affecting international boundaries, etc. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 23 10:17:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12172; Mon, 23 Sep 96 10:17:12 PDT Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12166; Mon, 23 Sep 96 10:16:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA11549; Mon, 23 Sep 1996 10:10:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA18855; Mon, 23 Sep 1996 10:10:44 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id NAA04949 for ipng@sunroof.Eng.Sun.COM; Mon, 23 Sep 1996 13:10:36 -0400 Date: Mon, 23 Sep 1996 13:10:36 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9609231310.ZM4947@seawind.bellcore.com> In-Reply-To: rja@cisco.com (Ran Atkinson) "(IPng 2135) Re: availability of PF_KEY" (Sep 23, 9:06am) References: <199609231606.JAA02020@cornpuffs.cisco.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: ipng@sunroof.eng.sun.com Subject: (IPng 2137) Re: availability of PF_KEY Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk $ I do not understand. Will the new law be less difficult for French users of $ cryptography or more difficult for French users of cryptography ? The new law is probably less difficult, albeit the fine print is hard to assess. In the previous law, authentication was OK but requested declaration, while encryption requested a hard-to-get authorisation. With the new law, authentication is basically deregulated and encryption is OK ... provided you escrow the key. How key escrow works in conjunction with Diffie-Hellmann is left as an exercize for the reader. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 23 23:33:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12656; Mon, 23 Sep 96 23:33:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12650; Mon, 23 Sep 96 23:32:58 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA12517; Mon, 23 Sep 1996 23:27:02 -0700 Received: from dxmint.cern.ch by venus.Sun.COM (Sun.COM) id XAA16867; Mon, 23 Sep 1996 23:26:58 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id IAA23797 for ; Tue, 24 Sep 1996 08:26:56 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA04502; Tue, 24 Sep 1996 08:26:55 +0200 Message-Id: <9609240626.AA04502@dxcoms.cern.ch> Subject: (IPng 2138) Re: availability of PF_KEY To: ipng@sunroof.eng.sun.com Date: Tue, 24 Sep 1996 08:26:55 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9609231310.ZM4947@seawind.bellcore.com> from "Christian Huitema" at Sep 23, 96 01:10:36 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm much more negative about the new French law than Christian, because I think that national escrow schemes screw up international deployment in the most impossible way. Brian Carpenter >--------- Text sent by Christian Huitema follows: > > $ I do not understand. Will the new law be less difficult for French > users of > $ cryptography or more difficult for French users of cryptography ? > > The new law is probably less difficult, albeit the fine print is hard to > assess. In the previous law, authentication was OK but requested > declaration, while encryption requested a hard-to-get authorisation. With > the new law, authentication is basically deregulated and encryption is OK > ... provided you escrow the key. How key escrow works in conjunction with > Diffie-Hellmann is left as an exercize for the reader. > > -- > Christian Huitema > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Sep 24 19:25:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13663; Tue, 24 Sep 96 19:25:18 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13657; Tue, 24 Sep 96 19:25:03 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA19688; Tue, 24 Sep 1996 19:19:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id TAA07527; Tue, 24 Sep 1996 19:19:03 -0700 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.198.61]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id LAA11315 for ; Wed, 25 Sep 1996 11:18:58 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id CAA03647; Wed, 25 Sep 1996 02:20:07 GMT To: ipng@sunroof.eng.sun.com Subject: (IPng 2139) The IPv6 communication model X-Mailer: Mew version 1.07 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Sep_25_11:19:59_1996)--" Date: Wed, 25 Sep 1996 11:20:07 +0900 Message-Id: <3644.843618007@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----Next_Part(Wed_Sep_25_11:19:59_1996)-- Content-Type: Text/Plain; charset=us-ascii Hi all, We WIDE project have submitted a draft on the IPv6 communication model. This is a result of our four-times meeting. It is felt that this draft says implementation issues much. But we hope that it's helpful to start discussion. Thanks. --Kazu ----Next_Part(Wed_Sep_25_11:19:59_1996)-- Content-Type: Text/Plain; charset=us-ascii Internet-Draft Kazu Yamamoto draft-wide-ipv6-comm-model-00.txt NAIST Expires in six months Atsushi Onoe Sony Akira Kato The University fo Tokyo September 1996 The IPv6 communication model Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This memo discusses semantics of communication with IPv6 addresses. This model introduces three address scope classes, node-local, site-local, and global, for both IPv6 unicast and multicast addresses. For a given packet, all addresses in the packet including those in the routing header must be in the same address scope class. Since the sockaddr_in6 address data structure is extended to be able to hold an interface index number, a kernel and applications can exchange interface information. A source address is uniquely determined with the destination address and the outgoing interface. This memo also clarifies packet processing mechanism for the input, forward, and output function. 1. Introduction Though RFC1884[1] introduced scope for IPv6 address architecture, its semantics is not clear. For example, the following questions are often asked: (1) Are semantics of unicast scope and that of multicast scope equal? (2) What are site-local-use addresses? (3) How to use multicast scope? (4) How to select a source address for a given destination address? YAMAMOTO [Page 1] Internet-Draft The IPv6 communication model September 1996 (5) How does a routing daemon know an incoming interface where routing advertisement announced to link-local multicast comes? This memo intends to clarify semantics of IPv6 address scope and to define a communication model for IPv6. It is intended to provoke discussion to lead a general consensus. 2. Address Scope Class To avoid confusion of terminology, this memo first defines one term "address scope class" or "scope-class" as a short representation. Each IPv6 address is categorized to exactly one scope-class out of node-local, link-local, and global. An IPv6 addresses in node-local scope-class are valid inside the node only. Likewise IPv6 addresses in link-local scope-class are valid inside the link only. IPv6 addresses in global scope-class are valid in the entire Internet. Concrete categorization will be discussed later in this memo. Please note that this memo carefully distinguishes the term "scope" for multicast in RFC1884 and the term "scope-class". For convenience, this memo defines one function called "SC()" which takes one IPv6 address as argument and returns a scope-class out of node-local, link-local, and global. Their total ordering is also defined as follows: node-local < link-local < global To ensure communication, this memo defines a basic principle for a given IPv6 packet as follows: SC(src) = SC(r1) = SC(r2) = ... = SC(rn) = SC(dst) where "src" is the source address, "dst" is the destination address, and r1, r2, ..., rn are intermediate nodes specified in the routing header. This basic principle can be logically proved as follows: (1) In general, SC(src) must be greater than or equal to SC(dst). That is, SC(src) >= SC(dst) must be satisfied. If not, it is often happened that the receiving node cannot send back packets to the sending node. (2) If two nodes are on the same link, SC(dst) may be greater than SC(src). For example, node A sends a packet to node B where scope-class of its source address is link-local and that of destination is global. In this case, node B can send back packets to node A where scope-class of its source address is global and that of destination is link-local. Unfortunately, there is no way to tell that the two nodes are on the same link YAMAMOTO [Page 2] Internet-Draft The IPv6 communication model September 1996 in IPv6 scheme. (3) If two nodes are not on the same link, the following condition must be satisfied according to (1): SC(src) >= SC(r1) >= SC(r2) >= ... >= SC(rn) >= SC(dst) Considering a reply packet, the following condition must be satisfied: SC(src) <= SC(r1) <= SC(r2) <= ... <= SC(rn) <= SC(dst) Therefore, the following condition must be satisfied to ensure communication for two nodes which are not on the same link. SC(src) = SC(r1) = SC(r2) = ... = SC(rn) = SC(dst) (4) According to (2) and (3), the basic principle is introduced. 3. Address Scope Class Categorization Each IPv6 address are categorized to scope-class as follows: Unicast and Anycast SC(::1) = node-local Memo: the loopback address SC(FE80::/10) = link-local Memo: link-local-use addresses SC(others) = global Memo: any other addresses including site-local-use addresses and provider based addresses Multicast SC(FF?1/16) = node-local Memo: node local scope multicast addresses SC(FF?2/16) = link-local Memo: link local scope multicast addresses SC(FF/8) = global Memo: any other multicast addresses including site-local scope, organization-local scope, global scope Both the loopback address and node-local scope multicast addresses are valid inside a node by definition. So, it is reasonable to give them node-local scope-class. Link-local-use addresses are IP representations of MAC addresses and are necessary for NDP[2]. They are valid inside the link by definition. Link-local scope multicast addresses are also valid inside the link by definition. So, it is reasonable to categorize them to link-local scope-class. Any communication rather than NDP can be done with global scope-class addresses, though, it is basically a good idea to use link-local scope-class address to YAMAMOTO [Page 3] Internet-Draft The IPv6 communication model September 1996 ensure that packets are not forwarded to other links. Good examples are kinds of routing protocol. RFC1884 defines neither semantics of site-local-use unicast addresses nor that of site-local scope of multicast addresses. It was suggested to define scope-class for each multicast scope such as site-local and organization-local for a sophisticated communication model. Suppose that lower 64 bits are chosen to be unique inside a site and upper 64 bits are assigned by its provider. A global address is generated by concatenating the upper 64 bits and the lower 64 bits while a site-local-use address is generated by concatenating FEC0::/64 and the lower 64 bits. In this case, it is easy to change the provider to another and to maintains communication inside the site using the site-local-use address during the reassign period of global address. But it is very likely that poor hosts cannot handle such sophisticated communication. For address reassignment, another mechanism such as auto-configuration should be developed. Unfortunately organization-local-use address are not defined in RFC1884, so organization-local scope-class for organization-local multicast addresses cannot be defined. This violates the basic principle. Moreover, address selection is much difficult in this model. For instance, with given a name of target host, how to resolve both its link-local-use address and global address and then how to select the best one out of them? If sites/organizations are allowed to be connected by a router, it must have multiple routing tables for the sites/organizations. This makes packet forwarding mechanism very complicated. This memo tries to make the communication model as simple as possible for feasibility inheriting reasonable parts of the IPv4 communication model. Thus, scope-class of site-local-use addresses is global and they are used as PRIVATE defined in [3], that is, free but not unique in the Internet. Likewise, site-local scope multicast and organization-local scope multicast are categorized as global scope-class. Their scope is used for filtering purpose. 4. Link-local Scope-class and Interface Selection Applications such as routing daemon cannot determine incoming/outgoing interface for a given link-local scope-class address in the original IPv6 scheme. So, it is necessary to define generic API to resolve this problem. This memo defines an interface index member for the sockaddr_in6 address data structure specified in [4]. The interface index number is unique on a node and orthogonal against IPv6 address. That is, the interface index number is not encoded into an IPv6 address. struct sockaddr_in6 { u_char sin6_len; /* length of this struct */ u_char sin6_family; /* AF_INET6 */ u_int16m_t sin6_port; /* Transport layer port # */ u_int32m_t sin6_flowinfo; /* IPv6 flow information */ YAMAMOTO [Page 4] Internet-Draft The IPv6 communication model September 1996 u_int32m_t sin6_ifindx; /* Interface Index */ u_int32m_t sin6_pad; /* Reserved */ struct in6_addr sin6_addr; /* IPv6 address */ }; An application specifies an outgoing interface for sending data with the interface index number to the kernel. If the destination address is in node-local scope-class, the kernel ignores the specified interface index number and chooses the loopback interface. If in link-local scope-class, the kernel use the specified interface index number to choose interface. If the destination address is unicast and in global scope-class, the kernel ignores the specified interface index number and chooses a interface according to the routing table. For the case where the destination address is multicast and in global scope-class, this memo does not define any actions and leaves it as an open problem. When you send a multicast packet, this structure may be more useful than specifying the outgoing interface via the setsockopt() function. Discussion is required. The kernel tells the application the incoming interface for the incoming packet with the interface index number. 5. Source Address Selection Any physical interface must have exactly one link-local-use address. Any physical interface must have one "primary" global scope-class address and may have one or more "secondary" global scope-class addresses. The loopback interface has only "::1", node-local scope-address. If a destination address is in node-local scope-class, the source address must be "::1". If a destination address is in link-local scope-class, the source address must be the link-local-use address of the outgoing interface. For example, consider the case to send data to "FF01::1", all node multicast address. An application specifies an interface index number as well as the destination address. Kernel can select the link-local-use address of the given interface. If a destination address is in global scope-class, the source address must be one of primary global scope-class addresses assigned to interfaces. If a source address has been already chosen for the communication (like TCP), it is used independent on the outgoing interface. Otherwise (like UDP), the primary global scope-class address of the outgoing interface is selected as a source address. That is, as far as global scope-class unicast addresses are concerned, a node can listen to all packets destined to all addresses assigned to its interfaces but must use the primary global scope-class addresses when it speaks. The BSD API bind() function specifies a listening address and a YAMAMOTO [Page 5] Internet-Draft The IPv6 communication model September 1996 listening port. This rule can apply for both unicast address and multicast address. If the bind() function is called with a specific unicast address, the source address of the communication is the unicast address. If the bind() function is called with IPV6ADDR_ANY_INIT or a multicast address, both the destination address of the incoming packet and the incoming interface can be resolved by the recvfrom() function thanks to sockaddr_in6 extension defined in this memo. The source address of outgoing packets generated by the sendto() function and the outgoing interface are determined by the rule described up above. 6. Packet Processing This section defines how to process packets according to their scope-class. It is supposed that hosts have input and output routines for IPv6 packets. It is also assumed that routers have a forward routine in additions to input and output routines. Illegal packets are filtered out on the beginning of each routines as follows: routine (PACKET) { if (SC(src of PACKET) is NG) { Discard the packet. Generate an ICMP error message if necessary. } if (SC(dst of PACKET) is NG) { Discard the packet. Generate an ICMP error message if necessary. } Do the routine job. } Here is a summary table for the three routines. Source Unicast unspecified OK not clear(*1) OK loopback from lo0(*2) meaningless(*3) to lo0(*4) link OK NG OK site OK if !pbound(*5) OK global OK OK OK undefined OK OK OK Multicast NG NG NG Anycast same as UC(*6) same as UC(*6) NG Destination Unicast/Anycast unspecified NG NG NG loopback from lo0(*2) meaningless(*3) to lo0(*4) link OK NG OK YAMAMOTO [Page 6] Internet-Draft The IPv6 communication model September 1996 site OK if !pbound(*5) OK global OK OK OK undefined OK OK OK Multicast node from lo0(*2) meaningless(*3) to lo0(*4) link OK NG OK site OK if !sbound(*7) OK organization OK if !obound(*8) OK global OK OK OK undefined NG NG NG OK -- Put the packet into the forward step. NG -- Discard the packet. *1 -- Need to research to fill this blank *2 -- If the packet comes from the loopback interface, OK. Otherwise, NG. *3 -- It is meaningless to forward this packet. The action is implementation dependent. *4 -- If the packet goes to the loopback interface, OK. Otherwise, NG. *5 -- If the packet is forwarded to the same private Internet, OK. Otherwise, NG. *6 -- Cannot distinguish anycast packets from unicast in input or forward routine. So, follow the same action of unicast. *7 -- If the packet is forwarded to the same site, OK. Otherwise, NG. *8 -- If the packet is forwarded to the same organization OK. Otherwise, NG. Implementation Note: some filter rules can be omitted to optimize performance. Appendix To conform this memo, some application must take an interface as an argument. A typical example is an ICMP ECHO/REPLY application called "ping". Here is a table of an outgoing interface and a source address for a given destination address and a given interface. That is, an action summary of "ping -i ". Outgoing Interface Source Address Unicast/Anycast node-local the loopback "::1" link-local the link-local-use address of global an interface the primary global resolved from scope-class address of the routing table the interface left Multicast YAMAMOTO [Page 7] Internet-Draft The IPv6 communication model September 1996 node-local the loopback "::1" link-local the link-local-use address of global an open problem an open problem Author's Address Kazuhiko YAMAMOTO Nara Institute of Science and Technology(NAIST) 8916-5 Takayama, Ikoma City 630-01 JAPAN Phone: +81-7437-2-5111 FAX: +81-7437-2-5329 EMail: kazu@is.aist-nara.ac.jp Atsushi ONOE Sony Corporation 3-3-1 Tsujido Shinmachi, Fujisawa City 251 JAPAN Phone: +81-466-30-4033 FAX: +81-466-30-4205 EMail: onoe@sm.sony.co.jp Akira KATO The University of Tokyo 2-11-16 Yayoi Bunkyo 113 JAPAN Phone: +81-3-3812-2111 ext 2726 FAX: +81-3-5684-7775 EMail: kato@wide.ad.jp References [1] R. Hinden, and S. Deering, "IP Version 6 Addressing Architecture", RFC1884, 1995. [2] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC1970, 1996. [3] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets", RFC1918, 1996. [4] R. E. Gilligan, S. Thomson, and J. Bound, "Basic Socket Interface Extensions for IPv6", Internet-Draft, , 1996. YAMAMOTO [Page 8] ----Next_Part(Wed_Sep_25_11:19:59_1996)---- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Sep 25 06:27:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14087; Wed, 25 Sep 96 06:27:21 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14081; Wed, 25 Sep 96 06:27:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA02027; Wed, 25 Sep 1996 06:21:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA19860; Wed, 25 Sep 1996 06:21:11 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id JAA06376; Wed, 25 Sep 1996 09:21:04 -0400 Date: Wed, 25 Sep 1996 09:21:04 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9609250921.ZM6374@seawind.bellcore.com> In-Reply-To: "Brian Carpenter CERN-CN" "(IPng 2138) Re: availability of PF_KEY" (Sep 24, 8:26am) References: <9609240626.AA04502@dxcoms.cern.ch> X-Mailer: Z-Mail (3.2.0 06sep94) To: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com Subject: (IPng 2140) Re: availability of PF_KEY Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm much more negative about the new French law than Christian, > because I think that national escrow schemes screw up international > deployment in the most impossible way. Brian, My opinion of key escrow is by no means less negative than yours. I was merely responding to Francis comment. It is a matter of half full and half empty glasses. Is authorisation of encryption with key escrow better or worse than a complete ban of encryption ? One may either look at it from Zimmerman's frog point of view, or believe that because escrow is untenable the law is merely one step towards complete liberalization. But the short answer for IPv6 is that atleast the AH can be deployed entirely freely in France, as well as some ESP. The restriction seems to apply to operation, not code distribution. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 26 04:19:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15163; Thu, 26 Sep 96 04:19:31 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA15157; Thu, 26 Sep 96 04:19:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA00394; Thu, 26 Sep 1996 04:13:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA14519; Thu, 26 Sep 1996 04:13:18 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA11669 for ; Thu, 26 Sep 1996 13:13:16 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA11918; Thu, 26 Sep 1996 13:13:16 +0200 Message-Id: <9609261113.AA11918@dxcoms.cern.ch> Subject: (IPng 2141) Re: availability of PF_KEY To: ipng@sunroof.eng.sun.com Date: Thu, 26 Sep 1996 13:13:15 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9609250921.ZM6374@seawind.bellcore.com> from "Christian Huitema" at Sep 25, 96 09:21:04 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As a matter of fact I spent yesterday in Paris, at a conference on cryptography regulations, sponsored by EPIC but atttended by the members of the OECD working group on crypto policy. There was no consensus there whether the new French law is an improvement or a worsening. The question of mandatory security in IPv6 was discussed explicitly (raised by Yves Le Roux of Digital). It's a good example of why restrictions including escrow are technically abhorrent. However, the view that it should be mandatory to implement prevailed in the IETF discussion last year. Shall we get back to technical discussion? Brian Carpenter >--------- Text sent by Christian Huitema follows: > > > I'm much more negative about the new French law than Christian, > > because I think that national escrow schemes screw up international > > deployment in the most impossible way. > > Brian, > My opinion of key escrow is by no means less negative than yours. I was > merely responding to Francis comment. It is a matter of half full and half > empty glasses. Is authorisation of encryption with key escrow better or > worse than a complete ban of encryption ? One may either look at it from > Zimmerman's frog point of view, or believe that because escrow is > untenable the law is merely one step towards complete liberalization. > > But the short answer for IPv6 is that atleast the AH can be deployed > entirely freely in France, as well as some ESP. The restriction seems to > apply to operation, not code distribution. > > -- > Christian Huitema > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 26 08:58:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15317; Thu, 26 Sep 96 08:58:56 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA15311; Thu, 26 Sep 96 08:58:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA26624; Thu, 26 Sep 1996 08:52:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA25924; Thu, 26 Sep 1996 08:52:38 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id LAA18028; Thu, 26 Sep 1996 11:56:03 -0400 Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id LAA06290; Thu, 26 Sep 1996 11:51:13 -0400 Date: Thu, 26 Sep 1996 11:51:13 -0400 From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <199609261551.LAA06290@pobox.BayNetworks.com> To: kazu@is.aist-nara.ac.jp Subject: (IPng 2142) Re: The IPv6 communication model Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kazu, A few comments on your draft: > > To ensure communication, this memo defines a basic principle for a > given IPv6 packet as follows: > > SC(src) = SC(r1) = SC(r2) = ... = SC(rn) = SC(dst) > > where "src" is the source address, "dst" is the destination address, > and r1, r2, ..., rn are intermediate nodes specified in the routing > header. > > This basic principle can be logically proved as follows: > > (1) In general, SC(src) must be greater than or equal to > SC(dst). That is, > > SC(src) >= SC(dst) > > must be satisfied. If not, it is often happened that the > receiving node cannot send back packets to the sending node. > > (2) If two nodes are on the same link, SC(dst) may be greater > than SC(src). For example, node A sends a packet to node B where > scope-class of its source address is link-local and that of > destination is global. In this case, node B can send back > packets to node A where scope-class of its source address is > global and that of destination is link-local. Unfortunately, > there is no way to tell that the two nodes are on the same link > in IPv6 scheme. > This is not entirely true. A node may learn about on-link address prefixes from ND's Router Advertisements. As matter of fact it will be quite common to see packets with link-local sorce addresses addressed to global-scope addresses, e.g. redirects. > (3) If two nodes are not on the same link, the following > condition must be satisfied according to (1): > > SC(src) >= SC(r1) >= SC(r2) >= ... >= SC(rn) >= SC(dst) > > Considering a reply packet, the following condition must be > satisfied: > > SC(src) <= SC(r1) <= SC(r2) <= ... <= SC(rn) <= SC(dst) > > Therefore, the following condition must be satisfied to ensure > communication for two nodes which are not on the same link. > > SC(src) = SC(r1) = SC(r2) = ... = SC(rn) = SC(dst) > Frankly, I'm lost here. E.g., I don't see any problem using a global scope address for sending packets to site-local destinations. > > 5. Source Address Selection > > Any physical interface must have exactly one link-local-use address. Any technical reason for such a limitation? What if I get multiple link-local addresses assigned to an interface? I don't not yet why I'd want it but don't see any reason to block my inventiveness in this area in the furture. > Any physical interface must have one "primary" global scope-class > address and may have one or more "secondary" global scope-class > addresses. I don't see any reason to force all implementations to divide global scope addresses on primary and secondary. If some implementation wants to do so, it's fine, but my implementation works great with multiple global addresses per interface without such a division. > The loopback interface has only "::1", node-local > scope-address. > The "loopback interface" term used by some vendors to identify something different from what you, I believe, try to define. In their definition it is a pseudo-interface that is not associated with a particular physical link but still can have addresses that can be used as packet source and destination. Such a "loopback interface" can have any scope addresses assigned to it. The advantage of this interface is that it stays up and is reachable as long as there is some connectivity to the corresponding node. The rest of document comes to conclusions that, I believe,are based on flawed premises. Regards, Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Sep 26 09:53:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15405; Thu, 26 Sep 96 09:53:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA15399; Thu, 26 Sep 96 09:52:41 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26375; Thu, 26 Sep 1996 09:46:42 -0700 Received: from jennie.bellcore.com by venus.Sun.COM (Sun.COM) id JAA19332; Thu, 26 Sep 1996 09:46:43 -0700 Received: from bellcore.com (localhost [127.0.0.1]) by jennie.bellcore.com (8.6.9/8.6.10) with ESMTP id MAA13181; Thu, 26 Sep 1996 12:46:30 -0400 Message-Id: <199609261646.MAA13181@jennie.bellcore.com> To: ipng@sunroof.eng.sun.com Cc: kazu@is.aist-nara.ac.jp, dhaskin@baynetworks.com (Dimitry Haskin), gja@bellcore.com Subject: (IPng 2143) Re: The IPv6 communication model In-Reply-To: Your message of Thu, 26 Sep 1996 11:51:13 -0400. <199609261551.LAA06290@pobox.BayNetworks.com> Date: Thu, 26 Sep 1996 12:46:28 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Kazu, [..] >>> 5. Source Address Selection >>> >>> Any physical interface must have exactly one link-local-use address. >> >>Any technical reason for such a limitation? What if I get multiple >>link-local addresses assigned to an interface? I don't not yet why >>I'd want it but don't see any reason to block my inventiveness >>in this area in the furture. Haven't read the full document, but I'm fairly sure I agree with Dimitry here. An obvious scenario is a node with a single physical interface supporting multiple _logical_ link-level interfaces, and each logical link interface supporting a virtual host (such a thing is conceivable, eg. in ATM environments). Each virtual host might be on the same IPv6 subnet, and so require separate link local addresses, even though there's only a single physical ATM NIC from which to derive some identifying key. cheers, gja ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Sep 27 14:21:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16552; Fri, 27 Sep 96 14:21:31 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA16546; Fri, 27 Sep 96 14:21:17 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA22261; Fri, 27 Sep 1996 14:15:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA02848; Fri, 27 Sep 1996 14:15:15 -0700 Received: from hpinpcb.cup.hp.com (hpindwx.cup.hp.com) by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA087568903; Fri, 27 Sep 1996 14:15:04 -0700 Received: by hpinpcb.cup.hp.com (1.37.109.16/15.5+IOS 3.20+cup+OMrelay) id AA132528960; Fri, 27 Sep 1996 14:16:00 -0700 From: "Bill Medlin" Message-Id: <9609271415.ZM13250@hpindwx.cup.hp.com> Date: Fri, 27 Sep 1996 14:15:59 -0700 X-Mailer: Z-Mail (3.2.1 10apr95) To: ipng@sunroof.eng.sun.com Subject: (IPng 2144) HP's IPv6 Implementation is Now Available Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello everyone, I am pleased to announce that HP's implementation of IPv6, developed by Peter Sjodin of the Swedish Institute of Computer Science, is now available for distribution for testing purposes. This implementation runs on the 9.05 release of hp-ux. This distribution will be limited to academic institutions who plan to use this implementation for research projects. The code will be made available on an application-response basis only. There will be no anonymous ftp access to the code. Note that this code is purely experimental. It is not supported by HP. No guarantees or warranties will be provided. If you are interested in obtaining access to this code, please send me e-mail at billmd@cup.hp.com. Bill Medlin IPv6 Project Manager Networked Computing Division Hewlett-Packard Company ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Sep 29 12:56:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17248; Sun, 29 Sep 96 12:56:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17242; Sun, 29 Sep 96 12:55:48 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA20866; Sun, 29 Sep 1996 12:49:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA14334; Sun, 29 Sep 1996 12:49:34 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA12759; Sun, 29 Sep 96 15:43:49 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id PAA13288; Sun, 29 Sep 1996 15:51:25 -0400 Date: Sun, 29 Sep 1996 15:51:25 -0400 Message-Id: <199609291951.PAA13288@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2145) The IPv6 communication model In-Reply-To: <3644.843618007@mine.aist-nara.ac.jp> References: <3644.843618007@mine.aist-nara.ac.jp> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I don't think there is anything to gain out of dividing global addresses into primary and secondary. The fact that a node has multiple global-scope IPv6 addresses implies that a node subscrbies to mulitple providers and in that case one would want to pick up the that global address as source address which has a longest match with the destination address. Now this statement about a finding a longest match can be extended with a little caution to addresses of all scope. If you find a match of length greater than zero, then you have found a source address of equivalent scope. If you don't find a match (i,e, a zero length match), then choose the address with highest scope. This algorithm works fine on single homed hosts. In case of multihomed nodes, one might want to extend this algorithm to first search all addresses on the outgoing interface based on the route to the destination. If no match is found, then one might or might not want to search other interfaces in an implementation defined fashion. In most normal cases, if you have a route for a destination thru an outgoing interface, you also are very like to have an address of equivalent scope on that interface. Obviously there are exception to this model when we try to cramp in too many features at the network layer. If someone tries to have a global scoped address on one interface and a site-local scoped address on another on purpose, for firewall designs or whatever, and if you have default routers on either side, than its difficult to choose the proper default router as specified by the neighbor discovery mechanism and hence the proper outgoing address and proper source address. Also adding an interface index in the socket interface is useful only on multihomed nodes and applications like routed. Instead one might want to use a socket option to specify an outgoing interface. This might mean an extra context swich (from kernel to user space) per send in applications like routed. In that case, one might open one socket per interface rather and use a socket option at initailization. Similary for receiving interface information, a socket option can be used and interface information will then be received as control part of a receive call. Regards, Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 30 00:55:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17473; Mon, 30 Sep 96 00:55:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17467; Mon, 30 Sep 96 00:55:12 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA29900; Mon, 30 Sep 1996 00:49:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA23981; Mon, 30 Sep 1996 00:48:56 -0700 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.198.61]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id QAA20858; Mon, 30 Sep 1996 16:48:40 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id HAA02495; Mon, 30 Sep 1996 07:49:47 GMT To: dhaskin@baynetworks.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2146) Re: The IPv6 communication model In-Reply-To: Your message of "Thu, 26 Sep 1996 11:51:13 -0400" References: <199609261551.LAA06290@pobox.BayNetworks.com> X-Mailer: Mew version 1.07 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 30 Sep 1996 16:49:47 +0900 Message-Id: <2492.844069787@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, From: dhaskin@BayNetworks.com (Dimitry Haskin) Subject: Re: (IPng 2139) The IPv6 communication model Date: Thu, 26 Sep 1996 11:51:13 -0400 > This is not entirely true. A node may learn about on-link address prefixes > from ND's Router Advertisements. I guess that you and I are saying the same thing. (Probably my poor explanation led you misunderstanding.) In some cases, a node can tell that other nodes are on the same link. In some cases, a node cannot tell that other nodes are on the same link. This is the point. We have to ensure communication in any case. If there is change to fail to communicate, we have to reject the approach. > Frankly, I'm lost here. E.g., I don't see any problem using a global scope > address for sending packets to site-local destinations. Please read again the draft. site-local use addresses are categorized to global scope-class. > Any technical reason for such a limitation? What if I get multiple > link-local addresses assigned to an interface? I don't not yet why > I'd want it but don't see any reason to block my inventiveness > in this area in the furture. You're right. I can modify this. I'm listing to other opinions. > I don't see any reason to force all implementations to divide global > scope addresses on primary and secondary. If some implementation wants > to do so, it's fine, but my implementation works great with multiple > global addresses per interface without such a division. Is there any generic algorithm to select a source address for a given destination address? If so, I'd like to learn it. Please explain. Anyway, I know the draft is not friendly with multi-home. I'm happy to modify the draft to reflect other's opinion. --Kazu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 30 01:19:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17510; Mon, 30 Sep 96 01:19:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17504; Mon, 30 Sep 96 01:19:06 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA02053; Mon, 30 Sep 1996 01:13:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA28106; Mon, 30 Sep 1996 01:12:49 -0700 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.198.61]) by mailgate.aist-nara.ac.jp (8.7.6+2.6Wbeta7/3.4W4/Naist2.0[gate]) with ESMTP id RAA22958; Mon, 30 Sep 1996 17:12:26 +0900 Received: from mine.aist-nara.ac.jp by mine.aist-nara.ac.jp (8.7.3/2.7W-AIST/1.3) id IAA02515; Mon, 30 Sep 1996 08:13:34 GMT To: qv@sparky.iol.unh.edu Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2147) Re: The IPv6 communication model In-Reply-To: Your message of "Sun, 29 Sep 1996 15:51:25 -0400" References: <199609291951.PAA13288@sparky.IOL.UNH.EDU> X-Mailer: Mew version 1.07 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Mon, 30 Sep 1996 17:13:34 +0900 Message-Id: <2512.844071214@mine.aist-nara.ac.jp> From: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, From: Quaizar Vohra Subject: (IPng 2139) The IPv6 communication model Date: Sun, 29 Sep 1996 15:51:25 -0400 > I don't think there is anything to gain out of dividing global > addresses into primary and secondary. The fact that a node has > multiple global-scope IPv6 addresses implies that a node subscrbies to > mulitple providers and in that case one would want to pick up the > that global address as source address which has a longest match with > the destination address. As I said in the previous message, I can modify this area. > Also adding an interface index in the socket interface is useful only > on multihomed nodes and applications like routed. Instead one might > want to use a socket option to specify an outgoing interface. This > might mean an extra context swich (from kernel to user space) per send > in applications like routed. In that case, one might open one socket > per interface rather and use a socket option at initailization. > Similary for receiving interface information, a socket option can be > used and interface information will then be received as control part > of a receive call. We have once discussed the setsockopt() approach but rejected it. The approach is fine for sending. But for receiving, as you said above, we have to open one socket per interface. This violates the current BSD socket model that opens just one socket and uses recvfrom() and recvmsg() to tell the source address. --Kazu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 30 03:11:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17592; Mon, 30 Sep 96 03:11:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17586; Mon, 30 Sep 96 03:11:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA09444; Mon, 30 Sep 1996 03:05:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA12597; Mon, 30 Sep 1996 03:05:16 -0700 Received: from shand.reo.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id FAA32506; Mon, 30 Sep 1996 05:56:08 -0400 (EDT) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA16653; Mon, 30 Sep 1996 10:56:03 +0100 Message-Id: <9609300956.AA16653@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2148) Re: Source Address selection Date: Mon, 30 Sep 96 10:56:03 +0100 From: (Mike Shand REO2 G/C2 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, I've not been paying attention to this list for the last few weeks. First, let me say that sorting out the source address selection issue is fundamental to getting Multihomed Hosts sorted out (there are other issues of course). I think it is VERY important that we get some serious technical discussion going on this. My draft has been around in various forms for a long time now and we have never managed to get anyone interested enough to discuss. I don't believe this is something where we can just make a bunch of proposals and all go home. There are a lot of interrelated decisions to be made from a lot of people's different persepectives. My draft was an attempt to get most of those issues out on the table so we can make some progress. I confess to having swapped all this stuff out of my working set, but if we are going to get serious I'll take the hit and start thinking about it again. Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 30 09:54:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17757; Mon, 30 Sep 96 09:54:05 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17038; Sat, 28 Sep 96 09:49:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA19256; Sat, 28 Sep 1996 09:43:52 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA07655; Sat, 28 Sep 1996 09:43:47 -0700 Received: from yogya.wasantara.net.id (yogya.wasantara.net.id [202.159.85.163]) by ns2.wasantara.net.id (8.6.11/8.6.9) with ESMTP id XAA12121 for ; Sat, 28 Sep 1996 23:47:34 +0700 Received: from YOGYA/SpoolDir by yogya.wasantara.net.id (Mercury 1.21); 28 Sep 96 23:50:05 GMT+0700 Received: from SpoolDir by YOGYA (Mercury 1.21); 28 Sep 96 23:49:50 GMT+0700 Received: from kadek.wasantara.net.id by yogya.wasantara.net.id (Mercury 1.21); 28 Sep 96 23:49:36 GMT+0700 Message-Id: <324D5309.1BCA@palu.wasantara.net.id> Date: Sat, 28 Sep 1996 23:32:09 +0700 From: I Putu Gede Widiana Organization: Kurdi Soft. Inc. X-Mailer: Mozilla 2.02Gold (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 2149) Interoperate Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If header translating router consider harmful, how does IPv6 only host interoperate with IPv4 only host ? Thanks...! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Sep 30 21:34:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18274; Mon, 30 Sep 96 21:34:32 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA18268; Mon, 30 Sep 96 21:34:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA18407; Mon, 30 Sep 1996 21:28:15 -0700 From: bound@ZK3.DEC.COM Received: by mercury.Sun.COM (Sun.COM) id VAA29404; Mon, 30 Sep 1996 21:28:15 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id AAA20464; Tue, 1 Oct 1996 00:20:49 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14392; Tue, 1 Oct 1996 00:20:48 -0400 Message-Id: <9610010420.AA14392@fwasted.zk3.dec.com> To: Kazuhiko Yamamoto =?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?= Cc: dhaskin@baynetworks.com, ipng@sunroof.eng.sun.com Subject: (IPng 2150) Re: The IPv6 communication model In-Reply-To: Your message of "Mon, 30 Sep 96 16:49:47 +0900." <2492.844069787@mine.aist-nara.ac.jp> Date: Tue, 01 Oct 96 00:20:47 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kazu, I pretty much agree with Dimitry and Quaizar comments. I also believe that your scope-class is inherent already in most of our implementations. Or else we would not all interoperate at the UNH bake-offs or on the 6bone. But it definitely is making me think about what we did, which is good. Many of us believe that the way to get the interface index is via the 4.4 cmsg-ctl structure and it should not be part of the socket structure. As far as the source address selection. I am still listening but have no response to the discussion thus far. But I will say for me who is not building a public domain implementation to tell you how we did it is not going to happen. It affects many aspects of the IPv6 engineering implementation. I believe the same will be the case for multihoming. I have no other comments on your draft. But look forward to the discussion. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com