From owner-ipng@sunroof.eng.sun.com Thu Apr 2 07:05:51 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id HAA04946 for ipng-dist; Thu, 2 Apr 1998 07:00:28 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id HAA04939 for ; Thu, 2 Apr 1998 07:00:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA12130 for ; Thu, 2 Apr 1998 07:00:14 -0800 Received: from edu.al.unipmn.it (bikini.edu.al.unipmn.it [193.206.63.17]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA20280 for ; Thu, 2 Apr 1998 07:00:03 -0800 (PST) Received: from localhost by edu.al.unipmn.it (SMI-8.6/SMI-SVR4) id QAA22293; Thu, 2 Apr 1998 16:58:19 +0200 Date: Thu, 2 Apr 1998 16:58:18 +0200 (MET DST) From: Luigi Cappelletto X-Sender: cappo@bikini To: ipng@sunroof.eng.sun.com Subject: (IPng 5529) TUNNEL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I am a student of ALessandria University. I'm experimenting ipv6 in our LAB but I'm not able to configure the tunnel. Someone can give me some hints, please ? Thank you in advance :) Luigi Cappelletto. Universita di Torino sede di Alessandria -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 2 12:45:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA05392 for ipng-dist; Thu, 2 Apr 1998 12:37:53 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id MAA05385 for ; Thu, 2 Apr 1998 12:37:48 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id MAA13533 for ; Thu, 2 Apr 1998 12:37:47 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id MAA29414 for ipng@sunroof.eng.sun.com; Thu, 2 Apr 1998 12:37:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id LAA05292 for ; Thu, 2 Apr 1998 11:36:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA03731 for ; Thu, 2 Apr 1998 11:36:23 -0800 Received: from porsta.cs.Helsinki.FI (porsta.cs.Helsinki.FI [128.214.48.124]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA25759 for ; Thu, 2 Apr 1998 11:36:24 -0800 (PST) Received: from hydra (hydra.Helsinki.FI [128.214.4.29]) by porsta.cs.Helsinki.FI (8.8.8/8.8.8) with SMTP id WAA26664 for ; Thu, 2 Apr 1998 22:36:12 +0300 Date: Thu, 2 Apr 1998 22:36:10 +0300 (EET DST) From: Marko Lamminen X-Sender: mlammine@hydra Reply-To: Marko Lamminen To: ipng@sunroof.eng.sun.com Subject: (IPng 5531) ICMP or UDP node info? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This topic came out in the last session but there weren't too many comments on it. I thought that maybe we should try it again, on the list. I'll write my opinion on this here, which will, hopefully, raise some conversation. After talking with few people (well, actually only two) I feel that this topic is actually dependand on few others. First we should decide whether we are going suggest and general node info type packets (Either udp or icmp) or do we just need a simple name service? If we go the general node info way, I feel we should use icmp. Two reasons, little better security and the fact that kernel can directly answer most or all of these queries and sending queries can be implemented as a system call that the resolver could use (to enable non-priviliged programs to use it). I emphasize that this does _not_ mean an extra api for the application since all this can be hidden behind the resolver. However, if we decide to loose the node info type, we are probably better off with UDP and simple name server running on isolated (dentist office) networks. And I wonder if this would even be our area at all, or should the simple name service be left to some other wg? As of my personal (inexperienced as it may be) view is to go for the general way, even if this means incorporating some traditionally non-routing level stuff in the icmp. But does give as a mechanism which to use in the future, should we ever need to obtain some other relevant information from nodes. And we still haven't figured out how to obtain scoping information about hosts, even if we get the global addresses for routers from router advertisements, eg. the "whats your other addresses?" icmp for host address scoping. Well, I hope to raise conversation about this in both topics, eg. to use generalized node info icmp messages or to use other methods obtaining this info and if we go the generalized, whether to use icmp or udp? -Marko Lamminen (Marko.Lamminen@cs.Helsinki.FI or hawk@nixu.fi) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 2 15:56:01 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id PAA05663 for ipng-dist; Thu, 2 Apr 1998 15:50:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id PAA05656 for ; Thu, 2 Apr 1998 15:50:28 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA09506 for ; Thu, 2 Apr 1998 15:50:24 -0800 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by earth.sun.com (8.8.8/8.8.8) with SMTP id PAA11809 for ; Thu, 2 Apr 1998 15:49:38 -0800 (PST) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id RAA10378; Thu, 2 Apr 1998 17:02:32 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA19591; Thu, 2 Apr 98 17:02:31+0530 Date: Thu, 2 Apr 1998 16:54:50 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5532) IPv6 packet over Ethernet Networks. To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All I was reading the internet draft on "Transmission of IPv6 Packets over Ethernet Networks" (draft-ietf-ipngwg-trans-ethernet-04.txt). I have a question regarding the same. I am student of ME in IISC. 1. Will there be any need for ARP, once the Ethernet 48 bit MAC address is encoded in 64 interface identifier. Can any one explain this or direct me to any other drafts which can make me understand the concepts more clearly. With Regards -Raghu. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 2 20:02:54 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id TAA05887 for ipng-dist; Thu, 2 Apr 1998 19:59:05 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id TAA05880 for ; Thu, 2 Apr 1998 19:58:54 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA02949 for ; Thu, 2 Apr 1998 19:58:53 -0800 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA23018 for ; Thu, 2 Apr 1998 19:58:54 -0800 (PST) Received: by INET-05-IMC with Internet Mail Service (5.5.1960.3) id <2FV066GC>; Thu, 2 Apr 1998 19:58:56 -0800 Message-ID: <4FD6422BE942D111908D00805F3158DF11123E@red-msg-52.dns.microsoft.com> From: Brian Zill To: "'Vadapalli.V.V.J.Raghu'" , ipng@sunroof.eng.sun.com Subject: (IPng 5533) RE: IPv6 packet over Ethernet Networks. Date: Thu, 2 Apr 1998 19:58:52 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Raghu, In IPv6, address resolution is performed by the network (i.e. IP) layer, and not by the individual link-layers (so there is no Ethernet ARP). As for drafts, you should look at Neighbor Discovery (ND), which is part of IPv6. The current draft is draft-ietf-ipngwg-discovery-v2-02.txt. The draft is an update to RFC 1970 (which might be easier to find). --Brian > 1. Will there be any need for ARP, once the Ethernet 48 bit MAC address is > > encoded in 64 interface identifier. > > Can any one explain this or direct me to any other drafts which > can make me understand the concepts more clearly. > > With Regards > -Raghu. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 12:11:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA06475 for ipng-dist; Fri, 3 Apr 1998 12:00:13 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA06468 for ; Fri, 3 Apr 1998 12:00:04 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA29386 for ; Fri, 3 Apr 1998 11:59:58 -0800 Received: from mentat.com ([192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA17040 for ; Fri, 3 Apr 1998 12:00:00 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA15849; Fri, 3 Apr 98 11:56:44 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA07690; Fri, 3 Apr 1998 12:01:21 -0800 Date: Fri, 3 Apr 1998 12:01:21 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804032001.MAA07690@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5534) Basic Sockets API X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, After listening to the debate over the definition of a site at the IPng sessions at IETF and after having spent the last couple of weeks im- plementing the Advanced Sockets API I have come the the conclusion that the sockaddr_in6 as currently defined does not have enough information. Specifically, it should include an interface index and possibly a site index depending on how the debate over the definition of a site turns out. My reasoning is quite simple. For unicast IPv4, the sockaddr_in con- tained all the information necessary to unambiguously identify the local and remote ends of a socket. There are some edge cases with broadcast and multicast where there is additional information required in the form of socket options but for unicast IPv4 the sockaddr_in is all that is required. For unicast IPv6, the information contained in a sockaddr_in6 is not adequate to unambiguously identify the local and remote ends of a socket. On multi-homed nodes, we need additional pieces of information in the form of an interface index and/or a site index to unambiguously identify a peer. Currently, the Advanced API specification uses an ancillary data item (IPV6_PKTINFO) to aid in the identification of limited scope peers. Unfortunately, most application writers who are converting their applications from an IPv4 only application to IPv6 capable application will not want to add handling of ancillary data items into their application. It would be much simpler for these application writers if the sockaddr_in6 contained a fully qualified address. This would guarantee that accept, getpeername, getsockname, recvfrom and recvmsg would return completely qualified addresses. There would be no need for the IPV6_PKTINFO option to aid in the identification of local or remote addresses. I am proposing that we redefine the sockaddr_in6 as follows in order aleviate the problems with scoped addresses and multi-homing. struct sockaddr_in6 { sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_flowinfo; uint32_t sin6_siteindex; uint32_t sin6_ifindex; struct in6_addr sin6_addr; }; or for the 4.4 BSD crowd. struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_flowinfo; uint32_t sin6_siteindex; uint32_t sin6_ifindex; struct in6_addr sin6_addr; }; In addition to helping correct some of the ugly problems in dealing with multi-homing these changes also have the added benefit of making the size of the sockaddr_in6 structure a multiple if the cache line size on all CPU's with which I am familiar. This is a good thing. We will need to add appropriate wording about zeroing the fields in the case that the application does not care which interface or site is used for a bind, connect, sendmsg or sendto call. Since the Basic API specification is still more or less open for changes and there are no shipping commercial host implementations to date I think that this is probably the last chance we will have to make this change. I hope that everyone will give it due consideration before screaming in horror at the lateness of this proposal. Comments? Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 13:29:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id NAA06668 for ipng-dist; Fri, 3 Apr 1998 13:22:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id NAA06661 for ; Fri, 3 Apr 1998 13:22:42 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA19469 for ; Fri, 3 Apr 1998 13:22:40 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA11595 for ; Fri, 3 Apr 1998 13:22:40 -0800 (PST) Received: by INET-03-IMC with Internet Mail Service (5.5.1960.3) id <2FV94J7C>; Fri, 3 Apr 1998 13:22:40 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81005831F9E@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'thartric@mentat.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 5535) RE: Basic Sockets API Date: Fri, 3 Apr 1998 13:22:30 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > After listening to the debate over the definition of a site at the > IPng sessions at IETF and after having spent the last couple of weeks im- > plementing the Advanced Sockets API I have come the the conclusion that > the > sockaddr_in6 as currently defined does not have enough information. > Specifically, it should include an interface index and possibly a site > index > depending on how the debate over the definition of a site turns out. > [Richard Draves] I agree, this would be a big improvement and I'd be happy to change our implementation along these lines. In our implementation hosts are almost always multi-homed - even hosts with only one physical interface also have a virtual interface for Carpenter/Jung 6-over-4. This makes it awkward for applications to use link-local addresses. Our current solution is that to send to a link-local address, you have to specify a source address to disambiguate which interface you mean. But even that isn't quite right, because a link-local source address might not uniquely specify an interface. And in most cases the application doesn't want to pick the source address; it's just an unnatural constraint. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 14:02:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id NAA06745 for ipng-dist; Fri, 3 Apr 1998 13:45:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id NAA06738 for ; Fri, 3 Apr 1998 13:45:32 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA25247 for ; Fri, 3 Apr 1998 13:45:30 -0800 Received: from mentat.com ([192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA26039 for ; Fri, 3 Apr 1998 13:45:31 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA17773; Fri, 3 Apr 98 13:42:14 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA07767; Fri, 3 Apr 1998 13:46:50 -0800 Date: Fri, 3 Apr 1998 13:46:50 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804032146.NAA07767@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5536) RE: Basic Sockets API Cc: richdr@microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > In our implementation hosts are almost always multi-homed - even > hosts with only one physical interface also have a virtual interface for > Carpenter/Jung 6-over-4. This makes it awkward for applications to use > link-local addresses. Our current solution is that to send to a link-local > address, you have to specify a source address to disambiguate which > interface you mean. But even that isn't quite right, because a link-local > source address might not uniquely specify an interface. And in most cases > the application doesn't want to pick the source address; it's just an > unnatural constraint. > Indeed, one of the reasons that the IPV6_ADD_MEMBERSHIP and IPV6_DROP_- MEMBERSHIP socket options now take an interface index rather than an address to specify the interface is because an address cannot unambiguously identify and interface in IPv6. In general we would like to have the job of the person who is upgrading an application from IPv4 only to IPv6 capable to have as easy a job as possible. By adding this information to the sockaddr_in6 we can remove one additional tweak from the porting process. Some applications may still need to understand interface indices and a site indices but by embedding those items in the sockaddr_in6 we have a completely self-contained description of the local and remote ends of the association. No extras required. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 14:34:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id OAA06908 for ipng-dist; Fri, 3 Apr 1998 14:26:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id OAA06901 for ; Fri, 3 Apr 1998 14:26:14 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA06936 for ; Fri, 3 Apr 1998 14:26:12 -0800 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA22818 for ; Fri, 3 Apr 1998 14:26:13 -0800 (PST) Received: by INET-04-IMC with Internet Mail Service (5.5.1960.3) id <2HQD49YR>; Fri, 3 Apr 1998 14:23:42 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81005831FA1@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'thartric@mentat.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 5537) Re: Basic Sockets API Date: Fri, 3 Apr 1998 14:23:40 -0800 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In general we would like to have the job of the person who is upgrading > an application from IPv4 only to IPv6 capable to have as easy a job as > possible. > By adding this information to the sockaddr_in6 we can remove one > additional > tweak from the porting process. Some applications may still need to > understand interface indices and a site indices but by embedding those > items in the sockaddr_in6 we have a completely self-contained description > of the local and remote ends of the association. No extras required. > [Richard Draves] If this is really going to be easy to use, then we should also change the string representation of IPv6 addresses to allow these indices to be optionally specified. That way when I specify an address to an application (on the command line, in a dialog box, whatever), I can specify the complete endpoint. Otherwise each application will have to invent ways to allow these indices to be specified. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 14:50:34 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id OAA07072 for ipng-dist; Fri, 3 Apr 1998 14:41:57 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id OAA07065 for ; Fri, 3 Apr 1998 14:41:48 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA10852 for ; Fri, 3 Apr 1998 14:41:45 -0800 Received: from mentat.com ([192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA02364 for ; Fri, 3 Apr 1998 14:41:45 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA18819; Fri, 3 Apr 98 14:38:24 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA07812; Fri, 3 Apr 1998 14:43:00 -0800 Date: Fri, 3 Apr 1998 14:43:00 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804032243.OAA07812@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5538) Re: Basic Sockets API Cc: richdr@microsoft.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > > > In general we would like to have the job of the person who is upgrading > > an application from IPv4 only to IPv6 capable to have as easy a job as > > possible. > > By adding this information to the sockaddr_in6 we can remove one > > additional > > tweak from the porting process. Some applications may still need to > > understand interface indices and a site indices but by embedding those > > items in the sockaddr_in6 we have a completely self-contained description > > of the local and remote ends of the association. No extras required. > > > [Richard Draves] If this is really going to be easy to use, then we > should also change the string representation of IPv6 addresses to allow > these indices to be optionally specified. That way when I specify an address > to an application (on the command line, in a dialog box, whatever), I can > specify the complete endpoint. Otherwise each application will have to > invent ways to allow these indices to be specified. > I agree that it would be easier if we could specify something like: telnet fe80::a00:3eff:fe22:3b27,1,0 where the first index is the interface and the second is the site. I think this would be superior to every application needing an extra command line argument like the example below. telnet lan0 fe80::a00:3eff:fe22:2b27 I suggested this possibility to a few folks yesterday and was not over- whelmed with enthusiastic responses to the suggestion. I may have just picked a tough crowd. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 17:07:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id QAA07640 for ipng-dist; Fri, 3 Apr 1998 16:59:40 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id QAA07633 for ; Fri, 3 Apr 1998 16:59:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA16177 for ; Fri, 3 Apr 1998 16:59:30 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA17677 for ; Fri, 3 Apr 1998 16:59:31 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA00532; Fri, 3 Apr 1998 16:59:27 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199804032001.MAA07690@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Apr 1998 17:00:47 -0800 To: thartric@mentat.com (Tim Hartrick) From: Steve Deering Subject: (IPng 5539) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim's proposal sounds like the right thing to me. Perhaps the "ifindex" really ought to be a "linkindex", since a node may actually have more than one interface on the same link. I presume there would be a reserved value (zero? all ones?) to use in either the siteindex or ifindex/linkindex field to indicate "unspecified"? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 17:23:25 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id RAA07818 for ipng-dist; Fri, 3 Apr 1998 17:16:02 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id RAA07811 for ; Fri, 3 Apr 1998 17:15:52 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA20012 for ; Fri, 3 Apr 1998 17:15:51 -0800 Received: from mentat.com ([192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id RAA24988 for ; Fri, 3 Apr 1998 17:15:53 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA21709; Fri, 3 Apr 98 17:12:46 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA07933; Fri, 3 Apr 1998 17:17:23 -0800 Date: Fri, 3 Apr 1998 17:17:23 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804040117.RAA07933@feller.mentat.com> To: deering@cisco.com Subject: (IPng 5540) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > > Tim's proposal sounds like the right thing to me. Perhaps the "ifindex" > really ought to be a "linkindex", since a node may actually have more > than one interface on the same link. I presume there would be a reserved > value (zero? all ones?) to use in either the siteindex or ifindex/linkindex > field to indicate "unspecified"? > Yes a node can have more than one interface on a link however it is difficult for IPv6 to determine when that is the case. In fact there are a number of IPv4 clustering solutions out there which depend on the IPv4 stack being ignorant of the fact that it has multiple interfaces attached to the same wire. It is difficult to see how an IPv6 stack could determine unabiguously when it had multiple interfaces on the same wire. With VLANs and switched LANs the definition of a link is quite fuzzy and it gets even fuzzier by the time the packets actually get to IP[v6]. I am inclined to leave the description as an interface index since that is IP[v6]'s point of attachment, to borrow an OSI term. Also, since each of the interfaces which is attached to the single link will presumably have a different link-local address for which one would like to perform DAD etc. it still seems important to have the ability to designate a specific interface in a sendto call. Assuming that IPv6 could determine that it had multiple interfaces on the same link the "linkindex" would still be ambiguous for the purposes of performing DAD or other ND functions. In the current API documents (Basic and Advanced) zero is used as the value for the "unspecified" interface. It would probably be best to use zero as the value for the "unspecified" site as well. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 17:38:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id RAA07882 for ipng-dist; Fri, 3 Apr 1998 17:32:44 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id RAA07875 for ; Fri, 3 Apr 1998 17:32:35 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA23917 for ; Fri, 3 Apr 1998 17:32:33 -0800 Received: from iisc.ernet.in ([144.16.64.3]) by earth.sun.com (8.8.8/8.8.8) with SMTP id RAA02745 for ; Fri, 3 Apr 1998 17:31:47 -0800 (PST) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id LAA08161; Fri, 3 Apr 1998 11:31:11 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA06101; Fri, 3 Apr 98 11:31:09+0530 Date: Fri, 3 Apr 1998 11:25:56 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Reply-To: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5541) IPv6 version 2(draft-ietf-ipngwg-ipv6-spec-v2-01.txt) To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All I was reading the internet draft on IPv6 version 2. I have few questions regarding the new "Traffic Class" field. Can anyone please answer my doubts. Thanks in advance. 1.whether the definition of "Traffic class" in IPv6 will lead to some sort of TOS based routing. 2. The internet draft "A Proposal for the Format and Semantics of the TOS Byte and Traffic Class Byte in IPv4 and IPv6 Headers" draft-ellesson-tos-00.txt. defines the Explicit Service Class bits in which there are three classes are provided for the RSVP based flows. since RSVP Tspec are in the form of . How the application will be mapped to RSVP Explicit Service Class. Whether it will depend on the application to choose the service class. If it so, the IPv6 version 2 specification says that "Nodes that support a specific (experimental or eventual standard) use of some or all of the Traffic Class bits are permitted to change the value of those bits in packets that they originate, forward, or receive, as required for that specific use. Nodes should ignore and leave unchanged any bits of the Traffic Class field for which they do not support a specific use." When a interim router changes the Traffic class bit, then what will happen to the application. Whether it will degrade the application QoS when congestion occurs. I think the classification of the RSVP service classes should depend on applications. The draft draft-ellesson-tos-00.txt says that "One possible implementation method is to direct packets with a specific service class to an associated class-based queue [CBQ]. This permits the service class to act as an index into a queue that has been configured for a particular traffic type, in the same way that the port numbers are used today on commercial intranets. Note that the combination of source/ destination address, protocol id, and service class can be used in the same way, that is, as an index into a queue." Then RSVP packet classifier and Schedular should use this service class for packet forwarding. So now the identifier becomes Is it right!!. Is it compulsory for all the packets of same flow to have the service class. What it means is the service class is same all packets of the flow or it will depend on the packet content. with regards -Raghu. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 18:11:04 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id SAA08006 for ipng-dist; Fri, 3 Apr 1998 18:02:03 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id SAA07999 for ; Fri, 3 Apr 1998 18:01:51 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA28937 for ; Fri, 3 Apr 1998 18:01:49 -0800 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA14623 for ; Fri, 3 Apr 1998 18:01:52 -0800 (PST) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA07043; Fri, 3 Apr 1998 18:01:47 -0800 (PST) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199804040117.RAA07933@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 3 Apr 1998 18:03:07 -0800 To: thartric@mentat.com (Tim Hartrick) From: Steve Deering Subject: (IPng 5542) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:17 PM -0800 4/3/98, Tim Hartrick wrote: > It is difficult to see how an IPv6 stack could determine unabiguously > when it had multiple interfaces on the same wire. It could be configured to know. (One could also, maybe, someday, invent automatic means of detection, like sending periodic "discard" packets from each of a nodes's interfaces, addressed to each of the node's other interfaces' link-local addresses and seeing if they arrive. Or something. Let's not quibble about the details.) > Also, since each of the interfaces which is attached to the single link > will presumably have a different link-local address for which one would like > to perform DAD etc. it still seems important to have the ability to designate > a specific interface in a sendto call. Right you are. An alternative you *might* want to consider is a "scope identifier" structure containing two elements: scope_type: [GLOBAL|SITE|LINK|INTERFACE] scope_instance: integer index (0 = unspecified; meaningless for GLOBAL) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 3 23:16:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id XAA08270 for ipng-dist; Fri, 3 Apr 1998 23:10:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id XAA08263 for ; Fri, 3 Apr 1998 23:10:00 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA23705 for ; Fri, 3 Apr 1998 23:09:59 -0800 Received: from mail.wrs.com ([147.11.1.11]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id XAA27090 for ; Fri, 3 Apr 1998 23:10:01 -0800 (PST) Received: from pansy.wrs.com (dialup56.wrs.com [147.11.15.56]) by mail.wrs.com (8.8.6/8.8.5) with SMTP id XAA02374; Fri, 3 Apr 1998 23:09:46 -0800 (PST) Message-Id: <3.0.5.32.19980403172001.007d2680@wrs.com> X-Sender: gnn@wrs.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 03 Apr 1998 17:20:01 -0800 To: thartric@mentat.com (Tim Hartrick) From: "George V. Neville-Neil" Subject: (IPng 5543) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com, richdr@microsoft.com In-Reply-To: <199804032243.OAA07812@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:43 PM 4/3/98 -0800, Tim Hartrick wrote: >I agree that it would be easier if we could specify something like: > >telnet fe80::a00:3eff:fe22:3b27,1,0 > >where the first index is the interface and the second is the site. > >I think this would be superior to every application needing an extra >command line argument like the example below. > >telnet lan0 fe80::a00:3eff:fe22:2b27 > > Umm, perhaps I missed something on the list, but I don't think I did... You don't really consider this "easy to use" do you? I gather this is the Wizard's way of doing this much as I use telnet 128.32.42.2 25 right now. Saying the syntax's are "easy to use" is going a bit far. I understand the problem with the ambiguity, but there must be an easier way to hide this from the user. Later, George -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Apr 4 13:10:28 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id NAA08763 for ipng-dist; Sat, 4 Apr 1998 13:04:40 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id NAA08756 for ; Sat, 4 Apr 1998 13:04:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA14346 for ; Sat, 4 Apr 1998 13:04:27 -0800 Received: from mentat.com ([192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA01143 for ; Sat, 4 Apr 1998 13:04:29 -0800 (PST) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA11332; Sat, 4 Apr 98 13:01:20 PST Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA08307; Sat, 4 Apr 1998 13:05:58 -0800 Date: Sat, 4 Apr 1998 13:05:58 -0800 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804042105.NAA08307@feller.mentat.com> To: itojun@itojun.org Subject: (IPng 5546) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > Comments on this: > 1. If the proposal is to be incorporated, please be sure to put > sin6_addr right next to sin6_flowinfo, since many implementations > based on old spec sheet is already there. I believe we must at > least provide backward-compatibility. I am not sure I see any reason for this from an application point of view. Binary compatibility is broken as soon as the structure size changes so keeping the fields in the same order will not alleviate any binary com- patibility problems. If you are using the adjacency of the fields in your radix tree lookup then I guess I understand your request. > 2. I don't think sin6_siteindex and sin6_ifindex needs 32bits. > 8bit should be enough since they are local to each host. No they probably don't, however, interface indices are already expressed as uint32_t's in a number of other places in the basic and advanced API documents. For consistency it makes sense to have the fields be 32 bits. Also, as I noted in my earlier mail, using uint32_t's for the new fields will make the sockaddr_in6 a multiple of the cache line size. This will have performance benefits for many implementations. > 3. As a result, I'll be much happier to have the below, than Tim's > proposal: > struct sockaddr_in6 { > uint8_t sin6_len; > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_flowinfo; > struct in6_addr sin6_addr; > uint8_t sin6_siteindex; > uint8_t sin6_ifindex; > }; Something like: struct sockaddr_in6 { sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_ifindex; uint32_t sin6_siteindex; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; }; will satisfy your requirement that the sin6_flowinfo and sin6_addr be contiguous. The embedding of interface identification directly in the link-local addresses was discussed at length and rejected as a solution to this problem. I had also implemented a similar scheme at one time but once the working group had spoken on the issue of embedding indices inside the addresses I removed the code because the remapping of the addresses between the kernel and user space was not worth the effort. The problem here is that we don't want applications to have to carry around ancillary data items just to identify their peer. By including the indices in the sockaddr_in6 we have a self-contained description of a peer. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Apr 5 04:13:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id EAA09255 for ipng-dist; Sun, 5 Apr 1998 04:09:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id EAA09248 for ; Sun, 5 Apr 1998 04:09:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA21366 for ; Sun, 5 Apr 1998 04:09:31 -0700 Received: from iisc.ernet.in ([144.16.64.3]) by earth.sun.com (8.8.8/8.8.8) with SMTP id EAA11957 for ; Sun, 5 Apr 1998 04:08:33 -0700 (PDT) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id QAA09217; Sun, 5 Apr 1998 16:37:55 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA02753; Sun, 5 Apr 98 16:37:51+0530 Date: Sun, 5 Apr 1998 16:36:12 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5547) IGMP version for IPV6. To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All Are there any internet drafts related on IGMP to support IPv6. With Regards -Raghu. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Apr 5 07:23:22 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id HAA09393 for ipng-dist; Sun, 5 Apr 1998 07:16:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id HAA09386 for ; Sun, 5 Apr 1998 07:16:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA06375 for ; Sun, 5 Apr 1998 07:16:02 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA16265 for ; Sun, 5 Apr 1998 07:16:03 -0700 (PDT) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA12043; Sun, 5 Apr 1998 07:07:43 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 5 Apr 1998 06:08:48 -0800 To: "Vadapalli.V.V.J.Raghu" From: Steve Deering Subject: (IPng 5548) Re: IGMP version for IPV6. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:06 AM -0800 4/5/98, Vadapalli.V.V.J.Raghu wrote: > Are there any internet drafts related on IGMP to support IPv6. Yes. See draft-ietf-ipngwg-mld-00.txt. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Apr 5 10:15:12 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id KAA09532 for ipng-dist; Sun, 5 Apr 1998 10:09:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id KAA09525 for ; Sun, 5 Apr 1998 10:09:26 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA18419 for ; Sun, 5 Apr 1998 10:09:25 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA22650 for ; Sun, 5 Apr 1998 10:09:25 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id NAA09067; Sun, 5 Apr 1998 13:09:23 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03386; Sun, 5 Apr 1998 13:09:23 -0400 Message-Id: <199804051709.AA03386@wasted.zk3.dec.com> To: Steve Deering Cc: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 5549) Re: Basic Sockets API In-Reply-To: Your message of "Fri, 03 Apr 1998 18:03:07 PST." Date: Sun, 05 Apr 1998 13:09:23 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, I have connected with my co-authors on this issue and we will discuss. Seems to me we have to do this whether it is the right thing to do or not.. I asked a few folks after discussing this with Tim offline at L.A. about site-local issue. Several comments I received were that site and link local addresses may be best used for sys admin functions and not applications. Before we change one of the essential ingredients for IPv6, I would like to be sure this is really a done deal? The index is definitely useful for the multihome case. We should keep the sin6_addr and sin6_flowinfo contiguous as below as it has benefit in the radix tree and RSVP admin and scheduling policy for IPv6. struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_ifindex; uint32_t sin6_siteindex; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; }; >> Also, since each of the interfaces which is attached to the single link >> will presumably have a different link-local address for which one would like >> to perform DAD etc. it still seems important to have the ability to designate >> a specific interface in a sendto call. >Right you are. An alternative you *might* want to consider is a "scope >identifier" structure containing two elements: > scope_type: [GLOBAL|SITE|LINK|INTERFACE] > scope_instance: integer index (0 = unspecified; meaningless for GLOBAL) This can be done by defining a macro. p.s. this is significant and for the ISVs that have already started porting to IPv6 with several of our implementations. we have real customers using this API now and we need to begin considering that and we are leaving test mode for this API quickly. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 07:00:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id GAA10111 for ipng-dist; Mon, 6 Apr 1998 06:51:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id GAA10104 for ; Mon, 6 Apr 1998 06:51:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA09202 for ; Mon, 6 Apr 1998 06:51:15 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA26978 for ; Mon, 6 Apr 1998 06:51:16 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id JAA15127; Mon, 6 Apr 1998 09:51:08 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id JAA18326; Mon, 6 Apr 1998 09:51:07 -0400 (EDT) Date: Mon, 6 Apr 1998 09:51:07 -0400 (EDT) From: Christian Huitema Message-Id: <980406095107.ZM18324@seawind.bellcore.com> In-Reply-To: bound@zk3.dec.com "(IPng 5549) Re: Basic Sockets API" (Apr 5, 1:09pm) References: <199804051709.AA03386@wasted.zk3.dec.com> X-Mailer: Z-Mail (5.0.0 30July97) To: bound@zk3.dec.com, Steve Deering Subject: (IPng 5551) Re: Basic Sockets API Cc: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, I think that Jim is right on the mark. Using scoped addresses in application is *not* a good idea. We have two choices here, not just one: 1) update the interface format to include link and site specification in addresses. 2) not update it, and make it real hard to use scoped addresses in applications. I would personally go for option 2. Option 1, if abuse, will lead to stupidities like specifying a link for a fully defined address, and then see the connection break when the routing changes. One in between road is to specify a sockaddr for binding a socket to a link, or a site. Note that the possible benefits of site addresses, i.e. the net 10 property of not being sensitive to renumbering, can also be achieved by using unique but not routable addresses (see Moskowitz's "net 66" proposal.) -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 09:33:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA10316 for ipng-dist; Mon, 6 Apr 1998 09:29:12 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id JAA10309 for ; Mon, 6 Apr 1998 09:29:06 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id JAA25095 for ; Mon, 6 Apr 1998 09:29:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA07302 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 09:28:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id DAA08397 for ; Sat, 4 Apr 1998 03:11:46 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA04079 for ; Sat, 4 Apr 1998 03:11:45 -0800 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id DAA00094 for ; Sat, 4 Apr 1998 03:11:44 -0800 (PST) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id UAA24688; Sat, 4 Apr 1998 20:11:28 +0900 (JST) To: thartric@mentat.com (Tim Hartrick) cc: ipng@sunroof.eng.sun.com In-reply-to: thartric's message of Fri, 03 Apr 1998 12:01:21 PST. <199804032001.MAA07690@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5553) Re: Basic Sockets API From: Jun-ichiro itojun Itoh Date: Sat, 04 Apr 1998 20:11:28 +0900 Message-ID: <24684.891688288@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, this is itojun, Tim: > I am proposing that we redefine the sockaddr_in6 as follows in order >aleviate the problems with scoped addresses and multi-homing. >struct sockaddr_in6 { > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_flowinfo; > uint32_t sin6_siteindex; > uint32_t sin6_ifindex; > struct in6_addr sin6_addr; >}; >or for the 4.4 BSD crowd. >struct sockaddr_in6 { > uint8_t sin6_len; > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_flowinfo; > uint32_t sin6_siteindex; > uint32_t sin6_ifindex; > struct in6_addr sin6_addr; >}; Comments on this: 1. If the proposal is to be incorporated, please be sure to put sin6_addr right next to sin6_flowinfo, since many implementations based on old spec sheet is already there. I believe we must at least provide backward-compatibility. 2. I don't think sin6_siteindex and sin6_ifindex needs 32bits. 8bit should be enough since they are local to each host. 3. As a result, I'll be much happier to have the below, than Tim's proposal: struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; uint8_t sin6_siteindex; uint8_t sin6_ifindex; }; 4. (actually I'm a bit tired to follow too many changes... oh my gosh!) And our $0.02: Our (WIDE) implementation uses specially formed IPv6 address in the kernel, which embeds sin6_ifindex (interface index for link-local addresses) into s6_addr8[3], like: fe80:0009:0000:0000:0200:86ff:fe05:80da ff02:0009::1 In the past (before we implement advanced API) the form is used in the kernel as well as in the userland. The problem was that we must rewrite all the link-local addresses at kernel boundary, and network boundary. We must always rewrite the address for both inbound and outbound traffic. This is not very healthy for the application programmers. (at least, this is not portable) userland fe80:0009::1234:5678 ================ syscall entrypoint fe80:0009::1234:5678 ---------------- netinet6 fe80:0009::1234:5678 ----------------rewrite to fe80:0000::1234:5678 on output ethernet driver fe80:0000::1234:5678 | ==+=======================================+== The current implementation uses this form only in the kernel. Externally we obey advanced API, and internally we use the above address format (in routing table and other places). userland fe80:0000::1234:5678 + advapi(if=9) ================ syscall entrypoint fe80:0000::1234:5678 + advapi(if=9) ---------------- netinet6 fe80:0009::1234:5678 ----------------rewrite to fe80:0000::1234:5678 on output ethernet driver fe80:0000::1234:5678 | ==+=======================================+== To grab our implementation visit http://www.v6.wide.ad.jp/ or ftp://ftp.itojun.org/pub/ipv6/. Jun-ichiro itojun Itoh@already back to japan WIDE project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 09:33:51 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA10307 for ipng-dist; Mon, 6 Apr 1998 09:27:38 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id JAA10300 for ; Mon, 6 Apr 1998 09:27:31 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id JAA24955 for ; Mon, 6 Apr 1998 09:27:30 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA07264 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 09:27:21 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id BAA08344 for ; Sat, 4 Apr 1998 01:13:51 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA00097 for ; Sat, 4 Apr 1998 01:13:51 -0800 Received: from milou.comp.lancs.ac.uk (milou.comp.lancs.ac.uk [194.80.34.7]) by earth.sun.com (8.8.8/8.8.8) with SMTP id BAA01293 for ; Sat, 4 Apr 1998 01:13:49 -0800 (PST) Received: from scott (scott.lancs.ac.uk) by milou.comp.lancs.ac.uk; Sat, 4 Apr 1998 10:12:11 +0100 Received: by localhost with Microsoft MAPI; Sat, 4 Apr 1998 10:06:03 +0100 Message-Id: <01BD5FB1.46D18BF0.acs@comp.lancs.ac.uk> From: Andrew Scott Reply-To: "acs@comp.lancs.ac.uk" To: "'netdev@nuclecu.unam.mx'" , "'ipng@sunroof.eng.sun.com'" , "'6bone@isi.edu'" <6bone@isi.edu>, "'mobile-ip@hosaka.smallworks.com'" Subject: (IPng 5552) draft-ietf-mobileip-ipv6-05 Compliant Mobile IPv6 Implementation Date: Sat, 4 Apr 1998 10:06:01 +0100 Organization: Lancaster University X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, Following the release of the draft mobile IPv6 v5 spec we're releasing our IPv6 mobility package with the following features: Standards compliant (draft v5) mobile IPv6 implementation as specified in draft-ietf-mobileip-ipv6-05 Support for routers, correspondent nodes, and mobile nodes Includes support of route collapsing/optimisation Supports applications using UDP, TCP, and ICMP protocols Tested for efficient handovers using Lancaster video server (being released at the same time) Includes fast PCMCIA hot swapping support with fast network handover, for example, between Ethernet and Wavelan networks Provided as an kernel installable module Also includes new support for MAC layer roaming support for Wavelan networks Runs on latest 2.1.9x series Linux kernels Please see http://www.cs-ipv6.lancs.ac.uk/ipv6/MobileIP/ for more details about downloading and running the system. Similar details for the video server, which we've been using to test the system, are available at http://www.cs-ipv6.lancs.ac.uk/ipv6/videoserver/. Lancaster IPv6 Group -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 10:09:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id KAA10456 for ipng-dist; Mon, 6 Apr 1998 10:00:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id KAA10449 for ; Mon, 6 Apr 1998 10:00:17 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id KAA00900 for ; Mon, 6 Apr 1998 10:00:16 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id KAA07393 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 10:00:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id XAA09896 for ; Sun, 5 Apr 1998 23:20:43 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA05729 for ; Sun, 5 Apr 1998 23:20:42 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id XAA25160 for ; Sun, 5 Apr 1998 23:20:39 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id PAA29757; Mon, 6 Apr 1998 15:20:38 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (3.2) id xma029714; Mon, 6 Apr 98 15:20:21 +0900 Received: from localhost (localhost.aist-nara.ac.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id PAA03900 for ; Mon, 6 Apr 1998 15:33:01 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 5554) Re: Basic Sockets API From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: Your message of "Fri, 3 Apr 1998 17:00:47 -0800" References: X-Mailer: Mew version 1.93b26 on Emacs 20.2 / Mule 3.0 (MOMIJINOGA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980406153300L.kazu@Mew.org> Date: Mon, 06 Apr 1998 15:33:00 +0900 X-Dispatcher: imput version 980302 Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Steve Deering Subject: (IPng 5539) Re: Basic Sockets API Date: Fri, 3 Apr 1998 17:00:47 -0800 > Tim's proposal sounds like the right thing to me. Perhaps the "ifindex" > really ought to be a "linkindex", since a node may actually have more > than one interface on the same link. I presume there would be a reserved > value (zero? all ones?) to use in either the siteindex or ifindex/linkindex > field to indicate "unspecified"? Tim's proposal is exactly the same what WIDE Project proposed in the scope draft one year and half ago. Unfortunately, nobody supported our proposal then it was rejected. We should not repeat the same discussion again. --Kazu, WIDE Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 10:33:45 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id KAA10595 for ipng-dist; Mon, 6 Apr 1998 10:23:31 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id KAA10588 for ; Mon, 6 Apr 1998 10:23:19 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id KAA05042; Mon, 6 Apr 1998 10:23:14 -0700 (PDT) Date: Mon, 6 Apr 1998 10:20:54 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5555) Re: Basic Sockets API To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199804032001.MAA07690@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am proposing that we redefine the sockaddr_in6 as follows in order > aleviate the problems with scoped addresses and multi-homing. > > struct sockaddr_in6 { > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_flowinfo; > uint32_t sin6_siteindex; > uint32_t sin6_ifindex; > struct in6_addr sin6_addr; > }; I agree. Note that the RFC allows implementations to place the fields in any order (section 2.4 in RFC 2133). However, I'd suggest we recommend the order have the sin6_addr before the new fields. > We will need to add appropriate wording about zeroing the fields in > the case that the application does not care which interface or site is used > for a bind, connect, sendmsg or sendto call. OK. I wonder if we should also include a statement saying that getaddrinfo() might (depending on the implementation) set the sin6_ifindex and/or sin6_siteindex to a non-zero value. I also wonder if we should make sin6_siteindex instead be just reserved field (sin6_reserved) that the applications must set to zero on transmit and ignore on receipt. That way we don't have to pin the API to the future of site-local addresses. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 10:34:54 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id KAA10614 for ipng-dist; Mon, 6 Apr 1998 10:31:12 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id KAA10607 for ; Mon, 6 Apr 1998 10:30:57 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id KAA06486; Mon, 6 Apr 1998 10:30:54 -0700 (PDT) Date: Mon, 6 Apr 1998 10:28:34 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5556) Re: Basic Sockets API To: Richard Draves Cc: "'thartric@mentat.com'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D81005831FA1@red-msg-50.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [Richard Draves] If this is really going to be easy to use, then we > should also change the string representation of IPv6 addresses to allow > these indices to be optionally specified. That way when I specify an address > to an application (on the command line, in a dialog box, whatever), I can > specify the complete endpoint. Otherwise each application will have to > invent ways to allow these indices to be specified. My assumption is that getaddrinfo() would set the fields as needed when using a name service. Thus if getaddrinfo() somehow (e.g. using the link names draft protocol by Dan Harrington) finds a link-local address it would set sin6_ifindex to the correct value. Similar things could apply to site-local addresses. But I'm a little bit concerned about specifying ifindicies and siteindicies in textual format since this might imply additional stability requirements on those indicies. The typical implementation would have a hard time ensuring that such an index doesn't change across a reboot (especially when the reboot is associated with adding or deleting one or more interfaces). For the few applications (mostly "debugging" ones like traceroute, ping etc) I don't see much pain in having additional syntax to specify the site/ifindex. But I think it might invite more trouble than it is worth to allow arbitrary applications (and their configuration files) to specify addresses with these indicies - such applications should just use names and let getaddrinfo() take care of the indicies. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 10:50:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id KAA10644 for ipng-dist; Mon, 6 Apr 1998 10:44:00 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id KAA10637 for ; Mon, 6 Apr 1998 10:43:44 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id KAA08883; Mon, 6 Apr 1998 10:43:41 -0700 (PDT) Date: Mon, 6 Apr 1998 10:41:21 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5557) Re: Basic Sockets API To: Christian Huitema Cc: bound@zk3.dec.com, Steve Deering , Tim Hartrick , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <980406095107.ZM18324@seawind.bellcore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think that Jim is right on the mark. Using scoped addresses in > application is *not* a good idea. We have two choices here, not just one: > > 1) update the interface format to include link and site specification in > addresses. > > 2) not update it, and make it real hard to use scoped addresses in > applications. > > I would personally go for option 2. Option 1, if abuse, will lead to > stupidities like specifying a link for a fully defined address, and then > see the connection break when the routing changes. I agree that we don't want applications to set the interface and site indicies at random. Instead we want to hide this in the implementation. We can not do this when the application uses getnodebyname() (since that routine returns just the 128 bit IPv6 address) but we can hide this information when the application uses getaddrinfo(). I think only special applications (like "debugging" applications akin to traceroute and ping, and routing protocols) have the need to explicitly set the interface and/or site index. But if we don't introduce these new fields in the sockaddr_in6 structure (and require the applications to initialize them to zero) it will be a lot harder to make regular applications work transparently on mutihomed and "multisited" nodes in the future. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 11:17:56 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id LAA10801 for ipng-dist; Mon, 6 Apr 1998 11:12:45 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id LAA10794 for ; Mon, 6 Apr 1998 11:12:32 -0700 (PDT) Received: from lillen (lillen [129.146.86.161]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id LAA14536; Mon, 6 Apr 1998 11:12:26 -0700 (PDT) Date: Mon, 6 Apr 1998 11:12:24 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5558) Comments on draft-ietf-ipngwg-bsd-api-new-01.txt To: gilligan@freegate.net, set@thumper.bellcore.com, bound@zk3.dec.com, rstevens@kohala.com Cc: ipng@sunroof.eng.sun.com, nordmark@jurassic.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The addition of the sockaddr_union in section 3.10 will make porting easier. However, I don't see how this structure can be defined in sys/socket.h since the sockaddr_* structures are defined in other header files like netinet/in.h. Have you verified that X/Open name space rules allows sys/socket.h to include netinet/in.h, sys/un.h etc? I have some problems with the addition of the SA_LEN macro. Namely: 1. For implementations which include sa_len the macro would assume that sa_len is indeed initialized. This seems to be rare in applications for 4.4BSD. 2. For implementations without sa_len there are similar constraints: For AF_UNIX I can implement SA_LEN using strlen but only as long as the sockaddr_un has been initialized. 3. Also, for implementations without sa_len I don't see how I can easily handle 3rd party software which adds new sockaddr_* structures and the corresponding address families. Thus I can implement it for AF_INET, AF_INET6, AF_LINK but not for AF_ATM, AF_X25 etc. Since I can't understand how the introduction of SA_LEN makes it easier for the application programmer to port to IPv6 I seriously question adding this to the API. As previously discussed on the mailing list we should add default values for the IPV6_MULTICAST_ options. If it turns out that the default for IPV6_MULTICAST_HOPS will be the same as the default for IPV6_UNICAST_HOPS (Steve Deering didn't see a problem with this) then I would strongly suggest that we merge the 3 hop limit options into a single one (presumably named IPV6_HOPLIMIT). The description for getnodebyname() on page 22 says that the flags are ignored when parsing literal addresses. I think this is incorrect. When an application doesn't set AI_V4MAPPED it should not have getnodbyname return a mapped address just because the string contained a literal IPv4 address (a dotted-decimal). I think that getaddrinfo should be specified to support the new flags AI_ALL and AI_ADDRCONFIG since those apply to getnodebyname() and - we want getaddrinfo and getnodebyname to have the same capabilities, and - the specification already adds a flag (AI_NUMERICHOST) in addition to the flags specified in Posix 1003.1g Note that there is no need to add AI_V4MAPPED since getaddrinfo() can return addresses with different address families - applications set ai_family to AF_UNSPEC to retrieve addresses from any family. Editorial: Both in section 1 and 2.1 the draft has "priority" which should presumably be replaced with traffic class. The comments for sin6_flowinfo in section 3.3 and 3.4 are different. Presumably they could be the same. The text in section 3.10 uses "receive buffer" and "received" to describe the address retrieval for e.g. getpeername. Wouldn't "output buffer" and "retrieve" be better choice words? How about putting freehostent() in a separate subsection (it is in the getnodybyname section but it also applies to getnodebyaddr)? Also, it would make sense to state clearly next to the freehostent definition that it applies only to the hostent structures returned by getnodebyaddr and getnodybyname. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 11:47:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id LAA10908 for ipng-dist; Mon, 6 Apr 1998 11:41:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id LAA10879 for ; Mon, 6 Apr 1998 11:41:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA02000 for ; Mon, 6 Apr 1998 11:40:57 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA01883 for ; Mon, 6 Apr 1998 11:40:04 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA17780; Mon, 6 Apr 98 11:36:10 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA09360; Mon, 6 Apr 1998 11:40:54 -0700 Date: Mon, 6 Apr 1998 11:40:54 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804061840.LAA09360@feller.mentat.com> To: huitema@bellcore.com Subject: (IPng 5559) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > > I think that Jim is right on the mark. Using scoped addresses in > application is *not* a good idea. We have two choices here, not just one: > > 1) update the interface format to include link and site specification in > addresses. > > 2) not update it, and make it real hard to use scoped addresses in > applications. > So how does the canonical dentist's office example work if we can't use link-local addresses in applications? The dentist's office has a single subnet and has no router to advertise prefix information and no DHCP server to issue leases to addresses. Are you suggesting that the dentist office fall back on manual configuration of addresses? Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 12:12:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA11023 for ipng-dist; Mon, 6 Apr 1998 12:06:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id MAA11016 for ; Mon, 6 Apr 1998 12:06:30 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA26824; Mon, 6 Apr 1998 12:06:25 -0700 (PDT) Date: Mon, 6 Apr 1998 12:04:05 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5560) Overhaul of advanced API? To: rstevens@kohala.com, matt.thomas@altavista-software.com Cc: nordmark@jurassic.eng.sun.com, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here are some suggestions for simplifying the advanced API for both the users of the API and the implementors based on my attemtps at implementing the API. Let me know if you'd like help editing the draft. Some of these ideas for improvements were suggested by Tim Hartrick. Split the socket options into separate IPV6_RECVXXX options (which are used to enable the receipt of ancillary data) and the IPV6_XXX options (which are used in the ancillary data for transmit and receipt). This makes it more clear that the enabling of receipt is really separate (with a boolean value) than the extension header carrying options. Allow applications to specify IPV6_XXX (e.g. IPV6_RTHDR) directly for setsockopt to set sticky options. This simplies applications since they don't have to construct the cmsghdr and use IPV6_PKTOPTIONS. I suspect that most applications which will send ancillary data (even on UDP) will find it easier to use sticky options thus getting this part as simple as possible would be very good. We could even go so far as removing IPV6_PKTOPTIONS - What do other implementors think? Remove the generality of being able to specify multiple instances of IPV6_HOPOPTS and IPV6_DSTOPTS in ancillary data (and in IPV6_PKTOPTIONS if we decide to keep it). Requiring the kernel to merge these options together adds unneeded complexity - the inet6_option_xxx routing should do the 'merging'. This implies having a separate IPV6_DSTOPTS options that go before and after the routing header (when a routing header is in use). Update the draft to remove any references to "priority", the strict/loose source route, and that the source route can have only 23 elements. Include dst/hop option definitions for PAD1, PADN etc in section 2.1.2. Clarify what in section 4 are changes from Posix and X/Open specifications for ancillary data. (Perhaps the material which is not different from those specifications could be moved to an appendix so that the new aspects of the API would be much more clear.) We need to decide what it means to receive ancillary data on tcp and specify that in enough detail to allow portable applications. Questions to answer: - Is the received ancillary data synchronized with the data stream i.e. if the set of extension headers changes during a TCP connection will the application be able to tell what data was received with which extension headers? - Should the ancillary data be included for every recvmsg on TCP or only for the first one on the connection and when the content changes? The routines in section 6.3 seem very complex to use since the application has to determine the offset (e.g. IP6_Y_OPT_OFFSET) in order to declare the required structure. Wouldn't it be easier to define a different form of serialization API where the application would declare: - the total length of the option content - the alignment requirement for the largest component in the option Using this the library can determine how much padding is needed between the end of the previous option and the beginning of the new option. Then the application could lay in the different field members using procedures like inet6_option_add_value8(..., uint8_t value); inet6_option_add_value16(..., uint16_t value); inet6_option_add_value32(..., uint32_t value); inet6_option_add_value64(..., uint64_t value); That way the application doesn't need to define a structure (and worry about padding by the compiler) and the inet6_option_ routines can minimize the amount of internal padding relieving the kernel from any such work. For section 12.2 add the new options IPV6_RECVPMTU (to enable receipt of IPV6_PMTU as ancillary data) IPV6_PMTU (containing a uint32_t with the changed path MTU and the sockaddr_in6 specifying the destination which has that mtu) The IPV6_PMTU option can be passed up to recvmsg without any accompanying data - this is needed to map an ICMPv6 packet too big when no data is available. Applications can do a getsockopt on IPV6_PMTU (specifying the sockaddr_in6) to retrieve the currently known path MTU for that destination. For section 12.3 add the new option: IPV6_REACH_CONF which takes a uint32_t which when non-zero indicates that the destination address is reachable. This option can be used with setsockopt for connected sockets and with sendmsg ancillary data for unconnected sockets. Thus the option need not contain the IPv6 address that is reachable. The various inet6_{option,rthdr} routines are specified to belong in . This seems inconsistent with existing practise where inet_*() routines are defined in . If there is a good reason for this difference it would be good to state it in the document. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 12:14:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA11048 for ipng-dist; Mon, 6 Apr 1998 12:10:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA11041 for ; Mon, 6 Apr 1998 12:10:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA09222 for ; Mon, 6 Apr 1998 12:10:43 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id MAA18983 for ; Mon, 6 Apr 1998 12:10:45 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA18313; Mon, 6 Apr 98 12:06:05 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA09406; Mon, 6 Apr 1998 12:10:49 -0700 Date: Mon, 6 Apr 1998 12:10:49 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804061910.MAA09406@feller.mentat.com> To: Kazu@Mew.org Subject: (IPng 5561) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kazu, > > From: Steve Deering > Subject: (IPng 5539) Re: Basic Sockets API > Date: Fri, 3 Apr 1998 17:00:47 -0800 > > > Tim's proposal sounds like the right thing to me. Perhaps the "ifindex" > > really ought to be a "linkindex", since a node may actually have more > > than one interface on the same link. I presume there would be a reserved > > value (zero? all ones?) to use in either the siteindex or ifindex/linkindex > > field to indicate "unspecified"? > > Tim's proposal is exactly the same what WIDE Project proposed in the > scope draft one year and half ago. Unfortunately, nobody supported our > proposal then it was rejected. > > We should not repeat the same discussion again. > What I remember about the WIDE scope draft was that it placed unnecessary restrictions on the mixing of various scoped addresses in the source and destination address fields of IPv6 datagrams. That feature is what I rejected about the proposal. I didn't recall that you proposed that the sockaddr_in6 change. You were ahead of your time. Further, I was not operating under the illusion that what I was proposing was unique. I knew it was not since others, including you apparently, had proposed it before. Saying that we discussed this before and didn't choose to act on those discussions so we should not act on them now either, is not a technical counter argument against making the change. It is argument born of frustration with a tedious process. I feel your pain. Unfortunately, if we don't do something the problem of scoped addresses will persist. It needs to be solved no matter how late the solution is in coming. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 13:26:45 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id NAA11451 for ipng-dist; Mon, 6 Apr 1998 13:18:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id NAA11443 for ; Mon, 6 Apr 1998 13:18:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA24647 for ; Mon, 6 Apr 1998 13:18:46 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA04411 for ; Mon, 6 Apr 1998 13:12:23 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id QAA01931; Mon, 6 Apr 1998 16:11:56 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id QAA18479; Mon, 6 Apr 1998 16:11:56 -0400 (EDT) Date: Mon, 6 Apr 1998 16:11:56 -0400 (EDT) From: Christian Huitema Message-Id: <980406161155.ZM18477@seawind.bellcore.com> In-Reply-To: thartric@mentat.com (Tim Hartrick) "(IPng 5559) Re: Basic Sockets API" (Apr 6, 11:40am) References: <199804061840.LAA09360@feller.mentat.com> X-Mailer: Z-Mail (5.0.0 30July97) To: thartric@mentat.com (Tim Hartrick), huitema@bellcore.com Subject: (IPng 5562) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, I don't think that the dentist's office should use manual address configuration. On the other hand, it also cannot use DNS addresses (or can it?). The solution implemented in the Wide kernel looks like the most in line with the philosophy. Use some reserved bits in the link local and site local addresses to encode where the packet is coming from (which link, which site). This is consistent with the IPv4 address prefix encoding. It also enables responders in the dentist office and elsewhere to simply send their replies to the address from which the packet arrived without ever manipulating the link or site identifications. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 13:59:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id NAA11526 for ipng-dist; Mon, 6 Apr 1998 13:51:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id NAA11519 for ; Mon, 6 Apr 1998 13:51:28 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA05639; Mon, 6 Apr 1998 13:51:16 -0700 Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA25153; Mon, 6 Apr 1998 13:51:11 -0700 (PDT) Received: from netmail2.austin.ibm.com (netmail2.austin.ibm.com [9.53.250.97]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id PAA46564; Mon, 6 Apr 1998 15:51:09 -0500 Received: from taklimakan.austin.ibm.com (taklimakan.austin.ibm.com [9.53.150.247]) by netmail2.austin.ibm.com (8.8.5/8.8.5) with ESMTP id PAA56144; Mon, 6 Apr 1998 15:51:07 -0500 Received: (from marquard@localhost) by taklimakan.austin.ibm.com (AIX4.3/UCB 8.8.8/8.7-client1.01) id PAA33286; Mon, 6 Apr 1998 15:51:06 -0500 To: Erik Nordmark Cc: gilligan@freegate.net, set@thumper.bellcore.com, bound@zk3.dec.com, rstevens@kohala.com, ipng@sunroof.eng.sun.com Subject: (IPng 5563) Re: Comments on draft-ietf-ipngwg-bsd-api-new-01.txt References: From: Dave Marquardt Date: 06 Apr 1998 15:51:05 -0500 In-Reply-To: Erik Nordmark's message of "Mon, 6 Apr 1998 11:12:24 -0700 (PDT)" Message-ID: Lines: 12 X-Mailer: Gnus v5.6.2/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > The addition of the sockaddr_union in section 3.10 will > make porting easier. However, I don't see how this structure can > be defined in sys/socket.h since the sockaddr_* structures are > defined in other header files like netinet/in.h. > Have you verified that X/Open name space rules allows sys/socket.h to > include netinet/in.h, sys/un.h etc? You can include these things from sys/socket.h, as long as you don't pollute the name space. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 14:15:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id OAA11586 for ipng-dist; Mon, 6 Apr 1998 14:05:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id OAA11578 for ; Mon, 6 Apr 1998 14:05:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA11040 for ; Mon, 6 Apr 1998 14:05:34 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA05656 for ; Mon, 6 Apr 1998 14:05:12 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA20116; Mon, 6 Apr 98 14:01:54 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA09508; Mon, 6 Apr 1998 14:06:38 -0700 Date: Mon, 6 Apr 1998 14:06:38 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804062106.OAA09508@feller.mentat.com> To: huitema@bellcore.com Subject: (IPng 5564) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > > I don't think that the dentist's office should use manual address > configuration. On the other hand, it also cannot use DNS addresses > (or can it?). > I have always had doubts about the canonical dentist's office scenario but it has always been trotted out as an example of why scoped addresses were of value. I don't have clear idea how name resolution should work in that scenario. It will probably only work with ICMPv6 "who are you" queries. > The solution implemented in the Wide kernel looks like the most > in line with the philosophy. Use some reserved bits in the link > local and site local addresses to encode where the packet is > coming from (which link, which site). > But the current specifications prohibit the special link-local encoding from being passed to applications. That means they still need additional ancillary data to be passed around within applications to disambiguate their peer. There are a lot of IPv4 applications out there into which it will be very difficult to integerate this extra ancillary data cookie which needs to be passed around with every address. I know that I don't want to have to tell my customers that this extra blob of ancillary data is the best available solution and they should just live with it. Further I believe that WIDE has only solved the link-local problem with their internal encoding scheme. I don't believe they have a solution for the multi-sited problem either in the kernel or in user space. I am sure they will tell me if my understanding is incorrect. Don't get me wrong. I was in favor of encoding site and interface ID's in the addresses. I and others lost that argument a long time ago. Since we have lost that argument we now need some API construct that really works to handle address scoping. #ifdef RANTING /* Pardon the cliched use of preprocessor conditionals */ Do I sound frustrated. I am. We have been chasing our tails on this issue for many, many moons. I had at least the link-local portion of this problem solved in our implementation in a very similar fashion to the way the WIDE group has solved the problem. Then the WG said no you can't use those 54 bits between the well known prefix and the token, you need to use interface indices. Great, so now we have the specter of multi-sited nodes to deal with and absolutely no mechanism to handle the ambiguity associated with the site-local addresses. I keep hearing that scoped addresses are useful but when the detailed questions are posed as to how these things can actually be used by applications on multi-homed, multi-sited hosts I get the ever popular "Oh, well that is just an implementation issue". We need to define how to make these things useful to applications or they need to be shot in the head. #endif /* RANTING */ Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 14:19:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id OAA11607 for ipng-dist; Mon, 6 Apr 1998 14:11:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id OAA11600 for ; Mon, 6 Apr 1998 14:11:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA13232 for ; Mon, 6 Apr 1998 14:11:05 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA04411 for ; Mon, 6 Apr 1998 13:12:23 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id QAA01931; Mon, 6 Apr 1998 16:11:56 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id QAA18479; Mon, 6 Apr 1998 16:11:56 -0400 (EDT) Date: Mon, 6 Apr 1998 16:11:56 -0400 (EDT) From: Christian Huitema Message-Id: <980406161155.ZM18477@seawind.bellcore.com> In-Reply-To: thartric@mentat.com (Tim Hartrick) "(IPng 5559) Re: Basic Sockets API" (Apr 6, 11:40am) References: <199804061840.LAA09360@feller.mentat.com> X-Mailer: Z-Mail (5.0.0 30July97) To: thartric@mentat.com (Tim Hartrick), huitema@bellcore.com Subject: (IPng 5565) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, I don't think that the dentist's office should use manual address configuration. On the other hand, it also cannot use DNS addresses (or can it?). The solution implemented in the Wide kernel looks like the most in line with the philosophy. Use some reserved bits in the link local and site local addresses to encode where the packet is coming from (which link, which site). This is consistent with the IPv4 address prefix encoding. It also enables responders in the dentist office and elsewhere to simply send their replies to the address from which the packet arrived without ever manipulating the link or site identifications. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 15:02:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id OAA11798 for ipng-dist; Mon, 6 Apr 1998 14:52:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id OAA11791 for ; Mon, 6 Apr 1998 14:51:48 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA27897 for ; Mon, 6 Apr 1998 14:51:44 -0700 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA06688 for ; Mon, 6 Apr 1998 14:51:44 -0700 (PDT) From: Margaret Wasserman To: thartric@mentat.com CC: huitema@bellcore.com, ipng@sunroof.eng.sun.com In-reply-to: <199804062106.OAA09508@feller.mentat.com> (message from Tim Hartrick on Mon, 6 Apr 1998 14:06:38 -0700) Subject: (IPng 5566) Re: Basic Sockets API Date: Mon, 6 Apr 98 17:51:31 -0400 Message-ID: <9804061751.aa11758@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The solution implemented in the Wide kernel looks like the most > in line with the philosophy. Use some reserved bits in the link > local and site local addresses to encode where the packet is > coming from (which link, which site). Are you suggesting that these values (placed in the reserved bits of the link-local address) be passed end-to-end? Or only used within the local host and zero'ed on transmit. Passing them end-to-end would seem to have several problems, since the two hosts might not use the same identification values for their shared link or site. Would a host change these to the local representation upon receipt? Setting to zero on transmit would seem to imply setting them to zero before passing this information to the upper layer (TCP, UDP, etc.). Otherwise, there would be an incomplete correspondence between the upper layer datastructures (TCP connection list, etc.), the data sent on the wire, and the corresponding datastructures on the remote host. Also, upper layer checksums will not work if the IP addresses are not maintained end-to-end. I suppose it would be possible to treat these bits as zero during the checksum calculation, but actually pass a non-zero value to/from the upper layers. This would complicate the checksum calculation, and I don't understand what the advantages would be over storing this information separately from the address. I'd personally prefer setting/storing this information outside the addresses (presumably in a datastructure that contains information regarding the ongoing "conversation") to avoid: - Complicating the checksum calculation - Making it more difficult to identify corresponding "conversations" on two hosts and match these to packets on the wire. I don't know enough about sockets to have an opinion regarding whether the socket structure is the "right" place for this information, but I believe that the reserved portion of the link-local and site-local addresses is not the right place. What method is used for specifying this information on application command lines (and whether or not a given application allows it to be specified) should remain implemenation- and application-specific in my opinion. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 15:02:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id OAA11820 for ipng-dist; Mon, 6 Apr 1998 14:55:00 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id OAA11813 for ; Mon, 6 Apr 1998 14:54:53 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id OAA19454 for ; Mon, 6 Apr 1998 14:54:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id OAA08261 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 14:54:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id OAA11801 for ; Mon, 6 Apr 1998 14:53:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA28489 for ; Mon, 6 Apr 1998 14:53:33 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA07670 for ; Mon, 6 Apr 1998 14:53:33 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id GAA09279; Tue, 7 Apr 1998 06:53:13 +0900 (JST) To: thartric@mentat.com (Tim Hartrick) cc: ipng@sunroof.eng.sun.com In-reply-to: thartric's message of Fri, 03 Apr 1998 12:01:21 PST. <199804032001.MAA07690@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5568) Re: Basic Sockets API From: Jun-ichiro itojun Itoh Date: Tue, 07 Apr 1998 06:53:13 +0900 Message-ID: <9275.891899593@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry if I missed any of discussion emails, ipngwg mail reaches to me with big delay and they are out-of-order. One more comment on the structure: >struct sockaddr_in6 { > uint8_t sin6_len; > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_flowinfo; > uint32_t sin6_siteindex; > uint32_t sin6_ifindex; > struct in6_addr sin6_addr; >}; After attending the scope-rule discussion at LA, I believe that the site-index and if-index cannot be orthogonal. I think the agreement at IETF is "site is defined by a set of link". In that case, in the following configuation userland code cannot just say "site A and ifindex 2, please". interface ifindex site --- --- --- lo0 1 none ef0 2 B ef1 3 B ppp0 4 A Having separate field for siteindex and ifindex will raise the following questions: - how to relate ifindex and siteindex? (model issue) - how to manage siteindex? - how to bark if they contradicts? My proposal is to: 1. Remove sin6_siteindex 2. Use sin6_ifindex for both siteindex and ifindex. Ambiguity is resolved by either of the following: 2-a. Encode siteindex by raising a bit, say, 0x80000000. 2-b. The number will be interpreted based on the scope of sin6_addr. In this way we will never have to see ifindex-siteindex mismatch. Note: I am very happy with the addition of sin6_ifindex in the userland API. I believe that WIDE scheme (put ifindex into s6_addr8[3]) is only to be used in the kernel, not in userland API. Currently our implementation does not have code to manage site-local addresses, but we believe we can manage site-scoped addresses by our encoding scheme too. We can just put siteindex into s6_addr8[3], again IN THE KERNEL ONLY. s6_addr8[3] will be: - ifindex if address is link-local (fe80:: or ff02::) - siteindex if address is site-local (fec0:: or ff05::) (correct me if I'm wrong >kazu) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 15:34:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id PAA11937 for ipng-dist; Mon, 6 Apr 1998 15:27:36 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id PAA11930 for ; Mon, 6 Apr 1998 15:27:26 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id PAA02402 for ; Mon, 6 Apr 1998 15:27:12 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id PAA08291 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 15:27:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id PAA11891 for ; Mon, 6 Apr 1998 15:17:47 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA05538 for ; Mon, 6 Apr 1998 15:17:44 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA22852 for ; Mon, 6 Apr 1998 15:17:44 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id HAA09589; Tue, 7 Apr 1998 07:17:09 +0900 (JST) To: Margaret Wasserman cc: thartric@mentat.com, huitema@bellcore.com, ipng@sunroof.eng.sun.com In-reply-to: mrf's message of Mon, 06 Apr 1998 17:51:31 -0400. <9804061751.aa11758@khitomer.epilogue.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5570) Re: Basic Sockets API From: Jun-ichiro itojun Itoh Date: Tue, 07 Apr 1998 07:17:09 +0900 Message-ID: <9585.891901029@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The solution implemented in the Wide kernel looks like the most >> in line with the philosophy. Use some reserved bits in the link >> local and site local addresses to encode where the packet is >> coming from (which link, which site). >Are you suggesting that these values (placed in the reserved bits >of the link-local address) be passed end-to-end? Or only used >within the local host and zero'ed on transmit. Just to clarify for our method: We use s6_addr8[3] just for internal address management of the kernel. they will NEVER appear on the wire. ifindex and siteindex are local to each host; passing them to other host has no meaning at all. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 15:49:29 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id PAA11998 for ipng-dist; Mon, 6 Apr 1998 15:41:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id PAA11991 for ; Mon, 6 Apr 1998 15:41:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA11286 for ; Mon, 6 Apr 1998 15:41:24 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id PAA06114 for ; Mon, 6 Apr 1998 15:41:24 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA21542; Mon, 6 Apr 98 15:38:00 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA09540; Mon, 6 Apr 1998 15:42:44 -0700 Date: Mon, 6 Apr 1998 15:42:44 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804062242.PAA09540@feller.mentat.com> To: itojun@itojun.org Subject: (IPng 5572) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, > > After attending the scope-rule discussion at LA, I believe > that the site-index and if-index cannot be orthogonal. > I think the agreement at IETF is "site is defined by a set of link". > In that case, in the following configuation userland code > cannot just say "site A and ifindex 2, please". > interface ifindex site > --- --- --- > lo0 1 none > ef0 2 B > ef1 3 B > ppp0 4 A > Having separate field for siteindex and ifindex will raise the > following questions: > - how to relate ifindex and siteindex? (model issue) > - how to manage siteindex? > - how to bark if they contradicts? > > My proposal is to: > 1. Remove sin6_siteindex > 2. Use sin6_ifindex for both siteindex and ifindex. > Ambiguity is resolved by either of the following: > 2-a. Encode siteindex by raising a bit, say, 0x80000000. > 2-b. The number will be interpreted based on the scope of sin6_addr. > In this way we will never have to see ifindex-siteindex mismatch. > I understand your concern with potential conflicts between the sin6_ifindex and the sin6_siteindex. There are some nasty error conditions to be evaluated if both indices are present. You are correct that we could have a single integer which was a generic scope value associated with the sin6_addr. If the sin6_addr contained a link-local address then implicitly the scope value would be interpreted an an interface index. If the sin6_addr contained a site-local address then the scope value would be interpreted as a site index. This is similar to Steve Deering's counter proposal to my original proposal. The only reason I chose to propose that the sockaddr_in6 carry both an interface index and a site index was because I had hopes that we could eliminate entirely the need for the interface index field of the in6_pktinfo structure from the advanced API. By having both the interface index and the site index in the sockaddr_in6 we no longer need the IPV6_PKTINFO option to specify the outgoing interface and we no longer need to receive the IPV6_PKTINFO structure to determine the incoming interface. The information will be available in the sockaddr_in6 all the time. I should have made this desire more clear. > We can just put siteindex into s6_addr8[3], again IN THE KERNEL ONLY. > s6_addr8[3] will be: > - ifindex if address is link-local (fe80:: or ff02::) > - siteindex if address is site-local (fec0:: or ff05::) > (correct me if I'm wrong >kazu) > I don't think this will work. Site-local prefixes can be advertised by routers with prefixes between 10 and 64 bits in length. It is quite possible that you will not have any spare bits in your site-local addresses in which to encode the site index. If I am incorrect about this then site local addresses are truly worthless because they cannot be "subnetted". They would be equivalent to link-local addresses. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 16:10:42 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id QAA12140 for ipng-dist; Mon, 6 Apr 1998 16:04:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA12133 for ; Mon, 6 Apr 1998 16:04:12 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id QAA18912; Mon, 6 Apr 1998 16:04:09 -0700 (PDT) Date: Mon, 6 Apr 1998 16:01:49 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5574) Re: Basic Sockets API To: Jun-ichiro itojun Itoh Cc: Margaret Wasserman , thartric@mentat.com, huitema@bellcore.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9585.891901029@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Just to clarify for our method: > We use s6_addr8[3] just for internal address management of the kernel. > they will NEVER appear on the wire. > ifindex and siteindex are local to each host; passing them to other > host has no meaning at all. Does this mean that your ftp application knows to zero out these bits to avoid including them in the PORT/LPRT command? If the ifindex/siteindex are contained in s6_addr8 they are more likely to be accidentally sent to the peer by unknowing application protocols. Storing these indicies in new fields in the sockaddr_in6 removes that risk. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 17:03:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id QAA12621 for ipng-dist; Mon, 6 Apr 1998 16:57:44 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA12614 for ; Mon, 6 Apr 1998 16:57:37 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA27484 for ; Mon, 6 Apr 1998 16:57:35 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id QAA08438 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 16:57:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id QAA12103 for ; Mon, 6 Apr 1998 16:00:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA16103 for ; Mon, 6 Apr 1998 16:00:16 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA16551 for ; Mon, 6 Apr 1998 16:00:17 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id IAA10040; Tue, 7 Apr 1998 08:00:09 +0900 (JST) To: thartric@mentat.com (Tim Hartrick) cc: ipng@sunroof.eng.sun.com In-reply-to: thartric's message of Mon, 06 Apr 1998 15:42:44 MST. <199804062242.PAA09540@feller.mentat.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5578) Re: Basic Sockets API From: Jun-ichiro itojun Itoh Date: Tue, 07 Apr 1998 08:00:09 +0900 Message-ID: <10036.891903609@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> We can just put siteindex into s6_addr8[3], again IN THE KERNEL ONLY. >> s6_addr8[3] will be: >> - ifindex if address is link-local (fe80:: or ff02::) >> - siteindex if address is site-local (fec0:: or ff05::) >> (correct me if I'm wrong >kazu) >I don't think this will work. Site-local prefixes can be advertised by >routers with prefixes between 10 and 64 bits in length. It is quite possible >that you will not have any spare bits in your site-local addresses in which >to encode the site index. If I am incorrect about this then site local >addresses are truly worthless because they cannot be "subnetted". They would >be equivalent to link-local addresses. we have the room. anyway, this is just how we implement our current code (yes, it is a hack); if we can't do this, we will implement this in other ways. itojun --- addr-arch-v2-06 Site-Local addresses have the following format: | 10 | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+----------------------------+ |1111111011| 0 | subnet ID | interface ID | +----------+-------------+-----------+----------------------------+ Site-Local addresses are designed to be used for addressing inside of a site without the need for a global prefix. Routers must not forward any packets with site-local source or destination addresses outside of the site. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 17:03:42 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id QAA12591 for ipng-dist; Mon, 6 Apr 1998 16:56:11 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA12584 for ; Mon, 6 Apr 1998 16:56:06 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA27226 for ; Mon, 6 Apr 1998 16:56:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id QAA08407 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 16:55:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id PAA11979 for ; Mon, 6 Apr 1998 15:41:12 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA11216 for ; Mon, 6 Apr 1998 15:41:09 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA05995 for ; Mon, 6 Apr 1998 15:41:10 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id HAA06624; Tue, 7 Apr 1998 07:41:09 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (3.2) id xma006621; Tue, 7 Apr 98 07:41:09 +0900 Received: from localhost (localhost.aist-nara.ac.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id HAA05023 for ; Tue, 7 Apr 1998 07:54:02 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 5577) Re: Basic Sockets API From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: Your message of "Tue, 07 Apr 1998 06:53:13 +0900" <9275.891899593@coconut.itojun.org> References: <9275.891899593@coconut.itojun.org> X-Mailer: Mew version 1.93b26 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980407075402P.kazu@Mew.org> Date: Tue, 07 Apr 1998 07:54:02 +0900 X-Dispatcher: imput version 980302 Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Jun-ichiro itojun Itoh Subject: (IPng 5568) Re: Basic Sockets API Date: Tue, 07 Apr 1998 06:53:13 +0900 > My proposal is to: > 1. Remove sin6_siteindex > 2. Use sin6_ifindex for both siteindex and ifindex. > Ambiguity is resolved by either of the following: I think you are right. > Itojun If ifindex is to be included in sockaddr_in6, it's enough. Siteindex is not necessary. An logical network interface must belong to exactly one link and one site. I also agree with Tim. Though 2 bytes are enough, ifindex should be 4 bytes for word alignment. However, I'm in neutral position in whether or not ifindex should be added. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 17:04:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id QAA12647 for ipng-dist; Mon, 6 Apr 1998 16:59:08 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA12640 for ; Mon, 6 Apr 1998 16:58:58 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA27699 for ; Mon, 6 Apr 1998 16:58:58 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id QAA08469 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 16:58:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id QAA12213 for ; Mon, 6 Apr 1998 16:11:11 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA18850 for ; Mon, 6 Apr 1998 16:11:09 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA22656 for ; Mon, 6 Apr 1998 16:11:09 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id IAA08707; Tue, 7 Apr 1998 08:11:09 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (3.2) id xma008699; Tue, 7 Apr 98 08:10:57 +0900 Received: from localhost (localhost.aist-nara.ac.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id IAA05064 for ; Tue, 7 Apr 1998 08:23:49 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 5579) Re: Basic Sockets API From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: Your message of "Mon, 6 Apr 1998 12:10:49 -0700" <199804061910.MAA09406@feller.mentat.com> References: <199804061910.MAA09406@feller.mentat.com> X-Mailer: Mew version 1.93b26 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980407082348K.kazu@Mew.org> Date: Tue, 07 Apr 1998 08:23:48 +0900 X-Dispatcher: imput version 980302 Lines: 42 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: thartric@mentat.com (Tim Hartrick) Subject: Re: (IPng 5554) Re: Basic Sockets API Date: Mon, 6 Apr 1998 12:10:49 -0700 > What I remember about the WIDE scope draft was that it placed unnecessary > restrictions on the mixing of various scoped addresses in the source and > destination address fields of IPv6 datagrams. That is one part of our old proposal. Sorry but I'm not comfortable with your word, "unnecessary restrictions". Scope rule is one of core features of our implementation. It has been tested well in many places in our 6bone for a year and half, and is proofed that it's a good idea I believe. > I didn't recall that you proposed that the sockaddr_in6 change. You were > ahead of your time. Further, I was not operating under the illusion that > what I was proposing was unique. I knew it was not since others, including > you apparently, had proposed it before. Let me summarize what happened in ipng ml. We proposed to include ifindex to sockaddr_in6 as well as scope rule. At that time, the advanced API was coming. Changing the basic structure seemed evil to many people. We also proposed to embed ifindex to link-local and site-local addresses instead of the modification of sockaddr_in6. Many people said that our proposal was an ugly way. All in all, many people believed that ancillary data was enough and clean. (I wonder that how many peoble had enough experiences to make IPv4 application to be bilingual at that time.) My current frustration to the adv API is how to use ancillary data for TCP. In other words, how can I specify an interface for a TCP socket with good-old read() and write() system calls? I also proposed the IPV6_UNICAST_IF socket option to solve this problem, though, it was not accepted, neither. I know if ifindex exists in sockaddr_in6, this is resolved straightforward. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 17:07:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id RAA12670 for ipng-dist; Mon, 6 Apr 1998 17:01:04 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id RAA12660 for ; Mon, 6 Apr 1998 17:00:42 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id RAA27893 for ; Mon, 6 Apr 1998 17:00:43 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id RAA08498 for ipng@sunroof.eng.sun.com; Mon, 6 Apr 1998 17:00:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id QAA12359 for ; Mon, 6 Apr 1998 16:29:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA24351; Mon, 6 Apr 1998 16:29:49 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA02861; Mon, 6 Apr 1998 16:29:48 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W/smtpfeed 0.59) with ESMTP id IAA10350; Tue, 7 Apr 1998 08:29:45 +0900 (JST) To: Erik Nordmark cc: Margaret Wasserman , thartric@mentat.com, huitema@bellcore.com, ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Mon, 06 Apr 1998 16:01:49 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5580) Re: Basic Sockets API From: Jun-ichiro itojun Itoh Date: Tue, 07 Apr 1998 08:29:45 +0900 Message-ID: <10346.891905385@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Just to clarify for our method: >> We use s6_addr8[3] just for internal address management of the kernel. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> they will NEVER appear on the wire. >> ifindex and siteindex are local to each host; passing them to other >> host has no meaning at all. >Does this mean that your ftp application knows to zero out these bits to >avoid including them in the PORT/LPRT command? Our implementation use current advanced api spec for communication between kernel and userland program. (therefore, applications that use link-local address will have to use sendmsg()) Application will always see address with s6_addr8[3] == 0. s6_addr8[3] is used only in the kernel. (see underlined part) Again, I'm not against of sin6_ifindex proposal. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 17:22:01 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id RAA12744 for ipng-dist; Mon, 6 Apr 1998 17:12:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id RAA12737 for ; Mon, 6 Apr 1998 17:12:05 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA06980 for ; Mon, 6 Apr 1998 17:12:03 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id RAA27068 for ; Mon, 6 Apr 1998 17:12:05 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id UAA19613; Mon, 6 Apr 1998 20:12:04 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA21461; Mon, 6 Apr 1998 20:08:48 -0400 Message-Id: <9804070008.AA21461@quarry.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: huitema@bellcore.com, ipng@sunroof.eng.sun.com Subject: (IPng 5581) Re: Basic Sockets API In-Reply-To: Your message of "Mon, 06 Apr 98 14:06:38 PDT." <199804062106.OAA09508@feller.mentat.com> Date: Mon, 06 Apr 98 20:08:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I keep hearing that scoped addresses are useful but when the detailed >questions are posed as to how these things can actually be used by applications >on multi-homed, multi-sited hosts I get the ever popular "Oh, well that is >just an implementation issue". > >We need to define how to make these things useful to applications or they need >to be shot in the head. Amen Brother.... I ranted on this one for a week before the IETF....and why I am uncomfortable putting this in just yet. My co-authors are baffled too. We will do what consensus calls for but it is totally unclear what any of this is going to be used for and putting something that we don't know what it is going to be used for and how in the cornerstone API for IPv6 deployment is very dangerous. People could really hurt themselves. But it appears in this group we have a folkway that it is ok to define things which are not well-thought-out or have a use that can be clearly articulated in the area of address scoping and duplication. We have not acted this way anywhere else for IPv6 and I am not comfortable how we are acting on this "particular" issue and subject manner. /jim /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 17:54:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id RAA12989 for ipng-dist; Mon, 6 Apr 1998 17:46:33 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id RAA12982 for ; Mon, 6 Apr 1998 17:46:22 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA14930 for ; Mon, 6 Apr 1998 17:46:20 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id RAA13399 for ; Mon, 6 Apr 1998 17:46:22 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA23448; Mon, 6 Apr 98 17:43:07 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA09590; Mon, 6 Apr 1998 17:47:52 -0700 Date: Mon, 6 Apr 1998 17:47:52 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804070047.RAA09590@feller.mentat.com> To: Kazu@Mew.org Subject: (IPng 5582) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kazu, > > That is one part of our old proposal. > > Sorry but I'm not comfortable with your word, "unnecessary > restrictions". Scope rule is one of core features of our > implementation. It has been tested well in many places in our 6bone > for a year and half, and is proofed that it's a good idea I believe. > I did not mean to imply that your proposal or your code would not work. Clearly they do work quite well. > > I didn't recall that you proposed that the sockaddr_in6 change. You were > > ahead of your time. Further, I was not operating under the illusion that > > what I was proposing was unique. I knew it was not since others, including > > you apparently, had proposed it before. > > Let me summarize what happened in ipng ml. We proposed to include > ifindex to sockaddr_in6 as well as scope rule. At that time, the > advanced API was coming. Changing the basic structure seemed evil to > many people. > > We also proposed to embed ifindex to link-local and site-local > addresses instead of the modification of sockaddr_in6. Many people > said that our proposal was an ugly way. All in all, many people > believed that ancillary data was enough and clean. (I wonder that how > many peoble had enough experiences to make IPv4 application to be > bilingual at that time.) > Clearly not enough experience. Ancillary data for TCP applications is very difficult to manage well. I don't recall arguing against your proposal to change the sockaddr_in6. If I did I was dead wrong. > My current frustration to the adv API is how to use ancillary data for > TCP. In other words, how can I specify an interface for a TCP socket > with good-old read() and write() system calls? I also proposed the > IPV6_UNICAST_IF socket option to solve this problem, though, it was > not accepted, neither. I know if ifindex exists in sockaddr_in6, this > is resolved straightforward. > Yes, I remember you requesting the IPV6_UNICAST_IF option. I don't recall arguing against it but I don't recall speaking up in favor of it either. I probably should have done the later. I don't think people appreciated the problems involved in dealing with TCP connections using link-local addresses on multi-homed nodes at the time. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 18:02:22 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id RAA13051 for ipng-dist; Mon, 6 Apr 1998 17:57:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id RAA13044 for ; Mon, 6 Apr 1998 17:57:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA16880 for ; Mon, 6 Apr 1998 17:57:27 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id RAA18207 for ; Mon, 6 Apr 1998 17:57:29 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA23615; Mon, 6 Apr 98 17:54:14 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA09593; Mon, 6 Apr 1998 17:59:00 -0700 Date: Mon, 6 Apr 1998 17:59:00 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804070059.RAA09593@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5583) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > Amen Brother.... I ranted on this one for a week before the IETF....and > why I am uncomfortable putting this in just yet. My co-authors are > baffled too. We will do what consensus calls for but it is totally > unclear what any of this is going to be used for and putting something > that we don't know what it is going to be used for and how in the > cornerstone API for IPv6 deployment is very dangerous. People could > really hurt themselves. > > But it appears in this group we have a folkway that it is ok to define > things which are not well-thought-out or have a use that can be clearly > articulated in the area of address scoping and duplication. We have not > acted this way anywhere else for IPv6 and I am not comfortable how we > are acting on this "particular" issue and subject manner. > I am not sure what you are saying here. Are you saying that you and the co-authors of the API draft don't see any reason to change the sockaddr_in6? So are you saying that implementations should refuse to allow applications to use limited scope addresses? Are you saying that the mechanisms defined in the advanced API are adequate to deal with all the problems of limited scope addresses? Are you saying that we shouldn't allow nodes to be multi-sited? If I am completely nuts here I will shut up but I just don't see how in the world any of the currently defined BSD API's will work in the face of a multi- sited node. They don't even really work that well in the face of a multi- homed node. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 18:35:01 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id SAA13212 for ipng-dist; Mon, 6 Apr 1998 18:26:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id SAA13205 for ; Mon, 6 Apr 1998 18:26:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA22394 for ; Mon, 6 Apr 1998 18:26:37 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA00534 for ; Mon, 6 Apr 1998 18:26:39 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id KAA22843; Tue, 7 Apr 1998 10:26:39 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (3.2) id xma022779; Tue, 7 Apr 98 10:26:20 +0900 Received: from localhost (localhost.aist-nara.ac.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id KAA10114 for ; Tue, 7 Apr 1998 10:39:17 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 5584) who are you over UDP From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.93b26 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980407103917Q.kazu@Mew.org> Date: Tue, 07 Apr 1998 10:39:17 +0900 X-Dispatcher: imput version 980302 Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, In the flight back to Japan, I had been thinking the root privilege problem of "who are you". Through our implementation experiences, I think that "who are you" is really useful. So, it should be available for ordinal applications. I reached conclusion that UDP should be used for it instead of ICMP. If we use UDP, it should be implemented in user space not in kernel. "inetd" is a good candidate, which typically carries out basic services internally including "daytime", "time", "echo", etc. I'm saying that, at least, reserve lookup service should be carried in UDP messages. I don't know about other node information. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 19:00:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id SAA13294 for ipng-dist; Mon, 6 Apr 1998 18:53:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id SAA13287 for ; Mon, 6 Apr 1998 18:53:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA25908 for ; Mon, 6 Apr 1998 18:53:07 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA10475 for ; Mon, 6 Apr 1998 18:53:09 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id KAA26420; Tue, 7 Apr 1998 10:53:09 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (3.2) id xma026393; Tue, 7 Apr 98 10:52:56 +0900 Received: from localhost (localhost.aist-nara.ac.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id LAA10166 for ; Tue, 7 Apr 1998 11:05:54 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 5585) search path From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.93b26 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980407110553M.kazu@Mew.org> Date: Tue, 07 Apr 1998 11:05:53 +0900 X-Dispatcher: imput version 980302 Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dual stack environments introduces several ambiguities which were not found in the single stack environment. One of them is related to "search path" of domain name lookup. (e.g. The "search" keyword in /etc/resolv.conf.) I pointed it out months ago but it is not resolved yet in the new basic API draft. So I'd repeat it here. Suppose there are two hosts. One is "host.foo" which is IPv4-only host. The other is "host.bar' which is IPv6-only host. Also suppose that the search path is "foo bar". Currently there is no consensus about how getaddrinfo() returns results. So, resolving "host" with AF_UNSPEC, some implementations would return "host.foo(IPv4) host.bar(IPv6)"(maybe IPv4-IPv6 order or maybe the search path order). Other implementations would return "host.bar(IPv6) host.foo(IPv4)"(maybe IPv6-IPv4 order). So, "telnet host" results in connecting "host.foo" on some implementations while connecting "host.foo" on other ones. This is a real story because many implementations of getaddrinfo() prefer protocol families to search path. So, I would suggest that the new draft should note that search path is always preferred. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 19:20:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id TAA13374 for ipng-dist; Mon, 6 Apr 1998 19:14:35 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id TAA13356 for ; Mon, 6 Apr 1998 19:14:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA29300 for ; Mon, 6 Apr 1998 19:14:09 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA19898 for ; Mon, 6 Apr 1998 19:14:12 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id LAA29204; Tue, 7 Apr 1998 11:14:09 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (3.2) id xma029153; Tue, 7 Apr 98 11:13:49 +0900 Received: from localhost (localhost.aist-nara.ac.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id LAA10194 for ; Tue, 7 Apr 1998 11:26:47 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 5586) routing table vs. multiple sites From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.93b26 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980407112646T.kazu@Mew.org> Date: Tue, 07 Apr 1998 11:26:46 +0900 X-Dispatcher: imput version 980302 Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI on multiple sites. The current BSD variants integrates ARP info and routing info into a single routing table. This is based on assumptions that key is IP address and the key is unique. This is a dilemma for IPv6 because the key(i.e. IPv6 address) is not unique. Considering only link-local addresses, we may say that BSD implementation is not right because ARP table and routing table should be separated. Considering site-local, however, we can't help saying that a single routing talbe approach itself is not right. We need multiple routing table if multi-homed to multiple *site*s. In other words, nobody connects his router to multiple number 10 networks in the Internet, so far. I wonder whether or not the multiple site feature is required in practical cases. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 19:37:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id TAA13452 for ipng-dist; Mon, 6 Apr 1998 19:32:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id TAA13445 for ; Mon, 6 Apr 1998 19:32:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA01472 for ; Mon, 6 Apr 1998 19:32:32 -0700 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA26981 for ; Mon, 6 Apr 1998 19:32:33 -0700 (PDT) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (980309.SGI.8.8.8-aspam-6.2/980304.SGI-aspam) via ESMTP id TAA05463; Mon, 6 Apr 1998 19:32:08 -0700 (PDT) mail_from (sm@bossette.engr.sgi.com) Received: from bossette.engr.sgi.com (bossette.engr.sgi.com [150.166.61.12]) by cthulhu.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id TAA8658841; Mon, 6 Apr 1998 19:32:02 -0700 (PDT) Received: (from sm@localhost) by bossette.engr.sgi.com (980205.SGI.8.8.8/970903.SGI.AUTOCF) id TAA38824; Mon, 6 Apr 1998 19:32:01 -0700 (PDT) From: sm@bossette.engr.sgi.com (Sam Manthorpe) Message-Id: <199804070232.TAA38824@bossette.engr.sgi.com> Subject: (IPng 5587) Re: who are you over UDP In-Reply-To: <19980407103917Q.kazu@Mew.org> from Kazu Yamamoto at "Apr 7, 98 10:39:17 am" To: Kazu@Mew.org (Kazu Yamamoto) Date: Mon, 6 Apr 1998 19:32:00 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, > Through our implementation experiences, I think that "who are you" is > really useful. So, it should be available for ordinal applications. > > I reached conclusion that UDP should be used for it instead of ICMP. For the requests, there is no problem with any apps sending requests, but isn't there a potential security problem with user-level apps sending replies? Sam. ------------------------------------------------------------ Sam Manthorpe, SGI. tel: (650) 933-2856 fax: (650) 932-2856 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 19:53:32 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id TAA13512 for ipng-dist; Mon, 6 Apr 1998 19:45:44 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id TAA13476 for ; Mon, 6 Apr 1998 19:45:24 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA02959 for ; Mon, 6 Apr 1998 19:45:23 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA01321 for ; Mon, 6 Apr 1998 19:45:23 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id WAA02051; Mon, 6 Apr 1998 22:45:18 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA25512; Mon, 6 Apr 1998 22:45:13 -0400 Message-Id: <199804070245.AA25512@wasted.zk3.dec.com> To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5588) Re: Basic Sockets API In-Reply-To: Your message of "Mon, 06 Apr 1998 15:33:00 +0900." <19980406153300L.kazu@Mew.org> Date: Mon, 06 Apr 1998 22:45:12 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kazu, The reason we did not support the proposal is the same now. Many of us are not clear what value scope has other than link-local (for sysadm, DAD, the Dentist Office) and Global. I for one think it should be shot in the head, but I am not debating that and letting others debate it. I am talked out on the uselessness of anything other than link-local and global for unicast addresses. I do think we need the index in sockaddr_in6, but want to hear a bit more so we do it right once. I am less clear on the site description, but like you and Tim favor 32bits for alignment. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 19:57:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id TAA13548 for ipng-dist; Mon, 6 Apr 1998 19:54:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id TAA13536 for ; Mon, 6 Apr 1998 19:54:12 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA04090 for ; Mon, 6 Apr 1998 19:54:11 -0700 Received: from rast.cisco.com (rast.cisco.com [171.69.187.231]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA04645 for ; Mon, 6 Apr 1998 19:54:12 -0700 (PDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by rast.cisco.com (8.8.7/8.8.7) with SMTP id TAA04943; Mon, 6 Apr 1998 19:53:35 -0700 (PDT) (envelope-from raj@cisco.com) Message-Id: <199804070253.TAA04943@rast.cisco.com> To: thartric@mentat.com (Tim Hartrick) cc: huitema@bellcore.com, ipng@sunroof.eng.sun.com Subject: (IPng 5589) Re: Basic Sockets API In-reply-to: Your message of "Mon, 06 Apr 1998 11:40:54 PDT." <199804061840.LAA09360@feller.mentat.com> X-Quote: If you consult enough experts, you can confirm any opinion. Date: Mon, 06 Apr 1998 19:53:34 -0700 From: Richard Johnson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I think that Jim is right on the mark. Using scoped addresses in > > application is *not* a good idea. We have two choices here, not just one: > > > > 1) update the interface format to include link and site specification in > > addresses. > > > > 2) not update it, and make it real hard to use scoped addresses in > > applications. > > > > So how does the canonical dentist's office example work if we can't use > link-local addresses in applications? > > The dentist's office has a single subnet and has no router to advertise > prefix information and no DHCP server to issue leases to addresses. Are you > suggesting that the dentist office fall back on manual configuration of > addresses? Seems to me that lacking a nameserver, a router, or a DHCP server means you need to translate names to addresses, and vis versa, using some other facility designed for such a limited situation. Sounds as if the ICMP "Who are you?" takes care of address -> hostname mappings, but we need a similar "Where are you?" ICMP (sent to all-nodes address?) to map a name to an IPv6 address. This low level functionality would only operate on the local link and would only be used in limited situations where there is no nameserver, DHCP server, etc. I see no problem with using link-local addresses in applications if the system only has one interface (as most would). If the system has more than one interface, then you don't have the "single subnet" dentist office situation. Also a system with more than one interface is beginning to look more like a router w.r.t. the issues it needs to deal with. /raj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 20:04:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id UAA13586 for ipng-dist; Mon, 6 Apr 1998 20:00:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id UAA13579 for ; Mon, 6 Apr 1998 20:00:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA04606 for ; Mon, 6 Apr 1998 20:00:29 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id UAA06633 for ; Mon, 6 Apr 1998 20:00:30 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA25419; Mon, 6 Apr 98 19:57:10 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id UAA09649; Mon, 6 Apr 1998 20:01:54 -0700 Date: Mon, 6 Apr 1998 20:01:54 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804070301.UAA09649@feller.mentat.com> To: Kazu@Mew.org Subject: (IPng 5591) Re: routing table vs. multiple sites Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kazu, > > FYI on multiple sites. > > The current BSD variants integrates ARP info and routing info into a > single routing table. This is based on assumptions that key is IP > address and the key is unique. > > This is a dilemma for IPv6 because the key(i.e. IPv6 address) is not > unique. Considering only link-local addresses, we may say that BSD > implementation is not right because ARP table and routing table should > be separated. > > Considering site-local, however, we can't help saying that a single > routing talbe approach itself is not right. We need multiple routing > table if multi-homed to multiple *site*s. > > In other words, nobody connects his router to multiple number 10 > networks in the Internet, so far. I wonder whether or not the multiple > site feature is required in practical cases. > This observation is one of the reasons why I get heartburn when I think about what it means for an implementation to be multi-sited. I assume it accounts for the sour stomach most of the other implementors have when thinking about this as well. Then we start thinking about name resolution and API's and..... There are some difficult implementation problems here. An implementation already needs to consider the interface index when doing routing table lookups for link-local addresses. You have achieved that by embedding interface indices into the link-local addresses in your routing table. That has essentially partitioned your routing table into per-interface pieces. The same type of partitioning is required for multi-sited nodes since a routing table entry for fec0::a00:3eff:fe22:3b27/128 is only meaningful when it is considered in the context of a specific site. The site index needs to be part of the "key". I have always thought of site-local addresses as being exactly equivalent to net 10 addresses. Networks of net 10 addresses are rarely interconnected. If they are connected at all it is using a DMZ link between border routers connected to the net 10 networks. If we adopt the same operational model for IPv6 site-local addresses we will save ourselves a lot of Maalox. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 20:04:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id TAA13576 for ipng-dist; Mon, 6 Apr 1998 19:58:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id TAA13569 for ; Mon, 6 Apr 1998 19:58:04 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA04429 for ; Mon, 6 Apr 1998 19:58:00 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA05835 for ; Mon, 6 Apr 1998 19:58:01 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id WAA27450; Mon, 6 Apr 1998 22:58:00 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA24187; Mon, 6 Apr 1998 22:57:44 -0400 Message-Id: <199804070257.AA24187@wasted.zk3.dec.com> To: Jun-ichiro itojun Itoh Cc: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 5590) Re: Basic Sockets API In-Reply-To: Your message of "Tue, 07 Apr 1998 06:53:13 +0900." <9275.891899593@coconut.itojun.org> Date: Mon, 06 Apr 1998 22:57:43 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When Steve drew a dotted line in the center of the node and said a site could pass in a node I got confused. But we did not finish that discussion in L.A. Now I don't think we need site-local addresses and they are evil. But...if we keep them...here are some rules I would like to see: More than one site cannot be associated on an interface. On a node a site can span more than one interface. So if we have siteA and siteB ln0 - can either belong to siteA or siteB but not both. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 20:38:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id UAA13730 for ipng-dist; Mon, 6 Apr 1998 20:33:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id UAA13723 for ; Mon, 6 Apr 1998 20:33:40 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA07656 for ; Mon, 6 Apr 1998 20:33:39 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA17440 for ; Mon, 6 Apr 1998 20:33:40 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id XAA01561; Mon, 6 Apr 1998 23:33:31 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA27165; Mon, 6 Apr 1998 23:33:25 -0400 Message-Id: <199804070333.AA27165@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5592) Re: Basic Sockets API In-Reply-To: Your message of "Mon, 06 Apr 1998 17:59:00 PDT." <199804070059.RAA09593@feller.mentat.com> Date: Mon, 06 Apr 1998 23:33:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I am not sure what you are saying here. Are you saying that you and the >co-authors of the API draft don't see any reason to change the sockaddr_in6? Not at all. I am saying based on conversations at the IETF and on this mail list I am not clear what status "site" has for IPv6. Are you clear what a site is regarding boundaries for interfaces and links for your implementation based on the specs? Do you believe we need site local addresses for IPv6? >So are you saying that implementations should refuse to allow applications >to use limited scope addresses? No. I do believe link-local is fine for the link and the only area where I think I part with Christian because I don't want the dentist office to manual configure addresses if a DHCPv6 server is not present. But I don't think we need more than global or link-local addresses for IPv6 personally. >Are you saying that the mechanisms defined in the advanced API are adequate >to deal with all the problems of limited scope addresses? They are not at all and why we need to fix sockaddr_in6. We should add the interface index so all user xmit/recv libraries can use the index. I am just not clear on site and what we are doing with it. >Are you saying that we shouldn't allow nodes to be multi-sited? Yes. >If I am completely nuts here I will shut up but I just don't see how in the >world any of the currently defined BSD API's will work in the face of a multi- >sited node. They don't even really work that well in the face of a multi- >homed node. We need the index and most likely we will be forced to add the site to sockaddr_in6. But before we change the struct I would like to believe all realize what we are doing here and in the case of site we are walking down a dark alley with no clarity IMO. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 6 23:29:53 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id XAA14073 for ipng-dist; Mon, 6 Apr 1998 23:25:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id XAA14066 for ; Mon, 6 Apr 1998 23:25:05 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA24442 for ; Mon, 6 Apr 1998 23:24:59 -0700 Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id XAA17009 for ; Mon, 6 Apr 1998 23:24:59 -0700 (PDT) Received: from aussie.cs.mu.OZ.AU (aussie-ppp.cs.mu.OZ.AU [128.250.38.70]) by mulga.cs.mu.OZ.AU with ESMTP id QAA07467 for ; Tue, 7 Apr 1998 16:24:51 +1000 (EST) Received: from aussie.cs.mu.OZ.AU (kre@localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.5/8.8.5) with ESMTP id QAA06149 for ; Tue, 7 Apr 1998 16:25:00 +1000 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: Robert Elz Subject: (IPng 5593) Name lookups on isolated nets. To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 07 Apr 1998 16:24:58 +1000 Message-ID: <6146.891930298@aussie.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I too have been contemplating various issues over the past few days since the IETF, and while I am not convinced I have all of the answers yet, there are a couple of things which I have pretty much convinced myself (note the absence of much rational contrary argument however) are the right way to go. The first of these is the problem of name lookup in isolated networks. It seems generally accepted that we need some kind of "who are you" and "where are you" type messages to handle this, as no-one really expects the dentist in his office (or your granny in her flat) to configure a DNS server... (or even necessarily own a node upon which a server could be run). That I agree with. However, beyond that, Matt has his draft for "who are you" that I had generally supported before, and which I now believe is simply the wrong way. Instead of inventing new formats, and stuff, and producing a very sub-standard service (ie: capable of only the absolute basics), I suggest that the packet format to use should simply be a DNS packet, sent to UDP port 53 (there's already been some discussion of moving these from ICMP to UDP), but sent to the all nodes multicast address (from a link local source). The strategy would be as follows - to make a query, the API library routines form a DNS query (always) (ie: only one packet to ever build). Then, if a DNS server has been discovered somehow (configured manually, found via DHCP, or from svrloc, or any other way we later dream up) the packet is sent to the relevant address (or in turn, addresses, if there are more than one). If there were no addresses for DNS servers found, or if none of the addresses respond at all (not even a server failure type response), then the node sends the packet to the all nodes multicast on each link to which it is connected. There may be a delay introduced here, but only if DNS servers are supposed to exist but fail to respond - that generally indicates some kind of fault exists, and hence a lookup delay is not unreasonable. To complement this, all nodes would be required to have a very simple DNS server installed on (only) UDP port 53 (ie: no TCP DNS support is required for this). That server would listen to (only) multicast queries on UDP port 53 (a regular DNS server could listen for requests to unicast addresses on port 53, and TCP port 53, and could if it desired, replace the simple server and handle multicast queries as well). For further study is whether the simple server ever handling unicast requests would be useful. The simple server would know how to handle queries for only its own name (assuming it has discovered its own name somehow) and inverse queries for its own addresses (that is, IP6.INT queries, in exactly the same way as a DNS server handles queries) again assuming it has, somehow, obtained a name for itself to return (how names are obtained is an entirely different issue not covered here at all). Any other query received may be silently ignored. Note that I don't say must be, or even should be. When returning addresses, the node should return global addresses if it has any, site locals if and only if there are no globals, but site locals do exist, and link local addresses only when no other addresses exist. This pretty much parallels the way a real configured DNS server would respond, returning only global addresses, unless the site is totally disconnected, in which case site local addresses would probably be configured. We still need mechanism to deal with how a node receiving a global address checks to see if a site local is available and if so, whether it is appropriate to use. That will be needed for regular DNS responses anyway, the same technique ought be used here. The advantage of this scheme is that there is just one kind of nameserver packet involved, and we don't have to invent it, all we need to bother with is the method of addressing the packets, and for implementors to create baby servers to handle the necessary queries. Another advantage is that if your nameservers all become unreachable (eg: internal site links going down) you can at least automatically retain naming reachability to other local nodes (so you will still be able to telnet or snmp to your router by name, in order to find out what is broken and why - and one more excuse for users using addresses will be gone.) The disadvantage is that the packet format is rather more complicated than we had been imagining previously for this kind of service, and in particular the baby server in every node will be slightly more complicated than it would be with one of the new packet format schemes. This is tempered by the DNS having been pretty well thrashed out as to usage, capabilities, etc. That is it already allows multiple addresses, it already supplies TTL, etc. I don't think this is much of a disadvantage. By doing this we also leave lots of future options open with no extra effort - including the ability to implement other kinds of queries in the simple servers should they seem useful (queries for KEY records might be one that might be useful to be able to make in the dentist's office), without having to invent anything new. Similarly, the possibility of the simple server on some node doing more complex resolutions (a smart router might like to forward the query out other links and cache the results if it sees retransmitted queries - not the first one as it has no way to know that another node on the same link isn't going to reply, but if it sees a repeat query within hundred of two millseconds from the same node, for the same name with the same DNS ID, then assuming that the name is not on the first link and forwarding it might work - because other routers on the new links would see this as only a first query, it would take several retransmits to get the query to go very far - several routers all forwarding to the same link would not be seen as retransmits as the requests would be coming from different addresses). There are all kinds of issues involved here of course, and this is very much for further study - I mention it simply as an example of the kinds of things that might be able to be done. And yes, this is not all that different in some respects from the appletalk NBP name resolution stuff - with the major difference that the scaling problem is totally under control - any network big enough to be concerned simply needs to implement a DNS server, and the multicast queries all go away. There are still a few things that need specification. Eg: DNS packets generally should (must) contain FQDNs only. The baby servers need to expect to receive FQDNs. But because users typically type only abreviated names to applications, and without any config server to supply the default domain name (or search list) these packets ought to be able to also contain just the abbreviated name, and the servers ought probably be willing to respond to requests for abbreviated and fully qualified names equally. That is if the dentist does a lookup for "chair" the chair ought respond whether or not the chair believes its name is chair.dentist.com or just "chair" and regardless of whether or not the dentist (or his UI) knew the "dentist.com" part and sent chair.dentist.com or just chair in the query. Similarly, we have no name uniqueness protocol, and I'm not sure that we need one - if the dentist grows a bit bigger and buys a second chair, and both of them simply believe their name is "chair", then both of them respond. The client can take the first response, or better, take all that arrive (quickly) and then work out which address to use later - even you average dentist, or granny, won't have too much trouble working out that if there are two objects called "chair" that it is going to be somewhat random which gets selected each time, and so one of them ought be convinced to change its name (using whatever method it might have). And speaking of which, another further study mechanism which a baby DNS server in each node might implement might be a very limited dynamic DNS update - then, given a dynamic update packet to the baby server, with a request to delete the old name, and install a new one, and we'd have a mechanism by which even light bulbs could be given individual names. Nodes would ignore any packets attempting to associate addresses that don't belong to this node to a name. And yes, there are security issues, but as this kind of name service is only used in small isolated networks, and because the packets are required to come only from link local addresses in any case, it may not be too important that anyone on the net would be able to change any other node's name (or any willing to be changed this way). In any case, this is more that is for future study. I'll wait a bit to see what reactions this message elicits, and depending upon what that is, might send in a draft with a more complete specification of what is needed here. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 06:25:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id GAA14539 for ipng-dist; Tue, 7 Apr 1998 06:17:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id GAA14532 for ; Tue, 7 Apr 1998 06:17:13 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA26678 for ; Tue, 7 Apr 1998 06:17:10 -0700 Received: from bkb01-ims-01.us.ikom.net (bkb01-ims-01.ikon.com [205.145.58.62]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA06020 for ; Tue, 7 Apr 1998 06:17:07 -0700 (PDT) Received: by BKB01-IMS-01 with Internet Mail Service (5.5.1960.3) id <2AWGJHX0>; Tue, 7 Apr 1998 09:17:06 -0400 Message-ID: <4B9D30E70131D1119C0900805F5928C1047C9C@PHL02-MSX-01> From: "Jennings, Robert" To: bound@zk3.dec.com, Jun-ichiro itojun Itoh Cc: thartric@mentat.com, ipng@sunroof.eng.sun.com Subject: (IPng 5595) Re: Basic Sockets API Date: Tue, 7 Apr 1998 09:17:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I apologize if it's poor etiquette to intrude on this discussion group as a non-member, but as the manager of network computing for a large network integrator, I wanted to provide some input on the importance of site local addresses as a replacement for IANA-sanctioned private network addresses ("Net 10"). Lack of availability of sufficient addresses was the first reason for Net 10, then unconnected sites. There is a third reason (or maybe it's an outcome) of these two: SECURITY. The large majority of my customers have become VERY comfortable with NAT from a set-aside (Net 10) address that CAN NOT be routed on the Internet as a security mechanism to provide an additional layer of protection between their private network and their Internet connection. That's real world implementation, and just for reference, I'm talking about Fortune 1000 accounts and other organizations with 10,000 connected nodes and more. I hope this is useful information for all of you. Regards, Robert Jennings, MCNE, MCP Director, Network Computing Practice IKON Technology Services V: (610) 494-9000 F: (610) 494-2090 E-Mail: RJennings@IKON.com URL: www.uscphl.com www.IKON.com On Friday, 3/13, kaih@khms.westfalen.de wrote: >bound@zk3.dec.com wrote on 11.03.98 in <199803120243.AA03381@wasted.zk3.dec.com>: > >> I don't think using the NET 10 reasoning to keep site local addresses is >> valid. That reasoning really was because the IPv4 address is >> depleting. Also to do Net 10 we do not need site local addresses >> anyway, if one was so inclined. > >One reason was address depletion. There's another reason, and it seems to >me this is actually worse with IPv6 - unconnected sites. (There are lots >of small unconnected sites around, and not all of them have only one link >and can thus use link-local addresses.) > >Originally, unconnected sites could just apply for some IPv4 addresses, >until people realized there weren't enough. > >Then, they could use net 10. > >What are they going to do in IPv6? All the "usual" addresses are handed >down topologically, via providers. Unconnected sites aren't going to get >any. > >They are going to want an IPv6 equivalent of net 10. and, on Monday, 4/6, bound@zk3.dec.com wrote: > Now I don't think we need site-local addresses and they are evil. > > But...if we keep them...here are some rules I would like to see: > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 06:25:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id GAA14548 for ipng-dist; Tue, 7 Apr 1998 06:21:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id GAA14541 for ; Tue, 7 Apr 1998 06:21:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA27132 for ; Tue, 7 Apr 1998 06:21:41 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA08169 for ; Tue, 7 Apr 1998 06:21:42 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id JAA34364; Tue, 7 Apr 1998 09:18:52 -0400 (EDT) Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA25330; Tue, 7 Apr 1998 09:18:54 -0400 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21714; Tue, 7 Apr 1998 09:18:57 -0400 Message-Id: <352A27C1.27D134A5@raleigh.ibm.com> Date: Tue, 07 Apr 1998 09:18:57 -0400 From: Brian Haberman Organization: IBM Network Hardware Division X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5596) Re: Basic Sockets API References: <199804070257.AA24187@wasted.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bound@zk3.dec.com wrote: > > When Steve drew a dotted line in the center of the node and said a > site could pass in a node I got confused. But we did not finish that > discussion in L.A. > Jim, I have been looking at the site issue for awhile now and I agreed with Steve's picture in LA. The site boundaries should pass through nodes. The benefits of that are : 1. Physical links are associated with at most 1 site 2. Nodes can have multiple interfaces in a site 3. Nodes can be attached to multiple sites (if multi-homed) If it would help, I could put a draft together that specifies these site rules. Brian Haberman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 07:29:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id HAA14671 for ipng-dist; Tue, 7 Apr 1998 07:23:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id HAA14664 for ; Tue, 7 Apr 1998 07:23:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA11221 for ; Tue, 7 Apr 1998 07:23:28 -0700 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA10248 for ; Tue, 7 Apr 1998 07:23:27 -0700 (PDT) Received: from research.att.com ([135.207.30.100]) by rumor; Tue Apr 7 10:19:43 EDT 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Tue Apr 7 10:23:02 EDT 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id KAA03813; Tue, 7 Apr 1998 10:22:24 -0400 (EDT) Message-Id: <199804071422.KAA03813@postal.research.att.com> To: "Jennings, Robert" cc: bound@zk3.dec.com, Jun-ichiro itojun Itoh , thartric@mentat.com, ipng@sunroof.eng.sun.com Subject: (IPng 5597) Re: Basic Sockets API Date: Tue, 07 Apr 1998 10:22:23 -0400 From: Steve Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I apologize if it's poor etiquette to intrude on this discussion group as a non-member, but as the manager of network computing for a large network integrator, I wanted to provide some input on the importance of site local addresses as a replacement for IANA-sanctioned private network addresses ("Net 10"). Lack of availability of sufficient addresses was the first reason for Net 10, then unconnected sites. There is a third reason (or maybe it's an outcome) of these two: SECURITY. The large majority of my customers have become VERY comfortable with NAT from a set-aside (Net 10) address that CAN NOT be routed on the Internet as a security mechanism to provide an additional layer of protection between their private network and their Internet connection. That's real world implementation, and just for reference, I'm talking about Fortune 1000 accounts and other organizations with 10,000 connected nodes and more. I hope this is useful information for all of you. A number of people think that NATs per se are a strong security measure. In my opinion, that is a seriously mistaken notion. The security provided by a NAT box is comparable to that provided by a simple packet filter, and arguably less. If no one inside is trying to talk to the Internet, there are no externally-visible mappings from global addresses to private addresses. A packet filter with the rule 'no inbound packets to my inside addresses' has the same effect. Typically, of course, there are a few machines that can receive packets, such as the mail gateway. Again, this is easily expressed by packet filters. If a host makes an outgoing call, it suddenly acquires an address. What happens to inbound packets for this address? If the NAT box doesn't block them -- again, via a mechanism very much like a packet filter's port number rules -- the host is quite vulnerable. If the NAT box does block inbound packets from other connections, it is again behaving like a packet filter. And simple packet filters can use the ACK bit to distinguish incoming from outgoing calls. There are probably some hosts that are never allowed to talk to the Internet. NAT boxes can certainly enforce that. Of course, so can packet filters. To be sure, if you're using a router as your packet filter, it's a bit tricky to match up the rules for the inside and outside interfaces, to avoid oddball interactions. A real firewall based primarily on packet filtering would not have that problem. And its internal complexity is almost certainly significantly less than that of the NAT box, since it doesn't have to scan packets for addresses on a per-protocol basis. (I'm especially fond of the ftp PORT command, where the NAT box probably has to adjust the TCP sequence numbers as well, since the two different address strings are likely to be of different lengths.) The real danger, though, is from applications that must be processed separately. This typically includes mail, plus any other services that are provided by inside hosts. Even outside service hosts, such as Web and ftp servers, need some administrative access mechanism; if this isn't implemented carefully, it can be a venue for attack. In short -- both packet filter and NAT boxes can easily block direct access from the Internet. Both tend to require service hosts; these, if subverted, can be a mechanism for attack in either case. I frankly don't see any significant difference. If there is, it may be that NATs are less secure, because of the extra processing that they have to do. (To be sure, firewalls that try to know too much about application protocols -- including ftp, of course -- suffer similar weaknesses. But you don't have to do such checking on a firewall, especially if you use PASV instead.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 09:05:04 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id IAA14904 for ipng-dist; Tue, 7 Apr 1998 08:59:24 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id IAA14897 for ; Tue, 7 Apr 1998 08:59:19 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id IAA28496 for ; Tue, 7 Apr 1998 08:59:18 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id IAA08718 for ipng@sunroof.eng.sun.com; Tue, 7 Apr 1998 08:59:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id XAA14102 for ; Mon, 6 Apr 1998 23:51:38 -0700 (PDT) From: Mark.Andrews@cmis.CSIRO.AU Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA26520 for ; Mon, 6 Apr 1998 23:51:36 -0700 Received: from snowy.nsw.cmis.CSIRO.AU (snowy.nsw.cmis.CSIRO.AU [130.155.16.108]) by earth.sun.com (8.8.8/8.8.8) with SMTP id XAA24981 for ; Mon, 6 Apr 1998 23:51:36 -0700 (PDT) Received: by snowy.nsw.cmis.CSIRO.AU (SMI-8.6/SMI-SVR4) id QAA09878; Tue, 7 Apr 1998 16:51:22 +1000 Message-Id: <199804070651.QAA09878@snowy.nsw.cmis.CSIRO.AU> Received: from pride.nsw.cmis.CSIRO.AU(130.155.16.4) via SMTP by snowy.nsw.cmis.CSIRO.AU, id smtpdAAAa002QI; Tue Apr 7 16:51:16 1998 To: Robert Elz cc: ipng@sunroof.eng.sun.com Subject: (IPng 5598) Re: Name lookups on isolated nets. In-reply-to: Your message of "Tue, 07 Apr 1998 16:24:58 +1000." <6146.891930298@aussie.cs.mu.OZ.AU> Date: Tue, 07 Apr 1998 16:51:19 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I too have been contemplating various issues over the past few days since > the IETF, and while I am not convinced I have all of the answers yet, there > are a couple of things which I have pretty much convinced myself (note the > absence of much rational contrary argument however) are the right way to go. > > The first of these is the problem of name lookup in isolated networks. > > It seems generally accepted that we need some kind of "who are you" and > "where are you" type messages to handle this, as no-one really expects the > dentist in his office (or your granny in her flat) to configure a DNS > server... (or even necessarily own a node upon which a server could be run). > > That I agree with. > > However, beyond that, Matt has his draft for "who are you" that I had > generally supported before, and which I now believe is simply the wrong > way. Instead of inventing new formats, and stuff, and producing a very > sub-standard service (ie: capable of only the absolute basics), I suggest > that the packet format to use should simply be a DNS packet, sent to UDP > port 53 (there's already been some discussion of moving these from ICMP > to UDP), but sent to the all nodes multicast address (from a link local > source). > Sounds reasonable. Mark -- Mark Andrews, CSIRO Mathematical and Information Sciences Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 9325 3148 INTERNET: Mark.Andrews@cmis.csiro.au MOBIL: +61 41 442 9884 UUCP:....!uunet!cmis.csiro.au!mark.andrews -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 09:07:52 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA14937 for ipng-dist; Tue, 7 Apr 1998 09:04:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id JAA14924 for ; Tue, 7 Apr 1998 09:04:23 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA11480 for ; Tue, 7 Apr 1998 09:04:20 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA11108 for ; Tue, 7 Apr 1998 09:04:15 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id MAA01687; Tue, 7 Apr 1998 12:04:13 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA31524; Tue, 7 Apr 1998 12:03:57 -0400 Message-Id: <199804071603.AA31524@wasted.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5599) Re: Name lookups on isolated nets. In-Reply-To: Your message of "Tue, 07 Apr 1998 16:24:58 +1000." <6146.891930298@aussie.cs.mu.OZ.AU> Date: Tue, 07 Apr 1998 12:03:57 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, I think this is not a good idea. Have you looked at DNS Server code base for BIND as one example. Vendors are not in the business of developing DNS servers but get them from places like ISC, AIC, etc. for the most part. I think this is not a good paradigm for host machines to be involved with. What parts for RFC 1034/1035 would you have the hosts support? It is just too involved and I am not clear we need to solve this problem. In the caes of the dentist office link-local addresses will work fine if they have no connections. Also site and link-local addresses are not goiing to be stored in the DNS anyway at this point. I would claim this problem is future work for IPv6 if necessary we have enough now to deploy and I would like to see the Chairs differentiate the IPv6 work at this point now btw what is needed to deploy in the market and what is "nice to have". I am not even clear this is a nice to have. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 09:28:10 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA14967 for ipng-dist; Tue, 7 Apr 1998 09:19:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id JAA14960 for ; Tue, 7 Apr 1998 09:18:47 -0700 (PDT) From: bmanning@ISI.EDU Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA16166 for ; Tue, 7 Apr 1998 09:18:46 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA20742 for ; Tue, 7 Apr 1998 09:18:46 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by zephyr.isi.edu (8.8.7/8.8.6) with SMTP id JAA13210; Tue, 7 Apr 1998 09:18:45 -0700 (PDT) Posted-Date: Tue, 7 Apr 1998 09:16:14 -0700 (PDT) Message-Id: <199804071616.AA04864@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 7 Apr 1998 09:16:14 -0700 Subject: (IPng 5600) Re: Name lookups on isolated nets. To: bound@zk3.dec.com Date: Tue, 7 Apr 1998 09:16:14 -0700 (PDT) Cc: kre@munnari.oz.au, ipng@sunroof.eng.sun.com In-Reply-To: <199804071603.AA31524@wasted.zk3.dec.com> from "bound@zk3.dec.com" at Apr 7, 98 12:03:57 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 > Robert, > > I think this is not a good idea. Have you looked at DNS Server code > base for BIND as one example. Vendors are not in the business of > developing DNS servers but get them from places like ISC, AIC, etc. > for the most part. I think that this is really a case of a larger hurdle than folks wish to jump. I can't speak for Robert (although he does run some very large servers) but I have looked at the server code. It's... arcane? > I think this is not a good paradigm for host machines to be involved > with. > What parts for RFC 1034/1035 would you have the hosts support? It is > just too involved and I am not clear we need to solve this problem. In a very real sense this is in line with the arguments that we need to "dumb-down" the network and increase the "smarts" in the end systems. > In the caes of the dentist office link-local addresses will work fine if > they have no connections. Which (IMHO) will almost never be true, except for startup cases. > Also site and link-local addresses are not goiing to be stored in the > DNS anyway at this point. Being a DNS content policeman is a thankless job. > I would claim this problem is future work for IPv6 if necessary we have > enough now to deploy and I would like to see the Chairs differentiate > the IPv6 work at this point now btw what is needed to deploy in the > market and what is "nice to have". Fish or cut bait? Prolly true. -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 09:28:12 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA14976 for ipng-dist; Tue, 7 Apr 1998 09:20:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id JAA14969 for ; Tue, 7 Apr 1998 09:20:12 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA16637 for ; Tue, 7 Apr 1998 09:20:10 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA21722 for ; Tue, 7 Apr 1998 09:20:09 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id MAA01988; Tue, 7 Apr 1998 12:20:02 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00733; Tue, 7 Apr 1998 12:19:54 -0400 Message-Id: <199804071619.AA00733@wasted.zk3.dec.com> To: Brian Haberman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5601) Re: Basic Sockets API In-Reply-To: Your message of "Tue, 07 Apr 1998 09:18:57 EDT." <352A27C1.27D134A5@raleigh.ibm.com> Date: Tue, 07 Apr 1998 12:19:54 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > I have been looking at the site issue for awhile now and I agreed >with Steve's picture in LA. The site boundaries should pass through >nodes. The benefits of that are : > 1. Physical links are associated with at most 1 site OK. > 2. Nodes can have multiple interfaces in a site OK. > 3. Nodes can be attached to multiple sites (if multi-homed) OK. >If it would help, I could put a draft together that specifies these >site rules. Yes it would but before you do the work you should be comfortable that site will not get shot in the head as this is heating up off this list too and could be an issue with IETF last call drafts for the addr arch. Or worse yet addrconf or ND. As Last Call is a place to raise an issue in the appeals process for common sense in the IETF to let the IESG know of an issue that may have not been completely resolved in everyones mind. If adding site complicates implementations enough because it is not well defined I will raise this in IETF last call. As much as I want to see IPv6 deployed I do not want to build parts into a product I highly object too because 12 people believe it on IPng and at least give the IESG my doubts on this issue and the reason which is cost and bugs in the implementations. So a draft on site might be very helpful here. Unless someone can convince me privately I almost believe this could be an appeal to the IAB. We simply do not need site addresses and no one has depicted what good they are for IPv6. I would add this rule too: 4. An interface can only be associated with one site This is because of rule #1 above but I think needs to be clearly stated. Also I did not see Steve's diagram depict this ruleset but if it did then I misinterpreted his dotted line in the center of the node as did some of my other colleagues!!!! (in and out of Digital).. Also the Net 10 argument for Site is completely bogus. The only good reason for Net 10 is IPv4 ran out of addresses and this is not an issue for IPv6. The marketechture of some vendors and some in the IETF to make Net 10 more than that is unfortuneate, but that is not a good enough reason to put this in IPv6. Security is a bogus argument too. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 11:58:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id LAA15289 for ipng-dist; Tue, 7 Apr 1998 11:53:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id LAA15282 for ; Tue, 7 Apr 1998 11:53:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA05630 for ; Tue, 7 Apr 1998 11:53:39 -0700 Received: from tokyogw.iij.ad.jp (tokyogw.iij.ad.jp [202.232.15.22]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA01844 for ; Tue, 7 Apr 1998 11:53:40 -0700 (PDT) Received: by tokyogw.iij.ad.jp; id DAA22032; Wed, 8 Apr 1998 03:53:39 +0900 (JST) Received: from mine.iij.ad.jp(192.168.4.209) by tokyogw.iij.ad.jp via smap (3.2) id xma022025; Wed, 8 Apr 98 03:53:33 +0900 Received: from localhost (localhost.aist-nara.ac.jp [127.0.0.1]) by mine.iij.ad.jp (8.8.7/8.8.5) with ESMTP id EAA27361 for ; Wed, 8 Apr 1998 04:06:45 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 5602) Re: who are you over UDP From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: Your message of "Mon, 6 Apr 1998 19:32:00 -0700 (PDT)" <199804070232.TAA38824@bossette.engr.sgi.com> References: <199804070232.TAA38824@bossette.engr.sgi.com> X-Mailer: Mew version 1.93b26 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980408040644C.kazu@Mew.org> Date: Wed, 08 Apr 1998 04:06:44 +0900 X-Dispatcher: imput version 980407 Lines: 16 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: sm@bossette.engr.sgi.com (Sam Manthorpe) Subject: Re: (IPng 5584) who are you over UDP Date: Mon, 6 Apr 1998 19:32:00 -0700 (PDT) > For the requests, there is no problem with any apps sending > requests, but isn't there a potential security problem with > user-level apps sending replies? If you want root privilege on a server side, use a UDP port lower than 1024. This is UNIX convention. However, you must not rely on non-authentic data for security. There is no essential difference between ordial DNS reverse lookup (without secure DNS) and "how are you". --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 12:19:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA15319 for ipng-dist; Tue, 7 Apr 1998 12:13:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA15312 for ; Tue, 7 Apr 1998 12:13:39 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA10632 for ; Tue, 7 Apr 1998 12:13:36 -0700 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA13406 for ; Tue, 7 Apr 1998 12:13:37 -0700 (PDT) Received: from research.att.com ([135.207.30.100]) by rumor; Tue Apr 7 15:09:41 EDT 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Tue Apr 7 15:11:34 EDT 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id PAA13275; Tue, 7 Apr 1998 15:10:52 -0400 (EDT) Message-Id: <199804071910.PAA13275@postal.research.att.com> To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) cc: ipng@sunroof.eng.sun.com Subject: (IPng 5603) Re: who are you over UDP Date: Tue, 07 Apr 1998 15:10:51 -0400 From: Steve Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: sm@bossette.engr.sgi.com (Sam Manthorpe) Subject: Re: (IPng 5584) who are you over UDP Date: Mon, 6 Apr 1998 19:32:00 -0700 (PDT) > For the requests, there is no problem with any apps sending > requests, but isn't there a potential security problem with > user-level apps sending replies? If you want root privilege on a server side, use a UDP port lower than 1024. This is UNIX convention. However, you must not rely on non-authentic data for security. There is no essential difference between ordial DNS reverse lookup (without secure DNS) and "how are you". Right. This does point out one potential problem, though: how is each host to get a secure DNS response for its own host name? That is, today's secure DNS protocols assume that there is one master DNS machine onto which is loaded a signed zone. In this scheme, each machine would have to contact some master machine -- using some other protocol? -- to retrieve its own record. It could then echo that record in response to any queries. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 18:38:42 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id SAA15966 for ipng-dist; Tue, 7 Apr 1998 18:28:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id SAA15959 for ; Tue, 7 Apr 1998 18:28:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA12295 for ; Tue, 7 Apr 1998 18:28:15 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id SAA27387 for ; Tue, 7 Apr 1998 18:28:16 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA15455; Tue, 7 Apr 98 18:24:48 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id SAA10448; Tue, 7 Apr 1998 18:29:36 -0700 Date: Tue, 7 Apr 1998 18:29:36 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804080129.SAA10448@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5604) Re: Basic Sockets API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > >I am not sure what you are saying here. Are you saying that you and the > >co-authors of the API draft don't see any reason to change the sockaddr_in6? > > Not at all. I am saying based on conversations at the IETF and on this > mail list I am not clear what status "site" has for IPv6. > Good. I kind of thought that was what you were saying but I needed to clarify the point. > Are you clear what a site is regarding boundaries for interfaces and > links for your implementation based on the specs? > The specifications don't appear to make any statement about where site boundaries reside. From a correctness point of view it doesn't seem possible for a single interface to be in multiple sites. Based on discussions which have occurred on this list and at IETF it seems that the authors intended for site boundaries to run through nodes rather than through links. This choice of boundaries significantly complicates an implementation since it requires additional qualification in routing tables, API's, DNS lookups, etc. in order to disambiguate which site is being referenced by an address or a name. There is lots of work to do to make multi-sited nodes work but at a minimum we need to have enough information in the sockaddr_in6 structure to allow us to disambiguate which site is being referenced by the sin6_addr. There have been a couple of different proposals on what fields should be added to the sockaddr_in6 and how they should be interpreted. All of them would get the job done. I think we can proceed to specify the new and improved sockaddr_in6 and leave all the other details of how name resolution works as a TBD. If we wait to figure all the other issues out before we make the change to the sockaddr_in6 then we may not be able to change it at all. We would be forced to invent a new structure because too much code will be in the field. Regardless of how the site-local address debate plays out there are benefits to adding an index of some sort to the sockaddr_in6 to help deal with other flavors of limited scope addresses (node-local, link-local, site-local, org- local). > Do you believe we need site local addresses for IPv6? > Net 10 has been useful in IPv4. It just isn't clear to me that we need nodes to be the boundary between sites. More accurately it is not clear that we need it bad enough for us to solve all the other problems presented by allowing site boundaries to bisect nodes. > > We need the index and most likely we will be forced to add the site to > sockaddr_in6. But before we change the struct I would like to believe > all realize what we are doing here and in the case of site we are > walking down a dark alley with no clarity IMO. > Agreed. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 7 22:37:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id WAA16168 for ipng-dist; Tue, 7 Apr 1998 22:30:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id WAA16161 for ; Tue, 7 Apr 1998 22:30:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA09879 for ; Tue, 7 Apr 1998 22:30:39 -0700 Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id WAA17726 for ; Tue, 7 Apr 1998 22:30:40 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2166.0) id <2PXCJ7V8>; Tue, 7 Apr 1998 22:30:39 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF111251@red-msg-52.dns.microsoft.com> From: Brian Zill To: "'thartric@mentat.com'" , bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5605) Re: Basic Sockets API Date: Tue, 7 Apr 1998 22:30:38 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim wrote: > I am saying based on conversations at the IETF and on this > mail list I am not clear what status "site" has for IPv6. > The impression I got at IETF was that there was general consensus to leave "sites" in the spec, and use the definition Steve Deering originally intended. The rational for the first part of that being that revising the documents once again just to remove something we aren't sure whether we want or not isn't worth it, and the rational for the second part being that things make more sense that way :-). Tim wrote: > The specifications don't appear to make any statement about where site > boundaries reside. From a correctness point of view it doesn't seem > possible > for a single interface to be in multiple sites. Based on discussions > which > have occurred on this list and at IETF it seems that the authors intended > for site boundaries to run through nodes rather than through links. > I've found it helpful to think of a "site" as a collection of one or more (presumably interconnected) links. Just as an interface can only reside on one link, an interface can only reside within one site. Likewise, link-local address are unique only on a particular link, site-local addresses are unique only within a particular site. Etc, etc. This seems fairly intuitive to me, and has the handy quality of appearing to be what Steve intended. > There is lots of work to do to make multi-sited nodes work but at a > minimum > we need to have enough information in the sockaddr_in6 structure to allow > us to disambiguate which site is being referenced by the sin6_addr. > Unless I'm missing something, this same work needs to be done to make multi-homed nodes work (in order to disambiguate which link is being referenced by a link-local address). I don't see where having sites makes anything significantly more complicated. You have to avoid routing site-local packets between sites, which means you need to know for each of your interfaces whether it is in the same/different site as each of the others [1], but other than that I don't see any difference from link-local. > I think we can proceed to specify the new and improved sockaddr_in6 and > leave > all the other details of how name resolution works as a TBD. > I agree. I think it's a separate issue. Back to Jim again: > Do you believe we need site local addresses for IPv6? > "need" is a pretty strong word. There's lots in IPv6 we don't "need" (our critics would claim we don't need IPv6 at all). I believe that (a) site-local addresses don't add any significant complexity over link-local addresses, and (b) there might well be a good use or two for them in the future. Personally, I'm happier including them at their current level of (un)definition than I am some other features, like say, the "Flow Label" field. At worst, we won't use them. Unless someone thinks they add significant complexity beyond what link-local address already require, this issue quickly becomes one of "so what?" --Brian [1] This is the unresolved issue I have with sites. How does one determine which of one's interfaces share a site? At present, this information would appear to need to be manually configured. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 06:05:57 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id GAA17648 for ipng-dist; Wed, 8 Apr 1998 06:00:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id GAA17641 for ; Wed, 8 Apr 1998 06:00:14 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA18193 for ; Wed, 8 Apr 1998 06:00:12 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA26036 for ; Wed, 8 Apr 1998 06:00:12 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id JAA15374; Wed, 8 Apr 1998 09:00:11 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA25134; Wed, 8 Apr 1998 09:00:09 -0400 Message-Id: <199804081300.AA25134@wasted.zk3.dec.com> To: Brian Zill Cc: "'thartric@mentat.com'" , bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5606) Multisited Nodes.. Date: Wed, 08 Apr 1998 09:00:09 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I changed the subject to Multisited Nodes from: Subject: Re: (IPng 5604) Re: Basic Sockets API First.. We have two ISPs deploying IPv6 and will be using the flow label and I can't reveal them at this time so no one ask me. Also RSVP over IPv6 we are going to deploy and the Flow Label is being used by customers for Intranet QOS via IPv6. So I strongly don't agree with your statement about the use of the IPv6 Flow Label.. It is very important to IPv6.. Here is the issue for Multistited Nodes. 1. It is not like link-local addresses. These are needed for the new IPv6 paradigm so a node has an IP address when it boots. This has great benefit to start plug and play and eliminates BOOTP to do this. One does have to differentiate in the routing table the indices for LL addresses but that is a no brainer once you change your datastructures and so far as best we can tell has no performance hit as a Host or Router on Digital UNIX. 2. The issue for Multisited nodes are not at the API or kernel boundary we can add any changes for sockaddr_in6 to these boundaries, but depending on how you implemented IPv6 the changes will be significant. 3. One issue is the client resolvers and DNS servers. Which site does an AAAA Site-Local Address belong too? How is the index and site identifier stored in the DNS? This issue has not been resolved. 4. As far as Net 10 support we don't need site-local addresses for this reason. We can use defined IPv6 addresses just like IPv4 does today. 5. Two-Faced DNS is not resolved as an implementation. There are some DNS implementations playing with this now but it is not clear how this works. 6. Adding site identifier to the decision process for routing adds additional overhead to route lookups too. This has a cost for scalabiility and performance of IPv6. 7. If we change the sockaddr_in6 do we have to solve all problems for multisited nodes before IPv6 is deployed? The answer has to be NO. IPv6 is wanted by the market and ready to be deployed. So do we need to have IPv6 and then IPv6 Part II, supportinng multisite paradigm and other new evolutions to IPv6. If the answer is yes we need to clearly articulate in the WG what is Part I and what is Part II and understand some plan and how the above problems will be resolved. Or IPv6 will face some of the same problems that caused pain for OSI deployment years ago, which some of us lived with.. We need to discuss this as it has a great affect on IPv6 deployment which is in progress right now for several of us at the user and ISV level. Contrary to what some think IPv6 is a done deal for some in the market, not a research activity. Also as Tim brought up we need to be very careful where we draw that line for sites: thru the node or thru the link. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 06:46:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id GAA17733 for ipng-dist; Wed, 8 Apr 1998 06:37:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id GAA17723 for ; Wed, 8 Apr 1998 06:36:45 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA22912 for ; Wed, 8 Apr 1998 06:36:42 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA13584 for ; Wed, 8 Apr 1998 06:36:41 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA23912; Wed, 8 Apr 1998 23:33:13 +1000 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5607) Re: Name lookups on isolated nets. In-Reply-To: A message of "Tue, 07 Apr 1998 12:03:57 -0400." References: <199804071603.AA31524@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Apr 1998 23:33:10 +1000 Message-Id: <14811.892042390@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 07 Apr 1998 12:03:57 -0400 From: bound@zk3.dec.com Message-ID: <199804071603.AA31524@wasted.zk3.dec.com> | I think this is not a good idea. Have you looked at DNS Server code | base for BIND as one example. Yes, but I'm not sure what the relevance is - there is absolutely no suggestion that a DNS server be used (perhaps my language in the previous message wasn't as good as it could be). The only difference between simple "who are you" and "where are you" servers and this suggestion is the format of the bits in the packets on the wire. The suggestion is that we trade off some simplicity in the client (which no longer needs to consider different formats depending on what it needs to know) for a little extra complexity in the server end in unpacking and packing the packet format. | Vendors are not in the business of | developing DNS servers but get them from places like ISC, AIC, etc. | for the most part. Jim, I don't care where you get your code from. Nor does anyone else. | What parts for RFC 1034/1035 would you have the hosts support? Just the packet formats. | In the caes of the dentist office link-local addresses will work fine if | they have no connections. Sure, but you still need some way to translate names to addresses, right? That's what this is all about. | Also site and link-local addresses are not goiing to be stored in the | DNS anyway at this point. Great. I totally support that. But if someone wants to run a private isolated DNS world, and all they have is link or site local addresses, you're not proposing that the DNS implementation forbid their use are you? Not that that is relevant here anyway, because we're not talking about the DNS, just about using DNS format packets. | I would claim this problem is future work for IPv6 if necessary we have | enough now to deploy and I would like to see the Chairs differentiate | the IPv6 work at this point now btw what is needed to deploy in the | market and what is "nice to have". | | I am not even clear this is a nice to have. Is it that you don't want any name to address translation (beyond possibly an /etc/hosts format file that has to eb shipped around) for sites that won't be running DNS servers, or just that you don't like the particular method I have proposed? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 08:28:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id IAA18249 for ipng-dist; Wed, 8 Apr 1998 08:23:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id IAA18242 for ; Wed, 8 Apr 1998 08:23:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA21738 for ; Wed, 8 Apr 1998 08:23:15 -0700 Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA12718 for ; Wed, 8 Apr 1998 08:23:15 -0700 (PDT) Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id IAA04448; Wed, 8 Apr 1998 08:14:16 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id IAA02351; Wed, 8 Apr 1998 08:13:57 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (dhcp139-254 [192.32.139.254]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id LAA23384; Wed, 8 Apr 1998 11:15:16 -0400 for Message-Id: <199804081515.LAA23384@pobox.engeast.BayNetworks.COM> X-Sender: dhaskin@pobox X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.323 (Beta) Date: Wed, 08 Apr 1998 11:15:03 -0400 To: thartric@mentat.com (Tim Hartrick) From: Dimitry Haskin Subject: (IPng 5608) Re: Basic Sockets API Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <199804080129.SAA10448@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:29 PM 4/7/98 -0700, Tim Hartrick wrote: > >The specifications don't appear to make any statement about where site >boundaries reside. From a correctness point of view it doesn't seem possible >for a single interface to be in multiple sites. Based on discussions which >have occurred on this list and at IETF it seems that the authors intended >for site boundaries to run through nodes rather than through links. > >This choice of boundaries significantly complicates an implementation since >it requires additional qualification in routing tables, API's, DNS lookups, >etc. in order to disambiguate which site is being referenced by an address >or a name. > I can't speak for host implementation, but I definitely would not hold my breath waiting for the multi-sited router implementations any soon. I've been holding view that it is most practical to align site boundaries with the intra-domain routing boundaries. That is, an IGP interface scope defines the corresponding site boundary. Inter-domain routing is used to connect different sites. At least I can see how sites can be implemented and made useful with this simple approach. _______________________________________________________ Dimitry Haskin Bay Networks, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 08:29:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id IAA18258 for ipng-dist; Wed, 8 Apr 1998 08:26:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id IAA18251 for ; Wed, 8 Apr 1998 08:26:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA22398 for ; Wed, 8 Apr 1998 08:26:14 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA14556 for ; Wed, 8 Apr 1998 08:26:13 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id LAA15492; Wed, 8 Apr 1998 11:26:11 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id LAA19884; Wed, 8 Apr 1998 11:26:10 -0400 (EDT) Date: Wed, 8 Apr 1998 11:26:10 -0400 (EDT) From: Christian Huitema Message-Id: <980408112610.ZM19882@seawind.bellcore.com> In-Reply-To: bound@zk3.dec.com "(IPng 5606) Multisited Nodes.." (Apr 8, 9:00am) References: <199804081300.AA25134@wasted.zk3.dec.com> X-Mailer: Z-Mail (5.0.0 30July97) To: bound@zk3.dec.com, Brian Zill Subject: (IPng 5609) Re: Multisited Nodes.. Cc: "'thartric@mentat.com'" , ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Lets beat this horse until it dies. Scoped address are a bad idea. What this discussion showed is that kernel implementors need serious work to make themm behave properly, that applications are likely to be mightily confused (third party TCP using site local) and that poor concepts, when let loose, acquire their own momentum (net 10). I suggest that we restrict the use of scoped addresses by applications to the following cases: 1) link local addresses in unconnected links, 2) site local addresses in unconnected sites. The advantage of restriction (2) is that, by definition, a router cannot belong to two unconnected sites. This should remove a couple of amuzing implementation details, let alone field debugging calls. It also draws a clear picture on"how to connect a site:" 1) initially, in non connected mode, the administrators let routers or DHCP server hand out site local prefixes. The local non connected DNS uses the new AAAA record, pointing to a domain prefix set to "site local." 2) When the site acquires a valid address, routers and DHCP servers deprecate the site local address, and announce the global prefix instead. The domain prefix, in the DNS, is updated; the site local information is rmoved, replaced by the global prefix. 3) The site can now be connected to the Internet, or to another site. Note that this does no remove the concept of a site, which we still use for scoping multicast addresses. Site boundaries typically passe through routers, which have to implement multicast routing filters. It only remove the potential landmines associated to ambiguous addresses. In order to make this proposal acceptable, we need to somehow placate the net 10 followers. I think that the easiest way to do it is to create a class of "IPv6 non aggregatable unicast addresses" which essentially wil hand out flat /48 prefixes, guarantied unique and also guaranteed unroutable (i.e. not acceptable in the backbone). -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 08:44:48 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id IAA18326 for ipng-dist; Wed, 8 Apr 1998 08:38:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id IAA18319 for ; Wed, 8 Apr 1998 08:37:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA24901 for ; Wed, 8 Apr 1998 08:37:52 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA21722 for ; Wed, 8 Apr 1998 08:37:38 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id LAA16007; Wed, 8 Apr 1998 11:37:32 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id LAA19896; Wed, 8 Apr 1998 11:37:32 -0400 (EDT) Date: Wed, 8 Apr 1998 11:37:32 -0400 (EDT) From: Christian Huitema Message-Id: <980408113731.ZM19894@seawind.bellcore.com> In-Reply-To: Robert Elz "(IPng 5607) Re: Name lookups on isolated nets." (Apr 8, 11:33pm) References: <199804071603.AA31524@wasted.zk3.dec.com> <14811.892042390@munnari.OZ.AU> X-Mailer: Z-Mail (5.0.0 30July97) To: Robert Elz , bound@zk3.dec.com Subject: (IPng 5610) Re: Name lookups on isolated nets. Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I think that KRE is right. Focusing on a "distributed DNS server" has a lot of advantages, and not that much cost. First, the complexity is equivalent to that of a simple resolver, not that of a server. There is no requirement to permanently store any data. (except, obviously, the station's name and address). Second, the service can be very easily extended to provide for automatic DNS service discovery. For example, if a station knows that there is a DNS server somewhere, it can return the name server records for the local domain in the DNS packet. This means that the next request will not use broadcast, but rather natural unicast DNS... -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 09:23:01 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA18667 for ipng-dist; Wed, 8 Apr 1998 09:17:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id JAA18659 for ; Wed, 8 Apr 1998 09:17:00 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA03615 for ; Wed, 8 Apr 1998 09:16:58 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA17010 for ; Wed, 8 Apr 1998 09:16:58 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id MAA40610; Wed, 8 Apr 1998 12:16:37 -0400 (EDT) Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA34110; Wed, 8 Apr 1998 12:16:37 -0400 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16080; Wed, 8 Apr 1998 12:16:38 -0400 Message-Id: <352BA2E6.F2232DCC@raleigh.ibm.com> Date: Wed, 08 Apr 1998 12:16:38 -0400 From: Brian Haberman Organization: IBM Network Hardware Division X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: Christian Huitema Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5611) Re: Multisited Nodes.. References: <199804081300.AA25134@wasted.zk3.dec.com> <980408112610.ZM19882@seawind.bellcore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema wrote: > > 2) When the site acquires a valid address, routers and DHCP servers > deprecate the site local address, and announce the global > prefix instead. The domain prefix, in the DNS, is updated; the > site local information is rmoved, replaced by the global prefix. > Christian, Are you suggesting that routers now advertise the site local prefix? If so, I would assume they would advertise a prefix of FEC0::XXXX/64 where XXXX is the 16 bit subnet id. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 09:36:23 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA18789 for ipng-dist; Wed, 8 Apr 1998 09:28:14 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id JAA18782 for ; Wed, 8 Apr 1998 09:28:05 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA06569 for ; Wed, 8 Apr 1998 09:28:00 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA24306 for ; Wed, 8 Apr 1998 09:28:00 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id MAA18047; Wed, 8 Apr 1998 12:27:55 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id MAA19935; Wed, 8 Apr 1998 12:27:55 -0400 (EDT) Date: Wed, 8 Apr 1998 12:27:55 -0400 (EDT) From: Christian Huitema Message-Id: <980408122754.ZM19933@seawind.bellcore.com> In-Reply-To: Brian Haberman "Re: (IPng 5609) Re: Multisited Nodes.." (Apr 8, 12:16pm) References: <199804081300.AA25134@wasted.zk3.dec.com> <980408112610.ZM19882@seawind.bellcore.com> <352BA2E6.F2232DCC@raleigh.ibm.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Brian Haberman , Christian Huitema Subject: (IPng 5612) Re: Multisited Nodes.. Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Apr 8, 12:16pm, Brian Haberman wrote: > > > > Christian, > Are you suggesting that routers now advertise the site local > prefix? If so, I would assume they would advertise a prefix of > FEC0::XXXX/64 where XXXX is the 16 bit subnet id. Yes. Which means that the site local address would be configured in exactly the same way as any other address. That would certainly be the simplest solution. And a good rule, in case of uncertainties, is to look for simplicity. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 09:51:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id JAA18982 for ipng-dist; Wed, 8 Apr 1998 09:45:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id JAA18975 for ; Wed, 8 Apr 1998 09:45:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA11101 for ; Wed, 8 Apr 1998 09:45:29 -0700 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id JAA05391 for ; Wed, 8 Apr 1998 09:45:29 -0700 (PDT) From: Margaret Wasserman To: huitema@bellcore.com CC: bound@zk3.dec.com, bzill@microsoft.com, thartric@mentat.com, ipng@sunroof.eng.sun.com In-reply-to: <980408112610.ZM19882@seawind.bellcore.com> (message from Christian Huitema on Wed, 8 Apr 1998 11:26:10 -0400 (EDT)) Subject: (IPng 5613) Re: Multisited Nodes.. Date: Wed, 8 Apr 98 12:45:10 -0400 Message-ID: <9804081245.aa23253@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Scoped address are a bad idea. I must, ultimately, agree with this statement. Scoped addressing is a clever idea with some interesting advantages, but using multiple address scopes simultaneously on the same interface introduces a number of serious problems. >I suggest that we restrict the use of scoped addresses by applications >to the following cases: > >1) link local addresses in unconnected links, > >2) site local addresses in unconnected sites. Restriction #2 is fairly easy to swallow, since the advantages of site- local addressing remain more theoretical then practical. As far as I know, most of us haven't really implemented all of the ins- and-outs of site-local addressing, anyway (especially since the ins-and-outs haven't been fully defined). Restriction #1 may be more difficult to sell, though. Would this mean that hosts would no longer use link-local addressing to communicate with locally attached routers once they have discovered a local router and a site and/or global prefix has been obtained? This would require non-trivial changes to ND, correct? There seems to be some belief that site-local addresses are a bad idea, but that link-local addresses are okay. However, as I've tried to put forth in my previous mail, I believe that there are also significant problems with having both link-local and global addresses associated with the same interface. These problems all reduce to the lack of ability to convert between the address of different scopes and a lack of non-ambiguous node/interface identification. Apparently, some folks have taken the position that it is allowable to convert a link-local address to global address by chopping off the first 64 bits and attaching a global prefix (Both the Mobile IPv6 folks and Jim Bound are doing this in their implementations, I believe based on their statements at the Monday LA IETF meeting). Presumably, the same folks also think it would be reasonable to convert in the opposite direction (chop off the global prefix and add the link-local prefix when a node's global prefix, including SLA, matches your own)? The "safety" of performing these conversions relies upon the idea that there will be a one-to-one correspondence between link-local addresses and global addresses and that the correspondence exists solely in the token portions of the addresses. If we want to retain both link-local and global addressing simultaneously (and thus ignore your restriction #1), it might be possible to do so with the restriction that the link-local and global addresses must have this sort of one-to-one correspondence. I'm not sure, though, that this could be made to interact properly with either manual or server-based (DHCPv6) configuration. >Note that this does no remove the concept of a site, which we still >use for scoping multicast addresses. Site boundaries typically >passe through routers, which have to implement multicast routing >filters. It only remove the potential landmines associated to >ambiguous addresses. You don't explicitly state that the restrictions above do not apply to scoped multicast addresses, but this strongly implies that scoped multicast addresses would continue to exist. I hope that is your intention, as I consider scoped multicast addresses a separate issue (and a good thing, in general). Is it really possible to make this sort of change (adding these restrictions to the use of scoped addressing) without changing the existing specifications (base spec, addr arch, ND, etc.)? If not, do you think these changes would send the specs back to the beginning of the standards-track? Or, could they go forward from here? I think that we need to resolve (one way or the other) the scoped addressing issue before it makes any sense to advance these specs to draft-standard. Right now, we'd be in the position of trying to advance something we know has at least one serious unresolved flaw that will probably result in substantive changes to the specifications. But, there does not seem to be consensus that it is acceptable to make major changes to these specs this late in the process. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 10:26:33 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id KAA19215 for ipng-dist; Wed, 8 Apr 1998 10:19:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id KAA19208 for ; Wed, 8 Apr 1998 10:19:28 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA21195 for ; Wed, 8 Apr 1998 10:19:25 -0700 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA28076 for ; Wed, 8 Apr 1998 10:19:26 -0700 (PDT) From: Margaret Wasserman To: huitema@bellcore.com CC: kre@munnari.oz.au, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-reply-to: <980408113731.ZM19894@seawind.bellcore.com> (message from Christian Huitema on Wed, 8 Apr 1998 11:37:32 -0400 (EDT)) Subject: (IPng 5614) Re: Name lookups on isolated nets. Date: Wed, 8 Apr 98 13:19:13 -0400 Message-ID: <9804081319.aa23604@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Jim, I think that KRE is right. Focusing on a "distributed DNS >server" has a lot of advantages, and not that much cost. I think the idea of a distributed DNS server as KRE described is interesting, but I don't think it makes sense to require all IPv6 implementations/nodes to support this. I also don't see this as a particularly IPv6-specific mechanism. I think discussion of this type of mechanism falls outside the scope of the IPng WG. Maybe it should be brought up in a DNS working group or a BOF? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 11:34:17 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id LAA19780 for ipng-dist; Wed, 8 Apr 1998 11:23:37 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id LAA19773 for ; Wed, 8 Apr 1998 11:23:27 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA12461 for ; Wed, 8 Apr 1998 11:23:24 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA11031 for ; Wed, 8 Apr 1998 11:23:22 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id OAA29791; Wed, 8 Apr 1998 14:23:17 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22313; Wed, 8 Apr 1998 14:23:01 -0400 Message-Id: <199804081823.AA22313@wasted.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5615) Re: Name lookups on isolated nets. In-Reply-To: Your message of "Wed, 08 Apr 1998 23:33:10 +1000." <14811.892042390@munnari.OZ.AU> Date: Wed, 08 Apr 1998 14:23:01 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, Changed my mind this is a good idea. I read too much into your mail. | I think this is not a good idea. Have you looked at DNS Server code | base for BIND as one example. >Yes, but I'm not sure what the relevance is - there is absolutely no >suggestion that a DNS server be used (perhaps my language in the previous >message wasn't as good as it could be). The only difference between >simple "who are you" and "where are you" servers and this suggestion is >the format of the bits in the packets on the wire. The suggestion is that >we trade off some simplicity in the client (which no longer needs to consider >different formats depending on what it needs to know) for a little extra >complexity in the server end in unpacking and packing the packet format. Yep. That is what I read too much into. | Vendors are not in the business of | developing DNS servers but get them from places like ISC, AIC, etc. | for the most part. >Jim, I don't care where you get your code from. Nor does anyone else. Hmm let me say it a different way. In the IETF we have to consider "cost" and "compatibility" with any std. Most vendors don't eng'g DNS they use ISC's BIND. So to get changes in ISC BIND requires some cost and working with a keeper of the BIND code. I was really pointing to that how much work is really here and is it worth updating everyones DNS that uses BIND. That I do believe must be a consideration when considering messging with DNS. So I do think other vendors do care about this so your Nor does anyone else sentence should not encompass "ALL". | What parts for RFC 1034/1035 would you have the hosts support? >Just the packet formats. This is what I was not sure about either. | In the caes of the dentist office link-local addresses will work fine if | they have no connections. >Sure, but you still need some way to translate names to addresses, right? >That's what this is all about. OK. | Also site and link-local addresses are not goiing to be stored in the | DNS anyway at this point. >Great. I totally support that. But if someone wants to run a private >isolated DNS world, and all they have is link or site local addresses, you're >not proposing that the DNS implementation forbid their use are you? No. >Not that that is relevant here anyway, because we're not talking about the >DNS, just about using DNS format packets. I was assuming they would be AAAA records of some extended format. But this is not the case. | I would claim this problem is future work for IPv6 if necessary we have | enough now to deploy and I would like to see the Chairs differentiate | the IPv6 work at this point now btw what is needed to deploy in the | market and what is "nice to have". | | I am not even clear this is a nice to have. >Is it that you don't want any name to address translation (beyond possibly >an /etc/hosts format file that has to eb shipped around) for sites that won't >be running DNS servers, or just that you don't like the particular method I >have proposed? I was concerned that implementing a full blow DNS server on each client was overkill but that is not what your proposing, and now I think your idea is a good one. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 11:34:17 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id LAA19802 for ipng-dist; Wed, 8 Apr 1998 11:25:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id LAA19784 for ; Wed, 8 Apr 1998 11:24:31 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA12848 for ; Wed, 8 Apr 1998 11:24:25 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA11845 for ; Wed, 8 Apr 1998 11:24:26 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id OAA32166; Wed, 8 Apr 1998 14:24:16 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22225; Wed, 8 Apr 1998 14:24:14 -0400 Message-Id: <199804081824.AA22225@wasted.zk3.dec.com> To: Christian Huitema Cc: bound@zk3.dec.com, Brian Zill , "'thartric@mentat.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 5616) Re: Multisited Nodes.. In-Reply-To: Your message of "Wed, 08 Apr 1998 11:26:10 EDT." <980408112610.ZM19882@seawind.bellcore.com> Date: Wed, 08 Apr 1998 14:24:14 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, This is really good. If we could do this I think that would be great. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 11:34:19 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id LAA19831 for ipng-dist; Wed, 8 Apr 1998 11:27:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id LAA19824 for ; Wed, 8 Apr 1998 11:27:16 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA13722 for ; Wed, 8 Apr 1998 11:27:11 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA13749 for ; Wed, 8 Apr 1998 11:27:08 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id OAA11733; Wed, 8 Apr 1998 14:27:03 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22196; Wed, 8 Apr 1998 14:27:03 -0400 Message-Id: <199804081827.AA22196@wasted.zk3.dec.com> To: Christian Huitema Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: (IPng 5617) Re: Name lookups on isolated nets. In-Reply-To: Your message of "Wed, 08 Apr 1998 11:37:32 EDT." <980408113731.ZM19894@seawind.bellcore.com> Date: Wed, 08 Apr 1998 14:27:03 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, I agree and just sent KRE that I read too much into his mail. I agree seems like a good idea and look forward to reading and working on KRE's idea/draft as WG member. I like the idea of distributed DNS too and auto DNS discovery. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 11:50:39 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id LAA20111 for ipng-dist; Wed, 8 Apr 1998 11:45:42 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id LAA20104 for ; Wed, 8 Apr 1998 11:45:31 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id LAA23089; Wed, 8 Apr 1998 11:45:25 -0700 (PDT) Date: Wed, 8 Apr 1998 11:45:17 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5618) Re: Multisited Nodes.. To: Margaret Wasserman Cc: huitema@bellcore.com, bound@zk3.dec.com, bzill@microsoft.com, thartric@mentat.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <9804081245.aa23253@khitomer.epilogue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Apparently, some folks have taken the position that it is allowable to > convert a link-local address to global address by chopping off the > first 64 bits and attaching a global prefix (Both the Mobile IPv6 > folks and Jim Bound are doing this in their implementations, I believe > based on their statements at the Monday LA IETF meeting). Presumably, > the same folks also think it would be reasonable to convert in the > opposite direction (chop off the global prefix and add the link-local > prefix when a node's global prefix, including SLA, matches your own)? I don't recall Jim's comment. I view the mobile-IPv6 discussion as an "interesting" discussion that will lead to a robust mechanism to determine all addresses of a router/home agent without any creative address chopping and reconstrunction. Watch for the next mobile IPv6 draft. (The current idea is to use a bit in the prefix options in ND to allow routers to advertise their other addresses for use by mobile IP.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 12:13:03 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA20402 for ipng-dist; Wed, 8 Apr 1998 12:05:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA20393 for ; Wed, 8 Apr 1998 12:05:45 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA26332 for ; Wed, 8 Apr 1998 12:05:41 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA09894 for ; Wed, 8 Apr 1998 12:05:38 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA25994; Wed, 8 Apr 1998 14:04:53 -0500 Message-Id: <199804081904.OAA25994@gungnir.fnal.gov> To: Christian Huitema Cc: Brian Haberman , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5619) Re: Multisited Nodes.. In-reply-to: Your message of Wed, 08 Apr 1998 12:27:55 EDT. <980408122754.ZM19933@seawind.bellcore.com> Date: Wed, 08 Apr 1998 14:04:53 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Apr 8, 12:16pm, Brian Haberman wrote: > > Christian, > > Are you suggesting that routers now advertise the site local > > prefix? If so, I would assume they would advertise a prefix of > > FEC0::XXXX/64 where XXXX is the 16 bit subnet id. > > Yes. Which means that the site local address would be configured in exactly > the same way as any other address. This should not be news. -discovery-v2-02 makes no special mention of site-local addresses. Only the link-local prefix SHOULD NOT be advertised. Question for Christian: do you put no value on the long term survival of site-internal sessions across renumbering (and inital global numbering)? That's one of the arguments put forward for site-local addresses, if the selection problem can be solved. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 12:22:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA20504 for ipng-dist; Wed, 8 Apr 1998 12:13:46 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA20497 for ; Wed, 8 Apr 1998 12:13:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA28770 for ; Wed, 8 Apr 1998 12:13:34 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA15183 for ; Wed, 8 Apr 1998 12:13:30 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id PAA24798; Wed, 8 Apr 1998 15:13:28 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id PAA20160; Wed, 8 Apr 1998 15:13:27 -0400 (EDT) Date: Wed, 8 Apr 1998 15:13:27 -0400 (EDT) From: Christian Huitema Message-Id: <980408151327.ZM20158@seawind.bellcore.com> In-Reply-To: "Matt Crawford" "Re: (IPng 5612) Re: Multisited Nodes.." (Apr 8, 2:04pm) References: <199804081904.OAA25994@gungnir.fnal.gov> X-Mailer: Z-Mail (5.0.0 30July97) To: "Matt Crawford" , Christian Huitema Subject: (IPng 5620) Re: Multisited Nodes.. Cc: Brian Haberman , ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 1) in response to Margaret, I would like to discourage the use of link local addresses by *applications*, not by kernel-level maintenance procedures such as neighbor discovery (or routing protocols). The only way an application could possibly learn about a LL address is because someone is running a mock-dns (where-are-you) on an isolated link. 2) in response to Matt, no I don't see much value to the "TCP survives renumbering" argument. First, modifying TCP is easy, and has in fact been already implemented at UCLA based on a draft I wrote 3 years ago. Second, if that was a problem, "noin agregatable unicast addresses" would provide a much better solution than site-local addresses. I suggest that people look at the draft that Bob Moskowitz just put up on a related IPv4 issue (the draft is called something like net 66). -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 12:29:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA20625 for ipng-dist; Wed, 8 Apr 1998 12:19:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA20618 for ; Wed, 8 Apr 1998 12:19:47 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA00567 for ; Wed, 8 Apr 1998 12:19:43 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA19081 for ; Wed, 8 Apr 1998 12:19:44 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA00231; Wed, 8 Apr 98 12:16:22 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA11539; Wed, 8 Apr 1998 12:21:13 -0700 Date: Wed, 8 Apr 1998 12:21:13 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804081921.MAA11539@feller.mentat.com> To: mrf@epilogue.com, huitema@bellcore.com Subject: (IPng 5622) Re: Multisited Nodes.. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, Christian, > > >Scoped address are a bad idea. > > I must, ultimately, agree with this statement. > They certainly make life where I live interesting. They do have some good properties. > Scoped addressing is a clever idea with some interesting advantages, > but using multiple address scopes simultaneously on the same interface > introduces a number of serious problems. > > >I suggest that we restrict the use of scoped addresses by applications > >to the following cases: > > > >1) link local addresses in unconnected links, > > > >2) site local addresses in unconnected sites. > > Restriction #2 is fairly easy to swallow, since the advantages of > site- local addressing remain more theoretical then practical. As far > as I know, most of us haven't really implemented all of the ins- > and-outs of site-local addressing, anyway (especially since the > ins-and-outs haven't been fully defined). > Very easy to swallow. It makes them equivalent to Net 10. Easy to understand, easy to implement. > Restriction #1 may be more difficult to sell, though. Would this mean > that hosts would no longer use link-local addressing to communicate > with locally attached routers once they have discovered a local router > and a site and/or global prefix has been obtained? This would require > non-trivial changes to ND, correct? > > There seems to be some belief that site-local addresses are a bad > idea, but that link-local addresses are okay. However, as I've tried > to put forth in my previous mail, I believe that there are also > significant problems with having both link-local and global addresses > associated with the same interface. These problems all reduce to the > lack of ability to convert between the address of different scopes and > a lack of non-ambiguous node/interface identification. > The problems of scoped addresses are not related to their scope. Link-local addresses have exactly the same problems that site-local addresses have. The only difference is that we have found that link-local addresses have some immediate utility for ND and other functions and implementors have worked around some of the problems because they had to. > > >Note that this does no remove the concept of a site, which we still > >use for scoping multicast addresses. Site boundaries typically > >passe through routers, which have to implement multicast routing > >filters. It only remove the potential landmines associated to > >ambiguous addresses. > > You don't explicitly state that the restrictions above do not > apply to scoped multicast addresses, but this strongly implies > that scoped multicast addresses would continue to exist. I > hope that is your intention, as I consider scoped multicast > addresses a separate issue (and a good thing, in general). > Unfortunately, scoped multicast addresses have the same properties that scoped unicast addresses possess. That is, if we define a site or organizational boundary such that it passes through a node then the meaning of a site-local or org-local multicast address will be ambiguous on a node which is sitting at the boundary. The ambiguity could become even richer because the source addresses used in the datagrams could also be of limited scope. Such a node will require additional complexity in its multicast routing protocols, multicast applications and API's to handle the ambiguity associated with addresses. The problems are probably solvable but we have to be getting something in return for solving the problems right now. It just seems easier, at least for the time being, to say that a node can only be part of a single site or organization and leave it at that. That leaves us with only needing to solve the problem of multi-homed hosts and link-local multicast and unicast addresses which is a problem that most implementors have already had to solve in one way or another. With some minor tweaks to the sockets API and maybe the resolver API we can make the problem a little easier to solve for the implementors and the application writers and leave space for the possibility that a multi-homed, multi-sited, multi- organizationed node may be of utility in the future. > Is it really possible to make this sort of change (adding these > restrictions to the use of scoped addressing) without changing the > existing specifications (base spec, addr arch, ND, etc.)? If not, do > you think these changes would send the specs back to the beginning of > the standards-track? Or, could they go forward from here? > I don't see how address scoping could be expunged from the architecture without sending everything back to the beginning. That would be bad and I don't think it is necessary. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 12:29:09 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id MAA20605 for ipng-dist; Wed, 8 Apr 1998 12:19:06 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id MAA20598 for ; Wed, 8 Apr 1998 12:18:54 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id MAA27998; Wed, 8 Apr 1998 12:18:49 -0700 (PDT) Date: Wed, 8 Apr 1998 12:18:41 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5621) Re: Multisited Nodes.. To: Christian Huitema , deering@cisco.com, hinden@iprg.nokia.com Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <980408112610.ZM19882@seawind.bellcore.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Lets beat this horse until it dies. > > Scoped address are a bad idea. What this discussion showed is that > kernel implementors need serious work to make themm behave properly, > that applications are likely to be mightily confused (third party > TCP using site local) and that poor concepts, when let loose, acquire > their own momentum (net 10). Christian, I would agree that building an implementation that supports site-local (and link-local) is more complex that implementing IPv6 without either of these scoped addresses. But it is not impossible. (If we do the APIs right (sin6_siteindex + getaddrinfo might be all we need) the applications don't even need to be aware of any of this complexity.) But the question we need to answer is: Do we think that site-local (and link-local) will be useful in the IP protocol over the next 20 years? If the answer is "yes" or even "we don't know for sure but thay might increase the probability of the internet being able to scale (by reducing the (perceived) risk of renumbering sites)" then I personally don't care that it takes more than 5 minutes to implement suport for site-local addresses. Thus I'd argue for a much longer term perspective. A process question: On 3/11 Steve Deering declared: > Well, it does appear that we do not have consensus on deleting site-local > addresses from IPv6. I'd prefer if we don't have to go through this discussion every month so that we can get some other work done. Steve and Bob, How can we resolve this issue? I hear more or less the same arguments repeated over and over again (and end up repeating my own arguments as a result). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 13:16:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id NAA21476 for ipng-dist; Wed, 8 Apr 1998 13:10:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id NAA21469 for ; Wed, 8 Apr 1998 13:10:09 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA13647 for ; Wed, 8 Apr 1998 13:10:08 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA19988 for ; Wed, 8 Apr 1998 13:10:06 -0700 (PDT) Received: by INET-05-IMC with Internet Mail Service (5.5.1960.3) id <2PXHRT64>; Wed, 8 Apr 1998 13:10:06 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81005831FE7@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Christian Huitema'" , Matt Crawford Cc: Brian Haberman , ipng@sunroof.eng.sun.com Subject: (IPng 5623) Re: Multisited Nodes.. Date: Wed, 8 Apr 1998 13:10:02 -0700 X-Mailer: Internet Mail Service (5.5.1960.3) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) in response to Margaret, I would like to discourage the use of > link local addresses by *applications*, not by kernel-level > maintenance procedures such as neighbor discovery (or routing > protocols). The only way an application could possibly learn > about a LL address is because someone is running a mock-dns > (where-are-you) on an isolated link. > [Richard Draves] The line between applications and network maintenance procedures is fuzzy. If there is any use of link-local addresses outside the kernel, and I think there will be, then the APIs need to handle link-local addresses well. > 2) in response to Matt, no I don't see much value to the "TCP > survives renumbering" argument. First, modifying TCP is easy, > and has in fact been already implemented at UCLA based on a > draft I wrote 3 years ago. Second, if that was a problem, > "noin agregatable unicast addresses" would provide a much > better solution than site-local addresses. I suggest that > people look at the draft that Bob Moskowitz just put up on > a related IPv4 issue (the draft is called something like > net 66). > [Richard Draves] Hmm, can you send a pointer to your TCP-survives-renumbering draft? I think the biggest point in favor of site-local addresses is improved renumbering support; if it's easy to get that in other ways then site-local addresses are much less interesting to me. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 14:31:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id OAA22536 for ipng-dist; Wed, 8 Apr 1998 14:26:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id OAA22529 for ; Wed, 8 Apr 1998 14:26:21 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA07977 for ; Wed, 8 Apr 1998 14:26:17 -0700 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA00545 for ; Wed, 8 Apr 1998 14:26:00 -0700 (PDT) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id BAA10675; Thu, 9 Apr 1998 01:13:49 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA23899; Thu, 9 Apr 98 01:13:48+0530 Date: Thu, 9 Apr 1998 01:06:47 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5624) IPv6 Addressing Architecture. To: Matt Crawford Cc: Christian Huitema , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: <199804081904.OAA25994@gungnir.fnal.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All... Can we divide the 128 bit address space as follows : 1. Interface Identifier. - 64 bits. 2. subnet ID - K bits. 3. Area ID. ( Area in the context of OSPF)- L bits. 4. AS ID. - M bits. 5. Level ID - N bits. 6. Format Prefix. - O bits. Where K+L+M+N+Format Prefix = 64 bits. Where the values of K,L,M,N depends on the Internet size. I think this type of assignment will help more in Route Aggregation. Can We do this. With Regards -Raghu. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 14:59:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id OAA22656 for ipng-dist; Wed, 8 Apr 1998 14:54:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id OAA22649 for ; Wed, 8 Apr 1998 14:54:05 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA16947; Wed, 8 Apr 1998 14:54:01 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA27227; Wed, 8 Apr 1998 14:54:01 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id RAA13241; Wed, 8 Apr 1998 17:53:54 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA14794; Wed, 8 Apr 1998 17:53:35 -0400 Message-Id: <199804082153.AA14794@wasted.zk3.dec.com> To: Erik Nordmark Cc: Christian Huitema , deering@cisco.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: (IPng 5625) Re: Multisited Nodes.. In-Reply-To: Your message of "Wed, 08 Apr 1998 12:18:41 PDT." Date: Wed, 08 Apr 1998 17:53:35 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >> Scoped address are a bad idea. What this discussion showed is that >> kernel implementors need serious work to make themm behave properly, >> that applications are likely to be mightily confused (third party >> TCP using site local) and that poor concepts, when let loose, acquire >> their own momentum (net 10). >Christian, >I would agree that building an implementation that supports site-local >(and link-local) is more complex that implementing IPv6 without >>either of these scoped addresses. >But it is not impossible. (If we do the APIs right (sin6_siteindex + >getaddrinfo might be all we need) the applications don't even need to be aware >>of any of this complexity.) It is more than just changing the API which other mail listed. >But the question we need to answer is: Do we think that site-local (and >link-local) will be useful in the IP protocol over the next 20 years? >If the answer is "yes" or even "we don't know for sure but thay might increase >the probability of the internet being able to scale (by reducing the >(perceived) risk of renumbering sites)" then I personally don't care >that it takes more than 5 minutes to implement suport for site-local >addresses. >Thus I'd argue for a much longer term perspective. To change the sockaddr_in6 alone I am sure is more than 5 minutes. But the DNS alone is significant. >A process question: >>On 3/11 Steve Deering declared: >> Well, it does appear that we do not have consensus on deleting site-local >> addresses from IPv6. >I'd prefer if we don't have to go through this discussion every month >so that we can get some other work done. >Steve and Bob, >How can we resolve this issue? I hear more or less the same arguments repeated >over and over again (and end up repeating my own arguments as a result). It is not the same the API change brought all the ugliness of site-local to head. The mail is all new. The issue is duplicated yes, but with new questions, why is that bad? But you do need a different response IMO. Would you rather we do this a last call in the IETF and bring the entire Internet IETF community into the discussion with these issues? Or shut this down and cause an appeal to the IAB? I think not. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 15:30:52 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id PAA22727 for ipng-dist; Wed, 8 Apr 1998 15:24:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id PAA22720 for ; Wed, 8 Apr 1998 15:24:03 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA27187 for ; Wed, 8 Apr 1998 15:23:59 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA14998 for ; Wed, 8 Apr 1998 15:23:48 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id SAA23931; Wed, 8 Apr 1998 18:23:47 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA10272; Wed, 8 Apr 1998 18:23:30 -0400 Message-Id: <199804082223.AA10272@wasted.zk3.dec.com> To: Margaret Wasserman Cc: huitema@bellcore.com, kre@munnari.oz.au, bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5626) Re: Name lookups on isolated nets. In-Reply-To: Your message of "Wed, 08 Apr 1998 13:19:13 EDT." <9804081319.aa23604@khitomer.epilogue.com> Date: Wed, 08 Apr 1998 18:23:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I don't agree ths is an IPng issue and for IPv6 not IPv4. If KRE wants to take it to IPv4 thats cool but IPv4 don't have link-local and site-local addresses. Also if we want this implemented for IPv6 only and fast this is the place to do it. We have IPv6 and DNS experts right here. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 15:46:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id PAA22779 for ipng-dist; Wed, 8 Apr 1998 15:41:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id PAA22772 for ; Wed, 8 Apr 1998 15:41:22 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA03551 for ; Wed, 8 Apr 1998 15:41:17 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA25002 for ; Wed, 8 Apr 1998 15:41:11 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id SAA02951; Wed, 8 Apr 1998 18:41:09 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id SAA20314; Wed, 8 Apr 1998 18:41:08 -0400 (EDT) Date: Wed, 8 Apr 1998 18:41:08 -0400 (EDT) From: Christian Huitema Message-Id: <980408184108.ZM20312@seawind.bellcore.com> In-Reply-To: Richard Draves "RE: (IPng 5620) Re: Multisited Nodes.." (Apr 8, 1:10pm) References: <4D0A23B3F74DD111ACCD00805F31D81005831FE7@red-msg-50.dns.microsoft.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Richard Draves , "'Christian Huitema'" , Matt Crawford Subject: (IPng 5627) Re: Multisited Nodes.. Cc: Brian Haberman , ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The TCP survives renumbering draft is available, together with an implementation report, at http://www.chem.ucla.edu/~beichuan/etcp/ and http://www.chem.ucla.edu/~beichuan/etcp/huitema-TCP.txt One of the author of the implementation, Irene Wu, is working with Lixia Wang on an improved version of this draft. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 16:06:26 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id QAA22881 for ipng-dist; Wed, 8 Apr 1998 16:01:32 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA22874 for ; Wed, 8 Apr 1998 16:01:21 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id QAA03069; Wed, 8 Apr 1998 16:01:17 -0700 (PDT) Date: Wed, 8 Apr 1998 16:01:10 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5628) Re: Multisited Nodes.. To: bound@zk3.dec.com Cc: Brian Zill , "'thartric@mentat.com'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199804081300.AA25134@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Here is the issue for Multistited Nodes. > > 1. It is not like link-local addresses. These are needed for the new IPv6 > paradigm so a node has an IP address when it boots. This has great > benefit to start plug and play and eliminates BOOTP to do this. One does > have to differentiate in the routing table the indices for LL addresses > but that is a no brainer once you change your datastructures and so far > as best we can tell has no performance hit as a Host or Router on > Digital UNIX. As far as I can tell I can implement support for site indicies in the sockaddr_in6 without adding any performance hit on a host or router doing routing table lookups for global addresses. For site-local destinations it would be a few instructions more (in order to compare the site index). > 2. The issue for Multisited nodes are not at the API or kernel boundary > we can add any changes for sockaddr_in6 to these boundaries, but > depending on how you implemented IPv6 the changes will be significant. I don't disagree. But if site-local addresses offer significant renumbering benefits for the users of IPv6 the engineer cost of implementation is likely to be small in comparison. However, the user benefits would be spread out over the next 20 years thus there are some business tradeoffs on when to implement it. All I'm arguing for is that we should make the protocol and API standards so that it is possible for an implementor that so disires to (at the implementor's own schedule) to build a box that can function at a site boundary. > 3. One issue is the client resolvers and DNS servers. Which site > does an AAAA Site-Local Address belong too? How is the index and site > identifier stored in the DNS? This issue has not been resolved. I have some ideas which will be in an updated version of -ipngwg-site-prefixes-. I don't recall if I've outlined this on the mailing list. The idea (wait for the draft for further details) is that when a node retrieves the AAAA RRset from the DNS it would ignore any site-local addresses unless 1. There are no global addresses in the RRset (e.g. when the site is not connected to the Internet), or 2. One or more of the global addresses in the RRset matches one of the site prefixes that are advertised in router advertisements as specified in draft-ietf-ipngwg-site-prefixes-01.txt This allows us to store site-local addresses in the DNS without having a two-faced DNS but those addresses will only be used for communication by the nodes that know they are in the same site. This just requires some additional filtering in the resolver (similar in nature to filtering required to implement the AI_ADDRCONFIG flag). > 4. As far as Net 10 support we don't need site-local addresses for this > reason. We can use defined IPv6 addresses just like IPv4 does today. Depends how such a "Net 10 equivalent" will be used in IPv6. One danger is that such a "net 10" will paint ourselves in proverbial corner and end up with v6-v6 NAT boxes for the forseable future. That would be unfortunate since it would prevent us from getting end-end IPsec. > 5. Two-Faced DNS is not resolved as an implementation. There are some > DNS implementations playing with this now but it is not clear how this > works. As I can above it can be designed to not require a two-faced DNS. > 6. Adding site identifier to the decision process for routing adds > additional overhead to route lookups too. This has a cost for > scalabiility and performance of IPv6. It *potentially* adds overhead when forwarding packets destined to site-local addresses. However, while I don't build high-performance routers, I think most high-performance routers have a route cache per interface. This can be used to remove any overhead for site-local forwarding: E.g. if eth1 and eth3 is in the blue site and eth5 is in the red site the route cache for eth1 and eth3 would contain the site-local routes for the blue site. Thus there would not be any extra check needed in the fast path to handle the site boundary in a router that has per interface route caches. > 7. If we change the sockaddr_in6 do we have to solve all problems for > multisited nodes before IPv6 is deployed? The answer has to be NO. > IPv6 is wanted by the market and ready to be deployed. So do we need to > have IPv6 and then IPv6 Part II, supportinng multisite paradigm and > other new evolutions to IPv6. If the answer is yes we need to clearly > articulate in the WG what is Part I and what is Part II and understand > some plan and how the above problems will be resolved. Or IPv6 will > face some of the same problems that caused pain for OSI deployment years > ago, which some of us lived with.. I agree we need to start deploying IPv6. You can view adding the sin6_siteindex as risk management: If we add it now it will be a lot easier to move to building boxes that can live at the site boundary when and if we will take such a step. If it turns out that we decide that site-local addresses don't make sense (and we remove them from IPv6) we will have wasted 4 bytes of memory in every application but that is the only downside. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 16:29:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id QAA22971 for ipng-dist; Wed, 8 Apr 1998 16:24:38 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id QAA22964 for ; Wed, 8 Apr 1998 16:24:27 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id QAA06662; Wed, 8 Apr 1998 16:24:20 -0700 (PDT) Date: Wed, 8 Apr 1998 16:24:13 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5629) Re: Multisited Nodes.. To: bound@zk3.dec.com Cc: Erik Nordmark , Christian Huitema , deering@cisco.com, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199804082153.AA14794@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It is more than just changing the API which other mail listed. For an implementation of the protocol stack and DNS etc there is a lot more work than the API - I agree completely. But I was responding to Christian's concern about the applications needing to support site-local addresses and site indicies and I would argue that if we add sin6_siteindex and the applications use getaddrinfo() (as opposed to getnodebyname(), see below) it can be implemented by the resolver and the protocol stack so that the application can transparently work on a multisited node: The application calls getaddrinfo() which returns a sockaddr_in6. getaddrinfo() may or may not have set sin6_siteindex to a non-zero value - the application doesn't care. The application calls connect/sendto/sendmsg passing the sockaddr_in6. If the sin6_siteindex is non-zero and the destination is site-local then the stack will compare site indicies when doing the routing lookup. Note that getnodbyname doesn't work here since it only returns the 128 bit IPv6 address and not a whole sockaddr_in6. Note2: It could even be possible to implement this without adding sin6_siteindex to the API since an implementation is free to add other (hidden) fields to the sockaddr_in6 structure (see section 2.4 in the basic API). > > [...] > the >(perceived) risk of renumbering sites)" then I personally don't care > >that it takes more than 5 minutes to implement suport for site-local > >addresses. > >Thus I'd argue for a much longer term perspective. > > To change the sockaddr_in6 alone I am sure is more than 5 minutes. But > the DNS alone is significant. I said it was "more than 5 minutes" - I didn't say e.g. that it is exactly 5 minutes or e.g. less than 1 staff year. How much more than 5 minutes is a open question that would depend on the implementation. > >Steve and Bob, > >How can we resolve this issue? I hear more or less the same arguments > repeated >over and over again (and end up repeating my own arguments as a > result). > > It is not the same the API change brought all the ugliness of site-local > to head. The mail is all new. The issue is duplicated yes, but with > new questions, why is that bad? But you do need a different response > IMO. Would you rather we do this a last call in the IETF and bring the > entire Internet IETF community into the discussion with these issues? > Or shut this down and cause an appeal to the IAB? I think not. That was not my intent. My frustration is that 1. We agree that we don't have consensus to remove site-local addresses from the architecture. Implicitly this tells me that it is worth-while for the WG to investigate what it would take to make site-local addresses work so that we have some better basis to determine whether or not the complexity of site-local addresses is worth the benefits. 2. Some of us try to figure out how to make site-local addresses work well by e.g. by Tim proposing API extensions. 3. The proposal is met with a the same arguments ("site local addresses are bad" etc) that lead to #1. Thus we are going around in circles without any apparent progress. To resolve this I'd like to ask if anybody in the WG disagrees with The IPNGWG should investigate (assuming there are volounteers) what it would take to make site-local addresses to work and propose API and protocol extensions to the WG. If we can do this without every email restarting the "site local addresses are bad" debate we can hopefully move forward and a few months from now have more information that can be used to move the WG towards consensus. Comments? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 16:57:10 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id QAA23115 for ipng-dist; Wed, 8 Apr 1998 16:52:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id QAA23108 for ; Wed, 8 Apr 1998 16:52:12 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA25433 for ; Wed, 8 Apr 1998 16:52:10 -0700 Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA02740 for ; Wed, 8 Apr 1998 16:52:09 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2166.0) id <2PXCMP4L>; Wed, 8 Apr 1998 16:52:08 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF111256@red-msg-52.dns.microsoft.com> From: Brian Zill To: "'bound@zk3.dec.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5630) RE: Multisited Nodes.. Date: Wed, 8 Apr 1998 16:49:00 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, Thanks for the detailed reply. > First.. We have two ISPs deploying IPv6 and will be using the flow > label and I can't reveal them at this time so no one ask me. > I don't want to turn this into a discussion on the merits of the flow label. For the record, I'm not against it. My point was that there are parts of the protocol for which the practical usage patterns have yet to be ironed out. That doesn't mean that I can't implement them. My specific comment about the flow label is related to the downside argument: if flow labels never achieve popular use, we waste a couple bytes in every packet. The downside of supporting sites is much lower, IMHO. Erik already elaborated on this in his mail, so I won't belabor the point. > Here is the issue for Multistited Nodes. > > 1. It is not like link-local addresses. These are needed for the new IPv6 > paradigm so a node has an IP address when it boots. > I'm well aware of the practical uses for link-local addresses. However, if your point is that site-local is not like link-local because we haven't ironed out practical uses, than I say so what? I don't think we've ironed out practical uses for the flow label, but you seem to think they will be useful. Someone may think site-local addresses are useful. Leave them both in. On the other hand, if your point is that site-local are not like link-local in some significant protocol behavior reason, I've yet to hear (or at least understand) the reason. Implementing site-local looks to me like the same "no brainer" that you say link-local is. > 2. The issue for Multisited nodes are not at the API or kernel boundary > we can add any changes for sockaddr_in6 to these boundaries, but > depending on how you implemented IPv6 the changes will be significant. > I'm not sure I understand your point. If you're saying that you don't have a problem with adding site and link indexes to sockaddr_in6, then great! I take it you mean that's not what bothers you, it's that people haven't ironed out how to use site-local addresses. Again, so what? > 3. One issue is the client resolvers and DNS servers. Which site > does an AAAA Site-Local Address belong too? How is the index and site > identifier stored in the DNS? This issue has not been resolved. > Again, this is a usage issue. We can spec the protocol behavior just fine without ever mentioning DNS. Maybe site-local addresses will never be in the DNS. I can think of possible uses for site-local addresses without having to place them in the DNS. Then again, maybe they will. But it's a separate issue. > 4. As far as Net 10 support we don't need site-local addresses for this > reason. We can use defined IPv6 addresses just like IPv4 does today. > Sure. Again, it's an issue of "need". I could also point out that there's no real difference as I see it between a "Net 10" like global prefix and the currently defined site-local prefix -- don't they both come down to different upper bits in the address? > 5. Two-Faced DNS is not resolved as an implementation. There are some > DNS implementations playing with this now but it is not clear how this > works. > See my answer to 3. > 6. Adding site identifier to the decision process for routing adds > additional overhead to route lookups too. This has a cost for > scalabiility and performance of IPv6. > It's not at all clear to me that this is the case. I take it from Erik's mail that he feels the same way. > 7. If we change the sockaddr_in6 do we have to solve all problems for > multisited nodes before IPv6 is deployed? The answer has to be NO. > I agree completely. We don't have to solve everything regarding the flow label either. It's the equivalent issue in my opinion. As long as we clearly define how the protocol layer is expected to behave, we can deploy now. Usage models can be determined later. If one of these things turns out not to be used and in need of redefinition later (like say, IPv4's TOS field) then we fix it later. > > Also as Tim brought up we need to be very careful where we draw that > line for sites: thru the node or thru the link. > I can't imagine how through the link would work. In IP, borders are always between the interfaces in nodes. Maybe the problem people keep having seeing this is similar to the one about IP addresses belonging to interfaces and not to nodes. Interfaces have addresses. Interfaces are on links. Interfaces belong to sites. Nodes are just a collection of one or more interfaces. Why is this so complicated? --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 17:04:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id RAA23172 for ipng-dist; Wed, 8 Apr 1998 17:01:35 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with ESMTP id RAA23163 for ; Wed, 8 Apr 1998 17:01:23 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id RAA13388; Wed, 8 Apr 1998 17:01:21 -0700 (PDT) Date: Wed, 8 Apr 1998 17:01:14 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5631) Re: Multisited Nodes.. To: Richard Draves Cc: "'Christian Huitema'" , Matt Crawford , Brian Haberman , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D81005831FE7@red-msg-50.dns.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [Richard Draves] Hmm, can you send a pointer to your > TCP-survives-renumbering draft? I think the biggest point in favor of > site-local addresses is improved renumbering support; if it's easy to get > that in other ways then site-local addresses are much less interesting to > me. I agree that the IETF should pursue "TCP-survives-renumbering" (in addition to pursuing IPsec, key management, and public key infratructure protocols). However, since the security of the Christian's draft (and presumably any draft that provide a protocol mechanism to tell TCP to send all the packets to some other IP address) needs IPsec for authentication when things do renumber, I think it will take a long time until we can rely solely on such technology for easing the pain of site renumbering. When will every node in a site (including the printer down the hall) have a public key certificate? Thus in my opinion it makes sense exploring different mechanisms for easing the pain and risk of site renumbering. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 18:02:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id RAA23409 for ipng-dist; Wed, 8 Apr 1998 17:56:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id RAA23402 for ; Wed, 8 Apr 1998 17:56:47 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA12664 for ; Wed, 8 Apr 1998 17:56:45 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id RAA05192 for ; Wed, 8 Apr 1998 17:56:47 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA05820; Wed, 8 Apr 98 17:53:24 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA12024; Wed, 8 Apr 1998 17:58:17 -0700 Date: Wed, 8 Apr 1998 17:58:17 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804090058.RAA12024@feller.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 5632) Re: Multisited Nodes.. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > That was not my intent. > > My frustration is that > 1. We agree that we don't have consensus to remove site-local addresses > from the architecture. Implicitly this tells me that it is worth-while > for the WG to investigate what it would take to make site-local addresses > work so that we have some better basis to determine whether or not > the complexity of site-local addresses is worth the benefits. > 2. Some of us try to figure out how to make site-local addresses work well > by e.g. by Tim proposing API extensions. > 3. The proposal is met with a the same arguments ("site local addresses are > bad" etc) that lead to #1. Thus we are going around in circles without > any apparent progress. > > To resolve this I'd like to ask if anybody in the WG disagrees with > The IPNGWG should investigate (assuming there are volounteers) > what it would take to make site-local addresses to work and > propose API and protocol extensions to the WG. > > If we can do this without every email restarting the "site local addresses > are bad" debate we can hopefully move forward and a few months from now > have more information that can be used to move the WG towards consensus. > > Comments? > You have expressed my feelings quite accurately. I don't want to argue anymore about the utility of scoped addresses. Nor do I want my mail box filling up with more E-mail arguments about the utility of scoped addresses. We have been there and done that. They are part of the architecture and multiple other protocols (ND, RIPng, BGP4+, OSPFv6 etc.) depend on them. We don't have the option of backing up and rehashing this debate again. > We need to define how to make these things useful to applications or they need > to be shot in the head. My statement above to Christian in one of my earlier rants was attempt to present an impossible alternative, namely removing scoped addresses, so that we could move forward on solving the problem at hand. The problem at hand being that we need to make scoped addresess at least minimally useful to applications which reside on multi-homed, multi-sited and multi- organizationed(sp?) nodes. >From where I sit the minimum that we can do is provide some sort of scope indication in the sockaddr_in6 which when taken in combination with the sin6_addr provides an unambiguous indication of where the datagram came from and/or where the datagram is going. Once we have that, host implementors might have a chance of solving the forwarding, routing protocol, DNS, multicast forwarding, multicast routing protocol and other issues which come with scoped addresses on a multi-scoped node. Without it host implementors don't have snowball's chance in Honduras of solving all those issues without creating a major headache for application writers. And remember one of the crucial components to making IPv6 successful is making sure that porting of IPv4 applications to IPv6 is dead simple. Also, as Erik noted in one of his earlier notes, a host implementor doesn't need get the API document changed to add some sort of scope indication to the sockaddr_in6. They can do it unilaterally while this group argues about scoped addresses and the definition of an organization and site. We don't want implementors doing this since we want applications to be portable among implementations. Again, IPv6's success is dependent on making the transition from IPv4 only applications to IPv4/IPv6 applications simple. That will not happen if we have ten different flavors of sockaddr_in6 in the world. Let's put an end to the scoped address, multi-scoped node debate and let the folks who have to write the code figure out what needs to go into the sockaddr_in6 so that applications will work. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 8 22:04:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) id VAA23726 for ipng-dist; Wed, 8 Apr 1998 21:59:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta4+Sun/8.9.0.Beta4) with SMTP id VAA23719 for ; Wed, 8 Apr 1998 21:59:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA19692 for ; Wed, 8 Apr 1998 21:59:15 -0700 Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id VAA24233 for ; Wed, 8 Apr 1998 21:59:16 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2166.0) id <2SMLGSMB>; Wed, 8 Apr 1998 21:57:47 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81005831FEF@red-msg-50.dns.microsoft.com> From: Richard Draves To: "'Christian Huitema'" Cc: Brian Haberman , ipng@sunroof.eng.sun.com, Matt Crawford , "'Erik Nordmark'" , "'Jim Bound'" Subject: (IPng 5633) Re: Multisited Nodes.. Date: Wed, 8 Apr 1998 21:57:46 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The TCP survives renumbering draft is available, together with an > implementation report, at http://www.chem.ucla.edu/~beichuan/etcp/ > and http://www.chem.ucla.edu/~beichuan/etcp/huitema-TCP.txt > > One of the author of the implementation, Irene Wu, is working with > Lixia Wang on an improved version of this draft. > Thanks for the pointers. Jim Bound also sent me a copy of his draft outlining another approach. Erik already raised questions of security. I have in mind another set of problems. The UCLA work demonstrates that with your proposal, simple applications like ftp, telnet, and web can survive renumbering. But those are wide-area applications. What about the much more complex applications found within a site? Like distributed file systems and distributed object systems. I believe that TCP or IP level magic will not suffice for these applications to survive renumbering. Today they are built with the assumption that they can use addresses to identify nodes. A related problem is applications that keep addresses in process variables, where renumbering won't reach. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 06:59:05 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id GAA24137 for ipng-dist; Thu, 9 Apr 1998 06:48:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id GAA24130 for ; Thu, 9 Apr 1998 06:48:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA05945; Thu, 9 Apr 1998 06:48:21 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA04154; Thu, 9 Apr 1998 06:48:23 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id JAA22213; Thu, 9 Apr 1998 09:48:18 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id JAA20521; Thu, 9 Apr 1998 09:48:16 -0400 (EDT) Date: Thu, 9 Apr 1998 09:48:16 -0400 (EDT) From: Christian Huitema Message-Id: <980409094814.ZM20519@seawind.bellcore.com> In-Reply-To: Erik Nordmark "Re: (IPng 5623) Re: Multisited Nodes.." (Apr 8, 5:01pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Erik Nordmark , Richard Draves Subject: (IPng 5635) Re: Multisited Nodes.. Cc: "'Christian Huitema'" , Matt Crawford , Brian Haberman , ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Apr 8, 5:01pm, Erik Nordmark wrote: > However, since the security of the Christian's draft (and presumably > any draft that provide a protocol mechanism to tell TCP to send > all the packets to some other IP address) needs IPsec for authentication > when things do renumber, I think it will take a long time until > we can rely solely on such technology for easing the pain of site renumbering. Using IPsec is only one way to solve this "secure renumbering" problem. There are many other ways, such as asking the implementation to vet the new address, providing a list of acceptable address (e.g. from the DNS for multihomed hosts), comparing with local prefixes (for site renumbering). If we start experimenting, we will probably find ways to deal with that. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 06:59:05 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id GAA24128 for ipng-dist; Thu, 9 Apr 1998 06:47:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id GAA24121 for ; Thu, 9 Apr 1998 06:47:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA05827 for ; Thu, 9 Apr 1998 06:47:36 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id GAA03838 for ; Thu, 9 Apr 1998 06:47:38 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA26978; Thu, 9 Apr 1998 08:47:37 -0500 Message-Id: <199804091347.IAA26978@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5634) Re: Multisited Nodes.. In-reply-to: Your message of Wed, 08 Apr 1998 17:58:17 PDT. <199804090058.RAA12024@feller.mentat.com> Date: Thu, 09 Apr 1998 08:47:37 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > To resolve this I'd like to ask if anybody in the WG disagrees with > > The IPNGWG should investigate (assuming there are volounteers) > > what it would take to make site-local addresses to work and > > propose API and protocol extensions to the WG. I agree with that proposal. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 07:13:02 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id HAA24194 for ipng-dist; Thu, 9 Apr 1998 07:12:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id HAA24180 for ; Thu, 9 Apr 1998 07:12:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09330 for ; Thu, 9 Apr 1998 07:12:35 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA17389 for ; Thu, 9 Apr 1998 07:12:35 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id KAA38238 for ; Thu, 9 Apr 1998 10:12:19 -0400 (EDT) Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA27366 for ; Thu, 9 Apr 1998 10:12:21 -0400 Received: from localhost.raleigh.ibm.com by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24488; Thu, 9 Apr 1998 10:12:31 -0400 Message-Id: <352CD74F.69E99D1B@raleigh.ibm.com> Date: Thu, 09 Apr 1998 10:12:31 -0400 From: Brian Haberman Organization: IBM Network Hardware Division X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) Mime-Version: 1.0 To: IPng Subject: (IPng 5636) Re: Multisited Nodes.. Content-Type: multipart/mixed; boundary="------------6FCF25DA5AC08BC8EF48E655" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------6FCF25DA5AC08BC8EF48E655 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------6FCF25DA5AC08BC8EF48E655 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <352CD710.B9768037@raleigh.ibm.com> Date: Thu, 09 Apr 1998 10:11:28 -0400 From: Brian Haberman Organization: IBM Network Hardware Division X-Mailer: Mozilla 4.04 [en] (X11; I; AIX 4.1) MIME-Version: 1.0 To: Matt Crawford Subject: Re: (IPng 5634) Re: Multisited Nodes.. References: <199804091347.IAA26978@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matt Crawford wrote: > > > > To resolve this I'd like to ask if anybody in the WG disagrees with > > > The IPNGWG should investigate (assuming there are volounteers) > > > what it would take to make site-local addresses to work and > > > propose API and protocol extensions to the WG. > > I agree with that proposal. > I agree also. In addition, I will be putting out a draft in a few weeks that outlines how to support site-scoped addresses from a multicast routing protocol perspective. I may be talked into documenting changes to RIPng to support site-scoped addresses, though I would like input from the RIPng authors on that one. Brian --------------6FCF25DA5AC08BC8EF48E655-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 08:46:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id IAA24393 for ipng-dist; Thu, 9 Apr 1998 08:42:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA24383 for ; Thu, 9 Apr 1998 08:41:59 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26549 for ; Thu, 9 Apr 1998 08:41:57 -0700 Received: from relay8.uu.net (relay8.uu.net [192.48.96.84]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA10212 for ; Thu, 9 Apr 1998 08:41:57 -0700 (PDT) Received: from neserve0.uu.net by relay8.uu.net with ESMTP (peer crosschecked as: neserve0.uu.net [153.39.50.135]) id QQekjm27794; Thu, 9 Apr 1998 11:41:55 -0400 (EDT) Received: from localhost by neserve0.uu.net with SMTP (peer crosschecked as: mo@localhost) id QQekjm13785; Thu, 9 Apr 1998 11:41:55 -0400 (EDT) Message-Id: To: Christian Huitema cc: Robert Elz , bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5637) Re: Name lookups on isolated nets. In-reply-to: Your message of "Wed, 08 Apr 1998 11:37:32 EDT." <980408113731.ZM19894@seawind.bellcore.com> Date: Thu, 09 Apr 1998 11:41:55 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk gee - sounds like NBP - Name Binding Protocol (from Appletalk) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 10:24:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id KAA24745 for ipng-dist; Thu, 9 Apr 1998 10:19:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id KAA24738 for ; Thu, 9 Apr 1998 10:17:59 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA24641; Thu, 9 Apr 1998 10:17:55 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA11524; Thu, 9 Apr 1998 10:17:56 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id NAA13795; Thu, 9 Apr 1998 13:17:53 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA09638; Thu, 9 Apr 1998 13:17:47 -0400 Message-Id: <199804091717.AA09638@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com Subject: (IPng 5638) Changes for Basic API for multisite nodes Date: Thu, 09 Apr 1998 13:17:47 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Changed subject from: Subject: Re: (IPng 5632) Re: Multisited Nodes.. I don't see any point in responding to Erik's, Brian's, or Tim's mail any further I could argue this forever that site was a mistake and not needed, I don't like "so what", "the next 20 years", or "it may be useful tomorrow" arguments, I also don't consider them "technical" arguments either, but what we don't want is to recirculate the drafts for sure. Lets make this thread changes needed to support multisited nodes in the basic API. First we need to define the structure and this is the last one we had seen for discussion: struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_ifindex; uint32_t sin6_siteindex; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; }; As an implementor I like the idea of the two fields in question being distinct. Also the sin6_addr and sin6_flowinfo contiguous... I will start looking at the error conditions we need to add to the spec too. So would folks please discuss the use of two fields vs one for implementation? And discuss and provide error condidtions you see so we can catch them all in one round of draft circulation. Also could we nail this down by April 17th please? The we will get the changes into a new Base API spec and other comments we have receieved. p.s. Erik I will call you offline I want to run by you the routing, performance, and transport layer hits I have seen from ***looking** at what this will do to any code generically whether you use Streams, 4.4, or some other flavor of OS. I think you missed my "technical" point in that last round of discussion, but this is not an IETF thing and want to discuss it with you. Email is not working at this point. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 11:36:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id LAA24958 for ipng-dist; Thu, 9 Apr 1998 11:30:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id LAA24951 for ; Thu, 9 Apr 1998 11:30:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA16253; Thu, 9 Apr 1998 11:30:13 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA29845; Thu, 9 Apr 1998 11:30:13 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id OAA03571; Thu, 9 Apr 1998 14:30:07 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id OAA20644; Thu, 9 Apr 1998 14:30:06 -0400 (EDT) Date: Thu, 9 Apr 1998 14:30:06 -0400 (EDT) From: Christian Huitema Message-Id: <980409143005.ZM20642@seawind.bellcore.com> In-Reply-To: bound@zk3.dec.com "(IPng 5638) Changes for Basic API for multisite nodes" (Apr 9, 1:17pm) References: <199804091717.AA09638@wasted.zk3.dec.com> X-Mailer: Z-Mail (5.0.0 30July97) To: bound@zk3.dec.com, thartric@mentat.com (Tim Hartrick) Subject: (IPng 5639) Re: Changes for Basic API for multisite nodes Cc: Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few questions on the propose structure: struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_ifindex; uint32_t sin6_siteindex; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; }; 1) Obviously, there has to be a value for "don't care" in sin6_ifindex; and sin6_siteindex. 2) Someone has to explain the rules that are to be followed by the system for incoming packets. The obvious rules are that: 1) we need to know the sin6_ifindex, or use a default value, for sending packets to a local link address. 2) we need to know the sin6_siteindex, or use a default value, for sending packets to a site address. 3) Overqualifying hurts. You may want to let the system use whatever interface is available when sending to a global address, and also whatever interface is available for the site when sending to a site address. 4) There is a site attached to each interface. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 12:10:20 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA25043 for ipng-dist; Thu, 9 Apr 1998 12:03:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA25036 for ; Thu, 9 Apr 1998 12:03:22 -0700 (PDT) From: akephart@austin.ibm.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA28003 for ; Thu, 9 Apr 1998 12:03:17 -0700 Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA21137 for ; Thu, 9 Apr 1998 12:03:08 -0700 (PDT) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id OAA47254; Thu, 9 Apr 1998 14:00:33 -0500 Received: from aguila.austin.ibm.com (aguila.austin.ibm.com [9.53.150.192]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id NAA68000; Thu, 9 Apr 1998 13:57:19 -0500 Received: (from akephart@localhost) by aguila.austin.ibm.com (AIX4.3/UCB 8.7/8.7-client1.01) id OAA25892; Thu, 9 Apr 1998 14:00:31 -0500 (CDT) Message-Id: <199804091900.OAA25892@aguila.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com Reply-To: akephart@austin.ibm.com Subject: (IPng 5640) Re: Changes for Basic API for multisite nodes In-reply-to: (Your message of Thu, 09 Apr 98 13:17:47 -0400.)<199804091717.AA09638@wasted.zk3.dec.com> Date: Thu, 09 Apr 98 14:00:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ho. Maybe I missed it the first time around, but what was the rationale for not putting the new fields at the end? I know that the spec allows us as implementors to vary it, but I think that most implementors will probably go with whatever is specified here for compatibility's sake. Since there are already folks out there using the API, it would seem to make sense to try and maintain binary compatibility wherever possible... -andrew > [much deleted] > Folks, > > Changed subject from: > Subject: Re: (IPng 5632) Re: Multisited Nodes.. > > > struct sockaddr_in6 { > uint8_t sin6_len; > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_ifindex; > uint32_t sin6_siteindex; > uint32_t sin6_flowinfo; > struct in6_addr sin6_addr; > }; > -- +---------------------------------------------------------------------------+ | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +---------------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 12:24:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA25070 for ipng-dist; Thu, 9 Apr 1998 12:17:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA25063 for ; Thu, 9 Apr 1998 12:17:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA02899 for ; Thu, 9 Apr 1998 12:17:14 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA00041 for ; Thu, 9 Apr 1998 12:16:47 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA20302; Thu, 9 Apr 98 12:13:19 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA12808; Thu, 9 Apr 1998 12:18:16 -0700 Date: Thu, 9 Apr 1998 12:18:16 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804091918.MAA12808@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5641) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > struct sockaddr_in6 { > uint8_t sin6_len; > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_ifindex; > uint32_t sin6_siteindex; > uint32_t sin6_flowinfo; > struct in6_addr sin6_addr; > }; > As I have thought about this the last few days I have begun to like Steve Deering's proposal more. He proposed something like: struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_scope_flag; uint32_t sin6_scope_index; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; }; #define SIN6_SCOPE_GLOBAL 0x0 /* sin6_scope_index, don't care */ #define SIN6_SCOPE_ORG 0x1 /* sin6_scope_index, organization index. */ #define SIN6_SCOPE_SITE 0x2 /* sin6_scope_index, site index. */ #define SIN6_SCOPE_LINK 0x4 /* sin6_scope_index, interface index. */ If we don't want to have the extra field to qualify the scope then we can simply use the address in the sin6_addr to qualify the scope. That would leave us with the following: struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_index; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; }; A third alternative for those who like the first proposal but want to save those precious bits of memory would be: struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint16_t sin6_scope_flag; uint16_t sin6_scope_index; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; }; #define SIN6_SCOPE_GLOBAL 0x0 /* sin6_scope_index, don't care */ #define SIN6_SCOPE_ORG 0x1 /* sin6_scope_index, organization index. */ #define SIN6_SCOPE_SITE 0x2 /* sin6_scope_index, site index. */ #define SIN6_SCOPE_LINK 0x4 /* sin6_scope_index, interface index. */ In all cases, a zero index means, don't care, stack's choice. This seems to be a better choice than having to place a new field in the sockaddr_in6 for every unicast and multicast scope (link, site, org). Comments Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 12:47:21 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA25115 for ipng-dist; Thu, 9 Apr 1998 12:41:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA25108 for ; Thu, 9 Apr 1998 12:41:11 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA10497 for ; Thu, 9 Apr 1998 12:41:07 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA14982 for ; Thu, 9 Apr 1998 12:40:58 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id PAA07165; Thu, 9 Apr 1998 15:40:52 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA20386; Thu, 9 Apr 1998 15:40:48 -0400 Message-Id: <199804091940.AA20386@wasted.zk3.dec.com> To: akephart@austin.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5642) Re: Changes for Basic API for multisite nodes In-Reply-To: Your message of "Thu, 09 Apr 1998 14:00:31 CDT." <199804091900.OAA25892@aguila.austin.ibm.com> Date: Thu, 09 Apr 1998 15:40:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk good point andrew... but even if at the end we will break binary compatibilty as the structure will get bigger. I think we can do this "one more time"............but then no one will take us seriously. folks I am not going to respond to each and every mail for now OK. unless I see implementation pain...........like anyone else not as co-author OK..... I did like Christians points as a comment and we need to cover that part. please keep going folks and lets nail this down. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 13:00:44 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA25164 for ipng-dist; Thu, 9 Apr 1998 12:53:23 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA25157 for ; Thu, 9 Apr 1998 12:53:14 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA14687 for ; Thu, 9 Apr 1998 12:53:05 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA21980 for ; Thu, 9 Apr 1998 12:52:59 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id PAA06416; Thu, 9 Apr 1998 15:52:57 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22244; Thu, 9 Apr 1998 15:52:50 -0400 Message-Id: <199804091952.AA22244@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5643) Re: Changes for Basic API for multisite nodes In-Reply-To: Your message of "Thu, 09 Apr 1998 12:18:16 PDT." <199804091918.MAA12808@feller.mentat.com> Date: Thu, 09 Apr 1998 15:52:49 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk tim, I am pretty flexible here. I need to think about the end result and parse for a moment. But I would love a 64bit aligned sockaddr_in6. also putting the new parts as the end seem better. I liked steves idea too. as a note. how we get there is what I need the moment for as an implementor, as I use the sockaddr_in6 in tact in my kernel. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 13:12:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id NAA25224 for ipng-dist; Thu, 9 Apr 1998 13:05:53 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id NAA25217 for ; Thu, 9 Apr 1998 13:05:44 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA18829 for ; Thu, 9 Apr 1998 13:05:40 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id NAA29487 for ; Thu, 9 Apr 1998 13:05:41 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA22077; Thu, 9 Apr 98 13:02:15 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA12856; Thu, 9 Apr 1998 13:07:12 -0700 Date: Thu, 9 Apr 1998 13:07:12 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804092007.NAA12856@feller.mentat.com> To: akephart@austin.ibm.com Subject: (IPng 5644) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, > > Maybe I missed it the first time around, but what was the > rationale for not putting the new fields at the end? I know that the > spec allows us as implementors to vary it, but I think that most > implementors will probably go with whatever is specified here for > compatibility's sake. > > Since there are already folks out there using the API, it would > seem to make sense to try and maintain binary compatibility wherever > possible... > My rationale was that for every system with which I am familiar binary com- patibility is broken as soon as the structure size changes. Where you put the fields is window dressing compared to the size change. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 14:32:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA25494 for ipng-dist; Thu, 9 Apr 1998 14:27:43 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id OAA25487 for ; Thu, 9 Apr 1998 14:27:32 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA27104; Thu, 9 Apr 1998 14:27:25 -0700 (PDT) Date: Thu, 9 Apr 1998 14:27:17 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5645) Re: Changes for Basic API for multisite nodes To: Tim Hartrick Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199804091918.MAA12808@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If we don't want to have the extra field to qualify the scope then we can > simply use the address in the sin6_addr to qualify the scope. That would > leave us with the following: Is there a case when it would be useful to decouple the scope for the index from the scope of the destination address? (I can't think of a useful case.) Having the scope that the index applies to be the same as the unicast or multicast scope for the dest address is fine with me. That avoids the issue of the semantics when sending to e.g. a global address but specifying an interface index, or sending to a link-local address and specifying a site index. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 14:39:32 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA25513 for ipng-dist; Thu, 9 Apr 1998 14:36:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA25506 for ; Thu, 9 Apr 1998 14:36:17 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14186 for ; Thu, 9 Apr 1998 14:36:15 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA25517 for ; Thu, 9 Apr 1998 14:36:02 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA23624; Thu, 9 Apr 98 14:32:35 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA12907; Thu, 9 Apr 1998 14:37:32 -0700 Date: Thu, 9 Apr 1998 14:37:32 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804092137.OAA12907@feller.mentat.com> To: Erik.Nordmark@Eng Subject: (IPng 5646) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > > Is there a case when it would be useful to decouple the scope for > the index from the scope of the destination address? > (I can't think of a useful case.) > I can't think of one either. > Having the scope that the index applies to be the same > as the unicast or multicast scope for the dest address is fine with me. > That avoids the issue of the semantics when sending to e.g. a global > address but specifying an interface index, or sending to a link-local > address and specifying a site index. > Yes it trims the error cases down a lot to have the scope field be implied by the scope of the address in the sin6_addr field. I only suggested the addition sin6_scope_type field because some folks may not want to have to examine the address to determine how to interpret the scope. The conditionals for that or more complex. I am easy either way. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 15:23:18 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id PAA25682 for ipng-dist; Thu, 9 Apr 1998 15:17:02 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id PAA25671 for ; Thu, 9 Apr 1998 15:16:52 -0700 (PDT) From: akephart@austin.ibm.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA29171 for ; Thu, 9 Apr 1998 15:16:48 -0700 Received: from ausmail.austin.ibm.com (ausmail.austin.ibm.com [192.35.232.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id PAA19198 for ; Thu, 9 Apr 1998 15:16:46 -0700 (PDT) Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [9.53.250.98]) by ausmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id RAA05222; Thu, 9 Apr 1998 17:16:43 -0500 Received: from aguila.austin.ibm.com (aguila.austin.ibm.com [9.53.150.192]) by netmail.austin.ibm.com (8.8.5/8.8.5) with ESMTP id RAA61060; Thu, 9 Apr 1998 17:13:29 -0500 Received: (from akephart@localhost) by aguila.austin.ibm.com (AIX4.3/UCB 8.7/8.7-client1.01) id RAA16930; Thu, 9 Apr 1998 17:16:42 -0500 (CDT) Message-Id: <199804092216.RAA16930@aguila.austin.ibm.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: thartric@mentat.com (Tim Hartrick) cc: ipng@sunroof.eng.sun.com Reply-To: akephart@austin.ibm.com Subject: (IPng 5647) Re: Changes for Basic API for multisite nodes In-reply-to: (Your message of Thu, 09 Apr 98 13:07:12 -0700.)<199804092007.NAA12856@feller.mentat.com> Date: Thu, 09 Apr 98 17:16:41 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, > > > Andrew, > > > > > Maybe I missed it the first time around, but what was the > > rationale for not putting the new fields at the end? I know that the > > spec allows us as implementors to vary it, but I think that most > > implementors will probably go with whatever is specified here for > > compatibility's sake. > > > > Since there are already folks out there using the API, it would > > seem to make sense to try and maintain binary compatibility wherever > > possible... > > > > My rationale was that for every system with which I am familiar binary com- > patibility is broken as soon as the structure size changes. Where you put > the fields is window dressing compared to the size change. This is only partially true, e.g. arrays and allocation issues. A function that takes a sockaddr_in6 * and prints the address would be a case where compatibility is conserved by adding to the end, but broken by adding to the middle. Even if you believe it's broken in all cases due to the size change -- in which case any position is as good as any other -- why add to the middle? I recognize that this is fairly small (given the way the spec was originally written), but I'd like to make sure that I haven't missed some larger driving philosophy; if the middle it is, so be it. -andrew -- +---------------------------------------------------------------------------+ | Andrew Kephart, AIX TCP/IP These are my opinions only...IBM might | | SMTP: akephart@austin.ibm.com agree, but I wouldn't count on it. | +---------------------------------------------------------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 15:47:43 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id PAA25745 for ipng-dist; Thu, 9 Apr 1998 15:40:15 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id PAA25738 for ; Thu, 9 Apr 1998 15:40:04 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id PAA08683; Thu, 9 Apr 1998 15:39:57 -0700 (PDT) Date: Thu, 9 Apr 1998 15:39:50 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5648) Re: Multisited Nodes.. To: Christian Huitema Cc: Erik Nordmark , Richard Draves , Matt Crawford , Brian Haberman , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Using IPsec is only one way to solve this "secure renumbering" problem. > There are many other ways, such as asking the implementation to vet the > new address, providing a list of acceptable address (e.g. from the DNS for > multihomed hosts), comparing with local prefixes (for site renumbering). > If we start experimenting, we will probably find ways to deal with that. We definitely need to explore these possibilities. Some of them would require API changes. If connect() (or an improved connect API) took the whole list of address returned by the DNS then TCP could switch any of those addresses without any security concerns which addresses the multihomed case. For renumbering we could build some upcall mechanisms where TCP would ask the DNS "do these two addresses refer to the same node" i.e. a new DNS lookup would occur before TCP switched to using the new destination address. This could be implemented without an API change if we rely on reverse lookups: ETCP is currently using destination A1. ETCP would like to switch to destination A2. DNS reverse lookup on A1 to get a FQDN. Forward lookup on that name. If A2 is one of the addresses returned then it can be used. If we want to get rid of the reverse lookup I think we want a connect like API that accepts a host name instead of an address so that when ETCP wants to switch there can just be a new DNS lookup to verify that the proposed destination is in the list. BTW: the java.net.Socket class allows this - Socket("www.foo.tld", 80) I don't quite see how "local prefixes" would work but if it will it could presumably be done without API changes. If the router advertise site prefixes as specified in my site-prefixes draft then each host in a site would now that e.g. all addresses in A::0/48 and B::0/48 are local to the site. But I don't think we want to require that A:0:0:17::1 and B:0:0:17::1 be the same node since that would place undo constrains e.g. if this site is really created by company A and B having merged. One might be able to argue that if we get an ETCP packet for a connection to A:0:0:17::1 effectively tell ETCP to switch to sending to B:0:0:17::1 that, while this can be used to steal connections in some cases. you can only - steal connections within your own site, and - only those where the last 80 bits match your own address. I don't know if that would be sufficient as "security". Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 9 19:34:36 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id TAA26145 for ipng-dist; Thu, 9 Apr 1998 19:30:51 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id TAA26138 for ; Thu, 9 Apr 1998 19:30:40 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA29366 for ; Thu, 9 Apr 1998 19:30:40 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id TAA00121 for ; Thu, 9 Apr 1998 19:30:41 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA28149; Thu, 9 Apr 98 19:27:09 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id TAA13147; Thu, 9 Apr 1998 19:32:07 -0700 Date: Thu, 9 Apr 1998 19:32:07 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804100232.TAA13147@feller.mentat.com> To: akephart@austin.ibm.com Subject: (IPng 5650) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, > > This is only partially true, e.g. arrays and allocation issues. > A function that takes a sockaddr_in6 * and prints the address would be a > case where compatibility is conserved by adding to the end, but broken > by adding to the middle. > Correct. I was only viewing it from the socket system call point of view. Even that binary compatibility issue can be finessed if the size or even the field ordering changes. If there are lots of IPv6 binaries out there then it makes sense to do the work to finesse the problem. I wasn't aware that there were that many binaries out there. > Even if you believe it's broken in all cases due to the size > change -- in which case any position is as good as any other -- why > add to the middle? > No special reason. Just constinency with other forms of sockaddr type structures where the address is the last component of the structure. > I recognize that this is fairly small (given the way the spec > was originally written), but I'd like to make sure that I haven't > missed some larger driving philosophy; if the middle it is, so be it. > I am OK with the end if there is reasonable consensus for it. It may well be that there is an advantage for 4.4 BSD based implementations to having the fields in some specific position in the structure for the pur- poses of radix tree lookups or something. If so then I am fine with what ever order makes life easy for those folks. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 02:49:06 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id CAA26403 for ipng-dist; Fri, 10 Apr 1998 02:45:34 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id CAA26396 for ; Fri, 10 Apr 1998 02:45:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA08642 for ; Fri, 10 Apr 1998 02:45:24 -0700 Received: from alpes.eurecom.fr (alpes.eurecom.fr [193.55.112.131]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id CAA27753 for ; Fri, 10 Apr 1998 02:43:08 -0700 (PDT) Received: from pensee.eurecom.fr (pensee.eurecom.fr [193.55.114.51]) by alpes.eurecom.fr (8.7.4/8.7.3) with ESMTP id LAA25876 for ; Fri, 10 Apr 1998 11:43:23 +0200 (MET DST) Received: from pensee (localhost [127.0.0.1]) by pensee.eurecom.fr (8.8.4/8.8.4) with SMTP id LAA24400 for ; Fri, 10 Apr 1998 11:41:24 +0200 (MET DST) Message-ID: <352DE942.3096@eurecom.fr> Date: Fri, 10 Apr 1998 11:41:22 +0200 From: Marie-Noelle Sauvayre Organization: Eurecom X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 5651) ipv6 addressing and Exchanges Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear all, I am preparing a course about IPv6 addressing. I am sorry not to find in the existing Ipng documentation explanations about what an "Exchange" is and how it can help to avoid renumbering in case of provider's change. If any of you had papers, explanations... Thanks in advance, -- Marie-Noelle SAUVAYRE Research and Teaching associate Bureau 025 Institut EURECOM 2229, Route des Cretes BP193 06904 Sophia-Antipolis Cedex Tel dir : (33) 04 93 00 26 95 Tel sec : (33) 04 93 00 26 64 Fax : (33) 04 93 00 26 27 E-mail : sauvayre@eurecom.fr http://www.eurecom.fr/~sauvayre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 05:08:58 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id FAA26536 for ipng-dist; Fri, 10 Apr 1998 05:02:04 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id FAA26529 for ; Fri, 10 Apr 1998 05:01:53 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA18541 for ; Fri, 10 Apr 1998 05:01:47 -0700 Received: from alpes.eurecom.fr (alpes.eurecom.fr [193.55.112.131]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id FAA08065 for ; Fri, 10 Apr 1998 05:01:29 -0700 (PDT) Received: from pensee.eurecom.fr (pensee.eurecom.fr [193.55.114.51]) by alpes.eurecom.fr (8.7.4/8.7.3) with ESMTP id OAA29205; Fri, 10 Apr 1998 14:01:45 +0200 (MET DST) Received: from pensee (localhost [127.0.0.1]) by pensee.eurecom.fr (8.8.4/8.8.4) with SMTP id NAA26554; Fri, 10 Apr 1998 13:59:45 +0200 (MET DST) Message-ID: <352E09B1.79B1@eurecom.fr> Date: Fri, 10 Apr 1998 13:59:45 +0200 From: Marie-Noelle Sauvayre Organization: Eurecom X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Anoop Kulkarni CC: ipng@sunroof.eng.sun.com Subject: (IPng 5652) Re: ipv6 addressing and Exchanges References: <199804101012.PAA00975@sunc2.sasi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Anoop Kulkarni wrote: > > In message <352DE942.3096@eurecom.fr>Marie-Noelle Sauvayre writes - > > Dear all, > > I am preparing a course about IPv6 addressing. > > I am sorry not to find in the existing Ipng documentation explanations > > about what an "Exchange" is and how it can help to avoid renumbering in > > case of provider's change. > > If any of you had papers, explanations... > > Thanks in advance, > > Hi, > I am not sure what exactly you are referring to as 'exchange'. If it is > about (static) address autoconfiguration (which I think you are looking > for) then its description is available in the draft in abundance. > > Best regards, > Anoop > -- > ---------------------------------------------------------------------------- > Home : Anoop Kulkarni, | Office: Anoop Kulkarni, > Flat A2, Pioneer | Silicon Automation Systems (I) Pvt Ltd. > Residency, HAL III | 3008, 12th 'B' Main, 8th Cross, > Stage, Bangalore 75 | HAL II Stage, Bangalore 560008, INDIA > Phone: +091-080-528 5749 | Fax : +091-080-528 4396 > Email: anoop@sasi.com | Phone : +091-080-528 1461 ext 4205 > ---------------------------------------------------------------------------- Hi, what I mean by "Exchange" is the word present in the draft "An IPv6 aggregatable Global Unicast Format", in figures or sentences such as : "this address format supports current provider-based aggregation and a new type of Exchange-based aggregation". -- Marie-Noelle SAUVAYRE Bureau 025 Institut EURECOM 2229, Route des Cretes BP193 06904 Sophia-Antipolis Cedex Tel dir : (33) 04 93 00 26 95 Tel sec : (33) 04 93 00 26 64 Fax : (33) 04 93 00 26 27 E-mail : sauvayre@eurecom.fr http://www.eurecom.fr/~sauvayre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 07:44:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id HAA26876 for ipng-dist; Fri, 10 Apr 1998 07:38:58 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id HAA26869 for ; Fri, 10 Apr 1998 07:38:49 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA15982 for ; Fri, 10 Apr 1998 07:38:47 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA07893 for ; Fri, 10 Apr 1998 07:38:47 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id KAA12140; Fri, 10 Apr 1998 10:38:43 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA22291; Fri, 10 Apr 1998 10:38:38 -0400 Date: Fri, 10 Apr 1998 10:38:38 -0400 From: Jack McCann Message-Id: <199804101438.AA22291@wasted.zk3.dec.com> To: bound@zk3.dec.com, thartric@mentat.com Subject: (IPng 5653) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com, mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My 2 cents: 1. We should not use the address in the sin6_addr to qualify the scope (e.g. I want to send to a site-scope address over a specific interface chosen from the set of interfaces belonging to the site) 2. I like the scope-flag + scope-index approach, it avoids index conflict and decouples index scope from sin6_addr scope 3. Does SIN6_SCOPE_SITE hold different meaning for unicast vs. multicast? (i.e. could the set of interfaces belonging to a unicast site index be different from the set of interfaces belonging to a multicast site index?) Do we need SIN6_SCOPE_UNICAST_SITE and SIN6_SCOPE_MULTICAST_SITE? 4. 16 bits is not enough for index, let's go with 32 (or maybe 24 and use the upper 8 bits for scoping?) 5. Even though the structure layout in the spec is just an example, let's make the sin6_addr 64 (or 128!) bit aligned. 6. Let's specify the structure as 32 octets (on a 64 bit system it's likely to be padded out to a 64 bit boundary anyway, 32 octets also has the nice property of being 128 bit aligned) 7. But let's not use all 32 octets just yet, it might be useful at some future date to have a bit of reserved MBZ space (8, 16, or 32 bits) in the structure. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 09:12:28 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA27042 for ipng-dist; Fri, 10 Apr 1998 09:07:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA27035 for ; Fri, 10 Apr 1998 09:07:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA01327 for ; Fri, 10 Apr 1998 09:07:36 -0700 Received: from smtp-gw.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA24911 for ; Fri, 10 Apr 1998 09:07:37 -0700 (PDT) Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by smtp-gw.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id JAA26262; Fri, 10 Apr 1998 09:04:46 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.8/8.8.8) with ESMTP id JAA28478; Fri, 10 Apr 1998 09:04:44 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (dhcp139-254 [192.32.139.254]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA17318; Fri, 10 Apr 1998 12:06:21 -0400 for Message-Id: <199804101606.MAA17318@pobox.engeast.BayNetworks.COM> X-Sender: dhaskin@pobox X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1.323 (Beta) Date: Fri, 10 Apr 1998 12:05:59 -0400 To: Marie-Noelle Sauvayre From: Dimitry Haskin Subject: (IPng 5654) Re: ipv6 addressing and Exchanges Cc: ipng@sunroof.eng.sun.com In-Reply-To: <352DE942.3096@eurecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marie-Noelle, >Dear all, >I am preparing a course about IPv6 addressing. >I am sorry not to find in the existing Ipng documentation explanations >about what an "Exchange" is and how it can help to avoid renumbering in >case of provider's change. >If any of you had papers, explanations... Internet Exchange is a public network exchange facility where Internet Service Providers (ISPs) can connect with one another in peering arrangements. It is also often called Network Access Point (NAP). Assigning a top level prefix (pTLA) to an Internet Exchange improves route aggregation since multiple providers that peer at the same exchange can share the same pTLA and therefore can be aggregated under a single address prefix. It is not clear that an Internet Exchange with a single pTLA helps to avoid renumbering when a provider is changed. Even if it is likely, due to geographical nature of NAPs, that the new provider belongs to the same NAP as the old provider and uses the same pTLA, the next level prefix (NLA) that is assigned to individual providers would change any way when providers are changed. I believe IPv6 architecture tries to ease renumbering - not to avoid it. Dimitry _______________________________________________________ Dimitry Haskin Bay Networks, Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 09:26:23 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA27098 for ipng-dist; Fri, 10 Apr 1998 09:22:08 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA27091 for ; Fri, 10 Apr 1998 09:21:57 -0700 (PDT) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA19173; Fri, 10 Apr 1998 09:21:55 -0700 (PDT) Date: Fri, 10 Apr 1998 09:19:28 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5655) Re: Changes for Basic API for multisite nodes To: Jack McCann Cc: bound@zk3.dec.com, thartric@mentat.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199804101438.AA22291@wasted.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > My 2 cents: > > 1. We should not use the address in the sin6_addr to qualify the > scope (e.g. I want to send to a site-scope address over a specific > interface chosen from the set of interfaces belonging to the site) Why would you want to do this? For both unicast and multicast? > 3. Does SIN6_SCOPE_SITE hold different meaning for unicast vs. multicast? > (i.e. could the set of interfaces belonging to a unicast site index be > different from the set of interfaces belonging to a multicast site > index?) > Do we need SIN6_SCOPE_UNICAST_SITE and SIN6_SCOPE_MULTICAST_SITE? Good question. If we want to allow the multicast site boundary to be at a different place that the unicast site boundary it sounds like we are really dealing with two different concepts: msite and usite. An msite could presumably be contained in a usite or vice versa, or one could even imagine partial overlaps between msites and usites. Do we really want to add this level of complexity/fliexbility? I personally do not see any benefit. > 5. Even though the structure layout in the spec is just an example, > let's make the sin6_addr 64 (or 128!) bit aligned. Fine with me. > 7. But let's not use all 32 octets just yet, it might be useful at some > future date to have a bit of reserved MBZ space (8, 16, or 32 bits) > in the structure. Would you express that as a sin6_reserved field (which the application must set to zero)? If you leave the field unnamed then a portable application must use bzero/memset to clear out the whole sockaddr_in6 before use just to make sure that the reserved bits got cleared. With a named field the application can use either bzero or "sin6->sin6_reserved = 0". Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 09:39:40 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA27140 for ipng-dist; Fri, 10 Apr 1998 09:32:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA27133 for ; Fri, 10 Apr 1998 09:32:16 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA07066 for ; Fri, 10 Apr 1998 09:32:13 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA08405 for ; Fri, 10 Apr 1998 09:32:12 -0700 (PDT) Received: from [171.69.116.90] ([171.69.116.90]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA11792 for ; Fri, 10 Apr 1998 09:32:11 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199804101438.AA22291@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Apr 1998 09:33:14 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 5656) Re: Changes for Basic API for multisite nodes Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry, folks, for not contributing to the latest round of the Great Site-Local Debate -- I've been tied up with more urgent matters this week, and I am also required to attend meetings all day today, so I won't have a chance to respond to the onslaught until tonight or tomorrow. Is there any chance you can take brief intermission and let me catch up? :-) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 09:54:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA27209 for ipng-dist; Fri, 10 Apr 1998 09:44:56 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA27202 for ; Fri, 10 Apr 1998 09:44:50 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA23084 for ; Fri, 10 Apr 1998 09:44:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA14737 for ipng@sunroof.eng.sun.com; Fri, 10 Apr 1998 09:44:38 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id TAA26119 for ; Thu, 9 Apr 1998 19:11:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA26388; Thu, 9 Apr 1998 19:11:15 -0700 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA21410; Thu, 9 Apr 1998 19:11:11 -0700 (PDT) Message-Id: <199804100211.TAA21410@earth.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA117074400; Thu, 9 Apr 1998 22:13:20 -0400 To: Erik Nordmark Cc: Christian Huitema , Richard Draves , Matt Crawford , Brian Haberman , ipng@sunroof.eng.sun.com Subject: (IPng 5657) Re: Multisited Nodes.. In-Reply-To: Your message of "Thu, 09 Apr 1998 15:39:50 EDT." Date: Thu, 09 Apr 1998 22:13:20 -0400 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Erik Nordmark w rites: > > Using IPsec is only one way to solve this "secure renumbering" problem. > > There are many other ways, such as asking the implementation to vet the > > new address, providing a list of acceptable address (e.g. from the DNS for > > multihomed hosts), comparing with local prefixes (for site renumbering). > > If we start experimenting, we will probably find ways to deal with that. > > We definitely need to explore these possibilities. > > Some of them would require API changes. > If connect() (or an improved connect API) took the whole list > of address returned by the DNS then TCP could switch any of those > addresses without any security concerns which addresses the multihomed case. > > For renumbering we could build some upcall mechanisms where TCP would > ask the DNS "do these two addresses refer to the same node" i.e. > a new DNS lookup would occur before TCP switched to using the new > destination address. This could be implemented without an API change > if we rely on reverse lookups: > ETCP is currently using destination A1. > ETCP would like to switch to destination A2. > DNS reverse lookup on A1 to get a FQDN. > Forward lookup on that name. > If A2 is one of the addresses returned then it can > be used. > If we want to get rid of the reverse lookup I think we want a connect like > API that accepts a host name instead of an address so that when > ETCP wants to switch there can just be a new DNS lookup to verify that > the proposed destination is in the list. > BTW: the java.net.Socket class allows this - Socket("www.foo.tld", 80) ... I would strongly suggest that all lookups involving renumbering be secured with DNS SIG records. Otherwise, I think you'd be opening up a lot of security holes. The most obvious example I see is: To pirate a TCP connection, all the bad guy has to do is send a single bad DNS reply at just the right time. I would also suggest that all lookups must be symmetric. Just a forward lookup is not sufficient. A reverse lookup must be performed to make sure the address maps back to the right name. An example of an attack for this would be more complex. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 09:54:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA27240 for ipng-dist; Fri, 10 Apr 1998 09:49:03 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA27233 for ; Fri, 10 Apr 1998 09:48:52 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA11395 for ; Fri, 10 Apr 1998 09:48:50 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id JAA17844 for ; Fri, 10 Apr 1998 09:48:51 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA00561; Fri, 10 Apr 98 09:45:26 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id JAA14392; Fri, 10 Apr 1998 09:50:08 -0700 Date: Fri, 10 Apr 1998 09:50:08 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804101650.JAA14392@feller.mentat.com> To: mccann@zk3.dec.com Subject: (IPng 5658) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jack, > > 1. We should not use the address in the sin6_addr to qualify the > scope (e.g. I want to send to a site-scope address over a specific > interface chosen from the set of interfaces belonging to the site) > So you are looking for a way to completely replace the in6_pktinfo structure and the IPV6_PKTINFO ancillary data item? What you want to do could be achieved by using a combination of the site index in the sockaddr_in6 and then using an IPV6_PKTINFO option to specify the interface and source address. I am not necessarily against what you are saying. I just wanted to point out that there was another way to skin that cat. > 2. I like the scope-flag + scope-index approach, it avoids index > conflict and decouples index scope from sin6_addr scope > > 3. Does SIN6_SCOPE_SITE hold different meaning for unicast vs. multicast? > (i.e. could the set of interfaces belonging to a unicast site index be > different from the set of interfaces belonging to a multicast site index?) > Do we need SIN6_SCOPE_UNICAST_SITE and SIN6_SCOPE_MULTICAST_SITE? > I was assuming when I made the flags plus index proposal that there would not be seperate disjoint site boundaries for unicast and multicast. Maybe Steve or Bob can comment on whether they intend for multicast and unicast sites to be disjoint sets of nodes. I can't imagine a utility for such a thing but it is possible to specify it that way. > 4. 16 bits is not enough for index, let's go with 32 (or maybe 24 > and use the upper 8 bits for scoping?) > Fine with me. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 10:45:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id KAA27501 for ipng-dist; Fri, 10 Apr 1998 10:40:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id KAA27494 for ; Fri, 10 Apr 1998 10:40:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA25182 for ; Fri, 10 Apr 1998 10:40:30 -0700 Received: from iisc.ernet.in (iisc.ernet.in [144.16.64.3]) by earth.sun.com (8.8.8/8.8.8) with SMTP id KAA18923 for ; Fri, 10 Apr 1998 10:40:06 -0700 (PDT) Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id XAA15068; Fri, 10 Apr 1998 23:08:45 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA15242; Fri, 10 Apr 98 23:08:45+0530 Date: Fri, 10 Apr 1998 22:49:14 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: (IPng 5659) Hi!! Route Aggregation. To: ipng@sunroof.eng.sun.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi!!! I was reading IPv6 addressing architecture and "An IPv6 Aggregatable Global Unicast Address Format" internet draft. I have few questions. OSPF version 2 and BGP -4 are totally based on Area and Autonomous system concepts. Why not we aggregate in terms of Areas and Autonomous. Why can't we have peer group concept with ASs as in ATM PNNI. I think this type of concept will be useful for QoS routing with Explicit\_Route support. Why don't we aggregate at the Area and AS level. This will reduce the routing table size at the routers. Am I correct. If not Can u explain me where I am mistaken the concepts. I want to have a addressing format of the following type. ------------------------------------- A | B | | D | | C | ------------------------------------ A - Peer Group Identifier. ( As in ATM PNNI) B - AS identifier.( It can be further divieded depending on the aggregation level ). B1 - Peer Group Identifier. B2 - AS identifier. C - Area ID. ( - do -) D - Interface Identifier. Can we do this. I want to have QoS support in IP. So every Area border router will maintain a graph of AREA connectivity ( With QoS ) only, but not the internal details of the Area. So for Inter-Area routing Crank Back occurs at the Area Border Routers. Same case with AS border Routers only. So AS border Routers will maintain a graph of ASs connectivity with QoS , but not the internal details of the AS as far as QoS is concerned. So crank back occurs at the AS border routers. This model almost same as the ATM PNNI. As suggested in Frame work for QoS based routing we can group some X number of ASs to form a group. They all can be given a Level identifier. ( This can a provider based Aggregation ). Waiting for somebody's kind reply. Thanks in advance. With Regards -Raghu. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 12:25:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA27631 for ipng-dist; Fri, 10 Apr 1998 12:20:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA27624 for ; Fri, 10 Apr 1998 12:19:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA17156 for ; Fri, 10 Apr 1998 12:19:43 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA14325 for ; Fri, 10 Apr 1998 12:19:45 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail12.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id PAA16578; Fri, 10 Apr 1998 15:19:38 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00836; Fri, 10 Apr 1998 15:19:37 -0400 Date: Fri, 10 Apr 1998 15:19:37 -0400 From: Jack McCann Message-Id: <199804101919.AA00836@wasted.zk3.dec.com> To: thartric@mentat.com Subject: (IPng 5660) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thartric@mentat.com (Tim Hartrick) wrote: >Subject: Re: (IPng 5653) Re: Changes for Basic API for multisite nodes > >> >> 1. We should not use the address in the sin6_addr to qualify the >> scope (e.g. I want to send to a site-scope address over a specific >> interface chosen from the set of interfaces belonging to the site) >> > >So you are looking for a way to completely replace the in6_pktinfo structure >and the IPV6_PKTINFO ancillary data item? > >What you want to do could be achieved by using a combination of the site >index in the sockaddr_in6 and then using an IPV6_PKTINFO option to specify >the interface and source address. > >I am not necessarily against what you are saying. I just wanted to point >out that there was another way to skin that cat. I guess what I had in mind would fall under the "debugging the network" category (e.g. I want to ping or traceroute a site-scope destination over a given interface to test reachability). Since I can't come up with a general purpose reason to do this, and since you point out we can do what I want with the advanced API pieces, and since "debugging" feels like an advanced API type of thing, I withdraw this suggestion. >> 3. Does SIN6_SCOPE_SITE hold different meaning for unicast vs. multicast? >> (i.e. could the set of interfaces belonging to a unicast site index be >> different from the set of interfaces belonging to a multicast site index?) >> Do we need SIN6_SCOPE_UNICAST_SITE and SIN6_SCOPE_MULTICAST_SITE? >> > >I was assuming when I made the flags plus index proposal that there would >not be seperate disjoint site boundaries for unicast and multicast. Maybe >Steve or Bob can comment on whether they intend for multicast and unicast >sites to be disjoint sets of nodes. I can't imagine a utility for such a >thing but it is possible to specify it that way. OK, I'm not advocating unicast site != multicast site, and in fact this feels like a good topic for the new "what is an IPv6 site" working group :-). We should probably just state the assumption/limitation explicitly. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 12:48:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA27718 for ipng-dist; Fri, 10 Apr 1998 12:39:19 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA27696 for ; Fri, 10 Apr 1998 12:39:00 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA21414; Fri, 10 Apr 1998 12:38:54 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA09343; Fri, 10 Apr 1998 12:09:27 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id PAA01220; Fri, 10 Apr 1998 15:09:26 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00229; Fri, 10 Apr 1998 15:09:23 -0400 Date: Fri, 10 Apr 1998 15:09:23 -0400 From: Jack McCann Message-Id: <199804101909.AA00229@wasted.zk3.dec.com> To: Erik.Nordmark@Eng Subject: (IPng 5661) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: >Subject: (IPng 5655) Re: Changes for Basic API for multisite nodes >> >> My 2 cents: >> >> 1. We should not use the address in the sin6_addr to qualify the >> scope (e.g. I want to send to a site-scope address over a specific >> interface chosen from the set of interfaces belonging to the site) > >Why would you want to do this? >For both unicast and multicast? I guess what I had in mind would fall under the "debugging the network" category (e.g. I want to ping or traceroute a site-scope destination over a given interface to test reachability). Since I can't come up with a general purpose reason to do this, and since Tim points out we can do what I want with the advanced API pieces, and since "debugging" feels like an advanced API type of thing, I withdraw this suggestion. >> 3. Does SIN6_SCOPE_SITE hold different meaning for unicast vs. multicast? >> (i.e. could the set of interfaces belonging to a unicast site index be >> different from the set of interfaces belonging to a multicast site >> index?) >> Do we need SIN6_SCOPE_UNICAST_SITE and SIN6_SCOPE_MULTICAST_SITE? > >Good question. >If we want to allow the multicast site boundary to be at a different >place that the unicast site boundary it sounds like we are really >dealing with two different concepts: msite and usite. >An msite could presumably be contained in a usite or vice versa, or one >could even imagine partial overlaps between msites and usites. >Do we really want to add this level of complexity/fliexbility? >I personally do not see any benefit. I don't know the answer to your questions, I just wanted to point out that with only one flag we are limiting this API to use where msite == usite, when the architecture does not require msite == usite (or did I miss something?). This is probably an acceptable limitation. >> 7. But let's not use all 32 octets just yet, it might be useful at some >> future date to have a bit of reserved MBZ space (8, 16, or 32 bits) >> in the structure. > >Would you express that as a sin6_reserved field (which the application >must set to zero)? If you leave the field unnamed then a portable application >must use bzero/memset to clear out the whole sockaddr_in6 before use >just to make sure that the reserved bits got cleared. >With a named field the application can use either bzero or >"sin6->sin6_reserved = 0". Yes, I was thinking there would be an explicit sin6_reserved field, I did not intend the field to be unnamed. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 13:48:32 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id NAA27867 for ipng-dist; Fri, 10 Apr 1998 13:40:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id NAA27859 for ; Fri, 10 Apr 1998 13:39:07 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA06949; Fri, 10 Apr 1998 13:39:03 -0700 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA22687; Fri, 10 Apr 1998 13:39:02 -0700 (PDT) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id QAA17101; Fri, 10 Apr 1998 16:39:00 -0400 (EDT) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id QAA21384; Fri, 10 Apr 1998 16:38:59 -0400 (EDT) Date: Fri, 10 Apr 1998 16:38:59 -0400 (EDT) From: Christian Huitema Message-Id: <980410163858.ZM21382@seawind.bellcore.com> In-Reply-To: Erik Nordmark "(IPng 5648) Re: Multisited Nodes.." (Apr 9, 3:39pm) References: X-Mailer: Z-Mail (5.0.0 30July97) To: Erik Nordmark , Christian Huitema Subject: (IPng 5662) Re: Multisited Nodes.. Cc: Richard Draves , Matt Crawford , Brian Haberman , ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Yes, an interface that asks the application for permission through some form of call back is probably the best way out. Something like: 1) a "got new address" error code, 2) a "what's the new address[es]" getsockopt, 3) a "please authorize these new addresses" setsockopt. Obviously, this merely pushes the problem to the application. But the application can then use many tools, such as "accept everything" if using SSL, look in the DNS, look in teh DNS and ask for secure records, request the set-up of an IPSEC association... -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 14:05:06 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id NAA27932 for ipng-dist; Fri, 10 Apr 1998 13:59:50 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id NAA27925 for ; Fri, 10 Apr 1998 13:59:41 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA11629 for ; Fri, 10 Apr 1998 13:59:39 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA02527 for ; Fri, 10 Apr 1998 13:59:38 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id QAA68796 for ; Fri, 10 Apr 1998 16:59:17 -0400 (EDT) Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA23726 for ; Fri, 10 Apr 1998 16:59:19 -0400 Received: by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21044; Fri, 10 Apr 1998 16:59:25 -0400 From: haberman@raleigh.ibm.com (Brian K. Haberman) Message-Id: <9804102059.AA21044@clemson.raleigh.ibm.com> Subject: (IPng 5663) Site Boundary Draft To: ipng@sunroof.eng.sun.com Date: Fri, 10 Apr 1998 16:59:24 -0400 (EDT) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, I am posting this document to solicit comments on the handling of the site boundary scenario. Please direct comments to the mailing list and/or to me. I want to thank Thomas Narten for reviewing the first pass of this document. Brian INTERNET DRAFT Brian Haberman April 1998 IBM Routing of Site-Scoped Addresses in the Internet Protocol Version 6 (IPv6) 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``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 ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document outlines a mechanism for generating routing tables that include site-scoped IPv6 addresses. It will define a set of rules for routers to follow in order to forward site-scoped addresses. Haberman Expires October 1998 [Page i] Internet Draft Routing of Site-Scoped Addresses April 1998 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Assumptions and Definitions 1 3. Single Site Routing 3 4. Site-Boundary Unicast Routing 3 4.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 3 4.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 5 5. Site-Boundary Multicast Routing 6 5.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 6 5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 6 6. Protocol Impact 6 Haberman Expires October 1998 [Page ii] Internet Draft Routing of Site-Scoped Addresses April 1998 1. Introduction This document defines a set of rules for the generation of forwarding tables that contain site-scoped addresses. This document will describe the handling of site-scoped addresses for both single-site and site-boundary routers. Ideally, these concepts should be included in follow-up drafts of IPv6 routing protocols. A preferred model for site-boundaries is depicted in Figure 1. In this model, each router is responsible for generating forwarding information for the global prefixes and exactly 1 site. The link between the routers is in neither site. In addition, routing information about Site Y is never propogated into Site X and routing information about Site X is never propogated into Site Y. This model is similar to that of net 10 in IPv4. ***** ***** * * * * * * * Router 1 Router 2 * +-*-+ +-*-+ | * | | * | Site X | * | ----------------- | * | Site Y | * | | * | +-*-+ +-*-+ * * * * * * * * ***** ***** Figure 1: Site Boundary Model The rest of this document describes the modifications needed in order to combine the functions of Router 1 and Router 2 into a single router. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Haberman Expires October 1998 [Page 1] Internet Draft Routing of Site-Scoped Addresses April 1998 2. Assumptions and Definitions This document makes several assumptions concerning sites : - Site boundaries cut through nodes - Site boundaries are identical for unicast and multicast traffic - A single interface can only be in one site - Each interface participating in a site has a site identifier - In the absence of explicit configuration, all site identifiers on a router default to the same value - Routers only advertise site prefixes on interfaces configured with site identifiers and site prefixes * * * * * Site ID = X * * * * * +-*---|--------|---*-+ | * i/f 1 i/f 2 * | | **************** | | | | | | Router | ***************** | | * | Site ID = Y - i/f 3 * i/f 4 - | * | ***************** | +--------------------+ Figure 2: Multi-Sited Router A single-site router is defined as a router configured with the same site identifier on all interfaces. A site-boundary router is defined as a router that has at least 2 distinct site identifiers configured. This could include a router connected to 2 distinct sites or a router connected to 1 site and a separate global network (Figure 2). Haberman Expires October 1998 [Page 2] Internet Draft Routing of Site-Scoped Addresses April 1998 3. Single Site Routing In a single-site router, a routing protocol can advertise and route all addresses and prefixes on all interfaces. This configuration does not require any special handling for site-local addresses. The reception and transmission of site-local addresses is handled in the same manner as globally scoped addresses. This applies to both unicast and multicast routing protocols. 4. Site-Boundary Unicast Routing With respect to site boundaries, routers must consider which interfaces a packet can be transmitted on as well as control the propogation of site-specific routing information. This includes controlling which prefixes can be advertised on an interface and what forwarding information can be sent to other routers out that interface. 4.1. Routing Protocols When a routing protocol determines that it is a site-boundary router, it must perform additional work in order to protect inter-site integrity and still maintain intra-site connectivity. In order to maintain connectivity, the routing protocol must be able to create forwarding information for the global prefixes as well as for all of the site prefixes defined in the router's site identifiers. The most straight forward way of doing this is to create up to (n + 1) routing tables; one for the global prefixes, if any, and one for each of the (n) sites. This will increase the protocol processing time, but is necessary for connectivity within sites. To protect inter-site integrity, routers must be selective in the forwarding information that is shared with neighboring routers. Routing protocols routinely transmit their routing information to neighboring routers. When a router is transmitting this routing information, it must not include any information about sites other than the site defined on the interface used to reach a neighbor. As an example, the router in Figure 3 must advertise routing information on four interfaces. The information advertised is as follows : - Interface 1 Haberman Expires October 1998 [Page 3] Internet Draft Routing of Site-Scoped Addresses April 1998 * * * * * Site ID = X * * * * * +-*---|--------|---*-+ i/f 1 : global prefix = 3FFE:20::/64 | * i/f 1 i/f 2 * | site prefix = FEC0:0:0:N/64 | **************** | | | i/f 2 : no global prefix | | site prefix = FEC0:0:0:K/64 | Router | ***************** | i/f 3 : global prefix = 3FFE:40::/64 | * | site prefix = FEC0:0:0:M/64 Site ID = Y - i/f 3 * i/f 4 - | * | i/f 4 : global prefix = 3FFE:80::/64 ***************** | no site prefix +--------------------+ Figure 3: Routing Information Exchange * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:N/64 * Site prefix FEC0:0:0:K/64 - Interface 2 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:N/64 * Site prefix FEC0:0:0:K/64 - Interface 3 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) * Site prefix FEC0:0:0:M/64 Haberman Expires October 1998 [Page 4] Internet Draft Routing of Site-Scoped Addresses April 1998 - Interface 4 * All global prefixes (3FFE:20::/64, 3FFE:40::/64, and 3FFE:80::/64) By imposing advertisement rules, site integrity is maintained by keeping all site routing information contained within the site. 4.2. Packet Forwarding In addition to the extra cost of generating additional forwarding information for each site, site-boundary routers must also do some additional checking when forwarding packets that contain site-local addresses. If a packet being forwarded contains a site-local destination address, regardless of the scope of the source address, the router must perform the following : - Lookup incoming interface's site identifier - Perform route lookup for destination address - Lookup outgoing interface's site identifier - Verify that the two site identifiers match The last two steps are required due to the fact that the two interfaces could be in different sites but have identical site-local prefixes. If a packet being forwarded contains a site-local source address and a globally-scoped destination address, there are two possible ways of handling it. The first way is to forward the packet based solely on the destination address. This leads to the possibility that the destination cannot send a response. The second option is to perform the same checks as outlined above for a site-local destination address. If this method is chosen, a new ICMPv6 message could be returned to the sender indicating there is a scoping mismatch. This would allow the sender the chance to use a higher scoped address. Haberman Expires October 1998 [Page 5] Internet Draft Routing of Site-Scoped Addresses April 1998 5. Site-Boundary Multicast Routing 5.1. Routing Protocols Multicast routing protocols will have to follow the same rules as the unicast protocols. They will be required to maintain information about global prefixes as well as information about all sites defined on the box. Protocols that rely on underlying unicast protocols will not suffer as much of a performance impact since the unicast protocol will handle the forwarding table generation. However, multicast protocols that generate and maintain their own routing tables will have to perform the additional route calculations for each site. 5.2. Packet Forwarding The forwarding rules for multicast can be described by the following combinations : - Global multicast destination address / Global unicast source address - Global multicast destination address / Site-local unicast source address - Site-scoped multicast destination address / Global unicast source address - Site-scoped multicast destination address / Site-local unicast source address The first combination should follow the same forwarding mechanisms that are in place today for IPv4 multicast. Combinations 3 and 4 should result in the router performing the same site identifiers check as outlined for site-local unicast destination addresses. Combination 2 could be handled in either manner. By performing the site identifier check, a source could be notified that there is a scoping mismatch and give it the opportunity to choose a higher scoped source address. This would require the definition of a new scoping mismatch ICMPv6 message. 6. Protocol Impact The performance impact on routing protocols is obvious. However, this impact should only be felt by those routers that exist on site boundaries. Realistically, a router would probably only be a boundary between either two sites or a site Haberman Expires October 1998 [Page 6] Internet Draft Routing of Site-Scoped Addresses April 1998 and the Internet. If site-scoped addresses are going to be realized, this performance impact may be acceptable. References [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1997. Security Considerations This document specifies a set of guidelines that allow routers to prevent site specific information from leaking out of each site. If site boundary routers allow site routing information to be forwarded outside of the site, the integrity of the site could be compromised. Acknowledgements I would like to thank Thomas Narten for doing the first reviews of this document. Author's Address Brian Haberman IBM Corporation 800 Park Office Drive Research Triangle Park, NC 27709 USA +1-919-254-2673 haberman@raleigh.ibm.com Haberman Expires October 1998 [Page 7] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 10 14:43:01 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA28064 for ipng-dist; Fri, 10 Apr 1998 14:34:56 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA28057 for ; Fri, 10 Apr 1998 14:34:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA18832 for ; Fri, 10 Apr 1998 14:34:43 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA18636 for ; Fri, 10 Apr 1998 14:34:41 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id RAA58912 for ; Fri, 10 Apr 1998 17:34:22 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA22094 for ; Fri, 10 Apr 1998 17:34:24 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id RAA18872 for ; Fri, 10 Apr 1998 17:34:37 -0400 (EDT) Message-Id: <199804102134.RAA18872@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 5664) Re: Multisited Nodes.. In-reply-to: Your message of "Wed, 08 Apr 1998 12:45:10 EDT." <9804081245.aa23253@khitomer.epilogue.com> Date: Fri, 10 Apr 1998 17:34:32 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I suggest that we restrict the use of scoped addresses by applications > >to the following cases: > > > >1) link local addresses in unconnected links, > > > >2) site local addresses in unconnected sites. > Restriction #2 is fairly easy to swallow, since the advantages of > site- local addressing remain more theoretical then practical. As far > as I know, most of us haven't really implemented all of the ins- > and-outs of site-local addressing, anyway (especially since the > ins-and-outs haven't been fully defined). One thing that I think that is making this discussion "interesting" is that I suspect that folks are all over the map with regards to what "supporting site-local addresses" really means. At one extreme, site-local addresses could be just like net 10 addresses, no more, no less. Nothing special has to happen with implementations, the stack and applications don't treat such addresses any differently. Where people do "bad idea" things such as try to connect two different sites to the same box, things just won't work. Solution: just say no to such configurations. Another extreme is that applications become aware of potential multi-sitedness, and have to do things to make the right thing happen if a host is (say) connected to three different sites. This will get *really* messy in a hurry (e.g., the suggestion that users be able to specify a site index in addtion to a DNS name when invoking telnet). My personal view is that we need site-local addresses for the same reasons net 10 has become popular. Or rather, we may not *need* them, but they will exist. If we don't have them in the architecture, folks will just pick some (hopefully) unused number to get the same effect. Thus, we need to try (within reason) to accomodate net 10 style prefixes. With that in mind, what do we believe the expected useage to be? My take: Individual sites will use them to get permanent numbers they can use across site renumberings as will sites that aren't (initially) connected to the Internet. In both of these scenarios, folks will use (some) common sense in numbering subnets (i.e., they'll use different subnet numbers on different links, etc.). Where I expect multiple sites to be a possibility is with corporate mergers/aquisitions. Situations where two formerly autonomous sites are forced to join. Note that in these cases we won't have very many (if any) individual boxes that are in both sites simultaneously. What we will have is multiple islands of overlapping site-local addresses. Some of these sites will simply have to renumber if they want to become one "great big happy site". I think the current proposals for the API are a positive avenue to pursue, because it may well be the case that some boxes (mostly routers IMO) will want to connect to two or more sites. The idea that adding things to the API that would in practice be transparent to most apps is doubly appealing. But I seriously question the idea that a significant fraction of the hosts will be multi-sited, and that we think this is a something we should try to encourage. One attractions of IPv6 is its potential for having a single large address space. Trying to support multiple address spaces leads us to some of the disadvantages of NAT. Another analogy that I've been thinking about is multihomed hosts in IPv4 (I'm talking about multiple interfaces per host, not multiple ISP connections). There is a "strict" and "weak" ES-IS model for describing what multihomed hosts should do (see RFC 1122). In the strict model, one conceptually has multiple IP stacks in the host, one for each interface. Each stack has its own routing table. Did anyone ever implement this model? Can we reasonably expect folks to do something similar now? My sense is that to correctly implement routing in multi-sited nodes will require something very close to implementing the strong model. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Apr 11 04:13:29 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id EAA28809 for ipng-dist; Sat, 11 Apr 1998 04:09:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id EAA28802 for ; Sat, 11 Apr 1998 04:09:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA10433 for ; Sat, 11 Apr 1998 04:09:31 -0700 Received: from mr.tuwien.ac.at (mr.tuwien.ac.at [128.130.2.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA24185 for ; Sat, 11 Apr 1998 04:09:32 -0700 (PDT) Received: from logo (actually logo.ikn.tuwien.ac.at) by mr.tuwien.ac.at with SMTP (PP); Sat, 11 Apr 1998 13:09:07 +0200 Message-Id: <3.0.3.32.19980411130204.009f76d0@mail.zserv.tuwien.ac.at> X-Sender: vanas@mail.zserv.tuwien.ac.at X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 11 Apr 1998 13:02:04 +0200 To: ipng@sunroof.eng.sun.com From: "Harmen R. van As" Subject: (IPng 5665) 8th IFIP Conference on High Performance Networking (HPN'98) Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear member of the IPNG community We still are looking for some papers for the HPN'98 Conference in Vienna. Would there be any change that you or somebody else would be able to submit a contribution within the next two weeks? Please notify coming submission With best regards Harmen R. van As
CALL FOR TUTORIALS CALL FOR PAPERS DEADLINE EXTENDED BUT NOTIFY COMING SUBMISSION ----------------------------------------------------------- 8th IFIP Conference on High Performance Networking (HPN'98) The Millennium Push of Internet =20 Vienna University of Technology, Vienna, Austria September 21-25, 1998 ------------------------------------------------------------ http://www.ikn.tuwien.ac.at/IKN/events/hpn-cfp.html March 15, 1998: Tutorial proposal March 15, 1998: Paper submission April 15, 1998: Notification May 15, 1998: Camera-ready paper =20 Conference book published by Chapman & Hall
Paper submission: preferably postscript file attached to email=20 otherwise 5 copies of paper by postal mail Topics of interest:=20 - Trends of Internet/Intranet Technologies=20 - Next Generation Internet, Evolutionary approaches=20 - Fast Internet (ADSL, HDSL, VHDSL, PONs)=20 - Cable Network, Wireless and Satellite Access=20 - Next Generation Routers, Tag Switching=20 - Bypass Tunneling (SDH, Photonics) =20 - Network/System Architecture and Design=20 - Cache Server Allocation and Interconnection=20 - Network Availability, Automatic Reconfiguration=20 - Coporate Networks, Global Networking =20 - Security in Internet, Network/System Security=20 - Network Management using Internet=20 - WWW and Java Network Service Management=20 - Distributed Systems Management in Internet=20 - Interworking with ATM, ISDN, and LANs=20 - System Interoperability =20 - Internet Mobility Support, Mobility Management=20 - Mobile-IP, Mobile-IPv6=20 - Mobile Agents, Intelligent/Smart Agents=20 - Flow Control, Traffic Monitoring and Control=20 - Adressing and Routing =20 - Advanced Internet Protocols (RTP, RSVP)=20 - Multicast Protocols=20 - Protocol Design, Combined ATM and IP=20 - Secure Protocols (S-HTTP, SSL, SET)=20 - Internet Tunneling =20 - Quality of Service, Service Level Guarantees=20 - Resource Management=20 - Real-Time Services over Internet=20 - IP Telephony, Voice over Internet=20 - Teleconferencing, Broadband Internet=20 - Integrated Services Internet=20 - Internet in Multimedia Environments=20 - Heterogenous Distributed Environments =20 - Internet Groupware and Cooperative Work=20 - Information Management over Internet=20 - Electronic Commerce, Online-Marketing=20 - Internet Payment Systems, Webcasting=20 - WWW Servers, Tele-Service-Systems=20 - Internet Servers (Data-Base, Cache, Archive)=20 - High-Performance Tele-Activities=20 - Social Impacts, Opportunities and Threats=20 INTERNATIONAL PROGRAM COMMITTEE:=20 General Chair:=20 Harmen R. van As, Vienna University of Technology, Austria=20 Ian Akyildiz, Georgia Tech, USA=20 Torsten Braun, Univ. of Berne, CH=20 Augusto Casaca, INESC, Portugal=20 Andre Danthine, Univ. Liege, Belgium=20 Michel Diaz, Univ. Toulouse, France=20 Christophe Diot, INRIA, France=20 Otto Duarte, Univ. Fed. Rio de Janeiro, Brazil=20 J=F6rg Ebersp=E4cher, Techn. Univ. Munich, Germany=20 Serge Fdida, Univ. Paris VI, France=20 Zygmunt Haas, Cornell University, USA=20 Marjory Johnson, NASA-RIACS, USA=20 Paul K=FChn, Univ. Stuttgart, Germany=20 Ralf Lehnert, Dresden Univ. of Technology, Germany=20 Helmut Leopold, Alcatel, Austria=20 Kurt Maly, Old Dominion Univ., USA=20 Olli Martikainen, Helsinki Univ. of Technology, Finland=20 Georg Mittenecker, Vienna Univ. of Technology, Austria=20 Hussein Mouftah, Queens Univ., Canada=20 Ignas Niemegeers, Univ. of Twente, The Netherlands=20 Guru Parulkar, Washington U. St. Louis, USA=20 Stephen Pink, SICS, Sweden=20 Radu Popescu-Zeletin, GMD Fokus, Germany=20 Ramon Puigjanier, Univ. Illes Balears, Spain=20 Guy Pujolle, Univ. Versailles, France=20 Doug Shepherd, Univ. Lancaster, UK=20 Thomas Sommer, Vienna Univ. of Technology, Austria=20 Otto Spaniol, Univ. Aachen, Germany=20 Ralf Steinmetz, Techn. Univ. Darmstadt, Germany=20 Ahmed Tantawi, IBM Res., Yorktown Heights, USA=20 Fouad Tobagi, Stanford Univ., USA=20 Samir Tohm=E9, ENST, France=20 Giorgio Ventre, Univ. Napoli, Italy=20 Martina Zitterbart, Univ. Braunschweig, Germany=20 ---------------------------------------------------------------------------- Prof.Dr. Harmen R. van As Institute of Communication Networks Vienna University of Technology Tel +43-1-58801-5246 Gusshausstrasse 25/388 Fax +43-1-5870583 A-1040 Vienna, Austria email: Harmen.R.van-As@tuwien.ac.at http://www.ikn.tuwien.ac.at=20 ---------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Apr 12 12:04:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id LAA00473 for ipng-dist; Sun, 12 Apr 1998 11:58:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id LAA00466 for ; Sun, 12 Apr 1998 11:58:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA20775 for ; Sun, 12 Apr 1998 11:58:35 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA01129 for ; Sun, 12 Apr 1998 11:58:37 -0700 (PDT) Received: from spruce.iprg.nokia.com ([205.226.22.76]) by mailhost.iprg.nokia.com (8.6.11/8.6.10) with SMTP id LAA12834; Sun, 12 Apr 1998 11:58:28 -0700 Message-Id: <3.0.5.32.19980412115717.00a75770@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sun, 12 Apr 1998 11:57:17 -0700 To: Steve Soule From: Bob Hinden Subject: (IPng 5668) Re: Destination Address Ambiguity Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199804111823.LAA04962@mailrelay.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >Node A with address A.1 has an open TCP connection from port P to >port Q on node B with address B.1. Suppose B also has address B.2. >Assume A.1, B.1, and B.2 are all globallly routable unicast addresses. >Suppose B receives a TCP packet with source address A.1, source port P, >destination port Q, and destination address B.2. Does node B consider >this packet to be part of the existing TCP connection, or a new one? > >In my opinion, the answer should be "same connection". But this is >not clearly specified in draft-ietf-ipngwg-ipv6-spec-v2-01.txt. > >In general, should layers above IPv6 treat packets with the same >identifying information but different (but equivalent) destination >addresses as the same? > >Again, in my opinion, the answer should be "yes". It is not so simple and does not work with the current definition of TCP. There has been some discussion about changing TCP (i.e., TCPng) to make it handle things like this, but it is beyond the scope of the IPv6 working group. Once one starts looking at changing what TCP uses to identify connections many issues arise. I suggest you read: "Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6" at http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-02.txt It explores some of the issues. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Apr 12 14:21:40 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA00699 for ipng-dist; Sun, 12 Apr 1998 14:15:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA00692 for ; Sun, 12 Apr 1998 14:15:30 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA26796 for ; Sun, 12 Apr 1998 14:15:28 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA29129 for ; Sun, 12 Apr 1998 14:15:28 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id QAA25273; Sun, 12 Apr 1998 16:13:13 -0500 (CDT) Date: Sun, 12 Apr 1998 16:13:13 -0500 (CDT) From: David Borman Message-Id: <199804122113.QAA25273@frantic.bsdi.com> To: akephart@austin.ibm.com, thartric@mentat.com Subject: (IPng 5670) Re: Changes for Basic API for multisite nodes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew and Tim, > > Maybe I missed it the first time around, but what was the > > rationale for not putting the new fields at the end? I know that the > > spec allows us as implementors to vary it, but I think that most > > implementors will probably go with whatever is specified here for > > compatibility's sake. > > > > Since there are already folks out there using the API, it would > > seem to make sense to try and maintain binary compatibility wherever > > possible... > > > > My rationale was that for every system with which I am familiar binary com- > patibility is broken as soon as the structure size changes. Where you put > the fields is window dressing compared to the size change. It is easier to maintain binary compatability if you just add to the end of the structure, and don't change the existing elements of the structure. Then (with extra code) the kernel can recognize old calls made with a shorter sockaddr structure; on input you zero out the extra space, and on output you truncate the copy. If you reorder the elements, then you have to do a bunch more copying around for compability. But then again, these are internal data structures (they don't go out on the wire). And though the elements may be listed in the standard in a particular order, there is no requirement that they be implemented in that order, or that there can't be other elements, right? You just have to make sure that you have at least the listed elements. Any user code that depends on the order of the structure elements would not be portable. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 07:21:22 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id HAA01550 for ipng-dist; Mon, 13 Apr 1998 07:16:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id HAA01543 for ; Mon, 13 Apr 1998 07:15:55 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA12733 for ; Mon, 13 Apr 1998 07:15:54 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA04543 for ; Mon, 13 Apr 1998 07:15:54 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA19672; Mon, 13 Apr 1998 09:15:48 -0500 Message-Id: <199804131415.JAA19672@gungnir.fnal.gov> To: Steve Soule , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5672) Re: Destination Address Ambiguity In-reply-to: Your message of Sun, 12 Apr 1998 11:57:17 PDT. <3.0.5.32.19980412115717.00a75770@mailhost.iprg.nokia.com> Date: Mon, 13 Apr 1998 09:15:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > In my opinion, the answer should be "same connection". But this is > > not clearly specified in draft-ietf-ipngwg-ipv6-spec-v2-01.txt. > > > > In general, should layers above IPv6 treat packets with the same > > identifying information but different (but equivalent) destination > > addresses as the same? > > > > Again, in my opinion, the answer should be "yes". This would break a lot of existing practice. Many web servers have multiple IP addresses and treat them as pointing to the roots of different HTML spaces. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 08:00:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id HAA01586 for ipng-dist; Mon, 13 Apr 1998 07:56:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id HAA01579 for ; Mon, 13 Apr 1998 07:56:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA23571 for ; Mon, 13 Apr 1998 07:56:35 -0700 Received: from epilogue.com (khitomer.epilogue.com [128.224.1.172]) by earth.sun.com (8.8.8/8.8.8) with SMTP id HAA24858 for ; Mon, 13 Apr 1998 07:56:35 -0700 (PDT) From: Margaret Wasserman To: hinden@iprg.nokia.com CC: soule@math.brown.edu, ipng@sunroof.eng.sun.com In-reply-to: <3.0.5.32.19980412115717.00a75770@mailhost.iprg.nokia.com> (message from Bob Hinden on Sun, 12 Apr 1998 11:57:17 -0700) Subject: (IPng 5673) Re: Destination Address Ambiguity Date: Mon, 13 Apr 98 10:56:22 -0400 Message-ID: <9804131056.aa23689@khitomer.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Node A with address A.1 has an open TCP connection from port P to >port Q on node B with address B.1. Suppose B also has address B.2. >Assume A.1, B.1, and B.2 are all globallly routable unicast addresses. >Suppose B receives a TCP packet with source address A.1, source port P, >destination port Q, and destination address B.2. Does node B consider >this packet to be part of the existing TCP connection, or a new one? Node B must consider this to be a different connection (and act accordingly), because node A will. There isn't any way that the TCP code on node A could know that addresses B.1 and B.2 identify the same node. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 08:39:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id IAA01742 for ipng-dist; Mon, 13 Apr 1998 08:35:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA01735 for ; Mon, 13 Apr 1998 08:35:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA29489 for ; Mon, 13 Apr 1998 08:35:02 -0700 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA16640 for ; Mon, 13 Apr 1998 08:34:57 -0700 (PDT) Message-Id: <199804131534.IAA16640@earth.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA145891779; Mon, 13 Apr 1998 11:36:20 -0400 To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5674) Re: Destination Address Ambiguity In-Reply-To: Your message of "Mon, 13 Apr 1998 09:15:47 EDT." <199804131415.JAA19672@gungnir.fnal.gov> Date: Mon, 13 Apr 1998 11:36:15 -0400 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199804131415.JAA19672@gungnir.fnal.gov>, "Matt Crawford" writes: > > > In my opinion, the answer should be "same connection". But this is > > > not clearly specified in draft-ietf-ipngwg-ipv6-spec-v2-01.txt. > > > > > > In general, should layers above IPv6 treat packets with the same > > > identifying information but different (but equivalent) destination > > > addresses as the same? > > > > > > Again, in my opinion, the answer should be "yes". > > This would break a lot of existing practice. Many web servers have > multiple IP addresses and treat them as pointing to the roots of > different HTML spaces. I'm guessing that what you mean by this is that the IP and UDP layers treat the addresses as equivalent, but the web server treats them as different. What if a node had addresses A.1, B.1, C.1, and C.2, and C.1 and C.2 were supposed to be equivalent, but A, B, and C were supposed to look like different web servers? Would the web server's configuration file list all four addresses and have some notation for indicating that C.1 and C.2 both give the same URL space? In such a server, are raw addresses or domain names used in the configuration file? According to the Apache docs, it accepts either, but the docs imply that a domain name maps to exactly one address. I'm guessing that at the very least, Apache will have to be modified to handle the fact that in IPv6, a domain name maps to more than one address. It then would listen for requests on all of the addresses associated with the domain name. (According to the Apache docs, by default it listens for all incoming HTTP connections, regardless of their destination address.) So it seems to me that a web server might very well thrive on an implementation that provided a mechanism whereby it could indicate that as far as it's concerned, a group of IP addresses assigned to the node are equivalent. However, this suggests that to make my idea work well, the bind() system call really ought to be modified (or a more powerful version created) so that it can be given a list of addresses, or maybe a domain name, rather than just a single address or the unspecified address as it is now. Or maybe it would be better if the IP layer had some notion of subsets of its addresses that ought to be considered equivalent, and a bind() call for one of the addresses in a group would bind to all of those addresses. In any case, I think you have pointed out something I hadn't considered: this isn't just a flaw in the IPv6 base specification, but in the API as well. Or perhaps a better way of putting it would be that in order for a node to take advantage of the fact that it can have multiple addresses in IPv6, the current API is not sufficient, since the bind call can only be told a single address or all of the node's addresses, rather than a subset or some notation such as a domain name that would imply a subset. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 09:06:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA01771 for ipng-dist; Mon, 13 Apr 1998 09:01:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA01764 for ; Mon, 13 Apr 1998 09:00:51 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA06529 for ; Mon, 13 Apr 1998 09:00:49 -0700 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA02919 for ; Mon, 13 Apr 1998 09:00:44 -0700 (PDT) Message-Id: <199804131600.JAA02919@earth.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA150523309; Mon, 13 Apr 1998 12:01:49 -0400 To: Margaret Wasserman Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: (IPng 5675) Re: Destination Address Ambiguity In-Reply-To: Your message of "Mon, 13 Apr 1998 10:56:22 EDT." <9804131056.aa23689@khitomer.epilogue.com> Date: Mon, 13 Apr 1998 12:01:48 -0400 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9804131056.aa23689@khitomer.epilogue.com>, Margaret Wasserman write s: > >Node A with address A.1 has an open TCP connection from port P to > >port Q on node B with address B.1. Suppose B also has address B.2. > >Assume A.1, B.1, and B.2 are all globallly routable unicast addresses. > >Suppose B receives a TCP packet with source address A.1, source port P, > >destination port Q, and destination address B.2. Does node B consider > >this packet to be part of the existing TCP connection, or a new one? > > Node B must consider this to be a different connection (and act > accordingly), because node A will. There isn't any way that the TCP > code on node A could know that addresses B.1 and B.2 identify the same > node. What if node A has some as-yet-unspecified mechanism for knowing that B.1 and B.2 identify the same node? Maybe it knows that B.1 is deprecated and it's just trying its best to avoid losing its connections. I don't think this is a TCP problem. TCP shouldn't have to worry about multiple addresses--it should just provide reliable streaming between nodes. So I think perhaps it would be the IP code, not the TCP code, on A that would determine that B.1 and B.2 were the same. Of course, the mechanism that node A would use has not yet been specified, so this is all just speculation. Is it desirable to have the two packets associated with different connections? Is there a case when we want node A to be able to open two TCP connections from the same port to the same destination node with different addresses? It seems to me that doing this should be discouraged (in which case, treating the packets as being part of the same connection might be a good way to discourage it). But perhaps you have a specific example in mind where this behavior is important. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 09:51:42 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA01883 for ipng-dist; Mon, 13 Apr 1998 09:44:37 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA01876 for ; Mon, 13 Apr 1998 09:44:28 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA08059 for ; Mon, 13 Apr 1998 09:44:26 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA16310 for ipng@sunroof.eng.sun.com; Mon, 13 Apr 1998 09:44:11 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA00316 for ; Sun, 12 Apr 1998 09:31:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA14101 for ; Sun, 12 Apr 1998 09:31:17 -0700 Received: from mx1.landsraad.net (chusuk.arrakis.es [195.5.65.35]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA00428 for ; Sun, 12 Apr 1998 09:31:09 -0700 (PDT) Received: from Limbornio (ii-161.arrakis.es [195.5.78.161]) by mx1.landsraad.net (8.8.6/8.7.3) with SMTP id SAA27386 for ; Sun, 12 Apr 1998 18:30:15 +0200 (MET DST) Date: Sun, 12 Apr 1998 18:30:15 +0200 (MET DST) Message-Id: <199804121630.SAA27386@mx1.landsraad.net> X-Sender: rss@pop.arrakis.es X-Mailer: Windows Eudora Light Versión 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: Rafa Subject: (IPng 5678) IPv6 version 2 typographic correction Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's a little typographic correction of "draft-ietf-ipngwg-ipv6-spec-v2-01". In the point 6 (Flow Labels), in the 4th parragraph it is said that ... "New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFFF hex" If Flow Label is a field of 20 bits (not 24) the upper limit should be FFFFF. We must supress that extra 'F'. Regards. - - - - - - - - - - - - - - - - - - - - - - - - - - - Rafael Sanchez Sanchez rss@arrakis.es MADRID / SPAIN - - - - - - - - - - - - - - - - - - - - - - - - - - - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 09:51:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA01839 for ipng-dist; Mon, 13 Apr 1998 09:41:42 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA01826 for ; Mon, 13 Apr 1998 09:41:34 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA07679 for ; Mon, 13 Apr 1998 09:41:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA16274 for ipng@sunroof.eng.sun.com; Mon, 13 Apr 1998 09:41:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id LAA29283 for ; Sat, 11 Apr 1998 11:23:38 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA14632 for ; Sat, 11 Apr 1998 11:23:35 -0700 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA02941 for ; Sat, 11 Apr 1998 11:23:36 -0700 (PDT) Message-Id: <199804111823.LAA02941@earth.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA002299155; Sat, 11 Apr 1998 14:25:55 -0400 To: ipng@sunroof.eng.sun.com, deering@cisco.com, hinden@ipsilon.com Subject: (IPng 5676) Destination Address Ambiguity Date: Sat, 11 Apr 1998 14:25:54 -0400 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think I've found an ambiguity in the IPv6 specifications. Consider the following example: Node A with address A.1 has an open TCP connection from port P to port Q on node B with address B.1. Suppose B also has address B.2. Assume A.1, B.1, and B.2 are all globallly routable unicast addresses. Suppose B receives a TCP packet with source address A.1, source port P, destination port Q, and destination address B.2. Does node B consider this packet to be part of the existing TCP connection, or a new one? In my opinion, the answer should be "same connection". But this is not clearly specified in draft-ietf-ipngwg-ipv6-spec-v2-01.txt. In general, should layers above IPv6 treat packets with the same identifying information but different (but equivalent) destination addresses as the same? Again, in my opinion, the answer should be "yes". I have not written any IPv6 code, but I would guess that all existing implementations behave this way (that is, they treat their addresses as equivalent as destinations in packets they receive). Is that so? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 09:51:50 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA01857 for ipng-dist; Mon, 13 Apr 1998 09:42:07 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA01845 for ; Mon, 13 Apr 1998 09:41:47 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA16874 for ; Mon, 13 Apr 1998 09:41:44 -0700 Received: from frantic.bsdi.com (frantic.BSDI.COM [205.230.227.254]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA27158 for ; Mon, 13 Apr 1998 09:41:44 -0700 (PDT) Received: (from dab@localhost) by frantic.bsdi.com (8.8.8/8.8.8) id LAA26361; Mon, 13 Apr 1998 11:38:58 -0500 (CDT) Date: Mon, 13 Apr 1998 11:38:58 -0500 (CDT) From: David Borman Message-Id: <199804131638.LAA26361@frantic.bsdi.com> To: mrf@epilogue.com, soule@math.brown.edu Subject: (IPng 5677) Re: Destination Address Ambiguity Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > Subject: (IPng 5675) Re: Destination Address Ambiguity > Date: Mon, 13 Apr 1998 12:01:48 -0400 > From: Steve Soule > > In message <9804131056.aa23689@khitomer.epilogue.com>, Margaret Wasserman write > s: > > >Node A with address A.1 has an open TCP connection from port P to > > >port Q on node B with address B.1. Suppose B also has address B.2. > > >Assume A.1, B.1, and B.2 are all globallly routable unicast addresses. > > >Suppose B receives a TCP packet with source address A.1, source port P, > > >destination port Q, and destination address B.2. Does node B consider > > >this packet to be part of the existing TCP connection, or a new one? > > > > Node B must consider this to be a different connection (and act > > accordingly), because node A will. There isn't any way that the TCP > > code on node A could know that addresses B.1 and B.2 identify the same > > node. > > What if node A has some as-yet-unspecified mechanism for knowing > that B.1 and B.2 identify the same node? Maybe it knows that B.1 > is deprecated and it's just trying its best to avoid losing its > connections. A TCP connection is identified by the quintuple: {source address, source port, destination address, destination port} It doesn't matter whether the addresses are IPv4 or IPv6. If you change any of those 4 parts, you identify a different TCP connection. If you want to be able to change B.1 to B.2 and have the connection survive, then you are addressing the same problem of making TCP connections survive across IP renumbering. If you want packets identified as {A.1, P, B.1, Q} and {A.1, P, B.2, Q} to be associated with a single TCP connection, then you are proposing something beyond the current scope of TCP. Not that that is a bad idea, but it is not within the current TCP specification. The only change for TCP/IPv6 versus TCP/IPv4 is the definition of the pseudo header to accommodate the larger addresses in IPv6. > I don't think this is a TCP problem. TCP shouldn't have to worry > about multiple addresses--it should just provide reliable streaming > between nodes. So I think perhaps it would be the IP code, not the TCP provide a data stream between two endpoints, where those endpoints are identified by individual IP addresses and port numbers, not groups of IP addresses. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 09:51:54 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA01893 for ipng-dist; Mon, 13 Apr 1998 09:45:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA01886 for ; Mon, 13 Apr 1998 09:45:21 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA17891 for ; Mon, 13 Apr 1998 09:45:19 -0700 Received: from mail1-b.microsoft.com (mail1-b.microsoft.com [131.107.3.125]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA29041 for ; Mon, 13 Apr 1998 09:45:20 -0700 (PDT) Received: by INET-IMC-01 with Internet Mail Service (5.5.2166.0) id <2YCQFMK2>; Mon, 13 Apr 1998 09:45:00 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF111265@red-msg-52.dns.microsoft.com> From: Brian Zill To: "'Steve Soule'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5679) Re: Destination Address Ambiguity Date: Mon, 13 Apr 1998 09:44:59 -0700 X-Mailer: Internet Mail Service (5.5.2166.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Before this misunderstanding gets too out of hand, let me point out that there is nothing different here between IPv6 and IPv4. This is an issue for multi-homed nodes using either protocol. TCP connections are distinguished (among other things) by the IP addresses of the endpoints, and IP addresses belong to interfaces, NOT nodes. > -----Original Message----- > From: Steve Soule [SMTP:soule@math.brown.edu] > Sent: Monday, April 13, 1998 8:36 AM > To: Matt Crawford > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 5674) Re: Destination Address Ambiguity > > In message <199804131415.JAA19672@gungnir.fnal.gov>, "Matt Crawford" > writes: > > > > In my opinion, the answer should be "same connection". But this is > > > > not clearly specified in draft-ietf-ipngwg-ipv6-spec-v2-01.txt. > > > > > > > > In general, should layers above IPv6 treat packets with the same > > > > identifying information but different (but equivalent) destination > > > > addresses as the same? > > > > > > > > Again, in my opinion, the answer should be "yes". > > > > This would break a lot of existing practice. Many web servers have > > multiple IP addresses and treat them as pointing to the roots of > > different HTML spaces. > > I'm guessing that what you mean by this is that the IP and UDP layers > treat the addresses as equivalent, but the web server treats them > as different. > To be specific, no. IP (and thus TCP and UDP) treats the addresses as distinct. What Matt was pointing out is that many web servers in the IPv4 world today rely upon this feature to disambiguate requests (between the different virtual web servers a single physical web server is hosting). --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 09:56:45 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA01920 for ipng-dist; Mon, 13 Apr 1998 09:49:55 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA01913 for ; Mon, 13 Apr 1998 09:49:47 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA08847 for ; Mon, 13 Apr 1998 09:49:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA16349 for ipng@sunroof.eng.sun.com; Mon, 13 Apr 1998 09:49:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id NAA00618 for ; Sun, 12 Apr 1998 13:25:28 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA24809 for ; Sun, 12 Apr 1998 13:25:26 -0700 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA18578 for ; Sun, 12 Apr 1998 13:25:12 -0700 (PDT) Message-Id: <199804122025.NAA18578@earth.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA080852840; Sun, 12 Apr 1998 16:27:21 -0400 To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5680) Re: Destination Address Ambiguity In-Reply-To: Your message of "Sun, 12 Apr 1998 11:57:17 EDT." <3.0.5.32.19980412115717.00a75770@mailhost.iprg.nokia.com> Date: Sun, 12 Apr 1998 16:27:19 -0400 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3.0.5.32.19980412115717.00a75770@mailhost.iprg.nokia.com>, Bob Hind en writes: > It is not so simple and does not work with the current definition of TCP. Could you be more specific? > There has been some discussion about changing TCP (i.e., TCPng) to make it > handle things like this, but it is beyond the scope of the IPv6 working group > . What sort of change to TCP were you thinking of? The change/clarification I was suggesting was to IP, not TCP. > Once one starts looking at changing what TCP uses to identify connections > many issues arise. I suggest you read: > > "Separating Identifiers and Locators in Addresses: An Analysis of the GSE > Proposal for IPv6" at > > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-02.txt > > It explores some of the issues. I've read that. It does not seem relevant. For that matter, I can't think of any possible uses for ESDs (except maybe for link layer purposes, for example, in addrconf). It's odd that you used the phrase, "changing what TCP uses to identify connections". Did you think that I was suggesting that something other than the IP addresses and ports be used? Note that I was only bringing up one small case: the case when a node receives two packets, each validly addressed to it, but with different destination addresses. Does the node have to pretend that it's two different nodes simply because it has two valid addresses, or can it treat these two packets as having the same destination? There is no security issue here that I can see. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 10:40:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id KAA02231 for ipng-dist; Mon, 13 Apr 1998 10:34:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id KAA02224 for ; Mon, 13 Apr 1998 10:34:15 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA01515 for ; Mon, 13 Apr 1998 10:34:12 -0700 Received: from cdsms.cdc.com (cdsms.cdc.com [129.179.192.11]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA00253 for ; Mon, 13 Apr 1998 10:34:13 -0700 (PDT) Received: from thughes.sta.cdc.com by cdsms.cdc.com; Mon, 13 Apr 1998 12:34:10 -0500 Received: by localhost with Microsoft MAPI; Mon, 13 Apr 1998 10:39:11 -0700 Message-ID: <01BD66C8.65166220.anthony.m.hughes@cdc.com> From: Tony Hughes To: "'Steve Soule'" , "ipng@sunroof.Eng.Sun.COM" , "deering@cisco.com" , "hinden@ipsilon.com" Subject: (IPng 5681) RE: Destination Address Ambiguity Date: Mon, 13 Apr 1998 10:39:09 -0700 Organization: Control Data Systems, Inc. STAOPS X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My guess would be that the App layer would handle this and not the transport. The transport would see two connections: {A1,P1,B1,Q1} and {A1,P2,B2,Q2} The app layer would know that these go to the same place and treat them as the same connection. -----Original Message----- From: Steve Soule [SMTP:soule@math.brown.edu] Sent: Saturday, April 11, 1998 11:26 AM To: ipng@sunroof.Eng.Sun.COM; deering@cisco.com; hinden@ipsilon.com Subject: (IPng 5676) Destination Address Ambiguity I think I've found an ambiguity in the IPv6 specifications. Consider the following example: Node A with address A.1 has an open TCP connection from port P to port Q on node B with address B.1. Suppose B also has address B.2. Assume A.1, B.1, and B.2 are all globallly routable unicast addresses. Suppose B receives a TCP packet with source address A.1, source port P, destination port Q, and destination address B.2. Does node B consider this packet to be part of the existing TCP connection, or a new one? In my opinion, the answer should be "same connection". But this is not clearly specified in draft-ietf-ipngwg-ipv6-spec-v2-01.txt. In general, should layers above IPv6 treat packets with the same identifying information but different (but equivalent) destination addresses as the same? Again, in my opinion, the answer should be "yes". I have not written any IPv6 code, but I would guess that all existing implementations behave this way (that is, they treat their addresses as equivalent as destinations in packets they receive). Is that so? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 16:59:27 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id QAA02717 for ipng-dist; Mon, 13 Apr 1998 16:55:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id QAA02710 for ; Mon, 13 Apr 1998 16:55:12 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA28827 for ; Mon, 13 Apr 1998 16:55:11 -0700 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA09152 for ; Mon, 13 Apr 1998 16:55:11 -0700 (PDT) Message-Id: <199804132355.QAA09152@earth.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA220591833; Mon, 13 Apr 1998 19:57:13 -0400 To: Brian Zill Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5682) Re: Destination Address Ambiguity In-Reply-To: Your message of "Mon, 13 Apr 1998 09:44:59 EDT." <4FD6422BE942D111908D00805F3158DF111265@red-msg-52.dns.microsoft.com> Date: Mon, 13 Apr 1998 19:57:12 -0400 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <4FD6422BE942D111908D00805F3158DF111265@red-msg-52.dns.microsoft.com >, Brian Zill writes: > Before this misunderstanding gets too out of hand, let me point out that > there is nothing different here between IPv6 and IPv4. This is an issue for > multi-homed nodes using either protocol. TCP connections are distinguished > (among other things) by the IP addresses of the endpoints, and IP addresses > belong to interfaces, NOT nodes. I agree that this is a problem with both IPv6 and IPv4, but it's too late to fix IPv4 now. > > I'm guessing that what you mean by this is that the IP and UDP layers > > treat the addresses as equivalent, but the web server treats them > > as different. > > > To be specific, no. IP (and thus TCP and UDP) treats the addresses as > distinct. What Matt was pointing out is that many web servers in the IPv4 > world today rely upon this feature to disambiguate requests (between the > different virtual web servers a single physical web server is hosting). You're right; I mispoke. I should have said that IP and TCP treat the addresses as all belonging to the node, while the web server treats them as belonging to different nodes. I understood Matt's example. Perhaps my response to his message wasn't clear. I'm not advocating that the IP layer should trick the higher layers into thinking that the node only has one address. I am suggesting that in IPv6 an upper layer will often get packets with different but theoretically equivalent destination addresses, and that it should say in the specs that all upper layers should do something intelligent about this, rather than creating a multitude of virtual hosts as they say to do now. An application like a web server that wants to have multiple virtual hosts certainly ought to be allowed to do so. But the specification currently requires that such a server have a separate listening socket or even a separate server for every address the node has configured. Presumably if there's any kind of renumbering, new web servers will have to be started and old ones killed off. This is not right--the web server wants multiple virtual hosts, not just multiple addresses. It ought to be able to listen for incoming connections targeted at any of the addresses of a particular virtual host, no matter what those addresses are, how many there are, or what their lifetimes are. In IPv4, each virtual host has exactly one address, so there's no ambiguity. But I don't think it is the intention of IPv6 that a node create a different virtual node for each of its many addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 17:46:27 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id RAA02782 for ipng-dist; Mon, 13 Apr 1998 17:41:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id RAA02775 for ; Mon, 13 Apr 1998 17:41:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA18243 for ; Mon, 13 Apr 1998 17:41:08 -0700 Received: from jacobi.math.brown.edu (jacobi.math.brown.edu [128.148.194.43]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id RAA02743 for ; Mon, 13 Apr 1998 17:40:58 -0700 (PDT) Message-Id: <199804140040.RAA02743@earth.sun.com> Received: from gauss (localhost) by jacobi.math.brown.edu with ESMTP (1.37.109.24/16.2) id AA224194578; Mon, 13 Apr 1998 20:42:59 -0400 To: ipng@sunroof.eng.sun.com, deering@cisco.com, hinden@ipsilon.com Subject: (IPng 5683) Re: Destination Address Ambiguity In-Reply-To: Your message of "Sat, 11 Apr 1998 14:25:54 EDT." <199804111823.LAA02941@earth.sun.com> Date: Mon, 13 Apr 1998 20:42:58 -0400 From: Steve Soule Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've gotten a lot of replies now that have strongly hinted that I'm pretty stupid. Let me try to put my original message in some more context. I see a major problem in IPv6 in that it does not include Transparent Renumbering. I don't think Transparent Renumbering will be finished in time to be included in the base IPv6 specifications (though I would prefer if it were). I believe that TR, once completed, will be mostly an IP-layer mechanism, though it may require many small changes to upper layers. Ultimately, I think renumbering and multihoming (and maybe somehow anycasting too) will use a simple model in which groups of addresses are considered, at the IP layer, to be interchangeable. Of course, any packet at any one time can have only one source address and one destination address, so there would probably be some system by which one of a group of addresses is preferred (possibly on a socket by socket basis). One of the problems that would have to be solved is the problem of security, or, "How can one determine for sure that some addresses are equivalent?" I am not addressing this problem at this time. In one case, however, there is no security issue: the case of the addresses of a node when considered by the node itself. Since a node cannot, at this time, tell another node what its addresses are securely, it must be certain to consistently use just one of its addresses as source addresses of packets in any one interaction. This is not a problem. (Hopefully implementations of IPv6 do this?) But when seen as destination addresses, a node's addresses can easily be treated as equivalent. No interaction with any other node need take place to determine this; the node has to know its own addresses in order to receive the packets at all. So think of my suggestion as phase one of Transparent Renumbering. If node B can accept packets with various of its addresses as destination addresses as equivalent, and node A has a full TR implementation, then node B can renumber (or be multihomed, or maybe even deal with having an anycast address) transparently. Perhaps I am mistaken, but I don't think node B needs anything more (at any layer). Perhaps this argument is too vague for action to be considered at this time. If so, then please ignore my idea and wait until someone comes out with a full and glorious Transparent Renumbering system. I'm a bit frustrated by the fact that the current IPv6 specs are so close to making this half of Transparent Renumbering work, but with (from my point of view, trivial) philosophical underpinnings that prohibit it. I believe that it really is more sensible for a node to treat its addresses as equivalent (except for handy virtual node cases such as the one Matt brought up), if this can be made to work. I received several messages whose purpose was to remind me that a TCP connection is identified by the endpoints and port numbers, and that endpoints are the same thing as IP addresses. Why not consider endpoints to be nodes (or virtual nodes) instead? (With behavior specified so that by default, an IP address is sufficient identificaiton for the node.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 18:29:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id SAA02869 for ipng-dist; Mon, 13 Apr 1998 18:22:26 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id SAA02862 for ; Mon, 13 Apr 1998 18:22:17 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA04754 for ; Mon, 13 Apr 1998 18:22:15 -0700 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA22512 for ; Mon, 13 Apr 1998 18:22:12 -0700 (PDT) Received: from rhine.sm.sony.co.jp (rhine.sm.sony.co.jp [133.138.10.37]) by onoe2.sm.sony.co.jp (8.8.5/Sony6.1MX) with ESMTP id KAA18550; Tue, 14 Apr 1998 10:21:51 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by rhine.sm.sony.co.jp (8.8.7/8.8.7) with ESMTP id JAA13819; Tue, 14 Apr 1998 09:44:01 +0900 (JST) Message-Id: <199804140044.JAA13819@rhine.sm.sony.co.jp> To: dab@BSDI.COM Cc: mrf@epilogue.com, soule@math.brown.edu, hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: (IPng 5684) Re: Destination Address Ambiguity In-Reply-To: Your message of "Mon, 13 Apr 1998 11:38:58 -0500 (CDT)" References: <199804131638.LAA26361@frantic.bsdi.com> X-Mailer: Mew version 1.52 on Emacs 19.28.1, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 14 Apr 1998 09:44:01 +0900 From: Atsushi Onoe Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A TCP connection is identified by the quintuple: > {source address, source port, destination address, destination port} > It doesn't matter whether the addresses are IPv4 or IPv6. In IPv6 case, the interface (or site) identifier should be considered to identify a TCP connection at the TCP layer. For example, there would be two different connections as follows: foreign addr, foreign port, local addr, local port, interface fe80::1, 2000, fe80::2, 80 1 (ppp0) fe80::1, 2000, fe80::2, 80 2 (ppp1) Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 19:18:16 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id TAA02939 for ipng-dist; Mon, 13 Apr 1998 19:14:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id TAA02932 for ; Mon, 13 Apr 1998 19:14:03 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA18701 for ; Mon, 13 Apr 1998 19:14:02 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA16696 for ; Mon, 13 Apr 1998 19:14:03 -0700 (PDT) From: Masataka Ohta Message-Id: <199804140204.LAA05585@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA05585; Tue, 14 Apr 1998 11:04:35 +0900 Subject: (IPng 5685) Re: Destination Address Ambiguity To: hinden@iprg.nokia.com (Bob Hinden) Date: Tue, 14 Apr 98 11:04:35 JST Cc: soule@math.brown.edu, ipng@sunroof.eng.sun.com In-Reply-To: <3.0.5.32.19980412115717.00a75770@mailhost.iprg.nokia.com>; from "Bob Hinden" at Apr 12, 98 11:57 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob; > Once one starts looking at changing what TCP uses to identify connections > many issues arise. I suggest you read: > > "Separating Identifiers and Locators in Addresses: An Analysis of the GSE > Proposal for IPv6" at > > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-02.txt > It explores some of the issues. The ID is OK as a critic on Mike's GSE. However, most of it does not reflect the discussion of the meeting and is wrong on many points, especially on security. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 13 19:21:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id TAA02951 for ipng-dist; Mon, 13 Apr 1998 19:18:29 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id TAA02942 for ; Mon, 13 Apr 1998 19:18:10 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id TAA19193 for ; Mon, 13 Apr 1998 19:18:10 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id TAA18402 for ; Mon, 13 Apr 1998 19:18:10 -0700 (PDT) From: Masataka Ohta Message-Id: <199804140210.LAA05599@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA05599; Tue, 14 Apr 1998 11:09:58 +0859 Subject: (IPng 5686) Re: Destination Address Ambiguity To: crawdad@fnal.gov (Matt Crawford) Date: Tue, 14 Apr 98 11:09:57 JST Cc: soule@math.brown.edu, ipng@sunroof.eng.sun.com In-Reply-To: <199804131415.JAA19672@gungnir.fnal.gov>; from "Matt Crawford" at Apr 13, 98 9:15 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt; > This would break a lot of existing practice. Many web servers have > multiple IP addresses and treat them as pointing to the roots of > different HTML spaces. Poor understanding. It is only that, just as many web servers today may have multiple IPv4 addresses, the same web servers may have multiple IPv6 identifiers. The IPv6 web servers will change the root of HTML space depending on the destination identifier, then. It has nothing to do with the details of TCP. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 14 02:40:02 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id CAA03223 for ipng-dist; Tue, 14 Apr 1998 02:35:06 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id CAA03216 for ; Tue, 14 Apr 1998 02:34:54 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA00080 for ; Tue, 14 Apr 1998 02:34:50 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id CAA26818 for ; Tue, 14 Apr 1998 02:34:50 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.8.8/8.8.8) id LAA19604; Tue, 14 Apr 1998 11:34:02 +0200 (MET DST) From: Ignatios Souvatzis Message-Id: <199804140934.LAA19604@theory.cs.uni-bonn.de> Subject: (IPng 5688) Re: Destination Address Ambiguity In-Reply-To: <199804122025.NAA18578@earth.sun.com> from Steve Soule at "Apr 12, 98 04:27:19 pm" To: soule@math.brown.edu (Steve Soule) Date: Tue, 14 Apr 1998 11:34:00 +0200 (MET DST) Cc: hinden@iprg.nokia.com, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In message <3.0.5.32.19980412115717.00a75770@mailhost.iprg.nokia.com>, Bob Hind > en writes: > > It is not so simple and does not work with the current definition of TCP. > > Could you be more specific? In short: TCP is defined to use the string to identify connection --- where "address" is the numerical address string. For details, please read the TCP definition. Regards, Ignatios Souvatzis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 14 02:45:59 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id CAA03244 for ipng-dist; Tue, 14 Apr 1998 02:43:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id CAA03237 for ; Tue, 14 Apr 1998 02:43:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA00577 for ; Tue, 14 Apr 1998 02:43:02 -0700 Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.161]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id CAA29336 for ; Tue, 14 Apr 1998 02:42:58 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.8.8/8.8.8) id LAA20016; Tue, 14 Apr 1998 11:42:29 +0200 (MET DST) From: Ignatios Souvatzis Message-Id: <199804140942.LAA20016@theory.cs.uni-bonn.de> Subject: (IPng 5689) Re: Destination Address Ambiguity In-Reply-To: <01BD66C8.65166220.anthony.m.hughes@cdc.com> from Tony Hughes at "Apr 13, 98 10:39:09 am" To: Anthony.M.Hughes@cdc.com (Tony Hughes) Date: Tue, 14 Apr 1998 11:42:28 +0200 (MET DST) Cc: soule@math.brown.edu, ipng@sunroof.eng.sun.com, deering@cisco.com, hinden@ipsilon.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hughes wrote: > My guess would be that the App layer would handle this and not the transport. The transport would see two connections: > {A1,P1,B1,Q1} and {A1,P2,B2,Q2} > The app layer would know that these go to the same place and treat them as the same connection. But... the application layer has now way to know what byte offset of stream {A1,P1,B1,Q1} corresponds to what byte offset of stream {A1,P2,B2,Q2}. It would have to explicitly close {A1,P1,B1,Q1} and explicitly open {A1,P2,B2,Q2}, using its own method (e.g. FTP's REGET) to set up in a way to not redo all of the communication. Regards, Ignatios Souvatzis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 14 04:46:18 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id EAA03361 for ipng-dist; Tue, 14 Apr 1998 04:42:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id EAA03354 for ; Tue, 14 Apr 1998 04:42:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA08034 for ; Tue, 14 Apr 1998 04:41:56 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id EAA04981 for ; Tue, 14 Apr 1998 04:41:58 -0700 (PDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id HAA34462; Tue, 14 Apr 1998 07:41:53 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id HAA27946; Tue, 14 Apr 1998 07:41:54 -0400 Received: from hygro.raleigh.ibm.com (lig32-224-57-24.us.lig-dial.ibm.com [32.224.57.24]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id HAA16154; Tue, 14 Apr 1998 07:41:53 -0400 (EDT) Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id GAA12649; Tue, 14 Apr 1998 06:44:59 -0400 Message-Id: <199804141044.GAA12649@hygro.raleigh.ibm.com> To: Masataka Ohta cc: ipng@sunroof.eng.sun.com Subject: (IPng 5690) Re: Destination Address Ambiguity In-reply-to: Your message of "Tue, 14 Apr 1998 11:04:35 +0200." <199804140204.LAA05585@necom830.hpcl.titech.ac.jp> Date: Tue, 14 Apr 1998 06:44:59 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masataka Ohta writes: > Bob; > > Once one starts looking at changing what TCP uses to identify connections > > many issues arise. I suggest you read: > > > > "Separating Identifiers and Locators in Addresses: An Analysis of the GSE > > Proposal for IPv6" at > > > > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-02.txt > > It explores some of the issues. > The ID is OK as a critic on Mike's GSE. > However, most of it does not reflect the discussion of the meeting > and is wrong on many points, especially on security. If you can point to specific points that are incorrect, please do so. Simply saying "wrong on many points" doesn't give the authors much to work with. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 14 09:54:52 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA03821 for ipng-dist; Tue, 14 Apr 1998 09:49:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id JAA03813 for ; Tue, 14 Apr 1998 09:49:20 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA01334 for ; Tue, 14 Apr 1998 09:49:16 -0700 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA19165 for ; Tue, 14 Apr 1998 09:49:17 -0700 (PDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA21975; Tue, 14 Apr 1998 09:41:35 -0700 (PDT) Received: (from suresh@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA04720; Tue, 14 Apr 1998 09:48:53 -0700 (PDT) From: Pyda Srisuresh Message-Id: <199804141648.JAA04720@server.livingston.com> Subject: (IPng 5692) Re: Destination Address Ambiguity To: ipng@sunroof.eng.sun.com Date: Tue, 14 Apr 1998 09:48:53 -0700 (PDT) Cc: soule@math.brown.edu Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, If it is any consolation, I wanted to let you know that you brought up a very intersting and relevant point with a seemingly simple example. The issue of seperation between end user identifier (EID or name) and it's locator (used to route pkt) has apparantly not been resolved with V6. A node can have many addresses and many names. From a session security stand point, a node should be able to use different names (or even same name) to talk with different session partners, but the name should remain the same throughout any given session (I.e., its route identifiers or locators could change). From a routing stand point, the names of a node can change all they want (router has to no way to know the names), but a router knows all the different addresses that belong to the same node (from routing protocols). Clearly, we do not have a solution that adequately addresses the seperation of name and locator in a general sense. Applications that are most successful doing this (i.e., idetifying senders and receivers by their names) are those that are short lived, such as mail application and HTTP based browser apps. Applications likes FTP and telnet which can stay on for extended periods of time are the counter examples. cheers, suresh > > I've gotten a lot of replies now that have strongly hinted that > I'm pretty stupid. Let me try to put my original message in some > more context. > > I see a major problem in IPv6 in that it does not include Transparent > Renumbering. I don't think Transparent Renumbering will be finished > in time to be included in the base IPv6 specifications (though I would > prefer if it were). I believe that TR, once completed, will be mostly > an IP-layer mechanism, though it may require many small changes to > upper layers. Ultimately, I think renumbering and multihoming (and > maybe somehow anycasting too) will use a simple model in which groups > of addresses are considered, at the IP layer, to be interchangeable. > Of course, any packet at any one time can have only one source address > and one destination address, so there would probably be some system by > which one of a group of addresses is preferred (possibly on a socket > by socket basis). > > One of the problems that would have to be solved is the problem of > security, or, "How can one determine for sure that some addresses > are equivalent?" I am not addressing this problem at this time. > In one case, however, there is no security issue: the case of the > addresses of a node when considered by the node itself. > > Since a node cannot, at this time, tell another node what its addresses > are securely, it must be certain to consistently use just one of > its addresses as source addresses of packets in any one interaction. > This is not a problem. (Hopefully implementations of IPv6 do this?) > > But when seen as destination addresses, a node's addresses can easily > be treated as equivalent. No interaction with any other node need > take place to determine this; the node has to know its own addresses > in order to receive the packets at all. > > So think of my suggestion as phase one of Transparent Renumbering. > If node B can accept packets with various of its addresses as > destination addresses as equivalent, and node A has a full TR > implementation, then node B can renumber (or be multihomed, or maybe > even deal with having an anycast address) transparently. Perhaps I > am mistaken, but I don't think node B needs anything more (at any > layer). > > Perhaps this argument is too vague for action to be considered at > this time. If so, then please ignore my idea and wait until someone > comes out with a full and glorious Transparent Renumbering system. > > I'm a bit frustrated by the fact that the current IPv6 specs are so > close to making this half of Transparent Renumbering work, but with > (from my point of view, trivial) philosophical underpinnings that > prohibit it. I believe that it really is more sensible for a node > to treat its addresses as equivalent (except for handy virtual node > cases such as the one Matt brought up), if this can be made to work. > > I received several messages whose purpose was to remind me that a > TCP connection is identified by the endpoints and port numbers, > and that endpoints are the same thing as IP addresses. Why not > consider endpoints to be nodes (or virtual nodes) instead? (With > behavior specified so that by default, an IP address is sufficient > identificaiton for the node.) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 14 18:29:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id SAA04854 for ipng-dist; Tue, 14 Apr 1998 18:19:43 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id SAA04847 for ; Tue, 14 Apr 1998 18:19:32 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA23412 for ; Tue, 14 Apr 1998 18:19:28 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA10559 for ; Tue, 14 Apr 1998 18:19:29 -0700 (PDT) From: Masataka Ohta Message-Id: <199804150111.KAA07693@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA07693; Wed, 15 Apr 1998 10:11:20 +0900 Subject: (IPng 5693) Re: Destination Address Ambiguity To: narten@raleigh.ibm.com (Thomas Narten) Date: Wed, 15 Apr 98 10:11:19 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199804141044.GAA12649@hygro.raleigh.ibm.com>; from "Thomas Narten" at Apr 14, 98 6:44 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas; > If you can point to specific points that are incorrect, Almost all except for a critic on Mike's GSE. > please do > so. Simply saying "wrong on many points" doesn't give the authors much > to work with. As I already posted several correct draft IDs, it was wrong that there was authors. If you want to work constructively, construtive comments on mine is welcome. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 16 12:17:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA07761 for ipng-dist; Thu, 16 Apr 1998 12:12:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA07754 for ; Thu, 16 Apr 1998 12:12:33 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA29174 for ; Thu, 16 Apr 1998 12:12:16 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA07494 for ; Thu, 16 Apr 1998 12:12:11 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id PAA13430 for ; Thu, 16 Apr 1998 15:12:10 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA16244; Thu, 16 Apr 1998 15:12:06 -0400 Date: Thu, 16 Apr 1998 15:12:06 -0400 From: Jack McCann Message-Id: <199804161912.AA16244@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5695) bsd-api-new-01: need to clarify allocation/deallocation of addrinfo Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Refering to draft-ietf-ipngwg-bsd-api-new-01.txt, I think we need to clarify the behavior of getaddrinfo() and freeaddrinfo() with regard to the dynamically allocated addrinfo structures. The description of freeaddrinfo() says: void freeaddrinfo(struct addrinfo *ai); The addrinfo structure pointed to by the ai argument is freed, along with any dynamic storage pointed to by the structure. This operation is repeated until a NULL ai_next pointer is encountered. The question is: repeated by whom? The caller or freeaddrinfo()? I had assumed this meant that freeaddrinfo() walk down the list pointed to by 'ai', freeing each one. Another interpretation is that the caller must call freeaddrinfo() once for each addrinfo structure in the list. The spec should be clarified to avoid this ambiguity. Also, is it intended that individual addrinfo structures in a list of such structures returned by getaddrinfo() be individually allocated and therefore individually freeable? Or must the entire list be freed by one call to freeaddrinfo()? If the latter, one could envision an implementation allocating one chunk of memory to hold several addrinfo structures linked together via ai_next. This would be "a bad thing" if the user assumes he can call freeaddrinfo() for each individual addrinfo structure in a list. I think the description of getaddrinfo() should be explicit with regard to how individual addrinfo structures are allocated. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 16 12:55:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA07832 for ipng-dist; Thu, 16 Apr 1998 12:45:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA07825 for ; Thu, 16 Apr 1998 12:45:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA11492 for ; Thu, 16 Apr 1998 12:45:19 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA03098 for ; Thu, 16 Apr 1998 12:45:12 -0700 (PDT) Received: from wasted.zk3.dec.com (bywasted.zk3.dec.com [16.140.96.51]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id PAA21391 for ; Thu, 16 Apr 1998 15:45:07 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA18267; Thu, 16 Apr 1998 15:45:05 -0400 Date: Thu, 16 Apr 1998 15:45:05 -0400 From: Jack McCann Message-Id: <199804161945.AA18267@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5696) sethostent/gethostent/endhostent Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Two questions related to the basic API: 1. Should we specify gethostent() for IPv6? It seems we cannot simply let gethostent() return 16 byte addresses for the same reason we could not let gethostbyname() return 16 byte addresses (i.e. the assumption that h_length will be 4). 2. The basic API spec should specify the interaction between getnodebyname/getnodebyaddr and sethostent/endhostent, if any. Specifically, should getnodebyname/getnodebyaddr honor the sethostent 'stayopen' flag? If getnodebyname/getnodebyaddr have no interaction with sethostent/endhostent, that should be explicitly stated. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 17 08:33:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id IAA09377 for ipng-dist; Fri, 17 Apr 1998 08:24:28 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA09370 for ; Fri, 17 Apr 1998 08:24:18 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA00698 for ; Fri, 17 Apr 1998 08:23:51 -0700 Received: from pony-2.mail.digex.net (pony-2.mail.digex.net [204.91.241.6]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA23109 for ; Fri, 17 Apr 1998 08:23:43 -0700 (PDT) Received: from krakow.brighttiger.com (brighttiger.com [207.86.119.34]) by pony-2.mail.digex.net (8.8.8/8.8.8) with SMTP id KAA27152 for ; Fri, 17 Apr 1998 10:23:37 -0500 (EDT) Received: from imitera (192.168.0.54) by krakow.brighttiger.com (EMWAC SMTPRS 0.81) with SMTP id ; Fri, 17 Apr 1998 11:22:32 -0400 Message-ID: <003301bd6a14$ca428850$01191fac@imitera.ne.mediaone.net> From: "Peter A. Schulter" To: Subject: (IPng 5697) Fw: (ION) I-D ACTION:draft-ietf-ion-ipv6-atm-02.txt Date: Fri, 17 Apr 1998 11:23:34 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 Content-Type: Multipart/Mixed; boundary="----=_NextPart_000_002E_01BD69F3.4288E880" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002E_01BD69F3.4288E880 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit This is the latest version of the ATM specific IPv6 over NBMA draft that was discussed in LA. It incorporates all the changes that were agreed to at the IPNG WG session last month. --- pete -----Original Message----- From: Internet-Drafts@ietf.org To: "IETF-Announce:;;;@cnri.reston.va.us;"@Eng.Sun.COM <"IETF-Announce:;;;@cnri.reston.va.us;"@Eng.Sun.COM> Cc: ion@sunroof.Eng.Sun.COM Date: Wednesday, April 15, 1998 10:47 AM Subject: (ION) I-D ACTION:draft-ietf-ion-ipv6-atm-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. > > Title : IPv6 over ATM Networks > Author(s) : G. Armitage, M. Jork, P. Schulter > Filename : draft-ietf-ion-ipv6-atm-02.txt > Pages : 12 > Date : 14-Apr-98 > > This document is a companion to the ION working group's architecture > document 'IPv6 over Non Broadcast Multiple Access (NBMA) networks'. > It provides specific details on how to apply the IPv6 over NBMA > architecture to ATM networks. This architecture allows conventional > host-side operation of the IPv6 Neighbor Discovery protocol, while > also supporting the establishment of 'shortcut' ATM forwarding paths > (when using SVCs). Operation over administratively configured Point > to Point PVCs is also supported. > >Internet-Drafts are available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-ion-ipv6-atm-02.txt". >A URL for the Internet-Draft is: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-ion-ipv6-atm-02.txt > >Internet-Drafts directories are located at: > > Africa: ftp.is.co.za > > Europe: ftp.nordu.net > ftp.nis.garr.it > > Pacific Rim: munnari.oz.au > > US East Coast: ftp.ietf.org > > US West Coast: ftp.isi.edu > >Internet-Drafts are also available by mail. > >Send a message to: mailserv@ietf.org. In the body type: > "FILE /internet-drafts/draft-ietf-ion-ipv6-atm-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > ------=_NextPart_000_002E_01BD69F3.4288E880 Content-Type: Multipart/Alternative; boundary="----=_NextPart_001_0031_01BD69F3.428A6F20" ------=_NextPart_001_0031_01BD69F3.428A6F20 Content-Transfer-Encoding: 7bit Content-Type: Message/External-body; server=mailserv@ietf.org; access-type=mail-server Content-Type: text/plain Content-ID: <19980414172650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ion-ipv6-atm-02.txt ------=_NextPart_001_0031_01BD69F3.428A6F20 Content-Transfer-Encoding: 7bit Content-Type: Message/External-body; site=ftp.ietf.org; directory=internet-drafts; name="draft-ietf-ion-ipv6-atm-02.txt"; access-type=anon-ftp Content-Type: text/plain Content-ID: <19980414172650.I-D@ietf.org> ------=_NextPart_001_0031_01BD69F3.428A6F20-- ------=_NextPart_000_002E_01BD69F3.4288E880-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 17 16:55:45 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id QAA15375 for ipng-dist; Fri, 17 Apr 1998 16:48:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id QAA15368 for ; Fri, 17 Apr 1998 16:48:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA22095 for ; Fri, 17 Apr 1998 16:48:24 -0700 Received: from kalae.kohala.com (kalae.kohala.com [209.75.135.35]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id QAA07187 for ; Fri, 17 Apr 1998 16:48:25 -0700 (PDT) Received: from kohala.kohala.com (kohala.kohala.com [209.75.135.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id QAA21869; Fri, 17 Apr 1998 16:48:24 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id QAA08695; Fri, 17 Apr 1998 16:48:21 -0700 (MST) Message-Id: <199804172348.QAA08695@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 17 Apr 1998 16:48:20 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Jack McCann , ipng@sunroof.eng.sun.com Subject: (IPng 5698) Re: bsd-api-new-01: need to clarify allocation/deallocation of addrinfo Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Apr 16, 3:12pm you write:] > > Refering to draft-ietf-ipngwg-bsd-api-new-01.txt, I think we need > to clarify the behavior of getaddrinfo() and freeaddrinfo() with > regard to the dynamically allocated addrinfo structures. The > description of freeaddrinfo() says: > > void freeaddrinfo(struct addrinfo *ai); > > The addrinfo structure pointed to by the ai argument is freed, along > with any dynamic storage pointed to by the structure. This operation > is repeated until a NULL ai_next pointer is encountered. > > The question is: repeated by whom? The caller or freeaddrinfo()? > I had assumed this meant that freeaddrinfo() walk down the list > pointed to by 'ai', freeing each one. Another interpretation is > that the caller must call freeaddrinfo() once for each addrinfo > structure in the list. The spec should be clarified to avoid this > ambiguity. Correct. The intent was that freeaddrinfo() frees it all. > Also, is it intended that individual addrinfo structures in a list > of such structures returned by getaddrinfo() be individually allocated > and therefore individually freeable? Or must the entire list be freed > by one call to freeaddrinfo()? If the latter, one could envision an > implementation allocating one chunk of memory to hold several addrinfo > structures linked together via ai_next. This would be "a bad thing" if > the user assumes he can call freeaddrinfo() for each individual addrinfo > structure in a list. I think the description of getaddrinfo() should > be explicit with regard to how individual addrinfo structures are > allocated. I'd say the intent was that one call frees everything. That is, the argument to freeaddrinfo() must be a return value from getaddrinfo(). That makes it an implementation decision whether to allocate one huge chunk, or little pieces. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Apr 20 06:59:26 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id GAA17273 for ipng-dist; Mon, 20 Apr 1998 06:49:17 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id GAA17266 for ; Mon, 20 Apr 1998 06:49:01 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA27876 for ; Mon, 20 Apr 1998 06:48:56 -0700 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id GAA05062 for ; Mon, 20 Apr 1998 06:48:58 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id JAA01675; Mon, 20 Apr 1998 09:48:18 -0400 (EDT) Message-Id: <199804201348.JAA01675@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 5699) I-D ACTION:draft-ietf-ipngwg-ipv6router-alert-04.txt Date: Mon, 20 Apr 1998 09:48:18 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Router Alert Option Author(s) : C. Partridge, D. Katz, A. Jackson Filename : draft-ietf-ipngwg-ipv6router-alert-04.txt Pages : 5 Date : 17-Apr-98 This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6router-alert-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6router-alert-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980417151653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6router-alert-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980417151653.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 11:33:38 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id LAA19313 for ipng-dist; Tue, 21 Apr 1998 11:21:09 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id LAA19306 for ; Tue, 21 Apr 1998 11:21:00 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA13238 for ; Tue, 21 Apr 1998 11:20:58 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id LAA25176 for ; Tue, 21 Apr 1998 11:20:58 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id OAA26016 for ; Tue, 21 Apr 1998 14:20:43 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id OAA38174 for ; Tue, 21 Apr 1998 14:20:44 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id OAA16142 for ; Tue, 21 Apr 1998 14:20:55 -0400 (EDT) Message-Id: <199804211820.OAA16142@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 5700) FWD: Re: Hop Limit in Inner Header (IPv6) Date: Tue, 21 Apr 1998 14:20:50 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This was discussed briefly on the IPSec list. Is there an issue here for this group? The key point from what I can tell is that the IPSec architecture says that all packets send via tunnel mode (i.e., headers = TCP, IP-inner, ESP/AH, IP-outer, link layer ) must have the TTL on the inner header decremented. This appears to include packets originating from the same host on which the sending end of the tunnel resides. Comments? Thomas ------- Forwarded Message From: Peter Curran To: Steve Bellovin Cc: "Theodore Y. Ts'o" , Karen Heron , ipsec@tis.com Date: Fri, 17 Apr 1998 15:32:50 +0100 Subject: Re: Hop Limit in Inner Header (IPv6) It sounds as if there is a danger of creating an illogicality here. When IPv6 automatic tunnels are used to connect two IPv6/IPv4 nodes (across an IPv4 network of any size) then the inner packet hop-limit is not decremented because both hosts are on the same logical link connecting them. As the packet is not *forwarded* into the tunnel, then the hop-limit remains unchanged. By the same logic, why should the hop-limit be decremented when the packet is being sent across an IPSEC tunnel that exists between the same two nodes? IMHO, this shouuld not happen because it is not logical. If the packet originated on a 3rd node, was passed to the 1st and then sent down a tunnel to the 2nd then I agree the hop-limit should be deceremented - the packet is forwarded from one link to another. The proposed mechanism will break NDP. Another question that should be considered relates to the scope of the IPv6 addresses. Is it illogical for an IPSEC tunnel to exist between two nodes, if the end-points of the tunnel are recognised by link local addresses and yet not on the same physical link? What if they are not on the same site? In the former case, link local addresses could be assigned to the tunnel ends - the two devices will be on the same logical link. Peter TICL At 21:27 16/04/98 -0400, Steve Bellovin wrote: > From: Karen Heron > Date: Wed, 15 Apr 1998 07:49:03 -0400 > > In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Constructio > n > for Tunnel Mode, the inner header Hop Limit is decremented. This > will cause problems for securing IPv6 NDP traffic. The hop limit i > s > set to 255 in NDP packets and checked in the receiving node to make > sure it came from the same link. If this NDP exchange is secured > using tunnel mode and the hop limit is decremented before the packe > t > is encapsulated, the receiving node will reject the NDP packet and > neighbor discovery will fail, even if the two nodes are on the same > link. Should the Hop Limit not be decremented for locally generate > d > traffic? If not, I don't see how NDP traffic can be secured using > tunnel mode - maybe I've missed something in the drafts that said > this. If this question has already been answered, I'd appreciate a > pointer to the discussion (I didn't see it in the archives). > > Karen, > I would think that if a packet originates at host A, and the > packet then gets encapsulated by security gateway G and sent down the > IPSEC tunnel to host B, that host A and host B are not on the same > network. > > In fact, even if the packet is originated and encapsulated at > host A, and sent over a IPSEC tunnel, which might send the packet > halfway across the world, when it is decapsulated at host B, the hop > count should be decremented, since it is extremely unlikely that they > are really "neighbors". > > I'm not completely familiar with what exactly NDP is trying to > do, but if you're using tunnel mode, you can't distinguish between > whether your communications partner is on the same ethernet, or on the > wrong side of MAE-EAST (you can tell that by the number of packets tha > t > get dropped, though :-). If this is what NDP is trying to do, then > fundamentally you shouldn't be using tunnel mode. Whether you always > decrement the hop count, as the spec currently states, or never > decrement the hop count, you still don't know whether someone is next > door or on the other side of the planet. > >My own view is that a tunnel is a virtual wire between two nodes. NDP >should work across that tunnel only to the extent that the packet >originated on one endpoint and terminated on the other. ("Neighbor" is >a topological construct here, and ignores phyiscal reality.) > ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 11:55:23 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id LAA19343 for ipng-dist; Tue, 21 Apr 1998 11:46:40 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id LAA19336 for ; Tue, 21 Apr 1998 11:46:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA20959 for ; Tue, 21 Apr 1998 11:46:25 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA11500 for ; Tue, 21 Apr 1998 11:46:26 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id NAA07240; Tue, 21 Apr 1998 13:46:16 -0500 Message-Id: <199804211846.NAA07240@gungnir.fnal.gov> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5701) Re: FWD: Re: Hop Limit in Inner Header (IPv6) In-reply-to: Your message of Tue, 21 Apr 1998 14:20:50 EDT. <199804211820.OAA16142@cichlid.raleigh.ibm.com> Date: Tue, 21 Apr 1998 13:46:15 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, it's an issue, but it can be solved with spec-tweaks. The discovery draft, sections 6.1.1, 6.1.2, 7.1.1, 7.1.2, 8.1, would would have to be changed to require EITHER HL=255 OR (appropriate security provided by the tunnel-mode security association). What is "appropriate" is not a question for a snap answer. It would certainly have to include authentication and replay protection since a stale ND message can do about as much damage as a complete forgery. I'd also point out that you DO NOT GET anti-replay with manual keying. I've been gnashing my teeth since the LA meeting trying to pin down exactly how to get the desired authentication properties for router renumbering through ipsec, so some tiny fraction of the ipsec details are fresh in my mind. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 12:30:46 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA19400 for ipng-dist; Tue, 21 Apr 1998 12:21:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA19393 for ; Tue, 21 Apr 1998 12:20:59 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA29866 for ; Tue, 21 Apr 1998 12:20:56 -0700 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id MAA01179 for ; Tue, 21 Apr 1998 12:20:56 -0700 (PDT) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id UAA16116; Tue, 21 Apr 1998 20:21:22 +0100 (BST) Message-Id: X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 21 Apr 1998 20:20:55 +0100 To: Robert Moskowitz From: Peter Curran Subject: (IPng 5702) Re: Hop Limit in Inner Header (IPv6) Cc: Steve Bellovin , "Theodore Y. Ts'o" , Karen Heron , ipsec@tis.com, ipng@sunroof.eng.sun.com In-Reply-To: <3.0.5.32.19980421135920.00a0b7f0@homebase.htt-consult.com> References: <199804171432.PAA06631@gate.ticl.co.uk> <199804170127.VAA09270@postal.research.att.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-==--==-=-===----=-=---=-=--==--=---====-=--==="; protocol="application/pgp-signature"; micalg=pgp-sha1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=-==--==-=-===----=-=---=-=--==--=---====-=--=== Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" (Sorry about retaining all the preceding in this reply, but I have copied this to the IPNG list in case the wider WG wants to make some further comments) The operation of tunneling as described in RFC2003 is in line with that used by IPv6. I have now had chance to read the stuff through again more carefully and think that the problem is one of interpretation. The ipsec-arch-sec document should make it clear that if the inner packet originates on the node that is responsible for encapsulation, then the TTL (or Hop Limit in the IPv6 case) should not be decremented as no forwarding is taking place. If the inner packet originates on a different node, then the TTL (HL) of the inner packet should be decremented prior to forwarding into the tunnel. Likewise, if the decapsulating node is not the final destination of the inner packet, then its TTL(HL) should be decremented when it is forwarded on from the decapsulating node towards its destination. (Incidentally, there is a typo. The IPv6 equivalent of the TTL field is called Hop Limit, not Hop Count) The issue raised by Karen Heron is that if this interpretation is not correct, then the NDP protocol will break. A 'built-in' security feature of the protocol design is that all NDP messages can only be received from the link to which you are fastened (physically or logically). By setting the HL to 255, an attempt to spoof an NDP message by forwarding it onto the link can be detected. *IF* IPSEC, using tunnel mode ESP, is to be used for NDP then it is essential that this behaviour is maintained. Of course, there may not be a need to use IPSEC in this mode for this purpose. Peter TICL At 13:59 21/04/98 -0400, Robert Moskowitz wrote: >At 03:32 PM 4/17/98 +0100, Peter Curran wrote: > >I am not familiar with NPD, but from RFC 2003 we have: > > When encapsulating a datagram, the TTL in the inner IP header is > decremented by one if the tunneling is being done as part of > forwarding the datagram; otherwise, the inner header TTL is not > changed during encapsulation. If the resulting TTL in the inner IP > header is 0, the datagram is discarded and an ICMP Time Exceeded > message SHOULD be returned to the sender. An encapsulator MUST NOT > encapsulate a datagram with TTL = 0. > > The TTL in the inner IP header is not changed when decapsulating. > If, after decapsulation, the inner datagram has TTL = 0, the > decapsulator MUST discard the datagram. If, after decapsulation, the > decapsulator forwards the datagram to one of its network interfaces, > it will decrement the TTL as a result of doing normal IP forwarding. > See also Section 4.4. > >This is a little different from IPsec-arch-04: > > 2. The TTL in the inner header is decremented by the > encapsulator prior to forwarding and by the decapsulator if > it forwards the packet. (The checksum changes when the TTL > changes.) > >but none the less, both decrement. I might point out that tunneling in >ipsec-arch's parentage is the 2003 work, if not 2003 itself. It is >interesting to note that 2003 does not decrement on decapsulating, though. > > >>It sounds as if there is a danger of creating an illogicality here. >> >>When IPv6 automatic tunnels are used to connect two IPv6/IPv4 nodes (across >>an IPv4 network of any size) then the inner packet hop-limit is not >>decremented because both hosts are on the same logical link connecting >>them. As the packet is not *forwarded* into the tunnel, then the hop-limit >>remains unchanged. >> >>By the same logic, why should the hop-limit be decremented when the packet >>is being sent across an IPSEC tunnel that exists between the same two nodes? >> >>IMHO, this shouuld not happen because it is not logical. If the packet >>originated on a 3rd node, was passed to the 1st and then sent down a tunnel >>to the 2nd then I agree the hop-limit should be deceremented - the packet >>is forwarded from one link to another. >> >>The proposed mechanism will break NDP. >> >>Another question that should be considered relates to the scope of the IPv6 >>addresses. Is it illogical for an IPSEC tunnel to exist between two nodes, >>if the end-points of the tunnel are recognised by link local addresses and >>yet not on the same physical link? What if they are not on the same site? >> >>In the former case, link local addresses could be assigned to the tunnel >>ends - the two devices will be on the same logical link. >> >>Peter >>TICL >> >> >>At 21:27 16/04/98 -0400, Steve Bellovin wrote: >>> From: Karen Heron >>> Date: Wed, 15 Apr 1998 07:49:03 -0400 >>> >>> In draft-ietf-ipsec-arch-sec-04, 5.1.2.2 IPv6 -- Header Constructio >>> n >>> for Tunnel Mode, the inner header Hop Limit is decremented. This >>> will cause problems for securing IPv6 NDP traffic. The hop limit i >>> s >>> set to 255 in NDP packets and checked in the receiving node to make >>> sure it came from the same link. If this NDP exchange is secured >>> using tunnel mode and the hop limit is decremented before the packe >>> t >>> is encapsulated, the receiving node will reject the NDP packet and >>> neighbor discovery will fail, even if the two nodes are on the same >>> link. Should the Hop Limit not be decremented for locally generate >>> d >>> traffic? If not, I don't see how NDP traffic can be secured using >>> tunnel mode - maybe I've missed something in the drafts that said >>> this. If this question has already been answered, I'd appreciate a >>> pointer to the discussion (I didn't see it in the archives). >>> >>> Karen, >>> I would think that if a packet originates at host A, and the >>> packet then gets encapsulated by security gateway G and sent down the >>> IPSEC tunnel to host B, that host A and host B are not on the same >>> network. >>> >>> In fact, even if the packet is originated and encapsulated at >>> host A, and sent over a IPSEC tunnel, which might send the packet >>> halfway across the world, when it is decapsulated at host B, the hop >>> count should be decremented, since it is extremely unlikely that they >>> are really "neighbors". >>> >>> I'm not completely familiar with what exactly NDP is trying to >>> do, but if you're using tunnel mode, you can't distinguish between >>> whether your communications partner is on the same ethernet, or on the >>> wrong side of MAE-EAST (you can tell that by the number of packets tha >>> t >>> get dropped, though :-). If this is what NDP is trying to do, then >>> fundamentally you shouldn't be using tunnel mode. Whether you always >>> decrement the hop count, as the spec currently states, or never >>> decrement the hop count, you still don't know whether someone is next >>> door or on the other side of the planet. >>> >>>My own view is that a tunnel is a virtual wire between two nodes. NDP >>>should work across that tunnel only to the extent that the packet >>>originated on one endpoint and terminated on the other. ("Neighbor" is >>>a topological construct here, and ignores phyiscal reality.) >>> >> >> >Robert Moskowitz >ICSA >Security Interest EMail: rgm-sec@htt-consult.com > --=-==--==-=-===----=-=---=-=--==--=---====-=--=== Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP for Personal Privacy 5.5.2 iQA/AwUBNTzxl5wudNbgUX8fEQJ+6gCgj5GM00Y7z6kwkZPWh+s4eyTz6a8AoMmG aBxiw8jZVFfwUfNl8B/aRXOk =4LVw -----END PGP MESSAGE----- --=-==--==-=-===----=-=---=-=--==--=---====-=--===-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 13:04:43 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA19481 for ipng-dist; Tue, 21 Apr 1998 12:52:32 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA19471 for ; Tue, 21 Apr 1998 12:52:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA06576 for ; Tue, 21 Apr 1998 12:52:13 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA18850 for ; Tue, 21 Apr 1998 12:52:15 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA00754; Tue, 21 Apr 98 12:48:40 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA04158; Tue, 21 Apr 1998 12:53:33 -0700 Date: Tue, 21 Apr 1998 12:53:33 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804211953.MAA04158@feller.mentat.com> To: crawdad@fnal.gov Subject: (IPng 5703) Re: FWD: Re: Hop Limit in Inner Header (IPv6) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, > > Yes, it's an issue, but it can be solved with spec-tweaks. > > The discovery draft, sections 6.1.1, 6.1.2, 7.1.1, 7.1.2, 8.1, would > would have to be changed to require EITHER HL=255 OR (appropriate > security provided by the tunnel-mode security association). What is > "appropriate" is not a question for a snap answer. It would > certainly have to include authentication and replay protection since > a stale ND message can do about as much damage as a complete forgery. > I'd also point out that you DO NOT GET anti-replay with manual keying. > Actually, my feeling is that the IPSec document is just incorrect. It is not drawing the appropriate distinction between encapsulation which is occuring on the machine which is originating the datagrams and encapsulation which is occuring on some sort of security gateway which is then going to forward the datagram. The hop limit should only be decremented by a machine which is going to forward a datagram. The act of transmitting a locally generated datagram into a tunnel does not constitute forwarding. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 14:41:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA19845 for ipng-dist; Tue, 21 Apr 1998 14:30:57 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA19837 for ; Tue, 21 Apr 1998 14:30:26 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA07390 for ; Tue, 21 Apr 1998 14:30:25 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA18499 for ; Tue, 21 Apr 1998 14:30:25 -0700 (PDT) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA07877; Tue, 21 Apr 1998 16:29:57 -0500 Message-Id: <199804212129.QAA07877@gungnir.fnal.gov> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5704) Re: FWD: Re: Hop Limit in Inner Header (IPv6) In-reply-to: Your message of Tue, 21 Apr 1998 12:53:33 PDT. <199804211953.MAA04158@feller.mentat.com> Date: Tue, 21 Apr 1998 16:29:57 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim sez: > Actually, my feeling is that the IPSec document is just incorrect. It is > not drawing the appropriate distinction ... I agree with you completely. But I was considering ipsec as a battleship that can't get out of our way. If they can fix the offending wording, that would be best. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 14:45:01 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA19898 for ipng-dist; Tue, 21 Apr 1998 14:40:45 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA19891 for ; Tue, 21 Apr 1998 14:40:34 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA10012 for ; Tue, 21 Apr 1998 14:40:32 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA24202 for ; Tue, 21 Apr 1998 14:40:32 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA01617; Tue, 21 Apr 98 14:37:14 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id OAA04243; Tue, 21 Apr 1998 14:42:05 -0700 Date: Tue, 21 Apr 1998 14:42:05 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804212142.OAA04243@feller.mentat.com> To: crawdad@fnal.gov Subject: (IPng 5705) Re: FWD: Re: Hop Limit in Inner Header (IPv6) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, > > Tim sez: > > Actually, my feeling is that the IPSec document is just incorrect. It is > > not drawing the appropriate distinction ... > > I agree with you completely. But I was considering ipsec as a > battleship that can't get out of our way. If they can fix the > offending wording, that would be best. > The IPSec documents are just now going to proposed. ND is ready to go to draft. Who is the battleship and who is the jet ski? tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 17:48:33 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id RAA20433 for ipng-dist; Tue, 21 Apr 1998 17:40:47 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id RAA20426 for ; Tue, 21 Apr 1998 17:40:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA05736 for ; Tue, 21 Apr 1998 17:40:35 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id RAA08405 for ; Tue, 21 Apr 1998 17:40:36 -0700 (PDT) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA03604; Tue, 21 Apr 1998 17:40:10 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: In-Reply-To: <199804211953.MAA04158@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 Apr 1998 17:41:26 -0700 To: thartric@mentat.com (Tim Hartrick) From: Steve Deering Subject: (IPng 5706) Re: FWD: Re: Hop Limit in Inner Header (IPv6) Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:53 PM -0700 4/21/98, Tim Hartrick wrote: > The hop limit should only be decremented by a machine which is going to > forward a datagram. The act of transmitting a locally generated datagram > into a tunnel does not constitute forwarding. Yes, exactly. The Hop Limit is decremented as part of the act of *forwarding* a packet received from one link onto another link, not as part of the act of encapsulating (or decapsulating) a packet on entrance to (or exit from) a tunnel. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 20:22:27 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id UAA20681 for ipng-dist; Tue, 21 Apr 1998 20:14:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id UAA20674 for ; Tue, 21 Apr 1998 20:14:40 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA02776 for ; Tue, 21 Apr 1998 20:14:40 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id UAA10250 for ; Tue, 21 Apr 1998 20:14:40 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id XAA10994 for ; Tue, 21 Apr 1998 23:14:39 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA01976; Tue, 21 Apr 1998 23:14:39 -0400 Message-Id: <199804220314.AA01976@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Cc: bound@zk3.dec.com Subject: (IPng 5707) sockaddr_in6 for the basic API Date: Tue, 21 Apr 1998 23:14:39 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Can we assume consensus for sockaddr_in6 is as follows per all the mail? struct sockaddr_in6 { uint8_t sin6_len; sa_family_t sin6_family; in_port_t sin6_port; uint32_t sin6_flowinfo; struct in6_addr sin6_addr; uint32_t sin6_index; uint32_t sin6_reserved; }; Scope is determined by the sin6_addr. A zero sin6_index means stacks choice.... sin6_addr is aligned on 64bit boundary. Added 32bits of reserved space....... I would like to assume we are done with sockaddr_in6 discussion. Silence means you agree........... We will get the other changes from about 97 mail messsages on this and get a new rev out as soon as we can. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 21 21:26:40 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id VAA20880 for ipng-dist; Tue, 21 Apr 1998 21:18:00 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id VAA20873 for ; Tue, 21 Apr 1998 21:17:46 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA10089 for ; Tue, 21 Apr 1998 21:17:44 -0700 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id VAA02633 for ; Tue, 21 Apr 1998 21:17:42 -0700 (PDT) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.8.8+3.0Wbeta12/3.6W) with ESMTP id NAA04597; Wed, 22 Apr 1998 13:15:37 +0900 (JST) To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com In-reply-to: bound's message of Tue, 21 Apr 1998 23:14:39 -0400. <199804220314.AA01976@wasted.zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 5709) Re: sockaddr_in6 for the basic API From: Jun-ichiro itojun Itoh Date: Wed, 22 Apr 1998 13:15:37 +0900 Message-ID: <4593.893218537@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Can we assume consensus for sockaddr_in6 is as follows per all the mail? >struct sockaddr_in6 { > uint8_t sin6_len; > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_flowinfo; > struct in6_addr sin6_addr; > uint32_t sin6_index; > uint32_t sin6_reserved; > }; >Scope is determined by the sin6_addr. >A zero sin6_index means stacks choice.... >sin6_addr is aligned on 64bit boundary. >Added 32bits of reserved space....... >I would like to assume we are done with sockaddr_in6 discussion. >Silence means you agree........... >We will get the other changes from about 97 mail messsages on this and >get a new rev out as soon as we can. I'm happy with the above, but just to be sure... please clarify the relationship with advanced-api IPV6_PKTINFO. (which overrides which , or IPV6_PKTINFO will be obsoleted, or something else) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 22 03:53:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id DAA21164 for ipng-dist; Wed, 22 Apr 1998 03:49:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id DAA21157 for ; Wed, 22 Apr 1998 03:49:14 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA22493 for ; Wed, 22 Apr 1998 03:49:10 -0700 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.8.8/8.8.8) with SMTP id DAA06512 for ; Wed, 22 Apr 1998 03:49:07 -0700 (PDT) Received: by mailgate.rdg.opengroup.org; id AA16931; Wed, 22 Apr 1998 10:48:35 GMT Received: from mailhome [192.153.166.5] by mailgate.rdg.opengroup.org via smtpd ; Wed Apr 22 10:48 GMT 1998 Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA04201; Wed, 22 Apr 1998 11:43:29 +0100 Received: from unknown(192.153.166.111) by mailhome.rdg.opengroup.org via smap (V1.3) id sma004196; Wed Apr 22 11:43:13 1998 Message-Id: <3.0.3.32.19980422114544.007ba1d0@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 22 Apr 1998 11:45:44 +0100 To: bound@zk3.dec.com From: Chris Harding Subject: (IPng 5710) Re: (c.harding 17696) sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org In-Reply-To: <199804220314.AA01976@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Jim, >Folks, > >Can we assume consensus for sockaddr_in6 is as follows per all the mail? > >struct sockaddr_in6 { > uint8_t sin6_len; > sa_family_t sin6_family; > in_port_t sin6_port; > uint32_t sin6_flowinfo; > struct in6_addr sin6_addr; > uint32_t sin6_index; > uint32_t sin6_reserved; > }; > >Scope is determined by the sin6_addr. > >A zero sin6_index means stacks choice.... > >sin6_addr is aligned on 64bit boundary. > >Added 32bits of reserved space....... > >I would like to assume we are done with sockaddr_in6 discussion. > >Silence means you agree........... > >We will get the other changes from about 97 mail messsages on this and >get a new rev out as soon as we can. > Two points: 1. I'd like to question the addition of a specific "sin6_reserved" field. Reserved fields are useful in protocol headers when you think you may want to add something later because in that situation, if you DON'T reserve the space, there's no way you will be able to get it when you do need it. But this isn't the case for API's. The normal convention (as several mails to ipng on this topic have mentioned) is to allow implementations the freedom to put the fields in any order and to add extra ones if they want to. Portable applications don't rely on field order and don't use any implementation-specific fields. Implementors can order the fields, add extra ones for padding, or add extra ones for their own private use, to their hearts' content. This is good because it allows implementors to do things to take advantage of their particular architectural features without compromising applications portability. Even if the structure given in the RFC is to be regarded as an example definition rather than a standard, I suggest that it would be better to omit an explicit sin6_reserved field and maybe add some words saying that implementors will probably add padding fields to ensure that the structure is appropriately aligned in memory. 2. What is the relation between the sin6_index and interface indexes? I may have mis-read the discussion on this, but I had the impression that for link-local addresses sin6_index would give an interface index that would identify the link in question. One possibility (I hate to raise it at this stage, but it is important to get this interface right) would be to have a single IPV6_IF_INDEX option that could be used via setsockopt to allow the application to set the interface index for use on any socket. This would replace sin6_index (at least in the link-local case) and also IPV6_MULTICAST_IF and the interface index fields in the mreq structures used for IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP. Doing things this way (and perhaps adding a new option for the site index) would have the advantage that most application programmers, who won't have to use these indexes, won't need to see them either. Alternatively, if we have sin6_index (which seems to be the consensus of the discussion so far), do we also need IPV6_MULTICAST_IF and the interface index fields in the mreq structures used for IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP? If we actually do need sin6_index as well as IPV6_MULTICAST_IF and the interface index fields in the mreq structures used for IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP, is there a relation between them - eg. can setting sin6_index affect the result of using IPV6_MULTICAST_IF with getsockopt()? Finally, if I am totally wrong (which has been known to happen) and sin6_index has no connection with interface indexes, please could a very clear explanation be added of what sin6_index actually is, to avoid having others fall into the same trap. Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 22 08:07:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id IAA21580 for ipng-dist; Wed, 22 Apr 1998 08:01:31 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA21573 for ; Wed, 22 Apr 1998 08:01:22 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA28278 for ; Wed, 22 Apr 1998 08:01:20 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA19739 for ; Wed, 22 Apr 1998 08:01:21 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id KAA26276; Wed, 22 Apr 1998 10:59:16 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA05261; Wed, 22 Apr 1998 10:59:08 -0400 Message-Id: <199804221459.AA05261@wasted.zk3.dec.com> To: Chris Harding Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, xnet@opengroup.org Subject: (IPng 5712) Re: (c.harding 17696) sockaddr_in6 for the basic API In-Reply-To: Your message of "Wed, 22 Apr 1998 11:45:44 BST." <3.0.3.32.19980422114544.007ba1d0@mailhome.rdg.opengroup.org> Date: Wed, 22 Apr 1998 10:59:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chris, >Two points: 1. I'd like to question the addition of a specific "sin6_reserved" field. Reserved fields are useful in protocol headers when you think you may want to add something later because in that situation, if you DON'T reserve the space, there's no way you will be able to get it when you do need it. But this isn't the case for API's. The normal convention (as several mails to ipng on this topic have mentioned) is to allow implementations the freedom to put the fields in any order and to add extra ones if they want to. Portable applications don't rely on field order and don't use any implementation-specific fields. Implementors can order the fields, add extra ones for padding, or add extra ones for their own private use, to their hearts' content. This is good because it allows implementors to do things to take advantage of their particular architectural features without compromising applications portability. Even if the structure given in the RFC is to be regarded as an example definition rather than a standard, I suggest that it would be better to omit an explicit sin6_reserved field and maybe add some words saying that implementors will probably add padding fields to ensure that the structure is appropriately aligned in memory. I think for IPv6 we are changing the "thinking" and "design" model of the API to be "extensible". The worst thing for vendors and APIs is breaking binary compatibility. IPv6 will evolve over time. On this list we have included many future hopes in the architecture. I think we need to do the same for the API. This is not painful to any of the vendors either. As we evolve the networking protocol we will need to evolve the API structure. 32 extra bits will buy us a lot IMO. 2. What is the relation between the sin6_index and interface indexes? I may have mis-read the discussion on this, but I had the impression that for link-local addresses sin6_index would give an interface index that would identify the link in question. It identifies an interface on the node. One possibility (I hate to raise it at this stage, but it is important to get this interface right) would be to have a single IPV6_IF_INDEX option that could be used via setsockopt to allow the application to set the interface index for use on any socket. This would replace sin6_index (at least in the link-local case) and also IPV6_MULTICAST_IF and the interface index fields in the mreq structures used for IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP. Doing things this way (and perhaps adding a new option for the site index) would have the advantage that most application programmers, who won't have to use these indexes, won't need to see them either. This is an argument IMO to not get rid if IPV6_MULTICAST_IF. In fact we will add words that for multicast IPV6_MULTICAST_IF overrides sin6_index. But, sin6_index is useful for non-multicast applications and IPv6 in particular to assist with scoping and multihomed nodes. Alternatively, if we have sin6_index (which seems to be the consensus of the discussion so far), do we also need IPV6_MULTICAST_IF and the interface index fields in the mreq structures used for IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP? Yes per my response above. If we actually do need sin6_index as well as IPV6_MULTICAST_IF and the interface index fields in the mreq structures used for IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP, is there a relation between them - eg. can setting sin6_index affect the result of using IPV6_MULTICAST_IF with getsockopt()? See my response above. Finally, if I am totally wrong (which has been known to happen) and sin6_index has no connection with interface indexes, please could a very clear explanation be added of what sin6_index actually is, to avoid having others fall into the same trap. sin6_index is in fact an interface index. We will make this clear in the next rev of the spec.. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 22 08:12:14 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id IAA21598 for ipng-dist; Wed, 22 Apr 1998 08:08:22 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA21591 for ; Wed, 22 Apr 1998 08:08:13 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA00321 for ; Wed, 22 Apr 1998 08:08:11 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA23617 for ; Wed, 22 Apr 1998 08:07:59 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id LAA16775; Wed, 22 Apr 1998 11:07:54 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA28010; Wed, 22 Apr 1998 11:07:46 -0400 Message-Id: <199804221507.AA28010@wasted.zk3.dec.com> To: Jun-ichiro itojun Itoh Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5713) Re: sockaddr_in6 for the basic API In-Reply-To: Your message of "Wed, 22 Apr 1998 13:15:37 +0900." <4593.893218537@coconut.itojun.org> Date: Wed, 22 Apr 1998 11:07:46 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, I'm happy with the above, but just to be sure... please clarify the relationship with advanced-api IPV6_PKTINFO. (which overrides which , or IPV6_PKTINFO will be obsoleted, or something else) I do not "think" we need unsigned int ipi6_ifindex; /* send/recv interface index */ in the advanced API anymore and it is deprecated. The rules for sin6_index vs IPV6_MULTICAST_IF would be moved to the basic API. Even for filtering sockaddr_in6 is part of the returned data too. But I do defer to Rich Stevens and Matt Thomas as authors of 2292 to tell me I am wrong for reasons not apparent to me right now, as I am not implementing the Advanced API? (or other Adv API implementors as yourself). I did look at code I am working on for addrconnf that uses features from ipv6_pktinfo struct and if the index is in sin6_index I just change my reference from one to the other in the daemon, and fix the addrconf and ND kernel mods to do this of course too. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 22 08:41:04 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id IAA21650 for ipng-dist; Wed, 22 Apr 1998 08:34:48 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA21643 for ; Wed, 22 Apr 1998 08:34:35 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA08644 for ; Wed, 22 Apr 1998 08:34:32 -0700 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.8.8/8.8.8) with SMTP id IAA09741 for ; Wed, 22 Apr 1998 08:34:33 -0700 (PDT) Received: by mailgate.rdg.opengroup.org; id AA23320; Wed, 22 Apr 1998 15:33:59 GMT Received: from mailhome [192.153.166.5] by mailgate.rdg.opengroup.org via smtpd ; Wed Apr 22 15:33 GMT 1998 Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA11129; Wed, 22 Apr 1998 16:28:54 +0100 Received: from unknown(192.153.166.111) by mailhome.rdg.opengroup.org via smap (V1.3) id sma011102; Wed Apr 22 16:28:45 1998 Message-Id: <3.0.3.32.19980422163136.007b7310@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 22 Apr 1998 16:31:36 +0100 To: bound@zk3.dec.com From: Chris Harding Subject: (IPng 5714) Re: (c.harding 17704) Re: (c.harding 17696) sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org In-Reply-To: <199804221459.AA05261@wasted.zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Jim, Thanks for your reply. On point 1. (sin6_reserved), I understand the argument that some vendors will want to provide this field. What I don't yet understand is whether there is an argument that says that a vendor who doesn't want to provide this field should nevertheless be forced to. On point 2. (sin6_index and interface indexes), I have no technical axe to grind - my concern is just that whatever technical decisions are made should be stated clearly. >Chris, > >>Two points: > > 1. I'd like to question the addition of a specific "sin6_reserved" field. > > Reserved fields are useful in protocol headers when you think you may > want to add something later because in that situation, if you DON'T > reserve the space, there's no way you will be able to get it when you > do need it. But this isn't the case for API's. The normal convention > (as several mails to ipng on this topic have mentioned) is to allow > implementations the freedom to put the fields in any order and to add > extra ones if they want to. Portable applications don't rely on field > order and don't use any implementation-specific fields. Implementors > can order the fields, add extra ones for padding, or add extra ones > for their own private use, to their hearts' content. This is good > because it allows implementors to do things to take advantage of > their particular architectural features without compromising > applications portability. > > Even if the structure given in the RFC is to be regarded as an example > definition rather than a standard, I suggest that it would be better > to omit an explicit sin6_reserved field and maybe add some words > saying that implementors will probably add padding fields to ensure > that the structure is appropriately aligned in memory. > >I think for IPv6 we are changing the "thinking" and "design" model of >the API to be "extensible". The worst thing for vendors and APIs is >breaking binary compatibility. IPv6 will evolve over time. On this >list we have included many future hopes in the architecture. I think we >need to do the same for the API. This is not painful to any of the >vendors either. As we evolve the networking protocol we will need to >evolve the API structure. 32 extra bits will buy us a lot IMO. > > 2. What is the relation between the sin6_index and interface indexes? > > I may have mis-read the discussion on this, but I had the impression > that for link-local addresses sin6_index would give an interface > index that would identify the link in question. > >It identifies an interface on the node. > > One possibility (I hate to raise it at this stage, but it is > important to get this interface right) would be to have a single > IPV6_IF_INDEX option that could be used via setsockopt to allow > the application to set the interface index for use on any socket. > This would replace sin6_index (at least in the link-local case) > and also IPV6_MULTICAST_IF and the interface index fields in the > mreq structures used for IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP. > Doing things this way (and perhaps adding a new option for the site > index) would have the advantage that most application programmers, > who won't have to use these indexes, won't need to see them either. > >This is an argument IMO to not get rid if IPV6_MULTICAST_IF. In fact >we will add words that for multicast IPV6_MULTICAST_IF overrides >sin6_index. But, sin6_index is useful for non-multicast applications >and IPv6 in particular to assist with scoping and multihomed nodes. > > Alternatively, if we have sin6_index (which seems to be the consensus > of the discussion so far), do we also need IPV6_MULTICAST_IF and the > interface index fields in the mreq structures used for > IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP? > >Yes per my response above. > > If we actually do need sin6_index as well as IPV6_MULTICAST_IF and the > interface index fields in the mreq structures used for > IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP, is there a relation > between them - eg. can setting sin6_index affect the result of > using IPV6_MULTICAST_IF with getsockopt()? > >See my response above. > > Finally, if I am totally wrong (which has been known to happen) and > sin6_index has no connection with interface indexes, please could a > very clear explanation be added of what sin6_index actually is, to > avoid having others fall into the same trap. > >sin6_index is in fact an interface index. We will make this clear in >the next rev of the spec.. > >thanks >/jim > > > > Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 22 09:39:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA21760 for ipng-dist; Wed, 22 Apr 1998 09:30:34 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA21753 for ; Wed, 22 Apr 1998 09:30:29 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA24858 for ; Wed, 22 Apr 1998 09:30:28 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA05327 for ipng@sunroof.eng.sun.com; Wed, 22 Apr 1998 09:30:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA21561 for ; Wed, 22 Apr 1998 08:01:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA28197 for ; Wed, 22 Apr 1998 08:01:00 -0700 Received: from cnrmail.lbl.gov (buster.lbl.gov [131.243.65.29]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA19488 for ; Wed, 22 Apr 1998 08:00:56 -0700 (PDT) Received: from truckee (128.3.9.225) by cnrmail.lbl.gov with SMTP (Eudora Internet Mail Server 2.1b5); Wed, 22 Apr 1998 08:00:56 -0700 X-Sender: rlfink@cnrmail.lbl.gov X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Wed, 22 Apr 1998 05:14:28 -0700 To: Jim Fleming , IPng List From: Jim Fleming (by way of Bob Fink ) Subject: (IPng 5716) IPv6 Address Management Plan Cc: Harald Tveit Alvestrand , ipv6-wg@ripe.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <1318890440-110882894@cnrmail.lbl.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Fleming, Sorry to be slow in responding, I just saw your email (below) of the 20th. Your question is one of IPv6 address architecture and thus is best discussed on the ipng mail list at: ipng@sunroof.Eng.Sun.COM I have copied that list in this reply. Thanks, Bob ============================================ From: Jim Fleming To: "'Bob Fink'" Subject: IPv6 Address Management Plan Date: Mon, 20 Apr 1998 23:39:50 -0500 Bob, Have the IPv6 developers settled on an Address Management Plan ? If so, I would like to develop a simple mapping from our 43 bit IPv8 addresses to the IPv6 transport. Do you have any suggestions on how you would do this ? Since the addresses are broken into 3, 8 and 32 bit fields there is some opportunity to map those to the various fields in the IPv6 address fields. I have hesitated to do this while IPv6 is still a moving target. Any guidance that you can provide would be helpful. I want to start testing using the IPv6 transport and would like to make sure we do not have to redo our IPv8 Address Management Plan. In this area, it pays to get it right the first time. Thanks in advance... - Jim Fleming Unir Corporation IBC, Tortola, BVI -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 22 11:14:24 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id LAA22035 for ipng-dist; Wed, 22 Apr 1998 11:08:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id LAA22028 for ; Wed, 22 Apr 1998 11:08:06 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA04546 for ; Wed, 22 Apr 1998 11:08:01 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id LAA20685 for ; Wed, 22 Apr 1998 11:08:00 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA09416; Wed, 22 Apr 98 11:04:40 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA01225; Wed, 22 Apr 1998 11:09:32 -0700 Date: Wed, 22 Apr 1998 11:09:32 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804221809.LAA01225@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5717) Re: sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, Jim, > > I do not "think" we need > > unsigned int ipi6_ifindex; /* send/recv interface index */ > > in the advanced API anymore and it is deprecated. > > The rules for sin6_index vs IPV6_MULTICAST_IF would be moved to the basic > API. > > Even for filtering sockaddr_in6 is part of the returned data too. > > But I do defer to Rich Stevens and Matt Thomas as authors of 2292 to > tell me I am wrong for reasons not apparent to me right now, as I am not > implementing the Advanced API? (or other Adv API implementors as > yourself). I did look at code I am working on for addrconnf that uses > features from ipv6_pktinfo struct and if the index is in sin6_index > I just change my reference from one to the other in the daemon, and fix > the addrconf and ND kernel mods to do this of course too. > I think that the ipi6_ifindex is still required in the in6_pktinfo structure. The reason being that the sin6_index is the scope index for the sin6_addr. If the address in the sin6_addr field is a site-local or org-local address then the interface on which the packet was received or is to be transmitted is not specified. It is still important for routing protocols and other control functions like DHCPv6 to allow for the interface index to be specified on outgoing datagrams and received on incoming datagrams. Of course an Itojun has pointed out we need to establish which index has priority when someone does a sendmsg to a link-local address with an interface index specified in the sockaddr_in6 and in a in6_pktinfo ancillary data item. My inclination is to specify that the ancillary data item index always takes priority over the index specified in the sockaddr_in6 structure in the case where the destination of the sendmsg is a link-local address. In the case of a recvmsg which is receiving a datagram addressed to a link- local address the two indices should be the same. That leaves the case where the sin6_index has specified a site or organization index but the ipi6_ifindex of the IPV6_PKTINFO ancillary data item is specifying an interface which is not part of the specified site or organization. Clearly this is an error which needs to be caught. It is not at all clear that we actually need the IPV6_MULTICAST_IF option anymore. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 23 14:47:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA24343 for ipng-dist; Thu, 23 Apr 1998 14:41:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA24336 for ; Thu, 23 Apr 1998 14:41:44 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA06300 for ; Thu, 23 Apr 1998 14:41:42 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA22143 for ; Thu, 23 Apr 1998 14:41:42 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail12.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id RAA18618; Thu, 23 Apr 1998 17:41:40 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA31767; Thu, 23 Apr 1998 17:41:31 -0400 Message-Id: <199804232141.AA31767@wasted.zk3.dec.com> To: Chris Harding Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org Subject: (IPng 5718) Re: (c.harding 17704) Re: (c.harding 17696) sockaddr_in6 for the basic API In-Reply-To: Your message of "Wed, 22 Apr 1998 16:31:36 BST." <3.0.3.32.19980422163136.007b7310@mailhome.rdg.opengroup.org> Date: Thu, 23 Apr 1998 17:41:31 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chris, >Thanks for your reply. Ditto..... >On point 1. (sin6_reserved), I understand the argument that some vendors >will want to provide this field. What I don't yet understand is whether >there is an argument that says that a vendor who doesn't want to provide >this field should nevertheless be forced to. I think all the vendors who will build Host IPv6 APIs are on the IPngwg List. Let them speak up now. More here than on the XNET group. >On point 2. (sin6_index and interface indexes), I have no technical axe to >grind - my concern is just that whatever technical decisions are made should >be stated clearly. Agreed. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 23 14:54:44 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA24405 for ipng-dist; Thu, 23 Apr 1998 14:51:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA24398 for ; Thu, 23 Apr 1998 14:51:27 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA08810 for ; Thu, 23 Apr 1998 14:51:24 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA27264 for ; Thu, 23 Apr 1998 14:51:24 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id RAA01691; Thu, 23 Apr 1998 17:51:23 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA32255; Thu, 23 Apr 1998 17:51:21 -0400 Message-Id: <199804232151.AA32255@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5719) Re: sockaddr_in6 for the basic API In-Reply-To: Your message of "Wed, 22 Apr 1998 11:09:32 PDT." <199804221809.LAA01225@feller.mentat.com> Date: Thu, 23 Apr 1998 17:51:21 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >I think that the ipi6_ifindex is still required in the in6_pktinfo structure. >The reason being that the sin6_index is the scope index for the sin6_addr. It is also the interface the packet will go out or come in on? >If the address in the sin6_addr field is a site-local or org-local address >then the interface on which the packet was received or is to be transmitted >is not specified. Why? >It is still important for routing protocols and other control functions >like DHCPv6 to allow for the interface index to be specified on outgoing >datagrams and received on incoming datagrams. We get that with sin6_index? >Of course an Itojun has pointed out we need to establish which index has >priority when someone does a sendmsg to a link-local address with an interface >index specified in the sockaddr_in6 and in a in6_pktinfo ancillary data item. But your saying they are different above regarding actual interface where the packet is sent or received so your confusing me? >My inclination is to specify that the ancillary data item index always takes >priority over the index specified in the sockaddr_in6 structure in the case >where the destination of the sendmsg is a link-local address. If it must exist I would say for all addresses? And we agree on the semantics of sin6_index of course? >In the case of a recvmsg which is receiving a datagram addressed to a link- >local address the two indices should be the same. Just use ancillary. >That leaves the case where the sin6_index has specified a site or organization >index but the ipi6_ifindex of the IPV6_PKTINFO ancillary data item is specifying >an interface which is not part of the specified site or organization. Clearly >this is an error which needs to be caught. Thats why one rules.. >It is not at all clear that we actually need the IPV6_MULTICAST_IF option >anymore. It is convenient. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 23 15:22:35 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id PAA24441 for ipng-dist; Thu, 23 Apr 1998 15:15:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id PAA24433 for ; Thu, 23 Apr 1998 15:15:41 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA15329 for ; Thu, 23 Apr 1998 15:15:33 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id PAA09514 for ; Thu, 23 Apr 1998 15:15:31 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA03925; Fri, 24 Apr 1998 08:12:36 +1000 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: Chris Harding , ipng@sunroof.eng.sun.com, xnet@opengroup.org Subject: (IPng 5720) Re: (c.harding 17704) Re: (c.harding 17696) sockaddr_in6 for the basic API In-Reply-To: A message of "Thu, 23 Apr 1998 17:41:31 -0400." References: <199804232141.AA31767@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Apr 1998 08:12:35 +1000 Message-Id: <13779.893369555@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 23 Apr 1998 17:41:31 -0400 From: bound@zk3.dec.com Message-ID: <199804232141.AA31767@wasted.zk3.dec.com> (quoting Chris Harding) | >On point 1. (sin6_reserved), ... | I think all the vendors who will build Host IPv6 APIs are on the IPngwg | List. Let them speak up now. I'm no vendor, but Chris is clearly right, requiring reserved fields so vendors can get API binary compability is silly - there are other ways that can be achieved, and vendors ought be free to choose the method that best suits their implementations. If vendors are to be assumed to be inept at the techniques involved, you may want to add a note to tell them they're allowed to add reserved fields so if extra fields are needed later they may be able to use the space reserved to retain binary compatability. I'm not sure if it is there already or not, but the spec should certainly explicitly say that the whole struct sockaddr_in6 must be zeroed before any fields are initialised, or having reserved fields is not going to help... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 23 16:24:55 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id QAA24612 for ipng-dist; Thu, 23 Apr 1998 16:19:30 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id QAA24605 for ; Thu, 23 Apr 1998 16:19:19 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA02887 for ; Thu, 23 Apr 1998 16:19:17 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id QAA12772 for ; Thu, 23 Apr 1998 16:19:14 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA21846; Thu, 23 Apr 98 16:15:55 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA01017; Thu, 23 Apr 1998 16:20:48 -0700 Date: Thu, 23 Apr 1998 16:20:48 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804232320.QAA01017@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5721) Re: sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > >I think that the ipi6_ifindex is still required in the in6_pktinfo structure. > >The reason being that the sin6_index is the scope index for the sin6_addr. > > It is also the interface the packet will go out or come in on? It depends. If the addresses scope is site-local and the node has multiple interfaces attached to the same site then no. The ability to know on which interface a datagram arrived has utility independent of whether we include an scope index in the sockaddr_in6. Routing protocols and other control functions (DHCPv6 maybe?) find it useful to know which interface a datagram arrived on. If a datagram is received from a site-local address then the sin6_index will be the site index not the interface index. These control programs will still need the in6_pktinfo.ipi6_ifindex in order to determine on which interface the packet arrived. Similarly I believe that these types of control programs will find it useful to be able to direct datagrams out specific interfaces using sendmsg. Maybe I am missing something but I remember routing daemon and DHCP implement- ors wanting this functionality pretty bad. It is a pain to implement so if I am wrong and they don't want it then I won't be upset to see the in6_pktinfo.ipi6_ifindex go. I could remove a bunch of pretty hideous code. > >My inclination is to specify that the ancillary data item index always takes > >priority over the index specified in the sockaddr_in6 structure in the case > >where the destination of the sendmsg is a link-local address. > > If it must exist I would say for all addresses? I am not sure I understand. The in6_pktinfo.ipi6_ifindex is an interface index only. It was intended to allow applications to determine which interface a datagram arrived on or direct a datagram out a specific interface. It really doesn't have anything to do with address scoping. It was claimed that the functionality had utility independent of the address scoping problems that the sockaddr_in6.sin6_index is intended to solve. If the folks who claimed that are happy with only having a sin6_index then great. I get to rip some bogus code. > And we agree on the semantics of sin6_index of course? > I guess yes. Although the details of how the sockaddr_in6.sin6_index and the in6_pktinfo.ipi6_ifindex interface in the case of link-local addresses needs to be clarified if the in6_pktinfo.ipi6_ifindex is going to survive. > >In the case of a recvmsg which is receiving a datagram addressed to a link- > >local address the two indices should be the same. > > Just use ancillary. > > >That leaves the case where the sin6_index has specified a site or organization > >index but the ipi6_ifindex of the IPV6_PKTINFO ancillary data item is specifying > >an interface which is not part of the specified site or organization. Clearly > >this is an error which needs to be caught. > > Thats why one rules.. > As I noted the in6_pktinfo.ipi6_ifindex is an interface index only. It can't really be used, at least as currently defined, to disambiguate sites. If we are going to change its semantics then I guess that we need to justify having it at all since that change in semantics would make it useless for the function for which it was originally intended. > >It is not at all clear that we actually need the IPV6_MULTICAST_IF option > >anymore. > > It is convenient. > I agree. I (re-)convinced myself that it has utility for applications which don't want the hassle of ancillary data. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 23 16:48:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id QAA24654 for ipng-dist; Thu, 23 Apr 1998 16:42:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id QAA24647 for ; Thu, 23 Apr 1998 16:42:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA09941 for ; Thu, 23 Apr 1998 16:42:03 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id QAA23677 for ; Thu, 23 Apr 1998 16:42:04 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA22058; Thu, 23 Apr 98 16:38:39 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id QAA01024; Thu, 23 Apr 1998 16:43:32 -0700 Date: Thu, 23 Apr 1998 16:43:32 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804232343.QAA01024@feller.mentat.com> To: kre@munnari.OZ.AU Subject: (IPng 5722) Re: (c.harding 17704) Re: (c.harding 17696) sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre, > > (quoting Chris Harding) > | >On point 1. (sin6_reserved), ... > > | I think all the vendors who will build Host IPv6 APIs are on the IPngwg > | List. Let them speak up now. > > I'm no vendor, but Chris is clearly right, requiring reserved fields so > vendors can get API binary compability is silly - there are other ways that > can be achieved, and vendors ought be free to choose the method that best > suits their implementations. > > If vendors are to be assumed to be inept at the techniques involved, you > may want to add a note to tell them they're allowed to add reserved fields > so if extra fields are needed later they may be able to use the space > reserved to retain binary compatability. > > I'm not sure if it is there already or not, but the spec should certainly > explicitly say that the whole struct sockaddr_in6 must be zeroed before > any fields are initialised, or having reserved fields is not going to > help... > There were a couple of reasons for having the reserved field. One was long term growth possibilities and ease of binary compatibility at the time of that growth and the other was alignment. By specifying the sin6_reserved field we get full 32-byte alignment of the structure. For some folks that is important. That said I think the whole binary compatibility thing is a non-issue. If a vendor or vendors need to add a field to the structure at some later time to support some new function then there are lots of ways to skin the binary compatibility cat. Heck, if it were up to me I would put the new sin6_index field in front of the sin6_flowinfo and remove the sin6_reserved field. Dealing with whatever binary compatibility issues that might raise is not free but it is not like building the pyramids. But I am a "go with the consensus" kind of guy so just forget that I wrote that.:-) tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 23 17:26:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id RAA24781 for ipng-dist; Thu, 23 Apr 1998 17:18:13 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id RAA24774 for ; Thu, 23 Apr 1998 17:17:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id RAA21346 for ; Thu, 23 Apr 1998 17:17:30 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id RAA10285 for ; Thu, 23 Apr 1998 17:17:27 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id AA21991; Fri, 24 Apr 1998 10:17:02 +1000 (from kre@munnari.OZ.AU) To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org Subject: (IPng 5723) Re: (c.harding 17704) Re: (c.harding 17696) sockaddr_in6 for the basic API In-Reply-To: A message of "Thu, 23 Apr 1998 16:43:32 -0700." References: <199804232343.QAA01024@feller.mentat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Apr 1998 10:17:01 +1000 Message-Id: <15056.893377021@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 23 Apr 1998 16:43:32 -0700 From: thartric@mentat.com (Tim Hartrick) Message-ID: <199804232343.QAA01024@feller.mentat.com> | There were a couple of reasons for having the reserved field. One was | long term growth possibilities and ease of binary compatibility at the time | of that growth and the other was alignment. By specifying the sin6_reserved | field we get full 32-byte alignment of the structure. For some folks that is | important. I doubt none of that - the point is that anyone who wants to add a reserved field for any of those reasons is free to do so, the spec doesn't need to demand that it be there. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 07:52:39 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id HAA25814 for ipng-dist; Fri, 24 Apr 1998 07:47:12 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id HAA25807 for ; Fri, 24 Apr 1998 07:47:02 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA12785 for ; Fri, 24 Apr 1998 07:47:01 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id HAA23521 for ; Fri, 24 Apr 1998 07:47:01 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail11.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id KAA06045; Fri, 24 Apr 1998 10:46:47 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA23668; Fri, 24 Apr 1998 10:46:07 -0400 Date: Fri, 24 Apr 1998 10:46:07 -0400 From: Jack McCann Message-Id: <199804241446.AA23668@wasted.zk3.dec.com> To: kre@munnari.OZ.AU Subject: (IPng 5724) Re: (c.harding 17704) Re: (c.harding 17696) sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As the one who suggested a reserved field... Yes there are other ways to provide binary compatibility, but explicitly providing for it in the structure itself seems more straight forward and less overhead than relying on mechanisms external to the structure. If we require the whole struct sockaddr_in6 must be zeroed prior to use then yes we can live without an explicit reserved field. - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 08:28:22 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id IAA25950 for ipng-dist; Fri, 24 Apr 1998 08:21:43 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id IAA25943 for ; Fri, 24 Apr 1998 08:21:29 -0700 (PDT) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.8.8) with ESMTP id IAA29622; Fri, 24 Apr 1998 08:21:04 -0700 (PDT) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.8.8+Sun/8.8.8) id IAA12553; Fri, 24 Apr 1998 08:20:47 -0700 (PDT) Date: Fri, 24 Apr 1998 08:20:47 -0700 (PDT) From: Mukesh Kacker Message-Id: <199804241520.IAA12553@lucknow.eng.sun.com> To: kre@munnari.OZ.AU, mccann@zk3.dec.com Subject: (IPng 5725) Re: (c.harding 17704) Re: (c.harding 17696) sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org, mukesh@lucknow.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As the one who suggested a reserved field... Yes there are other ways > to provide binary compatibility, but explicitly providing for it in the > structure itself seems more straight forward and less overhead than > relying on mechanisms external to the structure. > > > If we require the whole struct sockaddr_in6 must be zeroed prior to use > then yes we can live without an explicit reserved field. > Jack, Here are some opinions on this issue. I think the requirement that the whole struct be zeroed is necessary for binary compatibility on the assumption that the "reserved" field that reserves the space for future expanstion will be initialized to a "known" value (zero is often the right value too for the semantics) and future implementations can deal with older applications. But I do not see how we can "live without the explicit reserved field" for the "easy" method of binary compatibility which has motivated the suggestions to add it. The size of the structure will get encoded in the "intialize to zero code" and the extra length added by reserved field is needed to make sure "future fields" are intialized to zero value. [ There are strange and hairy ways to do binary compatibility but why resort to those when there is an easy option ? ] So, I think - adding the requirement to zero-intialize the data structure can be explicitly stated and is a good idea. Though you have to make sure zero is a valid "default" value for fields to be added in future which is the most likely case. - if we think more fields would be added in future, adding a reserved field is a good idea in the place where it is most likely to go. Sure the specs give freedom to vendors to do their fields in any order but most often the straightforward spec order is followed (deviating from that is the rare not the common case) and concern for binary compatibility dictates fields are added in the end of the structure. If we have an easy way to ensure most-likely-scenario for future binary compatibility, why not adopt it ? -Mukesh Kacker mukesh.kacker@eng.sun.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 08:57:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id IAA25984 for ipng-dist; Fri, 24 Apr 1998 08:46:36 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA25977 for ; Fri, 24 Apr 1998 08:46:25 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA27228; Fri, 24 Apr 1998 08:46:23 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA26301; Fri, 24 Apr 1998 08:46:24 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id LAA27504; Fri, 24 Apr 1998 11:46:22 -0400 (EDT) Received: by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA04306; Fri, 24 Apr 1998 11:46:16 -0400 Date: Fri, 24 Apr 1998 11:46:16 -0400 From: Jack McCann Message-Id: <199804241546.AA04306@wasted.zk3.dec.com> To: Mukesh.Kacker@Eng Subject: (IPng 5726) Re: (c.harding 17704) Re: (c.harding 17696) sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com, xnet@opengroup.org Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh, >[ There are strange and hairy ways to do binary compatibility but why > resort to those when there is an easy option ? ] > >So, I think > > - adding the requirement to zero-intialize the data structure can be > explicitly stated and is a good idea. Though you have to make sure > zero is a valid "default" value for fields to be added in future which > is the most likely case. > > - if we think more fields would be added in future, adding a reserved field > is a good idea in the place where it is most likely to go. > Sure the specs give freedom to vendors to do their fields in any order > but most often the straightforward spec order is followed (deviating > from that is the rare not the common case) and concern for binary > compatibility dictates fields are added in the end of the structure. > If we have an easy way to ensure most-likely-scenario for future binary > compatibility, why not adopt it ? I agree with your points. I am in favor of leaving the sin6_reserved field in the spec, but given the bzero requirement I was willing to let it go (with the intent to include it in our implementation anyway). - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 09:35:59 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id JAA26118 for ipng-dist; Fri, 24 Apr 1998 09:29:51 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with ESMTP id JAA26111 for ; Fri, 24 Apr 1998 09:29:45 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.0.Beta6+Sun/8.8.8) with ESMTP id JAA10316 for ; Fri, 24 Apr 1998 09:29:41 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.8.8+Sun/8.8.8) id JAA09161 for ipng@sunroof.eng.sun.com; Fri, 24 Apr 1998 09:29:27 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id IAA25995 for ; Fri, 24 Apr 1998 08:51:29 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA28582 for ; Fri, 24 Apr 1998 08:51:27 -0700 Received: from smtp3.ny.us.ibm.com (smtp3.ny.us.ibm.com [198.133.22.42]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA29458 for ; Fri, 24 Apr 1998 08:51:27 -0700 (PDT) Received: from relay1.server.ibm.com (relay1.server.ibm.com [9.14.2.98]) by smtp3.ny.us.ibm.com (8.8.7/8.8.7) with ESMTP id LAA34294; Fri, 24 Apr 1998 11:41:22 -0400 Received: from US.IBM.COM (d04lms03.raleigh.ibm.com [9.37.164.195]) by relay1.server.ibm.com (8.8.7/8.8.7) with SMTP id LAA56170; Fri, 24 Apr 1998 11:47:03 -0400 Received: by US.IBM.COM (Soft-Switch LMS 2.0) with snapi via D04AU035 id 5040300015365851; Fri, 24 Apr 1998 11:46:42 -0400 From: Mark Brown To: Cc: , , Subject: (IPng 5728) Re: (c.harding 17704) Re: (c.harding 17696) sock Message-ID: <5040300015365851000002L012*@MHS> Date: Fri, 24 Apr 1998 11:46:42 -0400 MIME-Version: 1.0 Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi- As a vendor, I think our worries are more about changing the ordering of fields already publicized, as opposed to adding a reserve field or other fields) at the end of the structure. Mark Brown ---------This message brought to you via PowerPC and Lotus Notes---------- Mark S. Brown IBM RS/6000 AIX System Architecture bmark@us.ibm.com 512.838.3926 T/L678.3926 IBM Corporation, Austin, Texas bound@zk3.dec.com on 04/23/98 04:38:23 PM Please respond to bound@zk3.dec.com To: c.harding@opengroup.org cc: xnet@opengroup.org, ipng@sunroof.eng.sun.com Subject: Re: (c.harding 17704) Re: (c.harding 17696) (IPng 5707) sock Chris, >Thanks for your reply. Ditto..... >On point 1. (sin6_reserved), I understand the argument that some vendors >will want to provide this field. What I don't yet understand is whether >there is an argument that says that a vendor who doesn't want to provide >this field should nevertheless be forced to. I think all the vendors who will build Host IPv6 APIs are on the IPngwg List. Let them speak up now. More here than on the XNET group. >On point 2. (sin6_index and interface indexes), I have no technical axe to >grind - my concern is just that whatever technical decisions are made should >be stated clearly. Agreed. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 10:11:42 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id KAA26272 for ipng-dist; Fri, 24 Apr 1998 10:01:52 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id KAA26265 for ; Fri, 24 Apr 1998 10:01:42 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA19113 for ; Fri, 24 Apr 1998 10:01:39 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA11059 for ; Fri, 24 Apr 1998 10:01:39 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id KAA19620; Fri, 24 Apr 1998 10:01:06 -0700 (PDT) Message-Id: <3.0.5.32.19980424100006.00a701c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 24 Apr 1998 10:00:06 -0700 To: minutes@ietf.org From: Bob Hinden Subject: (IPng 5729) IPng W.G. Minutes Los Angeles IETF Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng Minutes Los Angeles, IETF Robert Hinden / Nokia Steve Deering / Cisco co-chairs ---------------------------- Steve Deering introduced the meeting. Three meeting slots are scheduled. Robert Hinden took and edited the minutes. Monday 7:30PM - 10:00PM Tuesday 3:45PM - 4:45PM Thursday 9:00AM - 11:30AM The agenda was reviewed. The resulting agenda was: Monday Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) UNH Interoperability Testing / B. Lenharth (5 min) Document Status / R. Hinden (15 min) Mobile IPv6 Status / D. Johnson (15 min) Proposed ND Split / M. Wasserman (5 min) IPv6 over PVC ATM / S. Deering (10 min) IPv6 over NBMA & IPv6 over ATM Status / P. Schulter (10 min) Router Renumbering / M. Crawford (15 min) Scope Issues / S. Deering (30 min) Tuesday Multicast Listener Discovery Protocol / S. Deering (30 min) IPv6 Plug and Play, Done? / R. Hinden (30 min) Thursday DNS Status / S. Deering (30 min) ICMP Name Lookups / M. Crawford (5 min) ICMP Node Info / A. Durand (10 min) Reverse DNS Lookup / M. Crawford (15 min) IPv6 Host Naming Translations / J. Paugh (10 min) Address Allocation Status Report / R. Hinden (5 min) ------------------------------------------ UNH Interoperability Testing / B. Lenharth ------------------------------------------ [Editors note: B. Lenharth was not able to give the report. R. Hinden gave summary] Most recent test event was at Connectheon. No router vendors present. Used Sun as router between two segments. IMAG BGP4+athon Five implementations - cisco - Digital - Telebit-DK - Gated - MRT eBGP & iBGP tests route redistribution - BGP -> RIP - RIP -> BGP --------------------------- Document Status / R. Hinden --------------------------- RFC Published - RFC 2292 Advanced Sockets API for IPv6 (Informational) IESG Approved - MIB for IPv6: Textual Conventions & General Group / Jun 97 (PS) - MIB for IPv6: ICMPv6 Group / Jun 97 (PS) - IPv6 over PPP / Nov 97 (PS) - IPv6 Testing Address Allocation / Nov 97 (Informational) - IPv6 Multicast Address Assignments / Nov 97 (Informational) - IPv6 Packets over Token Ring Networks / Nov 97 (PS) - Generic Packet Tunneling in IPv6 Specification / Dec 96 (PS) - IPv6 Packets over FDDI Networks / Nov 97 (PS) - IPv6 Packets over Ethernet Networks / Nov 97 (PS) IETF Last Call completed for Proposed Standard - An IPv6 Aggregatable Global Unicast Address Format / Nov 97 (comments from Registries, new draft) - IP Version 6 Addressing Architecture / Nov 97 (new draft) - IP Header Compression / Nov 97 (need new ID, IPSEC) - MIB for IPv6: TCP / Jun 97 - MIB for IPv6: UDP / Jun 97 Submitted to IESG for Draft Standard - IPv6 Specification / Mar 98 - ICMPv6 / Mar 98 - Path MTU Discovery for IPv6 / Mar 98 - Submitted to IESG for Proposed Standard - IPv6 Router Alert Option (IESG returned, need new ID) Submitted to IESG for BCP - TLA and NLA Assignment Rules / Nov 97 IPng Working Group Last Call Completed for Draft Standard - Neighbor Discovery for IP Version 6 (IPv6) - IPv6 Stateless Address Autoconfiguration - IPng Working Group Last Call Completed for Proposed Standard - IPv6 over Point-to-Point ATM Link - IPng Working Group Last Call Completed for Experimental - IPv6 Name Lookups Through ICMP - IPng Working Group Last Call Ongoing - Router Renumbering for IPv6 (31 Mar 98) Submitted to IESG - IPv6 Specification - ICMPv6 - Path MTU Discovery for IPv6 - Implementation Reports ftp://playground.sun.com/pub/ipng/implementation-reports/ W.G. Last Call Completed - Neighbor Discovery for IP Version 6 (IPv6) - IPv6 Stateless Address Autoconfiguration TLA/NLA Assignment Rules Status - Plan to Create W.G. Unsuccessful - Should this be an IETF Document? - Meeting w/ Registries and IANA Tuesday - Proposed Changes (consistent w/ Current Aggregation Draft) o Focus on providing input from w.g. to IANA & Registries o TLA Assignment to all transit providers o Relax rules for peering and TLA routing o Remove Auction ------------------------------- Mobile IPv6 Status / D. Johnson ------------------------------- Mobile IPv6: IPv6 Changes and Open Issues Dynamic Home Agent Address Discovery - Mobile node may not always know its home agent address: o While mobile node is away from home o Home network may need to be reconfigured o Different machine may take over as home agent - Mobile IPv6 uses Home-Agents anycast address for this: o Mobile node sends to anycast address instead of directly to unicast home agent address o This home agent replies giving its own unicast address o But this anycast address (alone) only gets us only one home agent address o What if we then try to register with it but it says "busy," but there are other home agents on the home subnet? Improved Home Agent Discovery - Each home agent keeps a list of other home agents on subnet: o Home agents set new Home Agent (H) bit in Router Advertisements o Each home agent keeps a Home Agents List conceptual data structure, similar to Default Router List o Home agent replies to anycast giving complete list +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Other Neighbor Discovery Changes - New Advertisement Interval option for Router Advertisements: o Gives MaxRtrAdvInterval so mobile nodes know when they've missed (one or more) Advertisements from it +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertisement Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Discussion about need for this. Comparison with special home agent protocol. Mobile nodes need easy way to learn that they have moved. Proposal for sending to anycast address of home agent. Possible any assignment of "3" (0 is subnet router, 1 & 2 are for point-point link address assignment, 3 is next). Discussion about can interval be less than one seconds. Should ND be change to use milliseconds instead of seconds? Why is less than once second needed? Question about do all links need high frequency beacons? Only wireless? Mobile IP is not focused on wireless only. - Also allow MinRtrAdvInterval for home agents < 3 seconds: o Frequently enough to ``learn of their presence within a few minutes'' is not fast enough for mobile nodes moving about o Routers wanting to provide good service to mobile nodes MAY advertise more frequently Other Issues for IPng Working Group - How do we satisfy our IANA Considerations? o Need Destination Option type codes for 4 options o Need an anycast address for Home-Agents anycast - How do people know about Mobile IP SHOULDs and MUSTs? o Most important is requirement to be able to process received Home Address option - This applies to all implementations: hosts and routers, mobile and stationary --- everybody! o Suggestion: For now, collect all IPv6 requirements on a Web page, advertise it widely o Really need to write a real ``requirements'' document, but that's a big job (and too slow) ACTION DOC EDITOR: Get assignment for these options code points and start the anycast address assignment. Collect all code points. ND, ION, mobileIP etc. Deering and Johnson will write short draft describing anycast assignment in the next two weeks. Comments, Please - We are very close to going to Last Call for Mobile IPv6 - We need feedback/agreement from IPng Working Group - Please send e-mail comments to the Mobile IP mailing list: mobile-ip@SmallWorks.COM - Comments can also be sent to: o Dave Johnson, dbj@cs.cmu.edu o Charlie Perkins, cperkins@eng.sun.com -------------------------------- Proposed ND Split / M. Wasserman -------------------------------- ND is a useful set of mechanisms. Many IPv6 host will (and should) implement the full set. Some ND mechanisms may not apply to some: - link types - node types - situations Proposal to split ND into eight separable ND mechanisms - Address Resolution - Duplicate Address Detection (DAD) - Router Discovery - Prefix/parameter Discovery - Address Autoconfiguration - Router Unreachability Detection - Neighbor Unreachability Detection (NUD) - ICMP Redirects Requirement for minimal IPv6 functionality on many link types: - Address Resolution - DAD - ICMPv6 redirects Advanced Features: - Configuration o Router Discovery o Prefix/Parameter Discovery o Address Autoconfiguration - "Blackhole" detection / Fall back o Router Unreachability Detection o NUD Configuration "scopes": - Per link-type: all nodes must implement for communication to occur o Address resolution o ICMPv6 Redirects - Per link: Usefulness depends on cooperation of all nodes on link: o Duplicate address detection - Per link: Usefulness depends on cooperation of all routers on link: o Router discovery o Prefix/Parameter discovery - Per host/per-interface: can be useful without cooperation of all hosts on link: o Address Autoconfiguration o Router/Neighbor Unreachability detection Suggested specification changes - Make distinction between 8 mechanisms - Assign configuration scope, recommendations and defaults - Describe for separate implementations Suggested specification split: - Put minimal required mechanisms, related messages and descriptions into separate document o Address resolution o DAD o ICMPv6 Redirects Discussion. Suggestion was made that this document can define what is appropriate for each link types and what can be turned off. It would be an applicability document for ND and Autoconfiguration. ------------------------------ IPv6 over PVC ATM / S. Deering ------------------------------ Two competing specs for how to run IPv6 over ATM in a PVC mode. Point-to-point links between IPv6 nodes as opposed to using ATM in NBMA mode. IPv6 over PVC ATM draft and ION NBMA draft. In previous meetings the approach discussed was that there would be a separate document that defined this mode independently from full NBMA draft. Deadline proposed. Chairs believe deadline was end of January 1998 and that deadline has passed. ION document were published prior to March 1998 meeting. In ION documents IPv6overPVC-ATM is not in one place but spread over many sections in two documents. Some differences in two approaches: MTU, generation of link-local addresses, others? Deering's personal opinion is that it should not be spread over two documents. Would prefer PVC case to be in a single document. Stopped discussion and did following ION status. --------------------------------------------------- IPv6 over NBMA & IPv6 over ATM Status / P. Schulter --------------------------------------------------- ION meet today and discussed this issue. Grenville Armitage (Lucent) Peter Schulter (Bright Tiger Technologies) Markus Jork, Geraldine Harter (Digital) The General Architecture - Assume general NBMA 'cloud' o Capable of pt-pt links (static or dynamic) o Capable of pt-mpt links (dynamic, real or emulated) o May or may not have native 'multicast' - NBMA cloud could be o ATM o Frame Relay o IPv4 network o ... - MARS ? NHRP ? o Only used for SVC mode where native multicast is not supported, and dynamic shortcuts make sense Since last we met.... - Modified host triggered redirection behavior (replies are now Redirects) - Added new Shortcut Limit option for host triggered redirect (NS) message - General text cleanup Open Issues: - Assignment of a new ND option number (we picked the next available number) ACTION IPng Doc Editor: Get option assignment - What is it? o is a media-specific companion document to - Contains o Rules of generation of ND link tokens and link address fields o Codepoints for MARS and NHRP messages o Rules for LLC/SNAP encapsulation - Null encapsulation optional o Covers PVC and SVC cases separately - Clients do not need to implement SVC related extensions (eg. MARS) if only PVC support is required PVC rules - Standard LLC/SNAP encaps, with IPv6 PID o Null encapsulation allowed/negotiable - Default IP MTU of 9180 octets - All PVC rules now in section 3.1 (encapsulation, MTU, link token generation) SVC rules - Standard LLC/SNAP encaps with IPv6 PID o Different unicast and multicast formats as per RFC2022 o Null encapsulation discouraged, since it cannot be used between MARS and IPv6/NBMA client anyway --------------------------------------------------------- Continuation of IPv6 over PVC ATM Discussion / S. Deering --------------------------------------------------------- Three points: 1) Technical differences. "IPv6 over Point-to-Point ATM Link" spec is what has been implemented in WIDE implementation. 2) Should there be a stand alone document? 3) If we go with ION document, there should be proper acknowledgment of < authors. Asked for comments. Discussion. Many liked separate document. Suggested to use ION link-local rules. Another comment suggested that once technical issues resolved we should go with ION work. Suggestion that ION has been implemented as well. Discussion should have happened in ION. K. Yamamoto is willing to defer to ION, but wants it out quickly. Deering suggested that K. Yamamoto and ION authors get together and resolved differences. Would still like to have the PVC document be stand alone. Will go forward with ION document with closer coordination from K. Yamamoto. -------------------------------- Router Renumbering / M. Crawford -------------------------------- Status draft -03 - In w.g. last call - Outstanding issues o Stagger replies to multicast command o Limit multicast destination addresses to all routers only o Check for formation of unacceptable address (multicast, etc.) during execution - Open questions o enable matching conditions on length of prefix? Yes o Forbid formation of v4-compatible address? Yes o Discard custom authentication -IPSEC only? Yes, frees up field Spin-Off work - Define "Site" - Or agree not to Comment that given authentication this document does not need to define site. Security implicately defines site. -------------------------------------------------- Multicast Listener Discovery Protocol / S. Deering -------------------------------------------------- New draft out . Equivaliant of IPv4 IGMP for IPv6. Changes: - Using Link-local address for sourcing messages - Packet formats - Terminology Solicited comments. ------------------------- Scope Issues / S. Deering ------------------------- Discussion with diagrams. | | | | | | | | | +--------+ +--------+ +--------+ | | | | | | | Rtr | | Rtr | | Rtr | | | | | | | +--------+ +--------+ +--------+ | | | | | | | | | ============================================ Link Local: Drew scope boundary through the middle of Routers Site Local: Showed three alternatives. First site boundaries is in the middle of routers. Second boundary is in the middle of links. Third is interface based. Assumption that sites are not overlapping. Overlapping sites are not currently supported. There is only one site-local prefix. Question about why we want site local. Why do we want to have them? This was discussed at length on mailing list. Conclusion was to keep them. It would be more destructive to get rid of them, than to keep them and to define usage. Current objective is they are useful during renumbering. Site local addresses don't have to change. Comment that Erik Nordmarks draft is only defined usage of site-local. Think we can keep this usage without defining in detail. Deering want to propose simple definition with guidance for implementors. If they don't get use, this will not be a problem. +--------+ +--------+ | | | | | Rtr 1 +--------------------+ Rtr 2 | | | | | +--------+ +--------+ ..site A.. | ..........site B........... | ......site C......... In this example there is a site boundary between each router. This results in three sites (left 1/2 of rtr 1, right 1/2 of rtr 1 through left 1/2 of Rtr 2, etc. Long discussion..... General consensus in the discussion to keep site local and agreement to make site boundaries in node (not link or interface). ACTION: S. Deering to write a draft ------------------------------------- IPv6 Plug and Play, Done? / R. Hinden ------------------------------------- Context - Plug and Play likely to be IPv6's Carrot - Makes IP Easy to Use! - Lowers Cost of Ownership for Enterprises and ISP's - Enables Network Appliances o Phones, PDAs, Games, household appliances, etc. Where Are We Now? - ND and AddrConf o Global Address Creation o Router Discovery o IP Parameters - DHCPv6 - Router Renumbering o Centralized reconfiguration of Router Advertisement Information - DNS o Automatic Creation of Reverse Map What Is Missing? - DNS o How to find DNS Server o How to register Node DNS name - Services o How to find Printers, File Servers, etc. o Enterprise and Home Office solution Solutions - Role of Service Location Protocol o Appropriate for General Service Location o Works with and without Servers o Not appropriate for DNS server location - DNS Server Location o Need Something New - DNS Name Registration o Status of Dynamic DNS Updating? DNS Server Location - Need to Learn o Server Address(s) o Default Domain o Domain Suffix Search list o Others? - Issues o Authentication o Lifetimes o Changing Approaches - Add Attribute to ND Router Advertisements o Requires adding this info to Routers o What if no Router? - DNS Server Advertisements? - Anycast Address for DNS Servers o Requires further communication w/ DNS server to get other related information - Multicast Address for DNS Servers o Use Expanding Ring (TTL) Search Next Steps - Discussion - Pick Approach Ohta: for DNS lookups, and DNS server will do; for registering/updating names, need specific server Nordmark: what about coffee machines without keypads? Bound: don't dump on servers! Cheshire: svrloc allows literal addresses, so would work fine for DNS discovery Deering: maybe spin off to a separate working group? Bound: to use anycast, need to allow hosts to have anycast addrs Durand: DNS service itself is complex, server-based; not exactly what dentists want? more random discussion... General conclusion that topic should be pursued, but not clear if it should be in the IPng working group. ----------------------- DNS Status / S. Deering ----------------------- First item is where we are in DNS work. Major piece of core charter. Need to find current state and what should we do. What document should be moved forward, what not, what else needs to be done. Solicited opinion. CH: Did revision of draft based on previous decision. Submitted first release in January. New draft based on comments. Draft stable. Added tutorial part, comment to expand this and clarify. Reluctant to do any changes. Wants doc to go to w.g. last call. Has not received any major objections. Only wants to make changes based on w.g. comments. Waiting for results of reverse lookup. Publish as is or merge with new reverse lookup approach. Relationship w/ current RFC. Backwards compatible with current AAAA RFC. Conclusion (w/ no objections) is this will replace current AAAA RFC. RFC1886 will become obsoleted (historic). ACTION: Chairs do W.G. last call for when new draft is out. ------------------------------- ICMP Name Lookups / M. Crawford ------------------------------- Status (-02) - In w.g. last call for experimental. - Could rolled in with several other suggestions. Wants to hold off moving this forward until that is resolved. -------------------------- ICMP Node Info / A. Durand -------------------------- ICMP Node Info / Local extensions of ICMP "who are you" Motivation - Local address <=> "local name" mapping - Local address <=> global address mapping - local topology discovery - "local name" space discovery => local means "link local" or "site local" - Something very simple Two ICMP types, several codes, X: request, Y: reply X/0: "localname" request Y/0: "local name" reply X/1: incomming interface Y/1: incomming interface global address request global address reply X/2: all interfaces global Y/2: All interfaces global address request address reply Unicast Usage - X has only Y link local address and wants to discovery: o Y "local" name o Y global addresses Multicast Discovery - "Allowed" multicast destination addresses o All node link local o All router link local o All route site local - Source address of requests and replies packets MUST be local - Replies may be multicast to all node link local - anti-flooding mechanisms are needed Security Considerations - Do we open a can of worms? - Is IPSEC appropriate - if yes, is it necessary? Question: relationship between this and link local naming. CH: Should coffee pot use this or DNS? Answer this. Discussion. Generally thinks naming functions should be in DNS resolver and not in ICMP. M. Otha: Should this be used in sites? No only link scope. These names should only be used with limited scope. This can be used to discover all of the names on the link. Deering: Thinks functionality should be in resolver, but that doesn't mean that this needs to be in DNS protocol. Matt: Could make small changes to "who are you" draft to allow more request types and replies. Kazu: Doesn't link this under ICMP. On Unix systems UDP would be better. Need root access to send/receive ICMP messages. ACTION: Chairs to figure out how to keep this work going. Might be in new w.g., somewhere else. Dimitry H: Need mechanisms to discover global address of router from link-local address. Doesn't think SNMP is appropriate. Could add ND option to router advertisement to advertise global address of router. Can we require routers to accept packets sent to prefix it is advertising with interface ID from link local address of router. Becomes an anycast address for router. Deering: links and subnets are not necessarily the same thing. Would like architecture to allow subnets to span multiple links. Discussion.... Nordmark: Wants to keep node in control of what addresses it uses. Doesn't want other nodes to decide. Also, is this also needed for hosts too? Bound: Thinks we should just have ND advertise all address of node. Nordmark: If so, would need to add lifetimes with each addresses. Lots of detail here. Otha: Thinks sites are collection of links. Discussion.... ----------------------------------------- Reverse DNS Lookup / M. Crawford ----------------------------------------- IPv6 DNS Lookups Goals and Semi-Goals - Delegate on arbitrary boundaries - Cacheable intermediate data - A single zone can be used under multiple higher-level prefixes. - Zone needs no modification if net is renumbered - Coexists with existing ipv6.int - Forward and reverse can be in sme zone file. New DNS Tools - Binary Labels o Compact representation of bit-string with semantics of a sequence of 1-bit domain labels: \[x200100/24].ip6.int. o Longest-match fallback when nameor datanot found - Non-terminal domain renaming (DNAME) o Maps a suffix set of labels to a different suffix: c.d.d.f. DNAME y.z causes a query for a.b.c.d.e.f. to go to a.b.y.z Proposed Structure - Higher-level registries of ISPs delegate address space to a domain chosen by the lower-level entity. - The delegated prefix disappears in the mapping o Hence, lower-level domain can be used with multiple prefixes - The delegating DNAME record can be cached [ Slide w/ examples] Pesky Details - How to look up site-local addresses? o Resolvers know to use only same-site DNS server? o Top level delegates \[xFEC0/10] to special name with site-local addresses? - Like Questions: Has this been reviewed by DNS w.g.? Meet yesterday, feeling is that it should be done. Some technical details to work out, but should be done quickly. Expect to be done by next IETF meeting (August 98). CH: Thinks this is compatible with new DNS draft. Has talked to Matt C. about it. Good to have all of this together. Good thinking, very complementary. All data in one place. Only practical question is of timing. Relationship between DNAME and Binary Lables? Could this be blocked for a long time? Matt did not think this would happen. KRE: DNS group has a good track record to get work out. Should be ready for IESG by next IETF. Conclusion is to merge the two drafts. ---------------------------------------- IPv6 Host Naming Translations / J. Paugh ---------------------------------------- Solaris NIS/NIS+ Naming Services Goal is to not break IPv4 applications IPv4 & IPv6 Addresses Stored Separately - NIS map, NIS+ table and /etc file created for IPv6 addresses - Prevents existing IPv4 applications from unexpectedly receiving IPv6 addresses - Separate IPv6 database can be served by older slave/ replica Server Side Changes - New IPv6 host database created o hosts6.byname/hosts6.byaddr maps for NIS o hosts6.org_dir table for NIS+ o "AAAA" record for DNS o /etc/inet/hosts6 file for local file o Updated utilities to create hosts6 database (ypmake(1M), nisaddent(1M), nispopulate(1M), etc) [ Figure showing getXbyY() Application ] ------------------------------------------ Address Allocation Status Report / R. Hinden ------------------------------------------ Address Allocation Status Report / R. Hinden Meet with registries and IANA. General conclusion is continue with approach described on Monday. New change is approach to initially assign sub TLA to transit providers who request allocation. When this is 90% used, they can then ask for a full TLA. This will be assigned with the understanding that they will have to give back the sub-TLA after a transition period. This should keep the top level routing in the order of the number of transit providers. Will work with registries and IANA to revise the draft. Expect to publish it in early May. Dimitry: Make sure policy doc does not rule out allocation of TLAs to exchanges. Carpenter: this doc will not be an IESG-approved doc; will be published as Informational RFC. ----------------------- IANA Status / R. Hinden ----------------------- Meet with Jon Postel. Will collect and sanitize current code point request and send to IANA. Future request sent to IANA will be reviewed by IPng document editor. R. Hinden will serve as IANA technical reviewer for v6 numbers; asked for all spec authors to email him their code-point requirements and corresponding document citations. ------------------------- Meeting adjourned ------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 11:03:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id KAA26374 for ipng-dist; Fri, 24 Apr 1998 10:56:55 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id KAA26367 for ; Fri, 24 Apr 1998 10:56:43 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA07184 for ; Fri, 24 Apr 1998 10:56:31 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA13441 for ; Fri, 24 Apr 1998 10:56:26 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id NAA22754; Fri, 24 Apr 1998 13:56:25 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA11812; Fri, 24 Apr 1998 13:56:23 -0400 Message-Id: <199804241756.AA11812@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5730) Re: sockaddr_in6 for the basic API In-Reply-To: Your message of "Thu, 23 Apr 1998 16:20:48 PDT." <199804232320.QAA01017@feller.mentat.com> Date: Fri, 24 Apr 1998 13:56:23 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk tim, I need to go back to square one here. sin6_index to me is the index of an interface. just like the one in pktinfo. whether that index is for a particular scope is determined either before or after the app sends/receives the packet. scoping and interfaces are disjoint and only joint as an abstraction. ergo I could use index 1 (interface 1) for link, site, or global. If index 1 does not support a particular site based on the sin6addr then I need to find a different interface (sin6_index). /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 12:13:15 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id MAA26436 for ipng-dist; Fri, 24 Apr 1998 12:07:59 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id MAA26429 for ; Fri, 24 Apr 1998 12:07:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA28174 for ; Fri, 24 Apr 1998 12:07:46 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA23634 for ; Fri, 24 Apr 1998 12:07:48 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA29446; Fri, 24 Apr 98 12:04:24 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA01692; Fri, 24 Apr 1998 12:09:17 -0700 Date: Fri, 24 Apr 1998 12:09:17 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804241909.MAA01692@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5731) Re: sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > I need to go back to square one here. > As do I. I think you and I agree but I am not communicating very effectively. > sin6_index to me is the index of an interface. just like the one in > pktinfo. > > whether that index is for a particular scope is determined either before > or after the app sends/receives the packet. > > scoping and interfaces are disjoint and only joint as an abstraction. > > ergo I could use index 1 (interface 1) for link, site, or global. > > If index 1 does not support a particular site based on the sin6addr then > I need to find a different interface (sin6_index). > Lets look at an example of a routing daemons. Routing daemons are usually interested in knowing on which interface a datagram arrived. We all have various mechanisms in our IPv4 stacks to communicate this information through the socket API to an application like a routing daemon. They also like to be able to direct datagrams out specific interfaces. As I understand the sockaddr_in6.sin6_index field's definition it is a small integer which indicates the scope on which a datagram which has a limited scope source address arrived. So if you have a machine which is attached to two sites you will assign a site index of 1 to each interface on the machine which resides in site 1 and a site index of 2 to each interface on the machine which resides in site 2. You also may have some other mechanism for grouping interfaces which reside in the same site. The net result will be that you will be able to disambiguate datagrams which arrive from the two sites. Now when an application does a recvfrom and the address in the sockaddr_in6- .sin6_addr field is a site-local address, the sockaddr_in6.sin6_index will be either 1 or 2 depending on the site from which the datagram arrived. Similarly, if the sockaddr_in6.sin6_addr field is a link-local address, the sockaddr_in6.sin6_index will be the interface index of the interface from which the datagram arrived. The meaning of the sockaddr_in6.sin6_index is determined by the scope of the address in the sockaddr_in6.sin6_addr field. Site-local address, site index, link-local address, interface index. Now back to the routing daemon. If a routing daemon is receiving routing updates which use site-local addresses as their source address (I know most routing protocols use link-local addresses) then using nothing more than recvfrom will not allow it to determine on which interface the datagram arrived. This is because the sockaddr_in6.sin6_index will be a site index not an interface index. In order for this routing daemon to determine on which interface the datagram arrived it needs to use recvmsg and request reception of the IPV6_PKTINFO ancillary data item. As currently defined the IPV6_PKTINFO ancillary data item is a in6_pktinfo structure which contains the ipi6_addr and jpi6_ifindex fields. When used with recvmsg the in6_pktinfo.ipi6_addr is initialized to the destination address of the datagram being received and the in6_pktinf.ipi6_ifindex is initialized to the interface index of the interface which received the datagram. The routing daemon has a similar problem when transmitting packets to site-local destinations. It wants to direct datagrams out a specific interface but because it is using site-local address the sockaddr_in6.- sin6_index is a site index. It needs another mechanism which will allow it to specify the interface out of which it would like to transmit the site-locally addressed datagram. That mechanism is the IPV6_PKTINFO ancillary data item. This example is derived from discussions which I have had and overheard others having with folks who write and maintain routing daemon and DHCP code for BSD systems. Those folks claim to need the facility provided by the current definition of the IPV6_PKTINFO ancillary data item. If in fact they don't need it then I would love to see it get nuked. I just want to make sure that everyone understands why it is there and what it is used for before we rip it out or change it significantly. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 13:25:41 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id NAA26668 for ipng-dist; Fri, 24 Apr 1998 13:15:42 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id NAA26661 for ; Fri, 24 Apr 1998 13:15:32 -0700 (PDT) From: bound@zk3.dec.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA17274 for ; Fri, 24 Apr 1998 13:15:30 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id NAA00441 for ; Fri, 24 Apr 1998 13:15:30 -0700 (PDT) Received: from wasted.zk3.dec.com (fwasted.zk3.dec.com [16.140.160.5]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id QAA19165; Fri, 24 Apr 1998 16:15:29 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00258; Fri, 24 Apr 1998 16:15:25 -0400 Message-Id: <199804242015.AA00258@wasted.zk3.dec.com> To: thartric@mentat.com (Tim Hartrick) Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 5732) Re: sockaddr_in6 for the basic API In-Reply-To: Your message of "Fri, 24 Apr 1998 12:09:17 PDT." <199804241909.MAA01692@feller.mentat.com> Date: Fri, 24 Apr 1998 16:15:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, OK I am with you too. Also yes we need that for the routing daemon and for DHCPv6. So......... I think we need to change sin6_index's name to: sin6_identifier the reason is that is really what it is and also it won't pollute many implementation namespaces that use "index" to mean only the interface. We would use sin6_addr to determine scope. But....... I now think we do need sin6_ifindex field which does specify the normal case of the index we are choosing. We would have to let the sin6_identifier override sin6_ifindex in cases of site, org, etc as stated. Then I don't think we need the index in the pktinfo structure of the advanced API. But I do think we should keep IPV6_MULTICAST_IF field in mreq struct. ??? thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 15:05:20 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id OAA26769 for ipng-dist; Fri, 24 Apr 1998 14:56:41 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id OAA26762 for ; Fri, 24 Apr 1998 14:56:31 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA14530 for ; Fri, 24 Apr 1998 14:56:29 -0700 Received: from rast.cisco.com (rast.cisco.com [171.69.187.231]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id OAA23542 for ; Fri, 24 Apr 1998 14:56:28 -0700 (PDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by rast.cisco.com (8.8.7/8.8.7) with SMTP id OAA24731; Fri, 24 Apr 1998 14:53:55 -0700 (PDT) (envelope-from raj@cisco.com) Message-Id: <199804242153.OAA24731@rast.cisco.com> To: bound@zk3.dec.com cc: thartric@mentat.com (Tim Hartrick), ipng@sunroof.eng.sun.com Subject: (IPng 5733) Re: sockaddr_in6 for the basic API In-reply-to: Your message of "Fri, 24 Apr 1998 16:15:25 EDT." <199804242015.AA00258@wasted.zk3.dec.com> X-Quote: If you consult enough experts, you can confirm any opinion. Date: Fri, 24 Apr 1998 14:53:54 -0700 From: Richard Johnson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think we need to change sin6_index's name to: > > sin6_identifier Why not call it what is really is: "sin6_interface". "sin6_identifier" seems a little vague to me. /raj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 15:07:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id PAA26787 for ipng-dist; Fri, 24 Apr 1998 15:03:24 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id PAA26780 for ; Fri, 24 Apr 1998 15:03:13 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA16392 for ; Fri, 24 Apr 1998 15:03:08 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by earth.sun.com (8.8.8/8.8.8) with SMTP id PAA27078 for ; Fri, 24 Apr 1998 15:03:08 -0700 (PDT) Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA00892; Fri, 24 Apr 98 14:59:48 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA01757; Fri, 24 Apr 1998 15:04:43 -0700 Date: Fri, 24 Apr 1998 15:04:43 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199804242204.PAA01757@feller.mentat.com> To: bound@zk3.dec.com Subject: (IPng 5734) Re: sockaddr_in6 for the basic API Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > I think we need to change sin6_index's name to: > > sin6_identifier > I don't care what we call it as long as we don't name it sin6_svetlana.:-) What it means is what is important. > the reason is that is really what it is and also it won't pollute many > implementation namespaces that use "index" to mean only the interface. > > We would use sin6_addr to determine scope. > > But....... > > I now think we do need sin6_ifindex field which does specify the normal > case of the index we are choosing. We would have to let the > sin6_identifier override sin6_ifindex in cases of site, org, etc as > stated. > > Then I don't think we need the index in the pktinfo structure of the > advanced API. > I don't think we need to add this much complexity to the base processing rules of sockaddr_in6's. All we need to do, and all Itojun was asking in his original note, was that we define what happens when someone does a sendmsg to a link-local address with a sockaddr_in6.sin6_index initialized to and includes a IPV6_PKTINFO ancillary data item which specifies an in6_pktinfo.ipi6_ifindex of . Which index wins. If we define that we don't have any other problems. My inclination about which index should win is that the IPV6_PKTINFO ancillary data item overrides the sockaddr_in6.sin6_index. We can also say that the sockaddr_in6.sin6_index wins. We just need to write it down and we are done. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 18:17:11 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id SAA27543 for ipng-dist; Fri, 24 Apr 1998 18:11:49 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id SAA27536 for ; Fri, 24 Apr 1998 18:11:36 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA28000 for ; Fri, 24 Apr 1998 18:11:34 -0700 Received: from postoffice.cisco.com (postoffice-lane0.cisco.com [171.69.197.66]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA13494 for ; Fri, 24 Apr 1998 18:11:36 -0700 (PDT) Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by postoffice.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA24209; Fri, 24 Apr 1998 18:11:36 -0700 (PDT) X-Sender: deering@postoffice.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 Apr 1998 18:12:51 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 5735) NLPID for IPv6? Cc: Ofer Weill Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a vague memory of a NLPID being assigned to IPv6. Does anyone else here know if that's true and, if so, what the NLPID value is? Steve --------- > To: deering@cisco.com > From: Ofer Weill > Subject: NLPID for IPv6 > > Hello Steve, > > I try to find if IPv6 got a different NLPID number or it's number is the > same as IPv4 (0xCC) ? > >Thanks for your attention, > > Ofer > > >--------------------------------------------------------------------- >Ofer Weill >RAD data communications ltd. >31 Hbarzel St. Tel :+972.3.6455428 >TEL-AVIV 69710 Fax :+972.3.6455750 >ISRAEL E-mail:ofer_w@radmail.rad.co.il -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Apr 24 18:59:13 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) id SAA28031 for ipng-dist; Fri, 24 Apr 1998 18:50:08 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta6+Sun/8.9.0.Beta6) with SMTP id SAA28024 for ; Fri, 24 Apr 1998 18:49:56 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA02932 for ; Fri, 24 Apr 1998 18:49:54 -0700 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id SAA24551 for ; Fri, 24 Apr 1998 18:49:57 -0700 (PDT) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.7/8.6.10) with SMTP id SAA03088; Fri, 24 Apr 1998 18:49:23 -0700 (PDT) Message-Id: <3.0.5.32.19980424184822.009cb580@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 24 Apr 1998 18:48:22 -0700 To: minutes@ietf.org From: Bob Hinden Subject: (IPng 5736) Update IPng W.G. Minutes Los Angeles IETF Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng Minutes Los Angeles, IETF Robert Hinden / Nokia Steve Deering / Cisco co-chairs --------------------------------- Steve Deering introduced the meeting. Three meeting slots are scheduled. Robert Hinden took and edited the minutes. Monday 7:30PM - 10:00PM Tuesday 3:45PM - 4:45PM Thursday 9:00AM - 11:30AM The agenda was reviewed. The resulting agenda was: Monday Introduction / S. Deering (5 min) Review Agenda / S. Deering (5 min) UNH Interoperability Testing / B. Lenharth (5 min) Document Status / R. Hinden (15 min) Mobile IPv6 Status / D. Johnson (15 min) Proposed ND Split / M. Wasserman (5 min) IPv6 over PVC ATM / S. Deering (10 min) IPv6 over NBMA & IPv6 over ATM Status / P. Schulter (10 min) Router Renumbering / M. Crawford (15 min) Scope Issues / S. Deering (30 min) Tuesday Multicast Listener Discovery Protocol / S. Deering (30 min) IPv6 Plug and Play, Done? / R. Hinden (30 min) Thursday DNS Status / S. Deering (30 min) ICMP Name Lookups / M. Crawford (5 min) ICMP Node Info / A. Durand (10 min) Reverse DNS Lookup / M. Crawford (15 min) IPv6 Host Naming Translations / J. Paugh (10 min) Address Allocation Status Report / R. Hinden (5 min) ------------------------------------------ UNH Interoperability Testing / B. Lenharth ------------------------------------------ [Editors note: B. Lenharth was not able to give the report. R. Hinden gave summary] Most recent test event was at Connectathon. No router vendors present. Used Sun as router between two segments. IMAG BGP4+athon Five implementations - Cisco - Digital - Telebit-DK - Gated - MRT eBGP & iBGP tests route redistribution - BGP -> RIP - RIP -> BGP --------------------------- Document Status / R. Hinden --------------------------- RFC Published - RFC 2292 Advanced Sockets API for IPv6 (Informational) IESG Approved - MIB for IPv6: Textual Conventions & General Group / Jun 97 (PS) - MIB for IPv6: ICMPv6 Group / Jun 97 (PS) - IPv6 over PPP / Nov 97 (PS) - IPv6 Testing Address Allocation / Nov 97 (Informational) - IPv6 Multicast Address Assignments / Nov 97 (Informational) - IPv6 Packets over Token Ring Networks / Nov 97 (PS) - Generic Packet Tunneling in IPv6 Specification / Dec 96 (PS) - IPv6 Packets over FDDI Networks / Nov 97 (PS) - IPv6 Packets over Ethernet Networks / Nov 97 (PS) IETF Last Call completed for Proposed Standard - An IPv6 Aggregatable Global Unicast Address Format / Nov 97 (comments from Registries, new draft) - IP Version 6 Addressing Architecture / Nov 97 (new draft) - IP Header Compression / Nov 97 (need new ID, IPSEC) - MIB for IPv6: TCP / Jun 97 - MIB for IPv6: UDP / Jun 97 Submitted to IESG for Draft Standard - IPv6 Specification / Mar 98 - ICMPv6 / Mar 98 - Path MTU Discovery for IPv6 / Mar 98 Submitted to IESG for Proposed Standard - IPv6 Router Alert Option (IESG returned, need new ID) Submitted to IESG for BCP - TLA and NLA Assignment Rules / Nov 97 IPng Working Group Last Call Completed for Draft Standard - Neighbor Discovery for IP Version 6 (IPv6) - IPv6 Stateless Address Autoconfiguration IPng Working Group Last Call Completed for Proposed Standard - IPv6 over Point-to-Point ATM Link IPng Working Group Last Call Completed for Experimental - IPv6 Name Lookups Through ICMP IPng Working Group Last Call Ongoing - Router Renumbering for IPv6 (31 Mar 98) Moving Specifications to Draft Standard - Submitted to IESG o IPv6 Specification o ICMPv6 o Path MTU Discovery for IPv6 o Implementation Reports ftp://playground.sun.com/pub/ipng/implementation-reports/ - W.G. Last Call Completed o Neighbor Discovery for IP Version 6 (IPv6) o IPv6 Stateless Address Autoconfiguration TLA/NLA Assignment Rules Status - Plan to Create W.G. Unsuccessful - Should this be an IETF Document? - Meeting w/ Registries and IANA Tuesday - Proposed Changes (consistent w/ Current Aggregation Draft) o Focus on providing input from w.g. to IANA & Registries o TLA Assignment to all transit providers o Relax rules for peering and TLA routing o Remove Auction ------------------------------- Mobile IPv6 Status / D. Johnson ------------------------------- Mobile IPv6: IPv6 Changes and Open Issues Dynamic Home Agent Address Discovery - Mobile node may not always know its home agent address: o While mobile node is away from home o Home network may need to be reconfigured o Different machine may take over as home agent - Mobile IPv6 uses Home-Agents anycast address for this: o Mobile node sends to anycast address instead of directly to unicast home agent address o This home agent replies giving its own unicast address o But this anycast address (alone) gets us one home agent address o What if we then try to register with it but it says "busy," but there are other home agents on the home subnet? Improved Home Agent Discovery - Each home agent keeps a list of other home agents on subnet: o Home agents set new Home Agent (H) bit in Router Advertisements o Each home agent keeps a Home Agents List conceptual data structure, similar to Default Router List o Home agent replies to anycast giving complete list +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H| Reserved| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Other Neighbor Discovery Changes - New Advertisement Interval option for Router Advertisements: o Gives MaxRtrAdvInterval so mobile nodes know when they've missed (one or more) Advertisements from it +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertisement Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Discussion about need for this. Comparison with special home agent protocol. Mobile nodes need easy way to learn that they have moved. Proposal for sending to anycast address of home agent. Possible any assignment of "3" (0 is subnet router, 1 & 2 are for point-point link address assignment, 3 is next). Discussion about can interval be less than one second. Should ND be change to use milliseconds instead of seconds? Why is less than once second needed? Question about do all links need high frequency beacons? Only wireless? Mobile IP is not focused on wireless only. - Also allow MinRtrAdvInterval for home agents < 3 seconds: o Frequently enough to ``learn of their presence within a few minutes'' is not fast enough for mobile nodes moving about o Routers wanting to provide good service to mobile nodes MAY advertise more frequently Other Issues for IPng Working Group - How do we satisfy our IANA Considerations? o Need Destination Option type codes for 4 options o Need an anycast address for Home-Agents anycast - How do people know about Mobile IP SHOULDs and MUSTs? o Most important is requirement to be able to process received Home Address option - This applies to all implementations: hosts and routers, mobile and stationary --- everybody! o Suggestion: For now, collect all IPv6 requirements on a Web page, advertise it widely o Really need to write a real ``requirements'' document, but that's a big job (and too slow) ACTION DOC EDITOR: Get assignment for these options code points and start the anycast address assignment. Collect all code points. ND, ION, mobileIP etc. Deering and Johnson will write short draft describing anycast assignment in the next two weeks. Comments, Please - We are very close to going to Last Call for Mobile IPv6 - We need feedback/agreement from IPng Working Group - Please send e-mail comments to the Mobile IP mailing list: mobile-ip@SmallWorks.COM - Comments can also be sent to: o Dave Johnson, dbj@cs.cmu.edu o Charlie Perkins, cperkins@eng.sun.com -------------------------------- Proposed ND Split / M. Wasserman -------------------------------- ND is a useful set of mechanisms. Many IPv6 host will (and should) implement the full set. Some ND mechanisms may not apply to some: - link types - node types - situations Proposal to split ND into eight separable ND mechanisms - Address Resolution - Duplicate Address Detection (DAD) - Router Discovery - Prefix/parameter Discovery - Address Autoconfiguration - Router Unreachability Detection - Neighbor Unreachability Detection (NUD) - ICMP Redirects Requirement for minimal IPv6 functionality on many link types: - Address Resolution - DAD - ICMPv6 redirects Advanced Features: - Configuration o Router Discovery o Prefix/Parameter Discovery o Address Autoconfiguration - "Blackhole" detection / Fall back o Router Unreachability Detection o NUD Configuration "scopes": - Per link-type: all nodes must implement for communication to occur o Address resolution o ICMPv6 Redirects - Per link: Usefulness depends on cooperation of all nodes on link: o Duplicate address detection - Per link: Usefulness depends on cooperation of all routers on link: o Router discovery o Prefix/Parameter discovery - Per host/per-interface: can be useful without cooperation of all hosts on link: o Address Autoconfiguration o Router/Neighbor Unreachability detection Suggested specification changes - Make distinction between 8 mechanisms - Assign configuration scope, recommendations and defaults - Describe for separate implementations Suggested specification split: - Put minimal required mechanisms, related messages and descriptions into separate document o Address resolution o DAD o ICMPv6 Redirects Discussion. Suggestion was made that this document can define what is appropriate for each link types and what can be turned off. It would be an applicability document for ND and Autoconfiguration. ------------------------------ IPv6 over PVC ATM / S. Deering ------------------------------ Two competing specs for how to run IPv6 over ATM in a PVC Mode: IPv6 over PVC ATM draft and ION NBMA draft. In previous meetings the approach discussed was that there would be a separate document that defined this mode independently from full NBMA draft. Deadline proposed. Chairs believe deadline was end of January 1998 and that deadline has passed. ION document were published prior to March 1998 meeting. In ION documents IPv6overPVC-ATM is not in one place but spread over multiple sections in two documents. Some differences in two approaches: MTU, generation of link-local addresses, others? Deering's personal opinion is that it should not be spread over two documents. Would prefer PVC case to be in a single document. Postponed further discussion till after the ION status report, next. --------------------------------------------------- IPv6 over NBMA & IPv6 over ATM Status / P. Schulter --------------------------------------------------- ION meet today and discussed this issue. Grenville Armitage (Lucent) Peter Schulter (Bright Tiger Technologies) Markus Jork, Geraldine Harter (Digital) The General Architecture - Assume general NBMA 'cloud' o Capable of pt-pt links (static or dynamic) o Capable of pt-mpt links (dynamic, real or emulated) o May or may not have native 'multicast' - NBMA cloud could be o ATM o Frame Relay o IPv4 network o ... - MARS ? NHRP ? o Only used for SVC mode where native multicast is not supported, and dynamic shortcuts make sense Since last we met.... - Modified host triggered redirection behavior (replies are now Redirects) - Added new Shortcut Limit option for host triggered redirect (NS) message - General text cleanup Open Issues: - Assignment of a new ND option number (we picked the next available number) ACTION IPng Doc Editor: Get option assignment - What is it? o is a media-specific companion document to - Contains o Rules of generation of ND link tokens and link address fields o Codepoints for MARS and NHRP messages o Rules for LLC/SNAP encapsulation - Null encapsulation optional o Covers PVC and SVC cases separately - Clients do not need to implement SVC related extensions (eg. MARS) if only PVC support is required PVC rules - Standard LLC/SNAP encaps, with IPv6 PID o Null encapsulation allowed/negotiable - Default IP MTU of 9180 octets - All PVC rules now in section 3.1 (encapsulation, MTU, link token generation) SVC rules - Standard LLC/SNAP encaps with IPv6 PID o Different unicast and multicast formats as per RFC2022 o Null encapsulation discouraged, since it cannot be used between MARS and IPv6/NBMA client anyway --------------------------------------------------------- Continuation of IPv6 over PVC ATM Discussion / S. Deering --------------------------------------------------------- Three points: 1) Technical differences. "IPv6 over Point-to-Point ATM Link" spec is what has been implemented in WIDE implementation. 2) Should there be a stand alone document? 3) If we go with ION document, there should be proper acknowledgment of < authors. Asked for comments. Discussion. Many liked separate document. Suggested to use ION link-local rules. Another comment suggested that once technical issues resolved we should go with ION work. Suggestion that ION has been implemented as well. Discussion should have happened in ION. K. Yamamoto is willing to defer to ION, but wants it out quickly. Deering suggested that K. Yamamoto and ION authors get together and resolve differences. Would still like to have the PVC document be stand alone. Will go forward with ION document with closer coordination from K. Yamamoto. -------------------------------- Router Renumbering / M. Crawford -------------------------------- Status draft -03 - In w.g. last call - Outstanding issues o Stagger replies to multicast command o Limit multicast destination addresses to all routers only o Check for formation of unacceptable address (multicast, etc.) during execution - Open questions o enable matching conditions on length of prefix? Yes o Forbid formation of v4-compatible address? Yes o Discard custom authentication -IPSEC only? Yes, frees up field Spin-Off work - Define "Site" - Or agree not to Comment that given authentication this document does not need to define site. Security implicitly defines site. -------------------------------------------------- Multicast Listener Discovery Protocol / S. Deering -------------------------------------------------- New draft out . Equivalent of IPv4 IGMP for IPv6. Changes: - Using Link-local address for sourcing messages - Packet formats - Terminology Solicited comments. ------------------------- Scope Issues / S. Deering ------------------------- Discussion with diagrams. | | | | | | | | | +--------+ +--------+ +--------+ | | | | | | | Rtr | | Rtr | | Rtr | | | | | | | +--------+ +--------+ +--------+ | | | | | | | | | ============================================ Link Local: Drew scope boundary through the middle of Routers Site Local: Showed three alternatives. First site boundaries is in the middle of routers. Second boundary is in the middle of links. Third is interface based. Deering advocated the first alternative only. Assumption that sites are not overlapping. Overlapping sites are not currently supported. There is only one site-local prefix. Question about why we want site local. This was discussed at length on mailing list. Conclusion was to keep them. It would be more destructive to get rid of them, than to keep them and to define usage. Current objective is they are useful during renumbering. Site local addresses don't have to change. Comment that Erik Nordmark's draft is only defined usage of site-local. Think we can keep this usage without defining in detail. Deering wants to propose simple definition with guidance for implementors. If they don't get use, this will not be a problem. +--------+ +--------+ | | | | | Rtr 1 +--------------------+ Rtr 2 | | | | | +--------+ +--------+ ..site A.. | ..........site B........... | ......site C......... In this example there is a site boundary between each router. This results in three sites (left 1/2 of rtr 1, right 1/2 of rtr 1 through left 1/2 of Rtr 2, etc. Long discussion..... General consensus in the discussion to keep site local and agreement to make site boundaries in node (not link or interface). ACTION: S. Deering to write a draft ------------------------------------- IPv6 Plug and Play, Done? / R. Hinden ------------------------------------- Context - Plug and Play likely to be IPv6's Carrot - Makes IP Easy to Use! - Lowers Cost of Ownership for Enterprises and ISP's - Enables Network Appliances o Phones, PDAs, Games, household appliances, etc. Where Are We Now? - ND and AddrConf o Global Address Creation o Router Discovery o IP Parameters - DHCPv6 - Router Renumbering o Centralized reconfiguration of Router Advertisement Information - DNS o Automatic Creation of Reverse Map What Is Missing? - DNS o How to find DNS Server o How to register Node DNS name - Services o How to find Printers, File Servers, etc. o Enterprise and Home Office solution Solutions - Role of Service Location Protocol o Appropriate for General Service Location o Works with and without Servers o Not appropriate for DNS server location - DNS Server Location o Need Something New - DNS Name Registration o Status of Dynamic DNS Updating? DNS Server Location - Need to Learn o Server Address(s) o Default Domain o Domain Suffix Search list o Others? - Issues o Authentication o Lifetimes o Changing Approaches - Add Attribute to ND Router Advertisements o Requires adding this info to Routers o What if no Router? - DNS Server Advertisements? - Anycast Address for DNS Servers o Requires further communication w/ DNS server to get other related information - Multicast Address for DNS Servers o Use Expanding Ring (TTL) Search Next Steps - Discussion - Pick Approach Ohta: for DNS lookups, any DNS server will do; for registering/updating names, need specific server. Nordmark: what about coffee machines without keypads? Bound: don't dump on servers! Cheshire: svrloc allows literal addresses, so would work fine for DNS discovery. Deering: maybe spin off to a separate working group? Bound: to use anycast, need to allow hosts to have anycast addrs Durand: DNS service itself is complex, server-based; not exactly what dentists want? Additional discussion. General conclusion that topic should be pursued, but not clear if it should be in the IPng working group. ----------------------- DNS Status / S. Deering ----------------------- First item is where we are in DNS work. Major piece of core charter. Need to find current state and what should we do. What document should be moved forward, what not, what else needs to be done. Solicited opinion. Huitema: Did revision of draft based on previous decision. Submitted first release in January. New draft based on comments. Draft stable. Added tutorial part, comment to expand this and clarify. Reluctant to do any changes. Wants doc to go to w.g. last call. Has not received any major objections. Only wants to make changes based on w.g. comments. Waiting for results of reverse lookup. Publish as is or merge with new reverse lookup approach. Relationship w/ current RFC. Backwards compatible with current AAAA RFC. Conclusion (w/ no objections) is this will replace current AAAA RFC. RFC1886 will become obsoleted (historic). ACTION: Chairs do W.G. last call when new draft is out. ------------------------------- ICMP Name Lookups / M. Crawford ------------------------------- Status (-02) - In w.g. last call for experimental. - Could be rolled in with several other suggestions. Wants to hold off moving this forward until that is resolved. -------------------------- ICMP Node Info / A. Durand -------------------------- ICMP Node Info / Local extensions of ICMP "who are you" Motivation - Local address <=> "local name" mapping - Local address <=> global address mapping - local topology discovery - "local name" space discovery => local means "link local" or "site local" - Something very simple Two ICMP types, several codes, X: request, Y: reply X/0: "localname" request Y/0: "local name" reply X/1: incoming interface Y/1: incoming interface global address request global address reply X/2: all interfaces global Y/2: All interfaces global address request address reply Unicast Usage - X has only Y link local address and wants to discovery: o Y "local" name o Y global addresses Multicast Discovery - "Allowed" multicast destination addresses o All node link local o All router link local o All route site local - Source address of requests and replies packets MUST be local - Replies may be multicast to all node link local - anti-flooding mechanisms are needed Security Considerations - Do we open a can of worms? - Is IPSEC appropriate - if yes, is it necessary? Question: relationship between this and link local naming. Huitema: Should coffee pot use this or DNS? Answer this. Discussion. Generally thinks naming functions should be in DNS resolver and not in ICMP. M. Otha: Should this be used in sites? Not only link scope. These names should only be used with limited scope. This can be used to discover all of the names on the link. Deering: Thinks functionality should be in resolver, but that doesn't mean that this needs to be in DNS protocol. Matt: Could make small changes to "who are you" draft to allow more request types and replies. Kazu: Doesn't like this under ICMP. On Unix systems UDP would be better. Need root access to send/receive ICMP messages. ACTION: Chairs to figure out how to keep this work going. Might be in new w.g., somewhere else. Dimitry H: Need mechanisms to discover global address of router from link-local address. Doesn't think SNMP is appropriate. Could add ND option to router advertisement to advertise global address of router. Can we require routers to accept packets sent to prefix it is advertising with interface ID from link local address of router. Becomes an anycast address for router. Deering: links and subnets are not necessarily the same thing. Would like architecture to allow subnets to span multiple links. Discussion.... Nordmark: Wants to keep node in control of what addresses it uses. Doesn't want other nodes to decide. Also, is this also needed for hosts too? Bound: Thinks we should just have ND advertise all addresses of node. Nordmark: If so, would need to add lifetimes with each addresses. Lots of detail here. Otha: Thinks sites are collection of links. Discussion.... ----------------------------------------- Reverse DNS Lookup / M. Crawford ----------------------------------------- IPv6 DNS Lookups Goals and Semi-Goals - Delegate on arbitrary boundaries - Cacheable intermediate data - A single zone can be used under multiple higher-level prefixes. - Zone needs no modification if net is renumbered - Coexists with existing ipv6.int - Forward and reverse can be in sme zone file. New DNS Tools - Binary Labels o Compact representation of bit-string with semantics of a sequence of 1-bit domain labels: \[x200100/24].ip6.int. o Longest-match fallback when nameor datanot found - Non-terminal domain renaming (DNAME) o Maps a suffix set of labels to a different suffix: c.d.d.f. DNAME y.z causes a query for a.b.c.d.e.f. to go to a.b.y.z Proposed Structure - Higher-level registries of ISPs delegate address space to a domain chosen by the lower-level entity. - The delegated prefix disappears in the mapping o Hence, lower-level domain can be used with multiple prefixes - The delegating DNAME record can be cached [ Slide w/ examples] Pesky Details - How to look up site-local addresses? o Resolvers know to use only same-site DNS server? o Top level delegates \[xFEC0/10] to special name with site-local addresses? - Like Questions: Has this been reviewed by DNS w.g.? Met yesterday, feeling is that it should be done. Some technical details to work out, but should be done quickly. Expect to be done by next IETF meeting (August 98). Huitema: Thinks this is compatible with new DNS draft. Has talked to Matt C. about it. Good to have all of this together. Good thinking, very complementary. All data in one place. Only practical question is of timing. Relationship between DNAME and Binary Lables? Could this be blocked for a long time? Matt did not think this would happen. KRE: DNS group has a good track record to get work out. Should be ready for IESG by next IETF. Conclusion is to merge the two drafts. ---------------------------------------- IPv6 Host Naming Translations / J. Paugh ---------------------------------------- Solaris NIS/NIS+ Naming Services Goal is to not break IPv4 applications IPv4 & IPv6 Addresses Stored Separately - NIS map, NIS+ table and /etc file created for IPv6 addresses - Prevents existing IPv4 applications from unexpectedly receiving IPv6 addresses - Separate IPv6 database can be served by older slave/ replica Server Side Changes - New IPv6 host database created o hosts6.byname/hosts6.byaddr maps for NIS o hosts6.org_dir table for NIS+ o "AAAA" record for DNS o /etc/inet/hosts6 file for local file o Updated utilities to create hosts6 database (ypmake(1M), nisaddent(1M), nispopulate(1M), etc) [ Figure showing getXbyY() Application ] ------------------------------------------ Address Allocation Status Report / R. Hinden ------------------------------------------ Address Allocation Status Report / R. Hinden Met with registries and IANA. General conclusion is continue with approach described on Monday. New change is approach to initially assign sub TLA to transit providers who request allocation. When this is 90% used, they can then ask for a full TLA. This will be assigned with the understanding that they will have to give back the sub-TLA after a transition period. This should keep the top level routing in the order of the number of transit providers. Will work with registries and IANA to revise the draft. Expect to publish it in early May. Dimitry: Make sure policy doc does not rule out allocation of TLAs to exchanges. Carpenter: this doc will not be an IESG-approved doc; will be published as Informational RFC. ----------------------- IANA Status / R. Hinden ----------------------- Met with Jon Postel. Will collect and sanitize current code point request and send to IANA. Future request sent to IANA will be reviewed by IPng document editor. R. Hinden will serve as IANA technical reviewer for v6 numbers; asked for all spec authors to email him their code-point requirements and corresponding document citations. ------------------------- Meeting adjourned ------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 28 09:14:30 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id JAA03249 for ipng-dist; Tue, 28 Apr 1998 09:09:54 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id JAA03242 for ; Tue, 28 Apr 1998 09:09:41 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA12184; Tue, 28 Apr 1998 09:09:38 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id JAA16168; Tue, 28 Apr 1998 09:09:38 -0700 (PDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id JAA25062; Tue, 28 Apr 1998 09:09:34 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.6.9) id JAA21202; Tue, 28 Apr 1998 09:09:33 -0700 (PDT) From: Vivek Kashyap Message-Id: <199804281609.JAA21202@eng4.sequent.com> Subject: (IPng 5738) Re: ND use of link-locals [WAS: Re: Source Address Selection Issue and Scoping] To: narten@raleigh.ibm.com (Thomas Narten) Date: Tue, 28 Apr 1998 09:09:32 -0700 (PDT) Cc: roque@cisco.com, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-Reply-To: <199803121239.HAA05828@hygro.raleigh.ibm.com> from "Thomas Narten" at Mar 12, 98 07:39:00 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the late response on this. I had not been following this thread and came across it now while reading the archives (last month's). > The argument that won the day on prefix redirects (this is the DC > interim meeting I believe) was that one can construct scenarios that > make *either* type of redirect (per-host or prefix based) look > better. That is, there are scenarios where the use of prefix redirects > results in *more* redirects than the per-host redirects we have > today. It all depends on what your assuptions are. > > Also, the argument that prefix redirects allow you to reduce cache > state (i.e., maintain it per-prefix rather than per-host) is somewhat > suspect because there are lots of compelling arguments for maintaining > per-host state anyway (i.e., PMTU information, RTTs, etc.). That is, > having per-prefix state doesn't allow one to do away with the > per-destination host state. For PMTU per-host cache is not needed. Path MTU is determined at a router wrt to a particular net. If the net prefix length is returned to the end host it does not have to re-determine this bottleneck for another host on the same net. Instead of creating a per host route entry, using the destination address and the prefix length a net entry can be created. The connections will still pick up the right PMTU from the net route entry. Currently if a host gets 1000s of queries, it is likely to end up with a few hundred (or 1000) of routes (if there is an MTU bottleneck somewhere along the way). However it may actually have used only a handful of net-routes. Keeping per-prefix PMTU information (net-routes) reduces the routing table size and makes it more manageable. There is less load on the resources, more sharing, less to process or sort through for netstat/routing protocols and the administrators. Vivek > > Thomas > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 28 12:57:47 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id MAA03582 for ipng-dist; Tue, 28 Apr 1998 12:51:15 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id MAA03574 for ; Tue, 28 Apr 1998 12:51:04 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA17159 for ; Tue, 28 Apr 1998 12:50:58 -0700 Received: from blaze-net.com (barry.blaze-net.com [199.103.238.10]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA29184 for ; Tue, 28 Apr 1998 12:50:55 -0700 (PDT) Received: from blaze-net.com by blaze-net.com (SMI-8.6/SMI-SVR4) id PAA06569; Tue, 28 Apr 1998 15:54:53 -0400 Message-ID: <35463319.B808839@blaze-net.com> Date: Tue, 28 Apr 1998 15:50:49 -0400 From: Frank Solensky Organization: BlazeNet Inc X-Mailer: Mozilla 4.04 [en] (X11; U; SunOS 5.5.1 i86pc) MIME-Version: 1.0 To: Steve Deering CC: ipng@sunroof.eng.sun.com, Ofer Weill Subject: (IPng 5739) Re: NLPID for IPv6? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > > I have a vague memory of a NLPID being assigned to IPv6. Does anyone else > here know if that's true and, if so, what the NLPID value is? A link to the expired draft-conta-ipv6-trans-fr-00.txt includes: = The IPv6 does not have an NLPID defined at this time, therefore at = this point only the SNAP encapsulation is used. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 28 23:01:07 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id WAA04342 for ipng-dist; Tue, 28 Apr 1998 22:56:52 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id WAA04334 for ; Tue, 28 Apr 1998 22:56:33 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id WAA26676; Tue, 28 Apr 1998 22:56:31 -0700 (PDT) Date: Tue, 28 Apr 1998 22:13:51 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5741) Re: ND use of link-locals [WAS: Re: Source Address Selection Issue and Scoping] To: Vivek Kashyap Cc: Thomas Narten , roque@cisco.com, Erik.Nordmark@Eng, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199804281609.JAA21202@eng4.sequent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For PMTU per-host cache is not needed. Path MTU is determined > at a router wrt to a particular net. If the net prefix length is > returned to the end host it does not have to re-determine this > bottleneck for another host on the same net. Instead of creating a per > host route entry, using the destination address and the prefix length > a net entry can be created. The connections will still pick up the > right PMTU from the net route entry. What is a "net" and how can a host (like the one in my office) determine what a the prefix forms a "net" when the "net" is 17 hops away? Even if you would say that any /64 prefix could be considered a "net" you would have to handle mobile IPv6 where a mobile host will have a home address in one of your "net"s but will be located at the other end of a tunnel (from home agent to care-of-address). The path MTU of the tunnel is unrelated to the path MTU reaching the home "net". > Currently if a host gets 1000s of queries, it is likely to end > up with a few hundred (or 1000) of routes (if there is an MTU > bottleneck somewhere along the way). However it may actually have used > only a handful of net-routes. Keeping per-prefix PMTU information > (net-routes) reduces the routing table size and makes it more > manageable. There is less load on the resources, more sharing, less to > process or sort through for netstat/routing protocols and the > administrators. By "currently" I assume you mean IPv4. Just because the host has a single route for e.g. 129.146.0.0/16 doesn't mean that the path MTU to all the destinations in that "net" is the same - in fact in many cases it is different. And for a host that just has a default route (which is rather common) you clearly can't associate the path MTU with the default route. Note that having a per-destination address PMTU cache (or destination cache as it is called in RFC 1933) doesn't expand the routing table. It is a separate cache which exists in many IPv4 implementations today. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Apr 28 23:01:08 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id WAA04341 for ipng-dist; Tue, 28 Apr 1998 22:56:47 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with ESMTP id WAA04326 for ; Tue, 28 Apr 1998 22:56:29 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id WAA26672; Tue, 28 Apr 1998 22:56:28 -0700 (PDT) Date: Tue, 28 Apr 1998 21:55:39 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 5740) Re: (c.harding 17696) sockaddr_in6 for the basic API To: Chris Harding Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, xnet@opengroup.org In-Reply-To: "Your message with ID" <3.0.3.32.19980422114544.007ba1d0@mailhome.rdg.opengroup.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1. I'd like to question the addition of a specific "sin6_reserved" field. > > Reserved fields are useful in protocol headers when you think you may > want to add something later because in that situation, if you DON'T > reserve the space, there's no way you will be able to get it when you > do need it. But this isn't the case for API's. The normal convention > (as several mails to ipng on this topic have mentioned) is to allow > implementations the freedom to put the fields in any order and to add > extra ones if they want to. Portable applications don't rely on field > order and don't use any implementation-specific fields. Implementors > can order the fields, add extra ones for padding, or add extra ones > for their own private use, to their hearts' content. This is good > because it allows implementors to do things to take advantage of > their particular architectural features without compromising > applications portability. > > Even if the structure given in the RFC is to be regarded as an example > definition rather than a standard, I suggest that it would be better > to omit an explicit sin6_reserved field and maybe add some words > saying that implementors will probably add padding fields to ensure > that the structure is appropriately aligned in memory. Yes, we could do that. But in order to allow implementations to add new fields without potentially breaking applications we must then mandate that all (portable) applications that declare storage for a variable of type sockaddr_in6 (or use malloc to allocate storage) must explicitly clear the whole structure using e.g. bzero((char *)&sin6, sizeof (sin6)); Otherwise portable applications will pass uninitialized values to the implementation in any implementation specified fields. This is fine if it is only padding. But it doesn't work if an implementation wants to use new fields to e.g. carry additional information between getaddrinfo() and connect/sendto. Thus either we have a sin6_reserved with a statement that applications must set this field to zero (and ignore it when addresses are received from the implementation) or we add the above "bzero" requirement. > 2. What is the relation between the sin6_index and interface indexes? I think what we want to say if that when sin6_addr is a link-local address (includes link scope multicast addresses) the sin6_index is an interface index. I'd suggest we leave other use (e.g. "site index" for site-local addresses) open by not mentioning this in the specification. > Alternatively, if we have sin6_index (which seems to be the consensus > of the discussion so far), do we also need IPV6_MULTICAST_IF and the > interface index fields in the mreq structures used for > IPV6_ADD_MEMBERSHIP and IPV6_DROP_MEMBERSHIP? The multicast socket options are different in that they always need an interface index (could be zero to let the stack choose) independent of the scope of the address. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 29 09:05:31 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id IAA04802 for ipng-dist; Wed, 29 Apr 1998 08:56:20 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id IAA04795 for ; Wed, 29 Apr 1998 08:56:08 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA08933; Wed, 29 Apr 1998 08:56:06 -0700 Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA10125; Wed, 29 Apr 1998 08:56:06 -0700 (PDT) Received: from eng4.sequent.com (eng4.sequent.com [138.95.7.64]) by gateway.sequent.com (8.8.5/8.8.5) with ESMTP id IAA21026; Wed, 29 Apr 1998 08:56:04 -0700 (PDT) Received: (from viv@localhost) by eng4.sequent.com (8.8.5/8.6.9) id IAA23945; Wed, 29 Apr 1998 08:55:59 -0700 (PDT) From: Vivek Kashyap Message-Id: <199804291555.IAA23945@eng4.sequent.com> Subject: (IPng 5742) Re: ND use of link-locals [WAS: Re: Source Address Selection Issue and Scoping] To: Erik.Nordmark@Eng Date: Wed, 29 Apr 1998 08:55:58 -0700 (PDT) Cc: viv@sequent.com, narten@raleigh.ibm.com, roque@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Erik Nordmark" at Apr 28, 98 10:13:51 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What is a "net" and how can a host (like the one in my office) determine > what a the prefix forms a "net" when the "net" is 17 hops away? By net I mean a network that will be reached using a certain prefix length of an address. I'll use prefix length henceforth. The packet from the office goes through a 17 hops; any of routers (their outgoing links) in the path could determine the Path MTU. H --- R1 --- R2 --- R3 ...... R15 --- R16 --- H2 M1 Let M1 be the path MTU determining MTU. R2 has a routing entry that tells it to route the packets destined for H2 through R3. The address of H2 is a /128 address. R2 has an entry for /64 (say). If the length /64 is returned to H, it can build a route entry based on : A:B:C:D:E:F:G:H 'AND' A:B:C:D/64 gives me a route entry of the form A:B:C:D in host H. If the host was using the default route (or a more general route) then it now has a separate entry for destinations that would fall under the prefix A:B:C:D. This route entry will have the MTU stored as M1. Any connections using this route entry can now use M1 as the path MTU. By currently I mean the RFC1981 on Path MTU(I'll look into RFC 1933). As per the RFCs, I need to cache this information on a per host basis. So any host that happens to lie 'behind' the router from R2 will need a cached entry. With this modification all the cache I need is the route entry using the prefix A:B:C:D/64. I have addressed this in more detail in the draft: draft-kashyap-too-big-00.txt. I'll appreciate your comments on the draft wrt to this problem. > > Even if you would say that any /64 prefix could be considered a "net" > you would have to handle mobile IPv6 where a mobile host will have a home > address in one of your "net"s but will be located at the other end of > a tunnel (from home agent to care-of-address). The path MTU of the tunnel > is unrelated to the path MTU reaching the home "net". I am not sure of the exact problem here since it is the destination address and the intermediate routers and links that determine the path and the MTU. I'll go through mobile IP requirements, tunneling issues again and reply on this issue in a short while. > > > Currently if a host gets 1000s of queries, it is likely to end > > up with a few hundred (or 1000) of routes (if there is an MTU > > bottleneck somewhere along the way). However it may actually have used > > only a handful of net-routes. Keeping per-prefix PMTU information > > (net-routes) reduces the routing table size and makes it more > > manageable. There is less load on the resources, more sharing, less to > > process or sort through for netstat/routing protocols and the > > administrators. > > By "currently" I assume you mean IPv4. No IPv6, RFC 1981. (IPv4 is similar RFC 1191). > Just because the host has a single route for e.g. 129.146.0.0/16 doesn't > mean that the path MTU to all the destinations in that "net" is the same - > in fact in many cases it is different. Yes, it may be different in which case the router down the line will send a Datagram too big message with the prefix length it used. That prefix length can then be used to determine the new route entry in the host. > And for a host that just has a default route (which is rather common) > you clearly can't associate the path MTU with the default route. No, you cannot. A route entry will be derived from the default ie. use the gateway pointed to, interface etc. but will use the destination as the A:B:..../prefix_length. > > Note that having a per-destination address PMTU cache (or destination cache > as it is called in RFC 1933) doesn't expand the routing table. It is > a separate cache which exists in many IPv4 implementations today. I'll look into this RFC. What I propose doesn't require a separate cache at all. In IPv4 implementations I have seen FreeBSD and others who have taken the same code drop. They keep per host route entries. Vivek > > Erik > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Vivek Kashyap viv@sequent.com 503 578 3422 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Apr 29 10:30:20 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id KAA05039 for ipng-dist; Wed, 29 Apr 1998 10:22:39 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id KAA05032 for ; Wed, 29 Apr 1998 10:22:24 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA05017 for ; Wed, 29 Apr 1998 10:22:21 -0700 Received: from gecko.nas.nasa.gov (gecko.nas.nasa.gov [129.99.34.45]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id KAA02173 for ; Wed, 29 Apr 1998 10:22:23 -0700 (PDT) Received: from gecko.nas.nasa.gov (kml@localhost) by gecko.nas.nasa.gov (8.8.7/NAS8.8.7) with ESMTP id KAA26376; Wed, 29 Apr 1998 10:22:20 -0700 (PDT) Message-Id: <199804291722.KAA26376@gecko.nas.nasa.gov> To: Vivek Kashyap cc: ipng@sunroof.eng.sun.com Subject: (IPng 5743) problems with your path MTU discovery scheme In-reply-to: Your message of "Wed, 29 Apr 1998 08:55:58 PDT." <199804291555.IAA23945@eng4.sequent.com> Date: Wed, 29 Apr 1998 10:22:20 -0700 From: "Kevin M. Lahey" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199804291555.IAA23945@eng4.sequent.com>Vivek Kashyap writes >> What is a "net" and how can a host (like the one in my office) determine >> what a the prefix forms a "net" when the "net" is 17 hops away? > >By net I mean a network that will be reached using a certain prefix >length of an address. I'll use prefix length henceforth. The packet >from the office goes through a 17 hops; any of routers (their outgoing >links) in the path could determine the Path MTU. > > H --- R1 --- R2 --- R3 ...... R15 --- R16 --- H2 > M1 > >Let M1 be the path MTU determining MTU. R2 has a routing entry that >tells it to route the packets destined for H2 through R3. The address >of H2 is a /128 address. R2 has an entry for /64 (say). If the length >/64 is returned to H, it can build a route entry based on : > >A:B:C:D:E:F:G:H 'AND' A:B:C:D/64 gives me a route entry of the form >A:B:C:D in host H. If the host was using the default route (or a more >general route) then it now has a separate entry for destinations that >would fall under the prefix A:B:C:D. This route entry will have the >MTU stored as M1. Any connections using this route entry can now use >M1 as the path MTU. But what if R1 has a route to A:B:C:D::H3 with MTU M2? Your net-wide MTU table will instruct the host will always use the MTU M1 to get to H3. What if M1 is the minimum MTU, 1280, and M2 is ~64K? Because you'll always send packets of size M1, you'll never trigger MTU discovery for H3! Kevin kml@nas.nasa.gov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 30 08:18:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id IAA00486 for ipng-dist; Thu, 30 Apr 1998 08:13:18 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id IAA00479 for ; Thu, 30 Apr 1998 08:12:37 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA01907 for ; Thu, 30 Apr 1998 08:12:38 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA13143 for ; Thu, 30 Apr 1998 08:12:38 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id LAA39752; Thu, 30 Apr 1998 11:12:09 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA30238; Thu, 30 Apr 1998 11:12:10 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id LAA20002; Thu, 30 Apr 1998 11:12:27 -0400 (EDT) Message-Id: <199804301512.LAA20002@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: "Theodore Y. Ts'o" cc: jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5744) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-reply-to: Your message of "Thu, 30 Apr 1998 01:17:32 EDT." <199804300517.BAA20034@dcl.MIT.EDU> Date: Thu, 30 Apr 1998 11:12:27 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ted, [Sorry for the cross posting, but this is really both an IPSec and IPv6 issue.] Let me back up a little and clarify the point that caught my attention. draft-ietf-ipsec-auth-header-05.txt says: >>> As a new extension header or IPv4 option is created, it will be >>> defined in its own RFC and SHOULD include (in the Security >>> Considerations section) directions for how it should be handled when >>> calculating the AH ICV. If the IPsec implementation encounters an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> extension header that it does not recognize, it MUST zero the whole ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> header except for the Next Header and Hdr Ext Len fields. The length >>> of the extension header MUST be computed by 8 * Hdr Ext Len value + >>> 8. If the IPsec implementation encounters an IPv4 option that it >>> does not recognize, it should zero the whole option, using the second >>> byte of the option as the length. (IPv6 options contain a flag >>> indicating mutability, which determines appropriate processing for >>> such options.) There would seem to be an potential interoperability issue here. If what the AH actually covers is determined by what the sending IPSec module understands, how does the receiver obtain that knowledge? The receiver needs to know which headers are covered in order to validate the received AH. First, let us assume that we are talking about an extension header that precedes AH or ESP. Headers that appear afterwards are considered data to the AH/ESP, so nothing special needs to be done for them. If the sender "recognizes" the option, but the receiver does not, presumably there is no issue. The receiver will not know what to do with the header and toss the packet. It doesn't really make sense for a receiver to skip/ignore an extension header it does not understand. This check will take place before IPSec processing takes place. If the sender doesn't "recognize" the option, but the receiver does, here is where the issue comes up. The receiver needs an unambiguous way of knowing whether a particular extension header (that precedes AH) is covered by the AH check. I was assuming that it wouldn't make sense for a node to be sending extension headers it *does* understand that the IPSec module *did not*. I.e., if the extension header is mutable, but its contents are predictable at the reciever, the sending IPSec module should always be able to include it in the AH computation. Couple of perspectives: 1) As you point out, on some systems IPSec may not be upgraded or otherwise stay in sync with new extension headers. I'm not sure I agree with this (or rather, I'm not sure we should explicitely encourage this), but even if it is so, it leads to the interoperability issue described above. The receiver is left guessing which extension headers are actually covered. This would seem to be a bug. 2) One might argue that there will be no need to define future extension headers that a) precede the IPSec header, b) are mutable, but in a predictable way, c) zeroing out (i.e., not including) the extension header in the AH check results in undesired behavior and d) the header needs to be defined as extension headers as opposed to a destination option (which wouldn't have this problem thanks to an explicit bit). However, we should recognize that this approach potentially limits future flexibility, something that should not be done without careful thought. 3) It's not immediately clear to me how one could signal to the receiver in a generic way whether or not an extension header is covered by the AH check. This suggests a couple of approaches: - require that IPSec and future extension headers be upgraded in sync on sending/receiving machines, so that the extension header itself can define the right semantics regarding AH coverage. Note that this may not be as onerous as first appears, since it only applies to new extension headers that *precede* AH. - declare that all extension headers (except the IPv6 headers that are already defined) - including future ones that have yet to be defined - should be zeroed and ignored for the purposes of AH. (That is, take out the text that allows the sender to choose, based on what it understands) - leave the text as is, but at least document the interoperability implications. - are there other possibilities? > Karen and Charlie point out that if the IPV6 draft were changed > so that the meaning of that bit means "mutable or receiver can predict", I think you mean (thanks Matt): "mutable and sender can not predict" > then it would be possible to include such options in the Integrity Check > Value (ICV). That is what I *thought* the bit was supposed to mean. However, the current text doesn't say that, so I'm awaiting clarification from the IPng WG. > However, I note that if we do this, and later someone > defines a new mutable-but-predictable option, IPSEC implementations > which don't know about the new option won't know how to predict option > value, and thus will not be able to properly calculate the ICV. Agreed. But I think there is already an interoperability issue here. > It is therefore simpler to say that all mutable options are not > covered by the ICV, which is the current position of the IPV6 and IPSEC > documents. The tradeoff then is that existing mutable-but-predictable > options will not be integrity-protected. If we would like to change > this, we would need to tweak both documents. However, the introduction > of a new mutable-but-predictable option will cause interoperability > problems with older security gateways, so it's not clear that we will be > able to introduce new mutable-but-predictable options in the future in a > practical fashion anyway. Isn't there a similar issue here in that it may not make sense for the security gateway to understand how to process the option yet *not* understand how to do the integrity check on that option? > Given this, do you have a strong opinion regarding change both > drafts, or leaving them as they currently stand? My recommendation > would be to leave them as they currently stand, on the grounds of > simplifying the implementations. I'd like to hear from the IPng folks regarding the mutable but predictable issue (but that is a separate issue). I'm also uncomfortable with leaving the AH text as is without better addressing the interoperability issue. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 30 08:18:00 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id IAA00495 for ipng-dist; Thu, 30 Apr 1998 08:14:16 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id IAA00488 for ; Thu, 30 Apr 1998 08:14:06 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA02149 for ; Thu, 30 Apr 1998 08:14:06 -0700 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by earth.sun.com (8.8.8/8.8.8) with ESMTP id IAA13826 for ; Thu, 30 Apr 1998 08:14:06 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id LAA30500 for ; Thu, 30 Apr 1998 11:13:39 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA35498 for ; Thu, 30 Apr 1998 11:13:41 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id LAA19696 for ; Thu, 30 Apr 1998 11:14:04 -0400 (EDT) Message-Id: <199804301514.LAA19696@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 5745) FWD: [Karen Seo: Thomas Narten -- clarification, etc.] Date: Thu, 30 Apr 1998 11:14:04 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI. Rather than following up to this note (which is only going to the ipng list), see my response (which was sent to both ipng and ipsec). Thomas ------- Forwarded Message From: "Theodore Y. Ts'o" To: Thomas Narten , jis@MIT.EDU Cc: ipsec@tis.com Date: Thu, 30 Apr 1998 01:17:32 -0400 Subject: [Karen Seo: Thomas Narten -- clarification, etc.] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Hi Thomas, I spent quite a bit of time discussing the issue which you raised (forwarded to me by Jeff) with Karen Seo and Charlie Lynn. They believe that IPSEC architecture draft as it currently stands is consistent with the current IPV6 drafts. As it currently stands, because of how the IPV6 documents are written, the bit in the option defines whether or not the option contents is mutable, regardless of whether not the receive can predict it. As a result, the IPSEC implementation must zero all IPV6 options with the mutable bit set, regardless of whether or not the receiver can predict it. This was done so that we would be consistent with the current IPV6 specifications. Karen and Charlie point out that if the IPV6 draft were changed so that the meaning of that bit means "mutable or receiver can predict", then it would be possible to include such options in the Integrity Check Value (ICV). However, I note that if we do this, and later someone defines a new mutable-but-predictable option, IPSEC implementations which don't know about the new option won't know how to predict option value, and thus will not be able to properly calculate the ICV. It is therefore simpler to say that all mutable options are not covered by the ICV, which is the current position of the IPV6 and IPSEC documents. The tradeoff then is that existing mutable-but-predictable options will not be integrity-protected. If we would like to change this, we would need to tweak both documents. However, the introduction of a new mutable-but-predictable option will cause interoperability problems with older security gateways, so it's not clear that we will be able to introduce new mutable-but-predictable options in the future in a practical fashion anyway. Given this, do you have a strong opinion regarding change both drafts, or leaving them as they currently stand? My recommendation would be to leave them as they currently stand, on the grounds of simplifying the implementations. - Ted ------- Forwarded Message Date: Tue, 28 Apr 98 20:36:53 EDT From: Karen Seo To: tytso@MIT.EDU Cc: skent@BBN.COM, clynn@BBN.COM, kseo@BBN.COM Subject: Thomas Narten -- clarification, etc. Hi Ted, My apologies for not getting back to you yesterday. Per our conversation earlier today, here's our interpretation and comments on Thomas's message. Thanks again for your hard work and help with these documents. Please let us know if you have further questions, Karen >>Date: Fri, 24 Apr 1998 11:02:17 -0400 >>From: Thomas Narten >> >>Bob, Steve: >> >>In reviewing draft-ietf-ipsec-auth-header-05.txt, I noticed the >>following wording: >> >>> As a new extension header or IPv4 option is created, it will be >>> defined in its own RFC and SHOULD include (in the Security >>> Considerations section) directions for how it should be handled when >>> calculating the AH ICV. If the IPsec implementation encounters an >>> extension header that it does not recognize, it MUST zero the whole >>> header except for the Next Header and Hdr Ext Len fields. The length >>> of the extension header MUST be computed by 8 * Hdr Ext Len value + >>> 8. If the IPsec implementation encounters an IPv4 option that it >>> does not recognize, it should zero the whole option, using the second >>> byte of the option as the length. (IPv6 options contain a flag >>> indicating mutability, which determines appropriate processing for >>> such options.) >> >>Text regarding processing of unrecognized extension options seems >>wrong (there are bits in header saying whether field is mutable). Do >>you agree? As background... A. There are 3 cases of new IP extension headers and options: 1. new IPv4 options 2. new IPv6 extension headers (e.g., Routing (Type 0), Fragmentation, etc.) 3. new options in existing IPv6 extension headers, i.e., Hop-by-Hop, and Destination B. For case (3), a variable number of options are carried in the extension header with individual option headers which have a bit which indicates mutability/immutability (the Option Data field mentioned later in Thomas's message.) * We're not sure what Thomas is saying with regard to "unrecognized extension options". The bit for mutability/immutability is in the individual Option Header(s) not the Extension Header. Perhaps he's confusing Options with Extension Headers. C. An extension header has its own IP protocol number (e.g., AH = 51, ESP = 50) and fields like Next Header, etc. Although most folks think of them as strictly an IPv6 concept, they can in principle be used with IPv4 or IPv6. The first sentence is addressing cases 1 and 2 -- we didn't specify the "new extension header" as being "IPv6" because of point C above. The parenthetical statement at the end is addressing case 3. There isn't anything wrong with the text. We could add various clarifications if it would help. >>>>Also, in looking at the current IPv6 base document, it says on this >>>>point: >>>> >>> The third-highest-order bit of the Option Type specifies whether or >>> not the Option Data of that option can change en-route to the >>> packet's final destination. When an Authentication header is present >>> in the packet, for any option whose data may change en-route, its >>> entire Option Data field must be treated as zero-valued octets when >>> computing or verifying the packet's authenticating value. >>> >>> 0 - Option Data does not change en-route >>> >>> 1 - Option Data may change en-route >>> >>> The three high-order bits described above are to be treated as part >>> of the Option Type, not independent of the Option Type. That is, a >>> particular option is identified by a full 8-bit Option Type, not just >>> the low-order 5 bits of an Option Type. >> >>Is the above text correct? In particular, the text says "mutable" >>rather than "has predictable value at receiver". >> >>Do either or both of these drafts need tweaking? Thomas is correct in pointing out that there are really 3 cases: 1. Immutable -- Option Data does not change en-route 2. Mutable and predictable -- Option Data changes en-route; sender can predict its value at the receiver. 3. Mutable and unpredictable -- Option Data changes en-route; sender cannot predict its value at the receiver. At present, if the Option Data is "mutable", there is no way to tell whether the data is predictable or unpredictable. Hence the IPsec AH spec says that if the data is "mutable", the option data must be zero'd. If the IPv6 text above is changed to something like the following: 0 - Option Data does not change en-route or changes such that the sender can predict the value at the receiver 1 - Option Data may change en-route then case (2) is covered. And one would not need to change the IPsec AH text, but could highlight this if one wanted to by changing the paragraph in IPsec AH quoted by Thomas from: (IPv6 options contain a flag indicating mutability, which determines appropriate processing for such options.) to: (IPv6 options contain a flag indicating "immutable or mutable-predictable" vs "mutable-unpredictable", which determines appropriate processing for such options.) By the way, following up on your/Charlie's conversation re: what happens if sender understands a new extension header but the receiver does not recognize it.... Charlie says that this may not be a big problem because it will only apply if the new extension header is placed in front of the AH header. If it comes after the AH header, it will have been included verbatim in the ICV and not processed prior to the AH header being processed. ------- End Forwarded Message ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 30 12:26:49 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id MAA00692 for ipng-dist; Thu, 30 Apr 1998 12:20:25 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id MAA00685 for ; Thu, 30 Apr 1998 12:20:13 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA18661 for ; Thu, 30 Apr 1998 12:20:12 -0700 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA13870 for ; Thu, 30 Apr 1998 12:20:14 -0700 (PDT) Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA05125; Thu, 30 Apr 98 15:19:55 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id PAA20352; Thu, 30 Apr 1998 15:19:53 -0400 Date: Thu, 30 Apr 1998 15:19:53 -0400 Message-Id: <199804301919.PAA20352@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: Thomas Narten Cc: "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com In-Reply-To: Thomas Narten's message of Thu, 30 Apr 1998 11:12:27 -0400, <199804301512.LAA20002@cichlid.raleigh.ibm.com> Subject: (IPng 5746) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A number of folks have pointed out that I wrongly said "receiver can predict", when it should have been "sender can predict". They are of course right. My apologies for the error, which invalidates some of my comments regarding the interoperability issues of changing the sense of the IPv6 "mutable" bit. It seems to me now that making this change is certainly doable, should we have consensus that this would be a good thing to do for IPv6 options. With regards to your observations regarding new IPv6 extension headers: >1) As you point out, on some systems IPSec may not be upgraded or >otherwise stay in sync with new extension headers. I'm not sure I >agree with this (or rather, I'm not sure we should explicitely >encourage this), but even if it is so, it leads to the >interoperability issue described above. The receiver is left guessing >which extension headers are actually covered. This would seem to be a >bug. There is the added complications that the IPSEC processing may be happening on a security gateway which is separate from the end-system which is actually generating the newly defined extension header. The security gateway may be a turnkey "black box" provided by some VPN vendor. So we can't necessarily guarantee IPSEC implementation will be upgraded. >2) One might argue that there will be no need to define future >extension headers that a) precede the IPSec header, b) are mutable, >but in a predictable way, c) zeroing out (i.e., not including) the >extension header in the AH check results in undesired behavior and d) >the header needs to be defined as extension headers as opposed to a >destination option (which wouldn't have this problem thanks to an >explicit bit). However, we should recognize that this approach >potentially limits future flexibility, something that should not be >done without careful thought. I see three primary choices: (1) is to declare that any new extension headers that preceed the IPsec MUST not be included in the ICV (i.e., are zero'ed out), regardless of their mutability status. (2) would be to always included new extension headers in the ICV --- with the net result that new extension header would not be allowed to mutate. Finally (3) we could live with the potential interoperability problem that will occur when we define such a new extension header and it passes through an IPSEC gateway that doesn't understand the new extension. There are two subcases in this last case, (a) the IPSEC gateway simply refuses to process the packet with the unknown extension header, or (b) the IPSEC gateway assumes a default behaviour of zero'ing out the unknown extension header when calculating the ICV. (2)(b) is the current draft wording, and has the property of working if the default behaviour is correct. If the default behaviour is not correct, and the sending IPSEC gateway generates the ICV with the extension header, it will cause the receiver to reject the packet because of a bad ICV value. The worst case behaviour happens if there are two security gateways involved, and both IPSEC gateways don't understand the extension header, and so zero it when the calculate the ICV. Now the ICV matches, and the packet goes through, but the extension is not protected. If the sending and receiving hosts understand the extension, they might assume that the extension has been integrity protected, when in fact it has not been. If the extension has security implications, this would be bad. None of these choices are particularly palatable. Just so I understand the IPV6 issues a little better --- how likely is it that we will want to invent new extension headers? And how likely is it that the ordering will matter and that the new extension header will have to be before the AH header, and could not be placed after the AH header? - Ted -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 30 12:32:37 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id MAA00719 for ipng-dist; Thu, 30 Apr 1998 12:30:01 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id MAA00711 for ; Thu, 30 Apr 1998 12:29:50 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA20812 for ; Thu, 30 Apr 1998 12:29:45 -0700 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by earth.sun.com (8.8.8/8.8.8) with SMTP id MAA19625 for ; Thu, 30 Apr 1998 12:29:44 -0700 (PDT) Received: from research.att.com ([135.207.30.100]) by rumor; Thu Apr 30 15:25:30 EDT 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Thu Apr 30 15:27:22 EDT 1998 Received: from postal.research.att.com (localhost [127.0.0.1]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id PAA17855; Thu, 30 Apr 1998 15:27:29 -0400 (EDT) Message-Id: <199804301927.PAA17855@postal.research.att.com> To: "Theodore Y. Ts'o" cc: Thomas Narten , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5747) Re: [Karen Seo: Thomas Narten -- clarification, etc.] Date: Thu, 30 Apr 1998 15:27:28 -0400 From: Steve Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk None of these choices are particularly palatable. Just so I understand the IPV6 issues a little better --- how likely is it that we will want to invent new extension headers? And how likely is it that the ordering will matter and that the new extension header will have to be before the AH header, and could not be placed after the AH header? Well, Vern Paxson and I are talking about a new header right now -- and it would have to be mutable. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Apr 30 14:53:06 1998 Received: by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) id OAA00856 for ipng-dist; Thu, 30 Apr 1998 14:49:10 -0700 (PDT) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.0.Beta7+Sun/8.9.0.Beta7) with SMTP id OAA00849 for ; Thu, 30 Apr 1998 14:49:01 -0700 (PDT) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA26647 for ; Thu, 30 Apr 1998 14:49:01 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by earth.sun.com (8.8.8/8.8.8) with SMTP id OAA14229 for ; Thu, 30 Apr 1998 14:48:51 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA32087; Fri, 1 May 1998 07:46:40 +1000 (from kre@munnari.OZ.AU) To: Thomas Narten Cc: "Theodore Y. Ts'o" , jis@MIT.EDU, ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 5748) Re: [Karen Seo: Thomas Narten -- clarification, etc.] In-Reply-To: Thomas Narten's message of "Thu, 30 Apr 1998 11:12:27 -0400." References: <199804301512.LAA20002@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 May 1998 07:46:34 +1000 Message-Id: <17976.893972794@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 30 Apr 1998 11:12:27 -0400 From: Thomas Narten Message-ID: <199804301512.LAA20002@cichlid.raleigh.ibm.com> I just want to pick a piece out of the quoted text... | Let me back up a little and clarify the point that caught my | attention. draft-ietf-ipsec-auth-header-05.txt says: | | >>> If the IPsec implementation encounters an | >>> extension header that it does not recognize, it MUST zero the whole | >>> header except for the Next Header and Hdr Ext Len fields. To me, that reads like nonsense. If the implementation doesn't recognise the header, what would be the basis upon which it would locate the Next Header or Hdr Ext len fields? Is there some (incorrect) implicit assumption here that all headers for all time will have such fields, and that they'll always be in the same place? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------