From owner-ipng Tue Oct 1 13:01:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18639; Tue, 1 Oct 96 13:01:34 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA18633; Tue, 1 Oct 96 13:01:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA12049; Tue, 1 Oct 1996 12:55:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA26714; Tue, 1 Oct 1996 12:55:10 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15374(6)>; Tue, 1 Oct 1996 12:54:48 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 1 Oct 1996 12:54:31 PDT To: I Putu Gede Widiana Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2151) Re: Interoperate In-Reply-To: putu's message of Sat, 28 Sep 96 09:32:09 -0800. <324D5309.1BCA@palu.wasantara.net.id> Date: Tue, 1 Oct 1996 12:54:31 PDT From: Steve Deering Message-Id: <96Oct1.125431pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If header translating router consider harmful, how does IPv6 only host > interoperate with IPv4 only host ? IPv6 <-> IPv4 translating routers are not necessarily considered harmful, but they raise some serious management and complexity issues as a general mechanism for IPv6 <-> IPv4 interoperability. Therefore, a simpler approach is being recommended for interoperability: when you upgrade a node to support IPv6, you do *not* delete the IPv4 module on that node. Thus, an upgraded node can continue to talk to IPv4-only nodes using IPv4, and to IPv6-capable nodes using IPv6. At some point, we hope the vast majority of nodes will become IPv6 capable (probably as a side-effect of normal OS upgrades), at which point you can start throwing away the old IPv4 code, except perhaps on a few machines that will act as application-level gateways to remaining "legacy" IPv4 devices, e.g., that old IPv4-based printer down the hall that will never be upgraded to IPv6. That's the "official" plan. I would not, however, be surprised to see the following as well: - new classes of Internet-capable devices (e.g., home appliances, sensors such as electric power meters, stereo components, etc.) that are not general purpose computers that require access to the existing base of IPv4 services, and for which IPv6-only would suffice. - IPv4 <-> IPv6 translating routers, if the market demands them. Although translating routers are not part of the current transition plan, we have tried not to do anything in the IPv6 design that would obviously preclude them. According to a message on this list some time ago, supposedly some company in Japan demoed such a translator at the most recent Tokyo Interop. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 05:04:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19326; Wed, 2 Oct 96 05:04:54 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19320; Wed, 2 Oct 96 05:04:38 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA24217; Wed, 2 Oct 1996 04:58:31 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA23737; Wed, 2 Oct 1996 04:58:31 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA02677 for ; Wed, 2 Oct 1996 13:58:30 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA03704; Wed, 2 Oct 1996 13:58:29 +0200 Message-Id: <9610021158.AA03704@dxcoms.cern.ch> Subject: (IPng 2152) suggestion (long) To: ipng@sunroof.eng.sun.com Date: Wed, 2 Oct 1996 13:58:29 +0200 (MET DST) From: "Brian Carpenter CERN-CN" 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 IPng folks, draft-iab-ip-ad-today-00.txt says that > .... Thus, IPv6 will amplify the existing > problem of finding stable identifiers to be used for end-to-end > security and for session bindings such as TCP state. > > The IAB feels that this is unfortunate, and that the transition to > IPv6 would be an ideal occasion (possibly the last ever) to provide > upper layer end-to-end protocols with temporally unique identifiers. > The exact nature of these identifiers requires further study. On the grounds that this is a dangling pointer, here is an idea to stimulate debate. Transport and security mechanisms require end point identifiers which are guaranteed not to change when dynamic renumbering takes place. Such identifiers may also be needed when the host concerned is a member of an anycast group, or when communication flows through a network address translator, or when the host's apparent IP address is liable to change for any other reason. Approaches to this issue have been suggested in draft-bound-ipv6-ip-addr-00.txt, draft-bound-anycast-00.txt, and draft-huitema-multi-homed-01.txt [expired]. The underlying issues are discussed in those drafts and are not repeated here. The present [fragment of a] draft proposes an intentionally simplistic solution. It is suggested that the simplest approach to this problem is to limit the problem to source identifiers, trusting the addressing and routing systems to deliver packets only to the correct destination. In this case, it is only necessary for sources to identify themselves invariantly. If one end of a communication is renumbered, rehomed or has its outgoing packets translated, an invariant source identifier is necessary and sufficient. An IPv6 destination option is proposed for this. An IPv6 implementation MUST support this option both as a a source (generating the option) and as a destination (interpreting the option). Furthermore, the implementation MUST provide an administrative mechanism for enabling or disabling the generation of this option, and for assigning an EID value to the host. [The format is defined below.] When the generation of this option is enabled in a particular host, it MUST include the option in every outgoing IPv6 packet, filled in with the host's assigned EID value. Furthermore its transport and security mechanisms SHALL use the assigned EID value (padded to 16 octets) as a unique identifier for all outgoing traffic. Hosts with the option disabled SHALL use the IPv6 source address in use for a particular communication as a unique identifier for that communication. [This implies that the EID must be available to the transport and security layers, and presumably in the UDP API.] If an ongoing transaction is rehomed, its new host MUST use the same EID and port number. [This limits rehoming to a smallish group of co-managed hosts, but that is presumably reasonable.] When this option is received by any IPv6 host, transport and security mechanisms SHALL use the EID value supplied (padded to 16 octets) as a unique identifier for the sender. When this option is absent, they SHALL use the source IPv6 address as a unique identifier for the sender. In either case they SHALL send return packets to the source IPv6 address, which may legitimately change in the presence of the EID option. The worst case is that during a change of address, a few packets are lost; this is acceptable behaviour in an IP network. Note that the use of anycast addresses is fully compatible with this approach, since anycast addresses are disallowed as source addresses in any case. If a client opens communication with a server via an anycast address, the server that actually responds will do so from a legitimate unicast source address, with or without supplying an EID. The EID destination option is illustrated below. It has no alignment requirement. Its length is chosen such that if it is the only destination option present, the entire destination options header will be 16 octets. The option type code is 11-0-TBD = TBD decimal. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 TBD |Opt Data Len=12| OUI-head (octets 0-1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI-head (octets 2-5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI-tail (octets 0-2) |LocalID octet 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ID octets 1-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the OUI-head is zero, the 6 octets constituting the OUI-tail and Local identifier MUST be a valid, globally unique IEEE MAC address. If the OUI-head is non-zero, then the OUI-head and OUI-tail are considered to form a 9 octet OUI (Organizationally Unique Identifier), uniquely identifying a network site. The format and allocation mechanism for OUIs SHALL be analogous to that for provider-based IPv6 addresses with or without a national registry, but with a ProviderID of length zero (compare [draft-ietf-ipngwg-unicast-addr-fmt-04.txt]). Thus the two OUI formats are: | 3 | 5 bits | 64 bits | +---+----------+--------------+ |010|RegistryID| SiteID | +---+----------+--------------+ | 3 | 5 bits | n bits | 64-n bits | +---+----------+----------+------------+ |010|RegistryID| National | Site | | | |RegistryID| ID | +---+----------+----------+------------+ with the details being decided at registry level. In this case each site MUST administratively allocate unique 3 octet Local identifiers. [The assumption is that in most cases, a pure IEEE address will suffice as an EID. The additional mechanism is provided to ensure that this assumption never becomes a showstopper. Maybe the OUI is longer than necessary?] [A format prefix is used, as in an IPv6 address, so that additional formats could be added later.] [An alternative would be to use a full-size IPv6 address, with a specific format-prefix for EIDs, but this loses the possible neat alignment.] Implementations MUST interpret the option data length field, i.e. MUST NOT assume that all EIDs are of length 12 octets, in case of future extensions. Implementations MAY optimise for the case of length 12. Implementations MUST NOT interpret the contents of an EID as having any significance except that of being a unique bit string. The EID formats are specified only to enable an allocation mechanism. (Thanks to Yakov Rekhter, Tony Li, Jim Bound and Thomas Narten for comments on this. The basic idea is not original, and goes back to at least 1994...) Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 06:40:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19354; Wed, 2 Oct 96 06:40:36 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19348; Wed, 2 Oct 96 06:40:23 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29445; Wed, 2 Oct 1996 06:34:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA12209; Wed, 2 Oct 1996 06:34:17 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id JAA09942; Wed, 2 Oct 1996 09:34:10 -0400 Date: Wed, 2 Oct 1996 09:34:10 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9610020934.ZM9940@seawind.bellcore.com> In-Reply-To: "Brian Carpenter CERN-CN" "(IPng 2152) suggestion (long)" (Oct 2, 1:58pm) References: <9610021158.AA03704@dxcoms.cern.ch> X-Mailer: Z-Mail (3.2.0 06sep94) To: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com Subject: (IPng 2153) Re: suggestion (long) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, You wrote that "Transport and security mechanisms require end point identifiers which are guaranteed not to change when dynamic renumbering takes place." I entirely agree with the existence of this requirement, but I tend to differ intensely with your proposed solution, to push this requirement to the network layer. A basic precept of the architecture, the end to end argument, tells us that we should not ask the network to perform any function that end to end protocols could perform just as well, or probably better. This is definitely the case of identification: * security protocols identify principals, not network interfaces. A security association, as defined by IPSec, is identified by a destination address + association identifier tuple, irrespective of the source address. The identification is "certified" by the usage of a key, secret to the parties in the communication. The key exchange procedures rely on high level identifiers, e.g., certificates, not on network addresses. * it is entirely true that TCP connections, today, rely on the address + port tuples. This is however not true of all associations, and in particular not true of most RPC based associations. TCP could be modified to negotiate connection identifiers independent of the source address. This is in fact already a requirement of TTCP. The modifications to TCP to accept such identifiers are no more complex than those required for using an EID option field instead of a source address. In short, I maintain a long standing opinion that EID are not necessary for any practical purpose. We may define an end to end option to carry this field, but its unproven nature should maintain it in an experimental status. Parallel efforts to make TCP connections independent of the address in use for a particular packet should also be carried. And don't forget the possibility to define a simple "your partner has been renumbered" ICMP. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 07:36:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19420; Wed, 2 Oct 96 07:36:03 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19414; Wed, 2 Oct 96 07:35:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04848; Wed, 2 Oct 1996 07:29:43 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA00653; Wed, 2 Oct 1996 07:29:41 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id QAA27052 for ; Wed, 2 Oct 1996 16:29:08 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA17398; Wed, 2 Oct 1996 16:29:06 +0200 Message-Id: <9610021429.AA17398@dxcoms.cern.ch> Subject: (IPng 2154) Re: suggestion (long) To: ipng@sunroof.eng.sun.com Date: Wed, 2 Oct 1996 16:29:06 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9610020934.ZM9940@seawind.bellcore.com> from "Christian Huitema" at Oct 2, 96 09:34:10 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > > A basic precept of the architecture, the end to end argument, tells us > that we should not ask the network to perform any function that end to end > protocols could perform just as well, or probably better. This is > definitely the case of identification: I think you'll find that in RFC 1958 :-). However, I'm not asking the network to do anything except transmit the option. > > * security protocols identify principals, not network interfaces. A > security association, as defined by IPSec, is identified by a > destination address + association identifier tuple, irrespective > of the source address. The identification is "certified" by the usage > of a key, secret to the parties in the communication. The key exchange > procedures rely on high level identifiers, e.g., certificates, not > on network addresses. Right, so it's broken if the destination address changes (i.e. the source address in the opposite direction). So there is a problem. > > * it is entirely true that TCP connections, today, rely on the > address + port tuples. This is however not true of all associations, > and in particular not true of most RPC based associations. TCP could > be modified to negotiate connection identifiers independent of the > source address. This is in fact already a requirement of TTCP. The > modifications to TCP to accept such identifiers are no more > complex than those required for using an EID option field instead > of a source address. Is there a draft on this new TCP? > > In short, I maintain a long standing opinion that EID are not necessary > for any practical purpose. We may define an end to end option to carry > this field, but its unproven nature should maintain it in an experimental > status. However, dynamic renumbering is a feature of IPv6. We have to have a solution to this problem, not an experiment. I can't see any way out of production IPv6 stacks needing to be shipped with a new TCP; the question is only what particular mechanism is used. > ...Parallel efforts to make TCP connections independent of the > address in use for a particular packet should also be carried. Yes, but not in this WG. > ...And don't > forget the possibility to define a simple "your partner has been > renumbered" ICMP. The issue with that is that if that ICMP message gets lost, how can we recover? Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 08:10:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19463; Wed, 2 Oct 96 08:10:36 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19457; Wed, 2 Oct 96 08:10:23 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA09548; Wed, 2 Oct 1996 08:04:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA13294; Wed, 2 Oct 1996 08:04:00 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id QAA00571; Wed, 2 Oct 1996 16:01:00 +0100 Date: Wed, 2 Oct 1996 16:01:00 +0100 Message-Id: <199610021501.QAA00571@oberon.di.fc.ul.pt> From: Pedro Roque To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2155) suggestion (long) In-Reply-To: <9610021158.AA03704@dxcoms.cern.ch> References: <9610021158.AA03704@dxcoms.cern.ch> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Brian" == Brian Carpenter CERN-CN writes: Brian> IPng folks, draft-iab-ip-ad-today-00.txt says that >> .... Thus, IPv6 will amplify the existing problem of finding >> stable identifiers to be used for end-to-end security and for >> session bindings such as TCP state. >> >> The IAB feels that this is unfortunate, and that the transition >> to IPv6 would be an ideal occasion (possibly the last ever) to >> provide upper layer end-to-end protocols with temporally unique >> identifiers. The exact nature of these identifiers requires >> further study. Brian> On the grounds that this is a dangling pointer, here is an Brian> idea to stimulate debate. Brian> Transport and security mechanisms require end point Brian> identifiers which are guaranteed not to change when dynamic Brian> renumbering takes place. Such identifiers may also be Brian> needed when the host concerned is a member of an anycast Brian> group, or when communication flows through a network Brian> address translator, or when the host's apparent IP address Brian> is liable to change for any other reason. Brian> Approaches to this issue have been suggested in Brian> draft-bound-ipv6-ip-addr-00.txt, Brian> draft-bound-anycast-00.txt, and Brian> draft-huitema-multi-homed-01.txt [expired]. The underlying Brian> issues are discussed in those drafts and are not repeated Brian> here. The present [fragment of a] draft proposes an Brian> intentionally simplistic solution. draft-bound-ipv6-ip-addr-00 takes a different aproach to this problem than the one suggested in your message. As co-author, I'll try to defend why we believe this aproach to be apropriate. The objective we pursue, and which is common to the several proposals you refer, is to allow for comunication between end-systems in an enviroment where IP addresses used for comunication are dynamic. For this to be possible there are two requirements: - That hosts can be uniquely identified. - That the correspoding location (in the form of an IP address) is known. This means that there must be a way to map from identifier to locator to be used for comunication. Your current proposal defines a way to identify end-systems but does not mention how hosts keep track of IP addresses to use in communication. Personally i believe the later is the key part of a proposal in this area. Second, i believe that EIDs are not necessary or even an advantage. Unicast IP addresses uniquely identify an end-system. An address can become depreated and then be used to identify a diferent end-system but it is as easy for an host to maintain a table with {EID, address list} of it's comunication peers as it is to maintain one with {internal ID, address list}. Addresses present on the address list do identify the comunication peer. My second objection to EIDs is the classic assignment problem. The IPv6 framework demands, IMHO, that such EIDs to exist may be assigned to an end-system without any manual configuration. We already have a mechanism to automaticly assing IPv6 addressses that is one of the reasons i think they make excelent end-system identifiers. The main content of our draft is an attempt to define a set of mechanisms to comunicate valid communication address information between hosts, and to keep the information valid. Identification is done with the IP addresses themselfs. I'm the first one to recognise that the draft as some deficiencies, and is utterly unclear. Both me and Jim have been planing to update this draft for sometime. I hope we have a new version in time for December's meeting. Anyway i'm happy to see this discussion taking place, and while i'm biased towards one of the ways of looking into the problem i recognise that your proposal does in fact solve some of the problems we're trying to deal with. I apologise for not having commented your suggestion before, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 08:33:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19502; Wed, 2 Oct 96 08:33:45 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19496; Wed, 2 Oct 96 08:33:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA13252; Wed, 2 Oct 1996 08:27:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA21862; Wed, 2 Oct 1996 08:27:20 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA04045; Wed, 2 Oct 1996 17:26:55 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA24927; Wed, 2 Oct 1996 17:26:26 +0200 Message-Id: <9610021526.AA24927@dxcoms.cern.ch> Subject: (IPng 2156) Re: suggestion (long) To: roque@di.fc.ul.pt (Pedro Roque) Date: Wed, 2 Oct 1996 17:26:26 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199610021501.QAA00571@oberon.di.fc.ul.pt> from "Pedro Roque" at Oct 2, 96 04:01:00 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 Pedro, > Your current proposal defines a way to identify end-systems but does > not mention how hosts keep track of IP addresses to use in > communication. Personally i believe the later is the key part of a > proposal in this area. It doesn't spell this out in enough detail. My model is that if the EID option is present in incoming packets, one simply replies to whatever source address is in those packets; if the source address changes, you start sending to the new one. (You might lose a TCP window during an address change.) > > Second, i believe that EIDs are not necessary or even an advantage. > Unicast IP addresses uniquely identify an end-system. See the IAB draft I cited. We say they don't, or may not in certain circumstances. That's the basic issue. I'm very annoyed to be driven to the conclusion that maybe we need EIDs. > My second objection to EIDs is the classic assignment problem. The > IPv6 framework demands, IMHO, that such EIDs to exist may be assigned to > an end-system without any manual configuration. Indeed this is an issue. > > The main content of our draft is an attempt to define a set of > mechanisms to comunicate valid communication address information > between hosts, and to keep the information valid. Identification is > done with the IP addresses themselfs. > > I'm the first one to recognise that the draft as some > deficiencies, and is utterly unclear. Both me and Jim have been > planing to update this draft for sometime. I hope we have a new > version in time for December's meeting. > I think this is important to do. Please look at the arguments in draft-iab-ip-ad-today-00.txt carefully and test your proposal against them. (There'll be an -01 version very soon, but there is no major change.) Thanks for the constructive dialogue! Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 10:08:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19606; Wed, 2 Oct 96 10:08:11 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19552; Wed, 2 Oct 96 09:51:01 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA02419; Wed, 2 Oct 1996 09:44:42 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA24372; Wed, 2 Oct 1996 09:43:36 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id MAA07746; Wed, 2 Oct 1996 12:41:52 -0400 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/09-08-96) with SMTP id MAA619177; Wed, 2 Oct 1996 12:41:49 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA43196; Wed, 2 Oct 1996 12:41:46 -0400 From: Charlie Perkins Message-Id: <9610021641.AA43196@hawpub1.watson.ibm.com> To: Pedro Roque Cc: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com, dbj@cs.cmu.edu Subject: (IPng 2157) Re: suggestion (long) In-Reply-To: Your message of Wed, 02 Oct 96 16:01:00 N. <199610021501.QAA00571@oberon.di.fc.ul.pt> Date: Wed, 02 Oct 96 12:41:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The discussion centers around ways to enable EIDs to be used for identifying endpoints (sounds tautological) instead of using IPv6 addresses as, we presume, will be done initially. This is important because IPv6 addresses seem more likely to change than IPv4 addresses. I'd like to suggest that the Binding Update destination option defined for use by mobile IPv6 nodes be considered as one way to alleviate this problem. I don't claim that the option completely solves the multihome or the anycast problems, but I think that it does go a long way to help the renumbering problem. Briefly put, a Binding Update allows a recipient to associate a "care-of" address with a "home" address (a more permanent address); our model has been that the latter address is the unchanging target of various communication sessions, and the care-of address is "where" the target may currently be "located". Previous EID discussions about the way that IP addresses are used both as identifiers and locators apply here. If there is something additional that can be done to the Binding Update option to make it more fully applicable to the problem discussed here, I would be very interested to find out about it. Likewise, if there is something about the Binding Update that makes it unsuitable for the problem, I would like to hear about that too. Brian> == Brian Carpenter Pedro> == Pedro Roque Brian> Transport and security mechanisms require end point Brian> identifiers which are guaranteed not to change when dynamic Brian> renumbering takes place. Such identifiers may also be Brian> needed when the host concerned is a member of an anycast Brian> group, or when communication flows through a network Brian> address translator, or when the host's apparent IP address Brian> is liable to change for any other reason. Brian> Approaches to this issue have been suggested in Brian> draft-bound-ipv6-ip-addr-00.txt, Brian> draft-bound-anycast-00.txt, and Brian> draft-huitema-multi-homed-01.txt [expired]. The underlying Brian> issues are discussed in those drafts and are not repeated Brian> here. The present [fragment of a] draft proposes an Brian> intentionally simplistic solution. I would like to add draft-ietf-mobileip-ipv6-01.txt to the list. An updated version, reflecting discussions held at the last IETF meeting in Montreal, should be available in the very near future. Pedro> The objective we pursue, and which is common to the several proposals Pedro> you refer, is to allow for comunication between end-systems in an Pedro> enviroment where IP addresses used for comunication are dynamic. We (the IPng working group) can choose between mechanisms where the IP destination address is itself dynamic, or whether the destination address is reached by way of a source route or tunnel which is adjusted as needed. This involves no unnecessary overhead, because _something_ has to be adjusted _somewhere_, and the destination option we (Dave Johnson and I) specify does it about as cheaply as is imaginable. Pedro> Your current proposal defines a way to identify end-systems but does Pedro> not mention how hosts keep track of IP addresses to use in Pedro> communication. Personally i believe the later is the key part of a Pedro> proposal in this area. The IPv6 mobility proposal essentially allows one level of indirection to effectively serve several related requirements, one of which is mentioned in the last paragraph. Pedro> My second objection to EIDs is the classic assignment problem. The Pedro> IPv6 framework demands, IMHO, that such EIDs to exist may be assigned to Pedro> an end-system without any manual configuration. Pedro> We already have a mechanism to automaticly assing IPv6 addressses that Pedro> is one of the reasons i think they make excelent end-system identifiers. This is probably the heart of the argument. If we may consider that IPv6 addresses can be used as EIDs as well as addresses, then I think that the Binding Update is very well suited as a solution to the abovementioned problems. Regards, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 10:29:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19650; Wed, 2 Oct 96 10:29:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19644; Wed, 2 Oct 96 10:29:01 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA16160; Wed, 2 Oct 1996 10:22:52 -0700 Received: from seawind.bellcore.com by venus.Sun.COM (Sun.COM) id KAA11351; Wed, 2 Oct 1996 10:22:51 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id NAA10075; Wed, 2 Oct 1996 13:22:39 -0400 Date: Wed, 2 Oct 1996 13:22:39 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9610021322.ZM10073@seawind.bellcore.com> In-Reply-To: "Brian Carpenter CERN-CN" "(IPng 2154) Re: suggestion (long)" (Oct 2, 4:29pm) References: <9610021429.AA17398@dxcoms.cern.ch> X-Mailer: Z-Mail (3.2.0 06sep94) To: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com Subject: (IPng 2158) Re: suggestion (long) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Right, so it's broken if the destination address changes (i.e. the > source address in the opposite direction). So there is a problem. That is actually very debatable. If the destination changes but the "entity" remains the same, then the ports and keys will still be valid and the association will be maintained. The only requirement is that one can somehow associate the old and new destinations, something that can be done via for example an ICMP message. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 11:20:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19738; Wed, 2 Oct 96 11:20:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19732; Wed, 2 Oct 96 11:20:06 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA25425; Wed, 2 Oct 1996 11:14:00 -0700 From: bound@zk3.dec.com Received: from mail12.digital.com by venus.Sun.COM (Sun.COM) id LAA13186; Wed, 2 Oct 1996 11:13:58 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA19067; Wed, 2 Oct 1996 14:01:22 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11200; Wed, 2 Oct 1996 14:01:21 -0400 Message-Id: <9610021801.AA11200@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2159) Re: suggestion (long) In-Reply-To: Your message of "Wed, 02 Oct 96 17:26:26 +0200." <9610021526.AA24927@dxcoms.cern.ch> Date: Wed, 02 Oct 96 14:01:20 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few comments on this thread and my view of this discussion.... 1. Clarity on bound/roque IPv6 Anycast Draft: At Montreal IPng WG meeting Pedro and I were told to continue with our work to define how an anycast address could be used in an IPv6 implementation with our destination option approach so it could be specified for Hosts. The areas we need to address were stated in the IPng minutes from Montreal. I started to implement this and decided I would like to see one more discussion at the next IPng meeting. The next version of the draft will be a working group named draft. So that work is to be done on this list and group. This work is very focused for IPv6 as we need want to use anycast addresses for hosts. The abstract is below: "IPv6 Anycasting Service: Minimum requirements for end nodes", J. Bound, P. Roque, 06/10/1996, This document proposes a minimum set of requirements for IPv6 hosts in order to achieve communication with nodes providing services through IPv6 anycast addresses. We present a mechanism that aims to allow TCP and UDP communication between hosts where the packet exchange is initiated through the usage of an anycast address, without requiring modifications to the general definitions of the transport protocols. 2. Clarity bound/roque Dyn Reassign of IP Addresses. This is where Pedro and I started and move to the draft above to address the anycast addresses. But this work will continue and Pedro and I will update this draft and most likely rename it. I am not clear where this work should be discussed but it sounds like the Transports area. But for the IPv6 Multihoming work we need this work too. It is in direct competition with Christian Huitema draft and we just don't agree with Christian and also think UDP is important too not just TCP. "Dynamic Reassignment of IP Addresses for TCP and UDP", J. Bound, P. Roque, 02/19/1996, This document is a proposal to extend the communications model for IP version 6 (IPv6) to support changing the transport address dynamically between two communicating end systems using a new IPv6 Destination Option. The proposal supports this dynamic address change for both TCP and UDP. The proposal has applicability in IPv6 for Dynamic Renumbering, Anycast Addresses, Multihoming, and Mobility. The proposal requires no changes to the existing TCP or UDP protocols, and is optional for IPv6 implementations. 3. On EIDS. I support where Brian is headed because if we can develop an EID as a Destination Option for a "site" I think we can discuss how that could be used for security and as an administrative tool for packet forwarding in addition to the flow-id. I absolutely believe there is nothing wrong with using the network layer to parse identifiers for the transport and application conceptual layers. But that is an intense architecture discussion I am not sure where should take place but not on the Big-I list OK. 4. My conclusion: I see three subjects above. What I do not think now from Brian, Christian, and Pedro's mail is that a draft from the IAB should state that we have not done our job for IPv6 yet because we don't have an identifier (and actually see RFC 1884 where it states that the IPv6 address is an "identifier") in the architecture. This is not right, fair, and will do damage to our efforts to move IPv6 forward simply becuase of discussion. If that statement is made then I think it needs to be justified in detail and from all the past mail on EIDs where no one could even agree with each other I suggest we clarify in detail what Brian's purpose of an EID is for IPv6 on this mailing list as a worthwhile exercise so the next draft states the issue clearly. I think topic #1 anycast addresses is its own discussion. I think topic #2 anbd #3 are needed to happen in unison and should have their own mail list, but first getting clarity on the goals on the IPng list seems appropriate. But multihoming Mike Shand draft needs some of the concepts in topics #1, #2, and #3. So I think we need to parse the discussions to be productive. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 11:50:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19794; Wed, 2 Oct 96 11:50:21 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19788; Wed, 2 Oct 96 11:50:08 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA07898; Wed, 2 Oct 1996 11:43:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA15563; Wed, 2 Oct 1996 11:38:30 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id TAA01287; Wed, 2 Oct 1996 19:28:26 +0100 Date: Wed, 2 Oct 1996 19:28:26 +0100 Message-Id: <199610021828.TAA01287@oberon.di.fc.ul.pt> From: Pedro Roque To: Charlie Perkins Cc: Pedro Roque , "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com, dbj@cs.cmu.edu, bound@zk3.dec.com Subject: (IPng 2160) Re: suggestion (long) In-Reply-To: <9610021641.AA43196@hawpub1.watson.ibm.com> References: <199610021501.QAA00571@oberon.di.fc.ul.pt> <9610021641.AA43196@hawpub1.watson.ibm.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Charlie" == Charlie Perkins writes: Charlie> The discussion centers around ways to enable EIDs to be Charlie> used for identifying endpoints (sounds tautological) Charlie> instead of using IPv6 addresses as, we presume, will be Charlie> done initially. This is important because IPv6 addresses Charlie> seem more likely to change than IPv4 addresses. Charlie> I'd like to suggest that the Binding Update destination Charlie> option defined for use by mobile IPv6 nodes be considered Charlie> as one way to alleviate this problem. I don't claim that Charlie> the option completely solves the multihome or the anycast Charlie> problems, but I think that it does go a long way to help Charlie> the renumbering problem. Briefly put, a Binding Update Charlie> allows a recipient to associate a "care-of" address with Charlie> a "home" address (a more permanent address); our model Charlie> has been that the latter address is the unchanging target Charlie> of various communication sessions, and the care-of Charlie> address is "where" the target may currently be "located". Charlie> Previous EID discussions about the way that IP addresses Charlie> are used both as identifiers and locators apply here. Charlie, My objection with the Binding Update is that it uses a primary/secondary address model why has some limitations (like you acknowledge). For instance: Host A has address A1 and renumbers to B1 A1 will still be know to it's peers as A's identifier. This can be a problem if A's peer C gets to talk to a third host than now uses A1 has it's primary address. If we choose the Binding Update model, then i believe we must have EIDs. In fact Binding Updates are usable in the model Brian describes and can be an answer to the criticism i made about the destination address selection on communication peers of the host that is renumbering. The dynamic IP address draft could be seen as a superset of the binding update model. The main differences is that: 1) It does not have the concept of a primary address that must stay there for as long as the communication lasts. Any address can be removed from the set. 2) An ``address-set'' can have more than two addresses. 3) It provides identification by itself. The downside of our proposal is that we've yet to prove that it works :-) I believe it can be made to work. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 12:40:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19884; Wed, 2 Oct 96 12:40:59 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19878; Wed, 2 Oct 96 12:40:47 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA20868; Wed, 2 Oct 1996 12:34:41 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id MAA08182; Wed, 2 Oct 1996 12:34:40 -0700 Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA30694; Wed, 2 Oct 1996 15:20:50 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA24958; Wed, 2 Oct 1996 15:20:33 -0400 Message-Id: <9610021920.AA24958@fwasted.zk3.dec.com> To: Charlie Perkins Cc: Pedro Roque , "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com, dbj@CS.CMU.EDU Subject: (IPng 2161) Re: suggestion (long) In-Reply-To: Your message of "Wed, 02 Oct 96 12:41:44 CDT." <9610021641.AA43196@hawpub1.watson.ibm.com> Date: Wed, 02 Oct 96 15:20:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, Pedro and I looked at your binding update for anycast and fixed what we think was required. Also your update is focused on mobile and a different end result is needed. We stated this to the working group too. I guess you were not at that IPng meeting in Montreal. I see no problem of a binding update and an anycast update. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 2 13:30:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19957; Wed, 2 Oct 96 13:30:42 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19951; Wed, 2 Oct 96 13:30:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02753; Wed, 2 Oct 1996 13:24:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA27145; Wed, 2 Oct 1996 13:24:07 -0700 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id NAA03597; Wed, 2 Oct 1996 13:23:29 -0700 Date: Wed, 2 Oct 1996 13:23:29 -0700 From: Ran Atkinson Message-Id: <199610022023.NAA03597@cornpuffs.cisco.com> To: huitema@bellcore.com Subject: (IPng 2162) Re: suggestion (long) In-Reply-To: <9610021322.ZM10073@seawind.bellcore.com> References: Organization: cisco Systems Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Right, so it's broken if the destination address changes (i.e. the >> source address in the opposite direction). So there is a problem. In article <9610021322.ZM10073@seawind.bellcore.com> Christian Huitema wrote: >That is actually very debatable. If the destination changes but the >"entity" remains the same, then the ports and keys will still be valid and >the association will be maintained. The only requirement is that one can >somehow associate the old and new destinations, something that can be done >via for example an ICMP message. In the case where ISAKMP/Oakley is being used for key management (which is the common case as of the recent announcement from the Security AD), the optimal approach to handle the node renumbering issues related to IPsec is probably to send an (authenticated, of course) ISAKMP Modify message to modify the appropriate existing Security Association. An (authenticated) ICMP message could also work, but would involve kernel complexity not strictly needed to modify an IPsec Security Association. I generally prefer to avoid kernel bloat wherever practical. Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 3 01:45:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20845; Thu, 3 Oct 96 01:45:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA20839; Thu, 3 Oct 96 01:45:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA20341; Thu, 3 Oct 1996 01:38:53 -0700 From: Victor.DIAS-FERNANDES@dg12.cec.be Received: by mercury.Sun.COM (Sun.COM) id BAA16509; Thu, 3 Oct 1996 01:38:49 -0700 Received: from MX3.CEC.BE (tcbru10x [158.169.10.20]) by tcbru22.cec.be (8.6.12/8.6.12) with SMTP id KAA08965; Thu, 3 Oct 1996 10:12:44 +0200 X400-Received: by mta MX3.CEC.BE in /PRMD=CEC/ADMD=RTT/C=BE/; Relayed; Thu, 3 Oct 1996 10:12:19 +0200 X400-Received: by /PRMD=CEC/ADMD=RTT/C=BE/; Relayed; Thu, 3 Oct 1996 10:05:20 +0200 Date: Thu, 3 Oct 1996 10:05:20 +0200 X400-Originator: Victor.DIAS-FERNANDES@DG12.cec.be X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=CEC/ADMD=RTT/C=BE/;0011500003937828000002] X400-Content-Type: P2-1988 (22) Content-Identifier: Re: (IPng 2156) Message-Id: To: Cc: " (Pedro Roque)" , In-Reply-To: <9610021526.AA24927@dxcoms.cern.ch> Subject: (IPng 2163) Re: suggestion (long) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro> > My second objection to EIDs is the classic assignment problem. The Pedro> > IPv6 framework demands, IMHO, that such EIDs to exist may be assigned to Pedro> > an end-system without any manual configuration. Brian> Indeed this is an issue. I didn`t had the time to read all the referred drafts, and I don`t know if this solution will be useful. If a sufficiently long string is hashed to a sufficiently long value this value could be used as the EID for the session, e.g.: Current IP Address in use + host name + domain name + host serial number (if available) + etc ... Victor Fernandes ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 3 01:50:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20857; Thu, 3 Oct 96 01:50:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA20851; Thu, 3 Oct 96 01:49:55 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA20528; Thu, 3 Oct 1996 01:43:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA17170; Thu, 3 Oct 1996 01:43:47 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id KAA31261; Thu, 3 Oct 1996 10:19:41 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA03962; Thu, 3 Oct 1996 10:19:37 +0200 Message-Id: <9610030819.AA03962@dxcoms.cern.ch> Subject: (IPng 2164) Re: suggestion (long) To: bound@zk3.dec.com Date: Thu, 3 Oct 1996 10:19:36 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610021801.AA11200@fwasted.zk3.dec.com> from "bound@zk3.dec.com" at Oct 2, 96 02:01:20 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 Jim, > ... What I do not think now from Brian, > Christian, and Pedro's mail is that a draft from the IAB should state > that we have not done our job for IPv6 yet because we don't have an > identifier (and actually see RFC 1884 where it states that the IPv6 > address is an "identifier") in the architecture. This is not right, > fair, and will do damage to our efforts to move IPv6 forward simply > becuase of discussion. Of course we will review the text in the IAB draft as a result of this discussion. As a matter of fact the text was intended to re-trigger this discussion, so it's already succeeded. > ...If that statement is made then I think it needs > to be justified in detail and from all the past mail on EIDs where no > one could even agree with each other I suggest we clarify in detail what > Brian's purpose of an EID is for IPv6 on this mailing list as a > worthwhile exercise so the next draft states the issue clearly. My *personal* objective is to ensure that we do not launch IPv6 on the world without a fully functional renumbering/rehoming solution. I've got no particular emotional attachment to my proposal, except that I think it's fairly simple, which I like. ... > So I think we need to parse the discussions to be productive. Correct, and it would be good if somebody volunteers to do a compare/contrast analysis of the various possible solutions in San Jose. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 3 05:55:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20885; Thu, 3 Oct 96 05:55:32 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA20878; Thu, 3 Oct 96 05:55:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA05557; Thu, 3 Oct 1996 05:49:03 -0700 From: bound@ZK3.DEC.COM Received: by mercury.Sun.COM (Sun.COM) id FAA20927; Thu, 3 Oct 1996 05:49:01 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id IAA12967; Thu, 3 Oct 1996 08:40:30 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31858; Thu, 3 Oct 1996 08:40:29 -0400 Message-Id: <9610031240.AA31858@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2165) Re: suggestion (long) In-Reply-To: Your message of "Thu, 03 Oct 96 10:19:36 +0200." <9610030819.AA03962@dxcoms.cern.ch> Date: Thu, 03 Oct 96 08:40:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, I believe that renumbering completely works and for customers that want to know I explain it to them clearly how exactly it can be done with our knowledge from building the inherent renumbering into IPv6 implementation on Hosts and Routers. This includes renumbering with your upstream ISP. But there are missing pieces between the user site and the ISP not in the IPv6 architecture and more importantly not in the IPv6 addressing architecture. But as all know I think the market is ready and has enough customers with greenbacks telling us they want IPv6 now and that it will get launched very soon. The renumbering is very inherent from addrconf, dhcpv6, and the use of anycast addresses on "routers" (hosts we need to work out in the IETF). OSPFv6 is looking real good and uses link-local addresses and router identifiers for the LSP map. The missing admin pieces are for renumbering the update of a new prefix for the site from the ISP. There is no means to inject a prefix into a site via the routing protocols that this is a new prefix and you should renumber. What we are missing is work for IDRPv6. That is needed. For now if the ISP is running a DHCPv6 server and my site is a DHCPv6 client I can negotiate a new prefix and notification to renumber. Not a pretty solution but it will "work". We need other pieces for deployment on a wide scale and I think those top priority items are the Provider-Based draft to move to PS and for us implementors to figure out a way to discover IPv4 tunnels for IPv6 nodes between the tunnels. WHich I think we will figure out on the 6bone mail list soon. Multihoming is also critical and again if we don't figure it out in the IETF soon it will just get implemented. I note I still have yet to see any responses to Mike Shand who offered to get this Multihoming done via a standards forum. There is no hold at this point for IPv6 waiting for the IETF. Its just a matter of the vendors giving their customers implementations which will cause the customers to put packets on the network and then ISPs/NAPs routing the packets which they will do for numerous reasons. Plus with the recent ISAKMP/OAKLEY and administration news regarding freeing up encryption in the U.S. for international business that is out of our way to get security really really done. I view our work here to refine and verify the finer grained points of the IPv6 architecture and that will just take time. Get implementations done to test what we have built and get to IS status. We are long past the time for vague and long-winded Big-I architecture discussions for proposals that were utterly defeated in the IETF two years ago for IPng. The market won't listen to it and wants what Steve Deering invented and what this working group has done to invent the surrounding pieces around the IPv6 architecture. But what is the difference between "rehoming" and "renumbering" in your statement? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 3 08:48:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20968; Thu, 3 Oct 96 08:48:02 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA20962; Thu, 3 Oct 96 08:47:48 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23838; Thu, 3 Oct 1996 08:41:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA15290; Thu, 3 Oct 1996 08:40:43 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA11103 for ; Thu, 3 Oct 1996 17:40:26 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA30645; Thu, 3 Oct 1996 17:40:26 +0200 Message-Id: <9610031540.AA30645@dxcoms.cern.ch> Subject: (IPng 2166) Re: suggestion (long) To: ipng@sunroof.eng.sun.com Date: Thu, 3 Oct 1996 17:40:26 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9610031345.AA09266@fwasted.zk3.dec.com> from "bound@zk3.dec.com" at Oct 3, 96 09:45:43 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > Now if we are talking about TCP or even a UDP app running across and > past the invalidation timer that is another story? Is that what we are > talking about? Or changing the address during the telnet connection > when its not an anycast host situation? If so lets get that discussion > on the mailing list a.s.a.p. > Exactly. Any long-lived TCP or similar. There are plenty of apps that will just blow up if TCP blows up. telnet is the least of my worries. Other folks: am I worrying about something unimportant? Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 3 12:47:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21154; Thu, 3 Oct 96 12:47:40 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA21148; Thu, 3 Oct 96 12:47:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA03690; Thu, 3 Oct 1996 12:41:17 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id MAA23806; Thu, 3 Oct 1996 12:40:38 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA31584; Thu, 3 Oct 1996 15:31:20 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05433; Thu, 3 Oct 1996 15:31:25 -0400 Message-Id: <9610031931.AA05433@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2167) Re: suggestion (long) In-Reply-To: Your message of "Thu, 03 Oct 96 17:40:26 +0200." <9610031540.AA30645@dxcoms.cern.ch> Date: Thu, 03 Oct 96 15:31:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Now if we are talking about TCP or even a UDP app running across and >> past the invalidation timer that is another story? Is that what we are >> talking about? Or changing the address during the telnet connection >> when its not an anycast host situation? If so lets get that discussion >> on the mailing list a.s.a.p. >> >Exactly. Any long-lived TCP or similar. >There are plenty of apps that will just blow up >if TCP blows up. telnet is the least of my worries. >Other folks: am I worrying about something unimportant? Well if we are talking about that then that is what Pedro and I were first going to address and we can still address it as others should to as I think the answer will be a combination of good ideas. But to say that this is any reason to not deploy IPv6 now or in the near future is not valid and that is what I hope the IAB does not say or even allude too. In fact if that is done I think there would be a counter response from somewhere publicly. But I too would like to hear from others if this is something they want to solve. I also responded to the rehoming issue and like I stated that is a much larger problem than the Internet Protocol suite. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 3 13:55:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21268; Thu, 3 Oct 96 13:55:18 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA21261; Thu, 3 Oct 96 13:55:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA20959; Thu, 3 Oct 1996 13:48:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA15350; Thu, 3 Oct 1996 13:47:11 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id VAA00754; Thu, 3 Oct 1996 21:44:55 +0100 Date: Thu, 3 Oct 1996 21:44:55 +0100 Message-Id: <199610032044.VAA00754@oberon.di.fc.ul.pt> From: Pedro Roque To: "Brian Carpenter CERN-CN" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2168) Re: suggestion (long) In-Reply-To: <9610030819.AA03962@dxcoms.cern.ch> References: <9610021801.AA11200@fwasted.zk3.dec.com> <9610030819.AA03962@dxcoms.cern.ch> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Brian" == Brian Carpenter CERN-CN writes: Brian> My *personal* objective is to ensure that we do not launch Brian> IPv6 on the world without a fully functional Brian> renumbering/rehoming solution. I've got no particular Brian> emotional attachment to my proposal, except that I think Brian> it's fairly simple, which I like. ... I don't believe that this is going to happen. IPv6, as presently defined, supports "reboot renumbering" quite well (you don't actually need the reboot in many cases). This is a significative improvement from the IPv4 situation. Most vendors have running prototypes by now and i doubt they'll freeze them until we can get consensus on: 1) Is this an issue we should solve 2) How to do it And actually manage to come up with a specification that pleases everyone. I lost track of the "we're out of IPv4 addresses" deadline, but already many people claim the we're way behind schedule. Besides vendors are puting employes working full time into their IPv6 implementations. I doubt they won't make the client feel the need for the product. However i think we'll manage to acomplish this goal in time for the "IPv6 hosts requirements" RFC :-) I think that if the IAB hopes for the WG to fulfill it's miling stones in resonable time it cannot put this requirement to the group. >> So I think we need to parse the discussions to be productive. Brian> Correct, and it would be good if somebody volunteers to do Brian> a compare/contrast analysis of the various possible Brian> solutions in San Jose. That would be nice. My concern is that when we reach San Jose we might not have agreed on the right forum for this discussion yet. Can we hear something on this from the WG chairs ? regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 3 17:33:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21715; Thu, 3 Oct 96 17:33:44 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA21709; Thu, 3 Oct 96 17:33:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA11979; Thu, 3 Oct 1996 17:26:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA29275; Thu, 3 Oct 1996 17:25:41 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15545(3)>; Thu, 3 Oct 1996 17:25:37 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 3 Oct 1996 17:25:21 PDT To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, hinden@ipsilon.com, deering@parc.xerox.com Subject: (IPng 2169) Re: suggestion (long) In-Reply-To: brian's message of Thu, 03 Oct 96 08:40:26 -0800. <9610031540.AA30645@dxcoms.cern.ch> Date: Thu, 3 Oct 1996 17:25:20 PDT From: Steve Deering Message-Id: <96Oct3.172521pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, For some unknown reason, neither Bob Hinden nor I received a copy of your original message that triggered the current discussion thread on the ipng list -- I presume it was ipng message number 2152, since that's the one gap I see in the sequence number space. Could you please send a copy of the message to Bob and me? Also, if (and only if) you get messages from other people saying they also missed it, you should probably retransmit it to the mailing list. Thanks, Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 3 17:34:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21722; Thu, 3 Oct 96 17:34:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA21716; Thu, 3 Oct 96 17:33:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA14383; Thu, 3 Oct 1996 17:27:37 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA29739; Thu, 3 Oct 1996 17:27:37 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id UAA10679; Thu, 3 Oct 1996 20:25:52 -0400 Date: Thu, 3 Oct 1996 20:25:52 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9610032025.ZM10677@seawind.bellcore.com> In-Reply-To: Charlie Perkins "(IPng 2157) Re: suggestion (long)" (Oct 2, 12:41pm) References: <9610021641.AA43196@hawpub1.watson.ibm.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: Charlie Perkins , Pedro Roque Subject: (IPng 2170) Re: suggestion (long) Cc: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com, dbj@cs.cmu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie's proposition to relate identification and mobility is very interesting, because it provides for a "back up point of contact" after renumbering. However, we have to make sure for it to work that the "permanent" address is a) permanent, does not get renumbered or if so only rarely, b) reachable, which means that packet sent to that address will always arrive to the final destination, even if it has moved or was renumbered. But there is really very few requirement of performance, so (b) is probably workable. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 4 01:31:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22218; Fri, 4 Oct 96 01:31:08 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA22212; Fri, 4 Oct 96 01:30:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA15363; Fri, 4 Oct 1996 01:24:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA20862; Fri, 4 Oct 1996 01:24:15 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id KAA10482 for ; Fri, 4 Oct 1996 10:24:14 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA16858; Fri, 4 Oct 1996 10:24:13 +0200 Message-Id: <9610040824.AA16858@dxcoms.cern.ch> Subject: (IPng 2171) suggestion (long) (replay) To: ipng@sunroof.eng.sun.com Date: Fri, 4 Oct 1996 10:24:13 +0200 (MET DST) From: "Brian Carpenter CERN-CN" 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 Yes, I think there have been problems with the list. Things have been arriving in disorder or not at all. I'll add one clarification of the intent of this: it is me talking, not the IAB, and I do not mean to suggest that this issue is a show-stopper. It's just something we need to talk about. Brian >--------- Text sent by Brian Carpenter CERN-CN follows: From brian Wed Oct 2 13:58:29 1996 Subject: suggestion (long) To: ipng@sunroof.eng.sun.com Date: Wed, 2 Oct 1996 13:58:29 +0200 (MET DST) From: "Brian Carpenter CERN-CN" X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7214 IPng folks, draft-iab-ip-ad-today-00.txt says that > .... Thus, IPv6 will amplify the existing > problem of finding stable identifiers to be used for end-to-end > security and for session bindings such as TCP state. > > The IAB feels that this is unfortunate, and that the transition to > IPv6 would be an ideal occasion (possibly the last ever) to provide > upper layer end-to-end protocols with temporally unique identifiers. > The exact nature of these identifiers requires further study. On the grounds that this is a dangling pointer, here is an idea to stimulate debate. Transport and security mechanisms require end point identifiers which are guaranteed not to change when dynamic renumbering takes place. Such identifiers may also be needed when the host concerned is a member of an anycast group, or when communication flows through a network address translator, or when the host's apparent IP address is liable to change for any other reason. Approaches to this issue have been suggested in draft-bound-ipv6-ip-addr-00.txt, draft-bound-anycast-00.txt, and draft-huitema-multi-homed-01.txt [expired]. The underlying issues are discussed in those drafts and are not repeated here. The present [fragment of a] draft proposes an intentionally simplistic solution. It is suggested that the simplest approach to this problem is to limit the problem to source identifiers, trusting the addressing and routing systems to deliver packets only to the correct destination. In this case, it is only necessary for sources to identify themselves invariantly. If one end of a communication is renumbered, rehomed or has its outgoing packets translated, an invariant source identifier is necessary and sufficient. An IPv6 destination option is proposed for this. An IPv6 implementation MUST support this option both as a a source (generating the option) and as a destination (interpreting the option). Furthermore, the implementation MUST provide an administrative mechanism for enabling or disabling the generation of this option, and for assigning an EID value to the host. [The format is defined below.] When the generation of this option is enabled in a particular host, it MUST include the option in every outgoing IPv6 packet, filled in with the host's assigned EID value. Furthermore its transport and security mechanisms SHALL use the assigned EID value (padded to 16 octets) as a unique identifier for all outgoing traffic. Hosts with the option disabled SHALL use the IPv6 source address in use for a particular communication as a unique identifier for that communication. [This implies that the EID must be available to the transport and security layers, and presumably in the UDP API.] If an ongoing transaction is rehomed, its new host MUST use the same EID and port number. [This limits rehoming to a smallish group of co-managed hosts, but that is presumably reasonable.] When this option is received by any IPv6 host, transport and security mechanisms SHALL use the EID value supplied (padded to 16 octets) as a unique identifier for the sender. When this option is absent, they SHALL use the source IPv6 address as a unique identifier for the sender. In either case they SHALL send return packets to the source IPv6 address, which may legitimately change in the presence of the EID option. The worst case is that during a change of address, a few packets are lost; this is acceptable behaviour in an IP network. Note that the use of anycast addresses is fully compatible with this approach, since anycast addresses are disallowed as source addresses in any case. If a client opens communication with a server via an anycast address, the server that actually responds will do so from a legitimate unicast source address, with or without supplying an EID. The EID destination option is illustrated below. It has no alignment requirement. Its length is chosen such that if it is the only destination option present, the entire destination options header will be 16 octets. The option type code is 11-0-TBD = TBD decimal. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 TBD |Opt Data Len=12| OUI-head (octets 0-1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI-head (octets 2-5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OUI-tail (octets 0-2) |LocalID octet 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local ID octets 1-2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the OUI-head is zero, the 6 octets constituting the OUI-tail and Local identifier MUST be a valid, globally unique IEEE MAC address. If the OUI-head is non-zero, then the OUI-head and OUI-tail are considered to form a 9 octet OUI (Organizationally Unique Identifier), uniquely identifying a network site. The format and allocation mechanism for OUIs SHALL be analogous to that for provider-based IPv6 addresses with or without a national registry, but with a ProviderID of length zero (compare [draft-ietf-ipngwg-unicast-addr-fmt-04.txt]). Thus the two OUI formats are: | 3 | 5 bits | 64 bits | +---+----------+--------------+ |010|RegistryID| SiteID | +---+----------+--------------+ | 3 | 5 bits | n bits | 64-n bits | +---+----------+----------+------------+ |010|RegistryID| National | Site | | | |RegistryID| ID | +---+----------+----------+------------+ with the details being decided at registry level. In this case each site MUST administratively allocate unique 3 octet Local identifiers. [The assumption is that in most cases, a pure IEEE address will suffice as an EID. The additional mechanism is provided to ensure that this assumption never becomes a showstopper. Maybe the OUI is longer than necessary?] [A format prefix is used, as in an IPv6 address, so that additional formats could be added later.] [An alternative would be to use a full-size IPv6 address, with a specific format-prefix for EIDs, but this loses the possible neat alignment.] Implementations MUST interpret the option data length field, i.e. MUST NOT assume that all EIDs are of length 12 octets, in case of future extensions. Implementations MAY optimise for the case of length 12. Implementations MUST NOT interpret the contents of an EID as having any significance except that of being a unique bit string. The EID formats are specified only to enable an allocation mechanism. (Thanks to Yakov Rekhter, Tony Li, Jim Bound and Thomas Narten for comments on this. The basic idea is not original, and goes back to at least 1994...) Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 5 10:33:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23180; Sat, 5 Oct 96 10:33:58 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23174; Sat, 5 Oct 96 10:33:45 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA22413; Sat, 5 Oct 1996 10:27:34 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id KAA18636; Sat, 5 Oct 1996 10:25:43 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA05390; Sat, 5 Oct 1996 13:12:07 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA25561; Sat, 5 Oct 1996 13:10:44 -0400 Message-Id: <9610051710.AA25561@fwasted.zk3.dec.com> To: deering@parc.xerox.com, hinden@ipsilon.com Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 2172) IPv6 PS to DS Status? Date: Sat, 05 Oct 96 13:10:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve and Bob, Are we ready to move: RFC 1883 Base Spec RFC 1884 Addressing Architecture RFC 1885 ICMP RFC 1886 DNS AAAA Records RFC 1970 ND RFC 1971 Stateless Autoconfiguration RFC 1972 IPv6 over Ethernet RFC 1981 IPv6 Path MTU Discovery to Draft-Standard status. There are multiple independent implementations, interoperability testing via University of New Hampshire (UNH) IPv6 Interoperability Consortia, and two formal announcment and delivery of products from FTP Software and Telebit. Other vendors are giving clear signals that they are ready to consider products, and Sun and Digital are providing IPv6 AD kits to their users now, and HP will do so in the near future. IPv6 has also been implemented on the 6bone which is growing exponentially. In addition there is a growing ground swell from users in the market that want to begin using IPv6 for several reasons the most urgent being the expanded address space and efficiencies inherent in IPv6 for route aggregation and dynamic renumbering (e.g. plug and play, addr conf to reduce labor intensive cost of managing IPv4 as compared to IPv6). There are two public domain code bases one at INRIA and one at NRL, and another in process at UNH. Also rumor has it that at the UNH bake-off Dec 2-6 we will have implementations doing IPSEC and hopefully ISAKMP/OAKELY so we are even getting through the Security knot-hole too. I believe after San Jose December 1996 IETF meeting we should move the above work to Draft-Standard and this should also affect the IPng WG agenda at San Jose greatly. If we cannot do this? Why not and what else do we need officially to do as a WG to get this accomplished? I will address RFC 1933 IPv6 Transition on the ngtrans mailing list. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 5 11:08:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23216; Sat, 5 Oct 96 11:08:10 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23210; Sat, 5 Oct 96 11:07:56 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA24419; Sat, 5 Oct 1996 11:01:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA00421; Sat, 5 Oct 1996 10:56:57 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA24279; Sun, 6 Oct 1996 03:39:32 +1000 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: deering@parc.xerox.com, hinden@ipsilon.com, ipng@sunroof.eng.sun.com Subject: (IPng 2173) Re: IPv6 PS to DS Status? In-Reply-To: Your message of "Sat, 05 Oct 1996 13:10:44 -0400." <9610051710.AA25561@fwasted.zk3.dec.com> Date: Sun, 06 Oct 1996 03:39:29 +1000 Message-Id: <17910.844537169@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, the first four could go to DS, if everyone is happy with them, the last 4 haven't been at PS for 6 months yet, they're not eligible. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 5 20:35:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23522; Sat, 5 Oct 96 20:35:45 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23516; Sat, 5 Oct 96 20:35:26 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA18861; Sat, 5 Oct 1996 20:29:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA21991; Sat, 5 Oct 1996 20:28:45 -0700 From: Masataka Ohta Message-Id: <199610060327.MAA02475@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA02475; Sun, 6 Oct 1996 12:27:44 +0900 Subject: (IPng 2174) Re: suggestion (long) To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Sun, 6 Oct 96 12:27:43 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610031540.AA30645@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Oct 3, 96 5:40 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; > Exactly. Any long-lived TCP or similar. > There are plenty of apps that will just blow up > if TCP blows up. telnet is the least of my worries. > > Other folks: am I worrying about something unimportant? I do agree with you. We need world wide unique ID. Moreover, optional EID field is not so good because we must have a mechanism (like in-addr.arpa) to maintain the uniqueness of the EID IN ADDITION TO that for IPv6 addresses. Too much redundant work. Why don't we make lower 8 octets of Ipv6 address world-wide unique? It's doable as routing hierarchy does not have to and should not be encoded within that part of the address. And, there is one more reason why 8 byte ID is preferable. With a new link layer technology, IEEE 1394, world wide unique link layer ID is 8, NOT 6, octets long. This may not be a immediate problem for IPv6, as IEEE 1394 has a short-term 2 byte link-unique ID. But, the 2 byte ID changes dynamically upon bus reset, beyond which equipments are expected to continue operation. That is, Ipv6 equipments with IEEE 1394, at least, be able to detect bus reset and changes link local IP address. Moreover, it is quite likely that future link layer technologies will also use the 8 byte world wide ID with no shorter link unique IDs. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 5 22:41:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23562; Sat, 5 Oct 96 22:41:37 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23556; Sat, 5 Oct 96 22:41:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA22972; Sat, 5 Oct 1996 22:35:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA29305; Sat, 5 Oct 1996 22:34:38 -0700 From: Masataka Ohta Message-Id: <199610060534.OAA02789@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA02789; Sun, 6 Oct 1996 14:33:45 +0859 Subject: (IPng 2175) Re: suggestion (long) (replay) To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Sun, 6 Oct 96 14:33:45 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610040824.AA16858@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Oct 4, 96 10:24 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; I need a clarification. > Transport and security mechanisms require end point identifiers which > are guaranteed not to change when dynamic renumbering takes place. Does the end point identifier globally identifies: 1) a host, that is, an end system 2) an interface of a host or 3) an transport layer end points such as an end of an individual TCP connection ? For mobility and renumbering, 1) is sufficient. But several people have, during past EID discussions, insisted that EID is to identify 3). Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 00:57:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23649; Sun, 6 Oct 96 00:57:54 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23643; Sun, 6 Oct 96 00:57:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA27274; Sun, 6 Oct 1996 00:51:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA05469; Sun, 6 Oct 1996 00:50:59 -0700 Received: from localhost (vvivek@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id DAA11578 for ; Sun, 6 Oct 1996 03:50:55 -0400 Date: Sun, 6 Oct 1996 03:50:54 -0400 (EDT) From: Vivek Venkatraman To: ipng@sunroof.eng.sun.com Subject: (IPng 2176) MIBs for IPng Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hallo, I'd like to know if new MIBs have been defined or existing MIBs extended for the IPng protocols. thanks, Vivek ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 01:23:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23678; Sun, 6 Oct 96 01:23:23 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23672; Sun, 6 Oct 96 01:23:08 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA28629; Sun, 6 Oct 1996 01:16:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA07404; Sun, 6 Oct 1996 01:16:17 -0700 Received: from localhost (vvivek@localhost) by grex.cyberspace.org (8.6.13/8.6.12) with SMTP id EAA12952 for ; Sun, 6 Oct 1996 04:16:06 -0400 Date: Sun, 6 Oct 1996 04:16:05 -0400 (EDT) From: Vivek Venkatraman To: ipng@sunroof.eng.sun.com Subject: (IPng 2177) few queries Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hallo, I am working on a router implementation of IPV6 and would appreciate inputs on the following queries: * If an address is configured on a router interface with valid and preferred lifetimes, are these lifetimes meant only for Router Advertisement or should the router also run corresponding timers and invalidate the address after valid lifetime expires ? * If an address prefix is configured to be advertised but the router is configured to suppress both the A & O bits, should it advertise this prefix ? If hosts receive such a prefix information what do they do with it ? * When a router receives a packet on an interface destined to a subnet-router anycast address corresponding to some other interface of the router, should it accept the packet for itself ? * What do node-local multicast addresses signify ? * RFC 1933 indicates that a tunnel is to be viewed just like any other data link for the purposes of Hop Limit and so on. Does this imply that routers or nodes at either end of the tunnel are to be considered as "on-link" and exchange ND and RIP messages between themselves ? thanks Vivek ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 05:25:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23735; Sun, 6 Oct 96 05:25:09 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23729; Sun, 6 Oct 96 05:24:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA03925; Sun, 6 Oct 1996 05:18:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA16400; Sun, 6 Oct 1996 05:17:45 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.6/8.7.1) with ESMTP id OAA19089; Sun, 6 Oct 1996 14:17:43 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id NAA12399; Sun, 6 Oct 1996 13:17:42 +0100 (MET) Message-Id: <199610061217.NAA12399@givry.inria.fr> From: Francis Dupont To: Vivek Venkatraman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2178) Re: MIBs for IPng In-Reply-To: Your message of Sun, 06 Oct 1996 03:50:54 EDT. Date: Sun, 06 Oct 1996 14:17:41 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'd like to know if new MIBs have been defined or existing MIBs extended for the IPng protocols. => there is a mailing-list (ip6mib[-request]@research.ftp.com) with an archive ftp://research.ftp.com/pub/ip6mib/archive but without traffic on the list nor proposals... It seems rather easy to write an IPv6 MIB if (*if*!!!) you have free time. Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 05:42:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23751; Sun, 6 Oct 96 05:42:25 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23745; Sun, 6 Oct 96 05:42:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA04372; Sun, 6 Oct 1996 05:35:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA17148; Sun, 6 Oct 1996 05:35:23 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.6/8.7.1) with ESMTP id OAA19186; Sun, 6 Oct 1996 14:35:22 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id NAA12756; Sun, 6 Oct 1996 13:35:21 +0100 (MET) Message-Id: <199610061235.NAA12756@givry.inria.fr> From: Francis Dupont To: Vivek Venkatraman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2179) Re: few queries In-Reply-To: Your message of Sun, 06 Oct 1996 04:16:05 EDT. Date: Sun, 06 Oct 1996 14:35:21 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I am working on a router implementation of IPV6 and would appreciate inputs on the following queries: * If an address is configured on a router interface with valid and preferred lifetimes, are these lifetimes meant only for Router Advertisement or should the router also run corresponding timers and invalidate the address after valid lifetime expires ? => I believe router managers want to do the management themselves then automatic configuration/management of routers is not what they want (but I think the standard applies by default to routers too). * If an address prefix is configured to be advertised but the router is configured to suppress both the A & O bits, should it advertise this prefix? If hosts receive such a prefix information what do they do with it ? => this point was discussed at the last UNH test week. It seems reasonnable to ignore a such prefix information but something more accurate should be specified. * When a router receives a packet on an interface destined to a subnet-router anycast address corresponding to some other interface of the router, should it accept the packet for itself ? => I believe it should accept it (because this kind of anycast is "functionnal" then a property of the router not the interface). * What do node-local multicast addresses signify ? => they are for intra-node multicast communication (not so silly because the port management is different for multicasts). * RFC 1933 indicates that a tunnel is to be viewed just like any other data link for the purposes of Hop Limit and so on. Does this imply that routers or nodes at either end of the tunnel are to be considered as "on-link" and exchange ND and RIP messages between themselves ? => this point is still open. I think the answer is no but obviously some others believe it is yes: we'd like to restrict ND (NUD and redirects) to physical interfaces and they'd like to have unreachable detection for RIP without the facility in RIP... Regards Francis.Dupont@inria.fr PS: if I remember there are two other open questions: - should IPv4-compatible connection on the same link use a tunnel or fall back to ND ? - IPv4-compatible DNS entries (AAAA and PTR). ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 08:34:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23814; Sun, 6 Oct 96 08:34:27 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23808; Sun, 6 Oct 96 08:34:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08601; Sun, 6 Oct 1996 08:28:02 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id IAA27234; Sun, 6 Oct 1996 08:27:33 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA28399; Sun, 6 Oct 1996 11:20:12 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13737; Sun, 6 Oct 1996 11:20:07 -0400 Message-Id: <9610061520.AA13737@fwasted.zk3.dec.com> To: Vivek Venkatraman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2180) Re: MIBs for IPng In-Reply-To: Your message of "Sun, 06 Oct 96 03:50:54 EDT." Date: Sun, 06 Oct 96 11:20:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is really important if IPv6 is to be managed? Someone had started IPv6 mibs but I don't think its still in process. I think if not we need the chairs or ADs to do to SNMP Chair or AD and see if this work can get done. In another message we need a list of what else needs to be done and status for IPv6 MIBs and SNMP update is clearly one of them. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 08:56:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23854; Sun, 6 Oct 96 08:56:21 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23841; Sun, 6 Oct 96 08:56:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA09258; Sun, 6 Oct 1996 08:49:48 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id IAA28594; Sun, 6 Oct 1996 08:49:19 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA15890; Sun, 6 Oct 1996 11:41:01 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11971; Sun, 6 Oct 1996 11:41:00 -0400 Message-Id: <9610061541.AA11971@fwasted.zk3.dec.com> To: Vivek Venkatraman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2181) Re: few queries In-Reply-To: Your message of "Sun, 06 Oct 96 04:16:05 EDT." Date: Sun, 06 Oct 96 11:41:00 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >* If an address is configured on a router interface with valid and preferred >lifetimes, are these lifetimes meant only for Router Advertisement or should >the router also run corresponding timers and invalidate the address after >valid lifetime expires ? I believe the intention was for now only RAs. >* If an address prefix is configured to be advertised but the router is >configured to suppress both the A & O bits, should it advertise this prefix ? >If hosts receive such a prefix information what do they do with it ? If the A bit is suppressed then the host won't use the prefix option for autoconfig. The prefix can still be advertised with the L bit to state its an onlink prefix. But with the A and L bit off its saying don't use it for autoconfig and don't use it for onlink, so the value of sending a prefix that way is essentially a NOP spec directitive and will cause the host to just do nothing with the RA option. The O bit simply tells the host to go to stateful addr conf (e.g. DHCPv6) to get other configruation data. >* When a router receives a packet on an interface destined to a subnet-router >anycast address corresponding to some other interface of the router, should it >accept the packet for itself ? I am not sure. I interpret the answer to be yes as its stated that all routers should know where the anycast subnet-router is located. >* What do node-local multicast addresses signify ? If you want to communicate to applications on your node via multicast from an application its possible is one purpose. >* RFC 1933 indicates that a tunnel is to be viewed just like any other data >link for the purposes of Hop Limit and so on. Does this imply that routers >or nodes at either end of the tunnel are to be considered as "on-link" and >>exchange ND and RIP messages between themselves ? No. But you should take this question to ngtrans@sunroof.eng.sun.com. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 09:01:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23889; Sun, 6 Oct 96 09:01:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23883; Sun, 6 Oct 96 09:00:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA09491; Sun, 6 Oct 1996 08:54:40 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id IAA29195; Sun, 6 Oct 1996 08:54:11 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA02553; Sun, 6 Oct 1996 11:45:55 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28017; Sun, 6 Oct 1996 11:45:55 -0400 Message-Id: <9610061545.AA28017@fwasted.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2182) Re: IPv6 PS to DS Status? In-Reply-To: Your message of "Sun, 06 Oct 96 03:39:29 +1000." <17910.844537169@munnari.OZ.AU> Date: Sun, 06 Oct 96 11:45:54 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre, Good point. The last four will be elgible in Mar 97. We can test the waters at San Jose though. How should be keeping/recording any changes we have for the PS specs logistically? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 09:31:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24001; Sun, 6 Oct 96 09:31:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23992; Sun, 6 Oct 96 09:30:50 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA10510; Sun, 6 Oct 1996 09:24:38 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id JAA01477; Sun, 6 Oct 1996 09:24:09 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA01205; Sun, 6 Oct 1996 12:16:51 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17588; Sun, 6 Oct 1996 12:16:51 -0400 Message-Id: <9610061616.AA17588@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2183) IPv6 Other Work in Progress and Needed. Date: Sun, 06 Oct 96 12:16:51 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve and Bob, This is just my guess and vision of how things may be going not including the last 8 I sent our earlier I think a road map of the specs might be a good idea. I was thinking of putting all the related IPv6 work and specs into my Microsoft Project Manager tool and define critical paths that would be defined by market hick-ups and 6bone activity and of course the continued "Internet is Melting Down" messages I see from various places at this time and for various reasons. Specs that will become PS between Jan and June 97 meaning they could be DS by Jan 1998. IPv6 Provider Based Addressing (this is critical) IPv6 over PPP IPv6 over FDDI IPv6 over Token-Ring Mobile IPv6 Header Compression for IPv6 DHCPv6 RIPv6 OSPFv6 IPSEC Update Specs to RFCs and ISAKMP/OAKLEY (in fact I am not sure but the IPSEC specs are PS now so if we get updates by San Jose can they go directly to DS or does the clock restart for the 6 month period - Ran ?? if the community is comfortable with that of course) IPv6 "Basic" and "Advanced" API drafts to Informational RFC and then they will go to IEEE POSIX and WINSOCK Consortia to get really standardized. [Note Richard Steven/Matt Thomas and I are working on getting Advanced Draft out a.s.a.p. for discussion for San Jose and we should have update to Basic API very soon). What we need to get started a.s.a.p. IPv6 SNMP/MIB work IDRPv6 Other Work: Multicast Routing for IPv6 - I think this needs to be talked about it appears it will be PIM sparse and dense mode Dino/Steve ??? Anycast Addresses for Hosts - I think this is important as hosts will need to use this or they will anyway in a proprietary manner. This requires a fix to RFC 1884 to permit anycast addresses used by Hosts. Multihoming - Same here we need to either get some words and rules on this or everyone will do their own thing and figure it out at Sun Connectathon or some other interoperability place where vendors develop defacto standards by trial and error. IMHO there is no changes to other RFCs because of Multihoming needed. Changing Addresses on the Fly and EIDs - So far only a handful of us are discussing not sure where this fits and when needed. Transition I will take that to ngtrans but we need to advance Dimitry/Ross spec to DS. There are other needs that must be worked on we learned from the 6bone too. I am sured I may haved missed some above so folks tell me its Sunday a.m. and got to go rake leaves in New England (and pine needles) so I am in haste I must admit on my node at home. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 6 09:49:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24034; Sun, 6 Oct 96 09:49:19 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24028; Sun, 6 Oct 96 09:49:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA11132; Sun, 6 Oct 1996 09:42:54 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id JAA02899; Sun, 6 Oct 1996 09:42:25 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA15545; Sun, 6 Oct 1996 12:35:19 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA18007; Sun, 6 Oct 1996 12:35:18 -0400 Message-Id: <9610061635.AA18007@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2184) IPv6 Pointers and Education Date: Sun, 06 Oct 96 12:35:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Getting mail from new folks on IPng that want to learn more about where we are etc.. I know we have the archive but thats intense for this mail list. So here are some URLs and books IMHO are useful to anyone doing stuff with IPv6. I have also pulled off of the IETF drafs dir the Abstracts file and built a reduced version of all the specs that I think are related to IPng and its quite large. It includes DNS, RSVP, ATM, etc... If you want that I can send privately and if I get enough requests I will put it up for FTP on a public node. Also Steve Deering has an IPv6 Tutorial but we need more as Steve is only one person. There is an IPv6 Technical Seminar happening via Network World across the U.S. presented by Mark Miller. If you want dates and what city and cost let me know. The dates left now are between Oct 10th and Dec 11th. /jim ------------------------------------------------- Industry IPng WWW Page: http://playground.sun.com/pub/ipng/html/ipng-main.html 6bone WWW Page: http://www-6bone.lbl.gov/6bone/ IETF WWW Page: http://www.ietf.cnri.reston.va.us/home.html IPng Books: IPng: Internet Protocol Next Generation Editors Bradner/Mankin Addison & Wesley Publishers. IPng and the TCP/IP Protocols Implementing the Next Generation Internet Stephen Thomas Wiley Publisher IPv6: The New Internet Protocol Huitema Prentice Hall Routing in the Internet Huitema Prentice Hall You can also view an IPv6 white paper at www.digital.com/info/ipv6/ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 00:20:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24371; Mon, 7 Oct 96 00:20:01 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24365; Mon, 7 Oct 96 00:19:48 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA19275; Mon, 7 Oct 1996 00:13:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA06524; Mon, 7 Oct 1996 00:12:19 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA14197 for ; Mon, 7 Oct 1996 09:12:17 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA29823; Mon, 7 Oct 1996 09:12:17 +0200 Message-Id: <9610070712.AA29823@dxcoms.cern.ch> Subject: (IPng 2185) from Geert Jan To: ipng@sunroof.eng.sun.com Date: Mon, 7 Oct 1996 09:12:16 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Reply-To: ipng@sunroof.eng.sun.com 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 Hi, Forwarded with permission: >--------- Text sent by Geert Jan de Groot follows: To: "Brian Carpenter CERN-CN" From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: (IPng 2166) Re: suggestion (long) Date: Sun, 06 Oct 1996 01:06:04 +0300 Brian, As I'm on travel, bandwith is low and I'm too busy and will take a week vacation after that (I'll resurface when I get on top of my mailbox after oct 20), I can't join the public discussion at this point. However, I wrote down my thoughts some time ago and attach them for your amusement. Feel free to forward them to the list, just realize that I can't respond to responses.. Geert Jan --- Thoughts on IPv6 address space assignment. This is a response to IANA's request for comments on the imminent publication of draft-ietf-ipngwg-unicast-addr-fmt-04.txt as an RFC. I'd like to review what we currently have, what the goals should be, and what is missing. Then, I'd like to do some suggestions how to proceed from here and bring up some open issues. 1. What do we have? Currently, a few experimental IPv6 stacks exist. Interoperability has been tested amd (mostly) works. A few applications (such as telnet, tftp, http) are operational. Assignment of an IPv6 address is simplified because the subscriber suffix is commonly built from the MAC address of a host, and the router prefix can be learned from Router Announcements. Note that these mechanisms are aimed at hosts, not routers. As far as routing mechanisms go, I think that initially very similar mechanisms will be utilized. This includes global visability of Autonomous Systems: as with IPv4, automatic proxy aggregation is not available and thus will each prefix be announced on the global Internet. 2. Lessons learned from IPv4 2a. Assignment efficiency Assignment efficiency is very important to plan the lifetime of an address space. In the case of IPv4, it is worth pointing out that despite the fact that more than half of the IPv4 space is occupied (1-57, 128-173, 192-208), the total amount of Internet hosts would probably fit in one class-A prefix. It doesn't make sense to claim to have a nearly infinite amount of address space if the assignment efficiency is infinitely low. This means that a goal for the efficiency must be set. 2b. Reservation It is my experience that reservation of address space for future expansion, with the aim to reduce the need for additional prefixes which cannot be aggregated, does not work very well By reserving too much, much address space is lost (this 'killed' the B's and the A's). By reserving too little, an additional prefix will be needed, negating the benefit of reservations in the first place. Because of this, I think that it doesn't make much sense to allow for reservations of address space. 2c. Topology changes might result in a need to renumber. Current router paradigm suggests that the number of prefixes on the net should be minimized. Preferably, there should be only one prefix per Autonomous System. This suggests that changes in the topology might result in a need to renumber. This is one of the reasons to put easy, (preferably automatic), renumbering in the IPng spec. 3. The UAFORMAT draft The UAFORMAT draft provides a framework of how IPv6 addresses should be assigned. The 128 bits are split up as follows: 3 Fixed 5 RegistryID n ProviderID 56-n SubscriberID 64 Intra-Subscriber This means that the size of a subscriber assignment is fixed. The value of n decides how many subscribers can be allocated under one provider prefix. One of the questions is, how large n should be, and how this value should be derived. Note that under the current routing paradigms, the mechanism above does not work too well for multihomed sites (see below) 4. Goals The _assignment_ (ISP->subscriber) assignment mechanism is obvious (but see below). As far as allocations (registry->ISP) go, I think that we should aim at the following goals for IPv6 allocations: a. Minimal number of prefixes, preferrably only one per autonomous system b. Assignment of ProviderID prefixes based on objective grounds (hopefully we can put the 'registry black magic' to rest) c. Efficiency; minimal number of reservations d. Fairness; the resource is enormous but limited 5. Proposal At least two out of three regional registries have well established, objective mechanisms to decide who a registry is. It is possible to allocate an arbitrary-sized prefix to each registry, but this is not objective, not efficient and probably not fair. Another approach is to allocate a very long prefix to the registry, and replacing it with a shorter one should the old prefix run out. Assume that initial, N=52; this allows 16 subscribers. Should this prefix run out, then a new prefix of N=51 will be assigned, and the old prefix phased out and returned to the registry (IPng specifies easy renumbering). The time to phase out the old prefix is TBD; I suggest 3 months. Given that prefixes can be easily changed, I suggest to start the providerID at 0 and simply assign sequentially. The prefix-swapping mechanism should allow for growth and limit the entropy left in the routing system because of topology changes. 6. What we don't have Unfortunately, the work of IPv6 isn't finished, and some of the defiencies aren't even currently addressed. While easy renumbering of hosts is currently feasible, renumbering a subscriber as a whole is much more complicated because: - There is no mechanism for automatic dissemination of (new) prefixes between routers of the same Autonomous System. Should the Autonomous System need to renumber, then currently each router must be reconfigured by hand (I have some rough ideas how to address this issue, but lack the time to work on this) - No easy renumbering support for 'upper layers': applications still use numbers in configuration files. Note that the PIER WG currently aims at IPv4 renumbering, and doesn't provide mechanisms to avoid the difficulties of renumbering in the first place. I think that these issues should be brought up in the appropiate forums, as the IPv6 work isn't complete without. (and we're already building legacy IPv6 machines..) One can argue that we should simply waive this problem and make a workaround using reservations. I don't think this will work. The resulting, permanent entropy that will result from such a system after a while will probably be prohibitive and cause the same problems the current IPv4 routing system has. 7. Mechanics To the best of my knowledge, none of the registries is currently tooled up to handle assignments/allocations of IPv6 prefixes on a large scale. The new version of the RIPE-database has rudimentary support for IPv6 addresses, but that is probably not sufficient. 8. Open issues There are a number of open issues that need to be decided: a. Which entities are entitled to apply for a subscriber prefix? Company? Subsidiary? Building? Floor? (Note that we have had quite some cases already where it was perceived easier to apply for a new prefix at a registry, than to obtain a chunk from an older allocation to the same company. Since each assignment is big enough to hold the size of any network we currently know of, it may be a good idea to add some wording that new prefixes will only be assigned if the new prefix has a different routing policy than the existing one (is this a wise idea?) b. I think we should add some wording that in the case of very large, similar network (cable-TV boxes?), one should aim at a reasonable efficiency (10%?) before new prefixes are assigned (this to avoid the one-prefix-for-every-village problem). c. How long should the grandfathering period on old prefixes be? d. Another open issue is multihomed subscribers. Given the global visibility of these prefixes, should they be assigned by the regional registry directly or from the aggregate-block of one of the provider-registries? 9. 'Real' addresses vs RFC1897 address space I was surprized to learn that Jim Bound was serious about asking for 'real' address space. I think that assignment at this time isn't appropiate yet. Jim argues that he wants to have 'real' addresses to avoid future renumbering. I don't think that argument is valid; see above. As things currently stand, people who want 'real' addresses now will need to renumber for aggregation reasons anyway. As there is no fixed timelimit on RFC1897 addresses, I don't see the gain of assigning IPv6 addresses at this time. Jim's customers have to renumber anyway, whether that's from RFC1897-space to an aggregate or from a 'real' address to an aggregate doesn't make a difference. Geert Jan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 00:24:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24387; Mon, 7 Oct 96 00:24:31 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24381; Mon, 7 Oct 96 00:24:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA19799; Mon, 7 Oct 1996 00:18:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA07248; Mon, 7 Oct 1996 00:17:35 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA14977; Mon, 7 Oct 1996 09:16:03 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA21253; Mon, 7 Oct 1996 09:15:59 +0200 Message-Id: <9610070715.AA21253@dxcoms.cern.ch> Subject: (IPng 2186) Re: suggestion (long) (replay) To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 7 Oct 1996 09:15:59 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199610060534.OAA02789@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Oct 6, 96 02:33:45 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 Masataka, > > Does the end point identifier globally identifies: > > 1) a host, that is, an end system > > 2) an interface of a host > > or > > 3) an transport layer end points such as an end of an > individual TCP connection > In my mind, 3) is essential to allow for rehoming of transactions within an anycast server group. I think that is implied by my proposal. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 05:03:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24700; Mon, 7 Oct 96 05:03:47 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24694; Mon, 7 Oct 96 05:03:34 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA00824; Mon, 7 Oct 1996 04:57:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA24115; Mon, 7 Oct 1996 04:56:50 -0700 Received: (from tera@localhost) by tera.csl.sony.co.jp (8.6.12+2.4W/3.3W3) id UAA23396; Mon, 7 Oct 1996 20:56:18 +0900 Message-Id: <199610071156.UAA23396@tera.csl.sony.co.jp> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2187) Re: suggestion (long) (replay) In-Reply-To: Your message of "Fri, 04 Oct 96 10:24:13 +0200." <9610040824.AA16858@dxcoms.cern.ch> Date: Mon, 07 Oct 96 20:56:18 +0900 From: TERAOKA Fumio Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:24 96/10/04 +0200, Brian Carpenter CERN-CN wrote: > Transport and security mechanisms require end point identifiers which > are guaranteed not to change when dynamic renumbering takes place. > Such identifiers may also be needed when the host concerned is a member > of an anycast group, or when communication flows through a network > address translator, or when the host's apparent IP address is liable > to change for any other reason. > > Approaches to this issue have been suggested in > draft-bound-ipv6-ip-addr-00.txt, draft-bound-anycast-00.txt, and > draft-huitema-multi-homed-01.txt [expired]. The underlying issues are > discussed in those drafts and are not repeated here. The present > [fragment of a] draft proposes an intentionally simplistic solution. I would like to add draft-teraoka-ipv6-mobility-sup-03.txt to the list. This memo introduces source and destination ID options as IPv6 destination options to originally support mobility in IPv6. The same mechanism is applied to mobility support in IPv4 (draft-teraoka-mobileip-vip-01.txt[expired]). In IPv4 mobility, authentic firewall traversal is also achieved by using the source node identifier, as described in my talk in a mobileip session at the Montreal IETF. > The EID destination option is illustrated below. It has no > alignment requirement. Its length is chosen such that if it > is the only destination option present, the entire destination > options header will be 16 octets. There are two approaches in how to create EID: EID includes location information, or not. In my approach in IPv4 and IPv6, EID has the same format of the IP address. The relation between EID and IP address is analogous to that between the logical address and the physical address of virtual memory system in operating systems. This approach has some advantages: 1) EID assignment is easy, 2) TCP/UDP can use EIDs and IP addresses interchangeably, etc. Fumio TERAOKA (SonyCSL) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 05:35:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24768; Mon, 7 Oct 96 05:35:40 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24762; Mon, 7 Oct 96 05:35:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA02337; Mon, 7 Oct 1996 05:29:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA29404; Mon, 7 Oct 1996 05:28:42 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id OAA24351 for ; Mon, 7 Oct 1996 14:28:41 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA24594; Mon, 7 Oct 1996 14:28:40 +0200 Message-Id: <9610071228.AA24594@dxcoms.cern.ch> Subject: (IPng 2188) Re: suggestion (long) (replay) To: tera@csl.sony.co.jp (TERAOKA Fumio) Date: Mon, 7 Oct 1996 14:27:07 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199610071156.UAA23396@tera.csl.sony.co.jp> from "TERAOKA Fumio" at Oct 7, 96 08:56:18 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 Fumio, .. > I would like to add draft-teraoka-ipv6-mobility-sup-03.txt to > the list. This memo introduces source and destination ID options > as IPv6 destination options to originally support mobility in IPv6. > > The same mechanism is applied to mobility support in IPv4 > (draft-teraoka-mobileip-vip-01.txt[expired]). In IPv4 mobility, Sorry I missed your drafts. It's hard to keep track of everything. It's clearly desirable to find a single mechanism that covers renumbering, rehoming, and mobility. > There are two approaches in how to create EID: EID includes location > information, or not. In my approach in IPv4 and IPv6, EID has the > same format of the IP address. The relation between EID and IP address > is analogous to that between the logical address and the physical > address of virtual memory system in operating systems. This approach > has some advantages: 1) EID assignment is easy, 2) TCP/UDP can use > EIDs and IP addresses interchangeably, etc. Yes. I hesitated a lot between making the EID in the format of an address or making it shorter to have a chance of good alignment. However, I don't agree that making it the same format makes assignment easy - EID's are *not* addresses, so their assignment will not follow automatically from address assignment. Obviously, if we choose 16 byte EIDs, the option formats defined for mobility are the ones to use. In fact, in that case I would suggest allocating an RFC 1884 format prefix for EIDs, so that an EID and a locator would be syntactically distinct. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 07:33:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24849; Mon, 7 Oct 96 07:33:50 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24843; Mon, 7 Oct 96 07:33:38 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA10467; Mon, 7 Oct 1996 07:27:25 -0700 From: bmanning@ISI.EDU Received: by mercury.Sun.COM (Sun.COM) id HAA26670; Mon, 7 Oct 1996 07:26:54 -0700 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 7 Oct 1996 07:26:53 -0700 Posted-Date: Mon, 7 Oct 1996 07:26:35 -0700 (PDT) Message-Id: <199610071426.AA14167@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Mon, 7 Oct 1996 07:26:35 -0700 Subject: (IPng 2189) Re: IPv6 Other Work in Progress and Needed. To: bound@zk3.dec.com Date: Mon, 7 Oct 1996 07:26:35 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610061616.AA17588@fwasted.zk3.dec.com> from "bound@zk3.dec.com" at Oct 6, 96 12:16:51 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 > Multihoming - Same here we need to either get some words and rules > on this or everyone will do their own thing and figure it out at > Sun Connectathon or some other interoperability place where vendors > develop defacto standards by trial and error. IMHO there is no > changes to other RFCs because of Multihoming needed. > > Changing Addresses on the Fly and EIDs - So far only a handful of > us are discussing not sure where this fits and when needed. A couple of other folks here have been talking about this very idea. It seems that this topic is going to be brought up in a new wg hosted in the transport area. Its clear to me that the IPv6 efforts should be targeted on how to renumber end-nodes and let the transport folks worry about retaining session identity across topology renumbering. But that is just my thought. -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 07:49:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24865; Mon, 7 Oct 96 07:49:22 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24859; Mon, 7 Oct 96 07:49:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA12185; Mon, 7 Oct 1996 07:42:57 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id HAA01987; Mon, 7 Oct 1996 07:42:26 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA31187; Mon, 7 Oct 1996 10:26:06 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21521; Mon, 7 Oct 1996 10:25:57 -0400 Message-Id: <9610071425.AA21521@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2190) Re: suggestion (long) (replay) In-Reply-To: Your message of "Mon, 07 Oct 96 09:15:59 +0200." <9610070715.AA21253@dxcoms.cern.ch> Date: Mon, 07 Oct 96 10:25:57 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> 3) an transport layer end points such as an end of an >> individual TCP connection >> >In my mind, 3) is essential to allow for rehoming of >transactions within an anycast server group. I think that >is implied by my proposal. Just to determine if we agree on the abstractions. Changing addresses on the fly is one problem. Rehoming is completely another which entails migrating the transaction to a completely different anycast machine. In rehoming your not saying the client of the anycast server group should be able to switch to another client? If so we have three paradigms to discuss. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 08:00:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24892; Mon, 7 Oct 96 08:00:29 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24886; Mon, 7 Oct 96 08:00:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA13578; Mon, 7 Oct 1996 07:54:03 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id HAA06282; Mon, 7 Oct 1996 07:53:33 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA07586; Mon, 7 Oct 1996 10:44:43 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23599; Mon, 7 Oct 1996 10:44:42 -0400 Message-Id: <9610071444.AA23599@fwasted.zk3.dec.com> To: Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2191) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Mon, 07 Oct 96 07:26:35 PDT." <199610071426.AA14167@zed.isi.edu> Date: Mon, 07 Oct 96 10:44:34 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This sounds good.... Let me be very very very direct and ask a question: Does anyone on this list believe that IPv6 can not go to full standard status or be deployed widely without completing the answer to the variant EID problems? No response means either you don't care or that it is work that is needed but we need to get IPv6 what we have done. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 08:20:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24932; Mon, 7 Oct 96 08:20:10 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24926; Mon, 7 Oct 96 08:19:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA16467; Mon, 7 Oct 1996 08:13:38 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA13459; Mon, 7 Oct 1996 08:13:00 -0700 Received: from gungnir.fnal.gov ("port 34613"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IACW4P8URU002ZLD@FNAL.FNAL.GOV>; Mon, 07 Oct 1996 10:12:38 -0600 (CST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id KAA20370; Mon, 07 Oct 1996 10:12:29 -0500 Date: Mon, 07 Oct 1996 10:12:29 -0500 From: Matt Crawford Subject: (IPng 2192) Re: IPv6 PS to DS Status? In-Reply-To: "05 Oct 1996 13:10:44 EDT." <"9610051710.AA25561"@fwasted.zk3.dec.com> To: bound@zk3.dec.com Cc: deering@parc.xerox.com, hinden@ipsilon.com, ipng@sunroof.eng.sun.com Message-Id: <199610071512.KAA20370@gungnir.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Steve and Bob, > Are we ready to move: > RFC 1883 Base Spec [...] > to Draft-Standard status[?]. Shouldn't we make some determination on the fate of the priority field first? (Or did I blink?) Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 08:46:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24980; Mon, 7 Oct 96 08:46:24 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24974; Mon, 7 Oct 96 08:46:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA20631; Mon, 7 Oct 1996 08:39:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA23918; Mon, 7 Oct 1996 08:39:23 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA13147; Tue, 8 Oct 1996 01:36:21 +1000 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: bmanning@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 2193) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Mon, 07 Oct 1996 10:44:34 -0400." <9610071444.AA23599@fwasted.zk3.dec.com> Date: Tue, 08 Oct 1996 01:36:17 +1000 Message-Id: <18510.844702577@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 07 Oct 96 10:44:34 -0400 From: bound@zk3.dec.com Message-ID: <9610071444.AA23599@fwasted.zk3.dec.com> Does anyone on this list believe that IPv6 can not go to full standard status or be deployed widely without completing the answer to the variant EID problems? Whatever is done with EIDs, or the problems that lead to the demand for them is now looking like being done at a layer above the IP layer - so the most that is likely to be needed of IPv6 is an end to end option, and they're clearly intended to be defined as needed. So, from a technical viewpoint, no. However, something has to be done to solve the problems before implementations are shipped in any volume. Whether this is some change to TCP, or something else is still to be decided, but shipping the TCP that works over IPv4, to simply work with no change more than the pseudo-header checksum is simply inadequate. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 08:48:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24996; Mon, 7 Oct 96 08:48:17 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24990; Mon, 7 Oct 96 08:48:03 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA21061; Mon, 7 Oct 1996 08:41:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA24767; Mon, 7 Oct 1996 08:41:12 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA19111; Mon, 7 Oct 1996 17:41:07 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA31522; Mon, 7 Oct 1996 17:41:06 +0200 Message-Id: <9610071541.AA31522@dxcoms.cern.ch> Subject: (IPng 2194) Re: suggestion (long) (replay) To: bound@zk3.dec.com Date: Mon, 7 Oct 1996 17:41:06 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610071425.AA21521@fwasted.zk3.dec.com> from "bound@zk3.dec.com" at Oct 7, 96 10:25:57 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > Brian, > > >> 3) an transport layer end points such as an end of an > >> individual TCP connection > >> > >In my mind, 3) is essential to allow for rehoming of > >transactions within an anycast server group. I think that > >is implied by my proposal. > > Just to determine if we agree on the abstractions. > > Changing addresses on the fly is one problem. > > Rehoming is completely another which entails migrating the transaction > to a completely different anycast machine. Absolutely. However, to the remote client they look much the same I think: the server's address has changed. > > In rehoming your not saying the client of the anycast server group > should be able to switch to another client? If so we have three > paradigms to discuss. > I don't think so. I can't see a scenario where that makes any sense. (No doubt somebody will now invent one :-) Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 08:58:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25016; Mon, 7 Oct 96 08:58:25 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25010; Mon, 7 Oct 96 08:58:12 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23063; Mon, 7 Oct 1996 08:51:58 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA29115; Mon, 7 Oct 1996 08:50:43 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA22223; Mon, 7 Oct 1996 17:49:45 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA05266; Mon, 7 Oct 1996 17:49:35 +0200 Message-Id: <9610071549.AA05266@dxcoms.cern.ch> Subject: (IPng 2195) Re: suggestion (long) (replay) To: charliep@watson.ibm.com (Charlie Perkins) Date: Mon, 7 Oct 1996 17:49:35 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, tera@csl.sony.co.jp In-Reply-To: <9610071404.AA35643@hawpub1.watson.ibm.com> from "Charlie Perkins" at Oct 7, 96 10:04:40 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, as usual you make a lot of sense... > > > Obviously, if we choose 16 byte EIDs, the option formats > > defined for mobility are the ones to use. In fact, in that case > > I would suggest allocating an RFC 1884 format prefix for EIDs, > > so that an EID and a locator would be syntactically distinct. > > Doing so, however, means that we can't use the "home addresses" > effectively as EIDs. While I agree with those who point out that > identifiers and locators are distinct concepts, I think even so > that there are advantages to being able to distinguish one address > to serve as identifier even when it _can_ also serve as a locator. > The question is whether home addresses will be stable enough to act as EIDs. What happens if your home network is renumbered (maybe even changing providers) while you are far away with your mobile? However, that's why I suggested an EID format prefix. Whether the thing you use as an identifier is actually a (home) address or an EID is then transparent to the way you use it. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 08:59:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25028; Mon, 7 Oct 96 08:59:54 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25022; Mon, 7 Oct 96 08:59:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23408; Mon, 7 Oct 1996 08:53:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA29753; Mon, 7 Oct 1996 08:52:18 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA17487; Mon, 7 Oct 1996 17:52:01 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA25960; Mon, 7 Oct 1996 17:52:00 +0200 Message-Id: <9610071552.AA25960@dxcoms.cern.ch> Subject: (IPng 2196) Re: IPv6 Other Work in Progress and Needed. To: bmanning@ISI.EDU Date: Mon, 7 Oct 1996 17:52:00 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <199610071426.AA14167@zed.isi.edu> from "bmanning@ISI.EDU" at Oct 7, 96 07:26:35 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, > > Changing Addresses on the Fly and EIDs - So far only a handful of > > us are discussing not sure where this fits and when needed. > > A couple of other folks here have been talking about this very idea. > It seems that this topic is going to be brought up in a new wg > hosted in the transport area. Its clear to me that the IPv6 > efforts should be targeted on how to renumber end-nodes and let > the transport folks worry about retaining session identity across > topology renumbering. But that is just my thought. > I wish it was that simple. IP Sec also needs identifiers. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 09:10:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25074; Mon, 7 Oct 96 09:10:02 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25068; Mon, 7 Oct 96 09:09:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25658; Mon, 7 Oct 1996 09:03:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA04373; Mon, 7 Oct 1996 09:02:56 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id SAA21944; Mon, 7 Oct 1996 18:02:46 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA06486; Mon, 7 Oct 1996 18:02:46 +0200 Message-Id: <9610071602.AA06486@dxcoms.cern.ch> Subject: (IPng 2197) Re: IPv6 Other Work in Progress and Needed. To: bound@zk3.dec.com Date: Mon, 7 Oct 1996 18:02:45 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610071444.AA23599@fwasted.zk3.dec.com> from "bound@zk3.dec.com" at Oct 7, 96 10:44:34 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > > Does anyone on this list believe that IPv6 can not go to full standard > status or be deployed widely without completing the answer to the > variant EID problems? > I think it's slightly more subtle - we should be certain before we go to full standard that IPv6 *does not disallow* a solution, i.e. we need an existence proof of a solution. I doubt if this is far away, looking at the discussion. - the market decides about deployment. However, having seen how hard it was to get MTU Size Discovery or DHCP into all vendor's IPv4 stacks, I'm slightly nervous about wide deployment. How's that for answering "maybe"? Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 09:50:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25153; Mon, 7 Oct 96 09:50:31 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25147; Mon, 7 Oct 96 09:50:17 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA06236; Mon, 7 Oct 1996 09:43:59 -0700 From: bmanning@ISI.EDU Received: by mercury.Sun.COM (Sun.COM) id JAA21992; Mon, 7 Oct 1996 09:43:29 -0700 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 7 Oct 1996 09:43:28 -0700 Posted-Date: Mon, 7 Oct 1996 09:43:09 -0700 (PDT) Message-Id: <199610071643.AA14429@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Mon, 7 Oct 1996 09:43:10 -0700 Subject: (IPng 2198) Re: IPv6 Other Work in Progress and Needed. To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Mon, 7 Oct 1996 09:43:09 -0700 (PDT) Cc: bmanning@ISI.EDU, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <9610071552.AA25960@dxcoms.cern.ch> from "Brian Carpenter CERN-CN" at Oct 7, 96 05:52:00 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 > > Bill, > > > > Changing Addresses on the Fly and EIDs - So far only a handful of > > > us are discussing not sure where this fits and when needed. > > > > A couple of other folks here have been talking about this very idea. > > It seems that this topic is going to be brought up in a new wg > > hosted in the transport area. Its clear to me that the IPv6 > > efforts should be targeted on how to renumber end-nodes and let > > the transport folks worry about retaining session identity across > > topology renumbering. But that is just my thought. > > > I wish it was that simple. IP Sec also needs identifiers. > > Brian Why should they be the same? -- --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 10:01:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25198; Mon, 7 Oct 96 10:01:33 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA22230; Fri, 4 Oct 96 01:56:24 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA17056; Fri, 4 Oct 1996 01:50:16 -0700 From: senthilvn@future.futsoft.com Received: by mercury.Sun.COM (Sun.COM) id BAA26692; Fri, 4 Oct 1996 01:49:33 -0700 Received: from kailash.future.futsoft.com (38.242.192.4) by fsnt.future.futsoft.com (Integralis SMTPRS 1.4) with SMTP id ; Fri, 04 Oct 1996 14:22:16 +0530 Received: from calcutta.future.futsoft.com (calcutta.future.futsoft.com [10.0.4.8]) by kailash.future.futsoft.com (8.7.1/8.7.1) with ESMTP id DAA12206 for ; Fri, 4 Oct 1996 03:10:05 -0400 Received: (from senthilvn@localhost) by calcutta.future.futsoft.com (8.6.11/8.6.9) id OAA00208; Fri, 4 Oct 1996 14:18:10 -0400 Date: Fri, 4 Oct 1996 14:18:09 -0400 (EDT) To: ipng@sunroof.eng.sun.com Subject: (IPng 2199) Please Clarify.. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk << Future Software Confidential mail >> Email back to : email: vivekv@future.futsoft.com, senthilvn@future.futsoft.com Hallo, I am working on a router implementation of IPV6 and would appreciate inputs on the following queries: * If an address is configured on a router interface with valid and preferred lifetimes, are these lifetimes meant only for Router Advertisement or should the router also run corresponding timers and invalidate the address after valid lifetime expires ? * If an address prefix is configured to be advertised but the router is configured to suppress both the A & O bits, should it advertise this prefix ? If hosts receive such a prefix information what do they do with it ? * When a router receives a packet on an interface destined to a subnet-router anycast address corresponding to some other interface of the router, should it accept the packet for itself ? * What do node-local multicast addresses signify ? * RFC 1933 indicates that a tunnel is to be viewed just like any other data link for the purposes of Hop Limit and so on. Does this imply that routers or nodes at either end of the tunnel are to be considered as "on-link" and exchange ND and RIP messages between themselves ? thanks Vivek -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Venkatraman Future Software Private Ltd, No. 481, Mount Road, Nandanam, Madras - 600035, INDIA Phone: 91-44-4342166/4340323/4330589 Ext:250/251/252 email: vivekv@future.futsoft.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From owner-ipng@sunroof.eng.sun.com Sat Oct 5 08:23:42 1996 Return-Path: Received: from sunroof.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA12823; Sat, 5 Oct 1996 08:23:42 -0700 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22825; Sat, 5 Oct 96 08:29:49 PDT Date: Sat, 5 Oct 96 08:29:49 PDT Message-Id: <9610051529.AA22825@sunroof.eng.sun.com> To: owner-ipng@sunroof.eng.sun.com From: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Non-member submission from ["narayanasamy senthil vadivu" ] Content-Length: 1330 X-Lines: 33 Status: RO From senvad@hotmail.com Sat Oct 5 08:29:31 1996 Return-Path: Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA22819; Sat, 5 Oct 96 08:29:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15772; Sat, 5 Oct 1996 08:23:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA25203; Sat, 5 Oct 1996 08:22:51 -0700 Received: from constitution.hotmail.com by constitution.hotmail.com id <768392(24)>; Sat, 5 Oct 1996 08:22:44 -0700 Received: from 206.86.127.204 by www.hotmail.com with HTTP; Sat, 05 Oct 1996 08:22:43 PDT From: "narayanasamy senthil vadivu" To: ipng@sunroof.eng.sun.com Cc: kaushikb@future.futsoft.com Subject: Availability of MIBs for IPng Content-Type: text/plain Message-Id: <96Oct5.082244pdt.768392(24)@constitution.hotmail.com> Date: Sat, 5 Oct 1996 08:22:44 -0700 Hallo, I am working on an IPng router development project and would like to know if new MIBs have been defined or existing MIBs extended for the various IPng protocols. Please copy your responses to the address listed in the "Cc:" also. thanks Kaushik --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 10:24:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25243; Mon, 7 Oct 96 10:24:31 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA23545; Sat, 5 Oct 96 21:04:05 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA19667; Sat, 5 Oct 1996 20:57:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA23621; Sat, 5 Oct 1996 20:57:24 -0700 Received: by rodan.UU.NET id QQbkex25043; Sat, 5 Oct 1996 23:57:23 -0400 (EDT) Date: Sat, 5 Oct 1996 23:57:23 -0400 (EDT) From: mo@UU.NET (Mike O'Dell) Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 2200) 8+8... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk imagine that. i have a draft that i'm finishing up which details an 8+8 proposal.... -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 10:30:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25255; Mon, 7 Oct 96 10:30:30 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24077; Sun, 6 Oct 96 10:15:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA12118; Sun, 6 Oct 1996 10:08:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA04726; Sun, 6 Oct 1996 10:08:24 -0700 Received: by mail.noris.net id <35143-23695>; Sun, 6 Oct 1996 19:08:19 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2201) Re: suggestion (long) Date: 6 Oct 1996 19:08:09 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 47 Message-Id: <538p1p$i3r@work.smurf.noris.de> References: <9610031540.AA30645@dxcoms.cern.ch> <199610060327.MAA02475@necom830.hpcl.titech.ac.jp> <844573431.25946@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: unlisted-recipients:;@mercury (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In dist.ipng, article <844573431.25946@noris.de>, Masataka Ohta writes: > > We need world wide unique ID. Moreover, optional EID field is not > so good because we must have a mechanism (like in-addr.arpa) to > maintain the uniqueness of the EID IN ADDITION TO that for IPv6 > addresses. Too much redundant work. Right. In fact, you can take this further: We already _have_ a unique 'EID'. It's commonly called "IPv6 address". Systems just need to grab one of their IP addresses as "the" address which they use as 'EID' for the purpose of reassigning the destination of a connection. For mobile systems, for instance, it's their home address. For hosts with anycast addresses, it's the "normal" address on the interface the anycast arrives on. Or whatever, as long as it belongs to that host only. I see no need for a separate EID and another management body to assign them. (Ethernet hardware addresses already are reported not to be as unique as we all think they should be.) > Why don't we make lower 8 octets of Ipv6 address world-wide unique? > It's doable as routing hierarchy does not have to and should not > be encoded within that part of the address. > But we can't depend on everybody being assigned such an ID. What about all the people with PPP-only connections? Run MD5 over the home phone number and use that as EID? > With a new link layer technology, IEEE 1394, world wide > unique link layer ID is 8, NOT 6, octets long. This may not > be a immediate problem for IPv6, as IEEE 1394 has a short-term > 2 byte link-unique ID. > IMHO, this is a separate issue. -- Recollect: To recall with additions something not previously known. -- Ambrose Bierce, "The Devil's Dictionary" -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 10:46:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25309; Mon, 7 Oct 96 10:46:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA24829; Mon, 7 Oct 96 07:11:45 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA08440; Mon, 7 Oct 1996 07:05:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA20745; Mon, 7 Oct 1996 07:05:02 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id KAA12454; Mon, 7 Oct 1996 10:04:56 -0400 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/10-03-96) with SMTP id KAA463321; Mon, 7 Oct 1996 10:04:49 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA35643; Mon, 7 Oct 1996 10:04:41 -0400 From: Charlie Perkins Message-Id: <9610071404.AA35643@hawpub1.watson.ibm.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, tera@csl.sony.co.jp (TERAOKA Fumio) Subject: (IPng 2202) Re: suggestion (long) (replay) In-Reply-To: Your message of Mon, 07 Oct 96 14:27:07 O. <9610071228.AA24594@dxcoms.cern.ch> Date: Mon, 07 Oct 96 10:04:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> == Teraoka-san > == Brian >> I would like to add draft-teraoka-ipv6-mobility-sup-03.txt to >> the list. This memo introduces source and destination ID options >> as IPv6 destination options to originally support mobility in IPv6. >> >> The same mechanism is applied to mobility support in IPv4 >> (draft-teraoka-mobileip-vip-01.txt[expired]). In IPv4 mobility, > > Sorry I missed your drafts. It's hard to keep track of everything. > It's clearly desirable to find a single mechanism that > covers renumbering, rehoming, and mobility. Brian, while I agree with your last sentence, I don't think that the Source Address option can measure up to the task. The methods outlined in Teraoka-san's draft require far more overhead than what we have proposed in our Binding Update option. These issues have been discussed at length (multiple times) in the mobile-IP working group meetings. Without going back to find my previous notes, I should just mention that the source option needs to be sent in many, many more normal data packets than our Binding Update, and each one needs to be authenticated. In fact, in Teraoka-san's proposal as he presented it, I think that _every_ data packet needed authentication, but we determined that somewhat weaker (but still onerous) conditions could still guarantee correctness. There are other serious differences also at issue. Although I think that we should go ahead with the mobility draft as soon as possible, I also am willing to enlarge the scope of the Binding Update to handle other requirements if needed. I think that we already do a reasonable job to help with renumbering. On that issue, it would be helpful if the working group would decide whether or not it's legal to expect TCP (and other higher-level protocols) to fiddle around with their internal data structures in response to a renumbering (e.g, Binding Update) message. For anycast, the first thing to do is to find out whether generic (non-router) IPv6 nodes can respond to anycast addresses. For some of the multihoming problems, the Binding Update seems perfect, but I need to study Shand's existing draft to be sure. >> There are two approaches in how to create EID: EID includes location >> information, or not. I think it is almost necessarily a mistake to include location information in any sort of endpoint identification. To do so amounts to a statement that a _particular_ endpoint is tied to a _particular_ location, doesn't it? >> In my approach in IPv4 and IPv6, EID has the >> same format of the IP address. I think it would be a step forward in any future EID discussions if proponents (such as myself) would make this basic agreement. >> The relation between EID and IP address >> is analogous to that between the logical address and the physical >> address of virtual memory system in operating systems. I think this statement is true _only_ insofar as introducing and managing a level of indirection is valuable for solving both problems. Concepts of working set, page size, inverted lookup tables, and almost every other characteristic of virtual memory do not seem to apply. Cache management, on the other hand, is one area where interesting parallels may be drawn -- but it's not as closely tied to virtual memory. >> This approach >> has some advantages: 1) EID assignment is easy, 2) TCP/UDP can use >> EIDs and IP addresses interchangeably, etc. This statement seems to be applicable to the point about using IPv6 addresses as EIDs, not to the point about virtual memory. > Obviously, if we choose 16 byte EIDs, the option formats > defined for mobility are the ones to use. In fact, in that case > I would suggest allocating an RFC 1884 format prefix for EIDs, > so that an EID and a locator would be syntactically distinct. Doing so, however, means that we can't use the "home addresses" effectively as EIDs. While I agree with those who point out that identifiers and locators are distinct concepts, I think even so that there are advantages to being able to distinguish one address to serve as identifier even when it _can_ also serve as a locator. >> Fumio TERAOKA (SonyCSL) > Brian Carpenter Charles E. Perkins ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 11:03:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25459; Mon, 7 Oct 96 11:03:29 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25211; Mon, 7 Oct 96 10:08:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA11590; Mon, 7 Oct 1996 10:01:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA29584; Mon, 7 Oct 1996 10:00:42 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id NAA17196; Mon, 7 Oct 1996 13:00:31 -0400 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/10-03-96) with SMTP id NAA240853; Mon, 7 Oct 1996 13:00:28 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA63362; Mon, 7 Oct 1996 13:00:27 -0400 From: Charlie Perkins Message-Id: <9610071700.AA63362@hawpub1.watson.ibm.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2203) Re: suggestion (long) (replay) In-Reply-To: Your message of Mon, 07 Oct 96 17:49:35 O. <9610071549.AA05266@dxcoms.cern.ch> Date: Mon, 07 Oct 96 13:00:26 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for your kind words! > The question is whether home addresses will be stable enough to act > as EIDs. > > What happens if your home network is renumbered (maybe even > changing providers) while you are far away with your mobile? This is a concern. Here's an idea that might go some ways towards a solution. Suppose, indeed, that each node is numbered with an EID chosen from a reserved part of the IPv6 address space as you suggest. The first problem, then, is to get a (globally routeable) IPv6 address (to be used as a "locator"). That _could_ be done as follows: 1) Do neighbor discovery. 2) Negotiate with a router to get "home agent" service. 3) (?)Make the home agent aware of the EID.(?) 4) When necessary, renumber as needed by way of the renumbering algorithms outlined in the Neighbor Discovery RFC and our mobility draft. This procedure should be made idempotent, so that it would work over and over again with the same results even if the node never moves. In our scheme, as a mobile node moves from one point of attachment to another, it notifies its correspondent nodes about its new care-of address (new globally routeable locator address). So far, so good. Even if the node is renumbered without its knowledge (e.g, it was turned off while renumbering occurred), it can still manage communications with all of its correspondent nodes, as long as it initiates those communications. Nevertheless what should a (mobile) node do after it gets stranded in this way? It can: 1) Get service from a new "home agent". 2) Send Binding Updates to all existing correspondents. 3) Try for a while to relinquish the service from its previous home agent. If the new home agent is the same as the previous home agent, so much the better -- step (3) is unnecessary. Several things can go wrong -- but, this scheme is more robust than our previous scheme. We can make it somewhat more robust even, if we engineer a method by which a mobile node finds out about its newly-engaged home agent's FQDN. That way, the mobile node can more successfully employ step (3) in the event that things go haywire with an "un-renumbered" home address on a home network that has changed. On the other hand (as before), if the mobile node is really successful at sending Binding Updates to all of its correspondents, the home agent is unlikely to see very much traffic anyway. I think that in any case, there should be made some very strong suggestions that agent addresses should not be reused for quite a while after they lapse. Bottom line: I think we can get to a solution whereby nodes really do use an unchanging EID IPv6 address as their network identity, even if the unchanging EID is by definition unrouteable. Question: Does this initial design idea warrant completion? I can think of a dozen questions that need answers right away, but it all takes time that I'd rather not spend if it's unwarranted. One further idea: This line of reasoning indicates the need for two kinds of Binding Updates -- a "temporary" one that may have an expiration date, and a "permanent" one that _could_ trigger actions on the part of higher-level protocols (e.g., fiddling around with protocol control blocks). We do have plenty of spare bits in our Destination Option header, so one of them could be used for this purpose. The mobile node can certainly tell the difference. This bit might also be useful for handling anycast addresses. > I wish it was that simple. IP Sec also needs identifiers. I presume the EID-style IPv6 addresses would also be used for IPSec style identifiers. > Brian Charlie P. PS. Is "routeable" misspelled? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 13:55:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25713; Mon, 7 Oct 96 13:55:37 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25706; Mon, 7 Oct 96 13:55:24 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA13933; Mon, 7 Oct 1996 13:49:08 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id NAA05664; Mon, 7 Oct 1996 13:48:30 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA00111; Mon, 7 Oct 1996 16:48:26 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA17363; Mon, 7 Oct 1996 16:48:24 -0400 Message-Id: <9610072048.AA17363@fwasted.zk3.dec.com> To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2204) Re: IPv6 PS to DS Status? In-Reply-To: Your message of "Mon, 07 Oct 96 10:12:29 CDT." <199610071512.KAA20370@gungnir.fnal.gov> Date: Mon, 07 Oct 96 16:48:24 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Sorry "priority field"? Is there an issue? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 14:21:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25750; Mon, 7 Oct 96 14:21:26 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25744; Mon, 7 Oct 96 14:21:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA21166; Mon, 7 Oct 1996 14:14:56 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id OAA15328; Mon, 7 Oct 1996 14:13:58 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA15602; Mon, 7 Oct 1996 17:03:16 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21558; Mon, 7 Oct 1996 17:03:16 -0400 Message-Id: <9610072103.AA21558@fwasted.zk3.dec.com> To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2205) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Tue, 08 Oct 96 01:36:17 +1000." <18510.844702577@munnari.OZ.AU> Date: Mon, 07 Oct 96 17:03:16 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Does anyone on this list believe that IPv6 can not go to full standard > status or be deployed widely without completing the answer to the > variant EID problems? > >Whatever is done with EIDs, or the problems that lead to the >demand for them is now looking like being done at a layer above >the IP layer - so the most that is likely to be needed of IPv6 >is an end to end option, and they're clearly intended to be >defined as needed. > >So, from a technical viewpoint, no. > >However, something has to be done to solve the problems before >implementations are shipped in any volume. Whether this is some >change to TCP, or something else is still to be decided, but >shipping the TCP that works over IPv4, to simply work with no >change more than the pseudo-header checksum is simply inadequate. If we define them as a dst option then that puts a place holder I would think in most peoples stack implementations at the point the IPv6 header is processed off the queue to ip_intr to ip_input or ip_forward. To later add tcp_input/tcp_output and xxx_pcb data structures and the logic to support Dynamic Address Changing, Rehoming (if we believe we can even specify this), or if we get really good and do process migration within the context of an entire network stack is transparent to the IPv6 core development effort to produce a product for customers. Whether just as early adopter kits or large volume shipments of products. But....if it affects applications then that actually is harder to swallow and deploy because we would face yet another binary compatibility issue. Pedro and I found working on Anycast and Dynamic Renumbering that if the applications selects the dst address and depends on that for some reason in the application and then we change it underneath them we have to inform them that this took place. And we believe whatever is done here must be done for both UDP and TCP. If that is part of the technical philosophy or assumptions about solving this problem then there is no issue for the application. It can be done with a socket option or possibly with a new type of inline control character in the datastream or caused by the dst option itself as two ideas (I am sure there are others). But we cannot assume all applications don't care if the dst address changes if they did not bind to to a wild card. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 14:25:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25769; Mon, 7 Oct 96 14:25:13 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25763; Mon, 7 Oct 96 14:25:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA22216; Mon, 7 Oct 1996 14:18:32 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id OAA16595; Mon, 7 Oct 1996 14:17:17 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA12667; Mon, 7 Oct 1996 17:06:14 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19945; Mon, 7 Oct 1996 17:06:08 -0400 Message-Id: <9610072106.AA19945@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2206) Re: suggestion (long) (replay) In-Reply-To: Your message of "Mon, 07 Oct 96 17:41:06 +0200." <9610071541.AA31522@dxcoms.cern.ch> Date: Mon, 07 Oct 96 17:06:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Rehoming is completely another which entails migrating the transaction >> to a completely different anycast machine. >Absolutely. However, to the remote client they look much the same >I think: the server's address has changed. Yep. >> In rehoming your not saying the client of the anycast server group >> should be able to switch to another client? If so we have three >> paradigms to discuss. >> >>I don't think so. I can't see a scenario where that makes any sense. >(No doubt somebody will now invent one :-) Sh*t..... I should have shut up. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 16:13:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25849; Mon, 7 Oct 96 16:13:15 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25843; Mon, 7 Oct 96 16:13:02 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA20359; Mon, 7 Oct 1996 16:06:29 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id QAA27143; Mon, 7 Oct 1996 16:05:56 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA31412; Mon, 7 Oct 1996 18:58:28 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00515; Mon, 7 Oct 1996 18:58:27 -0400 Message-Id: <9610072258.AA00515@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2207) Re: from Geert Jan In-Reply-To: Your message of "Mon, 07 Oct 96 09:12:16 +0200." <9610070712.AA29823@dxcoms.cern.ch> Date: Mon, 07 Oct 96 18:58:27 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think Geert's synopsis is valid. But in logic and the real market a truth table can be valid but false when tested to reality. I think we need to do what Geert has stated. But the market will not be held captive to anyone if they have the big bucks. At least in a completely free enterprise environment. Or like Ethernet it does not work theoretically but does in practice. I think designing a system where renumbering is every 3 months is incompetent and I know of NO Fortune 100 company that would want this type of condition to be specified. But more importantly we need to take Geert's list and get to work folks. Also my name was used at the end out of context and my arguments with Geert and the IEPG were not presented and that I too believe we need to be able to renumber. But it wasn't negative so thats cool. I actually agree with Geert but he said nothing to prevent the market from moving forward unless some countries have government hoops that can prevent that evolution. But I have no customers who want to use RFC 1897 as the means to get their IPv6 address. They want it from a specified draft. So I will state now that I believe as a response to my own question we must have an Address Spec to assign IPv6 real addresses a.s.a.p. to move forward. I also think we need IDRPv6 and that work needs to begin quickly as an exterior routing protocol to move forward. Also we have heard from Geert can we hear from other Network Operators or ISP type folks. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 18:03:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25925; Mon, 7 Oct 96 18:03:33 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA25919; Mon, 7 Oct 96 18:03:15 PDT Received: from bobo.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA15471; Mon, 7 Oct 1996 17:57:02 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA17049; Mon, 7 Oct 1996 17:56:48 -0700 Date: Mon, 7 Oct 1996 17:56:48 -0700 From: nordmark@pacific-86 (Erik Nordmark) Message-Id: <199610080056.RAA17049@bobo.eng.sun.com> To: brian@dxcoms.cern.ch Subject: (IPng 2208) Re: suggestion (long) 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 > From brian@dxcoms.cern.ch Thu Oct 3 08:44:35 1996 > > Other folks: am I worrying about something unimportant? I think the case of established, long-lived TCP connections are important to handle when renumbering. But a case that might be used as important is dealing with applications that have not yet been established when the renumbering occurs. This could be caused by any number of reasons: - DNS ttl having too large values. - DNS implementations that do not honor the ttl. - Libraries that cache IP addresses without knowing the DNS ttl (I think the YP/NIS gethostbyname does this.) - Applications that keep IP addresses around for a long or unbounded time. I'm personally concerned about the two last items on the list. Thus I think a solution for renumbering needs to handle the case where the connection has not yet been established but the application/library has the "old" IP address. As far as I understand the solution space, being able to deal with stale cached addresses implies that it is not sufficient to have some message exchanges since the parties are not yet communicating. Thus this might force us towards a solution more like mobile-ip where there is some way to contact the host using the old address. BTW: I don't quite see how your proposed destination option handles the case when both parties renumber at the same time. That might be a common occurance if e.g. a provider and all its subscribers renumber at together. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 20:04:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26131; Mon, 7 Oct 96 20:04:58 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26125; Mon, 7 Oct 96 20:04:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA23142; Mon, 7 Oct 1996 14:21:52 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id OAA17666; Mon, 7 Oct 1996 14:20:28 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA12909; Mon, 7 Oct 1996 17:19:46 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23729; Mon, 7 Oct 1996 17:19:44 -0400 Message-Id: <9610072119.AA23729@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2209) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Mon, 07 Oct 96 18:02:45 +0200." <9610071602.AA06486@dxcoms.cern.ch> Date: Mon, 07 Oct 96 17:19:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Does anyone on this list believe that IPv6 can not go to full standard >> status or be deployed widely without completing the answer to the >> variant EID problems? >> >I think it's slightly more subtle Yes it is really good point. > - we should be certain before we go to full standard that IPv6 > *does not disallow* a solution, i.e. we need an existence > proof of a solution. I doubt if this is far away, looking at > the discussion. I agree thats why I am poking at it now rather than later and not trying to just be a jerk here. This is important to get on the table for early implementors now. > - the market decides about deployment. However, having seen > how hard it was to get MTU Size Discovery or DHCP into all > vendor's IPv4 stacks, I'm slightly nervous about wide deployment. Well unlike most of my other "vocal" peers (there is a silent majority we just don't know about usually until an IETF meeting) on IPng I am very confident any customer I talk to will want IPv6 yesterday. People are really board with the NO to new and needed address space and have come to understand the new technology features in IPv6 and want them. They also want to keep the open market for small ISPs to continue to exist for philosphical reasons is my reading and IPv6 will help that too. DHCP and MTU were iffy until Microsoft shipped DHCP in mass and it was unclear how long it would take for MTU to be useful and required for some (which I don't understand so I am lost on that one). IPv6 is a completely different thing here. We did it for a very good reason. That pain that caused that reason is here now and CIDR and all the IPv4 renumbering in the world will not solve that problem. It can help it like an asprin but the root of the pain to be solved is IPv6. Plus IPv6 creates a renewed market as I think some things will not deploy widely on IPv4 but on IPv6 (e.g. RSVP, IP over Cable, Mobility, Real Time Services). >How's that for answering "maybe"? Pretty darn good. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 23:19:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26558; Mon, 7 Oct 96 23:19:34 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26552; Mon, 7 Oct 96 23:19:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA25848; Mon, 7 Oct 1996 23:13:06 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA02016; Mon, 7 Oct 1996 23:12:35 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id IAA02117 for ; Tue, 8 Oct 1996 08:12:33 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA02466; Tue, 8 Oct 1996 08:12:32 +0200 Message-Id: <9610080612.AA02466@dxcoms.cern.ch> Subject: (IPng 2210) Re: IPv6 and 1394.2 (fwd) To: ipng@sunroof.eng.sun.com Date: Tue, 8 Oct 1996 08:12:32 +0200 (MET DST) From: "Brian Carpenter CERN-CN" 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 Following a recent comment by Masataka Ohta about hardware ID length, I decided to check, and here is a full explanation from the IEEE 1394 expert. We do need to think about this, I suspect. Brian Carpenter >--------- Text sent by David B Gustavson follows: > From dbg@SCIzzL.com Mon Oct 7 22:15:32 1996 > X-Delivered: at request of brian on dxcoms.cern.ch > X-Sender: dbg@ng.netgate.net > Message-Id: > In-Reply-To: <9610070750.AA09577@dxcoms.cern.ch> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Date: Mon, 7 Oct 1996 11:00:41 -0700 > To: "Brian Carpenter CERN-CN" > From: David B Gustavson > Subject: Re: IPv6 and 1394.2 > Cc: bogaerts@dxcern.cern.ch (Andre Bogaerts), dvj@apple.com > > >Dave, > > > >Andre Bogaerts suggested that you might be able to help me. > >Over in another universe (the IETF) we are discussing end-point > >identifiers for use with IPv6 (IP next generation). Up to now > >we've been asuming that 48 bit unique identifiers (as for Ethernet) > >are sufficient. A colleague in Japan alleges: > >> > >> And, there is one more reason why 8 byte ID is preferable. > >> > >> With a new link layer technology, IEEE 1394, world wide > >> unique link layer ID is 8, NOT 6, octets long. This may not > >> be a immediate problem for IPv6, as IEEE 1394 has a short-term > >> 2 byte link-unique ID. > >> > > > >I presume he's failing to distinguish 1394 from 1394.2 in this. > >My question is, are addresses in 1394.2 allocated at the factory > >like Ethernet addresses, or dynamically like SCI addresses? > > > >Thanks, > > Brian Carpenter (IAB Chair) (brian@dxcoms.cern.ch) > > voice +41 22 767 4967, fax +41 22 767 7155 > > Both. There is a unique 64-bit ID assigned through a mechanism > administrated under the IEEE Registration Authority Committee, which has > resulted in 2-pin electronic components available for about $0.50 each, > that contain such unique numbers (as well as, typically, some other > nonvolatile storage available to the user). > > This unique ID is needed during initialization while assigning preliminary > addresses. The ID isn't really ever used as an address, it's just part of > the mechanism for making nodes unique and guaranteeing that one node will > always be selectable as the reference point for initialization management > and actual address assignments. > > So the first phase of initialization establishes a useable topology, > electronically severing unnecessary loop connections caused by extra > cables, for example, and establishes addressibility in a primitive way > (e.g. relating addresses to distance from the node with the highest unique > ID or something similar). > > Once addressibility is established, software takes over and writes the > addresses it wants the nodes to use into certain control registers in each > node. These addresses would normally be unique in a larger system--for > example, a real system might have several subsystems connected via bridges > or switches. The initial hardware level of address establishment will > assign the same addresses in each subsystem, leaving the bridges inactive. > Software assigns system-wide unique addresses in any way it finds > convenient, using the initial hardware-assigned addresses and special > mechanisms in the bridges, enabling bridges in the process. > > Once set up, nodes respond both to their software-assigned address and to > their hardware-assigned initial address. When dynamic changes occur (the > user plugs in something new or disconnects something), the interconnect > does a rapid reset. That reassigns hardware-assigned initial addresses, but > nodes try to keep their software-assigned addresses if possible, so as to > make operation as smooth as possible for the user and user application > software. > > These are 16-bit addresses, just as in SCI. > > SCI is essentially the same as this, but was defined before the economical > 64-bit unique IDs became available so relies on 48, and does not remember > and continue to respond to its initial hardware-assigned address--as soon > as software writes the new address to an SCI node, it forgets its > hardware-assigned one. That's something we'll change in the next > generation. Actually, the current plan is that Serial Express, P1394.2, > will be the next generation of SCI if it succeeds. It's a superset into > which we've poured all the optimizations we've thought of over the last 4 > years of SCI experience. > > > Hope this clarifies things. > In the IEEE we're urging people to aim new standards at the 64-bit unique > ID, and you're welcome to use it too. We do try to insist that all users > document the use of the bits carefully, and let us criticise those > documents and suggest clarifications where needed, to ensure as far as > possible that aliasing will not occur due to inconsistent bit assignments, > especially in technologies where such IDs might eventually meet (which is > getting to be almost everything in our increasingly interconnected world). > > Dave Gustavson > > --David B. Gustavson phone 415/961-0305 fax 415/961-3530 > IEEE CS/MMSC Microprocessor Standards Committee chairman > Exec. Director, SCIzzL: Assoc. SCI Local-Area MultiProcessor Users > 1946 Fallen Leaf Lane, Los Altos, CA 94024-7206 dbg@SCIzzL.com > For more info on SCI etc., see the Web: > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 7 23:56:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26590; Mon, 7 Oct 96 23:56:16 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26584; Mon, 7 Oct 96 23:56:02 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA29225; Mon, 7 Oct 1996 23:49:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA07857; Mon, 7 Oct 1996 23:49:18 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id IAA08028 for ; Tue, 8 Oct 1996 08:49:16 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA10231; Tue, 8 Oct 1996 08:49:16 +0200 Message-Id: <9610080649.AA10231@dxcoms.cern.ch> Subject: (IPng 2211) Re: IPv6 Other Work in Progress and Needed. To: ipng@sunroof.eng.sun.com Date: Tue, 8 Oct 1996 08:49:16 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199610071643.AA14429@zed.isi.edu> from "bmanning@ISI.EDU" at Oct 7, 96 09:43:09 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill, > > > > Changing Addresses on the Fly and EIDs - So far only a handful of > > > > us are discussing not sure where this fits and when needed. > > > > > > A couple of other folks here have been talking about this very idea. > > > It seems that this topic is going to be brought up in a new wg > > > hosted in the transport area. Its clear to me that the IPv6 > > > efforts should be targeted on how to renumber end-nodes and let > > > the transport folks worry about retaining session identity across > > > topology renumbering. But that is just my thought. > > > > > I wish it was that simple. IP Sec also needs identifiers. > > > > Brian > > Why should they be the same? > Correct, they don't need to be. My point is that the IP Sec identifier is an IP-level identifier, even if transport solves the problem separately. Security persons, please help us! Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 00:36:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26662; Tue, 8 Oct 96 00:36:23 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26656; Tue, 8 Oct 96 00:36:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA02693; Tue, 8 Oct 1996 00:29:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA14773; Tue, 8 Oct 1996 00:29:26 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA16929 for ; Tue, 8 Oct 1996 09:29:24 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA09730; Tue, 8 Oct 1996 09:29:24 +0200 Message-Id: <9610080729.AA09730@dxcoms.cern.ch> Subject: (IPng 2212) Re: suggestion (long) To: ipng@sunroof.eng.sun.com Date: Tue, 8 Oct 1996 09:29:24 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199610080056.RAA17049@bobo.eng.sun.com> from "Erik Nordmark" at Oct 7, 96 05:56:48 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 Erik, > > BTW: I don't quite see how your proposed destination option > handles the case when both parties renumber at the same time. > That might be a common occurance if e.g. a provider and all its > subscribers renumber at together. > Good point. In fact it might be a killer point. Jim, Pedro, does your address set mechanism have the same problem? Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 01:56:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26723; Tue, 8 Oct 96 01:56:23 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26717; Tue, 8 Oct 96 01:56:09 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA06905; Tue, 8 Oct 1996 01:49:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA28592; Tue, 8 Oct 1996 01:49:24 -0700 Received: from vega.csl.sony.co.jp (vega.csl.sony.co.jp [43.27.98.24]) by tera.csl.sony.co.jp (8.6.12+2.4W/3.3W3) with SMTP id RAA24512; Tue, 8 Oct 1996 17:48:58 +0900 Message-Id: <199610080849.RAA24512@tera.csl.sony.co.jp> X-Sender: tera@tera.csl.sony.co.jp X-Mailer: Windows Eudora Pro Version 2.2-Jr1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Tue, 08 Oct 1996 17:47:52 +0900 To: Charlie Perkins From: =?ISO-2022-JP?B?GyRCO3syLEo4Q0sbKEog?= Subject: (IPng 2213) Re: suggestion (long) (replay) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, I don't disagree with Binding Update. I do disagree with the usage of the source address field in the IPv6 header in your proposal. In your proposal, the source address field contains the home address (or EID in this discussion) of the sender. The receiver cannot know whether the source address field contains the address or EID of the sender. This causes problems on security and multicast routing using reverse path forwarding. The address fields should be used for locators. EIDs should be contained in other fields than the address fields. Fumio TERAOKA. At 10:04 96/10/07 -0500, Charlie Perkins wrote: > > >> == Teraoka-san > > == Brian > > >> I would like to add draft-teraoka-ipv6-mobility-sup-03.txt to > >> the list. This memo introduces source and destination ID options > >> as IPv6 destination options to originally support mobility in IPv6. > >> > >> The same mechanism is applied to mobility support in IPv4 > >> (draft-teraoka-mobileip-vip-01.txt[expired]). In IPv4 mobility, > > > > Sorry I missed your drafts. It's hard to keep track of everything. > > It's clearly desirable to find a single mechanism that > > covers renumbering, rehoming, and mobility. > > Brian, while I agree with your last sentence, I don't think that > the Source Address option can measure up to the task. The methods > outlined in Teraoka-san's draft require far more overhead than what > we have proposed in our Binding Update option. These issues have been > discussed at length (multiple times) in the mobile-IP working group > meetings. Without going back to find my previous notes, I should just > mention that the source option needs to be sent in many, many more > normal data packets than our Binding Update, and each one needs to > be authenticated. In fact, in Teraoka-san's proposal as he presented > it, I think that _every_ data packet needed authentication, but we > determined that somewhat weaker (but still onerous) conditions could > still guarantee correctness. There are other serious differences also > at issue. > > Although I think that we should go ahead with the mobility draft > as soon as possible, I also am willing to enlarge the scope of the > Binding Update to handle other requirements if needed. I think > that we already do a reasonable job to help with renumbering. > On that issue, it would be helpful if the working group would decide > whether or not it's legal to expect TCP (and other higher-level > protocols) to fiddle around with their internal data structures in > response to a renumbering (e.g, Binding Update) message. For anycast, > the first thing to do is to find out whether generic (non-router) IPv6 > nodes can respond to anycast addresses. For some of the multihoming > problems, the Binding Update seems perfect, but I need to study > Shand's existing draft to be sure. > > >> There are two approaches in how to create EID: EID includes location > >> information, or not. > > I think it is almost necessarily a mistake to include location > information in any sort of endpoint identification. To do so > amounts to a statement that a _particular_ endpoint is tied to > a _particular_ location, doesn't it? > > >> In my approach in IPv4 and IPv6, EID has the > >> same format of the IP address. > > I think it would be a step forward in any future EID discussions > if proponents (such as myself) would make this basic agreement. > > >> The relation between EID and IP address > >> is analogous to that between the logical address and the physical > >> address of virtual memory system in operating systems. > > I think this statement is true _only_ insofar as introducing and > managing a level of indirection is valuable for solving both problems. > Concepts of working set, page size, inverted lookup tables, > and almost every other characteristic of virtual memory do not > seem to apply. > > Cache management, on the other hand, is one area where interesting > parallels may be drawn -- but it's not as closely tied to virtual > memory. > > >> This approach > >> has some advantages: 1) EID assignment is easy, 2) TCP/UDP can use > >> EIDs and IP addresses interchangeably, etc. > > This statement seems to be applicable to the point about using > IPv6 addresses as EIDs, not to the point about virtual memory. > > > Obviously, if we choose 16 byte EIDs, the option formats > > defined for mobility are the ones to use. In fact, in that case > > I would suggest allocating an RFC 1884 format prefix for EIDs, > > so that an EID and a locator would be syntactically distinct. > > Doing so, however, means that we can't use the "home addresses" > effectively as EIDs. While I agree with those who point out that > identifiers and locators are distinct concepts, I think even so > that there are advantages to being able to distinguish one address > to serve as identifier even when it _can_ also serve as a locator. > > >> Fumio TERAOKA (SonyCSL) > > > Brian Carpenter > > Charles E. Perkins ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 03:55:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26791; Tue, 8 Oct 96 03:55:57 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26785; Tue, 8 Oct 96 03:55:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA11545; Tue, 8 Oct 1996 03:49:26 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA17812; Tue, 8 Oct 1996 03:48:54 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id LAA15189; Tue, 8 Oct 1996 11:46:21 +0100 Date: Tue, 8 Oct 1996 11:46:21 +0100 Message-Id: <199610081046.LAA15189@oberon.di.fc.ul.pt> From: Pedro Roque To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2214) Re: suggestion (long) In-Reply-To: <9610080729.AA09730@dxcoms.cern.ch> References: <199610080056.RAA17049@bobo.eng.sun.com> <9610080729.AA09730@dxcoms.cern.ch> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Brian" == Brian Carpenter CERN-CN writes: Brian> Erik, >> BTW: I don't quite see how your proposed destination option >> handles the case when both parties renumber at the same time. >> That might be a common occurance if e.g. a provider and all its >> subscribers renumber at together. >> Brian> Good point. In fact it might be a killer point. Brian> Jim, Pedro, does your address set mechanism have the same Brian> problem? No. Both hosts send updates on their address information and everything should work. At least it was designed with that purpose. But... i think i fail to see Erik's point... Using Brian's proposal: A B was using EID 1 was using EID 2 A1 old address B1 old address A2 new address B2 new address sends from A2 to B1 sends from B2 to A1 B updates binding: EID-1 goes to A2 A updates binding EID-2 goes to B2 everything should work, no ? ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 04:02:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26811; Tue, 8 Oct 96 04:02:44 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26805; Tue, 8 Oct 96 04:02:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA11844; Tue, 8 Oct 1996 03:56:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA19132; Tue, 8 Oct 1996 03:55:02 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id LAA15203; Tue, 8 Oct 1996 11:52:21 +0100 Date: Tue, 8 Oct 1996 11:52:21 +0100 Message-Id: <199610081052.LAA15203@oberon.di.fc.ul.pt> From: Pedro Roque To: nordmark@pacific-86.eng.sun.com (Erik Nordmark) Cc: brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com Subject: (IPng 2215) Re: suggestion (long) In-Reply-To: <199610080056.RAA17049@bobo.eng.sun.com> References: <199610080056.RAA17049@bobo.eng.sun.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Erik" == Erik Nordmark writes: >> From brian@dxcoms.cern.ch Thu Oct 3 08:44:35 1996 >> >> Other folks: am I worrying about something unimportant? Erik> I think the case of established, long-lived TCP connections Erik> are important to handle when renumbering. Erik> But a case that might be used as important is dealing with Erik> applications that have not yet been established when the Erik> renumbering occurs. This could be caused by any number of Erik> reasons: - DNS ttl having too large values. - DNS Erik> implementations that do not honor the ttl. - Libraries that Erik> cache IP addresses without knowing the DNS ttl (I think the Erik> YP/NIS gethostbyname does this.) - Applications that keep Erik> IP addresses around for a long or unbounded time. Erik> I'm personally concerned about the two last items on the Erik> list. Thus I think a solution for renumbering needs to Erik> handle the case where the connection has not yet been Erik> established but the application/library has the "old" IP Erik> address. Erik> As far as I understand the solution space, being able to Erik> deal with stale cached addresses implies that it is not Erik> sufficient to have some message exchanges since the parties Erik> are not yet communicating. Thus this might force us towards Erik> a solution more like mobile-ip where there is some way to Erik> contact the host using the old address. Eirk, I think in the examples you mention, specially the last two the applications are somehow broken. I don't think it makes sense to have an multi-homing like redirection for renumberng as that means you don't get to be able to reuse the address. Addresses deprecate, and must have a resonable deprecation time to deal with DNS update delays. After that deprecation time if an application as a stale cache entry it is broken and i don't think we can do anything about it at protocol design level. regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 04:26:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26854; Tue, 8 Oct 96 04:26:58 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26848; Tue, 8 Oct 96 04:26:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA12908; Tue, 8 Oct 1996 04:20:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA24154; Tue, 8 Oct 1996 04:20:00 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA21072 for ; Tue, 8 Oct 1996 13:19:58 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA22709; Tue, 8 Oct 1996 13:19:53 +0200 Message-Id: <9610081119.AA22709@dxcoms.cern.ch> Subject: (IPng 2216) Re: suggestion (long) To: ipng@sunroof.eng.sun.com Date: Tue, 8 Oct 1996 13:19:53 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199610081046.LAA15189@oberon.di.fc.ul.pt> from "Pedro Roque" at Oct 8, 96 11:46:21 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, > > But... i think i fail to see Erik's point... Using Brian's proposal: > > A B > > was using EID 1 was using EID 2 > A1 old address B1 old address > A2 new address B2 new address > > > sends from A2 to B1 sends from B2 to A1 > B updates binding: EID-1 goes to A2 > A updates binding > EID-2 goes to B2 > > > everything should work, no ? > If this is done during the period when the old addresses are deprecated but still valid, it's OK. I'm concerned that there might be a race condition in the rehoming case... if the unthinkable happens, and the server and client are rehomed simultaneously, there is no deprecation interval and all the packets get blackholed. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 04:51:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26890; Tue, 8 Oct 96 04:51:17 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26884; Tue, 8 Oct 96 04:50:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA14188; Tue, 8 Oct 1996 04:44:44 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA01928; Tue, 8 Oct 1996 04:44:13 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id HAA14370; Tue, 8 Oct 1996 07:44:13 -0400 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/10-03-96) with SMTP id HAA424350; Tue, 8 Oct 1996 07:44:09 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA50485; Tue, 8 Oct 1996 07:44:04 -0400 From: Charlie Perkins Message-Id: <9610081144.AA50485@hawpub1.watson.ibm.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2217) Re: suggestion (long) In-Reply-To: Your message of Tue, 08 Oct 96 13:19:53 O. <9610081119.AA22709@dxcoms.cern.ch> Date: Tue, 08 Oct 96 07:44:03 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If this is done during the period when the old addresses are > deprecated but still valid, it's OK. I'm concerned that there > might be a race condition in the rehoming case... if the > unthinkable happens, and the server and client are rehomed > simultaneously, there is no deprecation interval and all the > packets get blackholed. I should think that any realistic administrative guide for site renumbering would prohibit this scenario. All of the discussions I can remember about renumbering and address deprecation certainly indicated that IPv6 nodes would not perform such instant renumbering in the typical case. In the drastic cases, which are not disallowed by IPv6 but are within the realm of unlikely possibility, long-lasting TCP connections could be broken when there is no deprecation interval. Shouldn't we strongly discourage such behavior? IPv6 nodes that do not employ a reasonable deprecation interval may have to pay the price of broken connections. However, aside from that boundary problem, I think that overall we can expect robust renumbering even with mobility. It may be the case that renumbering without any deprecation interval only happens when there aren't any long-lived connections to maintain anyway. > Brian Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 05:03:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26915; Tue, 8 Oct 96 05:03:15 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA26909; Tue, 8 Oct 96 05:03:02 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA14707; Tue, 8 Oct 1996 04:56:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA05434; Tue, 8 Oct 1996 04:56:17 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA26393 for ; Tue, 8 Oct 1996 13:56:16 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA22511; Tue, 8 Oct 1996 13:56:15 +0200 Message-Id: <9610081156.AA22511@dxcoms.cern.ch> Subject: (IPng 2218) Re: suggestion (long) To: ipng@sunroof.eng.sun.com Date: Tue, 8 Oct 1996 13:56:15 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9610081144.AA50485@hawpub1.watson.ibm.com> from "Charlie Perkins" at Oct 8, 96 07:44:03 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, > .... In the > drastic cases, which are not disallowed by IPv6 but are within > the realm of unlikely possibility, long-lasting TCP connections > could be broken when there is no deprecation interval. > > Shouldn't we strongly discourage such behavior? > > IPv6 nodes that do not employ a reasonable deprecation interval > may have to pay the price of broken connections... I think that's a reasonable compromise. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 07:54:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27099; Tue, 8 Oct 96 07:54:37 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27093; Tue, 8 Oct 96 07:54:24 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA26727; Tue, 8 Oct 1996 07:48:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA22446; Tue, 8 Oct 1996 07:47:39 -0700 Received: from pferguso-pc.cisco.com (c3robo11.cisco.com [171.68.13.75]) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id HAA05803; Tue, 8 Oct 1996 07:47:30 -0700 Message-Id: <2.2.32.19961008144728.00693f8c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Oct 1996 10:47:28 -0400 To: "Brian Carpenter CERN-CN" From: Paul Ferguson Subject: (IPng 2219) Re: IPv6 Other Work in Progress and Needed. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:02 PM 10/7/96 +0200, Brian Carpenter CERN-CN wrote: >I think it's slightly more subtle > > - we should be certain before we go to full standard that IPv6 > *does not disallow* a solution, i.e. we need an existence > proof of a solution. I doubt if this is far away, looking at > the discussion. > > - the market decides about deployment. However, having seen > how hard it was to get MTU Size Discovery or DHCP into all > vendor's IPv4 stacks, I'm slightly nervous about wide deployment. > >How's that for answering "maybe"? > Pretty accurate. - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 08:42:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27139; Tue, 8 Oct 96 08:42:37 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27133; Tue, 8 Oct 96 08:42:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA03704; Tue, 8 Oct 1996 08:36:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA09688; Tue, 8 Oct 1996 08:34:54 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id LAA17536; Tue, 8 Oct 1996 11:33:19 -0400 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/10-03-96) with SMTP id LAA636885; Tue, 8 Oct 1996 11:33:15 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA33120; Tue, 8 Oct 1996 11:33:14 -0400 From: Charlie Perkins Message-Id: <9610081533.AA33120@hawpub1.watson.ibm.com> To: =?ISO-2022-JP?B?GyRCO3syLEo4Q0sbKEog?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2220) Re: suggestion (long) (replay) In-Reply-To: Your message of Tue, 08 Oct 96 17:47:52 V. <199610080849.RAA24512@tera.csl.sony.co.jp> Date: Tue, 08 Oct 96 11:33:13 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't disagree with Binding Update. I do disagree with > the usage of the source address field in the IPv6 header > in your proposal. In your proposal, the source address > field contains the home address (or EID in this discussion) > of the sender. Having the source address contain a static identifier has the advantage of simplifying TCP, but there are these disadvantages: 1) networks can be renumbered in IPv6, so that identifiers based on network addresses should be changeable too, and 2) steps (e.g., Binding Update option) need to be taken to associate a locator IPv6 address to the static identifier So far, we have chosen to live with these disadvantages, because the advantage of compatibility with existing TCP is a very big advantage. Letting "HLP" stand for any higher-level protocol (for instance, TCP), I think that one of the following has to be true whenever HLP uses source addresses in its protocol control blocks: 1) HLP protocol control blocks are anchored to an IPv6 address, and incoming packets with that address are the ones that are delivered to the HLP for processing by means of the information stored in the protocol control block (i.e., status quo). 2) IPv6 processing (i.e., at the network layer) is smart enough to translate the actual source address into another address expected by HLP. 3) HLP is altered so that protocol control blocks may be anchored to possibly changeable IPv6 source addresses, or alternatively so that HLP does the translation from the IPv6 source address into whatever address anchors the control block. Did I miss any relevant possibilities? As usual, confining such processing to the network layer has the advantage that it only has to be done once for all higher-level protocols. This may be reason enough to discourage solutions of the third variety. Others (e.g., Christian) may well disagree with this opinion. It would be useful if a consensus would emerge on this basic matter. Our current IPv6 mobility draft fits into the first category. There is, however, the possibility that we can design a more intelligent (more complicated?) way for IPv6 to process incoming packets so that (for instance) the incoming source "locator" IPv6 address (e.g., care-of address) is always translated into a source "EID" IPv6 address before HLP (e.g., TCP) gets it. I think that would be an elegant design, but the cost is that incoming IPv6 processing would be somewhat more time-consuming. It's like looking at the route table for incoming packets as well as outgoing packets (except it would have to be called the Origination Cache, by analogy to the Destination Cache). The Binding Update proposal could possibly be augmented to operate in this manner, but there are some issues that would have to be worked out. I didn't think there was much sympathy recently for making the life of the IPv6 nodes more complicated. Also, since (in this scenario) the sender is applying the forward translation and thus sending the packet to a locator address which is different than the actual destination EID, handling ICMP messages might be a little trickier. > The receiver cannot know whether the source > address field contains the address or EID of the sender. I guess the point of using a solution of the second variety above would be to make sure that the receiver _could_ know how to interpret incoming source IPv6 address fields. > This causes problems on security You bring up an interesting point here, which still needs attention. However, I don't think that any existing proposal has any significant advantages or disadvantages in this regard. In particular, the Source Address option cannot be said to really solve the problem, since any IPv6 firewall careful enough to check for IPv6 source addresses would necessarily also have to check for IPv6 Source Address options. > and multicast routing using > reverse path forwarding. I don't think this is necessarily a problem for nodes using the Binding Update option, since for multicast they would probably just use their _locator_ IPv6 address on outgoing packets. Handling group membership control packets might need more care. > The address fields should be used for locators. EIDs should be > contained in other fields than the address fields. This is one of the points at issue, and I refer to the three solution approaches outlined above. > Fumio TERAOKA. Regards, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 09:35:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27325; Tue, 8 Oct 96 09:35:15 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27319; Tue, 8 Oct 96 09:35:03 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA14300; Tue, 8 Oct 1996 09:28:46 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id JAA29637; Tue, 8 Oct 1996 09:27:44 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA21651; Tue, 8 Oct 1996 12:27:22 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA12058; Tue, 8 Oct 1996 12:27:21 -0400 Message-Id: <9610081627.AA12058@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2221) Re: suggestion (long) In-Reply-To: Your message of "Tue, 08 Oct 96 09:29:24 +0200." <9610080729.AA09730@dxcoms.cern.ch> Date: Tue, 08 Oct 96 12:27:20 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, >Erik, >> >> BTW: I don't quite see how your proposed destination option >> handles the case when both parties renumber at the same time. >> That might be a common occurance if e.g. a provider and all its >> subscribers renumber at together. >> >Good point. In fact it might be a killer point. >Jim, Pedro, does your address set mechanism have the same problem? Not an issue for Anycast Address draft. But for the draft-bound-ipv6-ip-addr-00.txt draft we saw this problem up front. Our draft assumes that an address-set view is presented in a dst option. We assumed and need to write in the next version that when an address becomes deprecated that new addresses are acquired. Once they are acquired then the address-set view is presented to the peer node before that nodes validation timer for that address expires, or the nodes validation timer. If implementations use the preferred and validation timers in addr conf and the network is set up correctly via the ND RAs via the admin it should work fine. But, errors in multiple places could occur but don't have to. Any solution will have the same problem if it does not rely on the inherent benefits of the preferred and validation timers for an address in IPv6 addr conf (also in DHCPv6 fyi). What an EID would do to help is permit a lookup for the most recent address for that EID if it changed. But this deprecates to the point where a DNS name lookup would regarding peformance (e.g. leaving the kernel [context switch], then doing the DNS resolver thing, then back to the kernel [context switch]. This is one reason we threw out the idea of EIDs in additon that no one seems to be able to define them, but mostly they won't help in the case Erik has put forth. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 09:40:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27447; Tue, 8 Oct 96 09:40:15 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27441; Tue, 8 Oct 96 09:39:57 PDT Received: from bobo.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA23827; Tue, 8 Oct 1996 09:33:43 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17475; Tue, 8 Oct 1996 09:33:30 -0700 Date: Tue, 8 Oct 1996 09:33:30 -0700 From: nordmark@pacific-86 (Erik Nordmark) Message-Id: <199610081633.JAA17475@bobo.eng.sun.com> To: charliep@watson.ibm.com Subject: (IPng 2222) Re: suggestion (long) (replay) 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 > Letting "HLP" stand for any higher-level protocol (for instance, > TCP), I think that one of the following has to be true whenever > HLP uses source addresses in its protocol control blocks: > > 1) HLP protocol control blocks are anchored to an IPv6 address, > and incoming packets with that address are the ones that are > delivered to the HLP for processing by means of the information > stored in the protocol control block (i.e., status quo). > > 2) IPv6 processing (i.e., at the network layer) is smart > enough to translate the actual source address into another > address expected by HLP. > > 3) HLP is altered so that protocol control blocks may be anchored > to possibly changeable IPv6 source addresses, or alternatively so > that HLP does the translation from the IPv6 source address into > whatever address anchors the control block. > > Did I miss any relevant possibilities? Some protocols (for example VMTP) might have their own HLP identifiers that are completely independent of the network layer. (If I'm not mistaken VMTP uses multicast to determine the mapping from its transport identifier to the IP address.) Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 09:54:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27532; Tue, 8 Oct 96 09:54:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27526; Tue, 8 Oct 96 09:54:10 PDT Received: from Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA18263; Tue, 8 Oct 1996 09:47:54 -0700 From: bound@zk3.dec.com Received: by Sun.COM (sun-barr.Sun.COM) id AA03489; Tue, 8 Oct 96 09:47:41 PDT Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA02681; Tue, 8 Oct 1996 12:47:38 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA08699; Tue, 8 Oct 1996 12:47:38 -0400 Message-Id: <9610081647.AA08699@fwasted.zk3.dec.com> To: Charlie Perkins Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2223) Re: suggestion (long) In-Reply-To: Your message of "Tue, 08 Oct 96 07:44:03 CDT." <9610081144.AA50485@hawpub1.watson.ibm.com> Date: Tue, 08 Oct 96 12:47:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, If there is no deprecation interval for an IPv6: Validation Timer = 30 minutes Preferred Timer = 0 Then the implementation should immediately be looking for another adddress and the state in an implementation is that the address is immediately in the deprecated state because the prefferred timer is 0. So if an implementation behaves correctly I don't see how the case you state can happen? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 10:15:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27596; Tue, 8 Oct 96 10:15:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27590; Tue, 8 Oct 96 10:15:15 PDT Received: from Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA21335; Tue, 8 Oct 1996 10:09:00 -0700 From: bound@zk3.dec.com Received: by Sun.COM (sun-barr.Sun.COM) id AA04186; Tue, 8 Oct 96 09:51:17 PDT Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA27983; Tue, 8 Oct 1996 12:41:50 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14047; Tue, 8 Oct 1996 12:41:49 -0400 Message-Id: <9610081641.AA14047@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2224) Re: suggestion (long) In-Reply-To: Your message of "Tue, 08 Oct 96 13:19:53 +0200." <9610081119.AA22709@dxcoms.cern.ch> Date: Tue, 08 Oct 96 12:41:49 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >If this is done during the period when the old addresses are >deprecated but still valid, it's OK. I'm concerned that there >might be a race condition in the rehoming case... if the >unthinkable happens, and the server and client are rehomed >simultaneously, there is no deprecation interval and all the >packets get blackholed. I thought the rehome case was to "only" apply to the "anycast" scenario? Which does not have Erik's problem. The reason is that the Anycast server can act as referree if the anycast responder to the clients address is in the deprecated state....but we just into cyberspace of where we need to go for anycast discussion without finishing the basics. In the rehome case your right it gets nasty but as usual I don't "think" we can standarize this case well in the IETF? HEre is why: I view the rehome case must migrate the entire network process state to a new node. If I see the deprecation timer has gone off I may not want to take that migration until the node renegotiates a new address with the existing connection per the preferred and validation timer methodology in my previous mail. But this is a policy and not a technical enhancement to addr conf or the anycast proposal. ???? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 11:07:34 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27690; Tue, 8 Oct 96 11:07:34 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27681; Tue, 8 Oct 96 11:07:17 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA00033; Tue, 8 Oct 1996 11:00:56 -0700 Received: from munnari.OZ.AU by venus.Sun.COM (Sun.COM) id LAA04433; Tue, 8 Oct 1996 11:00:45 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA02607; Wed, 9 Oct 1996 04:00:25 +1000 (from kre@munnari.OZ.AU) To: Charlie Perkins Cc: "Brian Carpenter CERN-CN" , ipng@sunroof.eng.sun.com Subject: (IPng 2225) Re: suggestion (long) In-Reply-To: Your message of "Tue, 08 Oct 1996 07:44:03 EST." <9610081144.AA50485@hawpub1.watson.ibm.com> Date: Wed, 09 Oct 1996 04:00:22 +1000 Message-Id: <29557.844797622@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 08 Oct 96 07:44:03 -0500 From: Charlie Perkins Message-ID: <9610081144.AA50485@hawpub1.watson.ibm.com> All of the discussions I can remember about renumbering and address deprecation certainly indicated that IPv6 nodes would not perform such instant renumbering in the typical case. This is certainly what I'd expect, however, it unfortunately doesn't avoid the problem. In "both ends renumber at the same time" the definition of "the same time" is anything within the time it takes to exchange packets between the two nodes. In your average case (common case) that's less than a second, or perhaps a few seconds, and we can certainly anticipate the old address remaining valid for far longer than that. However, not all cases will be like that, TCP connections can remain alive for weeks, or months, with no packet exchanges at all, and even without the possibility of a packet exchange. In that period it is very likely that the old address will be deprecated into non-existance, and perhaps even reallocated, so sending more pcakets to it will cause a RST from the new node at the old address, which has never heard of the old connection. There should be no reason that I should not shut down my network link while I am not using the thing, and restart it later. TCP connections should be able to survive that - renumbering (or movement) or not. I know this not going to be easy, and will almost certainly need more radical changes than many seem willing to make - perhaps even API changes, to allow the application to recompute the addresses when told by TCP that it is having difficulties communicating, as I doubt we'd want TCP itself racing off doing DNS queries (and knowing host names to do that) whenever it feels inclined. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 12:04:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27753; Tue, 8 Oct 96 12:04:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27747; Tue, 8 Oct 96 12:04:34 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA12783; Tue, 8 Oct 1996 11:58:19 -0700 From: bound@zk3.dec.com Received: from mail13.digital.com by venus.Sun.COM (Sun.COM) id LAA05565; Tue, 8 Oct 1996 11:05:05 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA21813; Tue, 8 Oct 1996 13:52:42 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23345; Tue, 8 Oct 1996 13:52:38 -0400 Message-Id: <9610081752.AA23345@fwasted.zk3.dec.com> To: Charlie Perkins Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2226) Re: suggestion (long) (replay) In-Reply-To: Your message of "Tue, 08 Oct 96 11:33:13 CDT." <9610081533.AA33120@hawpub1.watson.ibm.com> Date: Tue, 08 Oct 96 13:52:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, On the point of translating the address in the binding-update to the HLP PCB at the network layer. But that is anchored to the existing IPv6 addresses in the PCB is not going to fly for performance reasons. We need to use the new address immediately. The good news is that to update the PCB is very simple and few lines of code. This will make it transparent to the PRU_REQUEST_XXX binding routines, tcp_inuput/tcp_output mods etc... It can affect the routing tables if you keep ND data in them. But with NUD they will get updated anyway. So I got to push back on this point you make as an implementor. Once the address is changed then its a done deal until it changes again or becomes deprecated. As far as it causing a change to TCP Pedro and I claim that it does NOT change the TCP specification at all and is transparent to UDP. The only potential problem is a RST to the anycast server who may go into a FIN-WAIT or CLOSE state when TCP is used. But I believe that to be the deprecated case and a time-out needs to happen. It should not affect the connection for the anycast member responding to the client node. On security its our assumption that the dst option for anycast is encapsulated or authenticated as part of the extension headers via IPSEC which is mandatory in IPv6. THis is an almost perfect use of IPSEC for our anycast draft as the connection is truly being altered from IP -Layer to IP-Layer and exactly what IPSEC does very well. I assume I get replay protection via IPSEC? I have to check... Now for the application layer listening and that takes inherent knowledge of the peer adddress that needs to be addressed and Pedro and I are working on that problem at present. I sent out yesterday several ideas to solve this problem but its trivial IMHO. But there is no way to do it with a performance hit "initially" on the connection. Much like the performance hit you get on first setting up any security associations. But once the set up is complete it does not have to keep happening. There is no free-lunch for this expanded technical capabilities I am hearing requested on this list or in the market. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 12:07:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27771; Tue, 8 Oct 96 12:07:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27765; Tue, 8 Oct 96 12:07:05 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA13188; Tue, 8 Oct 1996 12:00:50 -0700 Received: from munnari.OZ.AU by venus.Sun.COM (Sun.COM) id MAA11117; Tue, 8 Oct 1996 12:00:48 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA06741; Wed, 9 Oct 1996 04:59:39 +1000 (from kre@munnari.OZ.AU) To: nordmark@pacific-86.eng.sun.com (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2227) Re: suggestion (long) In-Reply-To: Your message of "Mon, 07 Oct 1996 17:56:48 MST." <199610080056.RAA17049@bobo.eng.sun.com> Date: Wed, 09 Oct 1996 04:59:35 +1000 Message-Id: <29598.844801175@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 7 Oct 1996 17:56:48 -0700 From: nordmark@pacific-86.Eng.Sun.COM (Erik Nordmark) Message-ID: <199610080056.RAA17049@bobo.eng.sun.com> But a case that might be used as important is dealing with applications that have not yet been established when the renumbering occurs. This could be caused by any number of reasons: - DNS ttl having too large values. - DNS implementations that do not honor the ttl. - Libraries that cache IP addresses without knowing the DNS ttl (I think the YP/NIS gethostbyname does this.) - Applications that keep IP addresses around for a long or unbounded time. I'm personally concerned about the two last items on the list. Me too - which is why it was important to get the TTL passed through the API - the current problem is almost guaranteed because of the way the API that was used when fetching the address from a static file was (almost) not altered when the addresses were instead obtained from a dynamic protocol. Beyond that we really just need intensive education that addresses will change, and that believing one longer than its TTL says it should be believed is a serious bug. Fortunately, the number of applications and libraries that do any more than "look up address, immediately connect" isn't all that large. This one can be solved without protocol changes anywhere... The other two problems are less of an issue, the TTL too large will be something people will fix as it causes problems, right now I don't think we know how large is too large. If there are any DNS implementations that don'e honour the TTL I haven't seen them. Old BIND had a lower bound of 5 minutes, but that shouldn't be a huge issue - we'd want more than 5 minutes of addressing overlaps. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 13:57:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27887; Tue, 8 Oct 96 13:57:07 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27881; Tue, 8 Oct 96 13:56:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA13095; Tue, 8 Oct 1996 13:50:24 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA18867; Tue, 8 Oct 1996 13:49:11 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16586(1)>; Tue, 8 Oct 1996 13:47:40 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 8 Oct 1996 13:47:27 PDT To: ipng@sunroof.eng.sun.com Cc: deering@parc.xerox.com Subject: (IPng 2228) Re: suggestion (long) Date: Tue, 8 Oct 1996 13:47:27 PDT From: Steve Deering Message-Id: <96Oct8.134727pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I haven't yet absorbed all of the comments on this topic, but I'd like to throw out a few quick comments of my own... *If* we are going to go down the EID path, I'd *really* like to see the EIDs occupying the low-order 48 or 64 bits of the IPv6 address, rather than making the headers even bigger with additional identifier fields or options. One price we pay for all the benefits of our connectionless internet protocol is the cost of carrying bigger headers in every packet. As those headers get bigger, and the amount of payload per packet gets smaller, that price gets harder to justify and it becomes harder to avoid falling into the connection-oriented morass, with all of its complicated signalling protocols, set-up latencies, poorer scaling properties, more complicated adaptation to topology changes, ... In other words, just because IPv4 with its 20-byte header has been tremendously successful, it does not follow that IP with a significantly larger header will also be successful; there's some trade-off point at which the header overhead becomes unaceptable, and we don't know what that point is. We're already expecting more header bloat in the form of authentication and encryption headers. Let's try to avoid any unnecessary header growth, growth that might push us off the other side of that trade-off. If EIDs are globally- unique identifiers, and there is a way for nodes to learn their own EIDs, then they ought to be able to serve also as the "token" part of auto- configured addresses and they need not make the headers any bigger. My *personal* opinion (taking off my WG-chair hat) is that we would be much wiser to work on keeping addresses relatively stable by applying a little engineering discipline to the topology (e.g., using metro-based addressing and routing), than to invent yet another name space (EIDs). We already have enough problems with the two namespaces we have (IP addresses and DNS names)! Do we really want to have to invent more mechanisms/databases/protocols to map from names to EIDs, and EIDs to names, from EIDs to addresses, and from addresses to EIDs? To figure out how to auto-configure EIDs? To hunt down and change every piece of Internet software that now handles addresses and assumes that they are stable? What confidence do we have that those new, as-yet undefined mechanisms will scale adequately? As it is, I am very worried that the extensions being made to the DNS to support dynamic changes of the name->address binding will lead to everyone using much smaller cache lifetimes (so that the changes will be visible sooner), which will break the scalability of the DNS. This Internet thing is a large, complex, and successful system; to make its continued success depend on such a fundamental architectural change as is being discussed here, as if it were a "small matter of programming", seems exceedingly foolish to me. Am I the only one who thinks designing new protocols and algorithms that work well at the scale and heterogeneity of the Internet is *hard*, and something to be avoided if at all possible? All this just to avoid running a few extra fibres? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 14:14:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27911; Tue, 8 Oct 96 14:14:39 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27905; Tue, 8 Oct 96 14:14:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA16957; Tue, 8 Oct 1996 14:08:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA25433; Tue, 8 Oct 1996 14:07:07 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15405(6)>; Tue, 8 Oct 1996 14:06:53 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 8 Oct 1996 14:06:41 PDT To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2229) Re: IPv6 and 1394.2 (fwd) In-Reply-To: brian's message of Mon, 07 Oct 96 23:12:32 -0800. <9610080612.AA02466@dxcoms.cern.ch> Date: Tue, 8 Oct 1996 14:06:40 PDT From: Steve Deering Message-Id: <96Oct8.140641pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If new LANs with 64-bit, factory-assigned addresses start appearing, I suspect that it would work just fine to use the low-order 48 bits of such addresses as IPv6 auto-config tokens, i.e., it would be unnecessary to increase the token size to 64 bits. The probability of there being two interfaces with the same low-order 48 bits ought to be negligible (assuming factory assignment, not dynamic assignment by run-time software). If a collision did occur, the IPv6 Duplicate Address Detection would catch it (eventually). The unfortunate owner of such colliding interfaces could move one to a different link, arrange a trade with someone, or take one back to the store for an exchange (which would happen *much* less frequently than exchanges for other reasons, such as being broken). Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 14:53:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27944; Tue, 8 Oct 96 14:53:56 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27938; Tue, 8 Oct 96 14:53:42 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA25555; Tue, 8 Oct 1996 14:47:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA10534; Tue, 8 Oct 1996 14:46:40 -0700 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA1255014; Tue, 8 Oct 1996 17:42:08 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id RAA30296; Tue, 8 Oct 1996 17:42:05 -0400 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA16762; Tue, 8 Oct 1996 17:46:39 -0400 Message-Id: <9610082146.AA16762@ludwigia.raleigh.ibm.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2230) Re: IPv6 and 1394.2 (fwd) In-Reply-To: Your message of "Tue, 08 Oct 1996 14:06:40 PDT." <96Oct8.140641pdt."75270"@digit.parc.xerox.com> Date: Tue, 08 Oct 1996 17:46:38 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: >The probability of there being two >interfaces with the same low-order 48 bits ought to be negligible (assuming >factory assignment, not dynamic assignment by run-time software). I'll admit that I have only a sketchy understanding of how address assignment takes place in the 64-bit space (re: Brian's earlier note on 1394.x), but I can't help but wonder if a dangerous assumption is being made above. I can imagine company X getting a unique 2-byte prefix, and then numbering all its interfaces starting with 1. Company Y gets a different 2-byte prefix, and uses the same algorithm. Uh oh. It may well turn out that the probability of collisions is low. But I would not assume that without further knowledge of how address blocks get assigned. Anyone know more? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 15:05:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27976; Tue, 8 Oct 96 15:05:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27960; Tue, 8 Oct 96 15:03:04 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA10860; Tue, 8 Oct 1996 14:56:49 -0700 Received: from alpha.xerox.com by venus.Sun.COM (Sun.COM) id OAA24317; Tue, 8 Oct 1996 14:56:50 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14733(2)>; Tue, 8 Oct 1996 14:56:48 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 8 Oct 1996 14:56:32 PDT To: Thomas Narten Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2231) Re: IPv6 and 1394.2 (fwd) In-Reply-To: narten's message of Tue, 08 Oct 96 13:46:38 -0800. <9610082146.AA16762@ludwigia.raleigh.ibm.com> Date: Tue, 8 Oct 1996 14:56:31 PDT From: Steve Deering Message-Id: <96Oct8.145632pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, > I'll admit that I have only a sketchy understanding of how address > assignment takes place in the 64-bit space (re: Brian's earlier note > on 1394.x), but I can't help but wonder if a dangerous assumption is > being made above. I can imagine company X getting a unique 2-byte > prefix, and then numbering all its interfaces starting with 1. Company > Y gets a different 2-byte prefix, and uses the same algorithm. Uh oh. Even so, it seems highly unlikely that I would happen to buy, say, interface number 142 from company X and interface number 142 from company Y, and end up putting them on the same LAN. Anyway, I think they'll end up using more than 16 bits for the OUI (Company ID) -- with Ethernet addresses, they already have a 24-bit OUI. But you're right, with sufficient creativity or malevolence, they could arrange to violate my probability assumptions. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 17:14:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28071; Tue, 8 Oct 96 17:14:47 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28065; Tue, 8 Oct 96 17:14:29 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA29316; Tue, 8 Oct 1996 17:08:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA22917; Tue, 8 Oct 1996 17:07:44 -0700 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id RAA19087; Tue, 8 Oct 1996 17:00:48 -0700 Date: Tue, 8 Oct 1996 17:00:48 -0700 From: Ran Atkinson Message-Id: <199610090000.RAA19087@cornpuffs.cisco.com> To: brian@dxcoms.cern.ch Subject: (IPng 2232) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: <9610080649.AA10231@dxcoms.cern.ch> References: <199610071643.AA14429@zed.isi.edu> Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm not a security expert, but it seems to me that IPsec would be cleaner to implement (and more compatible with NAT or application-layer gateways) if it could use EIDs in the packet instead of the addresses in the packet for the bindings of Security Associations. It would require that both EIDs be present in each IPv6 base header. Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 17:46:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28101; Tue, 8 Oct 96 17:46:23 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28095; Tue, 8 Oct 96 17:46:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA06553; Tue, 8 Oct 1996 17:39:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA02437; Tue, 8 Oct 1996 17:39:44 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA18255; Tue, 8 Oct 96 20:33:53 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id UAA21183; Tue, 8 Oct 1996 20:41:49 -0400 Date: Tue, 8 Oct 1996 20:41:49 -0400 Message-Id: <199610090041.UAA21183@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk get ipng ipng.9610 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 17:50:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28113; Tue, 8 Oct 96 17:50:21 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28107; Tue, 8 Oct 96 17:50:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA07445; Tue, 8 Oct 1996 17:43:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA03653; Tue, 8 Oct 1996 17:43:40 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA18266; Tue, 8 Oct 96 20:37:53 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id UAA21185; Tue, 8 Oct 1996 20:45:49 -0400 Date: Tue, 8 Oct 1996 20:45:49 -0400 Message-Id: <199610090045.UAA21185@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk index ipng ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 8 22:14:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28850; Tue, 8 Oct 96 22:14:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28844; Tue, 8 Oct 96 22:14:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA07194; Tue, 8 Oct 1996 22:07:59 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA08067; Tue, 8 Oct 1996 22:07:55 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0v9EPF-000ZBqC; Fri, 4 Oct 96 10:51 PDT Message-Id: Date: Fri, 4 Oct 96 10:51 PDT From: Michael Gersten To: ipng@sunroof.eng.sun.com Subject: (IPng 2233) Re: Renumbering Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One quick question on renumbering for IPv6: DNS? Michael ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 04:47:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29616; Wed, 9 Oct 96 04:47:30 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29610; Wed, 9 Oct 96 04:47:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA28943; Wed, 9 Oct 1996 04:40:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA07281; Wed, 9 Oct 1996 04:40:52 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA28136; Wed, 9 Oct 1996 13:40:50 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA20058; Wed, 9 Oct 1996 13:40:50 +0200 Message-Id: <9610091140.AA20058@dxcoms.cern.ch> Subject: (IPng 2234) Re: IPv6 Other Work in Progress and Needed. To: rja@cisco.com (Ran Atkinson) Date: Wed, 9 Oct 1996 13:40:49 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199610090000.RAA19087@cornpuffs.cisco.com> from "Ran Atkinson" at Oct 8, 96 05:00:48 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 Ran, >--------- Text sent by Ran Atkinson follows: > > I'm not a security expert, we beg to differ > but it seems to me that IPsec would be cleaner to > implement (and more compatible with NAT or application-layer gateways) if it > could use EIDs in the packet instead of the addresses in the packet for the > bindings of Security Associations. It would require that both EIDs be present > in each IPv6 base header. could we get views on that from other security experts? Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 04:55:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29632; Wed, 9 Oct 96 04:55:37 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29626; Wed, 9 Oct 96 04:55:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA29282; Wed, 9 Oct 1996 04:49:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA08499; Wed, 9 Oct 1996 04:49:03 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA29205; Wed, 9 Oct 1996 13:49:00 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA20530; Wed, 9 Oct 1996 13:48:58 +0200 Message-Id: <9610091148.AA20530@dxcoms.cern.ch> Subject: (IPng 2235) Re: IPv6 and 1394.2 (fwd) To: deering@parc.xerox.com (Steve Deering) Date: Wed, 9 Oct 1996 13:48:58 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com In-Reply-To: <96Oct8.145632pdt."75270"@digit.parc.xerox.com> from "Steve Deering" at Oct 8, 96 02:56:31 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 Over in a private conversation, Mike O'Dell pointed out to me that if 64-bit hardware IDs turn up in the future, they could be used for the duration of autoconfiguration only, and then be replaced by a 48-bit software-assigned ID in the assigned IPv6 address. So I don't think we need to worry unduly. Brian >--------- Text sent by Steve Deering follows: > > Thomas, > > > I'll admit that I have only a sketchy understanding of how address > > assignment takes place in the 64-bit space (re: Brian's earlier note > > on 1394.x), but I can't help but wonder if a dangerous assumption is > > being made above. I can imagine company X getting a unique 2-byte > > prefix, and then numbering all its interfaces starting with 1. Company > > Y gets a different 2-byte prefix, and uses the same algorithm. Uh oh. > > Even so, it seems highly unlikely that I would happen to buy, say, interface > number 142 from company X and interface number 142 from company Y, and end > up putting them on the same LAN. > > Anyway, I think they'll end up using more than 16 bits for the OUI (Company > ID) -- with Ethernet addresses, they already have a 24-bit OUI. > > But you're right, with sufficient creativity or malevolence, they could > arrange to violate my probability assumptions. > > Steve > > > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 05:05:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29645; Wed, 9 Oct 96 05:05:43 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29639; Wed, 9 Oct 96 05:05:26 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA29712; Wed, 9 Oct 1996 04:59:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA10278; Wed, 9 Oct 1996 04:59:09 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA30630 for ; Wed, 9 Oct 1996 13:59:08 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA21323; Wed, 9 Oct 1996 13:59:07 +0200 Message-Id: <9610091159.AA21323@dxcoms.cern.ch> Subject: (IPng 2236) Re: suggestion (long) To: ipng@sunroof.eng.sun.com Date: Wed, 9 Oct 1996 13:59:07 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <29557.844797622@munnari.OZ.AU> from "Robert Elz" at Oct 9, 96 04:00:22 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Replying to both kre and jim, I'd say that we have to design to minimise cases where TCP dies, but we can't aim at TCP never dying. So I'd be prepared to accept the risk of race conditions, where a TCP dies because something odd like rehoming happens at both ends within some small delta-T. And I wouldn't design for survival of TCPs after several months of no traffic. In the normal cases, correct use of address deprecation should cover it. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 05:21:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29669; Wed, 9 Oct 96 05:21:27 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29663; Wed, 9 Oct 96 05:21:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA00510; Wed, 9 Oct 1996 05:14:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA13202; Wed, 9 Oct 1996 05:14:55 -0700 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA1756184; Wed, 9 Oct 1996 08:11:30 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id IAA34262; Wed, 9 Oct 1996 08:11:27 -0400 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA14694; Wed, 9 Oct 1996 08:16:15 -0400 Message-Id: <9610091216.AA14694@ludwigia.raleigh.ibm.com> To: "Brian Carpenter CERN-CN" Cc: deering@parc.xerox.com (Steve Deering), ipng@sunroof.eng.sun.com Subject: (IPng 2237) Re: IPv6 and 1394.2 (fwd) In-Reply-To: Your message of "Wed, 09 Oct 1996 13:48:58 +0200." <9610091148.AA20530@dxcoms.cern.ch> Date: Wed, 09 Oct 1996 08:16:15 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Over in a private conversation, Mike O'Dell pointed out to me >that if 64-bit hardware IDs turn up in the future, they could be used >for the duration of autoconfiguration only, and then be >replaced by a 48-bit software-assigned ID in the assigned IPv6 address. >So I don't think we need to worry unduly. Agreed. My main concern (which may be unwarranted) is that telling users to exchange their "broken" cards when duplicates appear seems awfully painful, and I think we can do better. Remember, we're talking about ubiquitous networking where you have to go exchange your brand new car or freezer because it won't connect to the network (plus it works fine when you take it back to the store :-)? Also, although the odds that *you* *individually* will ever run into duplicates might be pretty much nil, the odds that *somebody* will is a lot higher. It's the same argument that has some folks suggesting that the recent downed TWA flight could have been hit by a meteor (i.e., the odds are far from nil that no plane will ever get hit given the number of planes and meteors sharing a finite air space). Something simple like extending autoconfig to try alternate addresses in the case of duplicates (e.g., by hashing based on the 64 bit ID and other local info) would probably suffice and could be added later without too much pain. In any case, I don't see there being much for us to do right now. We certainly can't reserve 64 bits of an IPv6 address for a local identifier. The address space layout seems pretty well defined at this point with end sites assuming they have only the right-most 64 bits to play with. They'll need 1-2 of those bytes for internal routing. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 07:51:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29788; Wed, 9 Oct 96 07:51:43 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29782; Wed, 9 Oct 96 07:51:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA14338; Wed, 9 Oct 1996 07:45:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA27495; Wed, 9 Oct 1996 07:45:07 -0700 Received: from gungnir.fnal.gov ("port 33372"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IAFNQ9BCYC002X4H@FNAL.FNAL.GOV>; Wed, 09 Oct 1996 09:45:04 -0600 (CST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA06151; Wed, 09 Oct 1996 09:45:00 -0500 Date: Wed, 09 Oct 1996 09:45:00 -0500 From: Matt Crawford Subject: (IPng 2238) Re: IPv6 and 1394.2 (fwd) In-Reply-To: "08 Oct 1996 14:56:31 PDT." <96Oct8.145632pdt."75270"@digit.parc.xerox.com> To: Steve Deering Cc: Thomas Narten , ipng@sunroof.eng.sun.com Message-Id: <199610091445.JAA06151@gungnir.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Even so, it seems highly unlikely that I would happen to buy, say, interface > number 142 from company X and interface number 142 from company Y, and end > up putting them on the same LAN. On the other hand, if a place like Fermilab thought that Serial Express might be the answer to our next-generation data collection problems, we might buy the first available units from several vendors, which would raise the chance of a clash in the low bits. On the other hand, IPv6-over-1394.2 might specify that the address token is some less trivial function of the 64-bit identifier. Or it might use some upper bits of the 1212 address (which has 10 bits of bus ID, 6 bits of node id, 48 bits intra-node). In short, I wouldn't panic about 64 bit identifiers at this point. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 08:13:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00242; Wed, 9 Oct 96 08:13:23 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00233; Wed, 9 Oct 96 08:13:09 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17774; Wed, 9 Oct 1996 08:06:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA05433; Wed, 9 Oct 1996 08:06:51 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16368(9)>; Wed, 9 Oct 1996 08:06:40 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 9 Oct 1996 08:06:21 PDT To: Thomas Narten Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2239) Re: IPv6 and 1394.2 (fwd) In-Reply-To: narten's message of Wed, 09 Oct 96 04:16:15 -0800. <9610091216.AA14694@ludwigia.raleigh.ibm.com> Date: Wed, 9 Oct 1996 08:06:21 PDT From: Steve Deering Message-Id: <96Oct9.080621pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, So, are you suggesting that airplanes ought to be hardened against meteor strikes because there is a non-zero probability that such a strike could occur? > Remember, we're talking > about ubiquitous networking where you have to go exchange your brand > new car or freezer because it won't connect to the network... Generally, fixing a problem with some component of a car does not require exchanging the whole car for a new one. Anyway, I think we've flogged this one to death. I think we've agreed that an evolution to 64-bit LAN addresses will not necessitate increasing the IPv6 autoconfig token size to more than 48 bits. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 08:58:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00546; Wed, 9 Oct 96 08:58:29 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00540; Wed, 9 Oct 96 08:58:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA26556; Wed, 9 Oct 1996 08:51:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA22424; Wed, 9 Oct 1996 08:51:17 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id LAA06282; Wed, 9 Oct 1996 11:50:53 -0400 (EDT) Message-Id: <199610091550.LAA06282@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Michael Gersten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2240) Re: Renumbering In-Reply-To: Your message of "Fri, 04 Oct 1996 10:51:00 PDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 09 Oct 1996 11:50:52 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Gersten writes: > One quick question on renumbering for IPv6: > > DNS? Thats what the dynamic update stuff is supposed to be for... .pm ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 09:42:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00586; Wed, 9 Oct 96 09:42:07 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00580; Wed, 9 Oct 96 09:41:48 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA06919; Wed, 9 Oct 1996 09:35:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA08733; Wed, 9 Oct 1996 09:34:31 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id MAA06335; Wed, 9 Oct 1996 12:33:52 -0400 (EDT) Message-Id: <199610091633.MAA06335@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: "Brian Carpenter CERN-CN" Cc: rja@cisco.com (Ran Atkinson), ipng@sunroof.eng.sun.com Subject: (IPng 2241) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Wed, 09 Oct 1996 13:40:49 +0200." <9610091140.AA20058@dxcoms.cern.ch> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Wed, 09 Oct 1996 12:33:47 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Brian Carpenter CERN-CN" writes: > Ran, > > I'm not a security expert, > > we beg to differ > > > but it seems to me that IPsec would be cleaner to implement (and > > more compatible with NAT or application-layer gateways) if it > > could use EIDs in the packet instead of the addresses in the > > packet for the bindings of Security Associations. It would > > require that both EIDs be present in each IPv6 base header. > > could we get views on that from other security experts? I don't have the cojones to call myself a security expert either, but I'll chime in anyway in my capacity as an IPSec weenie. My opinion: I tend to agree with Ran on this. HOWEVER, I'd say that it would be much easier to comment in general if there were a real EID spec -- without exact semantics of EIDs, it is difficult to know if associations should be bound to the EID or to the address or both -- but there are so many ideas of what EIDs would be that its hard to know. Every attempt to produce one has lead to lots of people saying they want EIDs but very little consensus developing on exact semantics. This sort of thing is ripe (perhaps overripe) for a couple of design teams to go off and actually implement a couple of experimental EID based systems and see what they end up looking like. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 10:29:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00684; Wed, 9 Oct 96 10:29:26 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00678; Wed, 9 Oct 96 10:29:13 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA18820; Wed, 9 Oct 1996 10:22:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA26673; Wed, 9 Oct 1996 10:22:09 -0700 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA2210464; Wed, 9 Oct 1996 13:17:59 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id NAA33858; Wed, 9 Oct 1996 13:17:55 -0400 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA11306; Wed, 9 Oct 1996 13:22:02 -0400 Message-Id: <9610091722.AA11306@ludwigia.raleigh.ibm.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2242) Re: IPv6 and 1394.2 (fwd) In-Reply-To: Your message of "Wed, 09 Oct 1996 08:06:21 PDT." <96Oct9.080621pdt."75270"@digit.parc.xerox.com> Date: Wed, 09 Oct 1996 13:22:01 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, >So, are you suggesting that airplanes ought to be hardened against meteor >strikes because there is a non-zero probability that such a strike could >occur? Er um, not really. But the thought of developing and deploying meteor-shooting lasers in airplanes might just appeal to some. :-) >Anyway, I think we've flogged this one to death. Ahh, but things were just starting to get fun. :-) Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 11:56:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00805; Wed, 9 Oct 96 11:56:48 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00799; Wed, 9 Oct 96 11:56:35 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA09658; Wed, 9 Oct 1996 11:50:11 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id LAA16351; Wed, 9 Oct 1996 11:49:46 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA15602; Wed, 9 Oct 1996 14:41:12 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28625; Wed, 9 Oct 1996 14:41:04 -0400 Message-Id: <9610091841.AA28625@fwasted.zk3.dec.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2243) Re: suggestion (long) In-Reply-To: Your message of "Wed, 09 Oct 96 13:59:07 +0200." <9610091159.AA21323@dxcoms.cern.ch> Date: Wed, 09 Oct 96 14:41:04 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >Replying to both kre and jim, I'd say that we have to design >to minimise cases where TCP dies, but we can't aim at TCP >never dying. So I'd be prepared to accept the risk of race >conditions, where a TCP dies because something odd like >rehoming happens at both ends within some small delta-T. >And I wouldn't design for survival of TCPs after several >months of no traffic. In the normal cases, correct use >of address deprecation should cover it. This sounds very reasonable to me. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 12:17:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00843; Wed, 9 Oct 96 12:17:54 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00827; Wed, 9 Oct 96 12:15:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA14064; Wed, 9 Oct 1996 12:08:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA24479; Wed, 9 Oct 1996 12:08:35 -0700 Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.7.5/1.207) with SMTP id PAA11090 for ; Wed, 9 Oct 1996 15:08:31 -0400 (EDT) Date: Wed, 9 Oct 1996 15:08:31 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: kgk@ott.hookup.net (Keith G Knightson) Subject: (IPng 2244) On the subject of Subject EIDs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gentlemen, I may beout to lunch here but I have to ask... Suppose there are two TCP connections, or perhaps even more, between the same pair of hosts at the time that the address change/move (or whatever) occurs (at one or both ends). A single identifier at the IP level is not sufficient to uniquely unambiguously identify/maintain each of the two (or more) TCP connections between a given pair of hosts. Is it? This seems to indicate that that the unique identification is absolutely required at the TCP level and cannot even be single valued per user/host or whatever. Don't you need as many EIDs as you have TCP connections? Am I talking through my hat or what? Cheers Keith ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 12:31:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00858; Wed, 9 Oct 96 12:31:03 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00852; Wed, 9 Oct 96 12:30:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA17715; Wed, 9 Oct 1996 12:23:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA00154; Wed, 9 Oct 1996 12:23:41 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16252(5)>; Wed, 9 Oct 1996 12:23:37 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 9 Oct 1996 12:23:22 PDT To: fred@cisco.com, yakov@cisco.com Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com Subject: (IPng 2245) use of IPv6 Flow Label for tag switching In-Reply-To: yakov's message of Tue, 08 Oct 96 11:18:06 -0800. <199610081818.LAA27998@hubbub.cisco.com> Date: Wed, 9 Oct 1996 12:23:22 PDT From: Steve Deering Message-Id: <96Oct9.122322pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred and Yakov, Here are some comments/questions on your draft for using IPv6 Flow Labels as tags, draft-baker-flow-label-00.txt. I also include some comments/ questions about tag switching in general. I am cc-ing this message to both the ipng list and the tagswitch list; I suggest that follow-ups on the IPv6-specifics should go to ipng only, and on the general issues to tagswitch only. First of all, it would be *really* helpful if the flurry of tag-switching related drafts all had the word "tag" in their file names, to make them easier to find. Of the three I have looked at so far, draft-rfced-info-rekhter-00.txt draft-doolan-tdp-spec-00.txt draft-baker-flow-label-00.txt *none* of them have "tag" in their names; the first one is especially unhelpful. I am happy to see proposals and discussion about ways of using the IPv6 Flow Label field, including possible changes in its semantics. The IPv6 spec acknowledges that this aspect of the protocol is subject to such changes. Have you run this proposal by the Ipsilon folks? Is there anyone else out there inventing novel ways to bypass IP processing for IP packets? A change of semantics that would serve the purposes of all vendors playing in this space is much more acceptable than one that serves only one vendor's scheme, especially an untested one. > G G=0 indicates global end-to-end flow label definition, > G=1 indicates hop-by-hop flow label definition (tag). I assume "G" stands for global? If so, it is counterintuitive to have the zero value mean global and the one value mean non-global. I suggest you change the name of the bit to "H" (hop-by-hop) or "T" (tag). > If a router is not capable of using a tag, and the router receives an > IPv6 packet that carries a tag, the router forwards the packet > following the normal IPv6 procedures. That seems wrong. Doesn't that create the hazard that the tagged packet may be forwarded through some number of tag-ignorant routers and then hit a tagging router that has allocated that packet's tag to some other use? I would have expected you to require tag-ignorant routers to at least zero-out the tag field, if a tag is present. You need to specify that IPv6 packets carrying hop-by-hop options must never be tag-switched. (You'll need a similar rule for IPv4 packets, to ensure that options like Router Alert work properly.) I would like to see your protocol or algorithm for allocating tags to multicast packets being forwarded over multiaccess links. In the absence of an acceptable solution to that problem, I would object to adopting your proposed changes to IPv6. General tag switching questions: Packets that are tag-switched apparently do not have their TTLs/hop-limits decremented at each hop. You propose tag establishment driven by routing protocols. Typical IP routing protocols can create looping paths during times of topology change, loops that may exist for as long as tens of seconds. Does this mean that tag-switched packets may loop until the routing protocol converges (imagine millions of video packets stuck in a routing loop for many seconds), or do you require that routing protocols used with tag- switching be designed to never cause transient loops, or do you have some other solution to this problem? I don't recall any mention in your documents of the consequences of address filtering on tag switching. The fact that a routing entry says that packets to a particular destination should go along a certain path, does not imply that all packets to that destination can be tag-switched all the way through. You probably need to either disable tag switching in filtering routers (or for interfaces on which filters are in place, or perhaps at some finer grain), or arrange for filters to be conveyed upstream to the point at which the tagging starts. I presume tag-switching doesn't work through NAT routers, since NAT requires that IP and higher-layer fields be examined and modified. Note also that NAT boxes are typically placed at bottleneck points (e.g., the point through which all of an organization's external traffic is funneled) where the alleged benefits of tag switching might be most desired. That doesn't particularly bother me, but I know some of you are big fans of NAT. The prevarication of your overview document about whether tags are allocated by the upstream router, the downstream router, or the downstream router on demand by the upstream router seems likely to lead to confusion by people trying to diagnose problems, if not outright interoperability problems. Can't you just pick one method? In section 4.3 of your overview document, you use the term "spanning tree" in a way that differs from its use in the literature. A spanning tree is a single tree that spans all the nodes of a network, like the tree that ethernet bridges/switches route over. The trees that all existing IP multicast algorithms use are not spanning trees, according to the classic definition. General Lament: Tag switching looks to me like an admission of failure to build IP routers that are performance and cost competitive with layer 2 switches -- yet another layer of protocol/adddressing/complexity to forestall doing the right thing. Either that, or a last-ditch attempt to keep ATM from tanking. All of these devices -- routers, Ethernet bridges/switches, frame-relay switches, ATM switches -- are packet switches that do essentially the same job: receive a packet (or cell), look at some header bits to figure out what outgoing interface to use, queue the packet on that interface, and send it. Yes, the IP address lookup function is in theory more expensive than the ATM or frame-relay VC look-up (but not necessarily more expensive than the Ethernet address lookup that gigabit Ethernet switches will supposedly do), but is it really the case that the IP routing look-up cost is or must be a significant part of the total cost of forwarding a packet? Tag-switching will not eliminate the need to build fast routers, but fast routers could eliminate the need for layer 2 switches. Why not pursue *that* goal, which could greatly simplify the manageability, understandability, and robustness of this complex system we work on, rather than perpetrating a direction of ever increasing complexity, multiple, redundant levels of switching, and layers and layers of unnecessary protocols? I suppose that many companies are benefiting from the existance of an artificially stratified market -- it makes for lots of "niches" -- and certainly it creates lots of opportunities in the consulting business. But that doesn't strike me as being in the long term interests of the customers and of society at large. And that's what I lament. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 12:42:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00907; Wed, 9 Oct 96 12:42:38 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00901; Wed, 9 Oct 96 12:42:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA20570; Wed, 9 Oct 1996 12:35:59 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id MAA05713; Wed, 9 Oct 1996 12:35:53 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA15279; Wed, 9 Oct 1996 15:29:08 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA04093; Wed, 9 Oct 1996 15:29:07 -0400 Message-Id: <9610091929.AA04093@fwasted.zk3.dec.com> To: Charlie Perkins Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2246) Re: suggestion (long) (replay) In-Reply-To: Your message of "Wed, 09 Oct 96 13:52:21 CDT." <9610091752.AA17425@hawpub1.watson.ibm.com> Date: Wed, 09 Oct 96 15:29:06 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, >> On the point of translating the address in the binding-update to the HLP >> PCB at the network layer. But that is anchored to the existing IPv6 >> addresses in the PCB is not going to fly for performance reasons. We >> need to use the new address immediately. The good news is that to >> update the PCB is very simple and few lines of code. This will make it >> transparent to the PRU_REQUEST_XXX binding routines, >> tcp_inuput/tcp_output mods etc... ..... > >If I may try to restate your strategy: > >(1) Notification comes to the network layer that a source address > has changed. >(2) Network layer is responsible for triggering the appropriate > action for all higher-level protocols -- which is that they > should fiddle around with their internal data structures > to account for the IP address change. > >Is this correct? If so, then I think your point above is that Yes ... >in the case of TCP, step (2) is not a problem, and we can >confidently go about the business of finding the best method >to achieve step (1). Yes and for example Pedro and I are talking (given our different schedules and time zones) if there is away in our mind to accomodate the mobile binding update for our anycast address spec or what changes we would need in the binding-update to accomodate our anycast strategy. >If a workable system is specified that relies on requiring >higher level protocols to implement step (2), is that going >to be acceptable to the working group? At Montreal it appeared the answer was "maybe" and that Pedro and I should keep doing the work and that it appeared we were on the right track. For the Anycast draft. Our next spec will be a working group item which we feel is progress. This was our second draft to the group too. >> As far as it causing a change to TCP Pedro and I claim that it does NOT >> change the TCP specification at all and is transparent to UDP. ....... >If the (variant) Binding Update is processed at the network layer, >but has effects on data stored in the protocol control blocks, then >TCP has to implement _something_ to make it happen. This can >be viewed as an implementation requirement instead of a change >to the protocol, but in any case it is something that would affect >every HLP that keeps state about source IP addresses. For instance, >I suspect that IPsec would have to undergo analogous modifications >to account for changes in IP addresses. I wonder if those would be >equally easy to implement as your abovementioned changes to TCP. Well by the same logic IPv6 IP Layer packet causes changes to TCP/UDP too but it did not change the TCP/UDP RFCs. I had to make code changes to support IPv6 in TCP and UDP in the sense I don't want to support a dual stack or the UDP checksum is mandatory. As far as IPSEC in most implementations: 1. The IPv6 layer will be parsing options. 2. When the IPSEC option is seen: a) decrypt or authenticate the packet and build the data for the upper layers and provide the parts from the extensions submitted. 3. The SPI association should not have broken because of renumbering. 4. Once the option is available from the authenticate / decrypt operation then the address is updated and verified at the HLP as its changed before hand. >> Now for the application layer listening and that takes inherent >> knowledge of the peer adddress that needs to be addressed and Pedro and >> I are working on that problem at present. >One possibility is that the HLP itself does a mapping between >the peer address expected by the application and the last IP >address it received from the "binding update" message received >from below by way of its network layer. That almost sounds like >a reasonable transport-level operation to me. Maybe it's not >too bad to have the network layer distribute notifications to >all the HLPs, as long as they don't come in too often (in other >words, as long as the relevant networks don't renumber too >often). I think we need to notify the application of the change. I don't mind mappings for routing but applications are much more complex. I don't really want anymore mapping in an already large kernel set which is much greater than presently. I think an urgent pointer or socket-level option will work fine. But I admit I am being a purist here. >Another possibility is that applications make use of an EID-space >IPv6 address (which won't change), but then we get to long-standing >questions about how that address is going to be initially allocated >uniquely, or later located when the application starts up. I feel strongly about what Perry M. just said. No one has been able to define what an EID is and how its created. This I think is the real issue. Paul Francis years ago with PIP came closer than anyone I know of and it relates closely to one of your comments with whats wrong with an EID at times also being a locator. I agree with you fyi. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 13:14:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00972; Wed, 9 Oct 96 13:14:26 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00966; Wed, 9 Oct 96 13:14:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA27770; Wed, 9 Oct 1996 13:07:26 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id NAA16891; Wed, 9 Oct 1996 13:07:16 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id QAA09209; Wed, 9 Oct 1996 16:07:15 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA08722; Wed, 9 Oct 1996 16:07:14 -0400 Message-Id: <9610092007.AA08722@fwasted.zk3.dec.com> To: kgk@ott.hookup.net (Keith G Knightson) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2247) Re: On the subject of Subject EIDs In-Reply-To: Your message of "Wed, 09 Oct 96 15:08:31 EDT." Date: Wed, 09 Oct 96 16:07:14 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, >I may beout to lunch here but I have to ask... No your on the target. >Suppose there are two TCP connections, or perhaps even more, between the >same pair of hosts at the time that the address change/move (or whatever) >occurs (at one or both ends). A single identifier at the IP level is not >sufficient to uniquely unambiguously identify/maintain each of the two (or >more) TCP connections between a given pair of hosts. >Is it? No all it does is identify the node. We still need to know the locator. I agree so what good is it? I just responded to 6bone similar discussion that I asked a customer once about this who is quite technical and their response was the same as yours. But if the address is the EID than why call it an EID its an address. >This seems to indicate that that the unique identification is absolutely >required at the TCP level and cannot even be single valued per user/host or >whatever. Don't you need as many EIDs as you have TCP connections? And for TCP the IPv6 address does that exactly. Even if it changes we have that covered in IPv6 except in some cases. >Am I talking through my hat or what? No. I think you bring another good point to this discu_ussion. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 13:16:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00988; Wed, 9 Oct 96 13:16:18 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA00982; Wed, 9 Oct 96 13:16:05 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA28273; Wed, 9 Oct 1996 13:09:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA17706; Wed, 9 Oct 1996 13:09:37 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16487(5)>; Wed, 9 Oct 1996 13:07:05 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 9 Oct 1996 13:06:40 PDT To: fred@cisco.com, yakov@cisco.com Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com Subject: (IPng 2248) Re: use of IPv6 Flow Label for tag switching In-Reply-To: deering's message of Wed, 09 Oct 96 12:23:22 -0800. <96Oct9.122322pdt."75270"@digit.parc.xerox.com> Date: Wed, 9 Oct 1996 13:06:39 PDT From: Steve Deering Message-Id: <96Oct9.130640pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I wrote: > The prevarication of your overview document... Some one kindly pointed out to me that "prevarication" is probably not the word I should have used there. I thought "to prevaricate" meant to waffle, to refuse to make a decision. In fact it means to deviate from the truth, to lie, which is *not at all* what I meant. I apologize for any offence that I may have caused. (That should teach me to use such big words without looking them up in the dictionary first.) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 14:15:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01058; Wed, 9 Oct 96 14:15:07 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01033; Wed, 9 Oct 96 14:05:41 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA09583; Wed, 9 Oct 1996 13:58:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA06104; Wed, 9 Oct 1996 13:58:42 -0700 Received: from test-pc.cisco.com (dhcp-g2-205.cisco.com [171.68.239.205]) by lintjr.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id NAA28871; Wed, 9 Oct 1996 13:58:15 -0700 Message-Id: <2.2.32.19961009205805.009e91b4@lintjr.cisco.com> X-Sender: aalles@lintjr.cisco.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 09 Oct 1996 13:58:05 -0700 To: Steve Deering , fred@cisco.com, yakov@cisco.com From: Anthony Alles Subject: (IPng 2249) Re: use of IPv6 Flow Label for tag switching Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >General Lament: > >Tag switching looks to me like an admission of failure to build IP routers >that are performance and cost competitive with layer 2 switches -- yet another >layer of protocol/adddressing/complexity to forestall doing the right thing. >Either that, or a last-ditch attempt to keep ATM from tanking. > >All of these devices -- routers, Ethernet bridges/switches, frame-relay >switches, ATM switches -- are packet switches that do essentially the same >job: receive a packet (or cell), look at some header bits to figure out what >outgoing interface to use, queue the packet on that interface, and send it. >Yes, the IP address lookup function is in theory more expensive than the ATM >or frame-relay VC look-up (but not necessarily more expensive than the >Ethernet address lookup that gigabit Ethernet switches will supposedly do), >but is it really the case that the IP routing look-up cost is or must be >a significant part of the total cost of forwarding a packet? > >Tag-switching will not eliminate the need to build fast routers, but fast >routers could eliminate the need for layer 2 switches. Why not pursue *that* >goal, which could greatly simplify the manageability, understandability, and >robustness of this complex system we work on, rather than perpetrating a >direction of ever increasing complexity, multiple, redundant levels of >switching, and layers and layers of unnecessary protocols? I suppose that >many companies are benefiting from the existance of an artificially >stratified market -- it makes for lots of "niches" -- and certainly it >creates lots of opportunities in the consulting business. But that >doesn't strike me as being in the long term interests of the customers and >of society at large. And that's what I lament. Hmmm, I sense the slippery slope of a religious war here, so I will try to avoid that. I will say that we don't necessarily see tag switching as an alternative to building fast routers or anything else, for that matter. I prefer to think of tag switching (and Ipsilon's IP switching too) as a way of both modifying existing layer 2 switches to optimize the performance of mixed router/switch networks and also a way of modifying routers to enable them to have some of the same traffic management mechanisms previously available only in layer 2 switches. The reality is that both layer 2 switches and layer 3 routers will continue to exist - albeit increasingly in 'blended' fashions that might make these labels somewhat arbitrary - hence ways of fusing the best capabilities of each seems to be a pragmatic way of solving real world problems. That statement in itself, however, should not be read as constraining our own product strategies one way or the other. We will continue to give the market whatever they want and need. OK, enough advertising! :-) Anthony _____________________________________________________________________ Anthony Alles Cisco Systems Director, ATM Product Marketing Tel: +1-408-526-5424 email: aalles@cisco.com Fax: +1-408-526-6488 Mail: 170 West Tasman Drive, San Jose CA 95134-1706, USA. Cisco Location: Building G, San Jose Single Site. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 14:38:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01074; Wed, 9 Oct 96 14:38:03 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01068; Wed, 9 Oct 96 14:37:50 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA17238; Wed, 9 Oct 1996 14:31:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA18025; Wed, 9 Oct 1996 14:31:08 -0700 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id OAA00208; Wed, 9 Oct 1996 14:31:05 -0700 Received: from fred-axel-fr (localhost.cisco.com [127.0.0.1]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id OAA00609; Wed, 9 Oct 1996 14:31:04 -0700 Message-Id: <325C1998.ABD322C@cisco.com> Date: Wed, 09 Oct 1996 14:31:04 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: Steve Deering Cc: yakov@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 2250) Re: use of IPv6 Flow Label for tag switching References: <96Oct9.122322pdt."75270"@digit.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > Have you run this proposal by the Ipsilon folks? Is there anyone else > out there inventing novel ways to bypass IP processing for IP packets? > A change of semantics that would serve the purposes of all vendors > playing in this space is much more acceptable than one that serves > only one vendor's scheme, especially an untested one. We have run this by Bob Hinden, who suggested some changes and was interested in becoming an author if we changed it enough to accomodate the Ipsilon approach. We're certainly willing to see the document become a working group document, in which case it would incorporate ideas from wherever, but we felt the clearest picture of our proposal would be to submit it in the context of the other ideas we're presenting, at least in the first description. > > > G G=0 indicates global end-to-end flow label definition, > > G=1 indicates hop-by-hop flow label definition (tag). > > I assume "G" stands for global? If so, it is counterintuitive to have > the zero value mean global and the one value mean non-global. I > suggest you change the name of the bit to "H" (hop-by-hop) or "T" > (tag). As you wish > I would have expected you to require tag-ignorant routers to at least > zero-out the tag field, if a tag is present. You are quite correct. I think we had that in mind and neglected to say it. > You need to specify that IPv6 packets carrying hop-by-hop options must > never be tag-switched. (You'll need a similar rule for IPv4 packets, > to ensure that options like Router Alert work properly.) I think that falls out, but it's worth noting. > I would like to see your protocol or algorithm for allocating tags to > multicast packets being forwarded over multiaccess links. In the > absence of an acceptable solution to that problem, I would object to > adopting your proposed changes to IPv6. We are working on a procedure (basically, tags need to be assigned by the router or host that is transmitting the multicast rather than the one that is recieving it) and don't have it ready at this point. Ditto RSVP procedures - one might expect that the tag for RSVP flows would differ from the tag for more general flumps of data. Having said that, did we know all about how to route IP6 unicast before we adopted IP6? Surely we don't have to present the entire architecture in its final state to make a suggestion in a part? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 15:12:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01142; Wed, 9 Oct 96 15:12:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01136; Wed, 9 Oct 96 15:11:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA25692; Wed, 9 Oct 1996 15:05:26 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA13060; Wed, 9 Oct 1996 10:56:29 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id NAA16792; Wed, 9 Oct 1996 13:52:26 -0400 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/10-03-96) with SMTP id NAA506435; Wed, 9 Oct 1996 13:52:22 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA17425; Wed, 9 Oct 1996 13:52:21 -0400 From: Charlie Perkins Message-Id: <9610091752.AA17425@hawpub1.watson.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2251) Re: suggestion (long) (replay) In-Reply-To: Your message of Tue, 08 Oct 96 13:52:37 D. <9610081752.AA23345@fwasted.zk3.dec.com> Date: Wed, 09 Oct 96 13:52:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > On the point of translating the address in the binding-update to the HLP > PCB at the network layer. But that is anchored to the existing IPv6 > addresses in the PCB is not going to fly for performance reasons. We > need to use the new address immediately. The good news is that to > update the PCB is very simple and few lines of code. This will make it > transparent to the PRU_REQUEST_XXX binding routines, > tcp_inuput/tcp_output mods etc... ..... If I may try to restate your strategy: (1) Notification comes to the network layer that a source address has changed. (2) Network layer is responsible for triggering the appropriate action for all higher-level protocols -- which is that they should fiddle around with their internal data structures to account for the IP address change. Is this correct? If so, then I think your point above is that in the case of TCP, step (2) is not a problem, and we can confidently go about the business of finding the best method to achieve step (1). If a workable system is specified that relies on requiring higher level protocols to implement step (2), is that going to be acceptable to the working group? > As far as it causing a change to TCP Pedro and I claim that it does NOT > change the TCP specification at all and is transparent to UDP. ....... If the (variant) Binding Update is processed at the network layer, but has effects on data stored in the protocol control blocks, then TCP has to implement _something_ to make it happen. This can be viewed as an implementation requirement instead of a change to the protocol, but in any case it is something that would affect every HLP that keeps state about source IP addresses. For instance, I suspect that IPsec would have to undergo analogous modifications to account for changes in IP addresses. I wonder if those would be equally easy to implement as your abovementioned changes to TCP. > Now for the application layer listening and that takes inherent > knowledge of the peer adddress that needs to be addressed and Pedro and > I are working on that problem at present. One possibility is that the HLP itself does a mapping between the peer address expected by the application and the last IP address it received from the "binding update" message received from below by way of its network layer. That almost sounds like a reasonable transport-level operation to me. Maybe it's not too bad to have the network layer distribute notifications to all the HLPs, as long as they don't come in too often (in other words, as long as the relevant networks don't renumber too often). Another possibility is that applications make use of an EID-space IPv6 address (which won't change), but then we get to long-standing questions about how that address is going to be initially allocated uniquely, or later located when the application starts up. > /jim Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 15:14:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01164; Wed, 9 Oct 96 15:14:20 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01126; Wed, 9 Oct 96 15:10:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA24998; Wed, 9 Oct 1996 15:04:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA29546; Wed, 9 Oct 1996 15:04:22 -0700 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbksu21776; Wed, 9 Oct 1996 18:04:05 -0400 (EDT) Message-Id: To: Steve Deering Cc: fred@cisco.com, yakov@cisco.com, ipng@sunroof.eng.sun.com, tagswitch@cisco.com, mo@UU.NET Subject: (IPng 2252) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Wed, 09 Oct 1996 12:23:22 PDT." <96Oct9.122322pdt."75270"@digit.parc.xerox.com> Date: Wed, 09 Oct 1996 18:04:05 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Fast routers do not solve the problems that one can address with an explicit level-2 switching layer in a large network. (Tag Switching is a cute proposal for building hybrid L2/L3 boxes wit some interesting twists.) The general problem is easy to state: Given the current IP forwarding model, adequate traffic engineering for large networks is utterly intractable in IP-only networks. Or put another way: The topologies for which the current IP forwarding model can do adequate traffic management are too simple to be useful in the real world. Level 2 and Level 3 *do different jobs* in large networks. The notion that "one level fits all" is simply bankrupt. It worked fine when the world was a few T1s strung between a few boxes, but not in the networks of today or tomorrow. A closely-related notion is that Bandwidth == Capacity. When you have to add network capacity without simply increasing link bandwidth the problems of forcing the traffic across the new capacity become very clear. Whether the FlowID in IPv6 gets used this way is not particularly critical one way or another in my mind. If it isn't, it will get done in the outer framing of the packet. Fine with me. But the assertion that "just build faster routers" solves the problem indicates you don't understand the problem being solved. -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 15:25:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01215; Wed, 9 Oct 96 15:25:58 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01209; Wed, 9 Oct 96 15:25:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA28405; Wed, 9 Oct 1996 15:19:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA04442; Wed, 9 Oct 1996 15:19:07 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16300(5)>; Wed, 9 Oct 1996 15:19:02 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 9 Oct 1996 15:18:42 PDT To: Fred Baker Cc: yakov@cisco.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2253) Re: use of IPv6 Flow Label for tag switching In-Reply-To: fred's message of Wed, 09 Oct 96 14:31:04 -0800. <325C1998.ABD322C@cisco.com> Date: Wed, 9 Oct 1996 15:18:42 PDT From: Steve Deering Message-Id: <96Oct9.151842pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > We have run this by Bob Hinden, who suggested some changes and was > interested in becoming an author if we changed it enough to accomodate > the Ipsilon approach. We're certainly willing to see the document become > a working group document, in which case it would incorporate ideas from > wherever, but we felt the clearest picture of our proposal would be to > submit it in the context of the other ideas we're presenting, at least > in the first description. OK, great. > > You need to specify that IPv6 packets carrying hop-by-hop options must > > never be tag-switched. (You'll need a similar rule for IPv4 packets, > > to ensure that options like Router Alert work properly.) > > I think that falls out, but it's worth noting. Falls out of what? > We are working on a procedure (basically, tags need to be assigned by > the router or host that is transmitting the multicast rather than the > one that is recieving it) and don't have it ready at this point. Ditto > RSVP procedures - one might expect that the tag for RSVP flows would > differ from the tag for more general flumps of data. Good. > Having said that, did we know all about how to route IP6 unicast before > we adopted IP6? Heck, we still don't know all about how to route IPv4! > Surely we don't have to present the entire architecture > in its final state to make a suggestion in a part? Of course not. I just wanted to make sure that that problem was going to be addressed. Tag allocation for multicast is one of the things that added a lot of complication and bugs to the ST protocol (according to the study done by Pink & Partridge), and avoiding that problem was one of the main reasons for specifying end-to-end Flow Labels for IPv6. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 15:46:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01304; Wed, 9 Oct 96 15:46:06 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01298; Wed, 9 Oct 96 15:45:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA03026; Wed, 9 Oct 1996 15:39:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA10901; Wed, 9 Oct 1996 15:39:03 -0700 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id PAA03802; Wed, 9 Oct 1996 15:39:01 -0700 Received: from fred-axel-fr (localhost.cisco.com [127.0.0.1]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id PAA00729; Wed, 9 Oct 1996 15:39:00 -0700 Message-Id: <325C2984.63DECDAD@cisco.com> Date: Wed, 09 Oct 1996 15:39:00 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: Steve Deering Cc: yakov@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 2254) Re: use of IPv6 Flow Label for tag switching References: <96Oct9.151842pdt."75270"@digit.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > > > You need to specify that IPv6 packets carrying hop-by-hop options must > > > never be tag-switched. (You'll need a similar rule for IPv4 packets, > > > to ensure that options like Router Alert work properly.) > > > > I think that falls out, but it's worth noting. > > Falls out of what? Out of the fact that in a tag switch, one doesn't look at anything else. > Of course not. I just wanted to make sure that that problem was going to > be addressed. Tag allocation for multicast is one of the things that added > a lot of complication and bugs to the ST protocol (according to the study > done by Pink & Partridge), and avoiding that problem was one of the main > reasons for specifying end-to-end Flow Labels for IPv6. OK, I'm not in the group of folks that is developing that protocol, but let me air a general architecture for how it might work and you can take pot-shots at it. First, there are 2^N tags that a system might have in its name space - the tags that it will assign. This isn't automatically 2^23; one could easily imagine a system that routinely handles 2^16 routes and 2^17 simultaneous flows having 2^17 entries in its tag table. Of those 2^N tags, let's imagine that half are assignable by a system to unicast routes going through it, and the other half are negotiable. Since tags are local, one could imagine a protocol among the systems in a local domain in which (central version) a "local tag use authorization authority" assigns tags to any of the systems that asks for a tag. Once the tag is assigned, the system that asked for it now advertises to its neighbors "I know that you are not locally assigning this tag, and the numbering authority gave me permission to assign it, so I am assigning it to traffic on multicast address from system coming through me onto this interface." I would do some periodic refresh with the assignment authority so the that the authority knows that it is still using it, and perhaps a positive relinquish later. Distributed version 1: one could imagine a bidding system, in which folks needing to use a tag select one of the available negotiable numbers at random and say "I wish to use this, does anyone care?". If someone cares, it repeats the procedure, otherwise it uses it. Yes, interesting race conditions, but I suspect that they are solvable. Distributed version 2: a different bidding system, in which systems that may in the future need a tag value bid *now* for a set of values. Perhaps they have a periodic message in which they list the currently unused values that they plan to use in the future, and remove from their own list any that are being advertised by their peers. When in the future they need a value, the select one that they have been planning to use for some time and nobody has contested. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 15:46:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01311; Wed, 9 Oct 96 15:46:41 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01305; Wed, 9 Oct 96 15:46:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA00537; Wed, 9 Oct 1996 15:40:01 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA11214; Wed, 9 Oct 1996 15:40:02 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id PAA10910; Wed, 9 Oct 1996 15:37:30 -0700 (PDT) Message-Id: <199610092237.PAA10910@aland.bbn.com> To: Steve Deering Cc: fred@cisco.com, yakov@cisco.com, ipng@sunroof.eng.sun.com, tagswitch@cisco.com Subject: (IPng 2255) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of Wed, 09 Oct 96 12:23:22 -0700. <96Oct9.122322pdt."75270"@digit.parc.xerox.com> Date: Wed, 09 Oct 96 15:37:29 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk General Lament: Tag switching looks to me like an admission of failure to build IP routers that are performance and cost competitive with layer 2 switches -- yet anot her layer of protocol/adddressing/complexity to forestall doing the right thing . Either that, or a last-ditch attempt to keep ATM from tanking. The latter I believe. It is feasible to build IP routers that are price and cost competitive with layer 2 switches. At least, I'm building a prototype 50 Gb/s router designed to prove that's true. Incidentally, my view is that tag switching/routing is turning one's architecture inside out. It is often useful to put a tag on a packet buffer internal to a box saying "here's how this buffer is handled." The question is whether it is useful or necessary to make that tag externally visible. The other interesting problem is what happens if your tagging algorithm misfires, such that you don't get leverage. I.e., instead of tagging 90% of your traffic, you end up only tagging 9%... Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 15:49:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01332; Wed, 9 Oct 96 15:49:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01326; Wed, 9 Oct 96 15:49:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA00861; Wed, 9 Oct 1996 15:42:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA12172; Wed, 9 Oct 1996 15:42:49 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16002(4)>; Wed, 9 Oct 1996 15:42:42 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 9 Oct 1996 15:42:28 PDT To: "Mike O'Dell" Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com Subject: (IPng 2256) Re: use of IPv6 Flow Label for tag switching In-Reply-To: mo's message of Wed, 09 Oct 96 15:04:05 -0800. Date: Wed, 9 Oct 1996 15:42:28 PDT From: Steve Deering Message-Id: <96Oct9.154228pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, > The general problem is easy to state: > > Given the current IP forwarding model, adequate traffic > engineering for large networks is utterly intractable in > IP-only networks. Yes, you tried to explain that to me in Montreal, and I'm afraid I didn't then, nor do I now, grok exactly why you believe that's true, or whether or not it could be addressed by improvements in IP routing/forwarding. I'm failing to see the fundamental difference between level 2 switches and level 3 switches that requires us to keep both around. I am eager to be educated. In any case, isn't tag switching a proposal to use precisely the IP routing and forwarding model with level 2 switches, the model that you believe is inadequate? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 16:36:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01430; Wed, 9 Oct 96 16:36:12 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01424; Wed, 9 Oct 96 16:35:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA14034; Wed, 9 Oct 1996 16:28:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA25939; Wed, 9 Oct 1996 16:27:59 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.12/8.6.5) id QAA12501; Wed, 9 Oct 1996 16:22:57 -0700 Date: Wed, 9 Oct 1996 16:22:57 -0700 From: Dino Farinacci Message-Id: <199610092322.QAA12501@stilton.cisco.com> To: deering@parc.xerox.com Cc: mo@UU.NET, ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com In-Reply-To: <96Oct9.154228pdt."75270"@digit.parc.xerox.com> (message from Steve Deering on Wed, 9 Oct 1996 15:42:28 PDT) Subject: (IPng 2257) Re: use of IPv6 Flow Label for tag switching Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> In any case, isn't tag switching a proposal to use precisely the IP >> routing and forwarding model with level 2 switches, the model that you >> believe is inadequate? The proposal is to use IP routing protocols and level-2 forwarding mechanisms. Dino ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 16:43:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01478; Wed, 9 Oct 96 16:43:09 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01462; Wed, 9 Oct 96 16:40:01 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA15141; Wed, 9 Oct 1996 16:33:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA27488; Wed, 9 Oct 1996 16:33:16 -0700 Received: from pc.somewhere.in.the.world ([203.111.0.107]) by light.iinet.net.au (8.7.4/8.7.3) with SMTP id JAA05698; Thu, 10 Oct 1996 09:02:53 +0930 Date: Thu, 10 Oct 96 11:49:46 PDT From: "Thomas P. Koltai" Subject: (IPng 2258) Use of IPv6 Flow Label ISP Roamops To: fred@cisco.com, yakov@cisco.com, Steve Deering Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com X-Mailer: Chameleon ARM_55, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gentlemen, I have been lurking and reading. Unfortunately, no-one has come close to my raison detre. Therefore, the following multi-part question: 1. Would it be possible to add a unique 16 digit user identifier to each Tag request. 2. Would the overhead of the addition significantly impact routing throughput. 3. Is the Traffic Cop project shelved ? Tom ------------------------- Thomas P. Koltai Phone: +61-2-261-4884 Mobile: +61-414-574-242 185 Liverpool Street, Sydney NSW 2000 ------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 16:55:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01531; Wed, 9 Oct 96 16:55:53 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01523; Wed, 9 Oct 96 16:55:38 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA18446; Wed, 9 Oct 1996 16:49:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA02281; Wed, 9 Oct 1996 16:49:21 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16555(4)>; Wed, 9 Oct 1996 16:49:19 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 9 Oct 1996 16:49:08 PDT To: Dino Farinacci Cc: mo@uu.net, ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com Subject: (IPng 2259) Re: use of IPv6 Flow Label for tag switching In-Reply-To: dino's message of Wed, 09 Oct 96 16:22:57 -0800. <199610092322.QAA12501@stilton.cisco.com> Date: Wed, 9 Oct 1996 16:49:08 PDT From: Steve Deering Message-Id: <96Oct9.164908pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> In any case, isn't tag switching a proposal to use precisely the IP > >> routing and forwarding model with level 2 switches, the model that you > >> believe is inadequate? > > The proposal is to use IP routing protocols and level-2 forwarding > mechanisms. By the "IP routing and forwarding model", I meant that, with tag switching, packets would be forwarded along exactly the same paths they would follow if they had been IP-routed, even though they are being forwarded at level 2. I thought this forwarding behavior (determined by IP routing) was what Mike found to be inadequate. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 17:48:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01726; Wed, 9 Oct 96 17:48:16 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01720; Wed, 9 Oct 96 17:47:57 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA01812; Wed, 9 Oct 1996 17:40:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA18574; Wed, 9 Oct 1996 17:40:28 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.12/8.6.5) id RAA14524; Wed, 9 Oct 1996 17:35:31 -0700 Date: Wed, 9 Oct 1996 17:35:31 -0700 From: Dino Farinacci Message-Id: <199610100035.RAA14524@stilton.cisco.com> To: deering@parc.xerox.com Cc: mo@uu.net, ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com In-Reply-To: <96Oct9.164908pdt."75270"@digit.parc.xerox.com> (message from Steve Deering on Wed, 9 Oct 1996 16:49:08 PDT) Subject: (IPng 2260) Re: use of IPv6 Flow Label for tag switching Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> By the "IP routing and forwarding model", I meant that, with tag switching, >> packets would be forwarded along exactly the same paths they would follow if >> they had been IP-routed, even though they are being forwarded at level 2. >> I thought this forwarding behavior (determined by IP routing) was what Mike >> found to be inadequate. Understand. BTW, they are forwarded at level 2.5, if that matters at all. Dino ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 18:09:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01796; Wed, 9 Oct 96 18:09:23 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01790; Wed, 9 Oct 96 18:09:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA06640; Wed, 9 Oct 1996 18:02:53 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id SAA25469; Wed, 9 Oct 1996 18:02:53 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA04764; Wed, 9 Oct 1996 20:55:59 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21188; Wed, 9 Oct 1996 20:55:53 -0400 Message-Id: <9610100055.AA21188@fwasted.zk3.dec.com> To: Fred Baker Cc: Steve Deering , yakov@cisco.com, ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 2261) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Wed, 09 Oct 96 14:31:04 PDT." <325C1998.ABD322C@cisco.com> Date: Wed, 09 Oct 96 20:55:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, I just read the arch, tdp, and flow label spec. TAG Comments: 1. I think it would be good if all the specs had tag in their name as Steve noted. 2. Where do we go to discuss/listen about the discussion on TAGs in general but I think the change to the IPv6 flow-label should be discussed here. 3. Its another way to do IP/L2 routing/switching but it seems pretty obvious to me there will be or are already patents on the technology which kinda bums me out if you really want this to be a standard. It could even affect if I even care or anyone else and whether any of this should ever achieve Full Standard? Unless that is not your goal like IFMP being specified? Are you playing the Opens Systems game here or the proprietary game here? 4. I will discuss this in more detail where we are to discuss TAGs but I have a problem with this only being router-to-router and not involving the hosts with the TDP functions defined. I think this is a big mistake architecturally and from an operations perspective. But I will get into that once we get to the TAGs place of discussion. 5. I will stop on TAGs now. Let me know where its to be discussed if at all? -------------------------- IPv6 Flow Label. I say forget it use the hop-by-hop options thats what they are their for in IPv6. This is a protocol invented for routers and potentially for a proprietary patented prototocol parts. As a host vendor I don't want to give up this high-order bit and you should not depend on it in the IPv6 header. Thats my initial posture and feeling. Then you can go do whatever you want except if I set that high order bit don't change it. Which your draft does say if its not zero you can't use it. But if you do use it and the G bit is zero then I as a host assume the behavior specified in IPv6 so making hop-by-hop initially I find distasteful. If TAGs wants to use the flow label I see it only being used if the host left it completely as zeroes when it enters a routing domain where all the routers are TAG routers. Thats fine. But if even 1 bit is set anywhere in the flow-label then I don't think you can use that field for TAGs. Router to ROuter to communicate (e.g. set up) again do what you like I don't care. But the flow-label is very important to host vendors technically and it was not just supported in the IPv6 header to support routers. This should be discussed on the IPng WG list. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 21:41:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03252; Wed, 9 Oct 96 21:41:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03246; Wed, 9 Oct 96 21:41:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA28749; Wed, 9 Oct 1996 21:34:52 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA01235; Wed, 9 Oct 1996 21:34:52 -0700 From: Masataka Ohta Message-Id: <199610100431.NAA09655@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA09655; Thu, 10 Oct 1996 13:31:25 +0900 Subject: (IPng 2262) Re: suggestion (long) (replay) To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Thu, 10 Oct 96 13:31:24 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <9610070715.AA21253@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Oct 7, 96 9:15 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; I'm afraid you are repeating the confusion again and again. > > 3) an transport layer end points such as an end of an > > individual TCP connection > > > In my mind, 3) is essential to allow for rehoming of > transactions within an anycast server group. That's not our problem you wanted to solve. > I think that > is implied by my proposal. Not. Ethernet MAC in your proposal does not identify a rehoming transactions. Please make an archtecturally consistent proposal. What we need to solve is a problem related to a network layer end point, a host, not a transport layer end point, an application on a host. So, never say EID. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 21:43:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03264; Wed, 9 Oct 96 21:43:49 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03258; Wed, 9 Oct 96 21:43:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA28956; Wed, 9 Oct 1996 21:37:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA01660; Wed, 9 Oct 1996 21:37:14 -0700 From: Masataka Ohta Message-Id: <199610100435.NAA09668@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA09668; Thu, 10 Oct 1996 13:35:44 +0900 Subject: (IPng 2263) Re: IPv6 Other Work in Progress and Needed. To: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 10 Oct 96 13:35:43 JST Cc: bound@zk3.dec.com, bmanning@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: <18510.844702577@munnari.OZ.AU>; from "Robert Elz" at Oct 8, 96 1:36 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre; I do really need a clarification. > Whatever is done with EIDs, or the problems that lead to the > demand for them is now looking like being done at a layer above > the IP layer - so the most that is likely to be needed of IPv6 > is an end to end option, and they're clearly intended to be > defined as needed. What does "an end to end option" means? Does the end mean "an transport layer end" or "a network layer end"? So far, porblems mentioned is only related to "a network layer end" ID. So, never say "EID". What we need is "IID", Internet ID. > However, something has to be done to solve the problems before > implementations are shipped in any volume. Whether this is some > change to TCP, or something else is still to be decided, but > shipping the TCP that works over IPv4, to simply work with no > change more than the pseudo-header checksum is simply inadequate. Introduction of network layer ID does affect TCP to some extent. But, we don't need transport layer ID (EID) for mobile hosts and renumbering. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 22:00:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03285; Wed, 9 Oct 96 22:00:32 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03279; Wed, 9 Oct 96 22:00:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA00473; Wed, 9 Oct 1996 21:54:01 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA04491; Wed, 9 Oct 1996 21:54:01 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16953(2)>; Wed, 9 Oct 1996 21:54:00 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Wed, 9 Oct 1996 21:53:47 PDT To: Fred Baker Cc: yakov@cisco.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2264) Re: use of IPv6 Flow Label for tag switching In-Reply-To: fred's message of Wed, 09 Oct 96 15:39:00 -0800. <325C2984.63DECDAD@cisco.com> Date: Wed, 9 Oct 1996 21:53:46 PDT From: Steve Deering Message-Id: <96Oct9.215347pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > OK, I'm not in the group of folks that is developing that protocol, but > let me air a general architecture for how it might work and you can take > pot-shots at it. OK, here is one pot-shot: All of your proposed solutions are subject to failure after a partitioned subnetwork heals, if duplicate tags happened to be allocated in the different partitions. So you're going to need to run some sort of duplicate-tag detection, or partition-healing detection protocol, and it's probably going to have to detect the healing event fairly rapidly to avoid long durations of tagged packets streaming off in the wrong directions, which could mean a lot of busy-work pinging or something. More detail please. :-) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 22:45:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03339; Wed, 9 Oct 96 22:45:39 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03333; Wed, 9 Oct 96 22:45:21 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA03787; Wed, 9 Oct 1996 22:39:04 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id WAA10688 for ; Wed, 9 Oct 1996 22:39:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA10688; Wed, 9 Oct 1996 22:39:05 -0700 From: Masataka Ohta Message-Id: <199610100538.OAA09909@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA09909; Thu, 10 Oct 1996 14:38:01 +0900 Subject: (IPng 2265) Re: IPv6 and 1394.2 (fwd) To: deering@parc.xerox.com (Steve Deering) Date: Thu, 10 Oct 96 14:38:00 JST Cc: narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com In-Reply-To: <96Oct9.080621pdt."75270"@digit.parc.xerox.com>; from "Steve Deering" at Oct 9, 96 8:06 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > So, are you suggesting that airplanes ought to be hardened against meteor > strikes because there is a non-zero probability that such a strike could > occur? You are assuming that: Locally (randomly) generated 6 (*NOT* 8) byte MAC addresses won't practically cause accidental address collision. But, through the experience with Ethernet, our consensus today is that you are wrong. We have a collision detection mechanism NOT to encourage collision but to recognize a disasterous situation. As the 16 byte IPv6 address is long enough, we can accomodate 8 byte host ID with no pain. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 22:59:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03362; Wed, 9 Oct 96 22:59:24 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03356; Wed, 9 Oct 96 22:59:06 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA04674; Wed, 9 Oct 1996 22:52:48 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id WAA12888 for ; Wed, 9 Oct 1996 22:52:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA12888; Wed, 9 Oct 1996 22:52:48 -0700 From: Masataka Ohta Message-Id: <199610100552.OAA09970@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA09970; Thu, 10 Oct 1996 14:51:49 +0859 Subject: (IPng 2266) Re: suggestion (long) (replay) To: charliep@watson.ibm.com (Charlie Perkins) Date: Thu, 10 Oct 96 14:51:49 JST Cc: tera@csl.sony.co.jp, ipng@sunroof.eng.sun.com In-Reply-To: <9610081533.AA33120@hawpub1.watson.ibm.com>; from "Charlie Perkins" at Oct 8, 96 11:33 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie; > Having the source address contain a static identifier has > the advantage of simplifying TCP, but there are these > disadvantages: > 1) networks can be renumbered in IPv6, so that identifiers > based on network addresses should be changeable too, and You are wrong here at the very first assumption. Networks can be renumbered in IPv6. But, it has nothing to do with identification. As we have as long as 16 bytes for IPv6 addresses, the identifier part and the routable part may be separated. For example, it is completely possible to have a location- independent 8 byte identifier part which is USEFUL for mobility and a location-dependent 8 byte locator part which hierarchically identifies a subnet. > So far, we have chosen to live with these disadvantages, because > the advantage of compatibility with existing TCP is a very big > advantage. With the ID/locator separation, only change to TCP over IPv4 is, for the maintainance of connection table in host, NOT to use the entire 16 byte of address (which is already a change from IPv4 that address is 4 byte long) but to use the 8 byte identificatin part only. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 9 23:04:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03378; Wed, 9 Oct 96 23:04:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03372; Wed, 9 Oct 96 23:04:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA05030; Wed, 9 Oct 1996 22:57:53 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id WAA13780 for ; Wed, 9 Oct 1996 22:57:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA13780; Wed, 9 Oct 1996 22:57:54 -0700 From: Masataka Ohta Message-Id: <199610100556.OAA09995@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA09995; Thu, 10 Oct 1996 14:56:38 +0900 Subject: (IPng 2267) Re: On the subject of Subject EIDs To: bound@zk3.dec.com Date: Thu, 10 Oct 96 14:56:37 JST Cc: kgk@ott.hookup.net, ipng@sunroof.eng.sun.com In-Reply-To: <9610092007.AA08722@fwasted.zk3.dec.com>; from "bound@zk3.dec.com" at Oct 9, 96 4:07 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Keith, > > >I may beout to lunch here but I have to ask... Keith, you are absolutely correct. > >Suppose there are two TCP connections, or perhaps even more, between the > >same pair of hosts at the time that the address change/move (or whatever) > >occurs (at one or both ends). A single identifier at the IP level is not > >sufficient to uniquely unambiguously identify/maintain each of the two (or > >more) TCP connections between a given pair of hosts. > > >Is it? > > No all it does is identify the node. We still need to know the locator. Jim, "it", here, is an IP level identifier. With the single IP level ID, you can't map it to two locators. > But if the address > is the EID than why call it an EID its an address. Please, never, mention EID. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 01:01:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03825; Thu, 10 Oct 96 01:01:32 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03819; Thu, 10 Oct 96 01:01:17 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA12985; Thu, 10 Oct 1996 00:55:00 -0700 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA01031 for ; Thu, 10 Oct 1996 00:55:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA01031; Thu, 10 Oct 1996 00:55:00 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA22007 for ; Thu, 10 Oct 1996 09:54:58 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA09957; Thu, 10 Oct 1996 09:54:58 +0200 Message-Id: <9610100754.AA09957@dxcoms.cern.ch> Subject: (IPng 2268) Re: suggestion (long) (replay) To: ipng@sunroof.eng.sun.com Date: Thu, 10 Oct 1996 09:54:58 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199610100431.NAA09655@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Oct 10, 96 01:31:24 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 Masataka, > Not. Ethernet MAC in your proposal does not identify a rehoming > transactions. Correct. If a group of servers are configured to rehome transactions among themselves, they would have to use non-hardware dependent IDs. But if you look again at my original note, you will see that it allows for other formats than IEEE MAC, and says If an ongoing transaction is rehomed, its new host MUST use the same EID and port number. [This limits rehoming to a smallish group of co-managed hosts, but that is presumably reasonable.] > > Please make an archtecturally consistent proposal. > I think I did. Brian ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 02:32:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03976; Thu, 10 Oct 96 02:32:41 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03970; Thu, 10 Oct 96 02:32:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA17932; Thu, 10 Oct 1996 02:26:00 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA13579 for ; Thu, 10 Oct 1996 02:26:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id CAA13579; Thu, 10 Oct 1996 02:26:00 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA20248; Thu, 10 Oct 1996 19:22:34 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Masataka Ohta Cc: bound@zk3.dec.com, bmanning@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 2269) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Thu, 10 Oct 1996 13:35:43 +0200." <199610100435.NAA09668@necom830.hpcl.titech.ac.jp> Date: Thu, 10 Oct 1996 19:22:30 +1000 Message-Id: <10112.844939350@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 10 Oct 96 13:35:43 JST From: Masataka Ohta Message-ID: <199610100435.NAA09668@necom830.hpcl.titech.ac.jp> What does "an end to end option" means? I meant one of the options carried in IPv6 headers that is created at the source, and never seen again until it reaches the destination (ie: not examined or touched by routers along the way - if the packet is encrypted, it can be inside the encrypted section). Does the end mean "an transport layer end" or "a network layer end"? Network layer - but it is relaly just data the net layer is carrying, of not particular use to it - if you like, just another small payload in addition to the transport data. What we need is "IID", Internet ID. I don't care what it is called... The point with the *ID that I would like would be that it need not be related 1::1 with anything physical (certainly not an interface, but not necessarily a processor (or set of processors) either). One thing that we think of as a computer could have several *ID's, and what's more, some of those *ID's may be able to shift from one computer to another (without affecting others that remain). Much of this is just research, I have no plans to have anything like that implemented tomorrow, but I would not like the *ID decisions to make assumptions that preclude this. That's why EID - it identifies the end point of some communications, whatever that end point might be. Introduction of network layer ID does affect TCP to some extent. Yes, but not much. Two things come immediately to mind - one is that the IPv4 addr is the current TCP ID, so wherever the address is now used by TCP - other than where it is used for sending outgoing packets - would need to be replaced by the *ID. And second, assumptions that are made about security (if the IPv4 addr is bogus they won't get the packets I send...) need to be revisited. But, we don't need transport layer ID (EID) for mobile hosts and renumbering. Not only for that I would agree. I believe however that if one existed (some kind of ID) those things become easier to design - there are less impediments to worry about. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 09:12:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04168; Thu, 10 Oct 96 09:12:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04162; Thu, 10 Oct 96 09:11:50 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA22404; Thu, 10 Oct 1996 09:05:32 -0700 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA14443; Thu, 10 Oct 1996 09:05:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA14443; Thu, 10 Oct 1996 09:05:14 -0700 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id IAA10078; Thu, 10 Oct 1996 08:57:02 -0700 Received: from fred-axel-fr (localhost.cisco.com [127.0.0.1]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id IAA02071; Thu, 10 Oct 1996 08:57:01 -0700 Message-Id: <325D1CCD.33590565@cisco.com> Date: Thu, 10 Oct 1996 08:57:01 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: "Thomas P. Koltai" Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com Subject: (IPng 2270) Re: Use of IPv6 Flow Label ISP Roamops References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas P. Koltai wrote: > 1. Would it be possible to add a unique 16 digit user identifier to > each Tag request. why? (digit? I assume you mean BCD digit, for 8 bytes) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 09:30:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04249; Thu, 10 Oct 96 09:30:06 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04243; Thu, 10 Oct 96 09:29:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26658; Thu, 10 Oct 1996 09:23:34 -0700 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA22117 for ; Thu, 10 Oct 1996 09:23:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA22117; Thu, 10 Oct 1996 09:23:33 -0700 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id JAA10990; Thu, 10 Oct 1996 09:23:31 -0700 Received: from fred-axel-fr (localhost.cisco.com [127.0.0.1]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id JAA02123; Thu, 10 Oct 1996 09:23:30 -0700 Message-Id: <325D22FC.773C2448@cisco.com> Date: Thu, 10 Oct 1996 09:23:24 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 2.02 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2271) Re: use of IPv6 Flow Label for tag switching References: <9610100055.AA21188@fwasted.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: > 2. Where do we go to discuss/listen about the discussion on TAGs in > general but I think the change to the IPv6 flow-label should be > discussed here. you might try tagswitch@cisco.com. Do you want me to add you to it? > 3. Its another way to do IP/L2 routing/switching but it seems pretty > obvious to me there will be or are already patents on the technology > which kinda bums me out if you really want this to be a standard. It > could even affect if I even care or anyone else and whether any of this > should ever achieve Full Standard? Unless that is not your goal like > IFMP being specified? Are you playing the Opens Systems game here or > the proprietary game here? I think we're saying that this is something that we're working on and think we can make work well; if it does, we expect that portion of the backbone which is Cisco routers and switches might very well use it. If the other parts of the backbone want to also, we're all for it. For that to happen, some standards need to be written; if you folks don't want to, that's fine too. If we were playing the proprietary game, you wouldn't be reading public articles about it, but we're willing to be proprietary if you want. > But if you do use it and the G bit is zero then I as a host assume the > behavior specified in IPv6... Let me remind you the status of the flow label (RFC 1883, page 28): The 24-bit Flow Label field in the IPv6 header may be used by a source to label those packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet. IMHO, in present IP6, I have a choice between doing a destination lookup, or a source lookup in the same table followed by a hashed lookup in another table. I really cannot imagine how the latter would be an improvement over the former, and never have been able to figure that out. As a result (speaking for myself, not my employer) I can't imagine why any router vendor would implement the flow label as specified. > This should be discussed on the IPng WG list. This *is* the ipng list, no? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 10:32:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04403; Thu, 10 Oct 96 10:32:32 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04394; Thu, 10 Oct 96 10:32:13 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA13109; Thu, 10 Oct 1996 10:25:50 -0700 Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA15672 for ; Thu, 10 Oct 1996 10:25:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA15672; Thu, 10 Oct 1996 10:25:41 -0700 Received: (from jh@localhost) by lohi.dat.tele.fi (8.7.5/8.7.3) id SAA06201; Thu, 10 Oct 1996 18:12:20 +0300 Date: Thu, 10 Oct 1996 18:12:20 +0300 Message-Id: <199610101512.SAA06201@lohi.dat.tele.fi> From: Juha Heinanen To: deering@parc.xerox.com Cc: mo@uu.net, ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com In-Reply-To: <96Oct9.154228pdt."75270"@digit.parc.xerox.com> (deering@parc.xerox.com) Subject: (IPng 2272) Re: use of IPv6 Flow Label for tag switching Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, you tried to explain that to me in Montreal, and I'm afraid I didn't then, nor do I now, grok exactly why you believe that's true, or whether or not it could be addressed by improvements in IP routing/forwarding. I'm failing to see the fundamental difference between level 2 switches and level 3 switches that requires us to keep both around. I am eager to be educated. having run public data services for almost 10 years i can assure you that the backbone must be based on connection oriented layer 2 technology. there are tons of reasons for doing so even if the customers would only be running ip protocol in their networks. we tried router backbone in late 80s when nothing else was available and it failed miserably. woudn't it be a high time for you steve to step down from your ivory tower and face the real worl. -- juha ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 11:16:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04530; Thu, 10 Oct 96 11:16:02 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04524; Thu, 10 Oct 96 11:15:48 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA24617; Thu, 10 Oct 1996 11:09:15 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA06534 for ; Thu, 10 Oct 1996 11:08:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA06534; Thu, 10 Oct 1996 11:08:27 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14591(9)>; Thu, 10 Oct 1996 11:06:59 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 10 Oct 1996 11:06:45 PDT To: ipng@sunroof.eng.sun.com, idmr@cs.ucl.ac.uk, end2end-interest@isi.edu, dartnet@isi.edu Subject: (IPng 2273) october surprise Date: Thu, 10 Oct 1996 11:06:44 PDT From: Steve Deering Message-Id: <96Oct10.110645pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Friends, Just a short note to let you know that, at the end of this month, I will be leaving Xerox PARC and joining Cisco. I will be working with the group from Granite Systems that was acquired by Cisco in September, helping them to develop their "standards-based multilayer Gigabit Ethernet switching technology" (at least, that's what the press release called it). I will continue to participate in the IETF (including co-chairing the IPNG WG), in the dartnet community, and in the wider network-research community, and I will maintain a collaborative relationship with PARC. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 14:15:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04961; Thu, 10 Oct 96 14:15:46 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04955; Thu, 10 Oct 96 14:15:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA07417; Thu, 10 Oct 1996 14:09:07 -0700 Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA09372 for ; Thu, 10 Oct 1996 14:09:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA09372; Thu, 10 Oct 1996 14:09:03 -0700 Received: from research.att.com by ns; Thu Oct 10 17:08:12 EDT 1996 Received: from raptor.research.att.com by research; Thu Oct 10 17:06:59 EDT 1996 Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id RAA07040; Thu, 10 Oct 1996 17:06:59 -0400 (EDT) Message-Id: <199610102106.RAA07040@raptor.research.att.com> To: "Brian Carpenter CERN-CN" Cc: rja@cisco.com (Ran Atkinson), ipng@sunroof.eng.sun.com Subject: (IPng 2274) Re: IPv6 Other Work in Progress and Needed. Date: Thu, 10 Oct 1996 17:06:59 -0400 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, >--------- Text sent by Ran Atkinson follows: > > I'm not a security expert, we beg to differ > but it seems to me that IPsec would be cleaner to > implement (and more compatible with NAT or application-layer gateway s) if it > could use EIDs in the packet instead of the addresses in the packet for the > bindings of Security Associations. It would require that both EIDs be present > in each IPv6 base header. could we get views on that from other security experts? I'm not sure anything will make IPSEC work well with NAT boxes, but I agree completely with Ran that EIDs would be a tremendous help, for a lot of reasons. Under the current schemes, IPSEC is charged with protecting and using a quantity -- the IP address -- that is not only meaningless to the endpoints, but also susceptible to change at a moment's notice. This might be because of MobileIP, dynamic renumbering, or even (heaven help us) NAT boxes. That doesn't work. At a minimum, it demands that all active associations be rekeyed when an address changes, which is a tremendous increase in the number of packets that must be sent at such times. If I recall the Oakley draft correctly, it's an expensive rekey, since the cached seed material is bound to IP addresses as well. This not only adds packets, it requires expensive extra public key operations. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 14:22:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04973; Thu, 10 Oct 96 14:22:08 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04967; Thu, 10 Oct 96 14:21:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA08874; Thu, 10 Oct 1996 14:14:51 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA11254 for ; Thu, 10 Oct 1996 14:14:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA11254; Thu, 10 Oct 1996 14:14:18 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14973(7)>; Thu, 10 Oct 1996 14:14:12 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 10 Oct 1996 14:13:56 PDT To: Juha Heinanen Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com Subject: (IPng 2275) Re: use of IPv6 Flow Label for tag switching In-Reply-To: jh's message of Thu, 10 Oct 96 08:12:20 -0800. <199610101512.SAA06201@lohi.dat.tele.fi> Date: Thu, 10 Oct 1996 14:13:55 PDT From: Steve Deering Message-Id: <96Oct10.141356pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > woudn't it be a high time for you steve to step down > from your ivory tower and face the real worl. You're right, Juha! You know I always agree with your ideas, so I have decided to follow your advice. See ipng message number 2273. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 14:38:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04985; Thu, 10 Oct 96 14:38:27 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04979; Thu, 10 Oct 96 14:38:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA13407; Thu, 10 Oct 1996 14:31:37 -0700 Received: from nsco.network.com (nsco.network.com [129.191.1.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA16917 for ; Thu, 10 Oct 1996 14:31:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA16917; Thu, 10 Oct 1996 14:31:03 -0700 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA28016; Thu, 10 Oct 96 16:38:08 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA13386; Thu, 10 Oct 96 16:30:50 CDT Date: Thu, 10 Oct 96 16:30:50 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9610102130.AA13386@anubis.network.com> To: ipng@sunroof.eng.sun.com, tagswitch@cisco.com Subject: (IPng 2276) Re: use of IPv6 Flow Label for tag switching Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Layer 2/Layer 3 issues are virtually irrelevant here. Both 'switching' and 'routing' architectures look at a few header bits in the incoming Thing, and decide what the next hop is for that Thing, yes. Doing it at layer 2 is easier since layer 2 usually has things laid out better for hardware to do bit-groping, but you can do it at layer 3, too. In fact, it's routinely done now. In both models, there is bit-grubbing hardware, attached to caches or tables or something which tell the hardware what to do, based on the values of the bits grubbed out. The real and useful difference between the switching universe and the routing universe is that the switching world is designed to keep multiple cache/table animals in synch, across a network. Thus, once a Data Thing hits the network, it's zapped through hardware all the way. There's no fundamental difference between 'routing' (I think we now call it 'forwarding'?) and switching. The difference is in hop-by-hop and circuit-based (using the word "circuit" in a loose fashion). Circuit based scales better than hop-by-hop, but has other difficulties which it is clear the IP gang is simply going to have to cope with now. My own charmingly whacky opinions only, of course. Andrew ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 16:21:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05090; Thu, 10 Oct 96 16:21:08 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05067; Thu, 10 Oct 96 16:14:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA08170; Thu, 10 Oct 1996 16:08:24 -0700 Received: from csmes.ncsl.nist.gov (csmes.ncsl.nist.gov [129.6.54.2]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA16634 for ; Thu, 10 Oct 1996 16:07:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA16634; Thu, 10 Oct 1996 16:07:55 -0700 Received: (konczal@localhost) by csmes.ncsl.nist.gov (8.6.12/8.6.4jck0) id TAA08228; Thu, 10 Oct 1996 19:02:40 -0400 Date: Thu, 10 Oct 1996 19:02:40 -0400 Message-Id: <199610102302.TAA08228@csmes.ncsl.nist.gov> To: rja@cisco.com From: joe.konczal@nist.gov Cc: brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com In-Reply-To: <199610090000.RAA19087@cornpuffs.cisco.com> (message from Ran Atkinson on Tue, 8 Oct 1996 17:00:48 -0700) Subject: (IPng 2277) Re: IPv6 Other Work in Progress and Needed. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran, There is no installed base of IPv6 NATs. We should encourage the encapsulation of internet packets on non-standard intranets instead of providing for address translation. That puts the burden of supporting such networks on those who choose to use them, instead of burdening the whole internet with EIDs. Remember, IPSEC authentication depends on public key certificates and cryptographic proof of posession of the corresponding private keys, not on the purported network layer identities of the hosts involved. When a host communicates securely with an application-layer gateway, the IP connection and IPSEC security association are between the host and the gateway. They are independent of whatever might exist on the other side of the gateway. There is no reason to use EIDs here. An invariant identifier to supplement the volatile locator in each IPv6 packet seems no more useful for security than an IPv4 address. An IPv4 address has traditionally served as both an weak identifier and a locator, has never provided strong security. I'm not an expert either. Please explain to me where I am wrong. Joe ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 17:15:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05175; Thu, 10 Oct 96 17:15:35 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05165; Thu, 10 Oct 96 17:15:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA23739; Thu, 10 Oct 1996 17:08:39 -0700 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA02332 for ; Thu, 10 Oct 1996 17:08:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA02332; Thu, 10 Oct 1996 17:08:05 -0700 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id QAA10965; Thu, 10 Oct 1996 16:54:40 -0700 Message-Id: <199610102354.QAA10965@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Thu, 10 Oct 1996 16:54:40 PDT In-Reply-To: joe.konczal@nist.gov "Re: (IPng 2232) Re: IPv6 Other Work in Progress and Needed." (Oct 10, 7:02pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: joe.konczal@nist.gov Subject: (IPng 2278) Re: IPv6 Other Work in Progress and Needed. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Oct 10, 7:02pm, joe.konczal@nist.gov wrote: % There is no installed base of IPv6 NATs. We should encourage the % encapsulation of internet packets on non-standard intranets instead of % providing for address translation. That puts the burden of supporting % such networks on those who choose to use them, instead of burdening % the whole internet with EIDs. I am not interested in NATs either way in the current context. Please let us ignore them for the current discussion. :-) In IPv6, normal unicast addresses are intended to be significantly more dynamic than they historically have been in IPv4. IPv6 specifically includes mechanisms intended to make it easy to renumber hosts. Renumbering a host while it is still operational (e.g. via DHCP leases) raises operational issues with live sessions (including those sessions using IPsec). % Remember, IPSEC authentication depends on public key certificates and % cryptographic proof of posession of the corresponding private keys, not % on the purported network layer identities of the hosts involved. In cryptographic or trust model terms, this is clearly true. I anticipate that a number of different identity forms will be used inside public key certificates deployed in future within The Internet. Examples of these identity forms that would be associated with a given certificate include but are not strictly limited to (for "IP" please read "IPv4 or IPv6"): IP Address (IP ADDR) IP Address Range/IP Subnet (IP SUBNET) Fully-qualified Domain Name (FQDN) User at Fully Qualified Domain Name (USER_FQDN). Connection ID (CONN_ID) {IP ADDR plus upper-protocol plus port number) As a practical implementation matter, the IPsec standards state explicitly that the combination of the "Destination Address" and SPI are used to locate the appropriate Security Association to use on a given incoming packet containing IPsec. Here we have a formal binding between an IP address and the IPsec Security Association. An IP Security Association includes both the source and destination IP Address information [1]. The source address is part of the SA because source address checking is required to preclude certain kinds of tunnel-mode IPSEC spoofing attacks (the details of which have been discussed in the past on the IPsec list). % An invariant identifier to supplement the volatile locator in each % IPv6 packet seems no more useful for security than an IPv4 address. % An IPv4 address has traditionally served as both an weak identifier % and a locator, has never provided strong security. Please permit me to give an example of a case where I believe EIDs could provide significant benefit in the context of IPsec. This might help focus discussion somewhat. Let X and Y be IP-capable nodes using IPsec to communicate with each other. Let Xe be the EID for X and Ye be the EID for Y. Let A, B, C, and D represent IP addresses. Let XA represent node X using IP address A. Let XB represent node X using IP address B. Let time T0 be older than time T1 and let T1 be older than T2. Let N1 be the value of the IPsec SPI used between X and Y. Consider that at time T0 an IP session begins between XA and YB, using IPsec and with IPsec Security Associations having identities of the USER_FQDN flavour. Recall that YB is using the combination (B,N1) to locate the correct (XA->YB) IPsec Security Association needed to perform IPsec processing on the packet received by YB from XA. At time T1, the IP session from X to Y still exists, and the IPsec SA located by (B, N1) has not exceeded its lifetime, but X renumbers from A to C (e.g. because its DHCP lease on address A has expired). In the absence of explicit EIDs in the IP packet, the IP session now dies, the IPsec SA now becomes useless (even though it does not die immediately) because packets with a source address of A are not valid for that IPsec SA, and the user is unhappy. If one has explicit EIDs, then the IPsec processing could be based on the (Ye,N1) pair instead of (B,N1) and the IPsec source check could be performed on Xe instead of upon A. This keeps the IPsec SA alive _and_ useful. Now X renumbers at T1 and is able to send a hypothetical "ICMP Change of Address" packet to Y, protected via the (still existing and useful) IPsec SA. At time T2, Y receives this message, verifies that the source EID is Xe, authentically learns X's new address, and updates its internal data structures (e.g. IP protocol control block, TCP control block) with the revised information. As a result, the session from X to Y can continue even though X has renumbered. Further, all IPsec sessions between X and Y continue without loss of a packet. By a similar process, Y could renumber from B to D without losing the IP session or IPsec session. In a related good side effect, by binding the ISAKMP SA with (N2, Xe, Ye) instead of (N2, XA, YB), the important ability of ISAKMP/Oakley to rapidly generate new IPsec SAs based on cached ISAKMP state is also preserved. Ran rja@cisco.com [1] NB: Source is permitted to be the equivalent of INADDR_ANY when the destination is a multicast group using symmetric keying and each sender in the group uses the same session key. -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 10 18:35:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05310; Thu, 10 Oct 96 18:35:07 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05304; Thu, 10 Oct 96 18:34:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA10775; Thu, 10 Oct 1996 18:28:37 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA19853 for ; Thu, 10 Oct 1996 18:28:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA19853; Thu, 10 Oct 1996 18:28:36 -0700 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id SAA15758; Thu, 10 Oct 1996 18:28:35 -0700 Message-Id: <2.2.32.19961011012521.00c76f08@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 10 Oct 1996 18:25:21 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 2279) Lost Email Cc: hinden@Ipsilon.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I had a hard disk failure and lost the last week or so of email. If you sent me email and I did not respond, please resend it. Thanks, Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 00:47:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05582; Fri, 11 Oct 96 00:47:36 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05576; Fri, 11 Oct 96 00:47:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA02948; Fri, 11 Oct 1996 00:41:01 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA00836 for ; Fri, 11 Oct 1996 00:40:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA00836; Fri, 11 Oct 1996 00:40:50 -0700 From: Masataka Ohta Message-Id: <199610110739.QAA12590@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA12590; Fri, 11 Oct 1996 16:39:29 +0900 Subject: (IPng 2280) Re: suggestion (long) (replay) To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Fri, 11 Oct 96 16:39:28 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610100754.AA09957@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Oct 10, 96 9:54 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; > > Not. Ethernet MAC in your proposal does not identify a rehoming > > transactions. > > Correct. If a group of servers are configured to rehome transactions > among themselves, they would have to use non-hardware dependent IDs. > But if you look again at my original note, you will see that it > allows for other formats than IEEE MAC, and says > > If an ongoing transaction is rehomed, its new host MUST use the > same EID and port number. [This limits rehoming to a smallish > group of co-managed hosts, but that is presumably reasonable.] That limitation may be reasonable to your private goal of application-wise mobility but no good for for our current topic of supporting mobility with collision-prone 6 byte MAC derived from IEEE 1394 ID. > > Please make an archtecturally consistent proposal. > > > I think I did. Do you think we need MAC based EID or not? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 01:43:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05682; Fri, 11 Oct 96 01:43:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05676; Fri, 11 Oct 96 01:42:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA07739; Fri, 11 Oct 1996 01:36:27 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA16770 for ; Fri, 11 Oct 1996 01:36:26 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA16770; Fri, 11 Oct 1996 01:36:26 -0700 From: Masataka Ohta Message-Id: <199610110835.RAA12653@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA12653; Fri, 11 Oct 1996 17:34:54 +0859 Subject: (IPng 2281) Re: IPv6 Other Work in Progress and Needed. To: hostmaster@munnari.OZ.AU (Robert Elz) Date: Fri, 11 Oct 96 17:34:53 JST Cc: mohta@necom830.hpcl.titech.ac.jp, bound@zk3.dec.com, bmanning@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: <10112.844939350@munnari.OZ.AU>; from "Robert Elz" at Oct 10, 96 7:22 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre; > Does the end mean "an transport layer end" or "a network layer > end"? > > Network layer - > What we need is "IID", Internet ID. > > I don't care what it is called... I agree, as long as the transport/application layer end were not called EID. > The point with the *ID that I > would like would be that it need not be related 1::1 with anything > physical (certainly not an interface, but not necessarily a processor > (or set of processors) either). OK. According to your terminology, let's call it PID (Physical ID). But, don't call it EID. > One thing that we think of as a > computer could have several *ID's, and what's more, some of those > *ID's may be able to shift from one computer to another (without > affecting others that remain). Much of this is just research, I'm afraid you insist that current spec must reflect the future research result. But, OK. It's easy. > I > have no plans to have anything like that implemented tomorrow, but > I would not like the *ID decisions to make assumptions that preclude > this. PID combined with a TCP/UDP port number identifies the logical application/transport layer end point. The only change from IPv4 TCP/UDP is that, two end points on a single host with the same TCP/UDP port ID is different, if their PIDs are different. But, it only means that connection management table of TCP must be searched both with PID and port number, which is of course a slight change on TCP mentioned 5 lines below. Migrating applications with some connection or connectionless UDP should register their PID after moving onto a new host and reopening a socket. > Introduction of network layer ID does affect TCP to some extent. > > Yes, but not much. Two things come immediately to mind - one is that > the IPv4 addr is the current TCP ID, so wherever the address is now > used by TCP - other than where it is used for sending outgoing packets > - would need to be replaced by the *ID. I'm afraid the current TCP ID is a port number, becasue any destination address of a multihomed host is OK to connect to an application on the host. It should be replaced by the conbination of PID and a port number. > And second, assumptions that > are made about security (if the IPv4 addr is bogus they won't get the > packets I send...) need to be revisited. Don't worry. If locator is bogus, they won't get the packets I send. That is, you can trace to the source of the TCP_SYN attacker. > But, we don't need transport layer ID (EID) for mobile hosts and > renumbering. > > Not only for that I would agree. Thank you. > I believe however that if one existed > (some kind of ID) those things become easier to design - there are less > impediments to worry about. What happened so far TWICE is that, when serious discussion on network layer ID began, someone tried to force EID with no clear definition on it only because EID is good for their own not-clearly-defined purpose, which resulted in a complete confusion. Haven't we learned enough to not to say "EID" anymore for the third time? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 02:31:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05742; Fri, 11 Oct 96 02:31:10 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05736; Fri, 11 Oct 96 02:30:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA10044; Fri, 11 Oct 1996 02:24:32 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA24887 for ; Fri, 11 Oct 1996 02:24:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id CAA24887; Fri, 11 Oct 1996 02:24:32 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA19011; Fri, 11 Oct 1996 19:24:22 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2282) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Fri, 11 Oct 1996 17:34:53 +0200." <199610110835.RAA12653@necom830.hpcl.titech.ac.jp> Date: Fri, 11 Oct 1996 19:24:15 +1000 Message-Id: <10670.845025855@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Oct 96 17:34:53 JST From: Masataka Ohta Message-ID: <199610110835.RAA12653@necom830.hpcl.titech.ac.jp> I'm afraid you insist that current spec must reflect the future research result. No, that would clearly be silly, just not do anything that would preclude this possible research. Doing that would actually be pretty difficult, you'd have to contort things a little (perhaps insisting that there be a locator -> *ID mapping that produced exactly one result) to cause problems. PID combined with a TCP/UDP port number identifies the logical application/transport layer end point. Yes, just like the IPv4 addr does now. The only change from IPv4 TCP/UDP is that, two end points on a single host with the same TCP/UDP port ID is different, if their PIDs are different. Yes, just like the IPv4 addr now. But, it only means that connection management table of TCP must be searched both with PID and port number, which is of course a slight change on TCP mentioned 5 lines below. Yes, change IPv4 addr to *ID. Migrating applications with some connection or connectionless UDP should register their PID after moving onto a new host and reopening a socket. That would be the idea, or something like it, but this is the research part - including how packets currently in flight are handled, etc. I'm afraid the current TCP ID is a port number, becasue any destination address of a multihomed host is OK to connect to an application on the host. No, not at all, its entirely possible to have an application that accepts connections only to one of the addresses at a particular port, and a different application that accepts requests to a different address, same port. If that didn't work the HTTP server "virtual domain" trash wouldn't work at all (perhaps a good thing, but that's a different issue). Obviously an application can accept connections to any address - most do - with *IDs an application could accept connections to any *ID (if there is more than one) as well. No major paradigm shifts required there. Don't worry. If locator is bogus, they won't get the packets I send. That is, you can trace to the source of the TCP_SYN attacker. Sure, the difference is that now the connection identification is tied to the locator, if some *ID was used instead of the locator then that relationship will no longer hold. I think it has already been demonstrated that this kind of security isn't worth much, but I doubt it is 100% worthless either. Haven't we learned enough to not to say "EID" anymore for the third time? No. I think it is true that if you take any individual possible use of EIDs you can find an alternative way to design that mechanism. However, I also believe that what that leads to is a lot of little odd warts sticking around all over the place, that could all collectively be replaced by one common identifier. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 03:11:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05793; Fri, 11 Oct 96 03:11:25 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05787; Fri, 11 Oct 96 03:11:12 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA11584; Fri, 11 Oct 1996 03:04:52 -0700 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA00738 for ; Fri, 11 Oct 1996 03:04:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA00738; Fri, 11 Oct 1996 03:04:53 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id MAA03817; Fri, 11 Oct 1996 12:04:21 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA06536; Fri, 11 Oct 1996 12:04:21 +0200 Message-Id: <9610111004.AA06536@dxcoms.cern.ch> Subject: (IPng 2283) Re: suggestion (long) (replay) To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Fri, 11 Oct 1996 12:04:21 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199610110739.QAA12590@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Oct 11, 96 04:39:28 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 Masataka, > > Do you think we need MAC based EID or not? Identifiers need to be unique, and making them MAC-addr based is only a partial solution as we know. RFC 1526 analysed this and proposed a solution for unique 48 bit IDs. Brian P.S. I will shortly be off the network for 2 weeks. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 03:23:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05815; Fri, 11 Oct 96 03:23:33 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05805; Fri, 11 Oct 96 03:23:09 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA12055; Fri, 11 Oct 1996 03:16:50 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA02379 for ; Fri, 11 Oct 1996 03:16:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA02379; Fri, 11 Oct 1996 03:16:49 -0700 From: Masataka Ohta Message-Id: <199610111016.TAA12885@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA12885; Fri, 11 Oct 1996 19:15:49 +0859 Subject: (IPng 2284) Re: IPv6 Other Work in Progress and Needed. To: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 11 Oct 96 19:15:48 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <10670.845025855@munnari.OZ.AU>; from "Robert Elz" at Oct 11, 96 7:24 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre; > I'm afraid you insist that current spec must reflect the future > research result. > > No, that would clearly be silly, just not do anything that would > preclude this possible research. As I have shown, there is no research issues remaining. Just have PIDs. > Yes, just like the IPv4 addr does now. > Yes, just like the IPv4 addr now. Yes, except that IPv4 addr also functions as a locator. > Yes, change IPv4 addr to *ID. Yes. > Migrating applications with some connection or connectionless UDP > should register their PID after moving onto a new host and reopening > a socket. > > That would be the idea, or something like it, but this is the > research part - including how packets currently in flight are > handled, etc. If you insist that it research, how can you be so sure that your proposed solution will not be the obstacle to the future research result? > I'm afraid the current TCP ID is a port number, becasue any destination > address of a multihomed host is OK to connect to an application > on the host. > > No, not at all, its entirely possible to have an application that > accepts connections only to one of the addresses at a particular > port, and a different application that accepts requests to a different > address, same port. Oops, my mistake. You are right. Otherwise, multicasting won't scale with collisions of sender specified receiver port numbers. > No > major paradigm shifts required there. Thank you to make my solution even better. > Don't worry. If locator is bogus, they won't get the packets I send. > That is, you can trace to the source of the TCP_SYN attacker. > > Sure, the difference is that now the connection identification is > tied to the locator, if some *ID was used instead of the locator > then that relationship will no longer hold. Moreover, how can the new locator be securely informed with mobility is a solved issue. For renumbering, I don't think there is much room remaining for solutions different from mobility. TCP sequence number may be able to act a good shared weak secret for renumbering notification. > I think it has already > been demonstrated that this kind of security isn't worth much, but > I doubt it is 100% worthless either. The security that you can trace the location of the attacker is very very important for the protection against the denial of service attack. So, let's keep it. > Haven't we learned enough to not to say "EID" anymore for the > third time? > > No. I think it is true that if you take any individual possible use > of EIDs you can find an alternative way to design that mechanism. So far, EID discussions have created a lot of odd warts. > However, I also believe that what that leads to is a lot of little > odd warts sticking around all over the place, that could all > collectively be replaced by one common identifier. Which odd wart is remaining after EID is replaced by one common identifier, *ID, combined with a port number? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 03:24:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05822; Fri, 11 Oct 96 03:24:20 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05816; Fri, 11 Oct 96 03:23:47 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA12067; Fri, 11 Oct 1996 03:17:27 -0700 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA02436 for ; Fri, 11 Oct 1996 03:17:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA02436; Fri, 11 Oct 1996 03:17:10 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id WAA26085; Thu, 10 Oct 1996 22:54:45 +0100 Date: Thu, 10 Oct 1996 22:54:45 +0100 Message-Id: <199610102154.WAA26085@oberon.di.fc.ul.pt> From: Pedro Roque To: Steven Bellovin Cc: "Brian Carpenter CERN-CN" , rja@cisco.com (Ran Atkinson), ipng@sunroof.eng.sun.com Subject: (IPng 2285) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: <199610102106.RAA07040@raptor.research.att.com> References: <199610102106.RAA07040@raptor.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Steven" == Steven Bellovin writes: Steven> I'm not sure anything will make IPSEC work well with NAT Steven> boxes, but I agree completely with Ran that EIDs would be Steven> a tremendous help, for a lot of reasons. Under the Steven> current schemes, IPSEC is charged with protecting and Steven> using a quantity -- the IP address -- that is not only Steven> meaningless to the endpoints, but also susceptible to Steven> change at a moment's notice. This might be because of Steven> MobileIP, dynamic renumbering, or even (heaven help us) Steven> NAT boxes. That doesn't work. At a minimum, it demands Steven> that all active associations be rekeyed when an address Steven> changes, which is a tremendous increase in the number of Steven> packets that must be sent at such times. If I recall the Steven> Oakley draft correctly, it's an expensive rekey, since the Steven> cached seed material is bound to IP addresses as well. Steven> This not only adds packets, it requires expensive extra Steven> public key operations. I understand the desire to identify an SA independently of the IP address being used, if those IP addresses are subject to chance. What i don't understand is why an EID would be a superior alternative to an opaque X bit number (assigned by the host for instance) as long as it is possible to initially associate a credential with it. I would think that the proposals that use the second aproach (Huitema's multi-homed TCP for instance or others that followed an use the same principle) would provide IPsec SAs the same functionality... For instance, in the mobile IP case, it seams to me that it is possible to consider that if a binding cache exists for the HA then that SA would also be valid for the Care of Address... I understand the IPsec architecture document defines that an IP address and SPI pair identifies an SA but it is just a question of interpretation of what "IP address" means in that context and i believe it means "an opaque identifier of the end system". regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 03:31:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05851; Fri, 11 Oct 96 03:31:09 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05841; Fri, 11 Oct 96 03:30:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA12434; Fri, 11 Oct 1996 03:24:21 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA03354 for ; Fri, 11 Oct 1996 03:24:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA03354; Fri, 11 Oct 1996 03:24:20 -0700 From: Masataka Ohta Message-Id: <199610111023.TAA12917@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA12917; Fri, 11 Oct 1996 19:23:22 +0900 Subject: (IPng 2286) Re: suggestion (long) (replay) To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Fri, 11 Oct 96 19:23:21 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <9610111004.AA06536@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Oct 11, 96 12:04 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; > > Do you think we need MAC based EID or not? > > Identifiers need to be unique, Identifiers, by definition, are unique. Of course, 48 bit MAC ID has to only be link unique and need not be globally unique. You may even make it site unique. So what? Mobility still needs a globally unique ID beyond a small administrative region. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 03:33:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05866; Fri, 11 Oct 96 03:33:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05857; Fri, 11 Oct 96 03:33:06 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA12588; Fri, 11 Oct 1996 03:26:47 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA03703 for ; Fri, 11 Oct 1996 03:26:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA03703; Fri, 11 Oct 1996 03:26:48 -0700 From: Masataka Ohta Message-Id: <199610111025.TAA12946@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA12946; Fri, 11 Oct 1996 19:25:36 +0900 Subject: (IPng 2287) Re: IPv6 Other Work in Progress and Needed. To: hostmaster@munnari.OZ.AU (Robert Elz) Date: Fri, 11 Oct 96 19:25:34 JST Cc: mohta@necom830.hpcl.titech.ac.jp, bound@zk3.dec.com, bmanning@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: <10112.844939350@munnari.OZ.AU>; from "Robert Elz" at Oct 10, 96 7:22 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What does "an end to end option" means? > > I meant one of the options carried in IPv6 headers that is created > at the source, and never seen again until it reaches the destination > (ie: not examined or touched by routers along the way - if the packet > is encrypted, it can be inside the encrypted section). It seems to me that an end to end option not useful for firewall penetration. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 04:21:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06001; Fri, 11 Oct 96 04:21:32 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05995; Fri, 11 Oct 96 04:21:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA14380; Fri, 11 Oct 1996 04:14:54 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA10311 for ; Fri, 11 Oct 1996 04:14:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA10311; Fri, 11 Oct 1996 04:14:55 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id LA22055; Fri, 11 Oct 1996 21:14:21 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2288) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Fri, 11 Oct 1996 19:15:48 +0200." <199610111016.TAA12885@necom830.hpcl.titech.ac.jp> Date: Fri, 11 Oct 1996 21:14:14 +1000 Message-Id: <10735.845032454@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Oct 96 19:15:48 JST From: Masataka Ohta Message-ID: <199610111016.TAA12885@necom830.hpcl.titech.ac.jp> As I have shown, there is no research issues remaining. Maybe, maybe not, how to get the process, and all of its state, from one part of the net to another, seems like research to me. This may not be networking research, more OS research, but it still sounds like new stuff to me (maybe this is just an area I haven't been following, and this is all solved). Yes, except that IPv4 addr also functions as a locator. Of course, yes. If you insist that it research, how can you be so sure that your proposed solution will not be the obstacle to the future research result? I can't. I'd like to try for as few obstacles as possible though, as best we can see it now. Binding TCP connections to a locator seems like an obvious obstacle - not necessarily insurmountable, but an obstacle, so I'd very much like that to be avoided. The security that you can trace the location of the attacker is very very important for the protection against the denial of service attack. I think the recent SYN attacks show that there is no such (easy) trace. So far, EID discussions have created a lot of odd warts. So far, EIDs have been ignored (for some good, and some pretty pathetic reasons). Its had to see how EIDs can have actually created anything (other than mailing list heat). Which odd wart is remaining after EID is replaced by one common identifier, *ID, combined with a port number? Oh, I see you're making some kind of distinction between EID and *ID, I wasn't, to me your PID, or the more generic *ID is all just the same as an EID. That is, whatever semantic you presume an EID to have which the PID doesn't (or *ID doesn't) I don't think I am assuming in the EID. One common identifier (which would certainly not subsume the TCP, or UDP, port number) is what I would like to see. That is what I have called the EID. I know, one of the EID problems is that there is no standard definition, anywhere. What is the semantic that you think I imply an EID to have, and that you don't want to exist? kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 05:48:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06085; Fri, 11 Oct 96 05:48:05 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA06079; Fri, 11 Oct 96 05:47:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA18089; Fri, 11 Oct 1996 05:41:31 -0700 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23159 for ; Fri, 11 Oct 1996 05:41:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA23159; Fri, 11 Oct 1996 05:41:33 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id IAA00938; Fri, 11 Oct 1996 08:41:31 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06873; Fri, 11 Oct 1996 08:41:42 -0400 Message-Id: <9610111241.AA06873@fwasted.zk3.dec.com> To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2289) Re: On the subject of Subject EIDs In-Reply-To: Your message of "Thu, 10 Oct 96 14:56:37 +0200." <199610100556.OAA09995@necom830.hpcl.titech.ac.jp> Date: Fri, 11 Oct 96 08:41:42 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> No all it does is identify the node. We still need to know the locator. > >Jim, "it", here, is an IP level identifier. > >With the single IP level ID, you can't map it to two locators. I agree. >> But if the address >> is the EID than why call it an EID its an address. > >Please, never, mention EID. OK with me, if we would all do this, that would be great. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 06:06:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06126; Fri, 11 Oct 96 06:06:40 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA06120; Fri, 11 Oct 96 06:06:21 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA19287; Fri, 11 Oct 1996 06:00:01 -0700 Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA26984 for ; Fri, 11 Oct 1996 06:00:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA26984; Fri, 11 Oct 1996 06:00:03 -0700 Received: from research.att.com by ns; Fri Oct 11 08:59:09 EDT 1996 Received: from raptor.research.att.com by research; Fri Oct 11 08:58:58 EDT 1996 Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id IAA14143; Fri, 11 Oct 1996 08:58:57 -0400 (EDT) Message-Id: <199610111258.IAA14143@raptor.research.att.com> To: Pedro Roque Cc: "Brian Carpenter CERN-CN" , rja@cisco.com (Ran Atkinson), ipng@sunroof.eng.sun.com Subject: (IPng 2290) Re: IPv6 Other Work in Progress and Needed. Date: Fri, 11 Oct 1996 08:58:57 -0400 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I understand the desire to identify an SA independently of the IP address being used, if those IP addresses are subject to chance. What i don't understand is why an EID would be a superior alternative to an opaque X bit number (assigned by the host for instance) as long as it is possible to initially associate a credential with it. I would think that the proposals that use the second aproach (Huitema's multi-homed TCP for instance or others that followed an use the same principle) would provide IPsec SAs the same functionality... For instance, in the mobile IP case, it seams to me that it is possible to consider that if a binding cache exists for the HA then that SA would also be valid for the Care of Address... I understand the IPsec architecture document defines that an IP address and SPI pair identifies an SA but it is just a question of interpretation of what "IP address" means in that context and i believe it means "an opaque identifier of the end system". As kre just pointed out, an EID *is* an opaque X bit number. Huitema's solution, though far from the only one, would suffice. From a security perspective, other semantics of the EID are irrelevant; what matters is that the value be unique (with a high probability) and constant over the lifetime of a connection. (I should note, though, that having value that is constant over the lifetime of a key exchange would be a considerable help, and this might suggest some value not created on a per-connection basis.) Perry noted that we don't have a good definition for an EID. This is quite true. But while security uses do suggest certain constraints, almost any type would be better than what we have now. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 17:02:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07051; Fri, 11 Oct 96 17:02:42 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07045; Fri, 11 Oct 96 17:02:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA28958; Fri, 11 Oct 1996 16:56:07 -0700 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA22308 for ; Fri, 11 Oct 1996 16:54:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA22308; Fri, 11 Oct 1996 16:54:54 -0700 Received: from fred-ss20.cisco.com (fred-ss20.cisco.com [171.69.58.89]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id MAA26078; Fri, 11 Oct 1996 12:51:24 -0700 (PDT) Received: from fred-ss20 (localhost.cisco.com [127.0.0.1]) by fred-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id MAA01444; Fri, 11 Oct 1996 12:51:24 -0700 Message-Id: <325EA53C.63DECDAD@cisco.com> Date: Fri, 11 Oct 1996 12:51:24 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 3.0GoldC-CISCOENG (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2291) Re: use of IPv6 Flow Label for tag switching References: <9610111744.AA14704@fwasted.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: > I would rather stick pins in my armpits than get into poised > discussions. No problem, I don't want to either, so let's not have the POISED discussion here. > why not move them to hop by hop as you say below. *You* want it moved to hop by hop, I think that's a lousy tradeoff. > Why do you need a tag for [routing traffic detection]? Why not just > the flow-label? I said we are using IP Precedence for that, as defined, and would like to continue to do so! > >other than being zeroed as specified. > > ??? Not sure what your saying here??? OK, I went back and re-read it. It says the originator zeroes it and the router ignores it and passes it unchanged. OK, if I'm writing the code (I'm not) I'll ignore it and pass it unchanged. 6. Flow Labels The 24-bit Flow Label field in the IPv6 header may be used by a source to label those packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet. > I know you implemented so I ask as a question???? I implemented RSVP, not IP6. > >Let's see, the reasonable compromise proposed is: in order to save > >one bit in a field that is experimental and is believed by some to be > >poorly defined with respect to the solution offered, you want to add > >an entire option header and corresponding level of processing. No, > >that doesn't sound like a reasonable compromise. > > First what and why is the flow poorly designed I think that should be > put on the table on IPng WG now!!!! Lets not bring it up later. > Whats the issue? thanks.... It was put on the table, by myself at ACC and my counterparts at Cisco, and as I recall by others as well, three years ago. IPNG has never bothered to deal with the stated objection. I also stated the objection in my email to you yesterday. The flow label is designed to be an optimization, an improvement over destination address routing for longer term flows, which might additionally have QoS or other characteristics. The objection is: A destination address lookup requires a certain cost; a source address lookup requires the same cost. The defined behavior in the router is a source address lookup plus an additional lookup. The specified optimization fails first and foremost because it is not an optimization. What we're trying to propose here is something that both is an optimization *and* meets the needs of a host which wants special processing for a flow. And the mechanism we are proposing, unlike the mechanism I proposed three years ago (which was a hop by hop flow label, but I didn't think of using it as a route specifier) is not limited to supporting individual flows, but can be used in the general case of short flows without a setup at all, simply because they use the same routes. > But architecturally as long as a host can define a guranteed > end-to-end flow as they want it specified from a host application that > is more efficient in a network than a source route and gets QOS, > etc..then yes I am open to such a compromise. Maybe have a compromise in the works. The IP Architecture tends to not include the host in routing (hosts have limited route tables and generally don't get involved in PIM, OSPF, or BGP exchanges), and have therefore we not thought seriously about host involvement in TDP. But I am proposing that the RSVP RESV might contain a tag object (needed for tag distribution for unicast flows, and could be used to propagate the tag for a multicast session to the sender as well), so that's certainly one possible host involvement, and it's quite possible for a host to implement TDP or tag extensions for PIM if it wants to. > But this may get to the point where a discussion of why the flow-label > as specified won't work in some minds? I gave up on trying to have that discussion several years ago, when people couldn't remember on one day what was said in email the day before, because they basically weren't listening. If you're willing to seriously discuss it, I'm up to it. My issues are: 1. this need not remain proprietary 2. the flow label should be an optimization, not a headache, and implementable in hardware targetted for OC-xxx operation. 3. Carriers are looking for ways to do precedence for a class of traffic, and router folks would like to use it to identify routing traffic in a very simple manner. 4. hop by hop flow labelling is a proven technology at L2, while source designation of the flow is not proven. If you would like, we have another way of thinking about this. For IP4, IPX, etc, we are inserting a shim between the L2 and the L3 header for tagging. We were hoping that wouldn't be necessary here. However, we could deal with IP6 the same way we're dealing with other protocols, and simply treat the IP6-gram as data of the tag layer. That would avoid a nasty argument here. There were some in Cisco who suggested not making any proposal to IPNG and simply doing the shim, expecting that the nasty argument would ensue and take up a lot of everyone's time without producing much. If it would make you happier, we can take that route. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 17:20:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07092; Fri, 11 Oct 96 17:20:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07086; Fri, 11 Oct 96 17:20:03 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA23078; Fri, 11 Oct 1996 17:13:43 -0700 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA07864 for ; Fri, 11 Oct 1996 17:13:26 -0700 Received: from fred-ss20.cisco.com (fred-ss20.cisco.com [171.69.58.89]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id JAA00371; Fri, 11 Oct 1996 09:22:26 -0700 (PDT) Received: from fred-ss20 (localhost.cisco.com [127.0.0.1]) by fred-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id JAA00891; Fri, 11 Oct 1996 09:22:08 -0700 Message-Id: <325E7430.15FB7483@cisco.com> Date: Fri, 11 Oct 1996 09:22:08 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 3.0GoldC-CISCOENG (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2292) Re: use of IPv6 Flow Label for tag switching References: <9610111444.AA20238@fwasted.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: > But I think anything we standardize in the IETF SHOULD NOT > have vendor patents on that standard, unless there is no royalty charge > and people can use it for FREE. That opinion was raised in POISED, and that's not where they wound up. If you want to debate that again, I'd suggest poised@tis.com is a great place to discuss it. > I think the distribution should include Hosts in its > architecture. I'm prone to agree with you there, though I'm probably in a minority at Cisco. I don't see any good reason that hosts can't emulate TDP if they want. > I think we should get rid of > the version field and priority field and have a 32bit flow label. One consideration: have you noticed the backbone carriers discussing offering their customers varying levels of service, as in "bronze, silver, gold, platinum"? They are asking us to give them ways to use IP4 Precedence, setting it at their ingress routers and observing it throughout their networks, as a way of providing differential service. We're not likely to literally run precedence queuing at those rates, but we are likely to run RED with differential drop thresholds. Taking away IP6 Precedence is going to make this tough for them. I have a hunch that removing the priority field will come back to bite us. > I think then we should put the dst address right after it. Like this? I think I have heard proposals of this nature, with the justification that it saved reading an extra cache line. But somehow that either wasnt the consensus of the group or at least wasn't agreed to by the editor. Good one to check in the archives. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Prio. | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > the priority bits are not needed if > we define some basic flow labels up front, making QoS be an attribute of the route or flow? Yes, we can arrange that. But if you take those four bits and put them in the flow label, and then tell me to use flow labels to handle such QoS stuff, then I ask myself if that didn't consume the same space with the same function? Something else to consider: turing topology changes, we have found it useful to have a quick mark that tells us which traffic is routing traffic and which is not. When everything is going to get black holed for a second and the only thing that's relevant is routing traffic, it's nice to be able to tube the alligators and get on with draining the swamp. > My issue with the proposal to use the flow for TAGs is that it uses up a > bit I might need to generate a flow from the host (e.g. as request or > path for RSVP, Realtime QOS, or other IP/L2 switch proposals that do not > require the bit to be used) in an architecture that does not include > hosts in its set-up protocol. I wouldn't assume that RSVP can't use tags. > If a host does > set it for say RSVP to be used by the flow-spec then we don't want that > flow-label stepped on other than being zeroed as specified. > Given the premise I state above I think it would be really good if > TAGS and all new technology that wants to use the flow-label in fact > uses the hop-by-hop option... so flows, which are intended to be an optimization, require extra processing? This doesn't sound like the right endpoint. > Is this not a reasonable compromise to at least consider for your > spec? Let's see, the reasonable compromise proposed is: in order to save one bit in a field that is experimental and is believed by some to be poorly defined with respect to the solution offered, you want to add an entire option header and corresponding level of processing. No, that doesn't sound like a reasonable compromise. Let me offer a different compromise. You implement TDP or whatever in the host and use tags in that field to accomplish the same thing. You don't need an end to end value in the label, you need to know what value to put in the label. So you negotiate the value, and put it in the packet. I think that's a better compromise. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 17:32:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07107; Fri, 11 Oct 96 17:32:31 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07101; Fri, 11 Oct 96 17:32:18 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA06006; Fri, 11 Oct 1996 17:25:55 -0700 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA01112 for ; Fri, 11 Oct 1996 17:25:31 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA01112; Fri, 11 Oct 1996 17:25:31 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA32327; Fri, 11 Oct 1996 11:52:32 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA01542; Fri, 11 Oct 1996 11:51:11 -0400 Message-Id: <9610111551.AA01542@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2293) U.S. President Clinton to Discuss/Appt Internet Strategy Date: Fri, 11 Oct 96 11:51:10 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv4 address space is a problem and many users are saying now they wanted IPv6 in 1995 and for sure in 1996. CIDR as a band-aid is not stopping all the blood from flowing out. We can do it and get it done fast or someone else might. /jim --FORWARDS Deleted------ Subject: US $ for the internet? X-Url: http://cnn.com/US/9610/10/clinton.internet/ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit > > October 10, 1996 [Clinton] > Web posted at: 8:00 a.m. EDT > > WASHINGTON (CNN) -- President Clinton is expected > to propose steps Thursday that could pave the way > for the next Internet, White House officials told > CNN. > > Clinton plans to make the announcement during a > campaign stop in Knoxville, Tennessee, where the > president is expected to discuss technology and > its importance for the next century. > > White House officials told CNN that Clinton will > unveil his Internet plan during the rally and will > also name a board of both public and private > sector officials to oversee the creation of such a > system. Sources said the board is to be comprised > of corporate representatives from Time Warner, > Viacom and AT&T, among others. > > Clinton also is expected to emphasize the need to > connect schools to the Internet and that the > private sector should help carry out the plan. > > [rule] > > Tell us what you > [What You Think] think! [Image] [Image] > You said it... > [rule] > > [To the top] > > ) 1996 Cable News Network, Inc. > All Rights Reserved. > > Terms under which this service is provided to you. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 17:36:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07130; Fri, 11 Oct 96 17:36:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07010; Fri, 11 Oct 96 16:55:48 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA18270; Fri, 11 Oct 1996 16:49:29 -0700 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA29807 for ; Fri, 11 Oct 1996 16:48:58 -0700 Received: by mail.noris.net id <35167-5040>; Fri, 11 Oct 1996 18:20:33 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2294) Re: suggestion (long) (replay) Date: 11 Oct 1996 18:15:47 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 34 Message-Id: <53lrrj$pef@work.smurf.noris.de> References: <9610081752.AA23345@fwasted.zk3.dec.com> <9610091752.AA17425@hawpub1.watson.ibm.com> <844910599.1991@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: unlisted-recipients:;@venus (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In dist.ipng, article <844910599.1991@noris.de>, Charlie Perkins writes: > > (1) Notification comes to the network layer that a source address > has changed. > (2) Network layer is responsible for triggering the appropriate > action for all higher-level protocols -- which is that they > should fiddle around with their internal data structures > to account for the IP address change. > The higher-level PCB has currently two IPng addresses (source, destination). We could replace that with four addresses (source, destination, initial-source, initial-destination). The higher-level code could use the initial addresses for checksum generation, security et al., while the lower-level code uses the regular addresses for actually sending and receiving the packets. > Another possibility is that applications make use of an EID-space > IPv6 address (which won't change), but then we get to long-standing > questions about how that address is going to be initially allocated > uniquely, or later located when the application starts up. > IMHO, the original adresses used for connection establishment should _be_ the "EID"s for the purpose of this discussion. -- You might be a redneck if... People hear your car a long time before they see it. -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 17:37:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07142; Fri, 11 Oct 96 17:37:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07136; Fri, 11 Oct 96 17:36:54 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA27129; Fri, 11 Oct 1996 17:29:37 -0700 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA12554 for ; Fri, 11 Oct 1996 17:27:42 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id NAA07329; Fri, 11 Oct 1996 13:46:05 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14704; Fri, 11 Oct 1996 13:44:50 -0400 Message-Id: <9610111744.AA14704@fwasted.zk3.dec.com> To: Fred Baker Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2295) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Fri, 11 Oct 96 09:22:08 PDT." <325E7430.15FB7483@cisco.com> Date: Fri, 11 Oct 96 13:44:50 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, >> But I think anything we standardize in the IETF SHOULD NOT >> have vendor patents on that standard, unless there is no royalty charge >> and people can use it for FREE. > >That opinion was raised in POISED, and that's not where they wound up. >If you want to debate that again, I'd suggest poised@tis.com is a great >place to discuss it. No thanks.. I would rather stick pins in my armpits than get into poised discussions. Someone I work with is on that discussion and I guess they support that too. I don't but not willing to work on poised its not my forte. OK so I think I will go invent a patent now and then standardize it and get the whole world to implement it and I will sit up in Northern New Hampshire and fish, hunt, and grow hot peppers and listen to rock music in the woods for the rest of my life. Not a bad deal. Now I like it. >> I think we should get rid of >> the version field and priority field and have a 32bit flow label. >One consideration: have you noticed the backbone carriers discussing >offering their customers varying levels of service, as in "bronze, >silver, gold, platinum"? They are asking us to give them ways to use IP4 >Precedence, setting it at their ingress routers and observing it >throughout their networks, as a way of providing differential service. >We're not likely to literally run precedence queuing at those rates, but >we are likely to run RED with differential drop thresholds. >Taking away IP6 Precedence is going to make this tough for them. I have >a hunch that removing the priority field will come back to bite us. Yep... thats at good point...why move them to hop by hop as you say below. >making QoS be an attribute of the route or flow? Yes, we can arrange >that. But if you take those four bits and put them in the flow label, >and then tell me to use flow labels to handle such QoS stuff, then I ask >myself if that didn't consume the same space with the same function? Good point.... >Something else to consider: turing topology changes, we have found it >useful to have a quick mark that tells us which traffic is routing >traffic and which is not. When everything is going to get black holed >for a second and the only thing that's relevant is routing traffic, it's >nice to be able to tube the alligators and get on with draining the >swamp. Why do you need a tag for that? Why not just the flow-label? >> My issue with the proposal to use the flow for TAGs is that it uses up a >> bit I might need to generate a flow from the host (e.g. as request or >> path for RSVP, Realtime QOS, or other IP/L2 switch proposals that do not >> require the bit to be used) in an architecture that does not include >> hosts in its set-up protocol. >I wouldn't assume that RSVP can't use tags. Well the flow-spec can change in RSVP but it does not say it MUST. My fear is using the G bit means it will always change if it hits a tag router on the path? THis concern is not just for RSVP. >> If a host does >> set it for say RSVP to be used by the flow-spec then we don't want that >> flow-label stepped on >other than being zeroed as specified. ??? Not sure what your saying here??? This may be one of the issues I have with RSVP? When can it be zeroed? I ask as there is no redirect other than a completely new path to the requester or OPAW to change the flow-spec???? I know you implemented so I ask as a question???? >> Given the premise I state above I think it would be really good if >> TAGS and all new technology that wants to use the flow-label in fact >> uses the hop-by-hop option... > >so flows, which are intended to be an optimization, require extra >processing? This doesn't sound like the right endpoint. No I am saying if we want to tax the systems with a tag then tax it with the options not the flow. I can see the flow being used without any of the tag technology and being used very efficiently such as online-transactions at banks, coke-cola machine sending RF message that its empty, or my robot emptying the garbage in my kitchen. The flow is part of the header for many purposes, tags are a feature that will use flows. So tax the user of the header not the core Internet header in the architecture. Also the flow was envisioned to support the Network COmputer Appliance or toaster-net and my light-switches which was part of the discussion regarding IPv6 when it was IPng work item. >> Is this not a reasonable compromise to at least consider for your >> spec? > >Let's see, the reasonable compromise proposed is: in order to save one >bit in a field that is experimental and is believed by some to be poorly >defined with respect to the solution offered, you want to add an entire >option header and corresponding level of processing. No, that doesn't >sound like a reasonable compromise. First what and why is the flow poorly designed I think that should be put on the table on IPng WG now!!!! Lets not bring it up later. Whats the issue? thanks.... I answered why I believe the option is OK and tags should bear the brunt of the pain not reduce the scope of the flow-label. The flow-label will have uses wear tags do not exist or even an option. tags is an option so make it an option and live with being an option. >Let me offer a different compromise. You implement TDP or whatever in >the host and use tags in that field to accomplish the same thing. You >don't need an end to end value in the label, you need to know what value >to put in the label. So you negotiate the value, and put it in the >packet. I think that's a better compromise. I don't know about TDP OK that needs to be discussed. I am not going to support a core feature in IPv6 for the next 30 years that requires me to pay royalties to anyone if I am going to use it no matter what poised says or the company I work for and I will explain why. I might just shut up and not participate but I won't support it and don't want to work on it as an engineer. I don't mind doing this stuff when its proprietary but I am wearing my IETF hat now not my vendor hat. But architecturally as long as a host can define a guranteed end-to-end flow as they want it specified from a host application that is more efficient in a network than a source route and gets QOS, etc..then yes I am open to such a compromise. But this may get to the point where a discussion of why the flow-label as specified won't work in some minds? And really is not a tag issue. If tags is getting around something we need to fix in IPv6 flow-label then lets have the discussion whats wrong with the flow-label. My issues are: 1. Lets not use up bits in the flow-label that define options and that trashes my priority sugggestion too. 2. Definitely not use up bits in IPv6 anywhere that support one specific proprietary strategy methodology but permit those vendor extensions in the hop-by-hop options. 3. TDP should include hosts. 4. Lets flush out what the issues are with the flow-label as specified regardless of TAGs. I don't see them and listening and have been for a long time. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 17:37:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07149; Fri, 11 Oct 96 17:37:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07028; Fri, 11 Oct 96 17:01:05 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA19330; Fri, 11 Oct 1996 16:54:46 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA01326 for ; Fri, 11 Oct 1996 16:53:37 -0700 Received: from ftp.com by ftp.com ; Fri, 11 Oct 1996 14:04:18 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Fri, 11 Oct 1996 14:04:18 -0400 Received: by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id OAA11817; Fri, 11 Oct 1996 14:04:10 -0400 Date: Fri, 11 Oct 1996 14:04:10 -0400 Message-Id: <199610111804.OAA11817@MAILSERV-2HIGH.FTP.COM> To: bound@zk3.dec.com Subject: (IPng 2296) Re: IPv6 PS to DS Status? From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: kre@munnari.OZ.AU, ipng@sunroof.eng.sun.com Repository: mailserv-2high.ftp.com, [message accepted at Fri Oct 11 14:04:08 1996] Originating-Client: d-cell.ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How should be keeping/recording any changes we have for the PS specs > logistically? that would be a great help to the iesg when we deliberate our deliberations. -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 18:11:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07196; Fri, 11 Oct 96 18:11:22 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07190; Fri, 11 Oct 96 18:11:04 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA14495; Fri, 11 Oct 1996 18:04:44 -0700 Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA14472 for ; Fri, 11 Oct 1996 18:03:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA14472; Fri, 11 Oct 1996 18:03:49 -0700 Received: from research.att.com by ns; Fri Oct 11 21:02:01 EDT 1996 Received: from raptor.research.att.com by research; Fri Oct 11 21:00:33 EDT 1996 Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id VAA11813; Fri, 11 Oct 1996 21:00:33 -0400 (EDT) Message-Id: <199610120100.VAA11813@raptor.research.att.com> To: bound@zk3.dec.com Cc: Fred Baker , ipng@sunroof.eng.sun.com Subject: (IPng 2297) Re: use of IPv6 Flow Label for tag switching Date: Fri, 11 Oct 1996 21:00:33 -0400 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Something else to consider: turing topology changes, we have found it >useful to have a quick mark that tells us which traffic is routing >traffic and which is not. When everything is going to get black holed >for a second and the only thing that's relevant is routing traffic, i t's >nice to be able to tube the alligators and get on with draining the >swamp. Why do you need a tag for that? Why not just the flow-label? A much better idea. How do you prevent J. Random Luser from setting that special bit from his/her hacked Linux box -- you know, the one that's also emitting the phony IP addresses on the SYN packets... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 18:49:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07270; Fri, 11 Oct 96 18:49:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07264; Fri, 11 Oct 96 18:49:11 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA10296; Fri, 11 Oct 1996 18:42:50 -0700 Received: from cornpuffs.cisco.com (cornpuffs.cisco.com [171.69.1.219]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA06410 for ; Fri, 11 Oct 1996 17:06:59 -0700 Received: (rja@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id JAA16427; Fri, 11 Oct 1996 09:19:19 -0700 Message-Id: <199610111619.JAA16427@cornpuffs.cisco.com> From: rja@cisco.com (Ran Atkinson) Date: Fri, 11 Oct 1996 09:19:19 PDT In-Reply-To: Pedro Roque "(IPng 2274) Re: IPv6 Other Work in Progress and Needed." (Oct 10, 10:54pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Pedro Roque Subject: (IPng 2298) Re: IPv6 Other Work in Progress and Needed. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Oct 10, 10:54pm, Pedro Roque wrote: % I understand the desire to identify an SA independently of the IP address % being used, if those IP addresses are subject to chance. What i don't % understand is why an EID would be a superior alternative to an opaque X bit % number (assigned by the host for instance) as long as it is possible to % initially associate a credential with it. If the "opaque X bit number" is globally unique identifier, then it could be used. Note, however, that it that number is globally unique, it is then by definition an EID. If the "opaque X bit number" is not globally unique, then it won't work. Ran rja@cisco.com -- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 19:27:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07357; Fri, 11 Oct 96 19:27:54 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07351; Fri, 11 Oct 96 19:27:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA27402; Fri, 11 Oct 1996 19:21:20 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA23631 for ; Fri, 11 Oct 1996 17:01:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA23631; Fri, 11 Oct 1996 17:01:40 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id SAA14203; Fri, 11 Oct 1996 18:03:57 -0400 Date: Fri, 11 Oct 1996 18:03:57 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9610111803.ZM14201@seawind.bellcore.com> In-Reply-To: Steven Bellovin "(IPng 2274) Re: IPv6 Other Work in Progress and Needed." (Oct 10, 5:06pm) References: <199610102106.RAA07040@raptor.research.att.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: Steven Bellovin , "Brian Carpenter CERN-CN" Subject: (IPng 2299) Re: IPv6 Other Work in Progress and Needed. Cc: rja@cisco.com (Ran Atkinson), 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, Why exactly should the key relate to the addresses ? What about using the security association idea as a unique thingie in the receiving entity, meaning that the packet came from whoever established the association in the first place ? -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 19:38:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07376; Fri, 11 Oct 96 19:38:15 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07370; Fri, 11 Oct 96 19:38:02 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA28513; Fri, 11 Oct 1996 19:31:42 -0700 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA20519 for ; Fri, 11 Oct 1996 16:50:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA20519; Fri, 11 Oct 1996 16:50:19 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA25944; Fri, 11 Oct 1996 12:07:31 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA32195; Fri, 11 Oct 1996 12:06:10 -0400 Message-Id: <9610111606.AA32195@fwasted.zk3.dec.com> To: jh@lohi.dat.tele.fi Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com Subject: (IPng 2300) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Thu, 10 Oct 96 14:13:55 PDT." <96Oct10.141356pdt."75270"@digit.parc.xerox.com> Date: Fri, 11 Oct 96 12:06:09 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juha, Well Steve is going to be nice. I want to be mean but I won't either. What I will do is point you to: draft-odell-code-of-conduct-00.txt (this should become a BCP Mike) We are a community and your mail to Steve was I feel not put well and came off like an attack as opposed to a constructive comment. I think there are ways to say things without being mean and Steve did not deserve that comment in this community and I think you owe him an apology publicly. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 22:09:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07504; Fri, 11 Oct 96 22:09:45 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07498; Fri, 11 Oct 96 22:09:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA10916; Fri, 11 Oct 1996 22:03:11 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA08455 for ; Fri, 11 Oct 1996 22:03:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA08455; Fri, 11 Oct 1996 22:03:12 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA26165; Sat, 12 Oct 1996 15:02:48 +1000 (from kre@munnari.OZ.AU) To: smurf@noris.de (Matthias Urlichs) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2301) Re: suggestion (long) (replay) In-Reply-To: Your message of "11 Oct 1996 18:15:47 +0200." <53lrrj$pef@work.smurf.noris.de> Date: Sat, 12 Oct 1996 15:02:41 +1000 Message-Id: <11113.845096561@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 11 Oct 1996 18:15:47 +0200 From: smurf@noris.de (Matthias Urlichs) Message-ID: <53lrrj$pef@work.smurf.noris.de> IMHO, the original adresses used for connection establishment should _be_ the "EID"s for the purpose of this discussion. The problem with this is that the original address may have been switched to be used by someone else while the original connection remains intact. If the someone else happens to select the same port number for their end of a connection to a well known port at the server (very common, as most implementations tend to use a simple algorithm for port number generation, like "start at 2000 and go up by one for each new connection") then their attempt to create a new connection will look to be the same connection as the old existing connection from the previous user of the address. This would be one very weird failure mode. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 11 22:14:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07516; Fri, 11 Oct 96 22:14:47 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07510; Fri, 11 Oct 96 22:14:34 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA11218; Fri, 11 Oct 1996 22:08:13 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA09050 for ; Fri, 11 Oct 1996 22:08:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA09050; Fri, 11 Oct 1996 22:08:14 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA07015; Sat, 12 Oct 1996 15:05:23 +1000 (from kre@munnari.OZ.AU) To: Fred Baker Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2302) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Fri, 11 Oct 1996 09:22:08 MST." <325E7430.15FB7483@cisco.com> Date: Sat, 12 Oct 1996 15:05:18 +1000 Message-Id: <11118.845096718@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 11 Oct 1996 09:22:08 -0700 From: Fred Baker Message-ID: <325E7430.15FB7483@cisco.com> I think I have heard proposals of this nature, with the justification that it saved reading an extra cache line. But somehow that either wasnt the consensus of the group or at least wasn't agreed to by the editor. Good one to check in the archives. That was discussed at one of the meetings, with a bunch of measurements being presented (by Dimitry?) In any case, the result was that depending on the circumstances there could be either wins or costs in making the change, and that there certainly asn't a clear benefit to make it worth changing the specs (but by the same reasoning if it had originally been done the other way, that probably wouldn't have been changed either). Its a tossup decision. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 12 00:28:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07642; Sat, 12 Oct 96 00:28:33 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07636; Sat, 12 Oct 96 00:28:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA17287; Sat, 12 Oct 1996 00:21:55 -0700 Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA22191 for ; Sat, 12 Oct 1996 00:21:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA22191; Sat, 12 Oct 1996 00:21:55 -0700 Received: (from jh@localhost) by lohi.dat.tele.fi (8.7.6/8.7.3) id KAA02650; Sat, 12 Oct 1996 10:21:34 +0300 Date: Sat, 12 Oct 1996 10:21:34 +0300 Message-Id: <199610120721.KAA02650@lohi.dat.tele.fi> From: Juha Heinanen To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com In-Reply-To: <9610111606.AA32195@fwasted.zk3.dec.com> (bound@zk3.dec.com) Subject: (IPng 2303) Re: use of IPv6 Flow Label for tag switching Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jim, i will apologize when steve starts to send messages to this list that contribute to *solving* the problems related to runing ip over various layer 2 cloud technologies. advocating that these technologies should not be used at all is not a solution, because there is a real world out there. -- juha ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 12 05:15:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07765; Sat, 12 Oct 96 05:15:43 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07759; Sat, 12 Oct 96 05:15:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA24758; Sat, 12 Oct 1996 05:08:58 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id FAA07745 for ; Sat, 12 Oct 1996 05:08:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA07745; Sat, 12 Oct 1996 05:08:54 -0700 From: Masataka Ohta Message-Id: <199610121207.VAA02043@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA02043; Sat, 12 Oct 1996 21:07:28 +0900 Subject: (IPng 2304) Re: IPv6 Other Work in Progress and Needed. To: hostmaster@munnari.OZ.AU (Robert Elz) Date: Sat, 12 Oct 96 21:07:27 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <10735.845032454@munnari.OZ.AU>; from "Robert Elz" at Oct 11, 96 9:14 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I have shown, there is no research issues remaining. > > Maybe, maybe not, how to get the process, and all of its state, > from one part of the net to another, seems like research to me. Could you point me out specifically what is the problem of my proposal? My proposal is to: 1) use upper 8 byte of Ipv6 address for hierarchical routing 2) use lower 8 byte of Ipv6 address as *ID which is also useful for intra-subnet delivery (the last hierachy of locator) 3) use *ID and port number identify a transport layer entity Where is the odd wart? > This may not be networking research, more OS research, but it still What is "This"? > If you insist that it research, how can you be so sure that your > proposed solution will not be the obstacle to the future research > result? > > I can't. I'd like to try for as few obstacles as possible though, as > best we can see it now. Binding TCP connections to a locator seems > like an obvious obstacle - not necessarily insurmountable, but an > obstacle, so I'd very much like that to be avoided. I already avoided that, didn't I? > The security that you can trace the location of the attacker is > very very important for the protection against the denial of > service attack. > > I think the recent SYN attacks show that there is no such (easy) trace. The only requirement for the protection is, to enable serious denial of service attack, the attacker must be replied some packet containing a psuedo random information. It's a TCP implementation issue. SYN attack is not a serious attack, if you can make sequence number psuedo-random with hidden secret, as suggested by someone. > So far, EID discussions have created a lot of odd warts. > > So far, EIDs have been ignored (for some good, and some pretty > pathetic reasons). Its had to see how EIDs can have actually > created anything (other than mailing list heat). So, let's continue to *IGNORE* EID. Never say EID never again. OK? I replace EID Confused_Word for the rest of this mail. > Which odd wart is remaining after Confused_Word is replaced by one common > identifier, *ID, combined with a port number? > > Oh, I see you're making some kind of distinction between Confused_Word and *ID, Yes, of course. > I wasn't, to me your PID, or the more generic *ID is all just the same > as an Confused_Word. Never say Confused_Word and consistently call it *ID. > That is, whatever semantic you presume an Confused_Word to have > which the PID doesn't (or *ID doesn't) I don't think I am assuming in > the Confused_Word. Confused_Word is trademarked by Noel to mean transport/application layer entities. Then, the question is: Which odd wart is remaining if we have one common network layer identifier, *ID, which may be combined with a port number to identify a transport/application layer entity? > One common identifier (which would certainly not subsume the TCP, or > UDP, port number) is what I would like to see. That is what I have > called the Confused_Word. I know, one of the EID problems is that there is no > standard definition, anywhere. What is the semantic that you think > I imply an Confused_Word to have, and that you don't want to exist? The problem of you is that you use the word Confused_Word in a way different from others. Please don't insist on the confused terminology. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 12 06:09:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07801; Sat, 12 Oct 96 06:09:12 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07795; Sat, 12 Oct 96 06:08:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25991; Sat, 12 Oct 1996 06:02:37 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA10325 for ; Sat, 12 Oct 1996 06:02:38 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA10325; Sat, 12 Oct 1996 06:02:38 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA02075; Sat, 12 Oct 1996 23:02:24 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2305) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Sat, 12 Oct 1996 21:07:27 +0200." <199610121207.VAA02043@necom830.hpcl.titech.ac.jp> Date: Sat, 12 Oct 1996 23:02:18 +1000 Message-Id: <17940.845125338@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 12 Oct 96 21:07:27 JST From: Masataka Ohta Message-ID: <199610121207.VAA02043@necom830.hpcl.titech.ac.jp> Could you point me out specifically what is the problem of my proposal? One perhaps. My proposal is to: 1) use upper 8 byte of Ipv6 address for hierarchical routing Fine. 2) use lower 8 byte of Ipv6 address as *ID which is also useful for intra-subnet delivery (the last hierachy of locator) The effect of these two is that in any reasonably large organisation, some of the upper 8 bytes will need to be used for internal routing, rather than purely external (as has been planned). That isn't necessarily a problem, but is something to be aware of. Here (University of Melb) for example we've already run out of available routing hierarchy using just 8 bits, and are switching to mostly 10 (its actually very variable from 8 to 14 inside the 16 "host" bits of our /16 number). That is, we'd need to consume (now) at least 10 bits of the external 64 for internal routing, and into the future that will certainly be at least 12 (not in the lifetime of IPv4 possibly - or I hope, or we're in trouble, as I really don't want to attempt to get more IPv4 addressing space ... irrelevant aside ends) I really don't want to get back to the arguments about whether 64 bits is enough (real) locator bits (or, if you assume perhaps a generous average of 64 hosts/subnet, perhaps effectively 70 bits). 3) use *ID and port number identify a transport layer entity Fine. Or more accurately, use the *ID and whatever other identification the transport layer protocol provides (port for TCP or UDP). Where is the odd wart? Oh, I think you think I was criticising your design. I wasn't. The "odd warts" are in the various methods that manage to make everything work without any kind of *ID, with a different solution for every problem that arises. > This may not be networking research, more OS research, but it still What is "This"? A few messages ago, I mentioned that one use of a *ID may be to allow processes (or groups of processes) to migrate between hosts. Making that work is the research. SYN attack is not a serious attack, I won't argue about that, but I suspect you will find plenty of people to disagree. Confused_Word is trademarked by Noel to mean transport/application layer entities. Oh. I don't really believe that his definition is all that different than yours, I think it would be difficult to make it different in any sense that actually had practical effects. But as neither Noel, nor anyone else (me included) has ever actually written down a definition it isn't surprising if confusion has arisen. But never mind, if E is a nasty letter in your vocabulary, I shall avoid it... The problem of you is that you use the word Confused_Word in a way different from others. I think we have had a general problem that almost no two people have exactly the same concept in their minds, nor do people often understand just what definition is in someone else's mind. Now would you like to finally end the confusion, and write a draft defining the *ID (not how it is used in IPv6, just the number itself), how it is allocated, its properties, etc? kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 12 07:32:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07846; Sat, 12 Oct 96 07:32:49 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07840; Sat, 12 Oct 96 07:32:35 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA27867; Sat, 12 Oct 1996 07:26:16 -0700 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA15327 for ; Sat, 12 Oct 1996 07:26:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA15327; Sat, 12 Oct 1996 07:26:16 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA14801; Sat, 12 Oct 1996 10:26:15 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00635; Sat, 12 Oct 1996 10:26:35 -0400 Message-Id: <9610121426.AA00635@fwasted.zk3.dec.com> To: Fred Baker Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2306) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Fri, 11 Oct 96 12:51:24 PDT." <325EA53C.63DECDAD@cisco.com> Date: Sat, 12 Oct 96 10:26:35 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> why not move them to hop by hop as you say below. > >*You* want it moved to hop by hop, I think that's a lousy tradeoff. OK that is not going to fly. I can understand that.. >> Why do you need a tag for [routing traffic detection]? Why not just >> the flow-label? > >I said we are using IP Precedence for that, as defined, and would like >to continue to do so! Mail is getting mixed. I already conceded that ...???? >> >other than being zeroed as specified. >> >> ??? Not sure what your saying here??? > >OK, I went back and re-read it. It says the originator zeroes it and the >router ignores it and passes it unchanged. OK, if I'm writing the code >(I'm not) I'll ignore it and pass it unchanged. > >6. Flow Labels > > The 24-bit Flow Label field in the IPv6 header may be used by a > source to label those packets for which it requests special handling > by the IPv6 routers, such as non-default quality of service or > "real-time" service. This aspect of IPv6 is, at the time of writing, > still experimental and subject to change as the requirements for flow > support in the Internet become clearer. Hosts or routers that do not > support the functions of the Flow Label field are required to set the > field to zero when originating a packet, pass the field on unchanged > when forwarding a packet, and ignore the field when receiving a > packet. OK if a host specifies a flow of 000...02 for a path that routers are using to give that application a dedicated path to another host and if tags is deployed what will happen to the flow along the path. If its not zero? >> I know you implemented so I ask as a question???? > >I implemented RSVP, not IP6. I was referencing RSVP. Asking if the flowspec will stay in tact when specified by a requester down stream if it goes through 4 hops on return upstream to the sender. In IPv6 that object in RSVP can use the flow-lablel. Will the packet be altered if TAGs is implemented? >> First what and why is the flow poorly designed I think that should be >> put on the table on IPng WG now!!!! Lets not bring it up later. >> Whats the issue? thanks.... >It was put on the table, by myself at ACC and my counterparts at Cisco, >and as I recall by others as well, three years ago. IPNG has never >bothered to deal with the stated objection. I also stated the objection >in my email to you yesterday. Well then it was filtered to me as an IPng Directorate member as I don't recall the objection being stated. Also at the IETF meeting for almost 2 years now I have not seen any mail on this list until now discussing the issue. >The flow label is designed to be an optimization, an improvement over >destination address routing for longer term flows, which might >additionally have QoS or other characteristics. Yes. >The objection is: A destination address lookup requires a certain cost; >a source address lookup requires the same cost. The defined behavior in >the router is a source address lookup plus an additional lookup. The >specified optimization fails first and foremost because it is not an >optimization. But if you can use the source/flow as key for a dst address forwarding path is that not an optimization? Why look up the source address the source address/flow is just a key to determine in the lookup the destination address which provides the forwarding path. In addition based on the flow other QoS or Options in the forwarding path may be present especially on a longest match. It means more table entries and O(N) search would have to be optimized. Is that not better than today? >What we're trying to propose here is something that both is an >optimization *and* meets the needs of a host which wants special >processing for a flow. And the mechanism we are proposing, unlike the >mechanism I proposed three years ago (which was a hop by hop flow label, >but I didn't think of using it as a route specifier) is not limited to >supporting individual flows, but can be used in the general case of >short flows without a setup at all, simply because they use the same >routes. I don't see the optimization in TAGs. That could very well be because it does not include hosts presently in the set-up protocol. This is the advantage of the flow-label in the IPv6 packet today. We can actually build applications that depend on it. Like stock quote applications or online banking and with mulitcast it is even a more powerful tool. >Maybe have a compromise in the works. The IP Architecture tends to not >include the host in routing (hosts have limited route tables and >generally don't get involved in PIM, OSPF, or BGP exchanges), and have >therefore we not thought seriously about host involvement in TDP. But I >am proposing that the RSVP RESV might contain a tag object (needed for >tag distribution for unicast flows, and could be used to propagate the >tag for a multicast session to the sender as well), so that's certainly >one possible host involvement, and it's quite possible for a host to >implement TDP or tag extensions for PIM if it wants to. Yes that would be of benefit clearly. >> But this may get to the point where a discussion of why the flow-label >> as specified won't work in some minds? >I gave up on trying to have that discussion several years ago, when >people couldn't remember on one day what was said in email the day >before, because they basically weren't listening. If you're willing to >seriously discuss it, I'm up to it. I am up for it too. >My issues are: > > 1. this need not remain proprietary > 2. the flow label should be an optimization, not a headache, > and implementable in hardware targetted for OC-xxx operation. > 3. Carriers are looking for ways to do precedence for a class > of traffic, and router folks would like to use it to identify > routing traffic in a very simple manner. > 4. hop by hop flow labelling is a proven technology at L2, > while source designation of the flow is not proven. >If you would like, we have another way of thinking about this. For IP4, >IPX, etc, we are inserting a shim between the L2 and the L3 header for >tagging. We were hoping that wouldn't be necessary here. However, we >could deal with IP6 the same way we're dealing with other protocols, and >simply treat the IP6-gram as data of the tag layer. That would avoid a >nasty argument here. There were some in Cisco who suggested not making >any proposal to IPNG and simply doing the shim, expecting that the nasty >argument would ensue and take up a lot of everyone's time without >producing much. If it would make you happier, we can take that route. First what I like is not relevant other than one persons input. You need to see if there is interest to support the draft. I am just working it through and what it means to IPv6. I don't agree with the input you received. IPv6 will be around a long time. I think it needs to be the best it can be but at the same point it needs to be deployed very soon or I believe the Internet is going to melt down or governments are going to get involved. Its the standard engineerng trade off decision many of us make at work each week and why they pay us to be engineers in some respects as opposed to computer scientists. I think if TAGs is good to be specified then thats the TAGSWITCH list to determine not IPNg WG. But the flow label is really important discussion and I think we need to very quickly hear any input about that and how tags or any optimization that benefits minimizing the forwarding path for IPv6 can be absorbed. If it does not include hosts then I think we are missing a key point in the Internet and Intranet architecture needed IMHO for the next century. On hosts. I want to make it clear I think its really good hosts in ND don't have to snoop routing protocols. That is not good and can screw up the network when hosts do this. I don't have a problem with hosts that one interface is a router and another interface is a host that has given our industry great benefits to learn and deploy ideas quickly in networks. What I think is very important is that applications have the mechanisms on a host to participate in the definition of the QoS, Realtime, or Bandwidth it may need to operate correctly. The interface to the application is the host networking subsystem of that operating system. Not having the networking subsystem particpate in the set up for those requirements on the network is an idealistic view of networking. It comes down I think to an application has a choice and should be involved. Now how does that come about. TAGs is proposing an optimization and there are others out there too. The network is the computer some say and that means it has is own economy. I think economies work better when anyone can join in and develop new ideas etc.. The requirements for IPv6 should be requirements to make that economy work and what we work on and develop for IPv6 should be specifications for vendors and entrepreneuers to build parts for that economy. I don't think anything we build should force anyone to pay some money to someone else to use what we specify under the umbrella of the IETF in the core technology or eliminate technical evolution for any part of the network. Lets supposed you and I form a little company to build a really good box or software to support IPv6 over cable. But we need to develop algorithms for QoS. We don't want to start off by paying royalties to use the network at potential customers. Likewise the flow-label or whatever is the best optimization for that technology part of IPv6, should be left open enough for lots of TAGs inventions and uses for tomorrow. I don't think this is a nast argument either. An important discussion yes. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 12 08:22:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07883; Sat, 12 Oct 96 08:22:01 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07877; Sat, 12 Oct 96 08:21:48 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA29273; Sat, 12 Oct 1996 08:15:28 -0700 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA18643 for ; Sat, 12 Oct 1996 08:15:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA18643; Sat, 12 Oct 1996 08:15:28 -0700 Received: from fwasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA01903; Sat, 12 Oct 1996 11:15:26 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA28119; Sat, 12 Oct 1996 11:15:45 -0400 Message-Id: <9610121515.AA28119@fwasted.zk3.dec.com> To: Juha Heinanen Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com Subject: (IPng 2307) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Sat, 12 Oct 96 10:21:34 +0300." <199610120721.KAA02650@lohi.dat.tele.fi> Date: Sat, 12 Oct 96 11:15:45 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juha, Now I understand what you want the way you just put it and it was civil. My suggestion on conflict resolution so that progress can be made was just that, a suggestion. The reason I butted in is that many come to the IETF that are new OK. I know of two cases (people) that came on the scene some years back and actually thought that the way we operate in the IETF is to flame each other and ignore all civility and social gentleness in our tones within our mail. These two folks became abusive and only because thats how they thought things get done. We have new people on this list and I just did not want them to think this is how we communicate. I apologize to you for butting in but I had to for what I believed the greater good. Note I too picked up this behavior and it had to be corrected and I think I have been able to make that transition, and I said things much worse than your reference to Steve. What I do now is think about Mike's code of conduct and if they get really bad I store it in a register and deal with them privately to their face at the next IETF meeting if they get really really rude. I have found this to be productive and they usually no longer are rude to me anymore. Most are not quite as bold face to face as they are behind a terminal and email and 99% of the time we walk away as friends or colleagues who will work together even though we are diametrically opposed philosophically and technically. All bets are off if they something about my mother though. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 12 15:33:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07981; Sat, 12 Oct 96 15:33:24 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07975; Sat, 12 Oct 96 15:33:10 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA14645; Sat, 12 Oct 1996 15:26:50 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA23034 for ; Sat, 12 Oct 1996 15:26:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA23034; Sat, 12 Oct 1996 15:26:51 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14492(7)>; Sat, 12 Oct 1996 15:26:42 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sat, 12 Oct 1996 15:26:30 PDT To: Fred Baker Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2308) Re: use of IPv6 Flow Label for tag switching In-Reply-To: fred's message of Fri, 11 Oct 96 12:51:24 -0800. <325EA53C.63DECDAD@cisco.com> Date: Sat, 12 Oct 1996 15:26:30 PDT From: Steve Deering Message-Id: <96Oct12.152630pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > The flow label is designed to be an optimization, an improvement over > destination address routing for longer term flows, which might > additionally have QoS or other characteristics. You may think or wish that that is what it is designed for, but I must respectfully correct you. (I designed it, so I know.) As is stated in section 6 of the IPv6 spec, RFC-1883, the flow label was designed as a mechanism to enable a source to label those packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. "Special handling" means handling different than would normally be performed based solely on the destination and source addresses in the packet. It was not intended to be "an improvement over destination address routing for longer term flows" -- optimization of forwarding of default-QoS, best-effort flows was never an explicit goal. (Not that I necessarily object to speeding up best-effort forwarding, possibly using the flow label field for that purpose, but that was *not* the original intent of the flow label field.) Rather, it was meant to be an optimization over (and a less layer-violating alternative to) having the routers parse the transport-layer port numbers to identify non-default-QoS flows, as is necessary in IPv4. The requirement for random assignment of flow labels was meant to reduce the cost of flow look-up (by serving as pre-computed hash values), but absolutely minimizing the handling cost for non-default-QoS packets was also not a goal. All that being said, I don't have a strong attachment to the current design of the IPv6 flow label mechanism. When I originally did the design (back in the early SIP days), I attempted to find out from those people who were then doing the pioneering work on RSVP/int-serv -- folks like Lixia Zhang, Scott Shenker, and Dave Clark -- exactly what, if anything, they would want from a new version of IP to support non-default QoS. (The idea of using random flow-label allocation to avoid hop-by-hop hashing came from Dave Clark.) I showed them my proposed design and asked them for approval or suggested changes. They said it looked fine, but they acknowledged that the requirements were unclear at that point in time. Ever since then, I have on many occasions (including every meeting of the End-to-End Protocols Research Group, which includes other RSVP/int-serv designers, such as Bob Braden and John Wroclawski) asked for input on the design of the IPv6 flow label mechanism, warning that it would get harder to change as the IPv6 spec moved along the standards track. In the spec, I included the following caveat: This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. to try to keep the door open for change as long as possible. Over the past year or so, I have started to hear indirect reports that some folks wanted to change the IPv6 flow label to a hop-by-hop label rather than an end-to-end label, but I cannot recall anyone presenting, to me or to the IPng working group, a coherent alternative proposal (until now, with the publication of your tag-switching-for-IPv6 draft). It's about time! In *my* opinion (the working group may, of course, decide otherwise), a "coherent alternative proposal" must include a specification for how flow labels are allocated and reclaimed, including labels for multicast packets sent over multi-access links. Such a specification must be at a sufficient level of detail for the working group to judge how well it copes with label loss or collisions as a result of packet loss, link partitioning, failure of the end-points and/or routers participating in a flow, and other similar less-then-perfect network behavior. It is also desirable that the proposal not require all routers to have explicit support for flows. I am not trying to set unreasonable requirements here -- it was consideration of precisely these issues that led to, and are addressed by, the current IPv6 flow label design. It is of course also desirable that there be a rough consensus in favor of the alternative design, among those people who are interested in using the IPv6 flow label. I bring this up because, when I mentioned in my IPv6 tutorial at SIGCOMM last month that there was a possibility of the flow label being changed to have hop-by-hop semantics, a couple folks came up to me afterwards and said they thought that would be a big step backwards. They thought that having global flow identifiers was a significant advance over the typical hop-by-hop approach, especially in the area of network management and problem diagnosis. I.e., not everyone thinks hop-by-hop labels are good. Sorry for the long-winded reply. I'll talk about the Priority field in a separate message. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 13 00:59:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08640; Sun, 13 Oct 96 00:59:03 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08634; Sun, 13 Oct 96 00:58:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA01651; Sun, 13 Oct 1996 00:52:15 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id AAA23365 for ; Sun, 13 Oct 1996 00:52:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA23365; Sun, 13 Oct 1996 00:52:12 -0700 From: Masataka Ohta Message-Id: <199610130750.QAA03070@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA03070; Sun, 13 Oct 1996 16:50:44 +0900 Subject: (IPng 2309) Re: IPv6 Other Work in Progress and Needed. To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 13 Oct 96 16:50:43 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <17940.845125338@munnari.OZ.AU>; from "Robert Elz" at Oct 12, 96 11:02 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre; > 2) use lower 8 byte of Ipv6 address as *ID which is also > useful for intra-subnet delivery (the last hierachy of locator) > > The effect of these two is that in any reasonably large organisation, > some of the upper 8 bytes will need to be used for internal routing, > rather than purely external (as has been planned). > > That isn't necessarily a problem, but is something to be aware of. Yes. > Here (University of Melb) for example we've already run out of > available routing hierarchy using just 8 bits, and are switching to > mostly 10 (its actually very variable from 8 to 14 inside the 16 "host" > bits of our /16 number). That is, we'd need to consume (now) at > least 10 bits of the external 64 for internal routing, and into the > future that will certainly be at least 12 (not in the lifetime of > IPv4 possibly - or I hope, or we're in trouble, as I really don't want > to attempt to get more IPv4 addressing space ... irrelevant aside ends) What do you fear? Could you please assume almost automatic renumbering available even with the running TCP connection intact? You (U or Melb) should ask your provider 10 bit block today. Later, if you need 12 bit block, ask your provider. You may simply extend the current block, or, almost equally simply, renumber to the new 12 bit block. Or, if you do want to avoid renumbering, you may use four 10 bit blocks, incease the number of *intra-provider* routing table entry by 3. If your provider runs out of its address block, the provider may simply ask NIC extend the block, assign new block which add a new entry to the inter-provider routing table or renumber to a new block. > I really don't want to get back to the arguments about whether 64 > bits is enough (real) locator bits (or, if you assume perhaps a > generous average of 64 hosts/subnet, perhaps effectively 70 bits). I have never encoutered such argument against my proposal. So, I'd like to see one. The requirement to IPv6, documented in some RFC, is to support 10^12 networks (so, how many host do you have in a subnet does not matter), which alreay contain safety factor of 10^2. Note that the world population is less than 10^10. For simplicity, I fix hierarchy boundary. With IPv4, we already support almost 10^5 routing entries. So, make the top level IPv6 hierarchy 24 bit long which can support 10^5~10^6 entries with the first few bits for tags for multicast address and others. Then, we still have 40 bits remaining for at most 10^7 routes. Have 8 bit for extra safety. So, spend another 24 bits to support 10^5 entries. Finally, use 8 bits to support 10^2 entries maybe within a subscriber. So, 8 bits are left unused inaddition to the original safety factor of 10^2. You can save a lot more if you use variable hierarchy boundaries. Then, what is your arguemnt against me? The whole point is that, there is no reason to have a lot of levels of hierarchy as long as the number of routing table entries is not a problem. IPv6 addressing does not have to be a clone of NSAP addressing. > 3) use *ID and port number identify a transport layer entity > > Fine. Thank you. > Where is the odd wart? > > Oh, I think you think I was criticising your design. I wasn't. > The "odd warts" are in the various methods that manage to make > everything work without any kind of *ID, with a different solution > for every problem that arises. But, aren't current problems renumbering, mobility and security? What's the problem of the warts? If some solution needed some ID in a way incompatible to *ID, that might be a problem. But, are there any? > > This may not be networking research, more OS research, but it still > What is "This"? > > A few messages ago, I mentioned that one use of a *ID may be to allow > processes (or groups of processes) to migrate between hosts. Making > that work is the research. Sure. We agreed that > 3) use *ID and port number identify a transport layer entity would work, didn't we? > SYN attack is not a serious attack, > > I won't argue about that, but I suspect you will find plenty of > people to disagree. It may be a serious implementaiton issue of today's TCP. > Confused_Word is trademarked by Noel to mean transport/application > layer entities. > > Oh. I don't really believe that his definition is all that different > than yours, I think it would be difficult to make it different in any > sense that actually had practical effects. But as neither Noel, nor > anyone else (me included) has ever actually written down a definition > it isn't surprising if confusion has arisen. All the source of the confusion is that Noel gave a vague description on his ID as transport/application layer ID but insisted that it were a network layer ID. And, yes, poeple started discussing on Noel's ID by their own definitions. Thus, it was a waste of effort to give a difinition to Noel's ID. That's why I abondoned Noel's ID and began to use other terminologies for the network layer ID. I already suggested a terminology, IID, PID, *ID with concrete definitions with Internet Drafts. > I think we have had a general problem that almost no two people have > exactly the same concept in their minds, nor do people often > understand just what definition is in someone else's mind. > > Now would you like to finally end the confusion, and write a draft > defining the *ID (not how it is used in IPv6, just the number itself), > how it is allocated, its properties, etc? Suuurrrreee. Attached is my I.D. more than half and a year ago included but not limited to "the definition of IID", "how it is used in IPv6", "just the number itself", "how it is allocated". Any comment? Masataka Ohta INTERNET DRAFT M. Ohta draft-ohta-ipv6-addr-arch-00.txt Tokyo Institute of Technology March 1995 Provider Independent IPv6 Addressing Architecture 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. Internet-Drafts 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, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract An IPv6 addressing architecture which maximize the provider independence is described. With flatly routed IPv4 addresses, one can subscribe to multiple providers and change providers at will without a lot of efforts. But, IPv6 packets will be hierarchically routed and their addresses will have hierarchical structure, whose higher part is determined by the network provider. By separating a 128 bit IPv6 address into 64 bit ILOC (Internet LOCator), first 4 bytes of which is flat routable provider part and the rest 4 bytes of which is hierarchical intra-provider part, and 64 bit IID (Internet ID), which is not routable but globally unique, it is possible to preserve some of the provider independence of IPv4. The architecture can also identify geographical location of providers. Introduction IPv4 addresses do not contain provider dependent information. Thus, with IPv4 addresses, we can select and change providers without M. Ohta Expires on Sept. 25, 1995 [Page 1] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 reassigning IP addresses. On the other hand, IPv6 addresses contain provider dependent part for routing aggregation. If host identification is controlled by providers, it is difficult to change providers or have multiple provider. It is likely that subscribers are tuned into the provider they choose and tends to promote provider monopoly. The problem, obviously, is in provider-dependent hierarchical routing. And, the solution, obviously, is not to do provider-dependent hierarchical routing. This memo proposes an address assignment scheme for IPv6 which does flat routing for providers. Routing below providers is, of course, hierarchical so that enough scalability is assured to support 10^12 networks and 10^15 hosts. A mechanism to identify small geographical locations is also included to have geographically-near-optimal and least-costly routing with proper route selection. Assignment Plan for IPv6 address The 16 byte IPv6 address is divided into two fields: 8 byte ILOC (Internet LOCator) and 8 byte IID (Internet ID). ILOC is further divided into three sub fields: 4 byte "Provider ID", 2 byte "Subscriber ID" and 2 byte "Subnet ID". "Provider ID" and "Subscriber ID" together is called "Provider dependent part". Provider dependent part is supplied by providers and dynamically reconfigurable at system boot time or even during operation. It is expected that routers to providers announce provider dependent part information. IID is a globally unique ID of a host or a multicast group to identify the host or the multicast group. While an IID uniquely identifies a single host, a host may have multiple IIDs. But, within a lifetime of some connection or reservation such as for TCP or flow, the same IID should be used regardless of the routing changes. IID is supplied by subscribers. The configuration may be automatic. But it is expected that renumbering is necessary not so often, in M. Ohta Expires on Sept. 25, 1995 [Page 2] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 general, only when a host is purchased or the host is moved to different suborganization of the provider. Host specific information such as IP address to host name mapping is looked up only through IID. For autoconfiguration, it must be possible to derive some IIDs from MAC addresses. As 2^28<10^15, MAC addresses to support 10^15 hosts must be longer than 48 bits (actually, a lot longer than that), IID is designed to have 64 bits. Subnet ID is also supplied by subscribers and identifies a subnet within a subscribers LAN. The configuration may be automatic through nearest routers. Renumbering is necessary when a location of a host is changed to a different subnet. Network layer identification of a host is done through IID just like the current IPv4. Routing is controlled purely by the ILOC part of IPv6 address, which is 8byte aligned and, thus, is more efficient than schemes using full 16 bytes. For the deliverly between adjacent routers or a router and a host, which is within a single link layer, only the identification is necessary. So, for IPv6 ARP equivalent, IID is used and ILOC is not consulted. Users can change providers at will just by disconnecting one of its external routers and connect it to a new provider, and ILOC part will be automatically reconfigured. But, it is still necessary to update information of DNS, which is further explained in the "DNS interaction" section. A host of a subscriber belonging to multiple providers may have multiple provider dependent parts. Different interfaces of a host is, in general, distinguished by ILOC part. Assignment Plan for Provider ID, Subscriber ID and Subnet ID 4 byte provider ID uniquely identifies a single provider in the Internet, while a provider may have multiple provider IDs. 4 byte provider ID combined with 2 byte subscriber ID uniquely identifies a subscriber in the Internet. Provider ID of 0 is reserved for subscriber local routing. 2 byte subnet ID uniquely identifies a subnet in a subscribers M. Ohta Expires on Sept. 25, 1995 [Page 3] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 network. A large subscriber having more than 65536 subnets will have multiple subscriber IDs from a provider. A large provider having more than 65536 subscriber IDs or having some geographical constraints, as explained in the next section, will have multiple provider IDs. Avoiding Treework A goal of IPv6 is to avoid treework and make it real network. With usual provider based addressing, users within a single provider share the same routing prefix so that it is difficult to use better route outside the provider. That is, complex configuration is necessary to break the routing hierarchy, which does not scale. It is unlikely that providers welcome such configuration only to allow subscribers pay less to the provider. So, in this proposal, to identify small geographical locations, a provider ID should not cover an area of 100Km radius. That is, a large provider must use different provider IDs for hosts located more than 200Km apart. The distance is measured only for IP entry point of providers, so that PPP service through non-IP public data network for 1,000Km-distant user is allowed. Thus, it becomes naturally possible to favor local links outside of the centralized provider, if local IXes are available. Only about 17,000 IDs are necessary to cover the surface of the Earth. Inter-planetary communication is NOT considered here. Assignment Plan for IIDs There are two kinds of IIDs, structured and unstructured. Structured IIDs are maintained by IANA and is used to lookup IANA maintained database of in-addr.arpa. equivalent of IPv6. Unstructured IIDs are directly derived from globally unique MAC addresses of hosts and useful for autoconfiguration. The most significant bit of structured IID is 0. First three bytes of structured IID are assigned from IANA to country NICs. M. Ohta Expires on Sept. 25, 1995 [Page 4] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 Each country NIC uses the next three bytes for independent subscribers. A subscriber use the last two bytes for the internal use. If the lease significant bit of IID is 0, it is for unicasting. Otherwise, the IID identifies multicast. An IID of all 1's except of the first bit is for broadcasting. The most significant bit of unstructured IID is 1. For the current 48 bit MAC addresses maintained by IEEE, 16 bits prefix of "1000000000000000" is added to form the IID. Rest of the unstructured IID space is reserved for the future use. DNS Interaction While IPv6 addresses are mostly autoconfigurable, it is still necessary to use DNS to advertise IPv6 addresses all over the Internet. As IIDs are considered to be rather static, they can be stored in DNS just as the current IPv4 addresses. On the other hand, if a subscriber adds or changes a provider, it is necessary to reflect the change to DNS. To do so without a lot of pain, the DNS lookup of ILOC should be indirect. That is, each DNS node of a host should not directly have ILOC but have a pointer to some node. The node, which is pointed by a lot of hosts within the same subscriber, then, have (multiple) ILOC information of the subscriber. Thus, it is possible to quickly change a provider without much difficulty. Of course, some statically configured raw addresses, which is necessary for the minimal operation of DNS itself, will still need to be reconfigured. Supporting 10^12 networks and 10^15 hosts How the requirement to support 10^12 networks and 10^15 hosts can be satisfied? First, how routing between 10^12 networks is possible? 10^3 hosts within a subnet can easily be identified by the IID. Thus, (Provider ID, Subscriber ID, Subnet ID) must identify 10^12 networks. It is not unnatural that a provider, in average, supports at least 10^3 subscribers. It can also be safely assumed that subnet ID can identify 10^1 subnets. Thus, Provider ID is required to identify 10^8 hosts. Considering that the requirement contains 10^2 safety factor, the least significant byte of the Provider ID are reserved for the factor. The remaining 3 bytes (2^24>10^7) are much more than M. Ohta Expires on Sept. 25, 1995 [Page 5] INTERNET DRAFTProvider Independent IPv6 Addressing Architecture March 1995 enough to identify 10^6 providers. It is assumed that by the time we support 10^12 networks, flat routing of 10^6 providers is not a problem at all. The reserved lowest byte of provider ID may also be used for two-level routing among providers. Next, how identification of 10^15 hosts is possible? 10^3 hosts of a subscriber can easily be identified by the last two bytes of IID. For the remaining 10^12 factor, IANA and country NICs are expected to manage the upper 6 bytes (for about 2*10^24 hosts) densely enough. Thus, it is feasible that more than 10^12 networks can be identified with the 6 bytes. Conclusion As the 16 byte address space is so large, it is possible to use it wisely to enjoy full provider independence, including provider change without renumbering and long distance provider selection by provider IDs. Acknowledgement The work is inspired by the concept of locator/EID of NIMROD and PIP. Josh Osborne helped the Author to clarify the geographical identification feature of the proposal. References (to be provided) Security Considerations (to be provided) Author's Addresses Masataka Ohta Computer Center Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3415 EMail: mohta@necom830.cc.titech.ac.jp M. Ohta Expires on Sept. 25, 1995 [Page 6] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 13 02:05:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08696; Sun, 13 Oct 96 02:05:56 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08690; Sun, 13 Oct 96 02:05:37 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA03475; Sun, 13 Oct 1996 01:59:17 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA26180 for ; Sun, 13 Oct 1996 01:59:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA26180; Sun, 13 Oct 1996 01:59:16 -0700 From: Masataka Ohta Message-Id: <199610130858.RAA03267@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id RAA03267; Sun, 13 Oct 1996 17:58:09 +0900 Subject: (IPng 2310) Re: use of IPv6 Flow Label for tag switching To: deering@parc.xerox.com (Steve Deering) Date: Sun, 13 Oct 96 17:58:07 JST Cc: fred@cisco.com, yakov@cisco.com, ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com In-Reply-To: <96Oct9.122322pdt."75270"@digit.parc.xerox.com>; from "Steve Deering" at Oct 9, 96 12:23 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > Fred and Yakov, > > Here are some comments/questions on your draft for using IPv6 Flow Labels > as tags, draft-baker-flow-label-00.txt. Is April 1st not enough and you all are joking for October 1st? While tag switching is: > Either that, or a last-ditch attempt to keep ATM from tanking. why don't they use ATM VPI/VCI (upto 28 bits with NNI), Ethernet local MAC address (more than 40 bits, except for those already reserved by Steve for IPv6 multicast) and, maybe, a new PPP header option? Ip/tag switching means forwarding with layer 2 labels, isn't it? > Is there anyone else out > there inventing novel ways to bypass IP processing for IP packets? Here is, with TTL decrementing and without even detecting a flow. But it has nothing to do with Ipv6 nor tag switching ML. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 13 03:35:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08759; Sun, 13 Oct 96 03:35:19 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08736; Sun, 13 Oct 96 03:34:43 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA04976; Sun, 13 Oct 1996 03:28:22 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id DAA28738 for ; Sun, 13 Oct 1996 03:28:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA28738; Sun, 13 Oct 1996 03:28:22 -0700 From: Masataka Ohta Message-Id: <199610131027.TAA03405@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA03405; Sun, 13 Oct 1996 19:27:11 +0900 Subject: (IPng 2311) Re: IPv6 Other Work in Progress and Needed. To: rja@cisco.com (Ran Atkinson) Date: Sun, 13 Oct 96 19:27:10 JST Cc: roque@di.fc.ul.pt, ipng@sunroof.eng.sun.com In-Reply-To: <199610111619.JAA16427@cornpuffs.cisco.com>; from "Ran Atkinson" at Oct 11, 96 9:19 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > % I understand the desire to identify an SA independently of the IP address > % being used, if those IP addresses are subject to chance. What i don't > % understand is why an Confused_Word would be a superior alternative to an opaque X bit > % number (assigned by the host for instance) as long as it is possible to > % initially associate a credential with it. > > If the "opaque X bit number" is globally unique identifier, then it could be > used. Note, however, that it that number is globally unique, it is then by > definition an Confused_Word. If the "opaque X bit number" is not globally unique, > then it won't work. For some ID be useful for security with shared secret keys, which can not scale globally, uniqueness is not essential. For some ID be useful for some security all over the Internet, there must be an Internet-wide directory services (service depends on the type of the security) to relate the ID to public keys. For such directory services, the ID should not only be unique but also have hierarchy. DNS may be able to act as such directory service, though secure DNS can offer IANA-rooted security only. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 13 09:28:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08853; Sun, 13 Oct 96 09:28:24 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08847; Sun, 13 Oct 96 09:28:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA12336; Sun, 13 Oct 1996 09:21:50 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA13580 for ; Sun, 13 Oct 1996 09:21:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA13580; Sun, 13 Oct 1996 09:21:49 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA23210; Mon, 14 Oct 1996 02:21:39 +1000 (from kre@munnari.OZ.AU) To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2312) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Sun, 13 Oct 1996 16:50:43 +0200." <199610130750.QAA03070@necom830.hpcl.titech.ac.jp> Date: Mon, 14 Oct 1996 02:21:33 +1000 Message-Id: <4024.845223693@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 13 Oct 96 16:50:43 JST From: Masataka Ohta Message-ID: <199610130750.QAA03070@necom830.hpcl.titech.ac.jp> What do you fear? I fear that we may end up consuming too much of the upper 8 bytes for our internal routing if we go the way of using 8+8 addresses. With the current schemes proposed for IPv6 we get 16 bits available for internal routing, which is more than enough for now, and plenty for some time into the future. If it runs out, consuming just one bit of the upper 8 bytes will give us lots of new space. With 8+8 we'regoing to need to consume a much larger chunk of the top 8 bytes of the addressing, as our internal routing goes there. Could you please assume almost automatic renumbering available even with the running TCP connection intact? Yes, that I do. Renumbering isn't the problem. We renumber things all the time. We don't do Brian Carpenter type "renumber the universe in a month" stuff right now, as that's too hard with IPv4, but we do renumber hosts on subnets to shuffle available space around. We just have lots of hosts, and lots of internal subnets. Note that the world population is less than 10^10. This argument (how many bits are really needed) is exactly what I hoped to avoid starting again. All I will say now is that there are people who didn't believe that 128 bits was enough (and others who believed that 64 was plenty including on-subnet addressing). Finally, use 8 bits to support 10^2 entries maybe within a subscriber. This one is already way insufficient for us (I think we have now about 300-400 subnets, it is hard to tell as there's no point on the (local) net where they are all visible together). Into the future we'd need (at least) all of ... So, 8 bits are left unused leaving just the ... the original safety factor of 10^2. which begins to look just a little thin. This is not necessarily fatal, just the kind of thing that will cause disputes. Suuurrrreee. Attached is my I.D. more than half and a year ago included but not limited to "the definition of IID", "how it is used in IPv6", "just the number itself", "how it is allocated". Any comment? Trivially, there'a a typo, a 2^28 should be 2^48 (or perhaps 2^46 to be pedantic). More importantly, the draft is both too much and not enough. It is too much in that it includes a lot more than just the IID definition, and a draft that included only that, so it could be referred to by people not in the least interested in locator assignments, etc, would be useful. The problem that including all that in the same doc as the definition of te IID is that people who don't agree with your suggested method of doing the routing (and I think I am one, but let's forget that for now) are likely to object to the doc, and so kill the IID part along with the rest. It is insufficient in that it doesn't give enough detail about the properties of the IID. It does say that the IID should be used for DNS lookups to return the name, but doesn't explain how that would be done for the unstructured IID. It also says nothing about how multicast IIDs are assigned, and what, if any, meaning those have. Nothing is said about when an IID should be assigned, when, if ever, one should be changed, what is possible if no IID exists, etc. That is, we need a really complete specification. Don't misunderstand me, I think you, and everyone here by now, realises that I am a supporter of the use of some kind of *ID and I would like to see some proposal to incorporate them get adopted. If we can graft space out of the 128 bit address to make that happen, that's great. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 13 09:39:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08877; Sun, 13 Oct 96 09:39:48 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08871; Sun, 13 Oct 96 09:39:35 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA12670; Sun, 13 Oct 1996 09:33:14 -0700 Received: from tera.csl.sony.co.jp (tera.csl.sony.co.jp [133.138.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA14269 for ; Sun, 13 Oct 1996 09:33:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA14269; Sun, 13 Oct 1996 09:33:13 -0700 Received: from vega.csl.sony.co.jp (vega-197.csl.sony.co.jp [133.138.197.24]) by tera.csl.sony.co.jp (8.6.12+2.4W/3.3W3) with SMTP id AAA02107; Mon, 14 Oct 1996 00:48:41 +0900 Message-Id: <199610131548.AAA02107@tera.csl.sony.co.jp> X-Sender: tera@tera.csl.sony.co.jp X-Mailer: Windows Eudora Pro Version 2.2-Jr1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Date: Mon, 14 Oct 1996 00:47:30 +0900 To: Masataka Ohta From: =?ISO-2022-JP?B?GyRCO3syLEo4Q0sbKEog?= Subject: (IPng 2313) Re: IPv6 Other Work in Progress and Needed. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ohta-san, At 21:07 96/10/12 JST, Masataka Ohta wrote: > My proposal is to: > > 1) use upper 8 byte of Ipv6 address for hierarchical routing > > 2) use lower 8 byte of Ipv6 address as *ID which is also > useful for intra-subnet delivery (the last hierachy of locator) > > 3) use *ID and port number identify a transport layer entity >From network architecture viewpoint, IMHO, *ID should be contained in other fields than address fields, as I wrote in previous mail. If the IPv6 base header is not modified, *ID should be in a destination option. If it is possible to modify the IPv6 base header and if each node must have a *ID, src/dst *ID fields should be added the end of the IPv6 base header. According to your previous mail, it seems that *ID is based on layer-2 address. Is it right? If so, there are some problems. The layer-2 address of a node may change, e.g., a PC with PCMCIA can change its layer-2 medium, and a PCMCIA ether card used on a PC may be inserted into another PC. Thus, *ID should not be based on layer-2 addresses. Fumio TERAOKA ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 13 20:48:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09067; Sun, 13 Oct 96 20:48:45 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09061; Sun, 13 Oct 96 20:48:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA06136; Sun, 13 Oct 1996 20:42:05 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA13982 for ; Sun, 13 Oct 1996 20:42:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA13982; Sun, 13 Oct 1996 20:42:04 -0700 From: Masataka Ohta Message-Id: <199610140341.MAA04387@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA04387; Mon, 14 Oct 1996 12:40:58 +0859 Subject: (IPng 2314) Re: IPv6 Other Work in Progress and Needed. To: tera@csl.sony.co.jp (=?ISO-2022-JP?B?GyRCO3syLEo4Q0sbKEog?=) Date: Mon, 14 Oct 96 12:40:57 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199610131548.AAA02107@tera.csl.sony.co.jp>; from "=?ISO-2022-JP?B?GyRCO3syLEo4Q0sbKEog?=" at Oct 14, 96 12:47 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Teraoka-san; > > My proposal is to: > > > > 1) use upper 8 byte of Ipv6 address for hierarchical routing > > > > 2) use lower 8 byte of Ipv6 address as *ID which is also > > useful for intra-subnet delivery (the last hierachy of locator) > > > > 3) use *ID and port number identify a transport layer entity > > >From network architecture viewpoint, IMHO, *ID should be contained > in other fields than address fields, as I wrote in previous mail. Don't assume IPv4 ARP and IPv4 addressing. >From network architecture viewpoint, it is essential to contain *ID in address fields. > > 2) use lower 8 byte of Ipv6 address as *ID which is also ^^^^^^^^^^^^^ > > useful for intra-subnet delivery (the last hierachy of locator) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ With the above format, ARP (actually, ND) resolves maping between *ID and MAC. That is, the IP subnet model is preserved even between a mobile host and a foreign agent. As you know, current mobility proposals do not use regular subnet model in mobile segments, which is an architectural problem. > If the IPv6 base header is not modified, *ID should be in a > destination option. Considering security issues, *ID must be visible by network layer firewalls. > According to your previous mail, it seems that *ID is based on > layer-2 address. Is it right? No. Some *ID may be based on MAC for, say, local autoconfiguration. But, such *ID is not useful for, say, DNS lookup all over the Internet. *ID for global look-up needs to have some hierarchy (though the hierarchy has nothing to do with routing). Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 13 22:02:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09112; Sun, 13 Oct 96 22:02:40 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09106; Sun, 13 Oct 96 22:02:22 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA09281; Sun, 13 Oct 1996 21:56:01 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAA22640 for ; Sun, 13 Oct 1996 21:55:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA22640; Sun, 13 Oct 1996 21:55:57 -0700 From: Masataka Ohta Message-Id: <199610140454.NAA04518@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA04518; Mon, 14 Oct 1996 13:54:38 +0900 Subject: (IPng 2315) Re: IPv6 Other Work in Progress and Needed. To: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 14 Oct 96 13:54:37 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <4024.845223693@munnari.OZ.AU>; from "Robert Elz" at Oct 14, 96 2:21 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre; > What do you fear? > > I fear that we may end up consuming too much of the upper 8 bytes > for our internal routing if we go the way of using 8+8 addresses. How can you think, then, 16 bytes are enough? Why don't you use 20 bytes of NSAP address with CLNP? > With 8+8 we'regoing to need to consume a much larger chunk of the > top 8 bytes of the addressing, as our internal routing goes there. And, as I have shown, we still have a spare byte in addition to the safety factor of 100 even with a fixed hierarchy. > If it runs out, consuming just one > bit of the upper 8 bytes will give us lots of new space. Sure. With variable length hierarchy, we can save even more. > With the current schemes proposed for IPv6 we get 16 bits available > for internal routing, which is more than enough for now, and plenty > for some time into the future. Yes, yes, yes. But, with renumbering made easy, why do you think you need the space with fixed size? Can you say renumbering? > Could you please assume almost automatic renumbering available even > with the running TCP connection intact? > > Yes, that I do. Renumbering isn't the problem. We renumber things > all the time. We don't do Brian Carpenter type "renumber the universe > in a month" stuff right now, as that's too hard with IPv4, but we do > renumber hosts on subnets to shuffle available space around. We just > have lots of hosts, and lots of internal subnets. So, are you against 8+8 because renumbering with IPv4 is hard, even though the discussion is to have *ID for easy renumbering? BTW, as I responded to Teraoka-san, if you don't use *ID as part of address, you must renumber the lower part of address upon the movement of a host, which destroys the regular subnet model on mobile segments. Isn't it the wart of the current mobility proposal we should avoid? If it is, IID should essentially be part of IPv6 address. The issue was once discussed in Stockholm meeting for IPv6 mobility, where one of a co-chair (sorry, I've forgot the name) really wanted *ID for this purpose. But most of the people there couldn't understand what is the problem. > Note that the world population is less than 10^10. > > This argument (how many bits are really needed) is exactly what > I hoped to avoid starting again. All I will say now is that > there are people who didn't believe that 128 bits was enough (and > others who believed that 64 was plenty including on-subnet addressing). Kre, a mere statement that "didn't believe that 128 bits was enough" does not constitute an argument. Ignore it. > Finally, use 8 bits to support 10^2 entries maybe within > a subscriber. > > This one is already way insufficient for us (I think we have now > about 300-400 subnets, it is hard to tell as there's no point on > the (local) net where they are all visible together). Into the > future we'd need (at least) all of ... If your current block is small and not expandable, renumber!, renumber!!, renumber!!! > So, 8 bits are left unused > > leaving just the ... In addition to the safety factor of 100 and the fixed hierarchy boundary. > the original safety factor of 10^2. > > which begins to look just a little thin. This is not necessarily > fatal, just the kind of thing that will cause disputes. 100 is merely the safety factor of the original requirement of 10^12. You still have a spare byte and variable length netmasks. Moreover, as I used a byte-aligned hierarchy, there actually remains a several more bits available unused. > Suuurrrreee. Attached is my I.D. more than half and a year ago included > but not limited to "the definition of IID", "how it is used in IPv6", > "just the number itself", "how it is allocated". > > Any comment? > > Trivially, there'a a typo, a 2^28 should be 2^48 Aha, yes. Thank you. > (or perhaps 2^46 to be pedantic). It would have only resulted in a proposal to use currently local part globally to make use of 2 more bits. > More importantly, the draft is both too much and not enough. > > It is too much in that it includes a lot more than just the IID > definition, ..... As you wrote:: > about when an IID should be assigned, when, > if ever, one should be changed, what is possible if no IID exists, > etc. That is, we need a really complete specification. I should have written and did wrote a complete specification. Especially, I must show that it is defined reasonably. That is, I must determine the length, the feasible assignment methods and everything. > It is insufficient in that it doesn't give enough detail about the > properties of the IID. It does say that the IID should be used > for DNS lookups to return the name, No. It says: Structured IIDs are maintained by IANA and is used to lookup IANA maintained database of in-addr.arpa. equivalent of IPv6. > but doesn't explain how that > would be done for the unstructured IID. Why, do you think, such a thing could be possible? For the unstructured IID, the draft specifically says: Unstructured IIDs are directly derived from globally unique MAC addresses of hosts and useful for autoconfiguration. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ only. > It also says nothing about > how multicast IIDs are assigned, and what, if any, meaning those > have. ..... Isn't it obvious that an IPv4 multicast address is already location independent and just an ID? So, any IPv4 multicast routing protocol works as is, if IID is used instead of IPv4 multicast address. OK, in the next revision, I'll add a sentence to explain it. > Nothing is said about when an IID should be assigned, when, > if ever, one should be changed, what is possible if no IID exists, > etc. That is, we need a really complete specification. In the draft, there already exists a complete specification: Structured IIDs are maintained by IANA and is used to lookup IANA maintained database of in-addr.arpa. equivalent of IPv6. I think you know that the management of IPv4 addresses is through in-addr.arpa delegation and what is possible if no IPv4 address exists. Unstructured IID will be maintained by something outside of IETF, most certainly by IEEE, which should not be a part of IETF specification. > Don't misunderstand me, I think you, and everyone here by now, > realises that I am a supporter of the use of some kind of *ID > and I would like to see some proposal to incorporate them get > adopted. If we can graft space out of the 128 bit address to > make that happen, that's great. I, of course, understand that you are for *ID to solve, for example, renumbering and mobility warts. And, even if not, your comments are always appriciated, of course. But, to criticise my proposal, please, please, don't forget that renumbering could be made easy. Aside the difficulty of renumbering, do you still think any technical issue remaining unsolved in my proposal? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 04:55:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09214; Mon, 14 Oct 96 04:55:24 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09208; Mon, 14 Oct 96 04:55:06 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA25421; Mon, 14 Oct 1996 04:48:44 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA20348 for ; Mon, 14 Oct 1996 04:48:42 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA20348; Mon, 14 Oct 1996 04:48:42 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id LA01002; Mon, 14 Oct 1996 21:48:31 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2316) Re: IPv6 Other Work in Progress and Needed. In-Reply-To: Your message of "Mon, 14 Oct 1996 13:54:37 +0200." <199610140454.NAA04518@necom830.hpcl.titech.ac.jp> Date: Mon, 14 Oct 1996 21:48:24 +1000 Message-Id: <4262.845293704@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 14 Oct 96 13:54:37 JST From: Masataka Ohta Message-ID: <199610140454.NAA04518@necom830.hpcl.titech.ac.jp> How can you think, then, 16 bytes are enough? Because with 16 bytes, I know that there will be 8 available for routing external to our organisation, not just 6. And, as I have shown, we still have a spare byte in addition to the safety factor of 100 even with a fixed hierarchy. I thought I managed to consume that spare byte out of your hierarchy. Sure. With variable length hierarchy, we can save even more. Yes, but that wasn't what I was getting at, with the current schemes I just get one more organisation number, which effectively just consumes one bit (I would have 2 64 bit spaces, the equiv of a 65 bit space, ignoring whether they are numbered so that they could be treated that way). This is totally independant of any variable length assignment schemes (which incidentally I am amazed we are not planning, proposing fixed length assignments now is bizarre). Yes, yes, yes. But, with renumbering made easy, why do you think you need the space with fixed size? No no no - you aren't paying attention. Right now we need 10 bits (at least) of subnet routing space (internally). That's the number of distinct nets we have. But when we plan address space needs we need to work out what out demand will eventually be, not what it is now. My estimate is that within reasonable lifetimes for IPv6 we're likely to need 16 bits of subnet routing space. That is, we're likely to have > 30000 nets to route internally. Renumbering has nothing whatever to do with this, we can renumber ever hour forever, but 30000 nets will still be 30000 nets, and each of them needs some kind of a number... It is going to consume 16 bits (well, 15 perhaps) to hold those 30000 distinct numbers, and there's no way you can possibly renumber them to make 30000 distinct numbers fit in less that 15 bits! So, are you against 8+8 because renumbering with IPv4 is hard, even though the discussion is to have *ID for easy renumbering? No. Will you please forget renumbering. Renumbering has nothing at all to do with anything I have said. I am also not arguing against 8+8. I am simply point out some of the issues that you are going to need to address. Kre, a mere statement that "didn't believe that 128 bits was enough" does not constitute an argument. No, it doesn't, or perhaps shouldn't. However, the IETF works by consensus. That is, you have to make everyone comfortable that your proposal is right. Simply being right is useless. If people are uncomfortable that 64 bits of routing space will be sufficient, then they will not adopt your proposal. To have it accepted you need to do the work of showing that it is enough. > but doesn't explain how that > would be done for the unstructured IID. Why, do you think, such a thing could be possible? I don't necessarily, but I would think that needs to be expressly stated, even more than you did. Isn't it obvious that an IPv4 multicast address is already location independent and just an ID? Yes, but but (effectively) 24 bit IPv4 multicast addresses, and new 64 (effectively 62 or something) new ones aren't going to have a 1::1 mapping between them. nb: this is not a routing question, but an assignment question, are some addresses to be reserved for local scopes, if so, which, etc. > Nothing is said about when an IID should be assigned, when, > if ever, one should be changed, what is possible if no IID exists, > etc. That is, we need a really complete specification. In the draft, there already exists a complete specification: No, that's different. What you have explained is how I can get one when I decide I want it. The question I asked is when I should decide I want it. That relates to for what purposes I can use an auto-assigned type (not IANA rooted assignment), etc. Then there is the reassignment. I would have expected a *ID to remain for as long as the host (or role, or whatever) exists, it should never need a new one, yet your draft seemed to imply that an IID could be changed. Why would anyone want to do that? Note - that is a question to which an answer is needed in the draft, not here. But, to criticise my proposal, please, please, don't forget that renumbering could be made easy. I won't forget. But you please remember that easy renumbering solves routing table scaling problems, renumbering doesn't in any way reduce the number of numbers consumed. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 09:47:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09431; Mon, 14 Oct 96 09:47:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07293; Fri, 11 Oct 96 18:57:43 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA12065; Fri, 11 Oct 1996 18:51:24 -0700 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA29239 for ; Fri, 11 Oct 1996 16:47:27 -0700 Received: by mail.noris.net id <35169-5040>; Fri, 11 Oct 1996 18:11:27 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2317) Re: use of IPv6 Flow Label for tag switching Date: 11 Oct 1996 18:08:08 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 122 Message-Id: <53lrd8$pdc@work.smurf.noris.de> References: <9610100055.AA21188@fwasted.zk3.dec.com> <325D22FC.773C2448@cisco.com> <844966149.13664@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: unlisted-recipients:;@venus (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In dist.ipng, article <844966149.13664@noris.de>, Fred Baker writes: > > IMHO, in present IP6, I have a choice between doing a destination > lookup, or a source lookup in the same table followed by a hashed lookup > in another table. I really cannot imagine how the latter would be an > improvement over the former, and never have been able to figure that > out. As a result (speaking for myself, not my employer) I can't imagine > why any router vendor would implement the flow label as specified. How could they do it otherwise? The alternatives are (1) make the flow hop-by-hop, or (2) negotiate the flow ID so that it's unique across the path the packets take. (2) is difficult; for multicast traffic it's essentially impossible. (1) means that the flow ID may change in mid-traffic (as the path to the destination changes). Essentially, then, it becomes a hint which router A passes to router B how to process the packet. Hmmmm. That's certainly possible, assuming that the flow is recognized and tagged by _someone_. Preferably, the sending host could use a counter which increments for each new connection. This of course means that it's not a flow any more, it's a (routing) tag. Since the tag is hop-by-hop, it needs to be either understood or cleared by all routers. It's no good to leave the tag unchanged because then packets from A and B, both routed through non-flow-ID-aware C, arrive at D with identical IDs. D's messages to C to please reassign the tags are rejected or ignored. D can't assign 100%-new tags because it then would have to keep track of all the traffic from C. D can't keep track of all the destination addresses from C and still do any significant routing, so the only way out is to clear the tag. Implementing routing tags isn't difficult at all, but you need cooperation from hosts (they need to pre-tag their connections -- the routers can't do that) and _all_ routers. I'm thinking of a scheme like this: One bit (I'll call it "A") of the ID is reserved to tell whether the tag has been assigned by the destination router. If that bit is set, the tag is directly usable for routing (timeouts: see later). If it's clear, then the tag has been assigned by the previous hop. How to forward a packet: If we don't support tags: clear the tag forward according to destination. else if the tag is zero: forward according to destination. else if the A bit is zero: (the tag in the packet is assigned by the previous router) If there is no forwarding structure for (previous-tag/previous-router) Set up new forwarding structure with new, locally-unused, tag Send ICMP to previous-host to replace previous-tag with new-tag forward according to structure. else (the tag is assigned by us) lookup forwarding structure by indexing through the tag if found and OK if the last packet was sent too long ago clear next-hop tag set our-tag to a new locally-unused tag if there is a next-hop tag set tag to next-tag, set A bit else set tag to our-tag, clear A bit forward according to structure else clear tag send ICMP to previous-router to clear the tag set timer forward according to destination Originating a packet works the same way, exxcept that the forwarding structure is set up once when the connection is established. An originating host needs to observe this new ICMP message. If a message to clear/reassign a tag contains our-tag (the sender's previous-tag) and next-tag (the sender's our-tag): if previous-tag is zero: find forwarding structure with destination next-tag/next-router clear next-tag set our-tag to a new locally-unused tag (might not be necessary) else find forwarding structure with our-tag remember next-tag Presumably, this message could also contain a hint about the current timeout for forwarding structures. Thus, if the last packet for a particular flow was sent a long time ago, the source router immediately assigns a new local tag and sends If the timer runs out, the message could be repeated, or the forwarding structure is deleted. If this happens sufficiently often, i.e. the source router never sends packets with the A-bit set, we declare the thing bogus and ignore its tags. All of this is semantically distinct from the way IPng says a flow ID should work. That's because it's no flow ID, it's a tag. The question is, does this type of tagging make sense? It would mean that you need a tag for _every_ different source/destination combination which passes through any given router. Are there any data how many source/destination combinations pass through the backbone routers? (Log all packets that arrive within one minute, extract source/destination address, sort -u, mail to ipng-list, please.) If there are too many, we can forget about tagging. If not, do we need the old flow scheme at all (given that the local IDs could be set up at the same time we set up the flow, I don't think so) and do we defenestrate the previous recommendations about flow IDs? NB: for the Latin-challenged: "to defenestrate" means to throw something out of a window. -- A white lie is aversion of the truth. -- Alan F. G. Lewis -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 09:50:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09443; Mon, 14 Oct 96 09:50:13 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA07443; Fri, 11 Oct 96 20:42:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA04537; Fri, 11 Oct 1996 20:36:33 -0700 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA19111 for ; Fri, 11 Oct 1996 16:46:29 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA19111; Fri, 11 Oct 1996 16:46:29 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA01331; Fri, 11 Oct 1996 10:46:04 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA20238; Fri, 11 Oct 1996 10:44:48 -0400 Message-Id: <9610111444.AA20238@fwasted.zk3.dec.com> To: Fred Baker Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2318) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Thu, 10 Oct 96 09:23:24 PDT." <325D22FC.773C2448@cisco.com> Date: Fri, 11 Oct 96 10:44:47 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Fred, >you might try tagswitch@cisco.com. Do you want me to add you to it? Yes please add me. Thanks.... >> 3. Its another way to do IP/L2 routing/switching but it seems pretty >> obvious to me there will be or are already patents on the technology >> which kinda bums me out if you really want this to be a standard. It >> could even affect if I even care or anyone else and whether any of this >> should ever achieve Full Standard? Unless that is not your goal like >> IFMP being specified? Are you playing the Opens Systems game here or >> the proprietary game here? >I think we're saying that this is something that we're working on and >think we can make work well; if it does, we expect that portion of the >backbone which is Cisco routers and switches might very well use it. If >the other parts of the backbone want to also, we're all for it. For that >to happen, some standards need to be written; if you folks don't want >to, that's fine too. If we were playing the proprietary game, you >wouldn't be reading public articles about it, but we're willing to be >proprietary if you want. This makes sense OK. I think if a vendor invents a new technology that benefits their customer thats always goodness. I also think if there are interfaces or mechanisms that if defined permit that customers other vendors in a specific technology domain (like the Internet and Intranet Backbone) to participate then we need some kind of standard. That does not always have to be done in the IETF I am starting to believe when the market has a need that the IETF is just moving to slow on (e.g. Dynamic Updates to DNS, Service Location, HTTP, Mobile, etc....), and cosortias will solve the problem more efficiently so it can get deployed more expediently. But I think anything we standardize in the IETF SHOULD NOT have vendor patents on that standard, unless there is no royalty charge and people can use it for FREE. So thats where I am coming from on that vantage point OK. That is what I mean't with my "OPEN SYSTEMS" game comment. As far as it being proprietary or not thats the vendors choice. Leaving it propietary means there will be competition and that is usually a good thing for the economy, unless its done as a monopoly. Its what you want to achieve with a new technology as a vendor, which I believe is the determination of it being proprietary or open. I personally think TDP is an interesting method to solve the IP/L2 switch problem, but I think the distribution should include Hosts in its architecture. But thats just my own architecture view as one who also like you builds products. >> But if you do use it and the G bit is zero then I as a host assume the >> behavior specified in IPv6. >Let me remind you the status of the flow label (RFC 1883, page 28): The 24-bit Flow Label field in the IPv6 header may be used by a source to label those packets for which it requests special handling by the IPv6 routers, such as non-default quality of service or "real-time" service. This aspect of IPv6 is, at the time of writing, still experimental and subject to change as the requirements for flow support in the Internet become clearer. Hosts or routers that do not support the functions of the Flow Label field are required to set the field to zero when originating a packet, pass the field on unchanged when forwarding a packet, and ignore the field when receiving a packet. >IMHO, in present IP6, I have a choice between doing a destination >lookup, or a source lookup in the same table followed by a hashed lookup >in another table. I really cannot imagine how the latter would be an >improvement over the former, and never have been able to figure that >out. As a result (speaking for myself, not my employer) I can't imagine >why any router vendor would implement the flow label as specified. Glad you posted this to remind all and me. I think we should get rid of the version field and priority field and have a 32bit flow label. I think then we should put the dst address right after it. Simply because this is more efficient for routing, the priority bits are not needed if we define some basic flow labels up front, and the version number is not needed if we define that for other link-layers and tunnels some how as we have done for the Ethertype for Ethernet. As far as code change to existing IPv6 implementations I can only speak for ours and to do this is negligable at best (basically reoder the parsing of the header). Oh and all the books would be bogus but who cares they can sell updated editions and this is not a reason to not fix the header. Nor do I think this should prevent us from doing this as a change to get to Draft Standard for RFC 1883? But this is just a wish list on my part. And reodering the addresses was deemed not a gain at the L.A. meeting this year. My issue with the proposal to use the flow for TAGs is that it uses up a bit I might need to generate a flow from the host (e.g. as request or path for RSVP, Realtime QOS, or other IP/L2 switch proposals that do not require the bit to be used) in an architecture that does not include hosts in its set-up protocol. Given your above comment. A hop-by-hop option can be used by TDP to inform the router that the flow-label is being used as the flow label which I think is even a better solution than the G bit. Here is why: Its just a lookup at the option after the header which has already been extacted and an offset test can be made into the hop-by-hop option. If set then the flow-label is being used as a tag identifier. Even if TDP included hosts I would not feel using up the flow-label bit in this manner is a good idea either. This has no effect to your lookup if the flow label can be used. The benefit is that the flow-label is not further defined leaving it open to be used by anyone. Now as far as the flow-label itself being used in IPv6. If a host does set it for say RSVP to be used by the flow-spec then we don't want that flow-label stepped on (same for Realtime QOS needs using IPv6 or IP over Cable and other technologies to-be-defined using IPv6) Hosts need that to be end-to-end for a guranteed service across what the Host knows to be the "path". Now I know some router folks have a problem with Hosts assuming this and that maybe is the real battle-ground for flow-labels and tags/TDP is just going to resurface that discussion, but for the moment lets assume thats OK and its bi-partisan. Given the premise I state above I think it would be really good if TAGS and all new technology that wants to use the flow-label in fact uses the hop-by-hop option to define the "flow-representation" and its semantics for a packet as opposed to using up bits in the flow-label to define what it means. I think this will make the entire technical strategy to use flows more extensible for the industry, customers, and vendors whom will develop creative ways to use flow-labels. I think this keeps the 24 bits (and if I were king 32bits) pristine for flow-labels and proves to us the value of the hop-by-hop options we have invented for IPv6. It also keeps the spirit if changing parts in the architecture for what will be the International standard for the Internet Protocol Next Generation very "OPEN" as one objective and reason for the change at this point in the IPv6 spec evolution. Is this not a reasonable compromise to at least consider for your spec? >> This should be discussed on the IPng WG list. > This *is* the ipng list, no? Yes. Was not sure if that was a done deal? I guess it is right? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 10:06:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09498; Mon, 14 Oct 96 10:06:00 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08797; Sun, 13 Oct 96 07:07:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA08691; Sun, 13 Oct 1996 07:01:32 -0700 Received: from mail.noris.net (main.noris.net [193.141.54.1]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA05930 for ; Sun, 13 Oct 1996 07:01:31 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA05930; Sun, 13 Oct 1996 07:01:31 -0700 Received: by mail.noris.net id <35167-26946>; Sun, 13 Oct 1996 16:01:32 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2319) Re: suggestion (long) (replay) Date: 13 Oct 1996 16:01:10 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 36 Message-Id: <53qsn6$l3f@work.smurf.noris.de> References: <53lrrj$pef@work.smurf.noris.de> <11113.845096561@munnari.OZ.AU> <845098368.16235@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: unlisted-recipients:;@mercury (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > From: smurf@noris.de (Matthias Urlichs) > > IMHO, the original adresses used for connection establishment should _be_ > the "EID"s for the purpose of this discussion. > > The problem with this is that the original address may have been > switched to be used by someone else while the original connection > remains intact. Umm, I don't know whether that's a problem. After the initial exchange, packets do get labelled with "new" addresses, and the old address is only used for replacing the old address with the new one in the procotol control block. After the new address is known, the old one can be deleted. Therefore, there's no real problem, assuming that there's at least one packet exchange on any open TCP (or whatever) connection during the transition period. With the large address space we have with IPng, I'd say that the chance that your permanent address, after a renumber, suddenly shows up somewhere else, is pretty slim (after all, the link-level 48 bits are supposed to be globally unique...). The above isn't much of an "EID" any more, of course, but since there still doesn't seem to be any kind of consensus on what EIDs are supposed to mean, much less whether we need them, I view that as no great loss, myself. ;-) -- HOORAY, Ronald!! Now YOU can marry LINDA RONSTADT too!! -- Zippy the Pinhead -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 10:06:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09508; Mon, 14 Oct 96 10:06:38 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09500; Mon, 14 Oct 96 10:06:15 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA03499; Mon, 14 Oct 1996 09:59:23 -0700 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA17788 for ; Mon, 14 Oct 1996 09:58:29 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA17788; Mon, 14 Oct 1996 09:58:29 -0700 Received: from fred-ss20.cisco.com (fred-ss20.cisco.com [171.69.58.89]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id JAA06053; Mon, 14 Oct 1996 09:57:39 -0700 (PDT) Received: from fred-ss20 (localhost.cisco.com [127.0.0.1]) by fred-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id JAA02298; Mon, 14 Oct 1996 09:57:38 -0700 Message-Id: <32627102.6F5992E1@cisco.com> Date: Mon, 14 Oct 1996 09:57:38 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 3.0GoldC-CISCOENG (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2320) Re: use of IPv6 Flow Label for tag switching References: <9610121426.AA00635@fwasted.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: > >6. Flow Labels > > > > The 24-bit Flow Label field in the IPv6 header may be used by a > > source to label those packets for which it requests special handling > > by the IPv6 routers, such as non-default quality of service or > > "real-time" service. This aspect of IPv6 is, at the time of writing, > > still experimental and subject to change as the requirements for flow > > support in the Internet become clearer. Hosts or routers that do not > > support the functions of the Flow Label field are required to set the > > field to zero when originating a packet, pass the field on unchanged > > when forwarding a packet, and ignore the field when receiving a > > packet. > > OK if a host specifies a flow of 000...02 for a path that routers are > using to give that application a dedicated path to another host and if > tags is deployed what will happen to the flow along the path. What does it say? That's the reason we are suggesting that we use one bit to distinguish between a tag and a flow label. IF the value is a flow label AND tags are deployed AND flow labels are not deployed, THEN per spec we would ignore the flow label, and destination route the traffic. > Will the packet be altered if TAGs is implemented? No. if we don't implement the OPTIONAL IP6 flow label facility, we won't implement the OPTIONAL RSVP Flow Label facility. Instead, the router will send a PATH ERROR or RESV ERROR message to the sender of the message. > >The objection is: A destination address lookup requires a certain cost; > >a source address lookup requires the same cost. The defined behavior in > >the router is a source address lookup plus an additional lookup. The > >specified optimization fails first and foremost because it is not an > >optimization. > > But if you can use the source/flow as key for a dst address forwarding > path is that not an optimization? Why look up the source address the > source address/flow is just a key to determine in the lookup the > destination address which provides the forwarding path. So you're telling me that I have to look up the source, the destination, AND the flow label? Doing A+B+C takes less effort than doing A alone? In what way is this an optimization? What did it optimize? If you're telling me that this is helping in the VLSM selection, that is readily solvable. I don't need a protocol workaround for that. > In addition > based on the flow other QoS or Options in the forwarding path may be > present especially on a longest match. It means more table entries and > O(N) search would have to be optimized. Is that not better than today? No, at least not in every case, and I'm not sure why it would be. Here's one solution, one I deployed in Vitalink's router in 1989: consider the successive bytes of the address to be radixes in a radix tree. It takes four instructions and one memory access (load byte, use byte as an index to load address of next node, test for "leaf", conditional branch) to step through each successive radix. Where variable length masks are present, you have pointers to the appropriate next node in each place in the index table at each node to follow it (yes, the algorithms for building the tree are interesting, but by no means unsolvable). routes 128.1.0.0/16 root 128.1.2.0/24 /// | \\\ 128.1.3.0/24 |128 128.1.3.3/32 | node /// | subnet | 1 128.1.0.0 | | node / | | \\\ | 2 | 3 | | subnet node 128.1.2.0 | \\\ all | 3 \\\ others | \\\ host subnet 128.1.3.3 128.1.3.0 You deterministically get to the right subnet route or host route in a finite and small number of instructions, which BTW are implementable in a cheap FSM or sequencer if you're into lookup engines. If you have additional QoS identifiers, they fall into one of two categories - those that affect queuing, and those that affect routing. Those that affect routing you treat as additional bytes in the radix list, either at the beginning or the end (contrary to those to hotly debated this in the router requirements debate, putting it at either end makes no difference other than that it may affect memory volume). Those that affect queuing (like precedence) have additional handling after the lookup; the lookup only finds the parameters for that algorithm. OK, if the choice for doing a QoS lookup is between: a three byte tag a 16 byte source address plus a three byte flow label a 16 byte destination address plus a single byte ip protocol plus a two byte TCP port a 16 byte destination address plus a four byte IPSEC SPI Note, BTW, that (as suggested long ago), since the network hop receiving the message specifies the value, it can assure that the value is unambiguous. The tag therefore might not be used as a three byte radix, but as a three byte array index, for one memory look. Which is getting you the least instructions? Which is getting you the least memory references? (I'll grant you the point to point case, whee you have to look up the source AND the destination AND the IP protocol AND both TCP/UDP ports, but if you look at traffic on the net today, that's not a major contender). Which is an optimization? There are certainly many other implementation approaches - one suggestion made 2-3 years ago was that the flow label might be in a CAM. Use the algorithm you like best and demonstrate the optimization? > I don't see the optimization in TAGs. That could very well be because > it does not include hosts presently in the set-up protocol. I've addressed that complaint in my last two emails... > I don't think anything > we build should force anyone to pay some money to someone else to use > what we specify under the umbrella of the IETF in the core technology or > eliminate technical evolution for any part of the network. POISED. Take it to POISED. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 10:20:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09562; Mon, 14 Oct 96 10:20:12 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09556; Mon, 14 Oct 96 10:19:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA07260; Mon, 14 Oct 1996 10:13:30 -0700 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA23988 for ; Mon, 14 Oct 1996 10:13:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA23988; Mon, 14 Oct 1996 10:13:08 -0700 Received: from fred-ss20.cisco.com (fred-ss20.cisco.com [171.69.58.89]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id KAA08774; Mon, 14 Oct 1996 10:12:47 -0700 (PDT) Received: from fred-ss20 (localhost.cisco.com [127.0.0.1]) by fred-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id KAA02302; Mon, 14 Oct 1996 10:12:46 -0700 Message-Id: <3262748E.6EEA4806@cisco.com> Date: Mon, 14 Oct 1996 10:12:46 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 3.0GoldC-CISCOENG (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2321) Re: use of IPv6 Flow Label for tag switching References: <96Oct12.152630pdt."75270"@digit.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > Ever since then, I have on many occasions (including every meeting of > the End-to-End Protocols Research Group, which includes other > RSVP/int-serv designers, such as Bob Braden and John Wroclawski) e2e is an exclusive club that I'm not a member of > I cannot recall anyone presenting, to me or to the > IPng working group, a coherent alternative proposal I made my comments on the big-internet list. You're right, I gave up on anyone listening to alternatives before I got around to writing an internet draft. But if there's an archive, you'll find this very discussion in it. I could almost cut and paste messages. > a "coherent alternative proposal" must include a specification for how > flow labels are allocated and reclaimed, including labels for > multicast packets sent over multi-access links. Such a specification > must be at a sufficient level of detail for the working group to judge > how well it copes with label loss or collisions as a result of packet > loss, link partitioning, failure of the end-points and/or routers > participating in a flow, and other similar less-then-perfect network > behavior. It is also desirable that the proposal not require all > routers to have explicit support for flows. I am not trying to set > unreasonable requirements here -- it was consideration of precisely > these issues that led to, and are addressed by, the current IPv6 > flow label design. We have not yet published the suggested RSVP object or the approach in PIM for tag assignment; I believe that for the general unicast case, we have published a document (tdp) describing most of those things. That document describes that all routers need not support tags. maybe you'd like to post more specific questions to tagswitch? > Not everyone thinks hop-by-hop labels are good. I've worked that fact out :^) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 10:22:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09588; Mon, 14 Oct 96 10:22:50 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09582; Mon, 14 Oct 96 10:22:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA07957; Mon, 14 Oct 1996 10:15:40 -0700 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA25031 for ; Mon, 14 Oct 1996 10:15:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA25031; Mon, 14 Oct 1996 10:15:34 -0700 Received: from fred-ss20.cisco.com (fred-ss20.cisco.com [171.69.58.89]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id KAA09167; Mon, 14 Oct 1996 10:15:19 -0700 (PDT) Received: from fred-ss20 (localhost.cisco.com [127.0.0.1]) by fred-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id KAA02306; Mon, 14 Oct 1996 10:15:18 -0700 Message-Id: <32627526.5656AEC7@cisco.com> Date: Mon, 14 Oct 1996 10:15:18 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 3.0GoldC-CISCOENG (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: Steven Bellovin Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2322) Re: use of IPv6 Flow Label for tag switching References: <199610120100.VAA11813@raptor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven Bellovin wrote: > A much better idea. How do you prevent J. Random Luser from setting > that special bit from his/her hacked Linux box -- you know, the one > that's also emitting the phony IP addresses on the SYN packets... the same way you keep him from using the special flow label. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 11:20:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09634; Mon, 14 Oct 96 11:20:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09628; Mon, 14 Oct 96 11:20:08 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA14598; Mon, 14 Oct 1996 11:13:45 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA22741 for ; Mon, 14 Oct 1996 11:13:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA22741; Mon, 14 Oct 1996 11:13:40 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14852(6)>; Mon, 14 Oct 1996 11:10:37 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 14 Oct 1996 11:10:09 PDT To: Fred Baker Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2323) Re: use of IPv6 Flow Label for tag switching In-Reply-To: fred's message of Mon, 14 Oct 96 10:12:46 -0800. <3262748E.6EEA4806@cisco.com> Date: Mon, 14 Oct 1996 11:10:08 PDT From: Steve Deering Message-Id: <96Oct14.111009pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, > > Ever since then, I have on many occasions (including every meeting of > > the End-to-End Protocols Research Group, which includes other > > RSVP/int-serv designers, such as Bob Braden and John Wroclawski) > > e2e is an exclusive club that I'm not a member of And it was not the only place that I solicited input on the flow label design, as implied by the words "many" and "including" in the above quote. Every time that someone has come up to me and said "Why don't you make the flow label hop-by-hop?", I've said "Fine with me. But first show me how you are going to assign hop-by-hop flow labels to multicast packets sent over multiaccess links." And the response has usually been "Oh, I hadn't thought about that, but you're right -- that does need to be solved. Let me go away and think about that." And that's the last I hear from them. I'm still waiting. Don't get me wrong: I do *not* object to changing the flow label to hop- by-hop. I do hope you or someone else can come up with a good solution to the multicast flow-label allocation problem. > I made my comments on the big-internet list. You're right, I gave up on > anyone listening to alternatives before I got around to writing an > internet draft. But if there's an archive, you'll find this very > discussion in it. I could almost cut and paste messages. I don't know about others, but I have certainly been trying to listen. If you did post a solution to the multicast flow-label problem on the big-internet list, I apologize for missing it, and would appreciate receiving a copy of it. > We have not yet published the suggested RSVP object or the approach in > PIM for tag assignment; Do you view the multicast tag-allocation problem as specific to particular multicast routing protocols? I would have hoped that you would view this as a generic problem for all multicast routing protocols, and come up with a generic solution. > I believe that for the general unicast case, we have published a document > (tdp) describing most of those things. That document describes that all > routers need not support tags. Good. I haven't yet read the TDP spec in detail (personal hang-up: I always get bogged down in any spec that refers to packets or messages as "PDUs" :-). When I manage to get through it, if I have any questions, I'll post them to the tagswitch list as you requested. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 13:16:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09765; Mon, 14 Oct 96 13:16:35 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09676; Mon, 14 Oct 96 12:24:41 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA10760; Mon, 14 Oct 1996 12:18:06 -0700 Received: from tjok.tbit.dk (tjok.tbit.dk [194.182.135.79]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA14954 for ; Mon, 14 Oct 1996 12:17:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA14954; Mon, 14 Oct 1996 12:17:51 -0700 Received: from pcn.tbit.dk (pcn.tbit.dk [194.182.135.33]) by tjok.tbit.dk (8.7.5/8.7.3) with ESMTP id VAA13134; Mon, 14 Oct 1996 21:18:44 +0200 (MET DST) Received: from localhost (pcn@localhost) by pcn.tbit.dk (8.7.5/8.7.3) with ESMTP id VAA29209; Mon, 14 Oct 1996 21:16:31 +0200 (MET DST) Date: Mon, 14 Oct 1996 21:16:28 +0200 (MET DST) From: "Peder Chr. Norgaard" Reply-To: "Peder Chr. Norgaard" To: Vivek Venkatraman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2324) Re: MIBs for IPng In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-845320512=:29098" Content-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1804928587-845320512=:29098 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-ID: Content-Transfer-Encoding: quoted-printable On Sun, 6 Oct 1996, Vivek Venkatraman wrote: > Hallo, >=20 > I'd like to know if new MIBs have been defined or existing MIBs extende= d > for the IPng protocols. >=20 > thanks, > Vivek >=20 Well, it seems as if the group chartered with working on this topic is very passive. Needing a MIB for our product, the PAXNET router, I threw one together in our private enterprise subtree. I include the relevant part of the subtree in attachment. Now this is not something I have spent a whole lot of time on - I just took the MIB II and shuffled around with some things to adapt it to IPv6. The modifications are made are noted as comments in the MIB itself. I am no SNMP guru, so I am not even certain that the textual convention I defined for IPv6 addresses is correct (but I have checked that it works nicely with Scotty-based managers!). Furthermore, this mib is nothing like complete; it defines only the stuff that is usually defined in RFC 1213, minus the TCP and UDP groups which are not the most crucial ones for a router. The shortcomings aside, the MIB has proved quite useful and it was no more difficult to implement in the agent than the corresponding standardised IPv4 MIBs. You and everyone else are of course welcome to study and use this mib; and if the ipv6mib group needs some kind of kickstart, this mib may be copied to experimental subtree and developed further there. best regards Peder Chr. N=F8rgaard Systems Programmer, M. Sc.=20 Telebit Communications A/S tel: +45 86 28 81 77 - 49 Skanderborgvej 234 fax: +45 86 28 81 86 DK-8260 Viby J Denmark e-mail: pcn@tbit.dk ---559023410-1804928587-845320512=:29098 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="telebit.mib" Content-ID: Content-Description: Private enterprise MIB for part of IPv6 Content-Transfer-Encoding: BASE64 UEFYTkVULU1JQiBERUZJTklUSU9OUyA6Oj0gQkVHSU4NCg0KICAgIElNUE9S VFMNCgkgICAgTU9EVUxFLUlERU5USVRZLCBPQkpFQ1QtVFlQRSwgZW50ZXJw cmlzZXMsIENvdW50ZXIzMiwgSW50ZWdlcjMyDQoJICAgIAlGUk9NIFNOTVB2 Mi1TTUkNCgkgICAgRGlzcGxheVN0cmluZywgUm93U3RhdHVzLCBEYXRlQW5k VGltZQ0KCSAgICAgICAgRlJPTSBTTk1QdjItVEM7DQoNCiAgICBwYXhuZXQg TU9EVUxFLUlERU5USVRZDQogICAgICAgICAgICAgIExBU1QtVVBEQVRFRCAi OTYwNjE0MDkwNVoiDQoNCiAgICAgICAgICAgICAgT1JHQU5JWkFUSU9OICJU ZWxlYml0IENvbW11bmljYXRpb25zIEEvUywgRGVubWFyayINCiAgICAgICAg ICAgICAgQ09OVEFDVC1JTkZPDQogICAgICAgICAgICAgICAgICAgICAgIiAg ICAgICAgIg0KICAgICAgICAgICAgICBERVNDUklQVElPTg0KICAgICAgICAg ICAgICAgICAgICAgICJNSUIgZm9yIGNvbmZpZ3VyYXRpb24gYW5kIG1hbmFn ZW1lbnQgb2YgUEFYTkVUIHJvdXRlcnMiDQogICAgICAgICAgICAgIDo6PSB7 IGVudGVycHJpc2VzIDc2NiB9DQoNCg0KICAgIHBheE1hbmFnZW1lbnQgT0JK RUNUIElERU5USUZJRVIgOjo9IHsgcGF4bmV0IDIgfQ0KDQotLSBzdGFydGlu ZyB3aXRoIGludGVybmV0IGRyYWZ0IGRyYWZ0LWlldGYtc25tcHYyLWlwLWRz LTAzLnR4dA0KLS0gYWRkIHRleHQgY29udiBmb3IgYWRkcmVzcw0KLS0gY3V0 IGdyb3VwcyBpcCBhbmQgaWNtcCAoZHJvcCBjb21wbGlhbmNlIHN0dWZmKQ0K LS0gY2hhbmdlIG1pYi0yIHRvIG1pYjJ2Ng0KLS0gY2hhbmdlIGlwIHRvIGlw djYsIGljbXAgdG8gaWNtcHY2DQotLSBjaGFuZ2UgSVBWNiB0byBJUHY2LCBJ Q01QVjYgdG8gSUNNUHY2DQotLSBpcHY2QWRFbnRBZGRyLCBOZXRNYXNrIHRv IFByZWZpeCwgZHJvcCBCcm9hZGNhc3QgYWRkcg0KLS0gaXBDaWRyUm91dGVU YWJsZSBmcm9tIGRyYWZ0LWlldGYtb3NwZi1jaWRyLXJvdXRlLW1pYi0wNS50 eHQNCi0tIGNoYW5nZSBpcENpZHIgdG8gaXB2Ng0KLS0gcmVtb3ZlIFRvcywg Y2hhbmdlIG1hc2sgdG8gcHJlZml4LCBjaGFuZ2UgQVMgdG8gUkRJDQotLSBy ZW1vdmUgYWxsIGljbXAgdGltZXN0YW1wIHN0dWZmDQotLSBjaGFuZ2UgVFRM IHRvIEhvcCBMaW1pdA0KLS0gaW5jbHVkZSBJQ01QIHN0YXRpc3RpY3MgZm9y IEdyb3VwIE1lbWJlcnNoaXAsIFJvdXRlciBhbmQgTmVpZ2hib3Igc3R1ZmYN Ci0tIHNvcnQgaWNtcCBvYmplY3RzIGFjY29yZGluZyB0byB0aGUgbWVzc2Fn ZSBjb2Rlcw0KDQpJUHY2QWRkcmVzcyA6Oj0gVEVYVFVBTC1DT05WRU5USU9O DQogICAgRElTUExBWS1ISU5UICIyeDoyeDoyeDoyeDoyeDoyeDoyeDoyeCIN CiAgICBTVEFUVVMgICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQog ICAgICAgICAgICAiUmVwcmVzZW50cyBhbiBJUHY2IGFkZHJlc3MiDQogICAg U1lOVEFYICAgICAgIE9DVEVUIFNUUklORyAoU0laRSAoMTYpKQ0KDQoJbWli MnY2IE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IHBheE1hbmFnZW1lbnQgNiB9 DQoNCmlwdjYgICAgICAgICAgIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IG1p YjJ2NiA0IH0NCg0KDQoNCmlwdjZGb3J3YXJkaW5nIE9CSkVDVC1UWVBFDQog ICAgU1lOVEFYICAgICAgSU5URUdFUiB7DQogICAgICAgICAgICAgICAgICAg IGZvcndhcmRpbmcoMSksICAgIC0tIGFjdGluZyBhcyBhIHJvdXRlcg0KICAg ICAgICAgICAgICAgICAgICBub3RGb3J3YXJkaW5nKDIpICAtLSBOT1QgYWN0 aW5nIGFzIGEgcm91dGVyDQogICAgICAgICAgICAgICAgfQ0KICAgIE1BWC1B Q0NFU1MgIHJlYWQtd3JpdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgaW5kaWNhdGlvbiBv ZiB3aGV0aGVyIHRoaXMgZW50aXR5IGlzIGFjdGluZyBhcyBhbiBJUHY2DQog ICAgICAgICAgICByb3V0ZXIgaW4gcmVzcGVjdCB0byB0aGUgZm9yd2FyZGlu ZyBvZiBkYXRhZ3JhbXMgcmVjZWl2ZWQNCiAgICAgICAgICAgIGJ5LCBidXQg bm90IGFkZHJlc3NlZCB0bywgdGhpcyBlbnRpdHkuICBJUHY2IHJvdXRlcnMg Zm9yd2FyZA0KICAgICAgICAgICAgZGF0YWdyYW1zLiAgSVB2NiBob3N0cyBk byBub3QgKGV4Y2VwdCB0aG9zZSBzb3VyY2Utcm91dGVkIHZpYQ0KICAgICAg ICAgICAgdGhlIGhvc3QpLiINCiAgICA6Oj0geyBpcHY2IDEgfQ0KDQppcHY2 RGVmYXVsdEhvcExpbWl0IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAg SU5URUdFUiAoMS4uMjU1KQ0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtd3JpdGUN CiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAg ICAgICAgICAgICJUaGUgZGVmYXVsdCB2YWx1ZSBpbnNlcnRlZCBpbnRvIHRo ZSBIb3AgTGltaXQgZmllbGQgb2YNCiAgICAgICAgICAgIHRoZSBJUHY2IGhl YWRlciBvZiBkYXRhZ3JhbXMgb3JpZ2luYXRlZCBhdCB0aGlzIGVudGl0eSwN CiAgICAgICAgICAgIHdoZW5ldmVyIGEgaG9wIGxpbWl0IHZhbHVlIGlzIG5v dCBzdXBwbGllZCBieSB0aGUgdHJhbnNwb3J0IGxheWVyDQogICAgICAgICAg ICBwcm90b2NvbC4iDQogICAgOjo9IHsgaXB2NiAyIH0NCg0KaXB2NkluUmVj ZWl2ZXMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzIN CiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBj dXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgdG90 YWwgbnVtYmVyIG9mIGlucHV0IGRhdGFncmFtcyByZWNlaXZlZCBmcm9tDQog ICAgICAgICAgICBpbnRlcmZhY2VzLCBpbmNsdWRpbmcgdGhvc2UgcmVjZWl2 ZWQgaW4gZXJyb3IuIg0KICAgIDo6PSB7IGlwdjYgMyB9DQoNCmlwdjZJbkhk ckVycm9ycyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIz Mg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAg IGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBu dW1iZXIgb2YgaW5wdXQgZGF0YWdyYW1zIGRpc2NhcmRlZCBkdWUgdG8gZXJy b3JzIGluDQogICAgICAgICAgICB0aGVpciBJUHY2IGhlYWRlcnMsIGluY2x1 ZGluZyB2ZXJzaW9uIG51bWJlcg0KICAgICAgICAgICAgbWlzbWF0Y2gsIG90 aGVyIGZvcm1hdCBlcnJvcnMsIGhvcCBsaW1pdCBleGNlZWRlZCwgZXJyb3Jz DQogICAgICAgICAgICBkaXNjb3ZlcmVkIGluIHByb2Nlc3NpbmcgdGhlaXIg bmV4dCBoZWFkZXJzLCBldGMuIg0KICAgIDo6PSB7IGlwdjYgNCB9DQoNCmlw djZJbkFkZHJFcnJvcnMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBD b3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAg ICJUaGUgbnVtYmVyIG9mIGlucHV0IGRhdGFncmFtcyBkaXNjYXJkZWQgYmVj YXVzZSB0aGUgSVB2Ng0KICAgICAgICAgICAgYWRkcmVzcyBpbiB0aGVpciBJ UHY2IGhlYWRlcidzIGRlc3RpbmF0aW9uIGZpZWxkIHdhcyBub3QgYQ0KICAg ICAgICAgICAgdmFsaWQgYWRkcmVzcyB0byBiZSByZWNlaXZlZCBhdCB0aGlz IGVudGl0eS4gIEZvciBlbnRpdGllcw0KICAgICAgICAgICAgd2hpY2ggYXJl IG5vdCBJUHY2IHJvdXRlcnMgYW5kIHRoZXJlZm9yZSBkbyBub3QgZm9yd2Fy ZCBkYXRhZ3JhbXMsDQogICAgICAgICAgICB0aGlzIGNvdW50ZXIgaW5jbHVk ZXMgZGF0YWdyYW1zIGRpc2NhcmRlZCBiZWNhdXNlIHRoZSBkZXN0aW5hdGlv bg0KICAgICAgICAgICAgYWRkcmVzcyB3YXMgbm90IGEgbG9jYWwgYWRkcmVz cy4iDQogICAgOjo9IHsgaXB2NiA1IH0NCg0KaXB2NkZvcndEYXRhZ3JhbXMg T0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICBN QVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50 DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgbnVtYmVyIG9m IGlucHV0IGRhdGFncmFtcyBmb3Igd2hpY2ggdGhpcyBlbnRpdHkgd2FzIG5v dA0KICAgICAgICAgICAgdGhlaXIgZmluYWwgSVB2NiBkZXN0aW5hdGlvbiwg YXMgYSByZXN1bHQgb2Ygd2hpY2ggYW4gYXR0ZW1wdA0KICAgICAgICAgICAg d2FzIG1hZGUgdG8gZmluZCBhIHJvdXRlIHRvIGZvcndhcmQgdGhlbSB0byB0 aGF0IGZpbmFsDQogICAgICAgICAgICBkZXN0aW5hdGlvbi4gIEluIGVudGl0 aWVzIHdoaWNoIGRvIG5vdCBhY3QgYXMgSVB2NiByb3V0ZXJzLA0KICAgICAg ICAgICAgdGhpcyBjb3VudGVyIHdpbGwgaW5jbHVkZSBvbmx5IHRob3NlIHBh Y2tldHMgd2hpY2ggd2VyZQ0KICAgICAgICAgICAgU291cmNlLVJvdXRlZCB2 aWEgdGhpcyBlbnRpdHksIGFuZCB0aGUgU291cmNlLVJvdXRlIG9wdGlvbg0K ICAgICAgICAgICAgcHJvY2Vzc2luZyB3YXMgc3VjY2Vzc2Z1bC4iDQogICAg Ojo9IHsgaXB2NiA2IH0NCg0KaXB2NkluVW5rbm93blByb3RvcyBPQkpFQ1Qt VFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NF U1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgbG9jYWxs eS1hZGRyZXNzZWQgZGF0YWdyYW1zIHJlY2VpdmVkDQogICAgICAgICAgICBz dWNjZXNzZnVsbHkgYnV0IGRpc2NhcmRlZCBiZWNhdXNlIG9mIGFuIHVua25v d24gb3INCiAgICAgICAgICAgIHVuc3VwcG9ydGVkIHByb3RvY29sLiINCiAg ICA6Oj0geyBpcHY2IDcgfQ0KDQppcHY2SW5EaXNjYXJkcyBPQkpFQ1QtVFlQ RQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1Mg IHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVND UklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgaW5wdXQgSVB2 NiBkYXRhZ3JhbXMgZm9yIHdoaWNoIG5vIHByb2JsZW1zIHdlcmUNCiAgICAg ICAgICAgIGVuY291bnRlcmVkIHRvIHByZXZlbnQgdGhlaXIgY29udGludWVk IHByb2Nlc3NpbmcsIGJ1dCB3aGljaA0KICAgICAgICAgICAgd2VyZSBkaXNj YXJkZWQgKGUuZy4sIGZvciBsYWNrIG9mIGJ1ZmZlciBzcGFjZSkuICBOb3Rl IHRoYXQNCiAgICAgICAgICAgIHRoaXMgY291bnRlciBkb2VzIG5vdCBpbmNs dWRlIGFueSBkYXRhZ3JhbXMgZGlzY2FyZGVkIHdoaWxlDQogICAgICAgICAg ICBhd2FpdGluZyByZS1hc3NlbWJseS4iDQogICAgOjo9IHsgaXB2NiA4IH0N Cg0KaXB2NkluRGVsaXZlcnMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAg ICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICJUaGUgdG90YWwgbnVtYmVyIG9mIGlucHV0IGRhdGFncmFtcyBzdWNj ZXNzZnVsbHkgZGVsaXZlcmVkDQogICAgICAgICAgICB0byBJUHY2IHVzZXIt cHJvdG9jb2xzIChpbmNsdWRpbmcgSUNNUHY2KS4iDQogICAgOjo9IHsgaXB2 NiA5IH0NCg0KaXB2Nk91dFJlcXVlc3RzIE9CSkVDVC1UWVBFDQogICAgU1lO VEFYICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5 DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQog ICAgICAgICAgICAiVGhlIHRvdGFsIG51bWJlciBvZiBJUHY2IGRhdGFncmFt cyB3aGljaCBsb2NhbCBJUHY2IHVzZXItDQogICAgICAgICAgICBwcm90b2Nv bHMgKGluY2x1ZGluZyBJQ01QdjYpIHN1cHBsaWVkIHRvIElQdjYgaW4gcmVx dWVzdHMgZm9yDQogICAgICAgICAgICB0cmFuc21pc3Npb24uICBOb3RlIHRo YXQgdGhpcyBjb3VudGVyIGRvZXMgbm90IGluY2x1ZGUgYW55DQogICAgICAg ICAgICBkYXRhZ3JhbXMgY291bnRlZCBpbiBpcHY2Rm9yd0RhdGFncmFtcy4i DQogICAgOjo9IHsgaXB2NiAxMCB9DQoNCmlwdjZPdXREaXNjYXJkcyBPQkpF Q1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAg ICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2Ygb3V0 cHV0IElQdjYgZGF0YWdyYW1zIGZvciB3aGljaCBubyBwcm9ibGVtIHdhcw0K ICAgICAgICAgICAgZW5jb3VudGVyZWQgdG8gcHJldmVudCB0aGVpciB0cmFu c21pc3Npb24gdG8gdGhlaXINCiAgICAgICAgICAgIGRlc3RpbmF0aW9uLCBi dXQgd2hpY2ggd2VyZSBkaXNjYXJkZWQgKGUuZy4sIGZvciBsYWNrIG9mDQog ICAgICAgICAgICBidWZmZXIgc3BhY2UpLiAgTm90ZSB0aGF0IHRoaXMgY291 bnRlciB3b3VsZCBpbmNsdWRlDQogICAgICAgICAgICBkYXRhZ3JhbXMgY291 bnRlZCBpbiBpcHY2Rm9yd0RhdGFncmFtcyBpZiBhbnkgc3VjaCBwYWNrZXRz IG1ldA0KICAgICAgICAgICAgdGhpcyAoZGlzY3JldGlvbmFyeSkgZGlzY2Fy ZCBjcml0ZXJpb24uIg0KICAgIDo6PSB7IGlwdjYgMTEgfQ0KDQppcHY2T3V0 Tm9Sb3V0ZXMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVy MzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAg ICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUg bnVtYmVyIG9mIElQdjYgZGF0YWdyYW1zIGRpc2NhcmRlZCBiZWNhdXNlIG5v IHJvdXRlIGNvdWxkDQogICAgICAgICAgICBiZSBmb3VuZCB0byB0cmFuc21p dCB0aGVtIHRvIHRoZWlyIGRlc3RpbmF0aW9uLiAgTm90ZSB0aGF0DQogICAg ICAgICAgICB0aGlzIGNvdW50ZXIgaW5jbHVkZXMgYW55IHBhY2tldHMgY291 bnRlZCBpbiBpcHY2Rm9yd0RhdGFncmFtcw0KICAgICAgICAgICAgd2hpY2gg bWVldCB0aGlzIGBuby1yb3V0ZScgY3JpdGVyaW9uLiAgTm90ZSB0aGF0IHRo aXMNCiAgICAgICAgICAgIGluY2x1ZGVzIGFueSBkYXRhZ3JhbXMgd2hpY2gg YSBob3N0IGNhbm5vdCByb3V0ZSBiZWNhdXNlIGFsbA0KICAgICAgICAgICAg b2YgaXRzIGRlZmF1bHQgcm91dGVycyBhcmUgZG93bi4iDQogICAgOjo9IHsg aXB2NiAxMiB9DQoNCmlwdjZSZWFzbVRpbWVvdXQgT0JKRUNULVRZUEUNCiAg ICBTWU5UQVggICAgICBJbnRlZ2VyMzINCiAgICBNQVgtQUNDRVNTICByZWFk LW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJ T04NCiAgICAgICAgICAgICJUaGUgbWF4aW11bSBudW1iZXIgb2Ygc2Vjb25k cyB3aGljaCByZWNlaXZlZCBmcmFnbWVudHMgYXJlDQogICAgICAgICAgICBo ZWxkIHdoaWxlIHRoZXkgYXJlIGF3YWl0aW5nIHJlYXNzZW1ibHkgYXQgdGhp cyBlbnRpdHkuIg0KICAgIDo6PSB7IGlwdjYgMTMgfQ0KDQppcHY2UmVhc21S ZXFkcyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0K ICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1 cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1i ZXIgb2YgSVB2NiBmcmFnbWVudHMgcmVjZWl2ZWQgd2hpY2ggbmVlZGVkIHRv IGJlDQogICAgICAgICAgICByZWFzc2VtYmxlZCBhdCB0aGlzIGVudGl0eS4i DQogICAgOjo9IHsgaXB2NiAxNCB9DQoNCmlwdjZSZWFzbU9LcyBPQkpFQ1Qt VFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NF U1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgSVB2NiBk YXRhZ3JhbXMgc3VjY2Vzc2Z1bGx5IHJlLWFzc2VtYmxlZC4iDQogICAgOjo9 IHsgaXB2NiAxNSB9DQoNCmlwdjZSZWFzbUZhaWxzIE9CSkVDVC1UWVBFDQog ICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAgcmVh ZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBU SU9ODQogICAgICAgICAgICAiVGhlIG51bWJlciBvZiBmYWlsdXJlcyBkZXRl Y3RlZCBieSB0aGUgSVB2NiByZS1hc3NlbWJseQ0KICAgICAgICAgICAgYWxn b3JpdGhtIChmb3Igd2hhdGV2ZXIgcmVhc29uOiB0aW1lZCBvdXQsIGVycm9y cywgZXRjKS4NCiAgICAgICAgICAgIE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBu ZWNlc3NhcmlseSBhIGNvdW50IG9mIGRpc2NhcmRlZCBJUHY2DQogICAgICAg ICAgICBmcmFnbWVudHMgc2luY2Ugc29tZSBhbGdvcml0aG1zIChub3RhYmx5 IHRoZSBhbGdvcml0aG0gaW4NCiAgICAgICAgICAgIFJGQyA4MTUpIGNhbiBs b3NlIHRyYWNrIG9mIHRoZSBudW1iZXIgb2YgZnJhZ21lbnRzIGJ5DQogICAg ICAgICAgICBjb21iaW5pbmcgdGhlbSBhcyB0aGV5IGFyZSByZWNlaXZlZC4i DQogICAgOjo9IHsgaXB2NiAxNiB9DQoNCmlwdjZGcmFnT0tzIE9CSkVDVC1U WVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VT UyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIG51bWJlciBvZiBJUHY2IGRh dGFncmFtcyB0aGF0IGhhdmUgYmVlbiBzdWNjZXNzZnVsbHkNCiAgICAgICAg ICAgIGZyYWdtZW50ZWQgYXQgdGhpcyBlbnRpdHkuIg0KICAgIDo6PSB7IGlw djYgMTcgfQ0KDQppcHY2RnJhZ0ZhaWxzIE9CSkVDVC1UWVBFDQogICAgU1lO VEFYICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5 DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQog ICAgICAgICAgICAiVGhlIG51bWJlciBvZiBJUHY2IGRhdGFncmFtcyB0aGF0 IGhhdmUgYmVlbiBkaXNjYXJkZWQgYmVjYXVzZQ0KICAgICAgICAgICAgdGhl eSBuZWVkZWQgdG8gYmUgZnJhZ21lbnRlZCBhdCB0aGlzIGVudGl0eSBidXQg Y291bGQgbm90IGJlLiINCiAgICA6Oj0geyBpcHY2IDE4IH0NCg0KaXB2NkZy YWdDcmVhdGVzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRl cjMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAg ICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhl IG51bWJlciBvZiBJUHY2IGRhdGFncmFtIGZyYWdtZW50cyB0aGF0IGhhdmUg YmVlbg0KICAgICAgICAgICAgZ2VuZXJhdGVkIGFzIGEgcmVzdWx0IG9mIGZy YWdtZW50YXRpb24gYXQgdGhpcyBlbnRpdHkuIg0KICAgIDo6PSB7IGlwdjYg MTkgfQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KLS0gdGhlIElQdjYgYWRk cmVzcyB0YWJsZQ0KDQppcHY2QWRkclRhYmxlIE9CSkVDVC1UWVBFDQogICAg U1lOVEFYICAgICAgU0VRVUVOQ0UgT0YgSXB2NkFkZHJFbnRyeQ0KICAgIE1B WC1BQ0NFU1MgIG5vdC1hY2Nlc3NpYmxlDQogICAgU1RBVFVTICAgICAgY3Vy cmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIHRhYmxl IG9mIGFkZHJlc3NpbmcgaW5mb3JtYXRpb24gcmVsZXZhbnQgdG8gdGhpcw0K ICAgICAgICAgICAgZW50aXR5J3MgSVB2NiBhZGRyZXNzZXMuIg0KICAgIDo6 PSB7IGlwdjYgMjAgfQ0KDQppcHY2QWRkckVudHJ5IE9CSkVDVC1UWVBFDQog ICAgU1lOVEFYICAgICAgSXB2NkFkZHJFbnRyeQ0KICAgIE1BWC1BQ0NFU1Mg IG5vdC1hY2Nlc3NpYmxlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIGFkZHJlc3NpbmcgaW5m b3JtYXRpb24gZm9yIG9uZSBvZiB0aGlzIGVudGl0eSdzIElQdjYNCiAgICAg ICAgICAgIGFkZHJlc3Nlcy4iDQogICAgSU5ERVggICAgICB7IGlwdjZBZEVu dEFkZHIgfQ0KICAgIDo6PSB7IGlwdjZBZGRyVGFibGUgMSB9DQoNCklwdjZB ZGRyRW50cnkgOjo9IFNFUVVFTkNFIHsNCiAgICAgICAgaXB2NkFkRW50QWRk ciAgICAgICAgICBJUHY2QWRkcmVzcywNCiAgICAgICAgaXB2NkFkRW50SWZJ bmRleCAgICAgICBJTlRFR0VSLA0KICAgICAgICBpcHY2QWRFbnRQcmVmaXgg ICAgICAgIElOVEVHRVIgKDAuLjEyOCksDQogICAgICAgIGlwdjZBZEVudFJl YXNtTWF4U2l6ZSAgSU5URUdFUg0KICAgIH0NCg0KaXB2NkFkRW50QWRkciBP QkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIElQdjZBZGRyZXNzDQogICAg TUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIElQdjYgYWRk cmVzcyB0byB3aGljaCB0aGlzIGVudHJ5J3MgYWRkcmVzc2luZyBpbmZvcm1h dGlvbg0KICAgICAgICAgICAgcGVydGFpbnMuIg0KICAgIDo6PSB7IGlwdjZB ZGRyRW50cnkgMSB9DQoNCmlwdjZBZEVudElmSW5kZXggT0JKRUNULVRZUEUN CiAgICBTWU5UQVggICAgICBJTlRFR0VSICgxLi4yMTQ3NDgzNjQ3KQ0KICAg IE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJl bnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBpbmRleCB2 YWx1ZSB3aGljaCB1bmlxdWVseSBpZGVudGlmaWVzIHRoZSBpbnRlcmZhY2Ug dG8NCiAgICAgICAgICAgIHdoaWNoIHRoaXMgZW50cnkgaXMgYXBwbGljYWJs ZS4gIFRoZSBpbnRlcmZhY2UgaWRlbnRpZmllZCBieQ0KICAgICAgICAgICAg YSBwYXJ0aWN1bGFyIHZhbHVlIG9mIHRoaXMgaW5kZXggaXMgdGhlIHNhbWUg aW50ZXJmYWNlIGFzDQogICAgICAgICAgICBpZGVudGlmaWVkIGJ5IHRoZSBz YW1lIHZhbHVlIG9mIFJGQyAxNTczJ3MgaWZJbmRleC4iDQogICAgOjo9IHsg aXB2NkFkZHJFbnRyeSAyIH0NCg0KaXB2NkFkRW50UHJlZml4IE9CSkVDVC1U WVBFDQogICAgU1lOVEFYICAgICAgSU5URUdFUiAoMC4uMTI4KQ0KICAgIE1B WC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQN CiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2Yg Yml0cyBpbiB0aGUgSVB2NiBhZGRyZXNzIHRoYXQgY29uc3RpdHV0ZXMgdGhl DQogICAgICAgICAgICBuZXR3b3JrIHBhcnQgb2YgdGhlIGFkZHJlc3MiDQog ICAgOjo9IHsgaXB2NkFkZHJFbnRyeSAzIH0NCg0KaXB2NkFkRW50UmVhc21N YXhTaXplIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgSU5URUdFUiAo MC4uNjU1MzUpDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICAiVGhlIHNpemUgb2YgdGhlIGxhcmdlc3QgSVB2NiBkYXRhZ3JhbSB3aGlj aCB0aGlzIGVudGl0eSBjYW4NCiAgICAgICAgICAgIHJlLWFzc2VtYmxlIGZy b20gaW5jb21pbmcgSVB2NiBmcmFnbWVudGVkIGRhdGFncmFtcyByZWNlaXZl ZA0KICAgICAgICAgICAgb24gdGhpcyBpbnRlcmZhY2UuIg0KICAgIDo6PSB7 IGlwdjZBZGRyRW50cnkgNSB9DQoNCg0KDQoNCg0KLS0gdGhlIElQdjYgQWRk cmVzcyBUcmFuc2xhdGlvbiB0YWJsZQ0KDQotLSBUaGUgQWRkcmVzcyBUcmFu c2xhdGlvbiB0YWJsZXMgY29udGFpbiB0aGUgSVB2NkFkZHJlc3MgdG8NCi0t ICJwaHlzaWNhbCIgYWRkcmVzcyBlcXVpdmFsZW5jZXMuICBTb21lIGludGVy ZmFjZXMgZG8gbm90DQotLSB1c2UgdHJhbnNsYXRpb24gdGFibGVzIGZvciBk ZXRlcm1pbmluZyBhZGRyZXNzDQotLSBlcXVpdmFsZW5jZXMgKGUuZy4sIERE Ti1YLjI1IGhhcyBhbiBhbGdvcml0aG1pYyBtZXRob2QpOw0KLS0gaWYgYWxs IGludGVyZmFjZXMgYXJlIG9mIHRoaXMgdHlwZSwgdGhlbiB0aGUgQWRkcmVz cw0KLS0gVHJhbnNsYXRpb24gdGFibGUgaXMgZW1wdHksIGkuZS4sIGhhcyB6 ZXJvIGVudHJpZXMuDQoNCmlwdjZOZXRUb01lZGlhVGFibGUgT0JKRUNULVRZ UEUNCiAgICBTWU5UQVggICAgICBTRVFVRU5DRSBPRiBJcHY2TmV0VG9NZWRp YUVudHJ5DQogICAgTUFYLUFDQ0VTUyAgbm90LWFjY2Vzc2libGUNCiAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICJUaGUgSVB2NiBBZGRyZXNzIFRyYW5zbGF0aW9uIHRhYmxlIHVzZWQg Zm9yIG1hcHBpbmcgZnJvbSBJUHY2DQogICAgICAgICAgICBhZGRyZXNzZXMg dG8gcGh5c2ljYWwgYWRkcmVzc2VzLiINCiAgICA6Oj0geyBpcHY2IDIyIH0N Cg0KaXB2Nk5ldFRvTWVkaWFFbnRyeSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRB WCAgICAgIElwdjZOZXRUb01lZGlhRW50cnkNCiAgICBNQVgtQUNDRVNTICBu b3QtYWNjZXNzaWJsZQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBE RVNDUklQVElPTg0KICAgICAgICAgICAgIkVhY2ggZW50cnkgY29udGFpbnMg b25lIElQdjZBZGRyZXNzIHRvIGBwaHlzaWNhbCcgYWRkcmVzcw0KICAgICAg ICAgICAgZXF1aXZhbGVuY2UuIg0KICAgIElOREVYICAgICAgIHsgaXB2Nk5l dFRvTWVkaWFJZkluZGV4LA0KICAgICAgICAgICAgICAgICAgaXB2Nk5ldFRv TWVkaWFOZXRBZGRyZXNzIH0NCiAgICA6Oj0geyBpcHY2TmV0VG9NZWRpYVRh YmxlIDEgfQ0KDQpJcHY2TmV0VG9NZWRpYUVudHJ5IDo6PSBTRVFVRU5DRSB7 DQogICAgICAgIGlwdjZOZXRUb01lZGlhSWZJbmRleCAgICAgIElOVEVHRVIs DQogICAgICAgIGlwdjZOZXRUb01lZGlhUGh5c0FkZHJlc3MgIFBoeXNBZGRy ZXNzLA0KICAgICAgICBpcHY2TmV0VG9NZWRpYU5ldEFkZHJlc3MgICBJUHY2 QWRkcmVzcywNCiAgICAgICAgaXB2Nk5ldFRvTWVkaWFUeXBlICAgICAgICAg SU5URUdFUg0KICAgIH0NCg0KaXB2Nk5ldFRvTWVkaWFJZkluZGV4IE9CSkVD VC1UWVBFDQogICAgU1lOVEFYICAgICAgSU5URUdFUiAoMS4uMjE0NzQ4MzY0 NykNCiAgICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAg ICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRo ZSBpbnRlcmZhY2Ugb24gd2hpY2ggdGhpcyBlbnRyeSdzIGVxdWl2YWxlbmNl IGlzDQogICAgICAgICAgICBlZmZlY3RpdmUuICBUaGUgaW50ZXJmYWNlIGlk ZW50aWZpZWQgYnkgYSBwYXJ0aWN1bGFyIHZhbHVlDQogICAgICAgICAgICBv ZiB0aGlzIGluZGV4IGlzIHRoZSBzYW1lIGludGVyZmFjZSBhcyBpZGVudGlm aWVkIGJ5IHRoZQ0KICAgICAgICAgICAgc2FtZSB2YWx1ZSBvZiBSRkMgMTU3 MydzIGlmSW5kZXguIg0KICAgIDo6PSB7IGlwdjZOZXRUb01lZGlhRW50cnkg MSB9DQoNCmlwdjZOZXRUb01lZGlhUGh5c0FkZHJlc3MgT0JKRUNULVRZUEUN CiAgICBTWU5UQVggICAgICBQaHlzQWRkcmVzcw0KICAgIE1BWC1BQ0NFU1Mg IHJlYWQtY3JlYXRlDQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERF U0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIG1lZGlhLWRlcGVuZGVudCBg cGh5c2ljYWwnIGFkZHJlc3MuIg0KICAgIDo6PSB7IGlwdjZOZXRUb01lZGlh RW50cnkgMiB9DQoNCmlwdjZOZXRUb01lZGlhTmV0QWRkcmVzcyBPQkpFQ1Qt VFlQRQ0KICAgIFNZTlRBWCAgICAgIElQdjZBZGRyZXNzDQogICAgTUFYLUFD Q0VTUyAgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgSVB2NkFkZHJlc3Mg Y29ycmVzcG9uZGluZyB0byB0aGUgbWVkaWEtZGVwZW5kZW50DQogICAgICAg ICAgICBgcGh5c2ljYWwnIGFkZHJlc3MuIg0KICAgIDo6PSB7IGlwdjZOZXRU b01lZGlhRW50cnkgMyB9DQoNCmlwdjZOZXRUb01lZGlhVHlwZSBPQkpFQ1Qt VFlQRQ0KICAgIFNZTlRBWCAgICAgIElOVEVHRVIgew0KICAgICAgICAgICAg ICAgIG90aGVyKDEpLCAgICAgICAgLS0gbm9uZSBvZiB0aGUgZm9sbG93aW5n DQogICAgICAgICAgICAgICAgaW52YWxpZCgyKSwgICAgICAtLSBhbiBpbnZh bGlkYXRlZCBtYXBwaW5nDQogICAgICAgICAgICAgICAgZHluYW1pYygzKSwN CiAgICAgICAgICAgICAgICBzdGF0aWMoNCkNCiAgICAgICAgICAgIH0NCiAg ICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgICAgIGN1 cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSB0eXBl IG9mIG1hcHBpbmcuDQoNCiAgICAgICAgICAgIFNldHRpbmcgdGhpcyBvYmpl Y3QgdG8gdGhlIHZhbHVlIGludmFsaWQoMikgaGFzIHRoZSBlZmZlY3QNCiAg ICAgICAgICAgIG9mIGludmFsaWRhdGluZyB0aGUgY29ycmVzcG9uZGluZyBl bnRyeSBpbiB0aGUNCiAgICAgICAgICAgIGlwdjZOZXRUb01lZGlhVGFibGUu ICBUaGF0IGlzLCBpdCBlZmZlY3RpdmVseSBkaXNhc3NvY2lhdGVzDQogICAg ICAgICAgICB0aGUgaW50ZXJmYWNlIGlkZW50aWZpZWQgd2l0aCBzYWlkIGVu dHJ5IGZyb20gdGhlIG1hcHBpbmcNCiAgICAgICAgICAgIGlkZW50aWZpZWQg d2l0aCBzYWlkIGVudHJ5LiAgSXQgaXMgYW4gaW1wbGVtZW50YXRpb24tDQog ICAgICAgICAgICBzcGVjaWZpYyBtYXR0ZXIgYXMgdG8gd2hldGhlciB0aGUg YWdlbnQgcmVtb3ZlcyBhbg0KICAgICAgICAgICAgaW52YWxpZGF0ZWQgZW50 cnkgZnJvbSB0aGUgdGFibGUuICBBY2NvcmRpbmdseSwgbWFuYWdlbWVudA0K ICAgICAgICAgICAgc3RhdGlvbnMgbXVzdCBiZSBwcmVwYXJlZCB0byByZWNl aXZlIHRhYnVsYXIgaW5mb3JtYXRpb24NCiAgICAgICAgICAgIGZyb20gYWdl bnRzIHRoYXQgY29ycmVzcG9uZHMgdG8gZW50cmllcyBub3QgY3VycmVudGx5 IGluDQogICAgICAgICAgICB1c2UuICBQcm9wZXIgaW50ZXJwcmV0YXRpb24g b2Ygc3VjaCBlbnRyaWVzIHJlcXVpcmVzDQogICAgICAgICAgICBleGFtaW5h dGlvbiBvZiB0aGUgcmVsZXZhbnQgaXB2Nk5ldFRvTWVkaWFUeXBlIG9iamVj dC4iDQogICAgOjo9IHsgaXB2Nk5ldFRvTWVkaWFFbnRyeSA0IH0NCg0KaXB2 NlJvdXRpbmdEaXNjYXJkcyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAg IENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNU QVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAg ICAgIlRoZSBudW1iZXIgb2Ygcm91dGluZyBlbnRyaWVzIHdoaWNoIHdlcmUg Y2hvc2VuIHRvIGJlDQogICAgICAgICAgICBkaXNjYXJkZWQgZXZlbiB0aG91 Z2ggdGhleSBhcmUgdmFsaWQuICBPbmUgcG9zc2libGUgcmVhc29uDQogICAg ICAgICAgICBmb3IgZGlzY2FyZGluZyBzdWNoIGFuIGVudHJ5IGNvdWxkIGJl IHRvIGZyZWUtdXAgYnVmZmVyDQogICAgICAgICAgICBzcGFjZSBmb3Igb3Ro ZXIgcm91dGluZyBlbnRyaWVzLiINCiAgICA6Oj0geyBpcHY2IDIzIH0NCg0K DQoNCmlwdjZGb3J3YXJkIE9CSkVDVCBJREVOVElGSUVSIDo6PSB7IGlwdjYg MjQgfQ0KDQoNCg0KDQppcHY2Um91dGVOdW1iZXIgT0JKRUNULVRZUEUNCiAg ICBTWU5UQVggICBHYXVnZTMyDQogICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkN CiAgICBTVEFUVVMgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAiVGhlIG51bWJlciBvZiBjdXJyZW50ICBpcHY2Rm9yd2FyZFRhYmxlICBl bnRyaWVzDQogICAgICAgdGhhdCBhcmUgbm90IGludmFsaWQuIg0KICAgIDo6 PSB7IGlwdjZGb3J3YXJkIDEgfQ0KDQoNCg0KDQppcHY2Um91dGVUYWJsZSBP QkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgIFNFUVVFTkNFIE9GIElwdjZSb3V0 ZUVudHJ5DQogICAgTUFYLUFDQ0VTUyBub3QtYWNjZXNzaWJsZQ0KICAgIFNU QVRVUyAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGlz IGVudGl0eSdzIElQIFJvdXRpbmcgdGFibGUuIg0KICAgIDo6PSB7IGlwdjZG b3J3YXJkIDIgfQ0KDQppcHY2Um91dGVFbnRyeSBPQkpFQ1QtVFlQRQ0KICAg IFNZTlRBWCAgIElwdjZSb3V0ZUVudHJ5DQogICAgTUFYLUFDQ0VTUyBub3Qt YWNjZXNzaWJsZQ0KICAgIFNUQVRVUyAgIGN1cnJlbnQNCiAgICBERVNDUklQ VElPTg0KICAgICAgICJBIHBhcnRpY3VsYXIgcm91dGUgdG8gIGEgIHBhcnRp Y3VsYXIgIGRlc3RpbmF0aW9uLiINCiAgICBJTkRFWCB7DQogICAgICAgIGlw djZSb3V0ZURlc3QsDQogICAgICAgIGlwdjZSb3V0ZVByZWZpeCwNCiAgICAg ICAgaXB2NlJvdXRlTmV4dEhvcA0KICAgICAgICB9DQogICAgOjo9IHsgaXB2 NlJvdXRlVGFibGUgMSB9DQoNCklwdjZSb3V0ZUVudHJ5IDo6PQ0KICAgIFNF UVVFTkNFIHsNCiAgICAgICAgaXB2NlJvdXRlRGVzdA0KICAgICAgICAgICAg SVB2NkFkZHJlc3MsDQogICAgICAgIGlwdjZSb3V0ZVByZWZpeA0KICAgICAg ICAgICAgSU5URUdFUiAoMC4uMTI4KSwNCiAgICAgICAgaXB2NlJvdXRlTmV4 dEhvcA0KICAgICAgICAgICAgSVB2NkFkZHJlc3MsDQogICAgICAgIGlwdjZS b3V0ZUlmSW5kZXgNCiAgICAgICAgICAgIEludGVnZXIzMiwNCiAgICAgICAg aXB2NlJvdXRlVHlwZQ0KICAgICAgICAgICAgSU5URUdFUiwNCiAgICAgICAg aXB2NlJvdXRlUHJvdG8NCiAgICAgICAgICAgIElOVEVHRVIsDQogICAgICAg IGlwdjZSb3V0ZUFnZQ0KICAgICAgICAgICAgSW50ZWdlcjMyLA0KICAgICAg ICBpcHY2Um91dGVJbmZvDQogICAgICAgICAgICBPQkpFQ1QgSURFTlRJRklF UiwNCiAgICAgICAgaXB2NlJvdXRlTmV4dEhvcFJESQ0KICAgICAgICAgICAg SVB2NkFkZHJlc3MsDQogICAgICAgIGlwdjZSb3V0ZU1ldHJpYzENCiAgICAg ICAgICAgIEludGVnZXIzMiwNCiAgICAgICAgaXB2NlJvdXRlTWV0cmljMg0K ICAgICAgICAgICAgSW50ZWdlcjMyLA0KICAgICAgICBpcHY2Um91dGVNZXRy aWMzDQogICAgICAgICAgICBJbnRlZ2VyMzIsDQogICAgICAgIGlwdjZSb3V0 ZU1ldHJpYzQNCiAgICAgICAgICAgIEludGVnZXIzMiwNCiAgICAgICAgaXB2 NlJvdXRlTWV0cmljNQ0KICAgICAgICAgICAgSW50ZWdlcjMyLA0KICAgICAg ICBpcHY2Um91dGVTdGF0dXMNCiAgICAgICAgICAgIFJvd1N0YXR1cw0KICAg IH0NCg0KaXB2NlJvdXRlRGVzdCBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAg IElQdjZBZGRyZXNzDQogICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICBT VEFUVVMgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhl IGRlc3RpbmF0aW9uIElQIGFkZHJlc3Mgb2YgdGhpcyByb3V0ZS4NCg0KICAg ICAgIFRoaXMgb2JqZWN0IG1heSBub3QgdGFrZSBhIE11bHRpY2FzdCBhZGRy ZXNzIHZhbHVlLiINCiAgICA6Oj0geyBpcHY2Um91dGVFbnRyeSAxIH0NCg0K aXB2NlJvdXRlUHJlZml4IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgSU5U RUdFUiAoMC4uMTI4KQ0KICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAg U1RBVFVTICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIklu ZGljYXRlIHRoZSBudW1iZXIgb2YgYml0cyBmcm9tIHRoZQ0KICAgICAgIGRl c3RpbmF0aW9uICB0byBiZSBjb21wYXJlZCB0bw0KICAgICAgIHRoZSB2YWx1 ZSAgaW4gIHRoZSAgaXB2NlJvdXRlRGVzdCAgZmllbGQuIg0KICAgIDo6PSB7 IGlwdjZSb3V0ZUVudHJ5IDIgfQ0KDQoNCmlwdjZSb3V0ZU5leHRIb3AgT0JK RUNULVRZUEUNCiAgICBTWU5UQVggICBJUHY2QWRkcmVzcw0KICAgIE1BWC1B Q0NFU1MgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgY3VycmVudA0KICAgIERF U0NSSVBUSU9ODQogICAgICAgIk9uIHJlbW90ZSByb3V0ZXMsIHRoZSBhZGRy ZXNzIG9mIHRoZSBuZXh0IHN5cy0NCiAgICAgICB0ZW0gZW4gcm91dGU7IE90 aGVyd2lzZSwgOjouIg0KICAgIDo6PSB7IGlwdjZSb3V0ZUVudHJ5IDQgfQ0K DQppcHY2Um91dGVJZkluZGV4IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAg SW50ZWdlcjMyDQogICAgTUFYLUFDQ0VTUyByZWFkLWNyZWF0ZQ0KICAgIFNU QVRVUyAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICJUaGUg aWZJbmRleCB2YWx1ZSB3aGljaCBpZGVudGlmaWVzICB0aGUgIGxvY2FsDQog ICAgICAgaW50ZXJmYWNlICB0aHJvdWdoICB3aGljaCAgdGhlIG5leHQgaG9w IG9mIHRoaXMNCiAgICAgICByb3V0ZSBzaG91bGQgYmUgcmVhY2hlZC4iDQog ICAgREVGVkFMIHsgMCB9DQogICAgOjo9IHsgaXB2NlJvdXRlRW50cnkgNSB9 DQoNCmlwdjZSb3V0ZVR5cGUgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICBJ TlRFR0VSIHsNCiAgICAgICAgICAgICAgICBvdGhlciAgICAoMSksIC0tIG5v dCBzcGVjaWZpZWQgYnkgdGhpcyBNSUINCiAgICAgICAgICAgICAgICByZWpl Y3QgICAoMiksIC0tIHJvdXRlIHdoaWNoIGRpc2NhcmRzIHRyYWZmaWMNCiAg ICAgICAgICAgICAgICBsb2NhbCAgICAoMyksIC0tIGxvY2FsIGludGVyZmFj ZQ0KICAgICAgICAgICAgICAgIHJlbW90ZSAgICg0KSAgLS0gcmVtb3RlIGRl c3RpbmF0aW9uDQogICAgICAgICAgICAgfQ0KICAgIE1BWC1BQ0NFU1MgcmVh ZC1jcmVhdGUNCiAgICBTVEFUVVMgICBjdXJyZW50DQogICAgREVTQ1JJUFRJ T04NCiAgICAgICAiVGhlIHR5cGUgb2Ygcm91dGUuICBOb3RlIHRoYXQgbG9j YWwoMykgIHJlZmVycw0KICAgICAgIHRvICBhIHJvdXRlIGZvciB3aGljaCB0 aGUgbmV4dCBob3AgaXMgdGhlIGZpbmFsDQogICAgICAgZGVzdGluYXRpb247 IHJlbW90ZSg0KSByZWZlcnMgdG8gIGEgIHJvdXRlICBmb3INCiAgICAgICB3 aGljaCAgdGhlICBuZXh0ICBob3AgaXMgbm90IHRoZSBmaW5hbCBkZXN0aW5h LQ0KICAgICAgIHRpb24uDQoNCiAgICAgICBSb3V0ZXMgd2hpY2ggZG8gbm90 IHJlc3VsdCBpbiB0cmFmZmljIGZvcndhcmRpbmcgb3INCiAgICAgICByZWpl Y3Rpb24gc2hvdWxkIG5vdCBiZSBkaXNwbGF5ZWQgZXZlbiBpZiB0aGUNCiAg ICAgICBpbXBsZW1lbnRhdGlvbiBrZWVwcyB0aGVtIHN0b3JlZCBpbnRlcm5h bGx5Lg0KDQogICAgICAgcmVqZWN0ICgyKSByZWZlcnMgdG8gYSByb3V0ZSB3 aGljaCwgaWYgbWF0Y2hlZCwgZGlzY2FyZHMNCiAgICAgICB0aGUgbWVzc2Fn ZSBhcyB1bnJlYWNoYWJsZS4gVGhpcyBpcyB1c2VkIGluIHNvbWUNCiAgICAg ICBwcm90b2NvbHMgYXMgYSBtZWFucyBvZiBjb3JyZWN0bHkgYWdncmVnYXRp bmcgcm91dGVzLiINCiAgICA6Oj0geyBpcHY2Um91dGVFbnRyeSA2IH0NCg0K aXB2NlJvdXRlUHJvdG8gT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICBJTlRF R0VSIHsNCiAgICAgICAgICAgICAgICBvdGhlciAgICAgKDEpLCAgLS0gbm90 IHNwZWNpZmllZA0KICAgICAgICAgICAgICAgIGxvY2FsICAgICAoMiksICAt LSBsb2NhbCBpbnRlcmZhY2UNCiAgICAgICAgICAgICAgICBuZXRtZ210ICAg KDMpLCAgLS0gc3RhdGljIHJvdXRlDQogICAgICAgICAgICAgICAgaWNtcCAg ICAgICg0KSwgIC0tIHJlc3VsdCBvZiBJQ01QIFJlZGlyZWN0DQoNCiAgICAg ICAgICAgICAgICAgICAgICAgIC0tIHRoZSBmb2xsb3dpbmcgYXJlIGFsbCBk eW5hbWljDQogICAgICAgICAgICAgICAgICAgICAgICAtLSByb3V0aW5nIHBy b3RvY29scw0KICAgICAgICAgICAgICAgIGVncCAgICAgICAoNSksICAtLSBF eHRlcmlvciBHYXRld2F5IFByb3RvY29sDQogICAgICAgICAgICAgICAgZ2dw ICAgICAgICg2KSwgIC0tIEdhdGV3YXktR2F0ZXdheSBQcm90b2NvbA0KICAg ICAgICAgICAgICAgIGhlbGxvICAgICAoNyksICAtLSBGdXp6QmFsbCBIZWxs b1NwZWFrDQogICAgICAgICAgICAgICAgcmlwICAgICAgICg4KSwgIC0tIEJl cmtlbGV5IFJJUCBvciBSSVAtSUkNCiAgICAgICAgICAgICAgICBpc2lzICAg ICAoOSksICAtLSBEdWFsIElTLUlTDQogICAgICAgICAgICAgICAgZXNpcyAg ICAgKDEwKSwgLS0gSVNPIDk1NDINCiAgICAgICAgICAgICAgICBjaXNjb0ln cnAgKDExKSwgLS0gQ2lzY28gSUdSUA0KICAgICAgICAgICAgICAgIGJiblNw ZklncCAoMTIpLCAtLSBCQk4gU1BGIElHUA0KICAgICAgICAgICAgICAgIG9z cGYgICAgICAoMTMpLCAtLSBPcGVuIFNob3J0ZXN0IFBhdGggRmlyc3QNCiAg ICAgICAgICAgICAgICBiZ3AgICAgICAgKDE0KSwgLS0gQm9yZGVyIEdhdGV3 YXkgUHJvdG9jb2wNCiAgICAgICAgICAgICAgICBpZHByICAgICAgKDE1KSwg LS0gSW50ZXJEb21haW4gUG9saWN5IFJvdXRpbmcNCgkgCWlkcnAgICAgICAo MTYpICAtLSBJbnRlckRvbWFpbiBSb3V0aW5nIFByb3RvY29sDQogICAgICAg ICAgICAgfQ0KICAgIE1BWC1BQ0NFU1MgcmVhZC1vbmx5DQogICAgU1RBVFVT ICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoZSByb3V0 aW5nIG1lY2hhbmlzbSB2aWEgd2hpY2ggdGhpcyByb3V0ZSB3YXMNCiAgICAg ICBsZWFybmVkLiAgSW5jbHVzaW9uIG9mIHZhbHVlcyBmb3IgZ2F0ZXdheSBy b3V0LQ0KICAgICAgIGluZyBwcm90b2NvbHMgaXMgbm90ICBpbnRlbmRlZCAg dG8gIGltcGx5ICB0aGF0DQogICAgICAgaG9zdHMgc2hvdWxkIHN1cHBvcnQg dGhvc2UgcHJvdG9jb2xzLiINCiAgICA6Oj0geyBpcHY2Um91dGVFbnRyeSA3 IH0NCg0KaXB2NlJvdXRlQWdlIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAg SW50ZWdlcjMyDQogICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkNCiAgICBTVEFU VVMgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAiVGhlIG51 bWJlciBvZiBzZWNvbmRzICBzaW5jZSAgdGhpcyAgcm91dGUgIHdhcw0KICAg ICAgIGxhc3QgIHVwZGF0ZWQgIG9yICBvdGhlcndpc2UgIGRldGVybWluZWQg IHRvIGJlDQogICAgICAgY29ycmVjdC4gIE5vdGUgdGhhdCBubyBzZW1hbnRp Y3Mgb2YgIGB0b28gIG9sZCcNCiAgICAgICBjYW4gIGJlIGltcGxpZWQgZXhj ZXB0IHRocm91Z2gga25vd2xlZGdlIG9mIHRoZQ0KICAgICAgIHJvdXRpbmcg IHByb3RvY29sICBieSAgd2hpY2ggIHRoZSAgIHJvdXRlICAgd2FzDQogICAg ICAgbGVhcm5lZC4iDQogICAgREVGVkFMICB7IDAgfQ0KICAgIDo6PSB7IGlw djZSb3V0ZUVudHJ5IDggfQ0KDQppcHY2Um91dGVJbmZvIE9CSkVDVC1UWVBF DQogICAgU1lOVEFYICAgT0JKRUNUIElERU5USUZJRVINCiAgICBNQVgtQUND RVNTIHJlYWQtY3JlYXRlDQogICAgU1RBVFVTICAgY3VycmVudA0KICAgIERF U0NSSVBUSU9ODQogICAgICAgIkEgcmVmZXJlbmNlIHRvIE1JQiBkZWZpbml0 aW9ucyBzcGVjaWZpYyB0byB0aGUNCiAgICAgICBwYXJ0aWN1bGFyICByb3V0 aW5nIHByb3RvY29sIHdoaWNoIGlzIHJlc3BvbnNpLQ0KICAgICAgIGJsZSBm b3IgdGhpcyByb3V0ZSwgYXMgZGV0ZXJtaW5lZCBieSB0aGUgIHZhbHVlDQog ICAgICAgc3BlY2lmaWVkICBpbiB0aGUgcm91dGUncyBpcHY2Um91dGVQcm90 byB2YWx1ZS4NCiAgICAgICBJZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBw cmVzZW50LCAgaXRzICB2YWx1ZQ0KICAgICAgIHNob3VsZCBiZSBzZXQgdG8g dGhlIE9CSkVDVCBJREVOVElGSUVSIHsgMCAwIH0sDQogICAgICAgd2hpY2gg aXMgYSBzeW50YWN0aWNhbGx5IHZhbGlkIG9iamVjdCAgaWRlbnRpZi0NCiAg ICAgICBpZXIsIGFuZCBhbnkgaW1wbGVtZW50YXRpb24gY29uZm9ybWluZyB0 byBBU04uMQ0KICAgICAgIGFuZCB0aGUgQmFzaWMgRW5jb2RpbmcgUnVsZXMg bXVzdCAgYmUgIGFibGUgIHRvDQogICAgICAgZ2VuZXJhdGUgYW5kIHJlY29n bml6ZSB0aGlzIHZhbHVlLiINCiAgICA6Oj0geyBpcHY2Um91dGVFbnRyeSA5 IH0NCg0KaXB2NlJvdXRlTmV4dEhvcFJESSBPQkpFQ1QtVFlQRQ0KICAgIFNZ TlRBWCAgIElQdjZBZGRyZXNzDQogICAgTUFYLUFDQ0VTUyByZWFkLWNyZWF0 ZQ0KICAgIFNUQVRVUyAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAg ICAgICJUaGUgUm91dGluZyBEb21haW4gSWRlbnRpZmllciBvZiB0aGUgTmV4 dCAgSG9wLg0KICAgICAgIFdoZW4gIHRoaXMgIGlzICB1bmtub3duICBvciBu b3QgcmVsZXZhbnQgdG8gdGhlDQogICAgICAgcHJvdG9jb2wgaW5kaWNhdGVk IGJ5IGlwdjZSb3V0ZVByb3RvLCB6ZXJvLiINCiAgICBERUZWQUwgeyAwIH0N CiAgICA6Oj0geyBpcHY2Um91dGVFbnRyeSAxMCB9DQoNCmlwdjZSb3V0ZU1l dHJpYzEgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICBJbnRlZ2VyMzINCiAg ICBNQVgtQUNDRVNTIHJlYWQtY3JlYXRlDQogICAgU1RBVFVTICAgY3VycmVu dA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoZSBwcmltYXJ5IHJvdXRp bmcgIG1ldHJpYyAgZm9yICB0aGlzICByb3V0ZS4NCiAgICAgICBUaGUgIHNl bWFudGljcyBvZiB0aGlzIG1ldHJpYyBhcmUgZGV0ZXJtaW5lZCBieQ0KICAg ICAgIHRoZSByb3V0aW5nLXByb3RvY29sIHNwZWNpZmllZCBpbiAgdGhlICBy b3V0ZSdzDQogICAgICAgaXB2NlJvdXRlUHJvdG8gIHZhbHVlLiAgIElmICB0 aGlzIG1ldHJpYyBpcyBub3QNCiAgICAgICB1c2VkLCBpdHMgdmFsdWUgc2hv dWxkIGJlIHNldCB0byAtMS4iDQogICAgREVGVkFMIHsgLTEgfQ0KICAgIDo6 PSB7IGlwdjZSb3V0ZUVudHJ5IDExIH0NCg0KaXB2NlJvdXRlTWV0cmljMiBP QkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgIEludGVnZXIzMg0KICAgIE1BWC1B Q0NFU1MgcmVhZC1jcmVhdGUNCiAgICBTVEFUVVMgICBjdXJyZW50DQogICAg REVTQ1JJUFRJT04NCiAgICAgICAiQW4gYWx0ZXJuYXRlIHJvdXRpbmcgbWV0 cmljICBmb3IgIHRoaXMgIHJvdXRlLg0KICAgICAgIFRoZSAgc2VtYW50aWNz IG9mIHRoaXMgbWV0cmljIGFyZSBkZXRlcm1pbmVkIGJ5DQogICAgICAgdGhl IHJvdXRpbmctcHJvdG9jb2wgc3BlY2lmaWVkIGluICB0aGUgIHJvdXRlJ3MN CiAgICAgICBpcHY2Um91dGVQcm90byAgdmFsdWUuICAgSWYgIHRoaXMgbWV0 cmljIGlzIG5vdA0KICAgICAgIHVzZWQsIGl0cyB2YWx1ZSBzaG91bGQgYmUg c2V0IHRvIC0xLiINCiAgICBERUZWQUwgeyAtMSB9DQogICAgOjo9IHsgaXB2 NlJvdXRlRW50cnkgMTIgfQ0KDQppcHY2Um91dGVNZXRyaWMzIE9CSkVDVC1U WVBFDQogICAgU1lOVEFYICAgSW50ZWdlcjMyDQogICAgTUFYLUFDQ0VTUyBy ZWFkLWNyZWF0ZQ0KICAgIFNUQVRVUyAgIGN1cnJlbnQNCiAgICBERVNDUklQ VElPTg0KICAgICAgICJBbiBhbHRlcm5hdGUgcm91dGluZyBtZXRyaWMgIGZv ciAgdGhpcyAgcm91dGUuDQogICAgICAgVGhlICBzZW1hbnRpY3Mgb2YgdGhp cyBtZXRyaWMgYXJlIGRldGVybWluZWQgYnkNCiAgICAgICB0aGUgcm91dGlu Zy1wcm90b2NvbCBzcGVjaWZpZWQgaW4gIHRoZSAgcm91dGUncw0KICAgICAg IGlwdjZSb3V0ZVByb3RvICB2YWx1ZS4gICBJZiAgdGhpcyBtZXRyaWMgaXMg bm90DQogICAgICAgdXNlZCwgaXRzIHZhbHVlIHNob3VsZCBiZSBzZXQgdG8g LTEuIg0KICAgIERFRlZBTCB7IC0xIH0NCiAgICA6Oj0geyBpcHY2Um91dGVF bnRyeSAxMyB9DQoNCmlwdjZSb3V0ZU1ldHJpYzQgT0JKRUNULVRZUEUNCiAg ICBTWU5UQVggICBJbnRlZ2VyMzINCiAgICBNQVgtQUNDRVNTIHJlYWQtY3Jl YXRlDQogICAgU1RBVFVTICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQog ICAgICAgIkFuIGFsdGVybmF0ZSByb3V0aW5nIG1ldHJpYyAgZm9yICB0aGlz ICByb3V0ZS4NCiAgICAgICBUaGUgIHNlbWFudGljcyBvZiB0aGlzIG1ldHJp YyBhcmUgZGV0ZXJtaW5lZCBieQ0KICAgICAgIHRoZSByb3V0aW5nLXByb3Rv Y29sIHNwZWNpZmllZCBpbiAgdGhlICByb3V0ZSdzDQogICAgICAgaXB2NlJv dXRlUHJvdG8gIHZhbHVlLiAgIElmICB0aGlzIG1ldHJpYyBpcyBub3QNCiAg ICAgICB1c2VkLCBpdHMgdmFsdWUgc2hvdWxkIGJlIHNldCB0byAtMS4iDQog ICAgREVGVkFMIHsgLTEgfQ0KICAgIDo6PSB7IGlwdjZSb3V0ZUVudHJ5IDE0 IH0NCg0KaXB2NlJvdXRlTWV0cmljNSBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRB WCAgIEludGVnZXIzMg0KICAgIE1BWC1BQ0NFU1MgcmVhZC1jcmVhdGUNCiAg ICBTVEFUVVMgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAi QW4gYWx0ZXJuYXRlIHJvdXRpbmcgbWV0cmljICBmb3IgIHRoaXMgIHJvdXRl Lg0KICAgICAgIFRoZSAgc2VtYW50aWNzIG9mIHRoaXMgbWV0cmljIGFyZSBk ZXRlcm1pbmVkIGJ5DQogICAgICAgdGhlIHJvdXRpbmctcHJvdG9jb2wgc3Bl Y2lmaWVkIGluICB0aGUgIHJvdXRlJ3MNCiAgICAgICBpcHY2Um91dGVQcm90 byAgdmFsdWUuICAgSWYgIHRoaXMgbWV0cmljIGlzIG5vdA0KICAgICAgIHVz ZWQsIGl0cyB2YWx1ZSBzaG91bGQgYmUgc2V0IHRvIC0xLiINCiAgICBERUZW QUwgeyAtMSB9DQogICAgOjo9IHsgaXB2NlJvdXRlRW50cnkgMTUgfQ0KDQpp cHY2Um91dGVTdGF0dXMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICBSb3dT dGF0dXMNCiAgICBNQVgtQUNDRVNTIHJlYWQtY3JlYXRlDQogICAgU1RBVFVT ICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgIlRoZSByb3cg c3RhdHVzIHZhcmlhYmxlLCB1c2VkIGFjY29yZGluZyB0bw0KICAgICAgIHJv dyBpbnN0YWxsYXRpb24gYW5kIHJlbW92YWwgY29udmVudGlvbnMuIg0KICAg IDo6PSB7IGlwdjZSb3V0ZUVudHJ5IDE2IH0NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCi0tIHRoZSBJQ01QdjYgZ3JvdXANCg0KaWNtcHY2ICAg ICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyBtaWIydjYgNSB9DQoNCmljbXB2 NkluTXNncyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIz Mg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAg IGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSB0 b3RhbCBudW1iZXIgb2YgSUNNUHY2IG1lc3NhZ2VzIHdoaWNoIHRoZSBlbnRp dHkNCiAgICAgICAgICAgIHJlY2VpdmVkLiAgTm90ZSB0aGF0IHRoaXMgY291 bnRlciBpbmNsdWRlcyBhbGwgdGhvc2UgY291bnRlZA0KICAgICAgICAgICAg YnkgaWNtcHY2SW5FcnJvcnMuIg0KICAgIDo6PSB7IGljbXB2NiAxIH0NCg0K aWNtcHY2SW5FcnJvcnMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBD b3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAg ICJUaGUgbnVtYmVyIG9mIElDTVB2NiBtZXNzYWdlcyB3aGljaCB0aGUgZW50 aXR5IHJlY2VpdmVkIGJ1dA0KICAgICAgICAgICAgZGV0ZXJtaW5lZCBhcyBo YXZpbmcgSUNNUHY2LXNwZWNpZmljIGVycm9ycyAoYmFkIElDTVB2Ng0KICAg ICAgICAgICAgY2hlY2tzdW1zLCBiYWQgbGVuZ3RoLCBldGMuKS4iDQogICAg Ojo9IHsgaWNtcHY2IDIgfQ0KDQppY21wdjZJbkRlc3RVbnJlYWNocyBPQkpF Q1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAg ICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgSUNN UHY2IERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIG1lc3NhZ2VzDQogICAgICAg ICAgICByZWNlaXZlZC4iDQogICAgOjo9IHsgaWNtcHY2IDMgfQ0KDQppY21w djZJblBhY2tUb29CaWdzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAg Q291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICAiVGhlIG51bWJlciBvZiBJQ01QdjYgUGFja2V0IFRvbyBCaWcgbWVzc2Fn ZXMgcmVjZWl2ZWQuIg0KICAgIDo6PSB7IGljbXB2NiA0IH0NCg0KaWNtcHY2 SW5UaW1lRXhjZHMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3Vu dGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMg ICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJU aGUgbnVtYmVyIG9mIElDTVB2NiBUaW1lIEV4Y2VlZGVkIG1lc3NhZ2VzIHJl Y2VpdmVkLiINCiAgICA6Oj0geyBpY21wdjYgNSB9DQoNCmljbXB2NkluUGFy bVByb2JzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMy DQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAg Y3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIG51 bWJlciBvZiBJQ01QdjYgUGFyYW1ldGVyIFByb2JsZW0gbWVzc2FnZXMgcmVj ZWl2ZWQuIg0KICAgIDo6PSB7IGljbXB2NiA2IH0NCg0KaWNtcHY2SW5FY2hv cyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAg IE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJl bnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIg b2YgSUNNUHY2IEVjaG8gKHJlcXVlc3QpIG1lc3NhZ2VzIHJlY2VpdmVkLiIN CiAgICA6Oj0geyBpY21wdjYgNyB9DQoNCmljbXB2NkluRWNob1JlcHMgT0JK RUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAgICBNQVgt QUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQog ICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIElD TVB2NiBFY2hvIFJlcGx5IG1lc3NhZ2VzIHJlY2VpdmVkLiINCiAgICA6Oj0g eyBpY21wdjYgOCB9DQoNCmljbXB2NkluR3JNZW1RcyBPQkpFQ1QtVFlQRQ0K ICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJl YWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQ VElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgSUNNUHY2IEdyb3Vw IE1lbWJlcnNoaXAgUXVlcnkgbWVzc2FnZXMgcmVjZWl2ZWQuIg0KICAgIDo6 PSB7IGljbXB2NiA5IH0NCg0KaWNtcHY2SW5Hck1lbVJwcyBPQkpFQ1QtVFlQ RQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1Mg IHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVND UklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgSUNNUHY2IEdy b3VwIE1lbWJlcnNoaXAgUmVwb3J0IG1lc3NhZ2VzIHJlY2VpdmVkLiINCiAg ICA6Oj0geyBpY21wdjYgMTAgfQ0KDQppY21wdjZJbkdyTWVtUmRzIE9CSkVD VC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFD Q0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAg IERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIG51bWJlciBvZiBJQ01Q djYgR3JvdXAgTWVtYmVyc2hpcCBSZWR1Y3Rpb24gbWVzc2FnZXMgcmVjZWl2 ZWQuIg0KICAgIDo6PSB7IGljbXB2NiAxMSB9DQoNCmljbXB2NkluUm91dFNv bHMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAg ICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgbnVtYmVy IG9mIElDTVB2NiBSb3V0ZXIgU29saWNpdGF0aW9uIG1lc3NhZ2VzIHJlY2Vp dmVkLiINCiAgICA6Oj0geyBpY21wdjYgMTIgfQ0KDQppY21wdjZJblJvdXRB ZHZzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQog ICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3Vy cmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIG51bWJl ciBvZiBJQ01QdjYgUm91dGVyIEFkdmVydGlzZW1lbnQgbWVzc2FnZXMgcmVj ZWl2ZWQuIg0KICAgIDo6PSB7IGljbXB2NiAxMyB9DQoNCmljbXB2NkluTmVp Z1NvbHMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzIN CiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBj dXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgbnVt YmVyIG9mIElDTVB2NiBOZWlnaGJvciBTb2xpY2l0YXRpb24gbWVzc2FnZXMg cmVjZWl2ZWQuIg0KICAgIDo6PSB7IGljbXB2NiAxNCB9DQoNCmljbXB2Nklu TmVpZ0FkdnMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVy MzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAg ICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUg bnVtYmVyIG9mIElDTVB2NiBOZWlnaGJvciBBZHZlcnRpc2VtZW50IG1lc3Nh Z2VzIHJlY2VpdmVkLiINCiAgICA6Oj0geyBpY21wdjYgMTUgfQ0KDQppY21w djZJblJlZGlyZWN0cyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENv dW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRV UyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAgICAgICAg IlRoZSBudW1iZXIgb2YgSUNNUHY2IFJlZGlyZWN0IG1lc3NhZ2VzIHJlY2Vp dmVkLiINCiAgICA6Oj0geyBpY21wdjYgMTYgfQ0KDQppY21wdjZPdXRNc2dz IE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAg TUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVu dA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIHRvdGFsIG51 bWJlciBvZiBJQ01QdjYgbWVzc2FnZXMgd2hpY2ggdGhpcyBlbnRpdHkNCiAg ICAgICAgICAgIGF0dGVtcHRlZCB0byBzZW5kLiAgTm90ZSB0aGF0IHRoaXMg Y291bnRlciBpbmNsdWRlcyBhbGwNCiAgICAgICAgICAgIHRob3NlIGNvdW50 ZWQgYnkgaWNtcHY2T3V0RXJyb3JzLiINCiAgICA6Oj0geyBpY21wdjYgMTcg fQ0KDQppY21wdjZPdXRFcnJvcnMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVgg ICAgICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAg ICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICAgICJUaGUgbnVtYmVyIG9mIElDTVB2NiBtZXNzYWdlcyB3aGljaCB0 aGlzIGVudGl0eSBkaWQgbm90IHNlbmQNCiAgICAgICAgICAgIGR1ZSB0byBw cm9ibGVtcyBkaXNjb3ZlcmVkIHdpdGhpbiBJQ01QdjYgc3VjaCBhcyBhIGxh Y2sgb2YNCiAgICAgICAgICAgIGJ1ZmZlcnMuICBUaGlzIHZhbHVlIHNob3Vs ZCBub3QgaW5jbHVkZSBlcnJvcnMgZGlzY292ZXJlZA0KICAgICAgICAgICAg b3V0c2lkZSB0aGUgSUNNUHY2IGxheWVyIHN1Y2ggYXMgdGhlIGluYWJpbGl0 eSBvZiBJUHY2IHRvIHJvdXRlDQogICAgICAgICAgICB0aGUgcmVzdWx0YW50 IGRhdGFncmFtLiAgSW4gc29tZSBpbXBsZW1lbnRhdGlvbnMgdGhlcmUgbWF5 DQogICAgICAgICAgICBiZSBubyB0eXBlcyBvZiBlcnJvciB3aGljaCBjb250 cmlidXRlIHRvIHRoaXMgY291bnRlcidzDQogICAgICAgICAgICB2YWx1ZS4i DQogICAgOjo9IHsgaWNtcHY2IDE4IH0NCg0KaWNtcHY2T3V0RGVzdFVucmVh Y2hzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQog ICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3Vy cmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAgICAiVGhlIG51bWJl ciBvZiBJQ01QdjYgRGVzdGluYXRpb24gVW5yZWFjaGFibGUgbWVzc2FnZXMg c2VudC4iDQogICAgOjo9IHsgaWNtcHY2IDE5IH0NCg0KaWNtcHY2T3V0UGFj a1Rvb0JpZ3MgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVy MzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAg ICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUg bnVtYmVyIG9mIElDTVB2NiBQYWNrZXQgVG9vIEJpZyBtZXNzYWdlcyBzZW50 LiINCiAgICA6Oj0geyBpY21wdjYgMjAgfQ0KDQppY21wdjZPdXRUaW1lRXhj ZHMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBDb3VudGVyMzINCiAg ICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFUVVMgICAgICBjdXJy ZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAgICJUaGUgbnVtYmVy IG9mIElDTVB2NiBUaW1lIEV4Y2VlZGVkIG1lc3NhZ2VzIHNlbnQuIg0KICAg IDo6PSB7IGljbXB2NiAyMSB9DQoNCmljbXB2Nk91dFBhcm1Qcm9icyBPQkpF Q1QtVFlQRQ0KICAgIFNZTlRBWCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1B Q0NFU1MgIHJlYWQtb25seQ0KICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAg ICBERVNDUklQVElPTg0KICAgICAgICAgICAgIlRoZSBudW1iZXIgb2YgSUNN UHY2IFBhcmFtZXRlciBQcm9ibGVtIG1lc3NhZ2VzIHNlbnQuIg0KICAgIDo6 PSB7IGljbXB2NiAyMiB9DQoNCmljbXB2Nk91dEVjaG9zIE9CSkVDVC1UWVBF DQogICAgU1lOVEFYICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAg cmVhZC1vbmx5DQogICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NS SVBUSU9ODQogICAgICAgICAgICAiVGhlIG51bWJlciBvZiBJQ01QdjYgRWNo byAocmVxdWVzdCkgbWVzc2FnZXMgc2VudC4iDQogICAgOjo9IHsgaWNtcHY2 IDIzIH0NCg0KaWNtcHY2T3V0RWNob1JlcHMgT0JKRUNULVRZUEUNCiAgICBT WU5UQVggICAgICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9u bHkNCiAgICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04N CiAgICAgICAgICAgICJUaGUgbnVtYmVyIG9mIElDTVB2NiBFY2hvIFJlcGx5 IG1lc3NhZ2VzIHNlbnQuIg0KICAgIDo6PSB7IGljbXB2NiAyNCB9DQoNCmlj bXB2Nk91dEdyTWVtUXMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAgICBD b3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBTVEFU VVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAgICAg ICJUaGUgbnVtYmVyIG9mIElDTVB2NiBHcm91cCBNZW1iZXJzaGlwIFF1ZXJ5 IG1lc3NhZ2VzIHNlbnQuIg0KICAgIDo6PSB7IGljbXB2NiAyNSB9DQoNCmlj bXB2Nk91dEdyTWVtUnBzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFYICAgICAg Q291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQogICAgU1RB VFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAgICAgICAg ICAiVGhlIG51bWJlciBvZiBJQ01QdjYgR3JvdXAgTWVtYmVyc2hpcCBSZXBv cnQgbWVzc2FnZXMgc2VudC4iDQogICAgOjo9IHsgaWNtcHY2IDI2IH0NCg0K aWNtcHY2T3V0R3JNZW1SZHMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVggICAg ICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAgICBT VEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAgICAg ICAgICJUaGUgbnVtYmVyIG9mIElDTVB2NiBHcm91cCBNZW1iZXJzaGlwIFJl ZHVjdGlvbiBtZXNzYWdlcyBzZW50LiINCiAgICA6Oj0geyBpY21wdjYgMjcg fQ0KDQppY21wdjZPdXRSb3V0U29scyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRB WCAgICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0K ICAgIFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAg ICAgICAgICAgIlRoZSBudW1iZXIgb2YgSUNNUHY2IFJvdXRlciBTb2xpY2l0 YXRpb24gbWVzc2FnZXMgc2VudC4iDQogICAgOjo9IHsgaWNtcHY2IDI4IH0N Cg0KaWNtcHY2T3V0Um91dEFkdnMgT0JKRUNULVRZUEUNCiAgICBTWU5UQVgg ICAgICBDb3VudGVyMzINCiAgICBNQVgtQUNDRVNTICByZWFkLW9ubHkNCiAg ICBTVEFUVVMgICAgICBjdXJyZW50DQogICAgREVTQ1JJUFRJT04NCiAgICAg ICAgICAgICJUaGUgbnVtYmVyIG9mIElDTVB2NiBSb3V0ZXIgQWR2ZXJ0aXNl bWVudCBtZXNzYWdlcyBzZW50LiINCiAgICA6Oj0geyBpY21wdjYgMjkgfQ0K DQppY21wdjZPdXROZWlnU29scyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAg ICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAg IFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgIlRoZSBudW1iZXIgb2YgSUNNUHY2IE5laWdoYm9yIFNvbGljaXRh dGlvbiBtZXNzYWdlcyBzZW50LiINCiAgICA6Oj0geyBpY21wdjYgMzAgfQ0K DQppY21wdjZPdXROZWlnQWR2cyBPQkpFQ1QtVFlQRQ0KICAgIFNZTlRBWCAg ICAgIENvdW50ZXIzMg0KICAgIE1BWC1BQ0NFU1MgIHJlYWQtb25seQ0KICAg IFNUQVRVUyAgICAgIGN1cnJlbnQNCiAgICBERVNDUklQVElPTg0KICAgICAg ICAgICAgIlRoZSBudW1iZXIgb2YgSUNNUHY2IE5laWdoYm9yIEFkdmVydGlz ZW1lbnQgbWVzc2FnZXMgc2VudC4iDQogICAgOjo9IHsgaWNtcHY2IDMxIH0N Cg0KaWNtcHY2T3V0UmVkaXJlY3RzIE9CSkVDVC1UWVBFDQogICAgU1lOVEFY ICAgICAgQ291bnRlcjMyDQogICAgTUFYLUFDQ0VTUyAgcmVhZC1vbmx5DQog ICAgU1RBVFVTICAgICAgY3VycmVudA0KICAgIERFU0NSSVBUSU9ODQogICAg ICAgICAgICAiVGhlIG51bWJlciBvZiBJQ01QdjYgUmVkaXJlY3QgbWVzc2Fn ZXMgc2VudC4gIEZvciBhIGhvc3QsDQogICAgICAgICAgICB0aGlzIG9iamVj dCB3aWxsIGFsd2F5cyBiZSB6ZXJvLCBzaW5jZSBob3N0cyBkbyBub3Qgc2Vu ZA0KICAgICAgICAgICAgcmVkaXJlY3RzLiINCiAgICA6Oj0geyBpY21wdjYg MzIgfQ0KDQoNCkVORA0K ---559023410-1804928587-845320512=:29098-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 13:52:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09863; Mon, 14 Oct 96 13:52:40 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09857; Mon, 14 Oct 96 13:52:26 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA03215; Mon, 14 Oct 1996 13:45:52 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA14237 for ; Mon, 14 Oct 1996 13:44:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA14237; Mon, 14 Oct 1996 13:44:53 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15386(8)>; Mon, 14 Oct 1996 13:44:00 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 14 Oct 1996 13:43:30 PDT To: Juha Heinanen Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com Subject: (IPng 2325) Re: use of IPv6 Flow Label for tag switching In-Reply-To: jh's message of Sat, 12 Oct 96 00:21:34 -0800. <199610120721.KAA02650@lohi.dat.tele.fi> Date: Mon, 14 Oct 1996 13:43:29 PDT From: Steve Deering Message-Id: <96Oct14.134330pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Juha, > i will apologize when steve starts to send messages to this list that > contribute to *solving* the problems related to runing ip over various > layer 2 cloud technologies. OK, here's a solution. To run IP over a connection-oriented layer-2 cloud, adminstratively establish layer-2 connections among pairs of IP nodes, and have the IP nodes treat those connections as point-to-point links. This is a proven solution -- it is the way IP has been run successfully over POTS, X.25, and ISDN, and it is probably the most common way IP is currently run over Frame Relay and ATM (I'm sure someone will correct me if am mistaken). Treating layer-2 clouds as configurable point-to-point links rather than multiaccess subnetworks avoids the need for ARP servers, MARS servers, LISes, NHRP, flow recognition/tagging, layer-2 signalling (when using leased lines/PVCs), and heuristics-driven, often tarriff- sensitive connection establishment and teardown. It avoids the problems of VC thrashing, ARP/MARS servers being single points of failure or being made even more complicated with redundancy and failure-recovery protocols, scaling limits on the number of neighbors for an IP router, layer-2 muxing defeating IP QoS guarantees (as long as the L2 connections are CBR or similar), and unexpected long-distance charges. If you insist on making the problem harder than it has to be, I hope you'll excuse me for deciding not to spend my own time working on it. > advocating that these technologies should not be used at all is not a > solution, because there is a real world out there. There already exists a workable solution. The question is: should we continue to make the system more and more complicated to try to "exploit" every clever new feature of every random new layer-2 technology that the "real world" throws at us, or should we spend our time trying to find ways to improve the "real world" by eliminating unnecessary redundancy and generally fighting entropy? I choose to spend my effort on the latter, because I believe that's what's necessary to prevent it all eventually collapsing into an unworkable, unmanageable heap. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 14:20:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09957; Mon, 14 Oct 96 14:20:08 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA09951; Mon, 14 Oct 96 14:19:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA10276; Mon, 14 Oct 1996 14:12:51 -0700 Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA23160 for ; Mon, 14 Oct 1996 14:12:29 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA23160; Mon, 14 Oct 1996 14:12:29 -0700 Received: (from jh@localhost) by lohi.dat.tele.fi (8.7.6/8.7.3) id AAA17249; Tue, 15 Oct 1996 00:11:31 +0300 Date: Tue, 15 Oct 1996 00:11:31 +0300 Message-Id: <199610142111.AAA17249@lohi.dat.tele.fi> From: Juha Heinanen To: deering@parc.xerox.com Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com In-Reply-To: <96Oct14.134330pdt."75270"@digit.parc.xerox.com> (deering@parc.xerox.com) Subject: (IPng 2326) Re: use of IPv6 Flow Label for tag switching Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk steve, i almost agree with the solution you proosed. in fact, we have rejected the use of all kinds of servers long time ago in our ip-over-atm implementation. how about if we also allow the use of p-to-mp layer 2 vcs to map them to source specific ip multicast trees at least in cases where the number of routers connected to the layer-2 cloud is not too large? if we can also agree on this, then it seems that we are done. -- juha ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 15:48:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10094; Mon, 14 Oct 96 15:48:33 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10088; Mon, 14 Oct 96 15:48:19 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA02312; Mon, 14 Oct 1996 15:41:24 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA19547 for ; Mon, 14 Oct 1996 15:40:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA19547; Mon, 14 Oct 1996 15:40:49 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14646(1)>; Mon, 14 Oct 1996 15:40:45 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 14 Oct 1996 15:40:31 PDT To: Juha Heinanen Cc: ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com Subject: (IPng 2327) Re: use of IPv6 Flow Label for tag switching In-Reply-To: jh's message of Mon, 14 Oct 96 14:11:31 -0800. <199610142111.AAA17249@lohi.dat.tele.fi> Date: Mon, 14 Oct 1996 15:40:31 PDT From: Steve Deering Message-Id: <96Oct14.154031pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > i almost agree with the solution you proosed. in fact, we have rejected > the use of all kinds of servers long time ago in our ip-over-atm > implementation. how about if we also allow the use of p-to-mp layer 2 > vcs to map them to source specific ip multicast trees at least in cases > where the number of routers connected to the layer-2 cloud is not too > large? if we can also agree on this, then it seems that we are done. Let me make sure I understand. One approach that has been used is to, at each router attached to the cloud, configure a p-to-mp VC that terminates at every other router in the cloud. All multicast packets are forwarded over those p-to-mp VCs. For small clouds, as you said, this approach works fine with negligible added complexity. If that's what you meant, sure I agree with that. Now, do I get my apology? :-) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 15:59:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10128; Mon, 14 Oct 96 15:59:22 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10122; Mon, 14 Oct 96 15:58:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA04940; Mon, 14 Oct 1996 15:51:25 -0700 Received: from ns.att.com (ns.research.att.com [192.20.225.4]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA22255 for ; Mon, 14 Oct 1996 15:51:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA22255; Mon, 14 Oct 1996 15:51:03 -0700 Received: from research.att.com by ns; Mon Oct 14 18:50:03 EDT 1996 Received: from raptor.research.att.com by research; Mon Oct 14 18:47:49 EDT 1996 Received: from research.att.com (raptor.research.att.com [135.205.49.32]) by raptor.research.att.com (8.7.5/8.7) with ESMTP id SAA18720; Mon, 14 Oct 1996 18:47:48 -0400 (EDT) Message-Id: <199610142247.SAA18720@raptor.research.att.com> To: Fred Baker Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2328) Re: use of IPv6 Flow Label for tag switching Date: Mon, 14 Oct 1996 18:47:48 -0400 From: Steven Bellovin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven Bellovin wrote: > A much better idea. How do you prevent J. Random Luser from setting > that special bit from his/her hacked Linux box -- you know, the one > that's also emitting the phony IP addresses on the SYN packets... the same way you keep him from using the special flow label. Flow labels require setup at the router, right? That process can be authenticated. Having a magic bit set can't be. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 19:34:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10417; Mon, 14 Oct 96 19:34:57 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10411; Mon, 14 Oct 96 19:34:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA15247; Mon, 14 Oct 1996 19:28:17 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA09429 for ; Mon, 14 Oct 1996 19:28:12 -0700 From: Masataka Ohta Message-Id: <199610150227.LAA06668@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA06668; Tue, 15 Oct 1996 11:27:02 +0900 Subject: (IPng 2329) Re: use of IPv6 Flow Label for tag switching To: deering@parc.xerox.com (Steve Deering) Date: Tue, 15 Oct 96 11:27:01 JST Cc: jh@lohi.dat.tele.fi, ipng@sunroof.eng.sun.com, tagswitch@cisco.com, deering@parc.xerox.com In-Reply-To: <96Oct14.134330pdt."75270"@digit.parc.xerox.com>; from "Steve Deering" at Oct 14, 96 1:43 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; The entire idea of layer 2 forwarding has nothing to do with IPv6. draft-baker-flow-label-00.txt is nothing in mixed IPv4 IPv6 environment and is just an evidence that no one, not even Yakov himself, seriously care tag switching. Let's ignore it. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 14 21:48:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10560; Mon, 14 Oct 96 21:48:12 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10554; Mon, 14 Oct 96 21:47:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA25521; Mon, 14 Oct 1996 21:41:30 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAA29286 for ; Mon, 14 Oct 1996 21:41:21 -0700 From: Masataka Ohta Message-Id: <199610150440.NAA06980@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA06980; Tue, 15 Oct 1996 13:39:49 +0859 Subject: (IPng 2330) Re: IPv6 Other Work in Progress and Needed. To: hostmaster@munnari.OZ.AU (Robert Elz) Date: Tue, 15 Oct 96 13:39:48 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <4262.845293704@munnari.OZ.AU>; from "Robert Elz" at Oct 14, 96 9:48 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre; > How can you think, then, 16 bytes are enough? > > Because with 16 bytes, I know that there will be 8 available for > routing external to our organisation, not just 6. If I say IPv6 is no good and CLNP is the way to go becasue I know that there will be 12 available for routing external to our organisation, not just 8, what can you do? Let's simply ignore a unfounded opinion. > And, as I have shown, we still have a spare byte in addition to > the safety factor of 100 even with a fixed hierarchy. > > I thought I managed to consume that spare byte out of your hierarchy. Yes, as long as you insist on the fixed hierarchy, which you don't have to, if you can renumber. > Sure. With variable length hierarchy, we can save even more. > > Yes, but that wasn't what I was getting at, with the current schemes > I just get one more organisation number, which effectively just > consumes one bit (I would have 2 64 bit spaces, the equiv of a 65 > bit space, ignoring whether they are numbered so that they could be > treated that way). What? Why do you think a provider can't assign two 16 bit block to a large organization? The provider can even make the number contiguous and allow the organization use variable length hierarchy. Or, if you really hate renumbering and variable length hierarchy, it is possible to develop a routing protocol which can mix subnets of two or more prefixes. Or, do you think even the smallest organizations will need 17bit internally? > That is, we're likely > to have > 30000 nets to route internally. That's fine. The number, 10^12, assumes that an organization with 300 people may need 30000 nets. > Kre, a mere statement that "didn't believe that 128 bits was enough" > does not constitute an argument. > > No, it doesn't, or perhaps shouldn't. OK. Let' me show a paradox. Suppose IETF think that X bit is OK for IETF with some safety factor. Then, some organization which is expected to hold the 10% of X bit space will think that they need X bit by themselves only because their estimation is like that of IETF but with 10 times more safety factor, which is precisely what you have done. Don't assume we may need 2 times more even though there already is the safety factor of 100. > However, the IETF works by > consensus. Based on technical discussion, yes, which is why any counter argument is welcome, as long as it is argument. > To have it accepted you need > to do the work of showing that it is enough. And that's what I have done and am doing. > > but doesn't explain how that > > would be done for the unstructured IID. > > Why, do you think, such a thing could be possible? > > I don't necessarily, but I would think that needs to be expressly > stated, even more than you did. In the next revision, maybe. But, adding explanation on one thing makes the document fat and other things will be more obscure. That you have missed so many explicitely written points, the draft should already be a little too fat. > Isn't it obvious that an IPv4 multicast address is already location > independent and just an ID? > > Yes, but but (effectively) 24 bit IPv4 multicast addresses, and new > 64 (effectively 62 or something) new ones aren't going to have a 1::1 > mapping between them. IID is not for IPv4. Can't you use IPv4 compatible addresses for the operation with IPv4 hosts. > nb: this is not a routing question, but an > assignment question, are some addresses to be reserved for local > scopes, if so, which, etc. It's a locator issue. It is already written that: Provider ID of 0 is reserved for subscriber local routing. > > Nothing is said about when an IID should be assigned, when, > > if ever, one should be changed, what is possible if no IID exists, > > etc. That is, we need a really complete specification. > > In the draft, there already exists a complete specification: > > No, that's different. What you have explained is how I can get > one when I decide I want it. The question I asked is when I should > decide I want it. "when I should decide I want it?"??? IETF shouldn't restrict one's free will. You can decide you want it anytime you want. > That relates to for what purposes I can use an > auto-assigned type (not IANA rooted assignment), etc. What? If IID is locally rooted, it will not be unique and is not IID. Automatic assignment of IID, of course, use part of the IANA rooted block. That's no different from using IANA-rooted IPv4 space for DHCP. > Then there > is the reassignment. I would have expected a *ID to remain for as > long as the host (or role, or whatever) exists, it should never need > a new one, yet your draft seemed to imply that an IID could be > changed. Why would anyone want to do that? Can you find the following section of the draft? IID is a globally unique ID of a host or a multicast group to identify the host or the multicast group. While an IID uniquely identifies a single host, a host may have multiple IIDs. But, within a lifetime of some connection or reservation such as for TCP or flow, the same IID should be used regardless of the routing changes. And, "Why would anyone want to do that?"? When one leaves a section of a company, one won't want to continue to use the part of the IID space controlled by his former section, through which the section can distribute a forged public key for hierarchical inquirey. > Note - that is a question to which an answer is needed in the draft, > not here. And there already is: IID is supplied by subscribers. The configuration may be automatic. But it is expected that renumbering is necessary not so often, in general, only when a host is purchased or the host is moved to different suborganization of the provider. Host specific information such as IP address to host name mapping is looked up only through IID. > But, to criticise my proposal, please, please, don't forget > that renumbering could be made easy. > > I won't forget. But you please remember that easy renumbering solves > routing table scaling problems, renumbering doesn't in any way reduce > the number of numbers consumed. The number of numbers consumed for routing is merely 10^12. If you could assume complete compactifiaction, 40 bits were enough. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 15 08:31:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11025; Tue, 15 Oct 96 08:31:53 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11015; Tue, 15 Oct 96 08:31:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA09227; Tue, 15 Oct 1996 08:25:10 -0700 Received: from lobster.wellfleet.com (lobster.corpeast.baynetworks.com [192.32.253.3]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA11121 for ; Tue, 15 Oct 1996 08:25:00 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id LAA08536; Tue, 15 Oct 1996 11:28:20 -0400 Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id LAA28154; Tue, 15 Oct 1996 11:23:01 -0400 Date: Tue, 15 Oct 1996 11:23:01 -0400 From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <199610151523.LAA28154@pobox.BayNetworks.com> To: ipng@sunroof.eng.sun.com, ip6mib@research.ftp.com Subject: (IPng 2331) FYI: I-D ACTION:draft-haskin-onishi-ipv6-mib-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Begin Included Message ----- >From ietf-announce-request@ietf.org Tue Oct 15 11:13 EDT 1996 Mime-Version: 1.0 To: IETF-Announce:;@ietf.org Sender: ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-haskin-onishi-ipv6-mib-00.txt Date: Tue, 15 Oct 1996 09:33:55 -0400 X-Orig-Sender: scoya@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Content-Length: 2643 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Management Information Base for IP Version 6 Author(s) : D. Haskin, S. Onishi Filename : draft-haskin-onishi-ipv6-mib-00.txt Pages : 75 Date : 10/10/1996 This paper is intended to serve as a framework for definition of IPv6 MIB objects. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. 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-haskin-onishi-ipv6-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-haskin-onishi-ipv6-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-haskin-onishi-ipv6-mib-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961015092900.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-haskin-onishi-ipv6-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-haskin-onishi-ipv6-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961015092900.I-D@ietf.org> --OtherAccess-- --NextPart-- ----- End Included Message ----- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 15 09:51:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11080; Tue, 15 Oct 96 09:51:40 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11074; Tue, 15 Oct 96 09:51:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26510; Tue, 15 Oct 1996 09:44:54 -0700 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA12834 for ; Tue, 15 Oct 1996 09:44:51 -0700 Received: from fred-ss20.cisco.com (fred-ss20.cisco.com [171.69.58.89]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with ESMTP id JAA16833; Tue, 15 Oct 1996 09:44:50 -0700 (PDT) Received: from fred-ss20 (localhost.cisco.com [127.0.0.1]) by fred-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id JAA02933; Tue, 15 Oct 1996 09:44:49 -0700 Message-Id: <3263BF81.20431CA7@cisco.com> Date: Tue, 15 Oct 1996 09:44:49 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 3.0GoldC-CISCOENG (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: Steven Bellovin Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2332) Re: use of IPv6 Flow Label for tag switching References: <199610142247.SAA18720@raptor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steven Bellovin wrote: > Flow labels require setup at the router, right? That process can be > authenticated. Having a magic bit set can't be. Tags also require setup at the router. That process can equally be authenticated. If you point is that scribbling some number of bits (in your case, 1) into a message is unauthenticatable, then I counter that scribbling some number of bits (in my case, 24) is equally unauthenticatable. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 15 10:42:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11151; Tue, 15 Oct 96 10:42:35 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10956; Tue, 15 Oct 96 07:11:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA27907; Tue, 15 Oct 1996 07:04:59 -0700 Received: from nic.ott.hookup.net (nic.ott.hookup.net [165.154.100.26]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA14893 for ; Tue, 15 Oct 1996 07:04:45 -0700 Received: from [165.154.16.159] (kgk.ott.hookup.net [165.154.16.159]) by nic.ott.hookup.net (8.8.0/1.207) with SMTP id KAA19130 for ; Tue, 15 Oct 1996 10:04:38 -0400 (EDT) Date: Tue, 15 Oct 1996 10:04:38 -0400 (EDT) X-Sender: kgk@ott.hookup.net (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: kgk@ott.hookup.net (Keith G Knightson) Subject: (IPng 2333) Re: IPv6 Other Work in Progress and Needed. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema wrote: >Steve, > >Why exactly should the key relate to the addresses ? What about using the >security association idea as a unique thingie in the receiving entity, >meaning that the packet came from whoever established the association in >the first place ? > >-- >Christian Huitema This is also what I was also getting at earlier. Such a case would then cover the entity that moved but, for some reason, was perhaps unable to use an address related "id" for verification. If the "sameness" can be determined from address-related information in a foolproof way, then fine. However, it might be safer not to make any assumptions solely on the basis of the address, but rather on the basis that one is still talking to the exactly same entity one was talking to before. Cheers Keith >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 16 06:53:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12222; Wed, 16 Oct 96 06:53:36 PDT Date: Wed, 16 Oct 96 06:53:36 PDT From: owner-ipng Message-Id: <9610161353.AA12222@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Wed Oct 16 07:47:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12339; Wed, 16 Oct 96 07:47:06 PDT Date: Wed, 16 Oct 96 07:47:06 PDT From: owner-ipng Message-Id: <9610161447.AA12339@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Wed Oct 16 07:47:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12346; Wed, 16 Oct 96 07:47:16 PDT Date: Wed, 16 Oct 96 07:47:16 PDT From: owner-ipng Message-Id: <9610161447.AA12346@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Wed Oct 16 08:30:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12429; Wed, 16 Oct 96 08:30:02 PDT Date: Wed, 16 Oct 96 08:30:02 PDT From: owner-ipng Message-Id: <9610161530.AA12429@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Wed Oct 16 08:30:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12441; Wed, 16 Oct 96 08:30:42 PDT Date: Wed, 16 Oct 96 08:30:42 PDT From: owner-ipng Message-Id: <9610161530.AA12441@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Wed Oct 16 08:49:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12469; Wed, 16 Oct 96 08:49:16 PDT Date: Wed, 16 Oct 96 08:49:16 PDT From: owner-ipng Message-Id: <9610161549.AA12469@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Wed Oct 16 09:16:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12536; Wed, 16 Oct 96 09:16:06 PDT Date: Wed, 16 Oct 96 09:16:06 PDT From: owner-ipng Message-Id: <9610161616.AA12536@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Wed Oct 16 10:13:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00265; Wed, 16 Oct 96 10:13:59 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00235; Wed, 16 Oct 96 10:03:59 PDT Received: from fstop. by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00545; Wed, 16 Oct 1996 09:57:34 -0700 Received: from fstop by fstop. (SMI-8.6/SMI-SVR4) id JAA08424; Wed, 16 Oct 1996 09:57:38 -0700 Message-Id: <199610161657.JAA08424@fstop.> From: sparker@eng.sun.com To: ipng@sunroof Subject: (IPng 2334) List hiccup, corrected... Date: Wed, 16 Oct 1996 09:57:38 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng mailing list server ran out of disk space last night, resulting in several empty messages being forwarded. The problem has been corrected, however if you did not receive back a copy of a message you recently sent to the list, please resend it. Sorry for the inconvenience, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 07:37:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01414; Thu, 17 Oct 96 07:37:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01408; Thu, 17 Oct 96 07:37:00 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA12044; Thu, 17 Oct 1996 07:30:35 -0700 Received: from stern.pacific.net.sg (stern.pacific.net.sg [203.120.88.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA24300 for ; Thu, 17 Oct 1996 07:30:33 -0700 Received: from LOCALNAME (max85ppp190.pacific.net.sg [203.120.85.190]) by stern.pacific.net.sg (8.7.6/8.7.3) with SMTP id WAA11599 for ; Thu, 17 Oct 1996 22:29:54 +0800 (SGT) Date: Thu, 17 Oct 1996 22:29:54 +0800 (SGT) Message-Id: <199610171429.WAA11599@stern.pacific.net.sg> X-Sender: ckwee@po.pacific.net.sg X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: Wee Chee Keong Subject: (IPng 2335) how does IPng differs from IPv4? Please help Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greetings everyone, I am new to this IPv6 and I am VERY keen on it. I would like to know the difference between the IPv4 and IPv6 and what kinds of implications it will have on all the systems? I will appreciate it very much if anyone can point me out to any web site which has these info. Thanks and regards, Wee Chee Keong ckwee@pacific.net.sg ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 08:27:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01501; Thu, 17 Oct 96 08:27:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01495; Thu, 17 Oct 96 08:27:11 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22262; Thu, 17 Oct 1996 08:19:47 -0700 Received: from mailhub.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA21155 for ; Thu, 17 Oct 1996 08:18:57 -0700 Received: from gideon.bt.co.uk (actually gideon.bt-sys.bt.co.uk) by mailhub.axion.bt.co.uk with SMTP (PP); Thu, 17 Oct 1996 16:14:51 +0100 Received: from localhost by gideon.bt.co.uk (5.x/SMI-SVR4) id AA02800; Thu, 17 Oct 1996 15:10:28 GMT Date: Thu, 17 Oct 1996 15:10:28 +0000 (GMT) From: George Tsirtsis To: Wee Chee Keong Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2336) Re: how does IPng differs from IPv4? Please help In-Reply-To: <199610171429.WAA11599@stern.pacific.net.sg> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 17 Oct 1996, Wee Chee Keong wrote: > Greetings everyone, > > I am new to this IPv6 and I am VERY keen on it. I would like to know the > difference between the IPv4 and IPv6 and what kinds of implications it will > have on all the systems? I will appreciate it very much if anyone can point > me out to any web site which has these info. > > Thanks and regards, > > Wee Chee Keong > ckwee@pacific.net.sg > The home page of IPng is at: http://playground.Sun.COM:80/ipng/ In this page you can find a very nice paper named 'IPng Overview' I am new in the subject as well and I found this document very good and easy to read. If you have any views on that I would like to here them from since the rest of the group is very advance and sometimes difficult to follow. It won't be long though .... George Tsirtsis -------------------------------------------------------------------------- Network Research Tel : 0044-1473-640756 BT Labs Fax : 0044-1473-640709 Ipswich e-mail: george@gideon.bt.co.uk -------------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 08:32:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01513; Thu, 17 Oct 96 08:32:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01507; Thu, 17 Oct 96 08:32:26 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA23152; Thu, 17 Oct 1996 08:24:18 -0700 Received: from farofa.cs.pitt.edu (farofa.cs.pitt.edu [136.142.79.46]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA22219 for ; Thu, 17 Oct 1996 08:22:21 -0700 Received: (from komandur@localhost) by farofa.cs.pitt.edu (8.7.5/8.7.3) id LAA06843 for ipng@sunroof.eng.sun.com; Thu, 17 Oct 1996 11:21:04 -0400 Date: Thu, 17 Oct 1996 11:21:04 -0400 From: Sridhar Komandur Message-Id: <199610171521.LAA06843@farofa.cs.pitt.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 2337) qos question ... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am interested in knowing what kind of support does IPV6 have for - QoS - QoS routing Can someone point me to appropriate documents. ( I am new to this list, and would appreciate pointers to the FAQ) Thanks, Regards, Sridhar Komandur komandur@cs.pitt.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 09:03:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01567; Thu, 17 Oct 96 09:03:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01561; Thu, 17 Oct 96 09:02:50 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA00597; Thu, 17 Oct 1996 08:55:37 -0700 Received: from lobster.wellfleet.com (lobster.corpeast.baynetworks.com [192.32.253.3]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA01175 for ; Thu, 17 Oct 1996 08:55:12 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id LAA29311; Thu, 17 Oct 1996 11:55:29 -0400 Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id LAA18382; Thu, 17 Oct 1996 11:51:48 -0400 Date: Thu, 17 Oct 1996 11:51:48 -0400 From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <199610171551.LAA18382@pobox.BayNetworks.com> To: crawdad@FNAL.GOV Subject: (IPng 2338) Re: [IPv6Imp] Re: Q re: Router Advert/Prefix option Cc: ipv6imp@munnari.OZ.AU, solensky@ftp.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [ I added the ipng list since I think it is not just an implementation issue.] Matt, > > Frank: > > > ... Stateless Address Configuration [says] that I should be ignoring > > > prefixes that are announced where the length is not 80 bits. > > > > > > ..., should the text be > > > changed so that "the sum of the prefix length and interface token length > > > is greater than 128 bits, the Prefix Information Option MUST be ignored"? > Dimitry: > > IMO, the text should be changed the way you're suggesting. Prefix lengths > > don't have to be limited to a specific sizes. This is an administrative > > choice and it doesn't break autoconfiguration. > > I still disagree. If you allow |prefix| + |token| < 128, the node > has to fill in the missing bits in some way. You may as well let the > router advertise the prefix with those bits already defined. > > Remember, you can always have prefixes of other lengths used with > some other ("stately") autoconfiguration scheme. > > Matt But why should we force upon one to use a stateful configuration when a stateless autoconfiguration still can be used? In addition to address autoconfiguration, the prefix information in RA enables hosts to learn the range of on-link addresses. If a link was assigned a prefix that is shorter than 128 - , I don't see any reason for lying in RA and reducing the on-link address range from what was administratively provisioned. I can see situations when hosts would like to use the available bits between prefix and token to form multiple addresses on the same physical interface and still take advantage of stateless autoconfiguration. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 10:05:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01645; Thu, 17 Oct 96 10:05:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01350; Thu, 17 Oct 96 06:45:33 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01740; Thu, 17 Oct 1996 06:39:08 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA10405 for ; Thu, 17 Oct 1996 06:39:05 -0700 Received: from localhost by ietf.org id aa28746; 17 Oct 96 9:29 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2339) I-D ACTION:draft-ietf-ipngwg-multicast-assgn-00.txt Date: Thu, 17 Oct 1996 09:29:28 -0400 Message-Id: <9610170929.aa28746@ietf.org> 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 Multicast Address Assignments Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-multicast-assgn-00.txt Pages : 8 Date : 10/16/1996 This document defines the initial assignment of IPv6 multicast addresses. It is based on the "RFC-1884 IP Version 6 Addressing Architecture" [RFC1884] and current IPv4 multicast address assignment found in . It adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4 assignments that were not relevant were not converted into IPv6 assignments. Comments are solicited on this conversion. All other IPv6 multicast addresses are reserved. Sections 2 and 3 specify reserved and preassigned IPv6 multicast addresses. Section 4 defines guidelines for assigning new IPv6 multicast addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-multicast-assgn-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961016111710.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-multicast-assgn-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961016111710.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 10:06:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01657; Thu, 17 Oct 96 10:06:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01356; Thu, 17 Oct 96 06:45:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01748; Thu, 17 Oct 1996 06:39:15 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA10430 for ; Thu, 17 Oct 1996 06:39:14 -0700 Received: from localhost by ietf.org id aa28833; 17 Oct 96 9:30 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2340) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-03.txt Date: Thu, 17 Oct 1996 09:30:29 -0400 Message-Id: <9610170930.aa28833@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-03.txt Pages : 35 Date : 10/16/1996 This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others. 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-ipv6-tunnel-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961016152312.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961016152312.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 11:42:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01847; Thu, 17 Oct 96 11:42:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01841; Thu, 17 Oct 96 11:42:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA07902; Thu, 17 Oct 1996 11:33:30 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA15895 for ; Thu, 17 Oct 1996 11:31:25 -0700 Received: from rtpdce03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA32740; Thu, 17 Oct 1996 14:26:37 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id OAA09740; Thu, 17 Oct 1996 14:26:33 -0400 Received: from hygro.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18336; Thu, 17 Oct 1996 14:31:32 -0400 Received: from hygro.raleigh.ibm.com (narten@loopback [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id OAA01196; Thu, 17 Oct 1996 14:27:27 -0400 Message-Id: <199610171827.OAA01196@hygro.raleigh.ibm.com> To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipv6imp@munnari.OZ.AU, solensky@ftp.com, ipng@sunroof.eng.sun.com Subject: (IPng 2341) Re: [IPv6Imp] Re: Q re: Router Advert/Prefix option In-Reply-To: Your message of "Wed, 16 Oct 1996 17:42:29 EDT." <199610162142.RAA26081@pobox.BayNetworks.com> Date: Thu, 17 Oct 1996 14:27:27 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Frank, Dimitry: >> >> A v6 router that we've had reports on is sending out RAs with a prefix >> option over an ethernet with a prefix less than 80 bits wide. My reading >> of Stateless Address Configuration (-07) is that I should be ignoring >> prefixes that are announced where the length is not 80 bits (pg 20, >> bullet 'e', 2nd paragraph). >> >> Is that, in fact, the expected practice? That is definitely the intention. >> If not, should the text be >> changed so that "the sum of the prefix length and interface token length >> is greater than 128 bits, the Prefix Information Option MUST be ignored"? >> Or if I take the waffle approach and make it configurable, should >> the default be to accept or drop? >> -- Frank >> >IMO, the text should be changed the way you're suggesting. Prefix lengths >don't have to be limited to a specific sizes. This is an administrative >choice and it doesn't break autoconfiguration. The suggested change makes it possible for a misconfigured router to advertise two prefixes: XXXX/n and XXXX/m, where XXXX are the same and n and m are different. Using either of those prefixes produces the same address, so you have two prefixes mapped into one address. So far no (big) problem. Later, however, the Lifetime of *one* of those prefixes expires. The address shouldn't expire (yet). To handle this case correctly (i.e.., not time out the address), you'd need extra code in the client that specifically tests for this case. The way things are currently defined, the problem cannot arise. I would expect that enforcing the current rule could be done by the software parsing the RA config file, and would be invisible to the network adminstrator. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 12:06:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01872; Thu, 17 Oct 96 12:06:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01866; Thu, 17 Oct 96 12:06:33 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA14622; Thu, 17 Oct 1996 11:59:00 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA24903 for ; Thu, 17 Oct 1996 11:58:17 -0700 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA99028; Thu, 17 Oct 1996 14:53:36 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id OAA45674; Thu, 17 Oct 1996 14:53:34 -0400 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18350; Thu, 17 Oct 1996 14:58:27 -0400 Message-Id: <9610171858.AA18350@ludwigia.raleigh.ibm.com> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: crawdad@FNAL.GOV, ipv6imp@munnari.OZ.AU, solensky@ftp.com, ipng@sunroof.eng.sun.com Subject: (IPng 2342) Re: [IPv6Imp] Re: Q re: Router Advert/Prefix option In-Reply-To: Your message of "Thu, 17 Oct 1996 11:51:48 EDT." <199610171551.LAA18382@pobox.BayNetworks.com> Date: Thu, 17 Oct 1996 14:58:26 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry: >In addition to >address autoconfiguration, the prefix information in RA enables hosts >to learn the range of on-link addresses. If a link was assigned a prefix >that is shorter than 128 - , I don't see any reason for lying in >RA and reducing the on-link address range from what was administratively >provisioned. I can see situations when hosts would like to use the available >bits between prefix and token to form multiple addresses on >the same physical interface and still take advantage of stateless >autoconfiguration. You are advocating that clients take liberties with prefixes that I think need *very* careful thought. Consider, for example an Ethernet client that decides it wants 10 extra addresses, and uses the byte just to the left of the 6 byte MAC address in the IPv6 address. Later, the site realizes that it needs those same bytes for routing, and proceeds to attempt to renumber that Ethernet subnet. It continues to advertise the the same prefix as before, but also advertises a second prefix that overlaps with the first, and als defines some additinal (subnet) bits in the byte the client used to create extra addresses. Uh oh. We now have a major conflict. Note that the old prefix is still valid, because we are renumbering gracefully, and the old prefix should remain in effect until the new one is in effect. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 17:22:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02145; Thu, 17 Oct 96 17:22:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02139; Thu, 17 Oct 96 17:21:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA06249; Thu, 17 Oct 1996 17:15:34 -0700 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA03625 for ; Thu, 17 Oct 1996 17:15:31 -0700 Received: from abelia.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA18747; Thu, 17 Oct 1996 20:08:02 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31764; Thu, 17 Oct 1996 20:08:06 -0400 Message-Id: <9610180008.AA31764@fwasted.zk3.dec.com> To: Fred Baker Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2343) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Mon, 14 Oct 96 09:57:38 PDT." <32627102.6F5992E1@cisco.com> Date: Thu, 17 Oct 96 20:08:06 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred, OK.. Your last mail with the search engine and that the tag permits a faster lookup has moved me and was an outstanding response. I would now like to give you some feedback on your draft attached that has me confused. Maybe its just my interpretation. I think we need to move forward. I know your working it but for the last time I will state that if the host does not participate in the TAGs architecture I think that is a mistake and I don't support that. I also think there is a POISED issue but I will send my thoughts to Scott Bradner and Richard Hovey on that privately just as some input. On to the draft: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Prio. |G| Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prio. 4-bit priority value. G G=0 indicates global end-to-end flow label definition, G=1 indicates hop-by-hop flow label definition (tag). Flow Label 23-bit flow label. A router could place a tag into the Flow Label field of a packet only if the Flow Label field is all zeros (this restriction doesn't apply to the case where a router just replaces one tag with another). Why not just check if the G bit is set? If its not you can't use it? That way you don't have to test all other bits? 4. Differences with the current definition of Flow Labels With this proposal the Flow Label field could be modified at every hop. This is in contrast with the current definition of Flow Label [RFC1883], where the value of this field is set up by the source of a packet, and is not modified by the routers that forward the packet. Moreover, the semantics of tag is different from the semantics of the Flow Label, as packets carrying the same tag may come from more than one source. We propose to reserve the value of the high-order bit of the Flow Label field to 1 (binary) to identify the cases where the field carries a tag. But if the G bit is not set then the flow-label is treated end-to-end and will not be modified at any hops. This may be implied but I think saying at this point in the draft is prudent. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 17 18:47:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02231; Thu, 17 Oct 96 18:47:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02225; Thu, 17 Oct 96 18:46:47 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA18696; Thu, 17 Oct 1996 18:40:20 -0700 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA23382 for ; Thu, 17 Oct 1996 18:40:15 -0700 From: Masataka Ohta Message-Id: <199610180139.KAA13802@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA13802; Fri, 18 Oct 1996 10:39:04 +0900 Subject: (IPng 2344) Re: use of IPv6 Flow Label for tag switching To: bound@zk3.dec.com Date: Fri, 18 Oct 96 10:39:03 JST Cc: fred@cisco.com, ipng@sunroof.eng.sun.com In-Reply-To: <9610180008.AA31764@fwasted.zk3.dec.com>; from "bound@zk3.dec.com" at Oct 17, 96 8:08 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim; > I think we need to move forward. I'm sorry but TAG switching with flow labels is not a forward movement. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 18 07:49:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02667; Fri, 18 Oct 96 07:49:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02661; Fri, 18 Oct 96 07:49:13 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA22501; Fri, 18 Oct 1996 07:42:46 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA16388 for ; Fri, 18 Oct 1996 07:42:45 -0700 Received: from ftp.com by ftp.com ; Fri, 18 Oct 1996 10:42:44 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Fri, 18 Oct 1996 10:42:44 -0400 Received: from trenton.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id KAA16630; Fri, 18 Oct 1996 10:42:36 -0400 Message-Id: <199610181442.KAA16630@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM Priority: Normal To: ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 2345) Q re: Router Advert/Prefix option Date: Fri, 18 Oct 1996 10:37:48 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I had sent this to ipv6imp last night and fat-fingered the address of this list) My first thought on the matter was that allowing the short prefix would be more consistant with "liberal in what you receive" -- filling the gap with zeros as some have suggested seems like a quick and easy approach. Still, it seems I've been hearing the phrases "128 bits is plenty" and "we've got lots of addresses" when it comes to many IPv6-related efforts these days. I'll still a bit uneasy about defaulting to 48-bit wide host numbers on an ether for stateless; accepting the short prefix allows the address space to be used in an even more inefficient manner. So if we look at this from the "conservative in what you send" perspective, and considering the problems that others have noted, is there a specific situation that the short prefix helps? I'm reluctant to add this based only on it allowing greater flexibility and not why it'd be needed. Making it configurable seems easy, too. But if we all agree on the default setting for this, folks in the opposite situation still have to set the option on all the nodes in that net. -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 18 08:15:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02705; Fri, 18 Oct 96 08:15:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02699; Fri, 18 Oct 96 08:15:22 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA26605; Fri, 18 Oct 1996 08:08:54 -0700 Received: from nacho.cisco.com (nacho.cisco.com [171.69.1.160]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA25905 for ; Fri, 18 Oct 1996 08:08:51 -0700 Received: from fred-axel-fr.cisco.com (fred-axel-fr.cisco.com [171.69.128.115]) by nacho.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id IAA16227; Fri, 18 Oct 1996 08:08:46 -0700 Received: from fred-axel-fr (localhost.cisco.com [127.0.0.1]) by fred-axel-fr.cisco.com (8.6.8+c/CISCO.WS.1.1) with SMTP id IAA04609; Fri, 18 Oct 1996 08:08:44 -0700 Message-Id: <32679D7C.446B9B3D@cisco.com> Date: Fri, 18 Oct 1996 08:08:44 -0700 From: Fred Baker Organization: Cisco Systems/IOS X-Mailer: Mozilla 2.0 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2346) Re: use of IPv6 Flow Label for tag switching References: <9610180008.AA31764@fwasted.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: > Why not just check if the G bit is set? If its not you can't use it? > That way you don't have to test all other bits? Testing one bit requires me to read the word, which contains all of them. I'm not sure I see the distinction. Having said that, if the value is a tag that the router doesn't recognize (the sender used the wrong value and the forwarder detects that, which I would expect that it would do by attempting to use the tag and finding an indication in the record that the tag is not currently in use) it does seem reasonable that it should not at that point zero the tag and act as though the message had been recieved with no tag specified. > But if the G bit is not set then the flow-label is treated end-to-end > and will not be modified at any hops. This may be implied but I think > saying at this point in the draft is prudent. OK. I think it is implied, but I'll say it. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 18 09:54:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02817; Fri, 18 Oct 96 09:54:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02811; Fri, 18 Oct 96 09:54:46 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA19332; Fri, 18 Oct 1996 09:48:17 -0700 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA03016 for ; Fri, 18 Oct 1996 09:47:29 -0700 Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA18633; Fri, 18 Oct 1996 12:21:01 -0400 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05799; Fri, 18 Oct 1996 12:20:57 -0400 Message-Id: <9610181620.AA05799@wasted.zk3.dec.com> To: Fred Baker Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2347) Re: use of IPv6 Flow Label for tag switching In-Reply-To: Your message of "Fri, 18 Oct 96 08:08:44 PDT." <32679D7C.446B9B3D@cisco.com> Date: Fri, 18 Oct 96 12:20:57 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk You have the header in registers. Are you telling me you can't just test an offset in that register when its in the first 32bits of the header let alone if you have 64bit registers. I don't see your comment about having to read the word unless the word is not the first register store. Which I assume the flow-label is. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 18 14:24:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03160; Fri, 18 Oct 96 14:24:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03154; Fri, 18 Oct 96 14:23:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA03882; Fri, 18 Oct 1996 14:16:23 -0700 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA09988 for ; Fri, 18 Oct 1996 14:15:51 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA05499; Fri, 18 Oct 96 17:10:06 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id RAA02834; Fri, 18 Oct 1996 17:18:16 -0400 Date: Fri, 18 Oct 1996 17:18:16 -0400 Message-Id: <199610182118.RAA02834@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: ipng@sunroof.eng.sun.com Subject: (IPng 2348) link-local addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a thought and just want to confirm that it is well founded. It seems that we can live with duplicate tokens on a link as long as that token is not used for auto-address configuration, but we can't live with duplicate IPv6 addresses. That's what DAD seems to be doing and I can argue in favor of such a notion. Now in case of a multihomed node, with link-local addresses, if I have a different link-local address on each interface corresponding to its unique link-layer token, it is difficult to select a source address before performing address resolution for a link-local destination. You spray NSs on each interface and wait for an NA, till then one can't select a source address, which is normally done at the transport layer. This makes implementations a lot more complex. On the other hand if I use the same link-local address on all my interfaces, the source address selection becomes really easy. I do duplicate address detection for this address as well as the first non-link-local address autoconfigured from the actual interface token. As far as identifying interfaces is concerned, my implementation keeps a reference to outgoing or incoming interface in the neighbor cache itself rendering mechanisms like identifying interfaces using ids in link-local addresses of no use. I expect this to be the case with all BSD implemntations, as the neighbor cache is nothing but a part of the routing table, where keeping reference to the outgoing interface has been the norm. As far as user level programs are concerned, they can receive the interface information using socket options, which is easily implemented without being costly. Can anybody see reasons against assigning the same link-local address to all interfaces on a node . Note that medias with different interface token lengths would not affect this. As far link-local addresses are concerned, the only requirement is the fe80::/10 prefix. Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 18 16:01:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03241; Fri, 18 Oct 96 16:01:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03235; Fri, 18 Oct 96 16:01:37 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA27818; Fri, 18 Oct 1996 15:55:08 -0700 Received: from oberon.di.fc.ul.pt (oberon.di.fc.ul.pt [192.67.76.44]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA09522 for ; Fri, 18 Oct 1996 15:55:08 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.7.5/8.7.3) id XAA06790; Fri, 18 Oct 1996 23:52:01 +0100 Date: Fri, 18 Oct 1996 23:52:01 +0100 Message-Id: <199610182252.XAA06790@oberon.di.fc.ul.pt> From: Pedro Roque To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2349) link-local addresses In-Reply-To: <199610182118.RAA02834@sparky.IOL.UNH.EDU> References: <199610182118.RAA02834@sparky.IOL.UNH.EDU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Quaizar" == Quaizar Vohra writes: Quaizar> Now in case of a multihomed node, with link-local Quaizar> addresses, if I have a different link-local address on Quaizar> each interface corresponding to its unique link-layer Quaizar> token, it is difficult to select a source address before Quaizar> performing address resolution for a link-local Quaizar> destination. Your message seams to imply that, on a multihomed host you spray all your interfaces looking for who answer for the address you where given. I've been told that other implementations use this aproach also. Since link local addresses are guarantied to be unique on-link only, doesn't this open a window for failure ? What are you going to do if you get the same link local on more than one link ? (another multihomed host might be multi-homed on the same links that you are and using your aproach... or with systems that configure all it's ethernet interfaces with the same ether address - this can happen on dual rail schemes for instance). regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 18 16:52:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03277; Fri, 18 Oct 96 16:52:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03271; Fri, 18 Oct 96 16:52:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA06110; Fri, 18 Oct 1996 16:45:57 -0700 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA10260 for ; Fri, 18 Oct 1996 16:45:54 -0700 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA06055; Fri, 18 Oct 96 19:40:10 EDT Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id TAA02970; Fri, 18 Oct 1996 19:48:13 -0400 Date: Fri, 18 Oct 1996 19:48:13 -0400 Message-Id: <199610182348.TAA02970@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: Pedro Roque Cc: Quaizar Vohra , ipng@sunroof.eng.sun.com Subject: (IPng 2350) link-local addresses In-Reply-To: <199610182252.XAA06790@oberon.di.fc.ul.pt> References: <199610182118.RAA02834@sparky.IOL.UNH.EDU> <199610182252.XAA06790@oberon.di.fc.ul.pt> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pedro, If you mean that in a dual rail case, a host will get two replies, then in that case it does opens a window of failure. I can still choose to heed to the first reply and communication will still go on, but then this is probably killing the usefulness of a dual rail. Well use global addresses in such cases :-). Now I have come to think that packets with link-local addresses should never be originated, unless the IP layer is explicitly supplied with the outgoing interface information by a higher layer, e.g. DNS or routing protocols (which I think will use link-local addresses quite often) or whosoever. My interest was more from a router point of view. I had just gone out to take care of the remote chance when a node needs to originate packet to a link-local address without being told where it lies. But I might as well resort to returning a "EHOSTUNREACHABLE" error. What does everybody think. Quaizar > >>>>> "Quaizar" == Quaizar Vohra writes: > > > Quaizar> Now in case of a multihomed node, with link-local > Quaizar> addresses, if I have a different link-local address on > Quaizar> each interface corresponding to its unique link-layer > Quaizar> token, it is difficult to select a source address before > Quaizar> performing address resolution for a link-local > Quaizar> destination. > > Your message seams to imply that, on a multihomed host you spray all your > interfaces looking for who answer for the address you where given. > I've been told that other implementations use this aproach also. > > Since link local addresses are guarantied to be unique on-link only, doesn't > this open a window for failure ? What are you going to do if you get > the same link local on more than one link ? (another multihomed host > might be multi-homed on the same links that you are and using your aproach... > or with systems that configure all it's ethernet interfaces with the same > ether address - this can happen on dual rail schemes for instance). > > regards, > ./Pedro. > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Oct 19 13:53:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03797; Sat, 19 Oct 96 13:53:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03791; Sat, 19 Oct 96 13:52:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA12377; Sat, 19 Oct 1996 13:46:03 -0700 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA02992 for ; Sat, 19 Oct 1996 13:45:17 -0700 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.7.4/8.7.3) with SMTP id NAA10157 for ; Sat, 19 Oct 1996 13:45:16 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id NAA28623; Sat, 19 Oct 1996 13:45:16 -0700 Message-Id: <199610192045.NAA28623@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Sat, 19 Oct 1996 13:45:15 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 2351) new "Advanced Sockets API for IPv6" I-D Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt Thomas and I have just submitted a new I-D that picks up where the existing "Basic Socket Interface Extensions for IPv6" I-D leaves off. It should appear in the I-D directories sometime this coming week as . If you want a copy before then, help yourself to: ftp://ftp.kohala.com/pub/rstevens/draft-stevens-advanced-api-00.txt Attached is the Introduction. Rich Stevens --------------------------------------------------------------------- 1. Introduction Specifications are in progress for changes to the sockets API to support IP version 6 [2]. These changes are for TCP and UDP-based applications. The current document defines some the "advanced" features of the sockets API that are required for applications to take advantage of additional features of IPv6. Today, the portability of applications using IPv4 raw sockets is quite high, but this is mainly because most IPv4 implementations started from a common base (the Berkeley source code) or at least started with the Berkeley headers. This allows programs such as Ping and Traceroute, for example, to compile with minimal effort on many hosts that support the sockets API. With IPv6, however, there is no common source code base that implementors are starting from, and the possibility for divergence at this level between different implementations is high. To avoid a complete lack of portability amongst applications that use raw IPv6 sockets, some standardization is necessary. There are also features from the basic IPv6 specification that are not addressed in [2]: sending and receiving hop-by-hop options, destination options, and routing headers, specifying the outgoing interface, and being told of the receiving interface. This document can be divided into the following main sections. 1. Definitions of the basic constants and structures required for applications to use raw IPv6 sockets. This includes structure definitions for the IPv6 and ICMPv6 headers and all associated constants (e.g., values for the next header field). 2. Some basic semantic definitions for IPv6 raw sockets. For exam- ple, a raw ICMPv4 socket requires the application to calculate and store the ICMPv4 header checksum. But with IPv6 this would require the application to choose the source IPv6 address because the source address is part of the pseudo header that ICMPv6 now uses for its checksum computation. It should be defined that with a raw ICMPv6 socket the kernel always calcu- lates and stores the ICMPv6 header checksum. 3. Interface identification: how applications specify the outgoing interface and are told of the incoming interface. There are a class of applications that need this capability and the tech- nique should be portable. 4. Access to the optional hop-by-hop, destination, and routing headers. The final two items (interface identification and access to the IPv6 extension headers) are specified using the "ancillary data" fields that were added to the 4.3BSD Reno sockets API in 1990. The reason is that these ancillary data fields are part of the Posix.1g stan- dard (which should be approved in 1997) and should therefore be adopted by most vendors. This document does not address application access to either the authentication header or the encapsulating security payload header. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 20 10:08:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04182; Sun, 20 Oct 96 10:08:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04176; Sun, 20 Oct 96 10:08:01 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA00564; Sun, 20 Oct 1996 10:01:30 -0700 From: bound@zk3.dec.com Received: from mail2.digital.com (mail2.digital.com [204.123.2.56]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA21317 for ; Sun, 20 Oct 1996 10:01:32 -0700 Received: from bwasted.zk3.dec.com by mail2.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA08105; Sun, 20 Oct 1996 09:57:36 -0700 Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA21511; Sun, 20 Oct 1996 12:53:48 -0400 Message-Id: <9610201653.AA21511@wasted.zk3.dec.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2352) Re: link-local addresses In-Reply-To: Your message of "Fri, 18 Oct 96 17:18:16 EDT." <199610182118.RAA02834@sparky.IOL.UNH.EDU> Date: Sun, 20 Oct 96 12:53:48 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Now in case of a multihomed node, with link-local addresses, if I have >a different link-local address on each interface corresponding to >its unique link-layer token, it is difficult to select a source >address before performing address resolution for a link-local >destination. You spray NSs on each interface and wait for an NA, till >then one can't select a source address, which is normally done at >the transport layer. This makes implementations a lot more complex. Just to make sure I get the direction of this discussion? You are questioning whether we should permit duplicate link-local addresses that are on different links (multihome different links) Case A below? Or duplicate link-local addresses on the same link Case B below. Case A: Node X interface=1 fe80::xx-xx-xx-xx-xx-AA on LINK#1 Node X interface=2 fe80::xx-xx-xx-xx-xx-AA on LINK#2 This is permitted in our specs. But I don't think it too wise from an implementation perspective. Case B: Node X interface=1 fe80::xx-xx-xx-xx-xx-AA on LINK#1 Node X interface=2 fe80::xx-xx-xx-xx-xx-AA on LINK#1 This is NOT permitted by our specs. We had much discussion and deliberation on why in the IPng WG. I will give you several reasons: 1) It is wise and good that nodes can communicate with link-local addresses architecturally for users that only have links ----> the IPng WG "Dentist Office" scenario. This is a huge benefit we get from IPv6. 2) During renumbering nodes can communicate on link with the link-local addresses. 3) For OSPFv6 they only use link-local addresses and routing identifiers, which is an optimization from IPv6 for interior routing architecture not that we should just accept it because OSPFv6 did. But that the OSPFv6 spec is a proof point IMHO. 4) Duplicate address detection for the link-local address guarantees unique link-local addresses on a link which is proving to be of great benefit to other protocols being developed to use the IPv6 architecture. So if your advocating we permit case B above I think that is not a good approach to solve the multihoming problem. >From an implementation perspective it is not difficult to do NS's across interfaces if they have different link-local addresses on the same link. There is a poblem when an NA comes to the implementation for a link-local address when it is duplicated on different links (the problem deprecates worse if we supported Case B), but there are solutions for CASE A. Note this is the reason I really do like Kre's proposal for permitting the extensions to the token for link-local addresses too. >On the other hand if I use the same link-local address on all my >interfaces, the source address selection becomes really easy. >I do duplicate address detection for this address as well as >the first non-link-local address autoconfigured from the actual >interface token. As far as identifying interfaces is concerned, my >implementation keeps a reference to outgoing or incoming interface >in the neighbor cache itself rendering mechanisms like identifying >interfaces using ids in link-local addresses of no use. I expect this >to be the case with all BSD implemntations, as the neighbor cache is >nothing but a part of the routing table, where keeping reference to >the outgoing interface has been the norm. As far as user level >programs are concerned, they can receive the interface information >using socket options, which is easily implemented without being >costly. The gain from the ease for the multihome case complicates and elimiates the gains for the non-multihome case we have consensus on thus far in the WG. Implementations can detect the interface on receipt of a packet for a multhome node on different links rather easily and then doing what you stated above differentiates it at a point in the implementation that can be used for further differentiation in an implementations IPv6 protocol suite. >Can anybody see reasons against assigning the same link-local address >to all interfaces on a node . Note that medias with different >interface token lengths would not affect this. As far link-local >addresses are concerned, the only requirement is the fe80::/10 prefix. Well for Case B I have given you my reasons above. For Case A you can do it that way presently though I think its not optimal. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 21 13:14:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05009; Mon, 21 Oct 96 13:14:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05003; Mon, 21 Oct 96 13:13:50 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA27240; Mon, 21 Oct 1996 13:07:13 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA25044 for ; Mon, 21 Oct 1996 13:07:05 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id NAA27683; Mon, 21 Oct 1996 13:04:29 -0700 (PDT) Message-Id: <199610212004.NAA27683@aland.bbn.com> To: fred@cisco.com, yakov@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2353) quick comment on draft-baker-flow-label-00.txt Reply-To: Craig Partridge From: Craig Partridge Date: Mon, 21 Oct 96 13:04:28 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred and Yakov: Quick comment (which I don't think I saw in the flurry of notes over the past several days, but this may represent a failing of my memory). The document makes it possible to convert flow labels from end-to-end labels to hop-by-hop labels. What it doesn't say is that hop-by-hop labels are less robust than end-to-end ones unless one creates a set of rules (which the document doesn't) to protect the net. Under the Internet rules of engagement, which say routes may flap and routers may crash, one has to worry about what happens if a labeled datagram lands someplace unexpected. Furthermore, there's been some thought that the flow ID table might be flushed by a timer, in which case a low frequency tag might be lost. With globally unique flow IDs, you know where the label was created and can go ask the source how to handle the datagram (obviously not in real-time -- you'd forward the datagram and simultaneously send a query back -- or you'd use some implicit refresh scheme -- some of this is touched on in RFC 1809). Point is, the document needs some statement about what to do with an unknown hop-by-hop flow ID and also needs some procedure to ensure that if you flip routes, you don't screw. The first problem is, I think, easy -- you zero the flow ID field if you don't know the hop-by-hop tag. The second is harder. The scenario is something like this: +----> router 3 router 1 --->router 2 | +----> router 4 As I read your draft, I can define a tag that goes through router 2 (which doesn't know about tags). If the tag was between router 1 and router 4 but router 2 flaps routes and sends the tag to router 3, we're in trouble unless there is global tag coordination. (And, of course, this is one instance of a general case -- assume N routers plugged into router 2, with tags to each other -- and router 2 flips some routes....) This does get solved if all routers in the path have to know about tags and zero any one they don't know (i.e. the statement that if the tag is unknown the datagram is forwarded normally, on page 2, is amended to zero the flow ID and then forward normally). Further, routers that don't know tags should zero flow ID fields with the high bit set... Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 21 20:53:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05323; Mon, 21 Oct 96 20:53:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05317; Mon, 21 Oct 96 20:53:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA25395; Mon, 21 Oct 1996 20:47:07 -0700 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA21762 for ; Mon, 21 Oct 1996 20:47:07 -0700 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id XAA01347; Mon, 21 Oct 1996 23:40:36 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05468; Mon, 21 Oct 1996 23:40:37 -0400 Message-Id: <9610220340.AA05468@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2354) IETF Meeting and IPng WG Date: Mon, 21 Oct 96 23:40:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve/Bob, We still are not listed on the IETF San Jose Dec Agenda? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 22 01:09:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05432; Tue, 22 Oct 96 01:09:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05426; Tue, 22 Oct 96 01:09:42 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA22108; Tue, 22 Oct 1996 01:03:09 -0700 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA06341 for ; Tue, 22 Oct 1996 01:03:08 -0700 Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 22 Oct 1996 09:02:33 +0100 To: Craig Partridge Cc: fred@cisco.com, yakov@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 2355) Re: quick comment on draft-baker-flow-label-00.txt In-Reply-To: Your message of "Mon, 21 Oct 1996 13:04:28 PDT." <199610212004.NAA27683@aland.bbn.com> Date: Tue, 22 Oct 1996 09:02:20 +0100 Message-Id: <797.845971340@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >What it doesn't say is that hop-by-hop labels are less robust than end-to-end >ones unless one creates a set of rules (which the document doesn't) to protect >the net. i think there are lots of good reasons for having hierarchical flow ids (CIDRized) which means that they have to be end to end.... j. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 22 09:28:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05536; Tue, 22 Oct 96 09:28:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05530; Tue, 22 Oct 96 09:27:56 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA23433; Tue, 22 Oct 1996 09:21:22 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA25643 for ; Tue, 22 Oct 1996 09:21:22 -0700 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA07889; Tue, 22 Oct 1996 09:18:45 -0700 Message-Id: <2.2.32.19961022161506.0071e5e8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Oct 1996 09:15:06 -0700 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 2356) Re: IETF Meeting and IPng WG Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, >We still are not listed on the IETF San Jose Dec Agenda? We have three sessions allocated to the IPng working group. See attached email. I suspect they will show up in the next update to the agenda. Bob >To: Steve Deering >From: Marcia Beaulieu >Subject: Re: SAN JOSE IETF: IPNGWG >Cc: deering@parc.xerox.com, hinden@ipsilon.com, jburgan@baynetworks.com, > kasten+iesg@ftp.com, sob@harvard.edu, mo@uunet.uu.net > > >>Thanks, Marcia. If I've interpreted the email exchange properly, you've >>assigned the following slots to ipngwg: >> >> Mon 13:00 >> Mon 19:30 >> Thu 13:00 >> >>Is that correct? > >yes, that is correct. > >Marcia > > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 22 10:01:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05659; Tue, 22 Oct 96 10:01:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05653; Tue, 22 Oct 96 10:01:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA01356; Tue, 22 Oct 1996 09:54:04 -0700 From: bound@ZK3.DEC.COM Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA09080 for ; Tue, 22 Oct 1996 09:53:33 -0700 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id MAA18428; Tue, 22 Oct 1996 12:37:21 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19318; Tue, 22 Oct 1996 12:37:28 -0400 Message-Id: <9610221637.AA19318@wasted.zk3.dec.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2357) Re: IETF Meeting and IPng WG In-Reply-To: Your message of "Tue, 22 Oct 96 09:15:06 PDT." <2.2.32.19961022161506.0071e5e8@mailhost.ipsilon.com> Date: Tue, 22 Oct 96 12:37:28 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Bob... /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 22 10:36:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05752; Tue, 22 Oct 96 10:36:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05746; Tue, 22 Oct 96 10:35:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA11092; Tue, 22 Oct 1996 10:28:51 -0700 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA23565 for ; Tue, 22 Oct 1996 10:28:22 -0700 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id NAA29751; Tue, 22 Oct 1996 13:20:24 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA26783; Tue, 22 Oct 1996 13:20:34 -0400 Message-Id: <9610221720.AA26783@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2358) Anycast/Dyanmic Reassignment/Multihoming et al Date: Tue, 22 Oct 96 13:20:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve/Bob, The ongoing work for Host Anycast Address Support, Dynamic Renumbering (addresses on the fly), and Multihoming is very complex but all interrelated. To that end Pedro Roque Perkins, Matt Thomas, Charlie Perkins, Mike Shand, and myself have joined forces as authors to put together a draft combining the above subjects. We will use the IPv6 Mobile Binding Update packet as the source for our work to provide a destination option to support these technologies. We will have an initial draft ready for the IPng WG meeting in San Jose. Christian Huitema will be consulted to review this work too. The time is short and we are working on it now. We ask the working group to bear with us and we would like a slot on the IPng WG agenda in San Jose to discuss this draft. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 22 10:55:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05803; Tue, 22 Oct 96 10:55:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05797; Tue, 22 Oct 96 10:55:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA16358; Tue, 22 Oct 1996 10:48:24 -0700 Received: from hubbub.cisco.com (hubbub.cisco.com [198.92.30.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA05864 for ; Tue, 22 Oct 1996 10:48:04 -0700 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.7.6/CISCO.GATE.1.1) with SMTP id KAA10067; Tue, 22 Oct 1996 10:47:13 -0700 (PDT) Message-Id: <199610221747.KAA10067@hubbub.cisco.com> To: Craig Partridge Cc: fred@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 2359) Re: quick comment on draft-baker-flow-label-00.txt In-Reply-To: Your message of "Mon, 21 Oct 96 13:04:28 PDT." <199610212004.NAA27683@aland.bbn.com> Date: Tue, 22 Oct 96 10:47:13 PDT From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > Point is, the document needs some statement about what to do with an unknown > hop-by-hop flow ID and also needs some procedure to ensure that if you flip > routes, you don't screw. > > The first problem is, I think, easy -- you zero the flow ID field if you don' t > know the hop-by-hop tag. Correct. > The second is harder. The scenario is something like this: > > +----> router 3 > router 1 --->router 2 | > +----> router 4 > > As I read your draft, I can define a tag that goes through router 2 (which > doesn't know about tags). I am not sure what gave you this impression. > This does get solved if all routers in the path have to know about tags and > zero any one they don't know (i.e. the statement that if the tag is unknown > the datagram is forwarded normally, on page 2, is amended to zero the flow > ID and then forward normally). Further, routers that don't know tags should > zero flow ID fields with the high bit set... Correct. We'll amend the text as you suggested. Yakov. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 22 11:23:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05862; Tue, 22 Oct 96 11:23:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05856; Tue, 22 Oct 96 11:22:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA23973; Tue, 22 Oct 1996 11:16:04 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16512 for ; Tue, 22 Oct 1996 11:15:34 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id LAA29603; Tue, 22 Oct 1996 11:12:59 -0700 (PDT) Message-Id: <199610221812.LAA29603@aland.bbn.com> To: Yakov Rekhter Cc: Craig Partridge , fred@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 2360) Re: quick comment on draft-baker-flow-label-00.txt In-Reply-To: Your message of Tue, 22 Oct 96 10:47:13 -0700. <199610221747.KAA10067@hubbub.cisco.com> Date: Tue, 22 Oct 96 11:12:54 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The second is harder. The scenario is something like this: > > +----> router 3 > router 1 --->router 2 | > +----> router 4 > > As I read your draft, I can define a tag that goes through router 2 (which > doesn't know about tags). I am not sure what gave you this impression. Just to clarify where I got the impression -- from page 2: If a router is not capable of using a tag, and the router receives an IPv6 packet that carries a tag, the router forwards the packet following the normal IPv6 procedures. Router 2 is a normal router that doesn't use a tag. Since later in your note you note this sentence needs to be changed, I think we're just fine. Thanks! Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 23 11:20:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07034; Wed, 23 Oct 96 11:20:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07028; Wed, 23 Oct 96 11:20:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA12268; Wed, 23 Oct 1996 11:13:09 -0700 Received: from INET-03-IMC.itg.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA22510 for ; Wed, 23 Oct 1996 11:12:22 -0700 Received: by INET-03-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56) id <01BBC0D3.659BEA90@INET-03-IMC.itg.microsoft.com>; Wed, 23 Oct 1996 11:14:45 -0700 Message-Id: From: Richard Draves To: "'conta@casc.com'" , "'deering@parc.xerox.com'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 2361) fragmentation in generic tunneling Date: Wed, 23 Oct 1996 11:10:53 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56 Encoding: 35 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm confused by the description of fragmentation (section 7.1) in draft-ietf-ipngwg-ipv6-tunnel-03.txt. RFC 1883 (section 5) says that an IPv6 node can always send 576 octet packets. If a node gets a Packet Too Big message specifying an MTU smaller than 576 octets, then the node can still send 576 octet packets but it must include a fragment header in the packets. In section 7.1 a) the draft says, if the tunnel packet would need to be fragmented and the original packet is bigger than 576 octets, then the tunnel entry-point node should send a Packet Too Big specifying an MTU that is the original packet size minus the size of the tunnel headers. In section 8.2 it says (slightly different) that the Packet Too Big should specify an MTU that is the tunnel MTU minus the size of the tunnel headers. Suppose the original packet is 586 octets, the tunnel MTU is 596 octets, and the tunnel headers are 40 octets. Then the draft says tunnel entry-point should send a Packet Too Big with an MTU of 546 or 556 octets, depending on which section you believe. In any case, won't this cause the source of the original packet to include fragment headers when it doesn't need to? (Eg when it later sends an original packet that is 576 octets.) I'm assuming here that the tunnel entry-point node should use its own identification values when it fragments tunnel packets - there's no need for it to get identification values from the source of the original packet. (The draft could also clarify this.) It seems like the draft should specify that the MTU in the tunnel entry-point's Packet Too Big should be max(576, tunnel MTU - tunnel header size) to prevent this. Rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 23 13:03:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07131; Wed, 23 Oct 96 13:03:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07123; Wed, 23 Oct 96 13:03:06 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA06286; Wed, 23 Oct 1996 12:56:31 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA00277 for ; Wed, 23 Oct 1996 12:56:32 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <19338(1)>; Wed, 23 Oct 1996 12:36:02 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75271>; Wed, 23 Oct 1996 11:58:51 PDT To: Richard Draves Cc: conta@casc.com, ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2362) Re: fragmentation in generic tunneling In-Reply-To: richdr's message of Wed, 23 Oct 96 11:10:53 -0800. Date: Wed, 23 Oct 1996 11:58:50 PDT From: Steve Deering Message-Id: <96Oct23.115851pdt."75271"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > It seems like the draft should specify that the MTU in the tunnel > entry-point's Packet Too Big should be > max(576, tunnel MTU - tunnel header size) > to prevent this. Yes, I agree. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 10:53:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00212; Thu, 24 Oct 96 10:53:41 PDT Date: Thu, 24 Oct 96 10:53:41 PDT From: owner-ipng Message-Id: <9610241753.AA00212@sunroof.eng.sun.com> Apparently-To: ipng-dist From owner-ipng Thu Oct 24 10:57:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00321; Thu, 24 Oct 96 10:57:46 PDT Received: from Eng.Sun.COM ([129.146.1.13]) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08805; Thu, 24 Oct 96 09:19:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA08123; Thu, 24 Oct 1996 09:11:42 -0700 Received: from unh.edu (unh.edu [132.177.132.50]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA16523 for ; Thu, 24 Oct 1996 09:11:37 -0700 Received: from whitec.sr.unh.edu by unh.edu with SMTP id AA25612 (5.67b+/IDA-1.5 for <@unh.edu:ipng@sunroof.Eng.Sun.COM>); Thu, 24 Oct 1996 12:11:29 -0400 Received: by whitec.sr.unh.edu (940816.SGI.8.6.9/921111.SGI) for ipng@sunroof.Eng.Sun.COM id MAA01164; Thu, 24 Oct 1996 12:15:09 -0400 Date: Thu, 24 Oct 1996 12:15:09 -0400 From: Bill.Lenharth@unh.edu (William Lenharth) Message-Id: <199610241615.MAA01164@whitec.sr.unh.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 2364) IPv6 test period at UNH X-Status: N X-Mailer: Applixware 4.0(429.85) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ****** Notice ******** Due to several requests we will be holding the test period at the SAME location as all the other test periods and we will use the same schedule ,e.g., Mon -though - Friday. Please advise me if this causes any problems. Send responses to whl@unh.edu . ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 11:18:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00403; Thu, 24 Oct 96 11:18:43 PDT Received: from Eng.Sun.COM ([129.146.1.13]) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08327; Thu, 24 Oct 96 04:01:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA03815; Thu, 24 Oct 1996 03:53:07 -0700 Received: from tjok.tbit.dk (tjok.tbit.dk [194.182.135.79]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA25552 for ; Thu, 24 Oct 1996 03:53:07 -0700 Received: from pcn.tbit.dk (pcn.tbit.dk [194.182.135.33]) by tjok.tbit.dk (8.7.5/8.7.3) with ESMTP id MAA27285 for ; Thu, 24 Oct 1996 12:53:02 +0200 (MET DST) Received: from localhost (pcn@localhost) by pcn.tbit.dk (8.7.5/8.7.3) with ESMTP id MAA07370 for ; Thu, 24 Oct 1996 12:49:50 +0200 (MET DST) Date: Fri, 18 Oct 1996 22:40:26 +0200 (MET DST) From: "Peder Chr. Norgaard" To: Frank T Solensky Cc: ipv6@sunroof.eng.sun.com, ipv6imp@munnari.OZ.AU, rja@cisco.com, crawdad@FNAL.GOV, dhaskin@baynetworks.com Subject: (IPng 2365) Re: [IPv6Imp] Re: Q re: Router Advert/Prefix option In-Reply-To: <199610180441.AAA19042@MAILSERV-2HIGH.FTP.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Resent-Date: Thu, 24 Oct 1996 12:49:27 +0200 (MET DST) Resent-From: "Peder Chr. Norgaard" Resent-To: ipng@sunroof.eng.sun.com Resent-Message-Id: Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 18 Oct 1996, Frank T Solensky wrote: > For the benefit of those who are on 'ipv6' but not 'ipv6imp': > a discussion about stateless address configuration is taking place. > We've run into a router that is announcing an address prefix which is > less than 80 bits to nodes on an ethernet interface. A strict > reading of RFC-1971 would suggest that this is incorrect behavior: > the nodes MUST ignore this (ref: page 18, bullet e, paragraph 2). > I asked whether we should instead allow it and change the text. >=20 Considering that the whole story started with one of our routers, I should perhaps throw in a remark or two: Now, this is not something that we have any really strong opinions on; after having read the pros and cons in the thread I am mostly inclied to support the strict interpretation of the current text in RFC1971 - Thomas Narten's arguments about renumbering problems seems rather convincing. That our router currently can be configured to be produce RAs that are illegal according to RFC1971 is a detail that can be fixed. The thing we need to hear more about would be Ran Atkinson's customers that wanted to use 64 bit suffixes - to me that sounds more like a mmodification to RFC1972 than RFC1971? I am pretty certain that our customer, the user of the router, has no unbendable reasons for wanting a shorter-than-80 bit prefix. At any rate, now that we understand the problem, it can be worked around rather easily by the customer defining two prefixes, a short one for on-link and an 80-bit one with a suitable number of zero bits for auto-configuration. Actually, we could change the router to do that automatically, in the sense that if it is configured with a shorter-than-80 bit prefix and auto-configuration, the router could just split that into two Prefix Information options. best regards Peder Chr. N=F8rgaard Systems Programmer, M. Sc.=20 Telebit Communications A/S tel: +45 86 28 81 77 - 49 Skanderborgvej 234 fax: +45 86 28 81 86 DK-8260 Viby J Denmark e-mail: pcn@tbit.dk ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 14:58:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00816; Thu, 24 Oct 96 14:58:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00810; Thu, 24 Oct 96 14:58:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA27919; Thu, 24 Oct 1996 14:51:16 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA24057 for ; Thu, 24 Oct 1996 14:50:45 -0700 Received: by mail4.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56) id <01BBC1BA.D6FA5B30@mail4.microsoft.com>; Thu, 24 Oct 1996 14:51:29 -0700 Message-Id: From: Richard Draves To: "'deering@parc.xerox.com'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 2366) fragmentation and translation Date: Thu, 24 Oct 1996 14:50:43 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56 Encoding: 37 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >RFC 1883 (section 5) says that an IPv6 node can always send 576 octet >packets. If a node gets a Packet Too Big message specifying an MTU smaller >than 576 octets, then the node can still send 576 octet packets but it must >include a fragment header in the packets. > There's something about this requirement that confuses me. The rationale in RFC 1883 is that you might have an IPv6-IPv4 translating router. This router might receive a 576 octet v6 packet that, after translation to a v4 packet, needs to be fragmented. I assume the rationale is that is difficult for the translating router to invent good identification values to use in the v4 fragments. This is true in a couple scenarios. For example, if the translating router is both converting some v6 fragments to v4 fragments (passing through an identification value) and doing the initial fragmentation of some v6 packets (inventing an identification value), then the router might invent a value and then the v6 source might use the same value a short time later and there would be confusion at the v4 destination. Less likely, if the packets could go through several such translating routers with coordinated v6-v4 address mappings, the routers would also have to coordinate their identification values. Better to rely on the v6 source to come up with unique identification values that can be used by the translating routers. However v6 identification values are 32 bits and v4 values are 16 bits, so it seems there's a problem here for translating routers: how should the identification value be translated? If the v6 source uses a wrap-around counter to generate identification values and the translating router knows which are the low 16 bits to grab in the conversion to v4, then this will work, but there's no such guarantee right now. It would help if the RFC specified a 16 bit subset of the v6 identification value and required that those bits be unique too, albeit at a smaller time scale than the full 32 bits. Rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 15:25:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00859; Thu, 24 Oct 96 15:25:04 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00849; Thu, 24 Oct 96 15:24:49 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA04284; Thu, 24 Oct 1996 15:18:09 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA02684 for ; Thu, 24 Oct 1996 15:18:09 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id SAA01587; Thu, 24 Oct 1996 18:17:49 -0400 Date: Thu, 24 Oct 1996 18:17:49 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9610241817.ZM1585@seawind.bellcore.com> In-Reply-To: Richard Draves "(IPng 2366) fragmentation and translation" (Oct 24, 2:50pm) References: X-Mailer: Z-Mail (3.2.0 06sep94) To: Richard Draves , "'deering@parc.xerox.com '" Subject: (IPng 2367) Re: fragmentation and translation 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 This discussion already took place, and a concusion was that translating routers were not such a good idea after all. However, if you really intend to do translating routers, then a reasonably safe way of producing a unique ID is to compute a 16 bit checksum of the IPv6 packet, which guarantees that if packets show up at different places, they will end up with the same check sum. That only applies in the absence of a fragmentation header. In the presence of such a header, we must make sure that the IPv6 fragments translate into IPv4 fragments properly, even if different fragments are routed through different gateways. There should be a rule. Either just take the lower 16 bits, or an XOR of low and up, but choose something... -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 15:49:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00915; Thu, 24 Oct 96 15:49:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00896; Thu, 24 Oct 96 15:45:05 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA08974; Thu, 24 Oct 1996 15:38:27 -0700 Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA09284 for ; Thu, 24 Oct 1996 15:38:28 -0700 Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id SAA29628; Thu, 24 Oct 1996 18:38:06 -0400 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma029574; Thu Oct 24 18:37:52 1996 Received: from thor.ca.newbridge.com (thor.ca.newbridge.com [138.120.100.14]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id SAA20330; Thu, 24 Oct 1996 18:37:51 -0400 Received: from fields.newbridge (fields [138.120.136.143]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id SAA21836; Thu, 24 Oct 1996 18:37:47 -0400 From: James Watt Message-Id: <199610242237.SAA21836@thor.ca.newbridge.com> Subject: (IPng 2368) Re: fragmentation in generic tunneling To: richdr@microsoft.com (Richard Draves) Date: Thu, 24 Oct 1996 18:37:43 -0400 (EDT) Cc: conta@casc.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com In-Reply-To: from "Richard Draves" at Oct 23, 96 11:10:53 am 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 Steve Deering writes: +---------- |Rich, | |> It seems like the draft should specify that the MTU in the tunnel |> entry-point's Packet Too Big should be |> max(576, tunnel MTU - tunnel header size) |> to prevent this. | |Yes, I agree. | |Steve +------- To recapitulate: 1) A sender is always allowed to send 576 2) A "Packet To Big" with a size smaller than 576 tells the sender to include a fragmentation header if it has a packet bigger than 576. The hypothesized situation is one in which the Tunnel MTU minus the tunnel header (useable tunnel payload) is less than 576. It would seem in this situation that one wants the originator to send a fragmentation header. To do this, one must use the SMALLER mtu. So there is no need to do the comparison with 576. The alternative would be to require that the fragmentation would be done at the tunnel level, and the tunnel egress would have to do re-assembly. If you want to do that, then there is never a need to send a tunnel MTU smaller than 576, and the suggested comparison is correct. However, it should be noted that the tunnelling draft does _not_ call for this behavior. Section 3.3 says that it simply decapsulates individual packets and forwards them. Regards, -james ____________________________________________________________________________ James W. Watt, james@newbridge.com Ph: +1 613 591-3600 Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 16:00:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00963; Thu, 24 Oct 96 16:00:41 PDT Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00933; Thu, 24 Oct 96 15:56:34 PDT Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA20121; Thu, 24 Oct 1996 15:49:59 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA17009; Thu, 24 Oct 1996 15:49:32 -0700 Date: Thu, 24 Oct 1996 15:49:32 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199610242249.PAA17009@bobo.eng.sun.com> To: richdr@microsoft.com Subject: (IPng 2369) Re: fragmentation and translation 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 > >RFC 1883 (section 5) says that an IPv6 node can always send 576 octet > >packets. If a node gets a Packet Too Big message specifying an MTU smaller > >than 576 octets, then the node can still send 576 octet packets but it must > >include a fragment header in the packets. > > > There's something about this requirement that confuses me. The rationale > in RFC 1883 is that you might have an IPv6-IPv4 translating router. This > router might receive a 576 octet v6 packet that, after translation to a > v4 packet, needs to be fragmented. > > I assume the rationale is that is difficult for the translating router > to invent good identification values to use in the v4 fragments. This is > true in a couple scenarios. For example, if the translating router is > both converting some v6 fragments to v4 fragments (passing through an > identification value) and doing the initial fragmentation of some v6 > packets (inventing an identification value), then the router might > invent a value and then the v6 source might use the same value a short > time later and there would be confusion at the v4 destination. Less > likely, if the packets could go through several such translating routers > with coordinated v6-v4 address mappings, the routers would also have to > coordinate their identification values. Better to rely on the v6 source > to come up with unique identification values that can be used by the > translating routers. Your understanding is correct. The translator can send an ICMP "packet too big" to the v6 source with an MTU < 576 to get the source to emit fragmentation headers. This avoids the translator ever having to invent a identification number. > However v6 identification values are 32 bits and v4 values are 16 bits, > so it seems there's a problem here for translating routers: how should > the identification value be translated? I guess the should be written up in the specification for v4<->v6 translators. However, as far as I know nobody is working on such a document. I always assumed to the low-order 16 bits would be a good choice but as you point out... > If the v6 source uses a wrap-around counter to generate identification > values and the translating router knows which are the low 16 bits to > grab in the conversion to v4, then this will work, but there's no such > guarantee right now. It would help if the RFC specified a 16 bit subset > of the v6 identification value and required that those bits be unique > too, albeit at a smaller time scale than the full 32 bits. ... the assumption would be that the v6 identification numbers are monotonically increasing and in network byte order. Note that the numbers are not unique - they always wrap around in some finite time. What we need is a more detailed specification so that a translator can pick 16 bits and still ensure that is doesn't wrap in less than 2**16 packets. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 16:04:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00990; Thu, 24 Oct 96 16:04:17 PDT Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00951; Thu, 24 Oct 96 16:00:20 PDT Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA20453; Thu, 24 Oct 1996 15:53:44 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA17266; Thu, 24 Oct 1996 15:53:18 -0700 Date: Thu, 24 Oct 1996 15:53:18 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199610242253.PAA17266@bobo.eng.sun.com> To: huitema@bellcore.com Subject: (IPng 2370) Re: fragmentation and translation 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 > This discussion already took place, and a concusion was that translating > routers were not such a good idea after all. However, if you really > intend to do translating routers, then a reasonably safe way of > producing a unique ID is to compute a 16 bit checksum of the IPv6 > packet, which guarantees that if packets show up at different places, > they will end up with the same check sum. We actually solved this problem so that there is no need for a translator to "invent" IDs. But as far I know it isn't written down except what can be inferred from the statement in the base specification that says: >RFC 1883 (section 5) says that an IPv6 node can always send 576 octet >packets. If a node gets a Packet Too Big message specifying an MTU smaller >than 576 octets, then the node can still send 576 octet packets but it must >include a fragment header in the packets. So it seems like we need somebody to write down a short spec on translators? Something for the ngtrans WG? Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 17:42:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01333; Thu, 24 Oct 96 17:42:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01327; Thu, 24 Oct 96 17:42:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA02956; Thu, 24 Oct 1996 17:35:38 -0700 Received: from INET-05-IMC.itg.microsoft.com (mail5.microsoft.com [131.107.3.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA11695 for ; Thu, 24 Oct 1996 17:35:39 -0700 Received: by INET-05-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56) id <01BBC1D2.2EBCAAF0@INET-05-IMC.itg.microsoft.com>; Thu, 24 Oct 1996 17:38:35 -0700 Message-Id: From: Richard Draves To: "'deering@parc.xerox.com'" , "'huitema@bellcore.com'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 2371) Re: fragmentation and translation Date: Thu, 24 Oct 1996 17:35:26 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56 Encoding: 12 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This discussion already took place, and a concusion was that translating >routers were not such a good idea after all. I'm not trying to argue the pros and cons of translation as a strategy for v6 -> v4 migration. My point is that the RFC seems to allow for translation (and I think providing for the possibility is a good idea) and it's unfortunate that it mostly solves the problem of translating fragments, but doesn't quite finish the job. >Rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 17:55:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01427; Thu, 24 Oct 96 17:55:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01421; Thu, 24 Oct 96 17:55:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA04965; Thu, 24 Oct 1996 17:48:52 -0700 Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA14721 for ; Thu, 24 Oct 1996 17:48:53 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <17080(4)>; Thu, 24 Oct 1996 17:48:50 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 24 Oct 1996 17:48:41 PDT To: James Watt Cc: richdr@microsoft.com (Richard Draves), conta@casc.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com Subject: (IPng 2372) Re: fragmentation in generic tunneling In-Reply-To: james's message of Thu, 24 Oct 96 15:37:43 -0800. <199610242237.SAA21836@thor.ca.newbridge.com> Date: Thu, 24 Oct 1996 17:48:40 PDT From: Steve Deering Message-Id: <96Oct24.174841pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: James Watt > > The hypothesized situation is one in which the Tunnel MTU minus the > tunnel header (useable tunnel payload) is less than 576. > > [omitted stuff] > > The alternative would be to require that the fragmentation would be > done at the tunnel level, and the tunnel egress would have to do > re-assembly. Yes, that alternative is what we intended to specify. If the packet to be forwarded through the tunnel is 576 bytes or shorter, but bigger than the tunnel MTU minus the tunnel header(s), then the tunnel entry point will encapsulate the packet and then fragment the outer, containing packet to fit in the tunnel path's MTU, for reassembly at the tunnel exit point. Such "link-local" fragmentation and reassembly is the required behavior of any IPv6-bearing link whose MTU is less than 576, and we are modeling a tunnel as a virtual link. > However, it should be noted that the tunnelling draft does > _not_ call for this behavior. Section 3.3 says that it simply > decapsulates individual packets and forwards them. Then that needs to be clarified. The strict left-to-right processing rules for extension header processing implies that the tunnel exit point completes reassembly before determining that an embedded IP packet is present. Sorry for the confusingness of the spec, and thanks for the feedback. We got confused a few times ourselves, and I'm afraid there are still traces of that in the draft. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 24 17:59:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01440; Thu, 24 Oct 96 17:59:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01433; Thu, 24 Oct 96 17:59:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA05624; Thu, 24 Oct 1996 17:53:00 -0700 Received: from INET-02-IMC.microsoft.com (mail2.microsoft.com [131.107.3.42]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA15726 for ; Thu, 24 Oct 1996 17:53:01 -0700 Received: by INET-02-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56) id <01BBC1D4.2FBCA3E0@INET-02-IMC.microsoft.com>; Thu, 24 Oct 1996 17:52:56 -0700 Message-Id: From: Richard Draves To: "'James Watt'" Cc: "'conta@casc.com'" , "'deering@parc.xerox.com'" , "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 2373) RE: fragmentation in generic tunneling Date: Thu, 24 Oct 1996 17:52:36 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56 Encoding: 39 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >To recapitulate: > >1) A sender is always allowed to send 576 > >2) A "Packet To Big" with a size smaller than 576 tells the sender to > include a fragmentation header if it has a packet bigger than 576. I think that's not accurate. RFC 1883 says "In that case, the IPv6 node is not required to reduce the size of subsequent packets to less than 576, but must include a Fragment header in those packets so that the IPv6-to-IPv4 translating router can obtain a suitable Identification value to use in resulting IPv4 fragments." I take that to mean that the IPv6 node should limit itself to sending 576 octet (or smaller) packets, and it should include a Fragment header on all subsequent packets, both 576 octet packets and smaller packets. >The hypothesized situation is one in which the Tunnel MTU minus the >tunnel header (useable tunnel payload) is less than 576. > >It would seem in this situation that one wants the originator to send >a fragmentation header. > >To do this, one must use the SMALLER mtu. So there is no need to do >the comparison with 576. > >The alternative would be to require that the fragmentation would be >done at the tunnel level, and the tunnel egress would have to do >re-assembly. If you want to do that, then there is never a need to >send a tunnel MTU smaller than 576, and the suggested comparison is >correct. However, it should be noted that the tunnelling draft does >_not_ call for this behavior. Section 3.3 says that it simply >decapsulates individual packets and forwards them. > As I read it, the tunneling draft does require the tunnel entry to fragment (and the tunnel exit to reassemble) in some situations. See section 7.1. >Rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 25 08:09:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01948; Fri, 25 Oct 96 08:09:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01942; Fri, 25 Oct 96 08:09:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA19488; Fri, 25 Oct 1996 08:02:34 -0700 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA03339 for ; Fri, 25 Oct 1996 08:02:34 -0700 Received: by rodan.UU.NET id QQbmyu29578; Fri, 25 Oct 1996 11:02:31 -0400 (EDT) Date: Fri, 25 Oct 1996 11:02:31 -0400 (EDT) From: mo@UU.NET (Mike O'Dell) Message-Id: To: ipng@sunroof.eng.sun.com Subject: (IPng 2374) it seems my first note didn't make it for some reason..... Cc: deering@parc.xerox.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk has been sent to be posted as an ID. ftp://ftp.uu.net/pub/mo/draft-odell-8+8-0.{txt,ps} are also available. cheers! -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 25 09:59:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02030; Fri, 25 Oct 96 09:59:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01931; Fri, 25 Oct 96 07:26:15 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA13617; Fri, 25 Oct 1996 07:19:39 -0700 Received: from endor.harvard.edu (endor.harvard.edu [128.103.50.55]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA19644 for ; Fri, 25 Oct 1996 07:19:38 -0700 Received: (from sob@localhost) by endor.harvard.edu (8.6.13/8.6.12) id KAA05712 for ipng@sunroof.Eng.Sun.COM; Fri, 25 Oct 1996 10:19:37 -0400 Date: Fri, 25 Oct 1996 10:19:37 -0400 From: Scott Bradner Message-Id: <199610251419.KAA05712@endor.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: (IPng 2375) Mike's 8+8 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd suggest that people take a look at this ID - it seems to me to be quite a win. Scott ---- From ietf-announce-request@ietf.org Fri Oct 25 10:09:16 1996 Received: from netop3.harvard.edu (netop3.harvard.edu [128.103.205.103]) by endor (8.6.13/8.6.12) with ESMTP id KAA05460 for ; Fri, 25 Oct 1996 10:09:15 -0400 Received: from ietf.org (ietf.org [132.151.1.19]) by netop3.harvard.edu (8.6.12/8.6.12) with SMTP id KAA15811 for ; Fri, 25 Oct 1996 10:09:14 -0400 Received: from ietf.org by ietf.org id aa03820; 25 Oct 96 9:46 EDT Received: from localhost by ietf.org id aa03091; 25 Oct 96 9:27 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Sender: ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-odell-8+8-00.txt Date: Fri, 25 Oct 1996 09:27:18 -0400 X-Orig-Sender: cclark@ietf.org Message-ID: <9610250927.aa03091@ietf.org> Status: R --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : 8+8 - An Alternate Addressing Architecture for IPv6 Author(s) : M. O'Dell Filename : draft-odell-8+8-00.txt Pages : 20 Date : 10/24/1996 This document presents an alternative addressing architecture for IPv6 which controls global routing growth with very aggressive topological aggregation. It also includes support for scalable multihoming as a distinguished service while freeing sites and service resellers from the tyranny of CIDR-based aggregation by providing transparent rehoming of both. 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-odell-8+8-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-odell-8+8-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-odell-8+8-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961024155204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-odell-8+8-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-odell-8+8-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961024155204.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Oct 25 17:32:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02359; Fri, 25 Oct 96 17:32:58 PDT Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02343; Fri, 25 Oct 96 17:30:49 PDT Received: from fstop. by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA08019; Fri, 25 Oct 1996 17:24:12 -0700 Received: from fstop by fstop. (SMI-8.6/SMI-SVR4) id RAA02893; Fri, 25 Oct 1996 17:23:54 -0700 Message-Id: <199610260023.RAA02893@fstop.> From: sparker@eng.sun.com To: ipng@sunroof Subject: (IPng 2376) IPng list machine off air.... Date: Fri, 25 Oct 1996 17:23:53 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Due to some work by the power company, the machine which forwards this list will be off the air soon, and back on sometime around mid-day Saturday, Pacific time. While e-mail should be buffered safely during that period, if there are disruptions, that will be the cause and I will be making sure the machine comes up as promptly as the situation allows. Thanks, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 27 18:18:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00694; Sun, 27 Oct 96 18:18:49 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00688; Sun, 27 Oct 96 18:18:37 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA09155; Sun, 27 Oct 1996 18:11:58 -0800 Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com [131.107.3.41]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA03808 for ; Sun, 27 Oct 1996 18:11:58 -0800 Received: by INET-01-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56) id <01BBC432.57C49310@INET-01-IMC.microsoft.com>; Sun, 27 Oct 1996 18:11:58 -0800 Message-Id: From: Richard Draves To: "'IPng List'" Subject: (IPng 2377) advanced sockets api Date: Sun, 27 Oct 1996 18:11:54 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56 Encoding: 18 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A couple comments on draft-stevens-advanced-api-00.txt... 1) The special treatment of ICMPv6 raw sockets bothers me... my intuition is that raw should be raw. For example, why not require the creator of an ICMPv6 raw socket to use the proposed IPV6_CHECKSUM option to have the kernel calculate and store the checksum? Given the proposal (that the kernel always does this for ICMPv6 raw sockets), how would one write a test program that generated misformed (bad checksum) ICMPv6 packets? 2) The proposal relies pretty heavily on sendmsg/recvmsg and the Posix.1g msg_control/msg_controllen fields in the msghdr structure. If you are interested in portability to an interesting subset of the world, you might want to consider Winsock in addition to Posix. Winsock 2.0 does not include sendmsg/recvmsg. I have no idea how changes are made to Winsock. Rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 27 23:19:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00740; Sun, 27 Oct 96 23:19:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00734; Sun, 27 Oct 96 23:19:47 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA22904; Sun, 27 Oct 1996 23:13:08 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA04641 for ; Sun, 27 Oct 1996 23:13:07 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id CAA07972; Mon, 28 Oct 1996 02:05:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00036; Mon, 28 Oct 1996 02:05:33 -0500 Message-Id: <9610280705.AA00036@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2378) Re: Mike's 8+8 In-Reply-To: Your message of "Fri, 25 Oct 96 10:19:37 EDT." <199610251419.KAA05712@endor.harvard.edu> Date: Mon, 28 Oct 96 02:05:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I really hope all check this out a.s.a.p. I think its really important and fixes a day-1 architecture problem for IPv6 that needs fixing if this protocol is to be widely deployed. I also think it should be part of the IPng WG agenda. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 27 23:29:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00763; Sun, 27 Oct 96 23:29:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00757; Sun, 27 Oct 96 23:29:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA23320; Sun, 27 Oct 1996 23:22:55 -0800 From: bound@zk3.dec.com Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id XAA05734 for ; Sun, 27 Oct 1996 23:22:55 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id CAA16068; Mon, 28 Oct 1996 02:16:13 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA00677; Mon, 28 Oct 1996 02:16:14 -0500 Message-Id: <9610280716.AA00677@wasted.zk3.dec.com> To: Richard Draves Cc: "'IPng List'" Subject: (IPng 2379) Re: advanced sockets api In-Reply-To: Your message of "Sun, 27 Oct 96 18:11:54 PST." Date: Mon, 28 Oct 96 02:16:13 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >1) The special treatment of ICMPv6 raw sockets bothers me... my >intuition is that raw should be raw. For example, why not require the >creator of an ICMPv6 raw socket to use the proposed IPV6_CHECKSUM option >to have the kernel calculate and store the checksum? Given the proposal >(that the kernel always does this for ICMPv6 raw sockets), how would one >write a test program that generated misformed (bad checksum) ICMPv6 >packets? On the special treatment. This draft permits the ability to parse the IPv6 ICMP messages for an application based on the applicaiton need. Such as addr conf, routing, ND, etc.. Why do you not think that is a good thing? >2) The proposal relies pretty heavily on sendmsg/recvmsg and the >Posix.1g msg_control/msg_controllen fields in the msghdr structure. If >you are interested in portability to an interesting subset of the world, >you might want to consider Winsock in addition to Posix. Winsock 2.0 >does not include sendmsg/recvmsg. I have no idea how changes are made to >Winsock. This draft is for BSD 4.4 like systems in that respect. The issue for Winsock and other types (e.g. X/Open, POSIX, etc.) is whether they want to use ancillary data as a means to process IPv6 options, interfaces, etc. Does Winsock have a problem using ancillary data? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Oct 27 23:40:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00809; Sun, 27 Oct 96 23:40:45 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00803; Sun, 27 Oct 96 23:40:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA23862; Sun, 27 Oct 1996 23:33:50 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id XAA06984 for ; Sun, 27 Oct 1996 23:33:47 -0800 From: Masataka Ohta Message-Id: <199610280732.QAA03714@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id QAA03714; Mon, 28 Oct 1996 16:31:56 +0859 Subject: (IPng 2380) Re: Mike's 8+8 To: bound@zk3.dec.com Date: Mon, 28 Oct 96 16:31:55 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610280705.AA00036@wasted.zk3.dec.com>; from "bound@zk3.dec.com" at Oct 28, 96 2:05 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I really hope all check this out a.s.a.p. I think its really important > and fixes a day-1 architecture problem for IPv6 that needs fixing if > this protocol is to be widely deployed. It's almost identical to my FIRST proposal of 8+8 proposed even before the day-1 and is no good. Why? Dig the ML archive. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 05:55:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00934; Mon, 28 Oct 96 05:55:08 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00928; Mon, 28 Oct 96 05:54:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA12721; Mon, 28 Oct 1996 05:48:10 -0800 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA27966 for ; Mon, 28 Oct 1996 05:48:11 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id IAA16626; Mon, 28 Oct 1996 08:47:53 -0500 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id IAA664907; Mon, 28 Oct 1996 08:47:42 -0500 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA61321; Mon, 28 Oct 1996 08:47:41 -0500 From: Charlie Perkins Message-Id: <9610281347.AA61321@hawpub1.watson.ibm.com> To: Masataka Ohta Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 2381) Re: Mike's 8+8 In-Reply-To: Your message of Mon, 28 Oct 96 16:31:55 O. <199610280732.QAA03714@necom830.hpcl.titech.ac.jp> Date: Mon, 28 Oct 96 08:47:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I regret that I don't have time today to dig through the mailing list archives, even though I am interested in the subject. Would you be willing to summarize in a few paragraphs (or sentences) the shortcomings of Mike's proposal? Regards, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 09:50:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01278; Mon, 28 Oct 96 09:50:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01269; Mon, 28 Oct 96 09:50:24 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA19808; Mon, 28 Oct 1996 09:43:40 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA18467 for ; Mon, 28 Oct 1996 09:43:00 -0800 Received: from redwood.ipsilon.com (redwood.Ipsilon.COM [205.226.8.238]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA08053; Mon, 28 Oct 1996 09:40:07 -0800 Message-Id: <2.2.32.19961028174006.00dc6f34@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Oct 1996 09:40:06 -0800 To: bound@zk3.dec.com From: Bob Hinden Subject: (IPng 2382) Re: Mike's 8+8 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I also think it should be part of the IPng WG agenda. It will be. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 11:43:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01439; Mon, 28 Oct 96 11:43:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01433; Mon, 28 Oct 96 11:43:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16719; Mon, 28 Oct 1996 11:36:51 -0800 Received: from INET-03-IMC.itg.microsoft.com (mail3.microsoft.com [131.107.3.23]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA03218 for ; Mon, 28 Oct 1996 11:36:20 -0800 Received: by INET-03-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56) id <01BBC4C4.47A488E0@INET-03-IMC.itg.microsoft.com>; Mon, 28 Oct 1996 11:36:37 -0800 Message-Id: From: Richard Draves To: "'bound@zk3.dec.com'" Cc: "'IPng List'" Subject: (IPng 2383) RE: advanced sockets api Date: Mon, 28 Oct 1996 11:32:11 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56 Encoding: 23 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >On the special treatment. This draft permits the ability to parse the >IPv6 ICMP messages for an application based on the applicaiton need. >Such as addr conf, routing, ND, etc.. Why do you not think that is a >good thing? I think it's a nice capability, but still it seems strange to put lots of semantics into a raw socket. I don't know if this is a practical suggestion, but how about defining a new socket type, SOCK_CONTROL, and using AF_INET6/SOCK_CONTROL/IPPROTO_ICMPV6 to get a socket that would have the semantics that you want for ICMPv6 sockets? >This draft is for BSD 4.4 like systems in that respect. The issue for >Winsock and other types (e.g. X/Open, POSIX, etc.) is whether they want >to use ancillary data as a means to process IPv6 options, interfaces, >etc. Does Winsock have a problem using ancillary data? Winsock 2.0 doesn't have sendmsg/recvmsg so ancillary data doesn't exist. I don't know what it would take to make a non-proprietary change to Winsock. The main point I'm trying to make is, if you want to promote the portability of applications using advanced IPv6 features, you might look at Winsock as well as BSD & Posix. Rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 12:07:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01497; Mon, 28 Oct 96 12:07:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01490; Mon, 28 Oct 96 12:07:39 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA22773; Mon, 28 Oct 1996 12:00:56 -0800 Received: from netmail.austin.ibm.com (netmail.austin.ibm.com [129.35.208.98]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA12554 for ; Mon, 28 Oct 1996 12:00:54 -0800 Received: from mojave.austin.ibm.com (mojave.austin.ibm.com [129.35.56.14]) by netmail.austin.ibm.com (8.6.12/8.6.11) with ESMTP id NAA65136 for ; Mon, 28 Oct 1996 13:59:37 -0600 Received: from loopback (loopback [127.0.0.1]) by mojave.austin.ibm.com (AIX4.2/UCB 8.7/8.7-client1.0) with SMTP id NAA51158 for ; Mon, 28 Oct 1996 13:59:37 -0600 (CST) Message-Id: <199610281959.NAA51158@mojave.austin.ibm.com> X-Authentication-Warning: mojave.austin.ibm.com: Host loopback [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.9 8/22/96 To: ipng@sunroof.eng.sun.com Subject: (IPng 2384) Re: advanced sockets api In-Reply-To: (Your message of Mon, 28 Oct 1996 11:32:11 PST.) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Oct 1996 13:59:37 -0600 From: Steve Wise Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves says: | Winsock 2.0 doesn't have sendmsg/recvmsg so ancillary data doesn't | exist. I don't know what it would take to make a non-proprietary change | to Winsock. The main point I'm trying to make is, if you want to promote | the portability of applications using advanced IPv6 features, you might | look at Winsock as well as BSD & Posix. Are there any plans for Winsock to adhere to industry standards like POSIX? I would think (hope) MS is working toward making Winsock compliant. If they are working on making Winsock compliant, then perhaps it's ok to require sendmsg/resvmsg? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 12:53:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01598; Mon, 28 Oct 96 12:53:43 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01592; Mon, 28 Oct 96 12:53:27 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA02624; Mon, 28 Oct 1996 12:46:40 -0800 Received: from lobster.wellfleet.com (lobster.corpeast.baynetworks.com [192.32.253.3]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA17873 for ; Mon, 28 Oct 1996 12:46:36 -0800 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id PAA20754; Mon, 28 Oct 1996 15:46:54 -0500 Received: from andover.engeast by pobox.BayNetworks.com (SMI-8.6/SMI-SVR4) id PAA14601; Mon, 28 Oct 1996 15:43:06 -0500 Date: Mon, 28 Oct 1996 15:43:06 -0500 From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <199610282043.PAA14601@pobox.BayNetworks.com> To: dhaskin@BayNetworks.com, narten@raleigh.ibm.com Subject: (IPng 2385) Re: [IPv6Imp] Re: Q re: Router Advert/Prefix option Cc: crawdad@FNAL.GOV, ipv6imp@munnari.OZ.AU, solensky@ftp.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I understand your concern of the possible re-numbering problems if the link prefix size is not limited to 80 bits. The problem with that is that it also limits the functional possibilities. In the most cases when there is a tradeoff between functionality and simplicity the former wins. This is why routers nowadays are quite complex to manage. So we are learning to live with that. I remember some discussions on ipng mailing list which has indicated that the ability to construct multible addresses per an interface in the autoconfiguration context is essential for some applications (e.g. for virtial hosts providing web services). So I tend to keep the ability to advertise shorter that 80 bits prefixes in RA. Dimitry > From: Thomas Narten > > Dimitry: > > >In addition to > >address autoconfiguration, the prefix information in RA enables hosts > >to learn the range of on-link addresses. If a link was assigned a prefix > >that is shorter than 128 - , I don't see any reason for lying in > >RA and reducing the on-link address range from what was administratively > >provisioned. I can see situations when hosts would like to use the available > >bits between prefix and token to form multiple addresses on > >the same physical interface and still take advantage of stateless > >autoconfiguration. > > You are advocating that clients take liberties with prefixes that I > think need *very* careful thought. Consider, for example an Ethernet > client that decides it wants 10 extra addresses, and uses the byte > just to the left of the 6 byte MAC address in the IPv6 address. Later, > the site realizes that it needs those same bytes for routing, and > proceeds to attempt to renumber that Ethernet subnet. It continues to > advertise the the same prefix as before, but also advertises a second > prefix that overlaps with the first, and als defines some additinal > (subnet) bits in the byte the client used to create extra > addresses. Uh oh. We now have a major conflict. Note that the old > prefix is still valid, because we are renumbering gracefully, and the > old prefix should remain in effect until the new one is in effect. > > Thomas > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 12:54:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01613; Mon, 28 Oct 96 12:54:05 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01599; Mon, 28 Oct 96 12:53:42 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA02706; Mon, 28 Oct 1996 12:47:01 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA17908 for ; Mon, 28 Oct 1996 12:46:59 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.7.6/8.7.3) with SMTP id NAA29782; Mon, 28 Oct 1996 13:46:58 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id NAA01331; Mon, 28 Oct 1996 13:46:42 -0700 Message-Id: <199610282046.NAA01331@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 28 Oct 1996 13:46:42 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Richard Draves , "'IPng List'" Subject: (IPng 2386) Re: advanced sockets api Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) The special treatment of ICMPv6 raw sockets bothers me... my > intuition is that raw should be raw. For example, why not require the > creator of an ICMPv6 raw socket to use the proposed IPV6_CHECKSUM option > to have the kernel calculate and store the checksum? Given the proposal > (that the kernel always does this for ICMPv6 raw sockets), how would one > write a test program that generated misformed (bad checksum) ICMPv6 > packets? I think 99% of all IPv6 raw sockets will be ICMPv6 raw sockets, so we should handle the most common case in the easiest fashion for the programmer. Perhaps we should explicitly state that one can turn off the IPV6_CHECKSUM option for an ICMPv6 raw socket, if the caller wants to set their own checksum. But I think the default should be for the kernel to calculate and store the checksum for ICMPv6. > 2) The proposal relies pretty heavily on sendmsg/recvmsg and the > Posix.1g msg_control/msg_controllen fields in the msghdr structure. If > you are interested in portability to an interesting subset of the world, > you might want to consider Winsock in addition to Posix. Winsock 2.0 > does not include sendmsg/recvmsg. Well, we have to assume some starting point, and all of the features that the advanced API provides access to (interface ID, destination address, hop-by-hop options, destination options, and routing headers) sure "feel" like ancillary data to me. The destination address is already handled in 4.4BSD systems as ancillary data. Also note that the draft provides access using the IPV6_PKTOPTIONS socket option, in addition to sendmsg/recvmsg, although the intent was to use this for TCP. I'd think this could also be used on systems without sendmsg/recvmsg. IMHO I think the Posix 1003.1g standard is a pretty good starting point to build from. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 13:12:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01709; Mon, 28 Oct 96 13:12:07 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01703; Mon, 28 Oct 96 13:11:55 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06489; Mon, 28 Oct 1996 13:04:13 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA00399 for ; Mon, 28 Oct 1996 13:03:31 -0800 Received: from muggsy.lkg.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA29034; Mon, 28 Oct 1996 15:42:45 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA26937; Mon, 28 Oct 1996 15:42:47 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id QAA18354; Mon, 28 Oct 1996 16:49:35 GMT Message-Id: <199610281649.QAA18354@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Richard Draves Cc: "'IPng List'" Subject: (IPng 2387) Re: advanced sockets api In-Reply-To: Your message of "Sun, 27 Oct 1996 18:11:54 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Oct 1996 16:49:33 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A couple comments on draft-stevens-advanced-api-00.txt... > > 1) The special treatment of ICMPv6 raw sockets bothers me... my > intuition is that raw should be raw. For example, why not require the > creator of an ICMPv6 raw socket to use the proposed IPV6_CHECKSUM option > to have the kernel calculate and store the checksum? Given the proposal > (that the kernel always does this for ICMPv6 raw sockets), how would one > write a test program that generated misformed (bad checksum) ICMPv6 > packets? One wouldn't use this API to send packets with invalid checksums. That's not this API is designed to do. Use an interface to the datalink (such as the Berkeley Packet Filter) and send the errant packets directly. I can't see the need for a production API to be able send bogons. > 2) The proposal relies pretty heavily on sendmsg/recvmsg and the > Posix.1g msg_control/msg_controllen fields in the msghdr structure. If > you are interested in portability to an interesting subset of the world, > you might want to consider Winsock in addition to Posix. Winsock 2.0 > does not include sendmsg/recvmsg. I have no idea how changes are made to > Winsock. Maybe winsock should consider adding sendmsg/recvmsg? They really do make things easier. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 13:19:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01724; Mon, 28 Oct 96 13:19:57 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01718; Mon, 28 Oct 96 13:19:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA08516; Mon, 28 Oct 1996 13:12:54 -0800 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA03200 for ; Mon, 28 Oct 1996 13:12:23 -0800 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA55456; Mon, 28 Oct 1996 16:07:10 -0500 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id QAA36522; Mon, 28 Oct 1996 16:07:09 -0500 Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA15088; Mon, 28 Oct 1996 16:12:25 -0500 Message-Id: <9610282112.AA15088@ludwigia.raleigh.ibm.com> To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2388) Re: Router Advert/Prefix option In-Reply-To: Your message of "Mon, 28 Oct 1996 15:43:06 EST." <199610282043.PAA14601@pobox.BayNetworks.com> Date: Mon, 28 Oct 1996 16:12:24 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, >I understand your concern of the possible re-numbering problems >if the link prefix size is not limited to 80 bits. The problem >with that is that it also limits the functional possibilities. I would suggest then that the discussion move to specifics on how the current specs are lacking and what needs to be done to fill in the gaps. One of the last things we need is for different vendors to come up with non-standard "extensions" that do not interoperate properly with other nodes that adhere to the standards. Having clients steal bits from the network part of an IPv6 address for private use without the rest of the system participating in (or even being aware of) such activities surely raises some dangers here. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 13:26:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01750; Mon, 28 Oct 96 13:26:56 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01730; Mon, 28 Oct 96 13:22:49 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA09251; Mon, 28 Oct 1996 13:16:01 -0800 Received: from precept.com (hydra.precept.com [204.162.119.8]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA04346 for ; Mon, 28 Oct 1996 13:15:28 -0800 Received: from little-toot.precept.com by precept.com (5.x/SMI-4.1) id AA18357; Mon, 28 Oct 1996 13:13:33 -0800 Message-Id: <9610282113.AA18357@precept.com> From: "Karl Auerbach" To: "W. Richard Stevens" , "Richard Draves" , "'IPng List'" Subject: (IPng 2389) Re: advanced sockets api Date: Mon, 28 Oct 1996 13:13:29 -0800 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 1) The special treatment of ICMPv6 raw sockets bothers me > > I think 99% of all IPv6 raw sockets will be ICMPv6 raw sockets Not for those of us playing with RSVP -- we'll need raw IP, not raw ICMP. --karl-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 13:28:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01762; Mon, 28 Oct 96 13:28:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01756; Mon, 28 Oct 96 13:28:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA10519; Mon, 28 Oct 1996 13:21:34 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA06260 for ; Mon, 28 Oct 1996 13:21:16 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.7.6/8.7.3) with SMTP id OAA29808; Mon, 28 Oct 1996 14:20:44 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id OAA01432; Mon, 28 Oct 1996 14:20:44 -0700 Message-Id: <199610282120.OAA01432@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 28 Oct 1996 14:20:43 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Karl Auerbach" , "Richard Draves" , "'IPng List'" Subject: (IPng 2390) Re: advanced sockets api Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Oct 28, 1:13pm you write:] > > > I think 99% of all IPv6 raw sockets will be ICMPv6 raw sockets > > Not for those of us playing with RSVP -- we'll need raw IP, not raw ICMP. But my point wasn't that these are not allowed, it was that ICMPv6 raw sockets will predominate (my guess today, but then I am not familar with RSVP programming). There is nothing to stop you from creating raw sockets that are not ICMPv6, and the I-D spells out how to tell the kernel either (a) don't calculate a checksum, or (b) calculate a checksum and here is the offset of where to store it. I think the original comment (complaint?) was that ICMPv6 raw sockets automatically had the checksum calculated and stored by the kernel, and a way was desired to avoid this. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 13:49:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01840; Mon, 28 Oct 96 13:49:23 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01834; Mon, 28 Oct 96 13:49:13 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA15068; Mon, 28 Oct 1996 13:42:26 -0800 Received: from unh.edu (unh.edu [132.177.132.50]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA13344 for ; Mon, 28 Oct 1996 13:41:49 -0800 Received: from strat.iol.unh.edu by unh.edu with SMTP id AA23311 (5.67b+/IDA-1.5 for <@unh.edu:ipng@sunroof.Eng.Sun.COM>); Mon, 28 Oct 1996 16:41:02 -0500 Received: by strat.iol.unh.edu (940816.SGI.8.6.9/940406.SGI) id QAA24801; Mon, 28 Oct 1996 16:43:21 -0800 Date: Mon, 28 Oct 1996 16:43:21 -0800 Message-Id: <199610290043.QAA24801@strat.iol.unh.edu> To: ipng@sunroof.eng.sun.com Cc: IPv6Imp@munnari.OZ.AU Subject: (IPng 2391) IOL December test regristration From: Sebastien.Roy@unh.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk UNH/IOL IPv6 Test Period Registration Form December 2-5, 1996 Organization _______________________________________________________________ IPv6 Implementation ________________________________________________________ List of Individuals (please include Email addresses) ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ List of Equipment (please provide at least the hardware platform, interface type, OS, and quantity, quantity being the most important. We need to know how many machines you will be bringing.) ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ ________________________________________________________ Arrival Date: ____________ Departure Date: ______________ Credit Card Info: Type:_____________________________________ Bank:_____________________________________ Account Number: __________________________ Expiration Date: ________ Note: Please only fill out one form per Implementation or group. You can respond by Email to whl@bigred.sr.unh.edu, or by regular mail to: IP/Routing Consortium InterOperability Lab University of New Hampshire 7 Leavitt Lane - Room 106 Durham, NH 03824 Any inquiries should be sent to Bill Lenharth (whl@bigred.sr.unh.edu). Please send responses before November 4, your quick responses will help us in making the test period as organized as possible. Thank you. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 13:52:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01854; Mon, 28 Oct 96 13:52:20 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01848; Mon, 28 Oct 96 13:52:08 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA15687; Mon, 28 Oct 1996 13:45:24 -0800 Received: from unh.edu (unh.edu [132.177.132.50]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA25158 for ; Mon, 28 Oct 1996 13:45:18 -0800 Received: from strat.iol.unh.edu by unh.edu with SMTP id AA23567 (5.67b+/IDA-1.5 for <@unh.edu:ipng@sunroof.Eng.Sun.COM>); Mon, 28 Oct 1996 16:45:15 -0500 Received: by strat.iol.unh.edu (940816.SGI.8.6.9/940406.SGI) id QAA24820; Mon, 28 Oct 1996 16:47:35 -0800 Date: Mon, 28 Oct 1996 16:47:35 -0800 Message-Id: <199610290047.QAA24820@strat.iol.unh.edu> To: IPv6Imp@munnari.OZ.AU Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2392) IOL December test overview From: Sebastien.Roy@unh.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Basic Schedule Overview UNH/IOL December test period 12/2 through 12/6 Monday: Setup + ND testing Tuesday: Router testing (RIPng + base router implementations) Wednesday: Testing by Request (more ND, base spec, autoconf etc...) Thursday: Interop Testing (API, Security, RIPng, etc...) Friday: Wrapup + Summary of Testing ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 14:16:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01924; Mon, 28 Oct 96 14:16:39 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01904; Mon, 28 Oct 96 14:13:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA20456; Mon, 28 Oct 1996 14:06:38 -0800 Received: from webserver.casc.com (webserver.casc.com [152.148.41.200]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA21387 for ; Mon, 28 Oct 1996 14:05:54 -0800 Received: from casc.com (alpo [152.148.10.6]) by webserver.casc.com (8.6.12/8.6.12) with ESMTP id RAA19551; Mon, 28 Oct 1996 17:03:43 -0500 Received: from centime.cascade by casc.com (SMI-8.6/SMI-SVR4-bob.2) id RAA28906; Mon, 28 Oct 1996 17:05:49 -0500 Received: by centime.cascade (5.x/SMI-SVR4) id AA25958; Mon, 28 Oct 1996 17:05:46 -0500 Date: Mon, 28 Oct 1996 17:05:46 -0500 From: conta@alpo.casc.com (Alex Conta) Message-Id: <9610282205.AA25958@centime.cascade> To: richdr@microsoft.com, ipng@sunroof.eng.sun.com, rstevens@kohala.com Subject: (IPng 2393) Re: advanced sockets api Cc: conta@alpo.casc.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: rstevens@kohala.com (W. Richard Stevens) > To: Richard Draves , > "'IPng List'" > Subject: (IPng 2386) Re: advanced sockets api > > > 1) The special treatment of ICMPv6 raw sockets bothers me... my > > intuition is that raw should be raw. For example, why not require the > > creator of an ICMPv6 raw socket to use the proposed IPV6_CHECKSUM option > > to have the kernel calculate and store the checksum? Given the proposal > > (that the kernel always does this for ICMPv6 raw sockets), how would one > > write a test program that generated misformed (bad checksum) ICMPv6 > > packets? IPv6 Raw sockets are, in my interpretation, for protocols that are not part of the base set of protocols supported by the kernel stack. Certainly user defined protocols would fall into this cathegory, but so do well known and well defined protocols, like an OSPF for example. ICMP v6 is part of the IPv6 base set of protocols, and like TCP, and UDP, may and as implementations experience shows, should have its own type of socket. Evenmore so, when there are at least a couple of server/clients that may be build in an implementation to receive/send a particular and narrow subset of ICMP types of messages. We are talking about a 'ping' anymore, we have autoconfiguration, router discovery, etc, etc.... > > I think 99% of all IPv6 raw sockets will be ICMPv6 raw sockets, so we > should handle the most common case in the easiest fashion for the > programmer. Perhaps we should explicitly state that one can turn off > the IPV6_CHECKSUM option for an ICMPv6 raw socket, if the caller wants > to set their own checksum. But I think the default should be for the > kernel to calculate and store the checksum for ICMPv6. > In supporting Richard's explanation, ICMP based applications that do not build the IPv6 header themeselves, do not have the capability to bind to a particular source address. Furthermore, the choice of a source address depends on the destination address, but the selection mechanism may be too complex for an application to implement, or access. Therefore it makes a lot of sense to have the specs this way. Alex ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 14:18:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01936; Mon, 28 Oct 96 14:18:10 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01930; Mon, 28 Oct 96 14:17:59 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA21490; Mon, 28 Oct 1996 14:11:17 -0800 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA22947 for ; Mon, 28 Oct 1996 14:10:16 -0800 Received: from muggsy.lkg.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV) id AA26852; Mon, 28 Oct 1996 13:56:38 -0800 Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA27442; Mon, 28 Oct 1996 16:56:34 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id SAA18950; Mon, 28 Oct 1996 18:03:22 GMT Message-Id: <199610281803.SAA18950@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: "Karl Auerbach" Cc: "W. Richard Stevens" , "'IPng List'" Subject: (IPng 2394) Re: advanced sockets api In-Reply-To: Your message of "Mon, 28 Oct 1996 13:13:29 PST." <9610282113.AA18357@precept.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 28 Oct 1996 18:03:21 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > 1) The special treatment of ICMPv6 raw sockets bothers me > > > > I think 99% of all IPv6 raw sockets will be ICMPv6 raw sockets > > Not for those of us playing with RSVP -- we'll need raw IP, not raw ICMP. And so will you'll use socket(PF_INET6, SOCK_RAW, IPPROTO_RSVP) which will give you an RSVP raw socket. Richard is only taking about people who do socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6) to get an ICMPv6 socket. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 17:05:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02277; Mon, 28 Oct 96 17:05:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02271; Mon, 28 Oct 96 17:05:27 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA25470; Mon, 28 Oct 1996 16:58:46 -0800 Received: from INET-05-IMC.itg.microsoft.com (mail5.microsoft.com [131.107.3.31]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA19404 for ; Mon, 28 Oct 1996 16:58:45 -0800 Received: by INET-05-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56) id <01BBC4F1.B2F60290@INET-05-IMC.itg.microsoft.com>; Mon, 28 Oct 1996 17:01:45 -0800 Message-Id: From: Richard Draves To: "'Steve Wise'" Cc: "'IPng List'" Subject: (IPng 2395) Re: advanced sockets api Date: Mon, 28 Oct 1996 16:58:39 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56 Encoding: 11 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Are there any plans for Winsock to adhere to industry standards like POSIX? >I would think (hope) MS is working toward making Winsock compliant. >If they are working on making Winsock compliant, then perhaps it's ok to >require sendmsg/resvmsg? Winsock IS an industry standard. See http://www.stardust.com/wsresource/. Perhaps the Winsock group would be amenable to picking up sendmsg/recvmsg; I don't know. (As an aside, I'm in MS's research group, not in a product group.) Rich ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 19:03:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02386; Mon, 28 Oct 96 19:03:19 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02380; Mon, 28 Oct 96 19:03:08 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA11737; Mon, 28 Oct 1996 18:56:27 -0800 From: bound@zk3.dec.com Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA16204 for ; Mon, 28 Oct 1996 18:56:27 -0800 Received: from wasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id VAA06716; Mon, 28 Oct 1996 21:45:54 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11329; Mon, 28 Oct 1996 21:45:52 -0500 Message-Id: <9610290245.AA11329@wasted.zk3.dec.com> To: Richard Draves Cc: "'IPng List'" Subject: (IPng 2396) Re: advanced sockets api In-Reply-To: Your message of "Mon, 28 Oct 96 11:32:11 PST." Date: Mon, 28 Oct 96 21:45:51 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, >I think it's a nice capability, but still it seems strange to put lots >of semantics into a raw socket. I don't know if this is a practical >suggestion, but how about defining a new socket type, SOCK_CONTROL, and >using AF_INET6/SOCK_CONTROL/IPPROTO_ICMPV6 to get a socket that would >have the semantics that you want for ICMPv6 sockets? I think that is an idea worth pursuing. So far we have been reluctant to define new types in sockets but maybe we should. I think I would like to hear from one of the authors on this idea... Matt/Rich? >>This draft is for BSD 4.4 like systems in that respect. The issue for >>Winsock and other types (e.g. X/Open, POSIX, etc.) is whether they want >>to use ancillary data as a means to process IPv6 options, interfaces, >>etc. Does Winsock have a problem using ancillary data? >Winsock 2.0 doesn't have sendmsg/recvmsg so ancillary data doesn't >exist. I don't know what it would take to make a non-proprietary change >to Winsock. The main point I'm trying to make is, if you want to promote >the portability of applications using advanced IPv6 features, you might >look at Winsock as well as BSD & Posix. I agree 100%. The problem we have had is not having the WINSOCK wizards present in the IETF as we don't usually do APIs. But I think there should be a way to permit ancillary data via WINSOCK as its really just a buffer. Also realize the part of sendmsg/recvmsg passing access rights and the IOVEC for readv/sendv semanatics is not tied to the need for ancillary data. Hence, it may be all WINSOCK would have to do for IPv6 is support the ancillary data which is really just a buffer to the API as a parameter and a length field. If I had the time I would love to go work on this, but I don't right now. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 19:19:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02416; Mon, 28 Oct 96 19:19:37 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02410; Mon, 28 Oct 96 19:19:21 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA13034; Mon, 28 Oct 1996 19:12:39 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA18912 for ; Mon, 28 Oct 1996 19:12:33 -0800 From: Masataka Ohta Message-Id: <199610290311.MAA05193@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA05193; Tue, 29 Oct 1996 12:10:59 +0859 Subject: (IPng 2397) Re: Mike's 8+8 To: charliep@watson.ibm.com (Charlie Perkins) Date: Tue, 29 Oct 96 12:10:58 JST Cc: mohta@necom830.hpcl.titech.ac.jp, bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: <9610281347.AA61321@hawpub1.watson.ibm.com>; from "Charlie Perkins" at Oct 28, 96 8:47 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie; > I regret that I don't have time today to dig through the > mailing list archives, even though I am interested in > the subject. Sorry that I didn't mentioned the name of the mailing list. As it was before day 1, it's not IPng and was big I. > Would you be willing to summarize in a few > paragraphs (or sentences) the shortcomings of Mike's proposal? Mike's? No. It's mine. It's really annoying to see someone slightly modify my current proposal only to make it my, now abandoned, first proposal. My first proposal is no good because ID depends on site topology. That is, though it can solve the issue of site rehoming or site multihoming, it can't remove problems or warts of IPv4 addressing architecture for mobility, multicast or process migration. As you might remember, a mobility problem was discussed in IPv6 mobility BOF at Stockholm, where you insisted on using your proposal for IPv4. In addition, Mike originally invented yet another problems that 2^45 (Mode 1 ESD) is a lot smaller than 10^15, the number of hosts someone requested to be supported by IPv6 ESD (except for small IPv4 compatible part) is no good for the lookup of hierarchical database It should be noted that, as discussed in Mike's explanation on Mode 1 ESD, hierarchy means less efficient use of ID space. Bob; > >I also think it should be part of the IPng WG agenda. > > It will be. It's a waste of time. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 19:58:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02436; Mon, 28 Oct 96 19:58:38 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02430; Mon, 28 Oct 96 19:58:28 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA17231; Mon, 28 Oct 1996 19:51:46 -0800 From: bound@ZK3.DEC.COM Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA25932 for ; Mon, 28 Oct 1996 19:51:46 -0800 Received: from wasted.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id WAA17532; Mon, 28 Oct 1996 22:47:32 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13367; Mon, 28 Oct 1996 22:47:34 -0500 Message-Id: <9610290347.AA13367@wasted.zk3.dec.com> To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2398) Re: Mike's 8+8 In-Reply-To: Your message of "Tue, 29 Oct 96 12:10:58 +0200." <199610290311.MAA05193@necom830.hpcl.titech.ac.jp> Date: Mon, 28 Oct 96 22:47:33 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >I also think it should be part of the IPng WG agenda. >> >> It will be. > >It's a waste of time. Your response is not really polite. Discussion of any idea is useful and we discussed your ideas I recall in April 95 at Danvers MA and we rejected your then proposal as a working group unamiously in a professional manner. I think you need to give Mike's work the same opportunity. I highly suggest from your mail that you read very carefully: draft-odell-code-of-conduct-00.txt I will not pursue this discussion but as a community member I am giving you a "forthtright" comment that you need to be more sensitive with your mail on others work. If you would like to discuss it in person at San Jose I would be glad to meet with you about your behavior and my concerns. I have seen your mail on many lists in this community and this type of behavior is not done to you. No one has ever said to you that your work is a "waste of time" and you should not do that to others. You also recently said this about Fred Bakers work on Flows for TAGs and TAGs in general. It is not polite in anyones culture I am aware of in the world. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 20:35:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02470; Mon, 28 Oct 96 20:35:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02464; Mon, 28 Oct 96 20:35:32 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA19876; Mon, 28 Oct 1996 20:28:50 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA01713 for ; Mon, 28 Oct 1996 20:28:50 -0800 From: Masataka Ohta Message-Id: <199610290427.NAA05588@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA05588; Tue, 29 Oct 1996 13:27:41 +0900 Subject: (IPng 2399) Re: Mike's 8+8 To: bound@ZK3.DEC.COM Date: Tue, 29 Oct 96 13:27:39 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <9610290347.AA13367@wasted.zk3.dec.com>; from "bound@ZK3.DEC.COM" at Oct 28, 96 10:47 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> >I also think it should be part of the IPng WG agenda. > >> > >> It will be. > > > >It's a waste of time. > > Your response is not really polite. Agaist the impolite attetude not to refer related works? > Discussion of any idea is useful and > we discussed your ideas I recall in April 95 at Danvers MA Sure. > and we > rejected your then proposal as a working group unamiously in a > professional manner. We didn't. We merely decided that Yakov's proposal shouldn't become a Proposed Standard, agreed to use it "FOR THE TIME BEING" with some masking and agreed to keep working on the addressing issue. As some of us are now favouring *ID, it's time to discuss 8+8 again. > I think you need to give Mike's work the same > opportunity. We may give the content, not the Author, the same opportunity. The problem is that the content is not new. > You also recently said this about Fred Bakers work on Flows > for TAGs and TAGs in general. Of course. Any proposal like Fred's should be accompanied by some reasoning on why it is necessary. As there was no reasoning and there can be none, it was a waste of time. It should also be noted that non-best-effort use of TAG is of my idea and it is really annoying that my idea in published papers is copied with very poor understanding on how and why the issues are solved. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Oct 28 21:41:15 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02526; Mon, 28 Oct 96 21:41:15 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02520; Mon, 28 Oct 96 21:41:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA24411; Mon, 28 Oct 1996 21:34:24 -0800 From: bound@zk3.dec.com Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA10350 for ; Mon, 28 Oct 1996 21:34:23 -0800 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id AAA06550; Tue, 29 Oct 1996 00:29:22 -0500 (EST) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16929; Tue, 29 Oct 1996 00:29:26 -0500 Message-Id: <9610290529.AA16929@wasted.zk3.dec.com> To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2400) Re: Mike's 8+8 In-Reply-To: Your message of "Tue, 29 Oct 96 13:27:39 +0200." <199610290427.NAA05588@necom830.hpcl.titech.ac.jp> Date: Tue, 29 Oct 96 00:29:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes your right about the Danvers meeting. We let this one sit around too long I think. I think your stating plagarism has taken place on both counts? You might want to take that offline with with the authors? If it was me I would and if it was true I would be upset too. Do you have patents in Japan? I don't particularly like them in the U.S. but this is the reason we do them here in some cases. But orginal ideas are key to any patent and architecture is very hard to prove was a sole original idea for addressing (and most architectures). For example the first 8+8 like idea I recall was Paul Francis's PIP in 1992 I think. It was not for addressing but routing but implied the same idea. Very tricky to prove the idea. This was also a major point of contention at the IPng Big Ten meeting (see RFC 1752) at an IPng Directorate meeting in Chicago June 1994 I think (off the top of my head). I think Mike has finally crystalized an 8+8 proposal that will work but more importantly can be implemented. But I am just one person and open to hear issues I may have missed in the draft. I bet though that if you worked with Mike or Fred they would listen to the input. It sounds like you agree with both principles architecturally? It would be good if we could get these two solved quickly it sounds like you have given this a lot of thought and if you would give details on where you think the specs specifically are in error it would be very useful to me and I am sure to others. I got customers that want IPv6 deployed and it is not going to happen unless we fix the addressing specs and they also want the IETF to figure out the use of flows and I think want L2 switching too. So I have a selfish reason to hear your input and I admit it. We need to get all the folks input on these a.s.a.p. Plus its going to affect the existing code base and specs somewhat and we should get that done too. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 00:55:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02705; Tue, 29 Oct 96 00:55:21 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02699; Tue, 29 Oct 96 00:55:09 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA07473; Tue, 29 Oct 1996 00:48:28 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA05538 for ; Tue, 29 Oct 1996 00:48:28 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA16096 for ; Tue, 29 Oct 1996 09:48:26 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA18432; Tue, 29 Oct 1996 09:48:26 +0100 Message-Id: <9610290848.AA18432@dxcoms.cern.ch> Subject: (IPng 2401) Re: fragmentation and translation To: ipng@sunroof.eng.sun.com Date: Tue, 29 Oct 1996 09:48:25 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199610242253.PAA17266@bobo.eng.sun.com> from "Erik Nordmark" at Oct 24, 96 03:53:18 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 Erik, > > So it seems like we need somebody to write down a short > spec on translators? > Why? Is there evidence of market demand for this? Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 01:30:32 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02723; Tue, 29 Oct 96 01:30:32 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02717; Tue, 29 Oct 96 01:30:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA09599; Tue, 29 Oct 1996 01:23:34 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA11902 for ; Tue, 29 Oct 1996 01:23:33 -0800 From: Masataka Ohta Message-Id: <199610290922.SAA05983@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id SAA05983; Tue, 29 Oct 1996 18:22:18 +0900 Subject: (IPng 2402) Masataka's 8+8 To: bound@zk3.dec.com Date: Tue, 29 Oct 96 18:22:17 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <9610290529.AA16929@wasted.zk3.dec.com>; from "bound@zk3.dec.com" at Oct 29, 96 12:29 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes your right about the Danvers meeting. We let this one sit around > too long I think. I have been waiting some real standard use more than 48 bit ID and IEEE 1394 is the one. Still, Mike says 45 bits... Sigh... > I think your stating plagarism has taken place on both counts? You > might want to take that offline with with the authors? As the proposals are so broken, I don't think it worth doing so. > If it was me > I would and if it was true I would be upset too. I rather upset with the poor modification on the idea. So, technically beating the proposal is enough for me. > But orginal > ideas are key to any patent and architecture is very hard to prove was > a sole original idea for addressing (and most architectures). It's not productive nor technical to claim originality over slightly modified proposals. So, can we concentrate on the technical points? Do you think we should solve site multihoming and site renumbering only, even though people want to remove warts from multicast, mobility and, in the future, want to support process migration? > For example the first 8+8 like idea I recall was Paul Francis's PIP in > 1992 I think. It was 2+2+2+... and I acknowledged PIP in my 8+8 draft of course. Am I polite enough? > I bet though that if you worked with Mike or Fred they would listen to > the input. Why do you think I work for them, even though I already worked for myself and produced a lot better solution? Even if I do, they, who designed the bad designs, can't understand the issues, which is what I have learned from my IETF experience. So, it's really a waste of time. > It sounds like you agree with both principles architecturally? No, because the slight modifications are architecturally fatal. Neither best effort IP switching nor best effort TAG switching scales, while I know how to scalablly switch best effort packets. Ethernet local MAC or ATM VPI/VCI is a lot more than enough for IP or TAG switching. IPv6 flow label has nothing to do with IP nor TAG switching. *ID MUST be topology independent. *ID MUST have hierarchy. > It would be good if we could get these two solved > quickly They are already solved. IPv6 WG ignore IP or TAG switching. Make *ID 64 bit long. Make *ID independent of any topology. Let *ID have hierarchy. Have 64 bit locator to locate a subnet. The only possible overloading is to use *ID as an intra-subnet, thus topology independent, locator. And, there are REASONS to do so. Moreover, we can still support 10**12 subnets and 10**15 hosts. > if you > would give details on where you think the specs specifically are in > error it would be very useful to me and I am sure to others. If you don't think my specs are not good enough, it would be very useful to me and I am sure to others if you would give details on where you think the specs specifically are in error. > So I have a > selfish reason to hear your input and I admit it. We need to get all > the folks input on these a.s.a.p. Strange. The solution has been available for more than a year. Why didn't you give any comment on it for such a long time? > Plus its going to affect the existing > code base and specs somewhat and we should get that done too. To your surprise, the modification is minimal to use the upper 64 bits of IPv6 address only for the forwarding decision of best effort packets beyond routers. For other purposes, including ND and forwarding of packets with flow label, lower 64 bits should be referenced. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 02:18:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02744; Tue, 29 Oct 96 02:18:17 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02738; Tue, 29 Oct 96 02:18:06 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA12190; Tue, 29 Oct 1996 02:11:24 -0800 Received: from rodan.UU.NET (rodan.UU.NET [153.39.130.10]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA18339 for ; Tue, 29 Oct 1996 02:11:24 -0800 Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQbnmu24611; Tue, 29 Oct 1996 05:08:44 -0500 (EST) Message-Id: To: Masataka Ohta Cc: bound@ZK3.DEC.COM, ipng@sunroof.eng.sun.com Subject: (IPng 2403) Re: Mike's 8+8 In-Reply-To: Your message of "Tue, 29 Oct 1996 13:27:39 +0200." <199610290427.NAA05588@necom830.hpcl.titech.ac.jp> Date: Tue, 29 Oct 1996 05:08:43 -0500 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ohtasan, Sorry you feel slighted. To my knowledge, this idea was first suggest by Dave Clark quite a while ago in the early 8/16 discussions and that's where *I* first heard it. I even have the email stored here somewhere... Yes, an ESD can encode Site-private topology if the Site desires. That's just fine. It has a cost and a benefit and that set of cost-benefit trade-offs is quite attractive to some Sites. Besides, the other IPv6 autoconfig/renumbering machinery makes the intra-Site system movement much easier. one important point of my proposal is that there are several places where considerable lattitude is included specifically because it is very, very difficult to make universal cost-benefit trade-offs in some of these cases. particularly in the case of Sites, they want a large amount of control, but that control isn't free in a global context. providing for explicit choices and autonomous decision making in a number of these cases is critical to acceptance. cheers, -mo ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 03:29:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02778; Tue, 29 Oct 96 03:29:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02772; Tue, 29 Oct 96 03:29:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA16209; Tue, 29 Oct 1996 03:22:56 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA27432 for ; Tue, 29 Oct 1996 03:22:57 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.7.6/8.7.3) with SMTP id EAA01887; Tue, 29 Oct 1996 04:22:56 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id EAA02442; Tue, 29 Oct 1996 04:22:55 -0700 Message-Id: <199610291122.EAA02442@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 29 Oct 1996 04:22:55 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: bound@zk3.dec.com, Richard Draves Subject: (IPng 2404) Re: advanced sockets api Cc: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Oct 28, 9:45pm you write:] > > >I think it's a nice capability, but still it seems strange to put lots > >of semantics into a raw socket. I don't know if this is a practical > >suggestion, but how about defining a new socket type, SOCK_CONTROL, and > >using AF_INET6/SOCK_CONTROL/IPPROTO_ICMPV6 to get a socket that would > >have the semantics that you want for ICMPv6 sockets? I don't see the point. Perhaps the term "raw" is what's confusing. Look at the existing implemetations. A raw socket of protocol type ICMPv4 or IGMPv4 is not 100% raw. The kernel processes everything in the packet and gives a copy to user processes when it's done. Most programs find that completely adequate: ping, traceroute, routed, mrouted, etc. These programs don't want to build their own IPv4 header, and are happy to let the kernel add it in for them. If you don't like that, then set the IP_HDRINCL socket option and build your own IPv4 header: you can even build your own UDP and TCP packets this way (I've done both). If the kernel doesn't handle the protocol type (e.g., OSPF) then the kernel does nothing with the packet and it's up to the implementation to do what they want with it. Perhaps that's what you're thinking of as a "raw" socket. You still have your choice of letting the kernel build the IPv4 header or not. And if none of the above do exactly what you want, you can use a datalink tape (BPF or DLPI, for example) and read and write your own datalink frames (I've done this before too, for diagnostic programs, when even a raw socket doesn't do exactly what I need). All the new I-D does is carry this concept into IPv6. It doesn't prevent any of what I described. It does specify that the kernel computes and stores the ICMPv6 header checksum by default, because with the pseudo header now part of the computation, this will simplify things for 99% of the ICMPv6 applications (of which we expect more with IPv6 than with IPv4). And it does specify a trivial amount of filtering by the kernel based on the ICMPv6 type field, which should help, performance-wise, by reducing the kernel-to-process copies with the expected range of ICMPv6 applications. We did not specify an equivalent to the IP_HDRINCL socket option, as with IPv6 there is now application access to every one of the IPv6 header fields (which isn't the case with IPv4), so we didn't see the purpose. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 04:41:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02806; Tue, 29 Oct 96 04:41:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02800; Tue, 29 Oct 96 04:41:40 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA21748; Tue, 29 Oct 1996 04:34:57 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA08880 for ; Tue, 29 Oct 1996 04:34:45 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id NAA14367 for ; Tue, 29 Oct 1996 13:34:44 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA26031; Tue, 29 Oct 1996 13:34:44 +0100 Message-Id: <9610291234.AA26031@dxcoms.cern.ch> Subject: (IPng 2405) Re: Mike's 8+8 To: ipng@sunroof.eng.sun.com Date: Tue, 29 Oct 1996 13:34:43 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: from "Mike O'Dell" at Oct 29, 96 05:08:43 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, > Yes, an ESD can encode Site-private topology if the Site desires. The "temporal uniqueness" needed for an identifier (as discussed in draft-iab-ip-ad-today-01.txt) must cover the longest relevant duration of a transport or security binding. What your proposal implies, therefore, is that if a site encodes topology in its ESDs, and if the topology is changed then current bindings will see a change of ESD. We need to think whether we want to live with this (i.e. accept that on-site topology changes at such sites kill bindings) or fix it. Remember that here we are *only* talking about voluntary topology changes made by the site concerned. Topology changes made by Big Bad ISPs are inside the routing gloop and do not affect ESDs. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 05:09:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02823; Tue, 29 Oct 96 05:09:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02817; Tue, 29 Oct 96 05:09:35 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA24694; Tue, 29 Oct 1996 05:02:53 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id FAA16107 for ; Tue, 29 Oct 1996 05:02:51 -0800 From: Masataka Ohta Message-Id: <199610291301.WAA06453@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA06453; Tue, 29 Oct 1996 22:01:38 +0900 Subject: (IPng 2406) Re: Mike's 8+8 To: mo@UU.NET (Mike O'Dell) Date: Tue, 29 Oct 96 22:01:37 JST Cc: mohta@necom830.hpcl.titech.ac.jp, bound@ZK3.DEC.COM, ipng@sunroof.eng.sun.com In-Reply-To: ; from "Mike O'Dell" at Oct 29, 96 5:08 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike; > To my knowledge, this idea was first suggest by Dave Clark quite a > while ago in the early 8/16 discussions and that's where *I* first > heard it. I even have the email stored here somewhere... The question is who is first to publicly suggest the idea. I also remember Dave Clark mentioned it in big I list after my proposal. > Yes, an ESD can encode Site-private topology if the Site desires. "if the Site desires."? When the alternative is to live with a single subnet, how can you say the Site does not desire to do so? > That's just fine. It has a cost and a benefit and that set > of cost-benefit trade-offs is quite attractive to some Sites. Whether we can remove problems and/or warts of mobility, multicast and process migration is not a site local issue. That is, *ID must be topology independent all over the Internet. > Besides, the other IPv6 autoconfig/renumbering machinery makes > the intra-Site system movement much easier. As long as *ID is invariant, yes, which is not the case of your proposal. > one important point of my proposal is that there are several places > where considerable lattitude is included specifically because it > is very, very difficult to make universal cost-benefit trade-offs > in some of these cases. No, that's not your point. That's simply a basic property of herarchically delegated addressing. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 05:48:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02861; Tue, 29 Oct 96 05:48:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02855; Tue, 29 Oct 96 05:48:42 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA28647; Tue, 29 Oct 1996 05:41:59 -0800 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA23493 for ; Tue, 29 Oct 1996 05:42:00 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id IAA11094; Tue, 29 Oct 1996 08:41:44 -0500 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/10-26-96) with SMTP id IAA135381; Tue, 29 Oct 1996 08:41:32 -0500 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA17934; Tue, 29 Oct 1996 08:41:31 -0500 From: Charlie Perkins Message-Id: <9610291341.AA17934@hawpub1.watson.ibm.com> To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com, dbj@cs.cmu.edu Subject: (IPng 2407) Re: Mike's 8+8 In-Reply-To: Your message of Tue, 29 Oct 96 12:10:58 O. <199610290311.MAA05193@necom830.hpcl.titech.ac.jp> Date: Tue, 29 Oct 96 08:41:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As you might remember, a mobility problem was discussed in IPv6 > mobility BOF at Stockholm, where you insisted on using your > proposal for IPv4. This statement needs, at minimum, enlargement. At one time, I made _two_ proposals to the IPv6 group concerning mobility. One was a translation of the IPv4 document into IPv6 language. The other was the forerunner of our current document (co-authored with Dave Johnson). I wanted to find out which direction would be preferred by the working groups in question (IPv6 and mobile-IP). The proposal using the Binding Update destination option is the one I'm currently laboring over and hoping to move towards standardization in the near future. A revised protocol document is due soon (due already, in fact). Your characterization that I "insisted on using proposal for IPv4" neglects the fact that there are so many substantial differences between the two that many people would find it difficult to identify them as similar, architecturally. Of course, there are important similarities, among them the existence of a home agent and the use of a home address. I hope in the near future to collaborate in offering a modification to the Binding Update which will go a long way towards enabling the use of anycast and long-lived connections which can be maintained even in the face of renumbering networks. I believe that the existing Binding Update already answers many of the needs for multihomed hosts. Regards, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 05:59:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02873; Tue, 29 Oct 96 05:59:01 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02867; Tue, 29 Oct 96 05:58:45 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA29801; Tue, 29 Oct 1996 05:52:01 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id FAA25678 for ; Tue, 29 Oct 1996 05:52:02 -0800 From: Masataka Ohta Message-Id: <199610291350.WAA06582@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA06582; Tue, 29 Oct 1996 22:50:37 +0900 Subject: (IPng 2408) Re: Mike's 8+8 To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Tue, 29 Oct 96 22:50:35 JST Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9610291234.AA26031@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Oct 29, 96 1:34 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; > Remember that here we are *only* talking about voluntary topology > changes made by the site concerned. Topology changes made by > Big Bad ISPs are inside the routing gloop and do not affect ESDs. When you move within or outof the site, don't you think it good if a foreign agent just rewrite the locator part of packets and not to tunnel? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 06:41:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02929; Tue, 29 Oct 96 06:41:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02923; Tue, 29 Oct 96 06:41:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA04832; Tue, 29 Oct 1996 06:34:55 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA06524 for ; Tue, 29 Oct 1996 06:34:54 -0800 From: Masataka Ohta Message-Id: <199610291434.XAA06775@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA06775; Tue, 29 Oct 1996 23:33:45 +0859 Subject: (IPng 2409) Re: Mike's 8+8 To: mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Tue, 29 Oct 96 23:33:43 JST Cc: brian@dxcoms.cern.ch, ipng@sunroof.eng.sun.com In-Reply-To: <199610291350.WAA06582@necom830.hpcl.titech.ac.jp>; from "Masataka Ohta" at Oct 29, 96 10:50 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian; > > > Remember that here we are *only* talking about voluntary topology > > changes made by the site concerned. Topology changes made by > > Big Bad ISPs are inside the routing gloop and do not affect ESDs. > > When you move within or outof the site, don't you think it good if > a foreign agent just rewrite the locator part of packets and not ^^^^^^^ > to tunnel? Sorry, just a mistake. It's home, not foreign, agent which can rewrite the locator. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 07:57:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02987; Tue, 29 Oct 96 07:57:51 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02981; Tue, 29 Oct 96 07:57:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA14643; Tue, 29 Oct 1996 07:50:57 -0800 Received: from dxmint.cern.ch (dxmint.cern.ch [137.138.26.76]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA29672 for ; Tue, 29 Oct 1996 07:50:54 -0800 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id QAA10605 for ; Tue, 29 Oct 1996 16:50:52 +0100 (MET) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA00727; Tue, 29 Oct 1996 16:50:51 +0100 Message-Id: <9610291550.AA00727@dxcoms.cern.ch> Subject: (IPng 2410) Re: Mike's 8+8 To: ipng@sunroof.eng.sun.com Date: Tue, 29 Oct 1996 16:50:51 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <199610291434.XAA06775@necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Oct 29, 96 11:33:43 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 Masataka, I can't parse this even with the correction. Can you explain in more detail please? Brian >--------- Text sent by Masataka Ohta follows: > > > Brian; > > > > > Remember that here we are *only* talking about voluntary topology > > > changes made by the site concerned. Topology changes made by > > > Big Bad ISPs are inside the routing gloop and do not affect ESDs. > > > > When you move within or outof the site, don't you think it good if > > a foreign agent just rewrite the locator part of packets and not > ^^^^^^^ > > to tunnel? > > Sorry, just a mistake. It's home, not foreign, agent which can rewrite > the locator. > > Masataka Ohta > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Oct 29 18:52:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03516; Tue, 29 Oct 96 18:52:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03510; Tue, 29 Oct 96 18:52:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA09525; Tue, 29 Oct 1996 18:45:37 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA17769 for ; Tue, 29 Oct 1996 18:45:35 -0800 From: Masataka Ohta Message-Id: <199610300244.LAA07817@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA07817; Wed, 30 Oct 1996 11:44:08 +0900 Subject: (IPng 2411) Warts with topology dependent ID To: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Date: Wed, 30 Oct 96 11:44:08 JST Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian; > > > When you move within or outof the site, don't you think it good if ! > > a home agent just rewrite the locator part of packets and not > > > to tunnel? > I can't parse this even with the correction. Can you explain > in more detail please? Sure. If a home agent can rewrite the locator part of the destination address of a packet to mobile host WITHOUT AFFECTING the *ID part, no special treatment, such as tunneling or mandatory addition of a routing header, is necessary. I personally communicated with Charlie and now know that his second proposal at Stockholm is to use a routing header. Yes, the encapsulation method is a quite serious issue of mobility. Note that, locator part shouldn't be protected by psuedo header check sum of TCP nor authentication header of IPSEC and it's still secure becasue the only possible attack of intermediate routers (including home agent) modifying the locator is just a denial of service and the routers can always deny service by simply not forwarding packets. BTW, topology independent *ID in IPv6 address is also good to retain regular subnet model even for the communication between a foreign agent and the mobile host. Kre, are these the warts you want to remove? Finally, though the statement might activate an automatic SPAM detector :-), it's absolutely free! We only have to convince people (if any) who, IMO unfoundedly, think 64 bits are not enough to locate a subnet. Are there any? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 09:17:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03828; Wed, 30 Oct 96 09:17:40 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03822; Wed, 30 Oct 96 09:17:29 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26560; Wed, 30 Oct 1996 09:10:42 -0800 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA10062 for ; Wed, 30 Oct 1996 09:10:21 -0800 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA02588; Wed, 30 Oct 96 12:04:04 EST Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id MAA11645; Wed, 30 Oct 1996 12:12:36 -0500 Date: Wed, 30 Oct 1996 12:12:36 -0500 Message-Id: <199610301712.MAA11645@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: ipng@sunroof.eng.sun.com Subject: (IPng 2412) Concerns and questions on the advanced API draft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I think the draft looks pretty good to me, just a few minor concerns. Which I hope get sorted soon so that I can get my implementation going. Following are my concerns regarding this draft. 1) Regarding passing a source route: The draft spedifies that connect, sendto etc syscalls will specify the 1st hop rather than the final dest. And the routing header passed as ancillary data will have 2nd to final dests. Doesn't this change the semantics of the calls. I think when you say connect, you mean connect to the final dest., not to 1st hop. 2) Regarding receiving ancillary data on TCP socket via getsockopt : Since ancillary data is received with every packet, while TCP is a byte stream oriented protocol, do you intend that all the recieved options in all previous packets be stored in the kernel, or just options from the last packet. 3) Regarding passing a hop-by-hop or dest. option : Currently the way the option is passed using the cmsghdr structure, there is no way one can pass an option which is not yet a standard, and hence recoginized in the kernel. The problem comes from the the absence of the option length field in the cmsghdr structure. The cmsg_len field cannot be used for this purpose. 4) Regarding 8 byte alignment problem in a cmsghsr structure. The cmsghdr structure's defination forces that data portion of the option begins at 4 byte boundary, which implies that one can't typecast 8 byte types in this data area. Since some v6 options which will have IPv6 addresses are likely to be defined with 8 byte alignment in mind. Instead we can define that all options be passed in the cmsghdr structure as the current suggestion, but leave the next 4 byte as pad, then put an option which is 8 byte aligned as a full tlv option. Or a better thing might be to define a function to add header options in a cmsghdr area, which can be implementation dependent. 5) I would still prefer that we have an IP_HDRINCL option, so that user appl. can have control over the checksum if it desires so. Also this helps us avoid all the setsockopt calls to set all the fields in the basic header. Regards, Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 09:40:31 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03862; Wed, 30 Oct 96 09:40:31 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03856; Wed, 30 Oct 96 09:40:20 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA00958; Wed, 30 Oct 1996 09:33:33 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA17882 for ; Wed, 30 Oct 1996 09:33:01 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id RAA03218; Wed, 30 Oct 1996 17:32:22 GMT Message-Id: <199610301732.RAA03218@inner.net> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2413) Re: Concerns and questions on the advanced API draft In-Reply-To: Your message of "Wed, 30 Oct 1996 12:12:36 EST." <199610301712.MAA11645@sparky.IOL.UNH.EDU> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Wed, 30 Oct 1996 12:32:20 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199610301712.MAA11645@sparky.IOL.UNH.EDU>, you write: >1) Regarding passing a source route: > The draft spedifies that connect, sendto etc syscalls will specify > the 1st hop rather than the final dest. And the routing header > passed as ancillary data will have 2nd to final dests. > > Doesn't this change the semantics of the calls. I think when you > say connect, you mean connect to the final dest., not to 1st hop. To some extent it doesn't matter since you can always extract the final hop address. For some things like IPsec that operate end-to-end and therefore need to know the final destination, it would probably tend to be less complex to implement if the parameter of sendto() et al. were the final destination and not the next hop. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 11:01:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03951; Wed, 30 Oct 96 11:01:20 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03945; Wed, 30 Oct 96 11:01:04 PST Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20286; Wed, 30 Oct 1996 10:54:18 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA06383; Wed, 30 Oct 1996 10:54:15 -0800 Date: Wed, 30 Oct 1996 10:54:15 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199610301854.KAA06383@bobo.eng.sun.com> To: brian@dxcoms.cern.ch Subject: (IPng 2414) Re: fragmentation and translation 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 > > > > So it seems like we need somebody to write down a short > > spec on translators? > > > > Why? Is there evidence of market demand for this? The primary purpose (in my opinion) is that every N months somebody new comes around and asks "how does XXX work with translators". Then we end up rehashing some old discussion on how translators could work. It would be nice it we could say "go read the draft" instead of wasting time on repeating things. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 14:08:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04114; Wed, 30 Oct 96 14:08:28 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04108; Wed, 30 Oct 96 14:08:17 PST Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02728; Wed, 30 Oct 1996 14:01:23 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA04580 for ; Wed, 30 Oct 1996 14:01:18 -0800 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA09502; Wed, 30 Oct 1996 16:52:46 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA12542; Wed, 30 Oct 1996 16:52:49 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id RAA01243; Wed, 30 Oct 1996 17:59:30 GMT Message-Id: <199610301759.RAA01243@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com, rstevens@kohala.com Subject: (IPng 2415) Re: Concerns and questions on the advanced API draft In-Reply-To: Your message of "Wed, 30 Oct 1996 12:12:36 EST." <199610301712.MAA11645@sparky.IOL.UNH.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Oct 1996 17:59:27 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) Regarding passing a source route: > The draft spedifies that connect, sendto etc syscalls will specify > the 1st hop rather than the final dest. And the routing header > passed as ancillary data will have 2nd to final dests. That isn't what I intended. The source route should only have the intermediate hops, not the final hop. > 2) Regarding receiving ancillary data on TCP socket via getsockopt : > Since ancillary data is received with every packet, while > TCP is a byte stream oriented protocol, do you intend that all > the recieved options in all previous packets be stored in the > kernel, or just options from the last packet. Just from the last packet. > 3) Regarding passing a hop-by-hop or dest. option : > Currently the way the option is passed using the cmsghdr structure, > there is no way one can pass an option which is not yet a standard, > and hence recoginized in the kernel. The problem comes from the > the absence of the option length field in the cmsghdr structure. > The cmsg_len field cannot be used for this purpose. The cmsg_len is the option length. Please explain why you think it cannot be used for that purpose. > 4) Regarding 8 byte alignment problem in a cmsghsr structure. > The cmsghdr structure's defination forces that data portion of the > option begins at 4 byte boundary, which implies that one can't > typecast 8 byte types in this data area. Since some v6 options > which will have IPv6 addresses are likely to be defined with 8 byte > alignment in mind. size_t on most 64LP implementations is a long and since the cmsghdr field cmsg_len is of type size_t, this will force the cmsghdr structure to be aligned on an alignment that will satisfy size_t. > Instead we can define that all options be passed in the cmsghdr > structure as the current suggestion, but leave the next 4 byte as > pad, then put an option which is 8 byte aligned as a full tlv > option. I don't see a need for this given what I said above. > Or a better thing might be to define a function to add header > options in a cmsghdr area, which can be implementation dependent. That's an option but I don't think it's needed. > 5) I would still prefer that we have an IP_HDRINCL option, so that > user appl. can have control over the checksum if it desires so. > Also this helps us avoid all the setsockopt calls to set all the > fields in the basic header. There's not much in the header right now. The payload length from the amount of data passed in via sendxxx(), the next header comes from the protocol passed to the socket() call, the hop limit comes from either IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS, and the destination address and flow label comes from the supplied sockaddr_in6. The source address is selected by the system, taken from the bind() or from the IPV6_TXINFO ancillary data. That means that all fields of the headers are fully specified by existing methods. Concerning checksums, other than for testing why would an application want to send a packet with an invalid checksum? As a developer, you can always make IPV6_CHECKSUM with a -1 indicate that no checksum is generated (or any other hack you need). But why does an application programmer need that? I don't think the scope of the advanced API should cover the needs of IPv6 stack developers to test their implementation. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 14:17:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04136; Wed, 30 Oct 96 14:17:01 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04120; Wed, 30 Oct 96 14:13:37 PST Received: from audeen.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA00472; Wed, 30 Oct 1996 14:06:52 -0800 Received: by audeen.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01659; Wed, 30 Oct 1996 14:06:48 -0800 Date: Wed, 30 Oct 1996 14:06:48 -0800 From: carlw@jurassic (Carl Williams) Message-Id: <199610302206.OAA01659@audeen.eng.sun.com> To: rstevens@kohala.com Subject: (IPng 2416) advanced sockets api for ipv6 (rcmd's) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, Remote Command Execution requires the need for two new api's rcmd6() and rresvport6(). Could the advanced api spec be extended in scope to define these two api's. Carl ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 14:31:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04157; Wed, 30 Oct 96 14:31:47 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04151; Wed, 30 Oct 96 14:31:36 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA09054; Wed, 30 Oct 1996 14:24:43 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA23207; Wed, 30 Oct 1996 14:24:00 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.2/8.7.3) with SMTP id PAA04696; Wed, 30 Oct 1996 15:22:05 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id PAA15755; Wed, 30 Oct 1996 15:22:05 -0700 Message-Id: <199610302222.PAA15755@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 30 Oct 1996 15:22:04 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: carl.williams@Eng (Carl Williams) Subject: (IPng 2417) Re: advanced sockets api for ipv6 (rcmd's) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Oct 30, 2:06pm you write:] > > Remote Command Execution requires the need for two new api's > rcmd6() and rresvport6(). > > Could the advanced api spec be extended in scope to define > these two api's. Sure, but we're also about to release a new version of the basic API . Shouldn't they go into the basic? Also, looking at rcmd(), I can't see the need for an IPv6 version of it, since it's triggered off a hostname, and not a binary address. That means that all of the resolver code that's in BIND-4.9.4 (and documented in the -06 draft mentioned above) should determine whether to create an IPv4/IPv6 socket. That is, if the host only has an A record, an IPv4 socket is created. If it also has an AAAA record, then the resolver rules and options determine which type of socket is created. All that's returned is a socket descriptor. rcmd() should be coded to use getaddrinfo() and then it'll work with IPv4 and IPv6. We do need an IPv6 version of rresvport(), however. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 14:42:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04177; Wed, 30 Oct 96 14:42:40 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04171; Wed, 30 Oct 96 14:42:24 PST Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04265; Wed, 30 Oct 1996 14:35:39 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA07414; Wed, 30 Oct 1996 14:35:37 -0800 Date: Wed, 30 Oct 1996 14:35:37 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199610302235.OAA07414@bobo.eng.sun.com> To: rstevens@kohala.com Subject: (IPng 2418) Re: advanced sockets api for ipv6 (rcmd's) 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 > Sure, but we're also about to release a new version of the basic API > . Shouldn't they go into the basic? Yes, assuming the issue isn't contentious. > Also, looking at rcmd(), I can't see the need for an IPv6 version of > it, since it's triggered off a hostname, and not a binary address. Isn't there a problem if a v6 unaware application calls rcmd() and rcmd() returns an AF_INET6 socket? If that application then calls getsockname or getpeername it would be "surprised" by the AF_INET6 address being returned. Thus the logical rcmd functionality needs to know what type of socket to create. Having a separate rcmd6() solves that problem. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 14:52:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04196; Wed, 30 Oct 96 14:52:11 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04190; Wed, 30 Oct 96 14:52:00 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA14297; Wed, 30 Oct 1996 14:45:13 -0800 Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA29720 for ; Wed, 30 Oct 1996 14:44:51 -0800 Received: from sparky.IOL.UNH.EDU by iol.unh.edu (4.1/SMI-4.1) id AA05594; Wed, 30 Oct 96 17:38:26 EST Received: by sparky.IOL.UNH.EDU (SMI-8.6/SMI-SVR4) id RAA11930; Wed, 30 Oct 1996 17:46:18 -0500 Date: Wed, 30 Oct 1996 17:46:18 -0500 Message-Id: <199610302246.RAA11930@sparky.IOL.UNH.EDU> From: Quaizar Vohra To: Matt Thomas Cc: Quaizar Vohra , ipng@sunroof.eng.sun.com, rstevens@kohala.com Subject: (IPng 2419) Re: Concerns and questions on the advanced API draft In-Reply-To: <199610301759.RAA01243@whydos.lkg.dec.com> References: <199610301712.MAA11645@sparky.IOL.UNH.EDU> <199610301759.RAA01243@whydos.lkg.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Matt, > > > 1) Regarding passing a source route: > > The draft spedifies that connect, sendto etc syscalls will specify > > the 1st hop rather than the final dest. And the routing header > > passed as ancillary data will have 2nd to final dests. > > That isn't what I intended. The source route should only have the > intermediate hops, not the final hop. Just check page 25 paragraph 1 of the draft. > > > 2) Regarding receiving ancillary data on TCP socket via getsockopt : > > Since ancillary data is received with every packet, while > > TCP is a byte stream oriented protocol, do you intend that all > > the recieved options in all previous packets be stored in the > > kernel, or just options from the last packet. > > Just from the last packet. Good. > > > 3) Regarding passing a hop-by-hop or dest. option : > > Currently the way the option is passed using the cmsghdr structure, > > there is no way one can pass an option which is not yet a standard, > > and hence recoginized in the kernel. The problem comes from the > > the absence of the option length field in the cmsghdr structure. > > The cmsg_len field cannot be used for this purpose. > > The cmsg_len is the option length. Please explain why you think it > cannot be used for that purpose. Here I am assuming that one might want to add padding at the end of the option, if the option data is not 4/8 byte muliple. So that next cmsg_hdr can be 4 or 8 byte aligned. So this means that cmsg_len includes the length of the padding too. I concede that if such an option is not designed then this won't be a problem. But I don't think this is guaranteed. > > 4) Regarding 8 byte alignment problem in a cmsghsr structure. > > The cmsghdr structure's defination forces that data portion of the > > option begins at 4 byte boundary, which implies that one can't > > typecast 8 byte types in this data area. Since some v6 options > > which will have IPv6 addresses are likely to be defined with 8 byte > > alignment in mind. > > size_t on most 64LP implementations is a long and since the cmsghdr field > cmsg_len is of type size_t, this will force the cmsghdr structure to be > aligned on an alignment that will satisfy size_t. Yes, but unfortunately NetBSD/alpha uses u_int instead of size_t for cmsg_len. > > > Instead we can define that all options be passed in the cmsghdr > > structure as the current suggestion, but leave the next 4 byte as > > pad, then put an option which is 8 byte aligned as a full tlv > > option. > > I don't see a need for this given what I said above. > > > Or a better thing might be to define a function to add header > > options in a cmsghdr area, which can be implementation dependent. > > That's an option but I don't think it's needed. I think this option will allow implementations to comply with the new draft with minimal changes, i.e. they won't have to change the cmsghdr structure etc., as in my case. > > > 5) I would still prefer that we have an IP_HDRINCL option, so that > > user appl. can have control over the checksum if it desires so. > > Also this helps us avoid all the setsockopt calls to set all the > > fields in the basic header. > > There's not much in the header right now. The payload length from the > amount of data passed in via sendxxx(), the next header comes from the > protocol passed to the socket() call, the hop limit comes from either > IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS, and the destination address > and flow label comes from the supplied sockaddr_in6. The source address > is selected by the system, taken from the bind() or from the IPV6_TXINFO > ancillary data. That means that all fields of the headers are fully > specified by existing methods. > > Concerning checksums, other than for testing why would an application want > to send a packet with an invalid checksum? As a developer, you can always > make IPV6_CHECKSUM with a -1 indicate that no checksum is generated (or any > other hack you need). But why does an application programmer need that? > > I don't think the scope of the advanced API should cover the needs of > IPv6 stack developers to test their implementation. Well I did not mean this. But think if an implementation needs more control of the source address, and doesn't want kernel to select one for it. Then it will have to call bind everytime. Also you will have to make extra calls to setsockopt in case you want to set hop limit etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 15:03:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04216; Wed, 30 Oct 96 15:03:16 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04210; Wed, 30 Oct 96 15:03:05 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA17098; Wed, 30 Oct 1996 14:56:15 -0800 Received: from inner.net (avarice.inner.net [198.82.204.99]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA03002; Wed, 30 Oct 1996 14:56:10 -0800 Received: from inner.net (lust.inner.net [199.33.248.1]) by inner.net (8.8.2/42) with ESMTP id WAA03596; Wed, 30 Oct 1996 22:56:02 GMT Message-Id: <199610302256.WAA03596@inner.net> To: erik.nordmark@Eng (Erik Nordmark) Cc: rstevens@kohala.com, ipng@sunroof.eng.sun.com Subject: (IPng 2420) Re: advanced sockets api for ipv6 (rcmd's) In-Reply-To: Your message of "Wed, 30 Oct 1996 14:35:37 PST." <199610302235.OAA07414@bobo.eng.sun.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Wed, 30 Oct 1996 17:56:01 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199610302235.OAA07414@bobo.eng.sun.com>, you write: >> Sure, but we're also about to release a new version of the basic API >> . Shouldn't they go into the basic? > >Yes, assuming the issue isn't contentious. I believe that putting them into the basic spec is not a good idea. The basic API is moving toward being the minimal subset of API changes needed to support most IPv6 applications. Not very many programs use rcmd(). The advanced API spec contains things that are needed for some applications but not critical to the use of IPv6; if rcmd() belongs anywhere, it's there IMO. >Thus the logical rcmd functionality needs to know what type of socket >to create. Having a separate rcmd6() solves that problem. Another solution is to seriously rethink the whole rcmd() interface. It has created lots of problems and it remains unclear to me that it does anything that can't be done better other ways. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 15:12:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04231; Wed, 30 Oct 96 15:12:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04225; Wed, 30 Oct 96 15:11:51 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA18702; Wed, 30 Oct 1996 15:04:21 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA04944; Wed, 30 Oct 1996 15:02:41 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.2/8.7.3) with SMTP id QAA04752; Wed, 30 Oct 1996 16:02:18 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id QAA15835; Wed, 30 Oct 1996 16:02:17 -0700 Message-Id: <199610302302.QAA15835@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 30 Oct 1996 16:02:17 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: erik.nordmark@Eng (Erik Nordmark) Subject: (IPng 2421) Re: advanced sockets api for ipv6 (rcmd's) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Oct 30, 2:35pm you write:] > > > Also, looking at rcmd(), I can't see the need for an IPv6 version of > > it, since it's triggered off a hostname, and not a binary address. > > Isn't there a problem if a v6 unaware application calls > rcmd() and rcmd() returns an AF_INET6 socket? Assuming that the IPv4 application calls gethostbyname() (which is what getaddrinfo() should be calling), all that is queried for in the DNS is an A record. This was done on purpose for 100% backward compatability with all existing IPv4-only applications. Even if the specified hostname has both an A record and an AAAA record, all that gethostbyname() will return by default is the A record. The only way to get back an IPv6 address is for (a) the application to set the resolver RES_USE_INET6 option, (b) set the environment variable RES_OPTIONS to inet6, or (c) for the sysadmin to set "options inet6" in /etc/resolv.conf (and there is a big warning not to do this until *every* application on the host is IPv6-aware). [These three rules are in the -06 basic API that will be out shortly.] Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 15:34:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04270; Wed, 30 Oct 96 15:34:56 PST Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04264; Wed, 30 Oct 96 15:34:40 PST Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA11331; Wed, 30 Oct 1996 15:27:54 -0800 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA07446; Wed, 30 Oct 1996 15:27:52 -0800 Date: Wed, 30 Oct 1996 15:27:52 -0800 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199610302327.PAA07446@bobo.eng.sun.com> To: rstevens@kohala.com Subject: (IPng 2422) Re: advanced sockets api for ipv6 (rcmd's) 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 > > Isn't there a problem if a v6 unaware application calls > > rcmd() and rcmd() returns an AF_INET6 socket? > > Assuming that the IPv4 application calls gethostbyname() (which is what > getaddrinfo() should be calling), all that is queried for in the DNS > is an A record. This was done on purpose for 100% backward compatability > with all existing IPv4-only applications. Even if the specified hostname > has both an A record and an AAAA record, all that gethostbyname() will > return by default is the A record. But with rcmd the application doesn't call gethostbyname. rcmd encapsulates both the creation of the socket *and* the IP address lookup. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 15:53:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04292; Wed, 30 Oct 96 15:53:50 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04286; Wed, 30 Oct 96 15:53:39 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA29028; Wed, 30 Oct 1996 15:46:52 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA17550; Wed, 30 Oct 1996 15:46:07 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.2/8.7.3) with SMTP id QAA04796; Wed, 30 Oct 1996 16:45:40 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id QAA15960; Wed, 30 Oct 1996 16:45:39 -0700 Message-Id: <199610302345.QAA15960@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 30 Oct 1996 16:45:39 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: erik.nordmark@Eng (Erik Nordmark) Subject: (IPng 2423) Re: advanced sockets api for ipv6 (rcmd's) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Oct 30, 3:27pm you write:] > > But with rcmd the application doesn't call gethostbyname. The application doesn't, but rcmd() does. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 16:18:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04409; Wed, 30 Oct 96 16:18:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04403; Wed, 30 Oct 96 16:17:53 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA04541; Wed, 30 Oct 1996 16:11:05 -0800 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA24488; Wed, 30 Oct 1996 16:10:17 -0800 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.2/8.7.3) with SMTP id RAA04810; Wed, 30 Oct 1996 17:09:45 -0700 (MST) Received: by kohala.kohala.com (SMI-8.6/SMI-SVR4) id RAA16007; Wed, 30 Oct 1996 17:09:44 -0700 Message-Id: <199610310009.RAA16007@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 30 Oct 1996 17:09:44 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: erik.nordmark@Eng (Erik Nordmark) Subject: (IPng 2424) Re: advanced sockets api for ipv6 (rcmd's) Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of Oct 30, 4:45pm you write:] > But with rcmd the application doesn't call gethostbyname. I'll be more specific, after looking at the source code for rcmd(). Let it still call gethostbyname(). Define a new function rresvport_af(int *, int) [instead of rresvport6()] that takes an address family as the second argument. (Given that gethostbyname() and getaddrinfo() both return an address family to the caller, I'll always opt for a new function that takes an address family as an argument, instead of something that only works with IPv6.) But pass hp->h_addrtype as the second argument to rresvport_af() and you then have an rcmd() that works with both IPv4 and IPv6. There are a few other places in the code that need fixing, for example some inet_ntoa() that should be inet_ntop(), but the bottom line is that I don't think we need an rcmd6() function. I see some other IPv4-specific pieces of code that need to be changed: for example, the function diddles with the port number in the socket address structure (sin_port). I've written some simple functions, sock_getport() and sock_setport(), that work with socket address structures and hide all the differences between sin_port and sin6_port, and I've found these make writing portable applicatons much easier (portable between IPv4 and IPv6, that is). Rich Stevens p.s. -- Much to my surprise I just did a "man rresvport" to verify that the pointer argument is an "int *" and not something else, and guess what, you've already defined rcmd6() and rresvport6()! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Oct 30 16:35:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04437; Wed, 30 Oct 96 16:35:58 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04431; Wed, 30 Oct 96 16:35:46 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA07791; Wed, 30 Oct 1996 16:28:58 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA29117 for ; Wed, 30 Oct 1996 16:28:30 -0800 Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id TAA03062; Wed, 30 Oct 1996 19:21:13 -0500 (EST) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA13462; Wed, 30 Oct 1996 19:21:13 -0500 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id UAA02561; Wed, 30 Oct 1996 20:27:54 GMT Message-Id: <199610302027.UAA02561@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com, rstevens@kohala.com Subject: (IPng 2425) Re: Concerns and questions on the advanced API draft In-Reply-To: Your message of "Wed, 30 Oct 1996 17:46:18 EST." <199610302246.RAA11930@sparky.IOL.UNH.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 30 Oct 1996 20:27:53 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Here I am assuming that one might want to add padding at the end > of the option, if the option data is not 4/8 byte muliple. So that next > cmsg_hdr can be 4 or 8 byte aligned. So this means that cmsg_len > includes the length of the padding too. The option processing in the kernel will do that automagically since it can determine the alignment of the option from its length. > I concede that if such an option is not designed then this won't be a > problem. But I don't think this is guaranteed. All options must be defined such that the "stuff" inside must be order from those the most strict alignment requirements to those with the least. > > size_t on most 64LP implementations is a long and since the cmsghdr field > > cmsg_len is of type size_t, this will force the cmsghdr structure to be > > aligned on an alignment that will satisfy size_t. > > Yes, but unfortunately NetBSD/alpha uses u_int instead of size_t for > cmsg_len. Digital UNIX currently has the problem however I felt that the right thing to do is use the POSIX definitions. At least until NetBSD fixes the definition, you have the option of recompiling the kernel with the right definition. > > > > > Instead we can define that all options be passed in the cmsghdr > > > structure as the current suggestion, but leave the next 4 byte as > > > pad, then put an option which is 8 byte aligned as a full tlv > > > option. > > > > I don't see a need for this given what I said above. > > > > > Or a better thing might be to define a function to add header > > > options in a cmsghdr area, which can be implementation dependent. > > > > That's an option but I don't think it's needed. > > I think this option will allow implementations to comply with the > new draft with minimal changes, i.e. they won't have to change the > cmsghdr structure etc., as in my case. While I "feel your pain", I don't think it is the right solution. It adds a level of complexity which is not needed if the O/S is POSIX compliant (and most are heading that way if not already there). > > I don't think the scope of the advanced API should cover the needs of > > IPv6 stack developers to test their implementation. > > Well I did not mean this. But think if an implementation needs > more control of the source address, and doesn't want kernel to > select one for it. Then it will have to call bind everytime. Also > you will have to make extra calls to setsockopt in case you want > to set hop limit etc. It does not have to bind, it should use IPV6_TXINFO option which will allow it to control the source address and/or interface. Also, now that the application is "unaware" of the IPv6 header format, adding/changing it is possible without causing everyone to compile or change their source. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Oct 31 10:02:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04932; Thu, 31 Oct 96 10:02:36 PST Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04798; Thu, 31 Oct 96 01:18:15 PST Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA00595; Thu, 31 Oct 1996 01:11:30 -0800 Received: from ietf.org (ietf.org [132.151.1.19]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA23719 for ; Wed, 30 Oct 1996 06:49:18 -0800 Received: from localhost by ietf.org id aa01835; 30 Oct 96 9:50 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2426) I-D ACTION:draft-ietf-ipngwg-ipv6-routing-00.txt Date: Wed, 30 Oct 1996 09:50:11 -0500 Message-Id: <9610300950.aa01835@ietf.org> 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 Routing Table Size Issues Author(s) : R. Atkinson Filename : draft-ietf-ipngwg-ipv6-routing-00.txt Pages : 4 Date : 10/29/1996 This note describes certain issues relating to the size of the IPv6 routing table in backbone routers. It also suggests several possible approaches to dealing with those issues. 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-ipv6-routing-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-routing-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.a o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-routing-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961029111155.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-routing-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-routing-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961029111155.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com