From owner-ipng@sunroof.eng.sun.com Mon Jun 2 02:41:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA18174; Mon, 2 Jun 1997 02:33:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA18167; Mon, 2 Jun 1997 02:32:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA18983; Mon, 2 Jun 1997 02:33:55 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA28193 for ; Mon, 2 Jun 1997 02:35:14 -0700 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20942; Mon, 2 Jun 1997 10:34:34 +0100 Date: Mon, 2 Jun 1997 10:34:34 +0100 Message-Id: <9706020934.AA20942@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3731) Re: comments on To: ipng@sunroof.eng.sun.com In-Reply-To: <338DC689.7A5F@netscape.com> from "John Francis Stracke" at May 29, 97 11:10:17 am Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 945 >- John Francis Stracke said: > > Bob Hinden wrote: > > > Brain, > > > >> - Plan or track record providing public internet transit service to > > >***** on fair, reasonable and non-discriminatory terms^ > > > > Good idea. > > Mmm, yes, but not necessarily feasible. "Fair, reasonable, and > non-discriminatory" is a good goal; but will the IANA have the ability > to enforce it? It won't, any more than the IETF can enforce it for patent royalties. But the phrase sets expectations and could conceivably be cited in court. Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 02:56:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA18184; Mon, 2 Jun 1997 02:48:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA18177; Mon, 2 Jun 1997 02:48:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA19741; Mon, 2 Jun 1997 02:49:04 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA29998 for ; Mon, 2 Jun 1997 02:50:23 -0700 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA26246; Mon, 2 Jun 1997 10:49:42 +0100 Date: Mon, 2 Jun 1997 10:49:42 +0100 Message-Id: <9706020949.AA26246@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 3732) Re: comments on To: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.1.32.19970528150211.007666a8@mailhost.ipsilon.com> from "Bob Hinden" at May 28, 97 03:02:11 pm Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3665 Bob, Ack to most of your comments on my comments... > >> - Periodically (interval set by registry) provide to registry > >> utilization statistics of the TLA it has custody of. The > > ^allocation > >> organization must also provide traffic statistics on amounts of > >> traffic for transit TLA traffic. > > > >You can't include that - it's illegal in some countries. > > What is illegal in some countries? Utilization statistics or traffic > statistics, or both? Why? Sorry - I meant traffic statistics. I have repeatedly been told this about Sweden (the law on privacy of communication is very strict there). There may be other cases; and in any case ISPs are often very reluctant to furnish traffic data, for commercial reasons. .... > >> The NLA delegation works the the same manner as CIDR delegation in > >> IPv4 [CIDR]. > >***** and MUST correspond to the routing topology as closely > > as possible. > > I think that at this level in the routing hierarchy it is a tradeoff of > routing aggregation v.s. routing/assignment flexibility. As long as the > NLA routing does not propagate to the top level, then this is a tradeoff > which belongs to the organization responsible for the specific NLA. I > could add some words to that effect. Right; I just want to be sure we apply maximum pressure to prevent long prefixes getting propagated up. > > >.... > >> of the previous level NLA. It is recommended that organizations > >> assigning NLA address space use "slow start" allocation procedures as > >> is currently done with IPV4 CIDR blocks. > > > >This is also BCP material, and it should be spelt out in a stand-alone > >way for IPv6, rather than a back-reference to a hopefully obsolete world. > > Does the NLA stuff have to be in a separate BCP from the TLA or could they > be combined? I'd hope they can be combined. > > >> The approach chosen for how to the structure of an SLA* field is the > >> responsibility of the individual organization. > > > > A large organization SHOULD use a hierarchical design > > corresponding as closely as possible to its routing > > topology. > > As above, there is a tradeoff which should be left to the site. How much > do you think needs to be said? I like Erik's suggestion to issue a separate informational doc on this like RFC 1219. .... > > > >> Documents of this type do not directly impact the security of the > >> Internet infrastructure or its applications. > > > >Hmm. Not sure that you can say as little as this. For example where > >in the IPv6 document set do we discuss address spoofing atacks? > >At least I'd be tempted to say (most everywhere, not just in this > >document) that IPv6 is intrinsically insecure unless IPSEC is switched > >on, and specifically that IPSEC can be used to mitigate address spoofing. > > I was given this text by an IESG member (who can identify him/herself if > he/she wishes). I think it is sufficient for this document given it's > content. Some of the other IPv6 specifications do need more on this topic. Yes, it may fit elsewhere. I'm just anxious that we don't lose time on this point when the draft gets officially sent to the IESG. > > Thanks again for the comments. > You're welcome Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 06:12:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA18394; Mon, 2 Jun 1997 06:03:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA18387; Mon, 2 Jun 1997 06:02:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01521; Mon, 2 Jun 1997 06:03:45 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA25375 for ; Mon, 2 Jun 1997 06:05:06 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 2 Jun 1997 09:03:25 -0400 Message-ID: From: "Conta, Alex" To: ipng@sunroof.eng.sun.com, "'brian@hursley.ibm.com'" , "'deering@cisco.com'" Subject: (IPng 3733) RE: the "u/l bit" in the IPv6 address - was "indica ting globicity" Date: Mon, 2 Jun 1997 09:03:22 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3227 I am with Brian's first message on "indicating globicity" - obviously, the more bits we have to interpret, to invert, the more prone to mistakes/bugs configurations/implementations are. Obviously with 128 bits for an address and 64 bits for an interface ID to play with, the temptation to introduce more and more "bit feature/significance" is hard to keep in control. So,... is a minor address bit thingy, getting us further away from SIMPLE IS GOOD ??? (or for example what we use, i.e. IPv4 ????) I do not see clearly the use/benefit of the "u/l" or "global/non-global" bit in the IPv6 address, which apparently the "draft-ietf-ipngwg-unicast-aggr-00.txt" - "where EUI-64 identifiers are used it is required that the "u" bit (universal/local bit in IEEE EUI-64 terminology) be set correctly." - and Steve's proposal introduce. We have already "local", and "site" unicast addresses - I could rant about them.... What is the role of the 'u/l' bit in the IPv6 address space? Does it make sense to carry (pick up) bit significance from Link Layer addresses into the IPv6 address space? What is the "universal/local" bit do for the IPv6 address, and why should one care about it more than any other bit of the 64 EUI-64 bits picked up as interface ID? Or for that matter for an interface for which the interface ID is generated by a node rather than picked up from a pre-existent value (link layer address)? Thanks, Alex --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 > ---------- > From: > owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] > Reply To: brian@hursley.ibm.com > Sent: Friday, May 23, 1997 1:06 PM > To: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 3698) Re: indicating globicity > > >- Steve Deering said: > > > > I wish to propose the following small change to the rules for > manufacturing > > IPv6 addresses out of EUI-64 addresses: that the "u" > (universal/local) bit > > in the EUI-64 address be *inverted* when forming the interface ID > part of > > an IPv6 address, > > I really think this would cause so much confusion and so many > coding errors over the next 50 years or so that we should > definitely not do it. I do understand the convenience argument, > but imagine the confusion it would cause in low level debugging. > > Brian Carpenter > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 09:36:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18645; Mon, 2 Jun 1997 09:27:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18638; Mon, 2 Jun 1997 09:27:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA18690; Mon, 2 Jun 1997 09:28:05 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA25186 for ; Mon, 2 Jun 1997 09:29:27 -0700 Received: (roque@localhost) by trix.cisco.com (8.6.12/8.6.5) id JAA14045; Mon, 2 Jun 1997 09:28:37 -0700 Date: Mon, 2 Jun 1997 09:28:37 -0700 Message-Id: <199706021628.JAA14045@trix.cisco.com> From: Pedro Marques To: "Conta, Alex" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3734) RE: the "u/l bit" in the IPv6 address - was "indica ting globicity" In-Reply-To: References: Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2077 >>>>> "Alex" == Conta, Alex writes: Alex> I am with Brian's first message on "indicating globicity" - Alex> obviously, the more bits we have to interpret, to invert, Alex> the more prone to mistakes/bugs Alex> configurations/implementations are. Alex> I do not see clearly the use/benefit of the "u/l" or Alex> "global/non-global" bit in the IPv6 address, which Alex> apparently the "draft-ietf-ipngwg-unicast-aggr-00.txt" - Alex> "where EUI-64 identifiers are used it is required that the Alex> "u" bit (universal/local bit in IEEE EUI-64 terminology) be Alex> set correctly." - and Steve's proposal introduce. Alex> We have already "local", and "site" unicast addresses - I Alex> could rant about them.... What is the role of the 'u/l' bit Alex> in the IPv6 address space? Alex> Does it make sense to carry (pick up) bit significance from Alex> Link Layer addresses into the IPv6 address space? imho you are right on that remark. Alex> What is the "universal/local" bit do for the IPv6 address, Alex> and why should one care about it more than any other bit of Alex> the 64 EUI-64 bits picked up as interface ID? The whole problem is that not all interfaces have a link layer token. Many interfaces need to be manually configured. Since IPv6 addresses now must aparently include an EUI-64 people are forced into fiddling with the local / global bits defined by the link layer address format. So unless you are proposing that we abandon the requirement that all addresses must include an EUI-64 we have to carry the local/global bit up to level 3, either inverted ot otherwise. regards, Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 10:11:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18690; Mon, 2 Jun 1997 10:00:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18683; Mon, 2 Jun 1997 10:00:34 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA27865; Mon, 2 Jun 1997 10:01:34 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA06593 for ; Mon, 2 Jun 1997 10:02:54 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id KAA22573; Mon, 2 Jun 1997 10:02:05 -0700 Message-Id: <3.0.1.32.19970602100248.00b5ae54@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Mon, 02 Jun 1997 10:02:48 -0700 To: brian@hursley.ibm.com From: Bob Hinden Subject: (IPng 3735) Re: comments on Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9706020949.AA26246@hursley.ibm.com> References: <3.0.1.32.19970528150211.007666a8@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2282 Brian, >Sorry - I meant traffic statistics. I have repeatedly been told this >about Sweden (the law on privacy of communication is very strict >there). There may be other cases; and in any case ISPs are often >very reluctant to furnish traffic data, for commercial reasons. I was thinking of changing the section to something like requiring evidence of actually carrying top level TLA traffic. This could be in the form of traffic statistics, traceroutes, routing table dumps, etc. Traceroutes are nice because they can be done externally. >> I think that at this level in the routing hierarchy it is a tradeoff of >> routing aggregation v.s. routing/assignment flexibility. As long as the >> NLA routing does not propagate to the top level, then this is a tradeoff >> which belongs to the organization responsible for the specific NLA. I >> could add some words to that effect. > >Right; I just want to be sure we apply maximum pressure to prevent >long prefixes getting propagated up. Yes, I agree. >> >> >> The approach chosen for how to the structure of an SLA* field is the >> >> responsibility of the individual organization. >> > >> > A large organization SHOULD use a hierarchical design >> > corresponding as closely as possible to its routing >> > topology. >> >> As above, there is a tradeoff which should be left to the site. How much >> do you think needs to be said? > >I like Erik's suggestion to issue a separate informational doc on this >like RFC 1219. A separate document which describes a few approaches for NLA and SLA allocation, with pluses and minus of each approach, examples, etc. This should probably end up as a BCP too. >Yes, it may fit elsewhere. I'm just anxious that we don't lose time >on this point when the draft gets officially sent to the IESG. I agree. It would be helpful if the IESG could provide some guidance in advance. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 12:48:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18870; Mon, 2 Jun 1997 12:36:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18860; Mon, 2 Jun 1997 12:36:36 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA11099; Mon, 2 Jun 1997 12:37:36 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA27754 for ; Mon, 2 Jun 1997 12:38:58 -0700 Received: from wasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) id PAA07422; Mon, 2 Jun 1997 15:27:23 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA03909; Mon, 2 Jun 1997 15:27:18 -0400 Message-Id: <9706021927.AA03909@wasted.zk3.dec.com> To: "Vijay G. Reddy" Cc: deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 3736) Re: indicating globicity In-Reply-To: Your message of "Thu, 29 May 97 14:04:33 CDT." <199705291904.OAA20745@paranoid.dfw.paranet.com> Date: Mon, 02 Jun 97 15:27:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1064 Vijay, I did not a see a response to this..so... >At a Cisco class, we were told that of the 128 bits the last 48 >are used for the MAC address while the first 80 bits indicate the >network address. This was a couple of months ago. Since then any >material I read on IPv6 has no mention of this. > >What's the correct answer? Our classes say the same thing. The lead time to update training from the real knowledge on this list is more than instaneous. The answer is 64bits for topology and 64bits for identification. I assume you have seen the mail on these drafts. Most of us are already changing our code to deal with the new token to test this at UNH event late July. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 13:03:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18905; Mon, 2 Jun 1997 12:49:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18894; Mon, 2 Jun 1997 12:48:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA13475; Mon, 2 Jun 1997 12:49:17 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA00862 for ; Mon, 2 Jun 1997 12:50:35 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 2 Jun 1997 15:49:00 -0400 Message-ID: From: "Conta, Alex" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 3737) my comments to "draft-ietf-ipngwg-unicast-aggr-00.txt" Date: Mon, 2 Jun 1997 15:48:59 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7768 Bob, Mike, Steve (in the order of your names on the draft) Please find attached my comments on your "draft-ietf-ipngwg-unicast-aggr-00.txt" I-D. Thanks, Alex ------------ =09 1. formatting - I am not sure whether it is my end that is not doing the right thing, but definitely the setup I have for M-soft Word to format in page RFCs, it does not work with your document. =09 =09 2. As I went through the document I felt that a "terminology section" would be valuable. There are terms that need a more precise definition (for removing ambiguity in the text) such as: long haul provider, long haul service, exchanges, leaf topology, private transit topology, public transit service, etc.,...=20 =09 3. Comments section by section follow: 3.1 >> 1.0 Introduction This document defines an IPv6 >>>aggregatable<<< global unicast address format for use in the Internet. =20 >> My spell checker does not like "aggregatable" - not big deal.=20 The word is also used in the title. I understand what you mean, but I wonder if "aggregate" would not do better, or perhaps no such adjective at all. "aggregatable" relays the meaning of "having or providing the ability to be aggregated", and as an adjective to "....address...." (global unicast address format) means to me that the "...address..." can be aggregated with (added to) something else. = Which is not what it is meant. =09 3.2 >>=20 This document defines an address format for the 001 (binary) Format Prefix for >>> Aggregatable<<< Global Unicast addresses.=20 >> The same comment as above 3.1 =09 3.3 >> 3.0 IPv6 >>>Aggregatable<<< Global Unicast Address Format >> The same as above 3.1 3.4 >> This document defines an address format for the IPv6 >>>aggregatable<<< global unicast address assignment. The authors believe that this >> The same as above 3.1 3.5 >> This address format is designed to support both the current provider-based aggregation and a new type of aggregation >>>called exchanges<<<. >> Perhaps >>>based on exchanges<<<, if the "exchange" is an organization like a "provider" and thus the wording to use is "exchange-based aggregation" as opposite/similar to "provider-based aggregation". 3.6 >>>Aggregatable<<< addresses The same as above 3.1. 3.7 >> ...are organized into a three level hierarchy: - Public Topology - Site Topology - >>>Interface Identifier<<< Public topology is the collection of providers and exchanges who provide public Internet transit services. Site topology is local to a specific site or organization which does not provide public = transit service to nodes outside of the site. >>>Interface identifiers<<< identify interfaces on links. >> In the above text "interface identifier" does not go well with the "public" and "site" topology. Perhaps >>>link topology<<<, since the interface identifier refers to nodes on a particular link? 3.8 >> As shown in the figure above, the >>>aggregatable<<< address format is >> The same as above 3.1. 3.9 >> ..3.1 >>>Aggregatable<<< Global Unicast Address Structure The >>>aggregatable<<< global unicast address format is as follows: >> Same as 3.1 =09 3.10 >> FP Format Prefix >>>(001)<<< >> This should be defined as a range (001 to a maximum of 110), since the extending of the TLA space relies on stilling from a different 3 bit FP value. 3.11 >> TLA >>>Top-Level<<< >>>Aggregator<<< NLA* >>>Next-Level<<< >>>Aggregator(s)<<< SLA* Site-Local >>>Aggregator(s)<<< >> While I do like very much the way the NLA and SLA subdivide, there is a weakness in the naming of these fields. Top-Level can be ambiguous: NLA may have a top level NLA. Then an NLA has other NLAs... =20 I am not sure "aggregator" is the right word. For instance, TLA may be interpreted as a set of 13 bits (not fewer) used to aggregate routes, when in fact a router may aggregate on subsets (fewer bits from left to right) of the 13 bit TLA.=20 3.12 >> The following sections specify each part of the IPv6 >>>Aggregatable<<< Global Unicast address format. >> Same as 3.1. 3.13 >> 3.2 Top-Level Aggregator >>> Top-Level Aggregators (TLA) are the top level in the routing hierarchy. Default-free routers will, at a minimum, have a routing table entry for every active TLA. <<< >> This confuses me. Does this mean that one cannot aggregate routes on fewer than 13 bits = of TLA, i.e. a router in the "default free zone" must always have any = entry for each active TLA? even when it can aggregate routes (have one route) to a group of TLAs?=20 It is not what I thought this would be, or should be.=20 Perhaps a re-wording would make this clearer. This is important. =09 3.14 >> This addressing format supports 8,192 (2^^13) TLA's. Additional TLA may be added by using this format for additional format prefixes. The addition of another FP will add another 8,192 TLA's. >> Since it is not a definition of a different address format, the FP for this type of address should be defined as a range (001 to a maximum of 110) rather than a value (001) (page 3), and the architecture document "draft-ietf-ipngwg-addr-arch-v2-00.txt" should reflect that. Is a maximum of 5*8192=3D 40960 TLAs enough? Perhaps commenting on = this would be helpful. 3.15 >>> TLA assignment requirements are as follows: - Must have a plan to offer public native IPv6 service within 6 months from assignment. Plan must include plan for NLA allocation.=20 - Plan... ...etc.,... <<< Perhaps >>>The organization a TLA is assigned to: - Must... - Must... <<< 3.16 Naming the organization that a TLA is assigned to - the organization that follows the requirements for being assigned a TLA - could be useful. That name could be used to rename the TLA field, which I commented above. The same for NLA. 3.17 >>> The number of subnets supported should be sufficient for all but the largest of organizations. Organizations which need additional subnets can arrange with the organization they are obtaining = internet service from to obtain additional site identifiers and use this to create additional subnets. <<< This is very good. However the above statement seem to leave room for non-contiguous address space allocated to a site, which introduces the site "multi-homing" problem to the NLA - the NLA may have to have two = or more route table entries for the site. Requiring contiguous space in = the text, or introducing a sliding NLA - SLA space divider per top level = NLA would eliminate this potential problem (the latter simply because the space would be allocated=20 implicitly contiguous). 3.18 >>>=20 Where EUI-64 identifiers are used it is required that the "u" bit (universal/local bit in IEEE EUI-64 terminology) be set correctly. <<< Does this mean that we carry the significance of link layer address = bits into the IPv6 address? If Yes why? If Not, and we make an exception to the "u" bit, why so? We do carry back IPv6 address into Link layer addresses. An explanation/discussion is on order here I think. --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810=20 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 2 13:05:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18921; Mon, 2 Jun 1997 12:52:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA18910; Mon, 2 Jun 1997 12:51:18 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA14259; Mon, 2 Jun 1997 12:52:12 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA01675 for ; Mon, 2 Jun 1997 12:53:26 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 2 Jun 1997 15:51:47 -0400 Message-ID: From: "Conta, Alex" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 3738) my comments to draft-ietf-ipngwg-addr-arch-v2-00.txt Date: Mon, 2 Jun 1997 15:51:45 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6155 Bob, and Steve, Please find below my comments to Each comment is marked with a number. Thanks, Alex 1.1 >> Abstract This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, >>> and an IPv6 nodes required addresses. <<< >> I think this meant to be: >>> and an enumeration of the IPv6 nodes required addresses. <<< 1.2 >>> Currently IPv6 continues the IPv4 model that a subnet is associated with one link. Multiple subnets may be assigned to the same link. <<< Recently I was pointed to an OSPF specifications in which two (or more) interfaces are on the same subnet. The above does not encompass this case. The case is not encompassed by multiple interfaces having the same address either. Do we want to mention it, though? 1.3 >>> Aggregatable Global Unicast Addresses 001 1/8 Unassigned 010 1/8 Unassigned 011 1/8 Unassigned 100 1/8 Unassigned 101 1/8 Unassigned 110 1/8 <<< I commented on the "aggregatable" on the "draft-ietf-ipngwg-unicast-aggr-00.txt" document. Also that draft indicates that it can borrow from the next FP value, which means that the AGU address type should be given a range (001 to xxx : a maximum of 110) rather than a value (001). 1.4 >>> This can be used for expansion of existing use (e.g., additional aggregatable addresses, etc.) or new uses (e.g., separate locators and identifiers). Fifteen percent of the address space is initially allocated. The remaining 85% is reserved for future use. <<< OK, this seems to take care of 1.3 1.5 >> In a number of the format prefixes (see section 2.4) Interface IDs are required to be 64 bits long and to be constructed in IEEE EUI-64 format [EUI-64]. EUI-64 based Interface identifiers may have global scope when a global token is available or may have local scope where a global token is not available (e.g., serial links, tunnel end- points, etc.). >>> It is required that the "u" bit (universal/local bit in IEEE EUI-64 terminology) be set correctly in the IEEE EUI-64 address. >>> >> Why? Is the significance of the Link layer address bits carried into the IPv6 address? And back? If yes, why? We know we cannot infer Link addresses from IPv6 addresses, so why this? If not, why just the "u" bit?. We have "local link" and "site" addresses. What is the "u" bit's role in the IPv6 address? I think this needs definition or justification. 1.6 >>>loopback address<<< The IPv6 loopback address is not to be assigned to any interface. However each interface must recognize it as its own if it receives a packet with such a destination address. This is clever. How strong is this restriction and is it really necessary to prohibit an implementation similar to BSD IPv4, in which a pseudo-interface Lo0 is the Loopback interface, the holder of the "loopback address"? 1.7 >> 2.5.7 Aggregatable Global Unicast Addresses The global aggregatable global unicast address is defined in [AGGR]. This address format is designed to support both the current provider based aggregation and a new type of aggregation called >>>exchanges<<<. The combination will allow efficient routing aggregation for both sites which connect directly to providers and who connect to exchanges. Sites will have the choice to connect to either type of aggregation point. >> I made this comment on the [AGGR] I-D. Is the type of aggregation called "exchange", or is the organization that holds the address it aggregates an "exchange", in which case the text should be rather >>>exchange based aggregation<<> +---+-----+-----------+--------+--------------------------------+ |001| TLA | NLA* | SLA* | Interface ID | +---+-----+-----------+--------+--------------------------------+ Where >>> 001 Format Prefix (3 bit) for Aggregatable Global Unicast Addresses <<< >>>> TLA Top Level Aggregator NLA* Next Level Aggregator(s) SLA* Site-Local Aggregator(s) >>>> >> I commented this in the [AGGR] I-D. FP = 001 should be a range? Aggregator, Top-Level, Next-Level are not the best names I think - see [AGGR] comments. 1.9 >> One expected use of anycast addresses is to identify the set of routers belonging to an internet service >>>aggregation<<<. Such addresses could be used as intermediate addresses in an IPv6 Routing header, to cause a packet to be delivered via a particular >>>aggregation<<< or sequence of >>>aggregations<<<. Some other possible uses are to identify the set of routers attached to a particular subnet, or the set of routers providing entry into a particular routing domain. >> Is the "aggregation" here the best term? I would have preferred a different wording. "Internet Service aggregation" seems to define a service that a collection of routers provide. The next use of "aggregation" refers to something else. Is the later "aggregation" one of the [AGGR] defined fields TLA, NLA??? Or what? The wording can/should be improved.... --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 08:40:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA19961; Tue, 3 Jun 1997 08:31:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA19943; Tue, 3 Jun 1997 08:31:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA28650; Tue, 3 Jun 1997 08:32:28 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA14100 for ; Tue, 3 Jun 1997 08:33:51 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Tue, 3 Jun 1997 11:32:11 -0400 Message-ID: From: "Conta, Alex" To: "'roque@cisco.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3740) Re: the "u/l bit" in the IPv6 address - was "i ndicating globicity" Date: Tue, 3 Jun 1997 11:32:09 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2262 > The whole problem is that not all interfaces have a link layer token. > Many > interfaces need to be manually configured. > I am well aware of that... > Since IPv6 addresses now must > aparently include an EUI-64 people are forced into fiddling with the > local / global bits defined by the link layer address format. > The fiddling with the EUI-64 bits is necessary only if the bits are significant to the IPv6 protocol, or if we allow taking the EUI-64 portion of an IPv6 address and inject it back in some Link layer processing, like for instance use the interface ID portion of the IPv6 address as a link layer address, bypassing the IPv6 Neighbor Discovery cache, or processing. But I am not aware of allowing that in the past, and am not aware of anybody proposing that, or perhaps I missed such a proposal being made? Did I? > So unless you are proposing that we abandon the requirement that all > addresses must include an EUI-64 we have to carry the local/global bit > up > to level 3, either inverted ot otherwise. > The company ID, and the "u/l" and "g/i" bits exist in the EUI-48 address as well, and I do not remember considering them significant or consider their values in a generated token in the previous IPv6 address format. The interface ID, in EUI-64 format is, as the EUI-48 was, unless I missed something, a block of bits that are picked up, hoping it is a unique number, to build an IPv6 address. If individual EUI-64 bits do not have significance in the IPv6 address format, then it seems to me that nobody need worry whether their value is correct, and thus the text in the I-Ds is not necessary. > regards, > Pedro. > Thanks, Alex > --------------------------------------------- > Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 > Fax: 508/287-2810 > Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 09:19:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20016; Tue, 3 Jun 1997 09:09:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20008; Tue, 3 Jun 1997 09:09:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA08268; Tue, 3 Jun 1997 09:10:17 -0700 Received: from aegir.EU.net (aegir.EU.net [193.242.90.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA27235 for ; Tue, 3 Jun 1997 09:11:40 -0700 Received: from aegir.EU.net (localhost.eu.net [127.0.0.1]) by aegir.EU.net (8.8.5/8.8.5) with ESMTP id SAA21117 for ; Tue, 3 Jun 1997 18:10:58 +0200 (MET DST) Message-Id: <199706031610.SAA21117@aegir.EU.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 3741) Re: the "u/l bit" in the IPv6 address - was "i ndicating globicity" In-reply-to: Your message of "Tue, 03 Jun 1997 11:32:09 EDT." From: James Aldridge Date: Tue, 03 Jun 1997 18:10:58 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2034 In message you w rite: > > Since IPv6 addresses now must > > aparently include an EUI-64 people are forced into fiddling with the > > local / global bits defined by the link layer address format. > > > The fiddling with the EUI-64 bits is necessary only if the bits are > significant to the IPv6 protocol, or if we allow taking the EUI-64 > portion of an IPv6 address and inject it back in some Link layer > processing, like for instance use the interface ID portion of the IPv6 > address as a link layer address, bypassing the IPv6 Neighbor Discovery > cache, or processing. But I am not aware of > allowing that in the past, and am not aware of anybody proposing that, > or perhaps I missed such a proposal being made? Did I? If you have a situation where addresses are being automatically configured using the EUI-64 hardware address and you also have links where this information doesn't exist (so you have to roll your own least-significant 64 bits) then you really don't the possibility of these two coinciding. The easiest way to ensure this is to make sure that you have the local/global bit set appropriately in each case. Maybe I've misunderstood something, but I'm not sure I really see a problem with this. James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 09:19:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20025; Tue, 3 Jun 1997 09:09:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20018; Tue, 3 Jun 1997 09:09:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA08377; Tue, 3 Jun 1997 09:10:45 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA27377 for ; Tue, 3 Jun 1997 09:12:09 -0700 Received: (roque@localhost) by trix.cisco.com (8.6.12/8.6.5) id JAA22811; Tue, 3 Jun 1997 09:11:26 -0700 Date: Tue, 3 Jun 1997 09:11:26 -0700 Message-Id: <199706031611.JAA22811@trix.cisco.com> From: Pedro Marques To: "Conta, Alex" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3742) Re: the "u/l bit" in the IPv6 address - was "i ndicating globicity" In-Reply-To: References: Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3253 >>>>> "Alex" == Conta, Alex writes: >> The whole problem is that not all interfaces have a link layer >> token. Many interfaces need to be manually configured. >> Alex> I am well aware of that... >> Since IPv6 addresses now must aparently include an EUI-64 >> people are forced into fiddling with the local / global bits >> defined by the link layer address format. >> Alex> The fiddling with the EUI-64 bits is necessary only if the Alex> bits are significant to the IPv6 protocol Alex, When you have to generate an eui-64 manualy for interfaces without link token you need to fiddle with the eui-64 bits. This does make the eui-64 format visible to the IP layer. Alex> , or if we allow Alex> taking the EUI-64 portion of an IPv6 address and inject it Alex> back in some Link layer processing, like for instance use Alex> the interface ID portion of the IPv6 address as a link layer Alex> address, bypassing the IPv6 Neighbor Discovery cache, or Alex> processing. Nobody is proposing that. That would be just too gross. >> So unless you are proposing that we abandon the requirement >> that all addresses must include an EUI-64 we have to carry the >> local/global bit up to level 3, either inverted ot otherwise. >> Alex> The company ID, and the "u/l" and "g/i" bits exist in the Alex> EUI-48 address as well, and I do not remember considering Alex> them significant or consider their values in a generated Alex> token in the previous IPv6 address format. Because you where not forced to use an eui-48 to build an ipv6 address. And we didn't care less about uniqueness properties of the lower part of the address beyond the local link. IPv6 addresses must now include a 64 bit "maybe unique" EID which, depending on a bit value in the middle of the word, must be guarantied to be globaly unique. As the protocol itself as no mechanisms to enforce this, it is upto the user to guaranty that property (although the protocol will still work if a supposedly global ID is not unique beyond the link). Alex> The interface ID, in EUI-64 format is, as the EUI-48 was, Alex> unless I missed something, a block of bits that are picked Alex> up, hoping it is a unique number, to build an IPv6 address. Except that the whole world is now an eui-64, even when no link token is present. Something that didn't occur some months ago. Alex> If individual EUI-64 bits do not have significance in the Alex> IPv6 address format They do. Note that i am not saying that i believe that is a nice property but the fact is the g/l bit in the eui-64 is significant to IPv6. Alex> then it seems to me that nobody need Alex> worry whether their value is correct, and thus the text in Alex> the I-Ds is not necessary. regards, Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 09:50:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20114; Tue, 3 Jun 1997 09:42:09 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20107; Tue, 3 Jun 1997 09:42:05 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA22475; Tue, 3 Jun 1997 09:43:56 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15076; Tue, 3 Jun 1997 09:42:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA19626; Mon, 2 Jun 1997 20:28:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA24734; Mon, 2 Jun 1997 20:29:46 -0700 Received: from tera.csl.sony.co.jp (tera.csl.sony.co.jp [133.138.1.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA27276 for ; Mon, 2 Jun 1997 20:30:52 -0700 Received: from vega.csl.sony.co.jp (vega.csl.sony.co.jp [133.138.1.24]) by tera.csl.sony.co.jp (8.8.4/3.3W3) with SMTP id MAA29606; Tue, 3 Jun 1997 12:28:29 +0900 (JST) Message-Id: <199706030328.MAA29606@tera.csl.sony.co.jp> X-Sender: tera@tera.csl.sony.co.jp (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1-J (32) Date: Tue, 03 Jun 1997 12:27:42 +0900 To: mobile-ip@hosaka.SmallWorks.COM, ipng@sunroof.eng.sun.com From: Fumio Teraoka Subject: (IPng 3743) new id for mobility support in IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1437 I submitted a revised internet draft for mobility support in IPv6 (draft-teraoka-ipv6-mobility-sup-04.txt). It will be located in the public directory in a few days. It can also be obtained from The abstract is attached below. Teraoka =========================================================================== Abstract This memo describes a protocol to support mobility in IPv6. The mobile node has an identifier (home address) and a temporary address (care-of address). The IPv6 base header includes the temporary addresses so that the source and destination addresses are always topologically significant, while the identifiers are included in the Destination Options Header. End nodes may have authentic cache information between identifiers and addresses for routing optimization. This protocol introduces two new destination options: `Source Identifier' and `Destination Identifier', and also introduces two control packets using UDP. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 13:05:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA20287; Tue, 3 Jun 1997 12:56:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA20280; Tue, 3 Jun 1997 12:55:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA10156; Tue, 3 Jun 1997 12:56:48 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA08429 for ; Tue, 3 Jun 1997 12:58:05 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Tue, 3 Jun 1997 15:56:29 -0400 Message-ID: From: "Conta, Alex" To: "'roque@cisco.com'" , "'hinden@ipsilon.com'" , "'deering@cisco.com'" , "'mo@uu.net'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3744) Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity" Date: Tue, 3 Jun 1997 15:56:27 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3988 > Alex, > > When you have to generate an eui-64 manualy for interfaces without > link token > you need to fiddle with the eui-64 bits. This does make the eui-64 > format > visible to the IP layer. > Pedro, This is the process of generating an IPv6 address though. But what purpose would serve to check the "u/l" bit of the EUI-64 (interface ID) of an IPv6 address of an incoming or outgoing packet? which is the IPv6 protocol processing that would justify the setting of the interface ID bits in a certain way. First one would do this only for unicast packets that have FP = 001, or an appropriate range. Would one take different decisions in a PCB lookup if the "u/l" bit of a packet is 0 or 1? I do not think so... It does not make sense... Is then this perhaps being over-zealous? If we now (pretend that we) (sometime) generate EUI-64s in each IPv6 node, then that may an expensive game - see next reply section below. > Because you where not forced to use an eui-48 to build an ipv6 > address. And > we didn't care less about uniqueness properties of the lower part of > the > address beyond the local link. IPv6 addresses must now include a 64 > bit > "maybe unique" EID which, depending on a bit value in the middle of > the > word, must be guarantied to be globaly unique. > For node (so called manually) generated EUI-64, what is the "company ID" to be used? (the addressing I-Ds pass this issue to IP over foo I-Ds) Apparently a vendor that sells devices with EUI-64s has the right to do so because it bought from the IEEE Registration Authority a "company ID" (24 bits). The 24 bit company ID contains the "u/l" bit, which means that one can set/clear that bit only if it has the appropriate address range assigned. If presumably for node IPv6 generated EUI-64s the value of the "company ID" is 00:00:00 (24 bits) - otherwise there would be collisions with valid assigned "company IDs" - then there is a "company ID" collision (all zero's) for all node generated EUI-64s, and furthermore, the "u/l" bit is 0, which means global unique. Who pays for the 00:00:00 "company ID"? Furthermore, it seems that "an organization generating EUI-64 values shall indemnify the IEEE for damages arising from duplicate assignments". Who pays this? The vendor of the IPv6 node hardware, or software, the owner of the IPv6 node, the IETF, the IANA ???? I guess, what I (slowly) got to, is to say wouldn't it be more simple to not use at all node generated EUI-64s - I feel a headache as I think about it. .... > They do. Note that i am not saying that i believe that is a nice > property > but the fact is the g/l bit in the eui-64 is significant to IPv6. > Well, well... The IPv6 multicast addresses MUST translate into a link address that has the "g/i" bit = 1, but they do not contain an EUI-64 part. An IPv6 unicast (AGU) address, if the EUI-64 is gotten from the link layer, it would be a (painful) bug to have the "g/i" bit = 1, and for a node generated EUI-64 the value would not matter, since the EUI-64 part would not be used as a link layer address - of course one may want to incur the implementation expense to make sure that generated "g/i" = 0, and incoming unicast packets have the "g/i" = 0. Is though enforcing a tight logic between IPv6 address bits and Link layer addresses bits become a purpose? I do not see its use... > regards, > Pedro. > Thanks, Alex > --------------------------------------------- > Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 > Fax: 508/287-2810 > Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 13:38:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA20357; Tue, 3 Jun 1997 13:29:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA20347; Tue, 3 Jun 1997 13:29:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA18926; Tue, 3 Jun 1997 13:30:36 -0700 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA19279 for ; Tue, 3 Jun 1997 13:32:00 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id NAA10978; Tue, 3 Jun 1997 13:31:18 -0700 (PDT) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA22226; Tue, 3 Jun 1997 13:31:18 -0700 (PDT) Date: Tue, 3 Jun 1997 13:31:18 -0700 (PDT) Message-Id: <199706032031.NAA22226@pedrom-ultra.cisco.com> From: Pedro Marques To: "Conta, Alex" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3745) Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity" In-Reply-To: References: Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5003 >>>>> "Alex" == Conta, Alex writes: >> Alex, >> >> When you have to generate an eui-64 manualy for interfaces >> without link token you need to fiddle with the eui-64 >> bits. This does make the eui-64 format visible to the IP layer. >> Alex> Pedro, Alex> This is the process of generating an IPv6 address though. Sure. But you have to abide by those rules... i think. Alex> But what purpose would serve to check the "u/l" bit of the Alex> EUI-64 (interface ID) of an IPv6 address of an incoming or Alex> outgoing packet? I wouldn't know. But i would assume you need to do that if you wish to make sure the lower part of an address can be seen as an EID. Alex> which is the IPv6 protocol processing that Alex> would justify the setting of the interface ID bits in a Alex> certain way. First one would do this only for unicast Alex> packets that have FP = 001, or an appropriate range. Would Alex> one take different decisions in a PCB lookup if the "u/l" Alex> bit of a packet is 0 or 1? As far as i understood the conclusion from the last ietf on this question was: "Maybe". >> Because you where not forced to use an eui-48 to build an ipv6 >> address. And we didn't care less about uniqueness properties of >> the lower part of the address beyond the local link. IPv6 >> addresses must now include a 64 bit "maybe unique" EID which, >> depending on a bit value in the middle of the word, must be >> guarantied to be globaly unique. >> Alex> For node (so called manually) generated EUI-64, what is the Alex> "company ID" to be used? (the addressing I-Ds pass this Alex> issue to IP over foo I-Ds) Global or local ? if you are generating a global eui-64 from an 802.3 token you have to use the ietf company ID. If it is local you can use the company ID you want since it is not an eui-64 anyway, it is just a plain ip address... Alex> Apparently a vendor that sells devices with EUI-64s has the Alex> right to do so because it bought from the IEEE Registration Alex> Authority a "company ID" (24 bits). The 24 bit company ID Alex> contains the "u/l" bit, which means that one can set/clear Alex> that bit only if it has the appropriate address range Alex> assigned. Sure. But when build the end-system identifier part of a v6 address, if the u/l bit is in the local position you can ignore the company id part. At least there is nothing that prevents you from doing so. Alex> Who pays for the 00:00:00 "company ID"? You don't need it. Alex> Furthermore, it Alex> seems that "an organization generating EUI-64 values shall Alex> indemnify the IEEE for damages arising from duplicate Alex> assignments". We are not really assigning eui-64s but ipv6 addresses and as long as one does not preclude the owner of an eui-64 to use the corresponding ipv6 EID all should be well, although i'd rather not have to explain this in a court of law. It would be perhaps rasonable to contact the IEEE and discuss the issue with them. Alex> Who pays this? The vendor of the IPv6 node Alex> hardware, or software, the owner of the IPv6 node, the IETF, Alex> the IANA ???? Alex> I guess, what I (slowly) got to, is to say wouldn't it be Alex> more simple to not use at all node generated EUI-64s - I Alex> feel a headache as I think about it. Well... that is an interestening thought. That was not however the decision made at the past ietf. >> They do. Note that i am not saying that i believe that is a >> nice property but the fact is the g/l bit in the eui-64 is >> significant to IPv6. >> Alex> Well, well... Alex> The IPv6 multicast addresses MUST translate into a link Alex> address that has the "g/i" bit = 1, but they do not contain Alex> an EUI-64 part. Alex> An IPv6 unicast (AGU) address, if the EUI-64 is gotten from Alex> the link layer, it would be a (painful) bug to have the Alex> "g/i" bit = 1, and for a node generated EUI-64 the value Alex> would not matter, since the EUI-64 part would not be used as Alex> a link layer address - of course one may want to incur the Alex> implementation expense to make sure that generated "g/i" = Alex> 0, and incoming unicast packets have the "g/i" = 0. I don't understand what you mean. Alex> Is though enforcing a tight logic between IPv6 address bits Alex> and Link layer addresses bits become a purpose? It sure looks that way... Alex> I do not see its use... regards, Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 14:09:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20498; Tue, 3 Jun 1997 14:00:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20491; Tue, 3 Jun 1997 14:00:25 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA28263; Tue, 3 Jun 1997 14:01:24 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA21734 for ; Tue, 3 Jun 1997 14:02:01 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id RAA10751; Tue, 3 Jun 1997 17:01:33 -0400 Date: Tue, 3 Jun 1997 17:01:33 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9706031701.ZM10749@seawind.bellcore.com> In-Reply-To: "Conta, Alex" "(IPng 3744) Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity"" (Jun 3, 3:56pm) References: X-Mailer: Z-Mail (3.2.1 10oct95) To: "Conta, Alex" , "'roque@cisco.com '" , "'hinden@ipsilon.com'" , "'deering@cisco.com'" , "'mo@uu.net'" Subject: (IPng 3746) Re: Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity" Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2310 On Jun 3, 3:56pm, Conta, Alex wrote: > Subject: (IPng 3744) Node generated EUI-64s - was the "u/l bit" in the IPv > > > Alex, > > > > When you have to generate an eui-64 manualy for interfaces without > > link token > > you need to fiddle with the eui-64 bits. This does make the eui-64 > > format > > visible to the IP layer. > > > Pedro, > > This is the process of generating an IPv6 address though. > > But what purpose would serve to check the "u/l" bit of the EUI-64 > (interface ID) of an IPv6 address of an incoming or outgoing packet? > which is the IPv6 protocol processing that would justify the setting of > the interface ID bits in a certain way. Well, do you really want a rehash of the EID debate? The basic answer is that no protocol uses this feature today, and that the collision detection feature of neighbor discovery prevents collisions on a given link. But then, TCPng may take advantage of the last 64 bits being worldwide unique to facilitate multihoming and renumbering. And then, maybe not, but you dont want that debate, do you ? > Who pays for the 00:00:00 "company ID"? Furthermore, it seems that "an > organization generating EUI-64 values shall indemnify the IEEE for > damages arising from duplicate assignments". Who pays this? > The vendor of the IPv6 node hardware, or software, the owner of the IPv6 > node, the IETF, the IANA ???? Actually, it would be a good idea to have a precise explanantion of the style, "if your box does not have an EUI-64, or cannot build one from an IEEE-802 number, then do this." This may be, for example, the combination of a specific prefix (e.g. the IANA IEEE-802 multicast for IPv6 prefix) properly tweaked (without g/u) with some random, or configured, number. Note that there is no relation whatsoever between the EUI-64 and whatever link layer address is used by a given interface -- they are allowed to be entirely different. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 3 14:27:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20559; Tue, 3 Jun 1997 14:18:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20546; Tue, 3 Jun 1997 14:18:39 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA03331; Tue, 3 Jun 1997 14:19:36 -0700 Received: from wachusett.altavista-software.com (wachusett.altavista-software.com [205.181.164.11]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA28467 for ; Tue, 3 Jun 1997 14:20:14 -0700 Received: by wachusett.altavista-software.com; (5.65v3.2/1.3/10May95) id AA30681; Tue, 3 Jun 1997 17:20:05 -0400 Message-Id: <3.0.1.32.19970603171908.0097a39c@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 03 Jun 1997 17:19:08 -0400 To: "Conta, Alex" Received: from 1Cust37.Max2.Boston.MA.MS.UU.NET by wachusett.altavista-software.com (smtpxd); id XA18100 From: Matt Thomas Subject: (IPng 3747) Re: Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity" Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3245 At 03:56 PM 6/3/97 -0400, Conta, Alex wrote: >But what purpose would serve to check the "u/l" bit of the EUI-64 >(interface ID) of an IPv6 address of an incoming or outgoing packet? >which is the IPv6 protocol processing that would justify the setting of >the interface ID bits in a certain way. First one would do this only for >unicast packets that have FP = 001, or an appropriate range. Would one >take different decisions in a PCB lookup if the "u/l" bit of a packet is >0 or 1? I do not think so... It does not make sense... >Is then this perhaps being over-zealous? This is a "reserved-for-future-use" thing. We don't know what we will use it for but if we don't do something NOW we will never be able to it. Therefore we impose a bit of pain now. Think of it as an investment. So for now, you don't check anything. You only do something special when you determining a link token. After that, treat it as opaque until told otherwise. >> Because you where not forced to use an eui-48 to build an ipv6 >> address. And >> we didn't care less about uniqueness properties of the lower part of >> the >> address beyond the local link. IPv6 addresses must now include a 64 >> bit >> "maybe unique" EID which, depending on a bit value in the middle of >> the >> word, must be guarantied to be globaly unique. >> >For node (so called manually) generated EUI-64, what is the "company ID" >to be used? (the addressing I-Ds pass this issue to IP over foo I-Ds) Anything you want as long the "i/m" bit is clear the "u/l" is set. >Apparently a vendor that sells devices with EUI-64s has the right to do >so because it bought from the IEEE Registration Authority a "company ID" >(24 bits). The 24 bit company ID contains the "u/l" bit, which means >that one can set/clear that bit only if it has the appropriate address >range assigned. Wrong. Company-ids are 22 bits long and do not contain the u/l bit (it does contain the i/g (multicast) bit). If the u/l bit is 1, the EUI-64 only has local significant and the company-id has no meaning. Even though Digital uses AA-00-03, AA-00-04, AB-00-02, and others Digital does not "own" them since they are in the local space. Of course, this invalidates most of the rest of your message. >> They do. Note that i am not saying that i believe that is a nice >> property >> but the fact is the g/l bit in the eui-64 is significant to IPv6. >> >Well, well... > >The IPv6 multicast addresses MUST translate into a link address that has >the "g/i" bit = 1, but they do not contain an EUI-64 part. That "g/l" (aka "u/l"), not "g/i". -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 4 07:02:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA24111; Wed, 4 Jun 1997 06:54:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA24104; Wed, 4 Jun 1997 06:54:28 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA24703; Wed, 4 Jun 1997 06:55:24 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA10755 for ; Wed, 4 Jun 1997 06:55:58 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 4 Jun 1997 09:54:46 -0400 Message-ID: From: "Conta, Alex" To: "'huitema@bellcore.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3955) RE: Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity" Date: Wed, 4 Jun 1997 09:54:44 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2588 > Well, do you really want a rehash of the EID debate? The basic answer > is > that no protocol uses this feature today, and that the collision > detection > feature of neighbor discovery prevents collisions on a given link. > But > then, TCPng may take advantage of the last 64 bits being worldwide > unique > to facilitate multihoming and renumbering. And then, maybe not, but > you > dont want that debate, do you ? > Christian, It makes sense, and I am sorry that bringing up what I see as a lateral issue looks like I try to rehash the entire EID debate, and/or trash its main outcome, that is the use of EUI-64s. I am not. Again, I am saying that I do not think it is a good idea for layer 3 and layer 4 - i.e. IPv6, and ng transports (TCPng) - to treat the layer 2 (link layer) EUI-64 bits other than a block of bits. And this goes beyond just discussing bit "a" or bit "z". It is the architectural principle of not making the layers above dependent on a particular configuration of bits significant to SOME of the protocols of the layer below. By the way, I see no use of the "u/l" bit in multihoming and renumbering. For both, the interface ID should be used as a block of bits (compare, replace,...etc.,...) i.e. local EIU-64's will have different values than any universal EUI-64. > Actually, it would be a good idea to have a precise explanantion of > the > style, "if your box does not have an EUI-64, or cannot build one from > an > IEEE-802 number, then do this." This may be, for example, the > combination > of a specific prefix (e.g. the IANA IEEE-802 multicast for IPv6 > prefix) > properly tweaked (without g/u) with some random, or configured, > number. > So far, apparently IANA (in fact ISI) owns only the 00-00-5E "company ID". > Note that there is no relation whatsoever between the EUI-64 and > whatever > link layer address is used by a given interface -- they are allowed to > be > entirely different. > Of course. > -- > Christian Huitema > Thanks, Alex > --------------------------------------------- > Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 > Fax: 508/287-2810 > Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 4 07:45:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA24141; Wed, 4 Jun 1997 07:38:07 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA24134; Wed, 4 Jun 1997 07:37:58 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06755; Wed, 4 Jun 1997 07:38:57 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA24636 for ; Wed, 4 Jun 1997 07:39:36 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 4 Jun 1997 10:38:28 -0400 Message-ID: From: "Conta, Alex" To: "'matt.thomas@altavista-software.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3956) RE: Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity" Date: Wed, 4 Jun 1997 10:38:25 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3491 > This is a "reserved-for-future-use" thing. We don't know what we will > use it for but if we don't do something NOW we will never be able to > it. > Therefore we impose a bit of pain now. Think of it as an investment. > > So for now, you don't check anything. You only do something special > when you determining a link token. After that, treat it as opaque until told otherwise. Matt, It may seem wise. But this phrase in a form or another is not more than hand waving... I do not think it is sound to do different than taking and using the EUI-64 as a block of bits. We should not build an internet layer (or transport protocol) based on the position and bit significance of some of the protocols of a layer below. > Wrong. Company-ids are 22 bits long and do not contain the u/l bit > (it > does contain the i/g (multicast) bit). If the u/l bit is 1, the > EUI-64 > only has local significant and the company-id has no meaning. Even > though Digital uses AA-00-03, AA-00-04, AB-00-02, and others Digital > does not "own" them since they are in the local space. > > Of course, this invalidates most of the rest of your message. > Hm.,... Matt, I think your math is not correct. If you take the "u/l" bit out but leave the 'i/g' bit in, than you have 23 rather than 22 bits. Anyways, I am afraid you take some of the DEC internal practices as IEEE rules. The IEEE OUI, and EUI-64 info are documenting unequivocally the "company ID' as a 24 bit field: "An OUI/"company_id" is a 24 bit globally unique assigned number referenced by various standards. OUI is used in the family of 802 LAN standards, e.g., Ethernet, Token Ring, etc." and "The IEEE defined 64-bit global identifier (EUI-64) is assigned by a manufacturer that has been assigned a company_id value by the IEEE Registration Authority. The 64-bit identifier is a concatenation of the 24-bit company_id value assigned by the IEEE Registration Authority and a 40- bit extension identifier assigned by the organization with that company_id assignment." Let's not hammer this to death though. By the way, DEC owns according to the public section of the IEEE data base the following "company IDs": 00-00-F8 (hex) DIGITAL EQUIPMENT CORPORATION 00-60-6D (hex) DIGITAL EQUIPMENT CORP. 08-00-2B (hex) DIGITAL EQUIPMENT CORPORATION AA-00-00 (hex) DIGITAL EQUIPMENT CORPORATION AA-00-03 (hex) DIGITAL EQUIPMENT CORPORATION AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION > That "g/l" (aka "u/l"), not "g/i". > It is rather "g/i" inverted, i.e. "i/g". "The first (leftmost) bit in the binary representation is the I/G Address Bit. If set to 0, it indicates an individual address. It may be set to 1 in an address allocated by the assignee to indicate that address is a group address. " Thanks, Alex --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 4 12:26:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24421; Wed, 4 Jun 1997 12:18:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24411; Wed, 4 Jun 1997 12:18:20 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA25181; Wed, 4 Jun 1997 12:19:16 -0700 Received: from wachusett.altavista-software.com (wachusett.altavista-software.com [205.181.164.11]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA15539 for ; Wed, 4 Jun 1997 12:19:58 -0700 Received: by wachusett.altavista-software.com; (5.65v3.2/1.3/10May95) id AA02816; Wed, 4 Jun 1997 15:19:52 -0400 Message-Id: <3.0.1.32.19970604151855.0073d900@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 04 Jun 1997 15:18:55 -0400 To: "Conta, Alex" Received: from 1Cust30.Max13.Boston.MA.MS.UU.NET by wachusett.altavista-software.com (smtpxd); id XA26599 From: Matt Thomas Subject: (IPng 3957) Re: Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity" Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3333 At 10:38 AM 6/4/97 -0400, Conta, Alex wrote: > >> This is a "reserved-for-future-use" thing. We don't know what we will >> use it for but if we don't do something NOW we will never be able to >> it. >> Therefore we impose a bit of pain now. Think of it as an investment. >> >> So for now, you don't check anything. You only do something special >> when you determining a link token. After that, treat it as opaque > until told otherwise. > >Matt, > >It may seem wise. But this phrase in a form or another is not more than >hand waving... Yes it is hand-waving. So what? So are the priority bits. >I do not think it is sound to do different than taking and using the >EUI-64 as a block of bits. > >We should not build an internet layer (or transport protocol) based on >the position and bit significance of some of the protocols of a layer >below. We are not basing stuff on lower lever protocols, but a standard definition (EUI-64) that happens to be used by a significant amount of equipment that will be running IPv6. >> Wrong. Company-ids are 22 bits long and do not contain the u/l bit >> (it >> does contain the i/g (multicast) bit). If the u/l bit is 1, the >> EUI-64 >> only has local significant and the company-id has no meaning. Even >> though Digital uses AA-00-03, AA-00-04, AB-00-02, and others Digital >> does not "own" them since they are in the local space. >> >> Of course, this invalidates most of the rest of your message. >> >Hm.,... Matt, I think your math is not correct. If you take the "u/l" >bit out but leave the 'i/g' bit in, than you have 23 rather than 22 >bits. But "i/g" bit must be 0 for addresses assigned to interfaces. Note that 09-00-2B and 08-00-2B refer to the same company so in effect the company-id is 22 bits. >Anyways, I am afraid you take some of the DEC internal practices as IEEE >rules. I might be wrong but I don't think so. If we want to be sure, I suppose one will us will need to refernce the appropriate ISO 8802-x specification. >Let's not hammer this to death though. [Chuckle!] >By the way, DEC owns according to the public section of the IEEE data >base the following >"company IDs": > >AA-00-00 (hex) DIGITAL EQUIPMENT CORPORATION >AA-00-03 (hex) DIGITAL EQUIPMENT CORPORATION >AA-00-04 (hex) DIGITAL EQUIPMENT CORPORATION The last 3 were not assigned by the IEEE but by XEROX. There were "grandfathered" to Digital when the IEEE 802 committee defined the u/l bit. Note that AA-00-03 was used in the address ROMs of DEUNAs until the u/l bit was defined and then 08-00-2B started being used (because AA-00-03 was not global). -- Matt Thomas Internet: matt.thomas@altavista-software.com Internet Locksmith WWW URL: AltaVista Internet Software Disclaimer: This message reflects my own Littleton, MA warped views, etc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 4 13:22:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24526; Wed, 4 Jun 1997 13:09:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24519; Wed, 4 Jun 1997 13:08:54 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA08135; Wed, 4 Jun 1997 13:09:50 -0700 Received: from aland.bbn.com (aland.bbn.com [204.162.9.10]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA03235 for ; Wed, 4 Jun 1997 13:10:32 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id NAA21560; Wed, 4 Jun 1997 13:09:57 -0700 (PDT) Message-Id: <199706042009.NAA21560@aland.bbn.com> To: ipng@sunroof.eng.sun.com cc: awjacks@bbn.com Subject: (IPng 3958) revised router alert From: Craig Partridge Date: Wed, 04 Jun 97 13:09:56 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1508 Hi folks: Alden Jackson and I revised the router alert draft about a month ago and Bob Hinden has asked us to circulate it. It is available at ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-ipv6-router-alert-02.txt Our goal in the revision was to make the minimal set of changes necessary to present the option's purpose without reference to a particular implementation style (e.g. fast path). We also cleaned up the semantics a little. We point out that due to layering issues, extension headers may get lost, and higher protocols need to define, on a per protocol type basis, what the semantics of handling the datagram is (e.g., is it copy for local processing and forward immediately? Do local processing and let local processing decide whether to forward the datagram? Etc.) I'll note I'm not entirely happy with this approach. It means everyone will have to maintain some sort of reference table that maps each protocol value in the option to a style of handling. I'd prefer those semantics encoded into the protocol value. Comments welcomed. Thanks! Craig E-mail: craig@aland.bbn.com or craig@bbn.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 4 13:49:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24591; Wed, 4 Jun 1997 13:40:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24584; Wed, 4 Jun 1997 13:40:05 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA16805; Wed, 4 Jun 1997 13:41:00 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA14545 for ; Wed, 4 Jun 1997 13:41:37 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 4 Jun 1997 16:40:26 -0400 Message-ID: From: "Conta, Alex" To: "'matt.thomas@altavista-software.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3959) Re: Node generated EUI-64s - was the "u/l bit" i n the IPv6 address - was "indicating globicity" Date: Wed, 4 Jun 1997 16:40:25 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1511 > We are not basing stuff on lower lever protocols, but a standard > definition (EUI-64) that happens to be used by a significant > amount of equipment that will be running IPv6. > Matt, "Significant amount" is exactly where I want to leave it... To be flexible, and to include everyone, and/or not to exclude someone means to not depend exclusively on EUI-64 bit position/values in the layers above layer 2. ..... Note that AA-00-03 was used in the address ROMs of > DEUNAs until the u/l bit was defined and then 08-00-2B started being > used (because AA-00-03 was not global). > Please no!... Who cares on this list about DEC Unibus Network Adapters popular 12 or more years ago? who remembers "una-0" or "de0"? a "code warrior" in the reserves (-:, maybe me.... "...start DECnet first, or trick DEUNA to think you're DECnet if you want to run/debug your TCP/IP..." ... let me not open my bag of stories.... Thanks, Alex --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 5 13:48:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26302; Thu, 5 Jun 1997 13:39:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26295; Thu, 5 Jun 1997 13:39:06 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA09453; Thu, 5 Jun 1997 13:40:02 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA16736 for ; Thu, 5 Jun 1997 13:40:46 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id NAA23429; Thu, 5 Jun 1997 13:40:27 -0700 Message-Id: <3.0.2.32.19970605134109.00b0f10c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 05 Jun 1997 13:41:09 -0700 To: "Conta, Alex" From: Bob Hinden Subject: (IPng 3960) Re: Node generated EUI-64s - was the "u/l bit" in the IPv6 address - was "indicating globicity" Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1724 Alex, >Again, I am saying that I do not think it is a good idea for layer 3 and >layer 4 - i.e. IPv6, and ng transports (TCPng) - to treat the layer 2 >(link layer) EUI-64 bits other than a block of bits. > >And this goes beyond just discussing bit "a" or bit "z". > >It is the architectural principle of not making the layers above >dependent on a particular configuration of bits significant to SOME of >the protocols of the layer below. All we are doing now is to define rules for the creation of Interface Identifiers in a range of IPv6 format prefixes. That is all. There is no specification which requires anything to look at specific bits in an interface identifier. They are, as you suggest, opaque. The choice of the EUI-64 as a format for these interface identifiers is for convience. It is a convenient framework to create interface ID's. It does not imply a tight coupling of IPv6 to one or more link layer protocols. There may be a research activity that might build some mechanisms to take advantage of the global property of some of the interface identifiers. This research is not part of the IPv6 standardization effort. This is research and in my opinion it is not appropriate criticize it on architectural principles. It is from research like this we learn what our architectural principals should be. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 5 15:10:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA26435; Thu, 5 Jun 1997 15:01:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA26428; Thu, 5 Jun 1997 15:01:46 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA00901; Thu, 5 Jun 1997 15:02:40 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA17181 for ; Thu, 5 Jun 1997 15:03:17 -0700 Received: from gungnir.fnal.gov ("port 36800"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01IJPYOWSO8E0001FG@FNAL.FNAL.GOV> for ipng@sunroof.Eng.Sun.COM; Thu, 05 Jun 1997 17:03:08 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA07671; Thu, 05 Jun 1997 17:03:08 -0500 Date: Thu, 05 Jun 1997 17:03:08 -0500 From: Matt Crawford Subject: (IPng 3961) Re: (IPng 3956 et seq.) RE: Node generated EUI-64s - was the "u/l bit" To: ipng@sunroof.eng.sun.com Message-id: <199706052203.RAA07671@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{ Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01546; Mon, 9 Jun 1997 17:19:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01539; Mon, 9 Jun 1997 17:18:55 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA12740; Mon, 9 Jun 1997 17:19:41 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA16120 for ; Mon, 9 Jun 1997 17:20:35 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id RAA14206; Mon, 9 Jun 1997 17:19:16 -0700 Message-Id: <3.0.2.32.19970609171911.00cb0d8c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 09 Jun 1997 17:19:11 -0700 To: Matt Crawford From: Bob Hinden Subject: (IPng 3962) Re: Node generated EUI-64s - was the "u/l bit" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199706052203.RAA07671@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1719 Matt, >Steve's suggestion of toggling the U/L (Universal/Local) bit when >forming an IPv6 address is a possible solution to this problem. >Other solutions in this class include complementing the whole first >octet, or the first three octets, the first five (turn those FFFE >sequences into quieter but equally inscrutable 0001's), or the whole >eight octets. How much ugliness is the right amount? As part of writing the appendix on how to create EUI-64 based interface identifiers for the address architecture spec. I came to the conclusion that Steve's suggestion makes a lot of sense. It resolves the potential problem with the all zeros company_id, makes creating interface identifiers on links with out global tokens (e.g. local talk, serial links, etc.) easier, and makes the current definition of the subnet-router anycast address work. Plus it will make the writing of IPv6 addresses with local scope identifiers much easier. I suspect we will see many address of the form: 4037:100:40:A01::1 I suspect that the addresses with local scope identifiers are much more likely to be manually configured than the ones created from a hardware token. Based on all of this I am planning to include this in the next version of the addressing architecture spec. If anyone has any strong objections please say something soon. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 13:05:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02415; Tue, 10 Jun 1997 12:32:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02407; Tue, 10 Jun 1997 12:32:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA01674; Tue, 10 Jun 1997 12:33:14 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA07627 for ; Tue, 10 Jun 1997 12:35:01 -0700 Received: by snoopy.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Tue, 10 Jun 1997 15:33:41 -0400 Message-ID: From: "Conta, Alex" To: "'hinden@ipsilon.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 3963) Re: Node generated EUI-64s - was the "u/l bit" Date: Tue, 10 Jun 1997 15:33:38 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1374 ... It resolves the potential > problem with the all zeros company_id, makes creating interface > identifiers > on links with out global tokens > >>>(e.g. local talk, serial links, etc.)<<< ... > Bob > Bob, I know I noticed this but not sure if included it in my previous comments: In the currently available draft the list of devices that have no global token includes tunnel end-points. That according to the IPv6 tunneling draft is not accurate, since a tunnel interface is a pseudo-interface characterized by entry and exit, i.e. a pair of IPv6 addresses - exit may be unspecified = open ended tunnel. In your most recent message (IPng 3962) you seem to have corrected this already in the new version of the draft, so I just wanted to make sure that that is indeed the case. Alex --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 13:31:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02461; Tue, 10 Jun 1997 12:58:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02454; Tue, 10 Jun 1997 12:58:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA06749; Tue, 10 Jun 1997 12:59:11 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA13167 for ; Tue, 10 Jun 1997 13:01:02 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id MAA17693; Tue, 10 Jun 1997 12:52:40 -0700 Message-Id: <3.0.2.32.19970610125238.00d8f3b0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 10 Jun 1997 12:52:38 -0700 To: "Conta, Alex" From: Bob Hinden Subject: (IPng 3964) Re: Node generated EUI-64s - was the "u/l bit" Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1064 Alex, >In the currently available draft the list of devices that have no global >token includes tunnel >end-points. That according to the IPv6 tunneling draft is not accurate, >since a tunnel interface is a pseudo-interface characterized by entry >and exit, i.e. a pair of IPv6 addresses - exit may be unspecified = open >ended tunnel. > >In your most recent message (IPng 3962) you seem to have corrected this >already in the new version of the draft, so I just wanted to make sure >that that is indeed the case. I am almost done with the new version of the document and I think it covers this case. I suspect that a small change will be need in the tunneling specification. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 15:12:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA02681; Tue, 10 Jun 1997 14:42:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA02674; Tue, 10 Jun 1997 14:42:25 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04248; Tue, 10 Jun 1997 14:43:11 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA12690 for ; Tue, 10 Jun 1997 14:44:58 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Tue, 10 Jun 1997 17:43:37 -0400 Message-ID: From: "Conta, Alex" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 3965) Re: Node generated EUI-64s - was the "u/l bit" Date: Tue, 10 Jun 1997 17:43:34 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1256 > Alex, > > I am almost done with the new version of the document and I think it > covers > this case. I suspect that a small change will be need in the > tunneling > specification. > Bob, I think you are right. I will need to take a look to make sure that the address related business is clear - relationship between tunnel interfaces addresses and the real interfaces addresses. I am not sure though what small change you suggest. > Bob > Thanks for the suggestion. Alex > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 15:17:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA02690; Tue, 10 Jun 1997 14:44:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA02683; Tue, 10 Jun 1997 14:44:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA04729; Tue, 10 Jun 1997 14:45:17 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA13375 for ; Tue, 10 Jun 1997 14:47:06 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id OAA03312; Tue, 10 Jun 1997 14:45:43 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 1997 14:45:48 -0700 To: "Conta, Alex" From: Steve Deering Subject: (IPng 3966) Re: Node generated EUI-64s - was the "u/l bit" Cc: "'hinden@ipsilon.com'" , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1653 > In the currently available draft the list of devices that have no global > token includes tunnel > end-points. That according to the IPv6 tunneling draft is not accurate, > since a tunnel interface is a pseudo-interface characterized by entry > and exit, i.e. a pair of IPv6 addresses - exit may be unspecified = open > ended tunnel. Alex, I'm not understanding what point you are making. We model tunnels as virtual links. The (virtual) interface to a virtual link, like any interface, may be assigned global and non-global unicast addresses, and those addresses would require an interface ID in their lowest order field. One way to create the interface ID of the tunnel endpoint address(es) might be to use the interface token of the underlying real interface, but if the underlying real interface does not have a globally unique token, there's the danger of both ends of tunnel fabricating the same address. A different way to create the interface ID is to use tunnel-specific tokens, e.g., the tokens 1 and 2 for each end of the tunnel, or perhaps large, randomly-generated, non-global tokens. This latter approach is what Bob was referring to in his earlier draft. Is that what you are objecting to, or are you talking about something else? Confused, Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 16:24:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02935; Tue, 10 Jun 1997 16:03:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02928; Tue, 10 Jun 1997 16:03:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA25705; Tue, 10 Jun 1997 16:04:18 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA07906 for ; Tue, 10 Jun 1997 16:06:06 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Tue, 10 Jun 1997 19:04:48 -0400 Message-ID: From: "Conta, Alex" To: "'Steve Deering'" Cc: "'hinden@ipsilon.com'" , ipng@sunroof.eng.sun.com Subject: (IPng 3967) Re: Node generated EUI-64s - was the "u/l bit" Date: Tue, 10 Jun 1997 19:04:45 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3019 > Alex, > > I'm not understanding what point you are making. We model tunnels as > virtual links. The (virtual) interface to a virtual link, like any > interface, may be assigned global and non-global unicast addresses, > and > those addresses would require an interface ID in their lowest order > field. > Steve, Sorry for confusing you. My text was not clear. Let me try again: The IPv6 tunneling draft specifies that: The tunnel entry-point node address is one of the valid IPv6 unicast addresses of the entry-point node ... A tunnel interface which is a pseudo or virtual interface is layered on a real interface. When the tunnel interface is configured, it is given as parameters the tunnel entry and exit point addresses. The entry point address is a valid IPv6 address of the real underlying interface. So my comment to Bob was that a tunnel interface is not assigned a separate interface ID, but rather takes altogether the IPv6 address, including the interface ID of the real underlying interface. Consequently, a tunnel interface IPv6 address can be link local, site local, or global, and the interface ID can be local or global. .... there's > the danger of both ends of tunnel fabricating the same address. > I raised this as a possible issue with Bob in a private message: I am not sure if this was discussed on the IPng list, but it seems to me that the "local token" can be used safely only with non-global IPv6 addresses (because two local interface IDs from different links or sites may collide easily), more precisely with link local IPv6 addresses, since it may be too much to attempt duplicate token checks when used for a site address. > A > different way to create the interface ID is to use tunnel-specific > tokens, > e.g., the tokens 1 and 2 for each end of the tunnel, or perhaps large, > randomly-generated, non-global tokens. This latter approach is what > Bob > was referring to in his earlier draft. Is that what you are objecting > to, > or are you talking about something else? > I do not think this is needed. At this point I think the tunnel specifications are right as they are. It seems to make sense to attach to a tunnel interface one of the underlying interface addresses, since the tunnel entry point interface receives and sends out packets though the underlying interface, and topologically is on the same subnet with it. > Confused, > Steve > Thanks, Alex > --------------------------------------------- > Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 > Fax: 508/287-2810 > Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 10 17:47:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA03165; Tue, 10 Jun 1997 17:38:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA03158; Tue, 10 Jun 1997 17:37:59 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA16325; Tue, 10 Jun 1997 17:38:44 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA02043 for ; Tue, 10 Jun 1997 17:40:35 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id RAA14151; Tue, 10 Jun 1997 17:37:59 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Jun 1997 17:38:04 -0700 To: "Conta, Alex" From: Steve Deering Subject: (IPng 3968) Re: Node generated EUI-64s - was the "u/l bit" Cc: "'hinden@ipsilon.com'" , ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2831 At 4:04 PM -0700 6/10/97, Conta, Alex wrote: > The IPv6 tunneling draft specifies that: > > The tunnel entry-point node address is one of the valid IPv6 > unicast addresses of the entry-point node ... Yes, to establish/configure a tunnel, one must specify its endpoints using pre-existing IPv6 unicast addresses. But the act of configuring the tunnel creates a new link, with a new (virtual) interface at each end. Those new interfaces may be left unnumbered if they exist within routers, since IPv6 permits routers (but not hosts) to have unnumbered interfaces. If those new interfaces *are* assigned IPv6 unicast addresses, then the assigned addresses must be ones that are *not* assigned to any other interface, real or virtual, within the same address scope. In particular, a tunnel endpoint interface must not be assigned a global IPv6 unicast address that has been assigned to any other interface in the IPv6 Internet, since each such address by definition identifies a single interface. Only anycast and multicast addresses can be assigned to multiple interfaces within their scope. > So my comment to Bob was that a tunnel interface is not assigned a > separate interface ID, but rather takes altogether the IPv6 address, > including the interface ID of the real underlying interface. I disagree, as explained above. > I am not sure if this was discussed on the IPng list, but it > seems to me that the "local token" can be used safely only with > non-global IPv6 addresses (because two local interface IDs from > different links or sites may collide easily), more precisely with link > local IPv6 addresses, since it may be too much to attempt duplicate > token checks when used for a site address. No, that's not right. Local tokens are only required to be unique within a single (real or virtual) link, regardless of the scope of IPv6 addresses into which they are embedded. For addresses of scope greater than link- local, the higher-order parts of the IPv6 address (e.g., the subnet field) ensure that an IPv6 address from one link can never be the same as an IPv6 address from another link. > the tunnel entry point interface receives and sends out packets though > the underlying interface, and topologically is on the same subnet with > it. No, no, no. The tunnel is topologically its own separate link/subnet. At least that's the model I thought we had agreed on -- the "virtual link" model of tunnels. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 02:02:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA03586; Wed, 11 Jun 1997 01:54:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA03579; Wed, 11 Jun 1997 01:54:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA08642; Wed, 11 Jun 1997 01:54:51 -0700 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA28363 for ; Wed, 11 Jun 1997 01:56:41 -0700 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id LAA21151; Wed, 11 Jun 1997 11:55:52 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id LAA20810; Wed, 11 Jun 1997 11:55:51 +0300 (EET DST) Message-Id: <199706110855.LAA20810@harakka.cs.tut.fi> Subject: (IPng 3969) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: from Steve Deering at "Jun 10, 97 12:46:08 pm" To: deering@cisco.com (Steve Deering) Date: Wed, 11 Jun 1997 11:55:50 +0300 (EET DST) Cc: int-serv@isi.edu, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2814 Obviously we have a problem here. (actually, two problems) We'd like to mark RSVP excess traffic (and also other misbehaving flows or just perhaps poorly-paying customers' packets) with some kind of "this packet can be dropped in the case of (or in danger of) congestion" in the router interface. Another problem is that applications don't have the ability to mark packets with priority information. (note that RSVP is not available everywhere and it can not be used for every videophone etc) Why not solve both these problems at the same time. One bit is enough for that. This bit (let's call it for example R bit) can be set by router or by end-terminal application. Router marks packets with R=1 for packets which exceeds their RSVP token packet rate, or for poorly-paying customers in some cases. Applications can set this bit anytime. Obvious situation is for future audio/video applications for which some packets (GOP headers etc) are very important while some (enhancement layer data) are not very important. As discussed in IPng mailing list (in March 97), many people opposed applications capability to mark some packets with higher priority. This new scenario (R=1) is an opposite strategy which can not harm network although someone can argue that this encourages applications to send unnecessary data to network. However, I don't believe that: they send it anyway. Some kind of consensus in IPng was reached (unfortunately) that applications are not allowed to change priority field bits and the usage of priority field is left to operators private purposes. For those who do not know; IPv6 includes 4 bits for priority field of which one is (as currently proposed) for Interactive bit and 3 for operator private use. Still, many people believe that (non-RSVP) applications should have the ability to mark packets with some kind of priority/drop information and since priority field is out of the question, why not using one bit from version field. (First or last bit from version field) So, I recommend that one bit from IPv6 version field is taken to this kind of drop bit, set by either router or application. The main usage of this bit is to mark RSVP excess traffic by router, and mark enhancement data (e.g. for video) by application. As far as I can see, this requires only minimal changes to IPv6 header compression proposal. Petri Koskelainen Nokia Research Center Tampere, Finland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 06:08:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03788; Wed, 11 Jun 1997 06:00:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03781; Wed, 11 Jun 1997 06:00:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA24642; Wed, 11 Jun 1997 06:00:59 -0700 Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA05199 for ; Wed, 11 Jun 1997 06:02:50 -0700 Received: (from sob@localhost) by newdev.harvard.edu (8.7.6/8.6.10-MT4.00) id IAA01384; Wed, 11 Jun 1997 08:59:47 -0400 (EDT) Date: Wed, 11 Jun 1997 08:59:47 -0400 (EDT) From: Scott Bradner Message-Id: <199706111259.IAA01384@newdev.harvard.edu> To: deering@cisco.com, petkos@cs.tut.fi Subject: (IPng 3970) Re: Qry on Traffic Policing (IPv6 header changes) Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 853 > So, I recommend that one bit from IPv6 version field is taken to this > kind of drop bit this sort of issue is not an easy one - there has been quite a bit of discussion in many forums about how best to deal with excess traffic - a discard OK bit is one of a number of options at this time it seems to me that the community does not have enough understanding of the complexities in this area and more research is needed before we should be off reserving bits. Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 06:22:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03826; Wed, 11 Jun 1997 06:14:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03819; Wed, 11 Jun 1997 06:13:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA26538; Wed, 11 Jun 1997 06:14:38 -0700 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA09238 for ; Wed, 11 Jun 1997 06:16:30 -0700 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id QAA00427; Wed, 11 Jun 1997 16:15:38 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id QAA24952; Wed, 11 Jun 1997 16:15:37 +0300 (EET DST) Message-Id: <199706111315.QAA24952@harakka.cs.tut.fi> Subject: (IPng 3971) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: <199706111259.IAA01384@newdev.harvard.edu> from Scott Bradner at "Jun 11, 97 08:59:47 am" To: sob@newdev.harvard.edu (Scott Bradner) Date: Wed, 11 Jun 1997 16:15:36 +0300 (EET DST) Cc: deering@cisco.com, petkos@cs.tut.fi, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1260 > > So, I recommend that one bit from IPv6 version field is taken to this > > kind of drop bit > > this sort of issue is not an easy one - there has been quite a bit > of discussion in many forums about how best to deal with excess > traffic - a discard OK bit is one of a number of options > > at this time it seems to me that the community does not have enough > understanding of the complexities in this area and more research > is needed before we should be off reserving bits. > > Scott Yes, but excess traffic is only one issue. Much more important issue is the applications ability to mark some packets with "drop this in the case of congestion" label thus increasing the propability of applications other packets delivery. Currently there is no way for applications to do so and I certainly believe that such is needed in the (near) future A/V applications. Petri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 06:44:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03873; Wed, 11 Jun 1997 06:36:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03866; Wed, 11 Jun 1997 06:36:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA00145; Wed, 11 Jun 1997 06:37:06 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA15061 for ; Wed, 11 Jun 1997 06:38:58 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id GAA12430 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/06/05-I) with ESMTP id GAA05879 Posted-Date: Wed, 11 Jun 1997 06:38:02 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id JAA23882; Wed, 11 Jun 1997 09:38:01 -0400 for Message-Id: <3.0.32.19970611093631.006ae80c@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 11 Jun 1997 09:36:31 -0400 To: "Conta, Alex" From: Dimitry Haskin Subject: (IPng 3972) Re: Node generated EUI-64s - was the "u/l bit" Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1646 At 07:04 PM 6/10/97 -0400, Conta, Alex wrote: > > >So my comment to Bob was that a tunnel interface is not assigned a >separate interface ID, but rather takes altogether the IPv6 address, >including the interface ID of the real underlying interface. I hope it is not what the tunneling spec says. For the exception of link-local addresses, there is no point for a tunnel interface to have the same address as of the underlying interface and it would violate the addressing architecture. >I do not think this is needed. At this point I think the tunnel >specifications are right as they are. It seems to make sense to attach >to a tunnel interface one of the underlying interface addresses, since >the tunnel entry point interface receives and sends out packets though >the underlying interface, and topologically is on the same subnet with >it. > No it does not make any sense -- at least not to me. A tunnel interface is a separate interface which should be identified with a separate address and may very well reside on a different subnet or no subnet at all. It may have sense for a tunnel interface to use the same interface id as of the underlying link (especially if it is globally unique) but it is as far as it goes. >Thanks, >Alex > Regards, Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 07:14:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03927; Wed, 11 Jun 1997 07:07:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03920; Wed, 11 Jun 1997 07:06:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA08664; Wed, 11 Jun 1997 07:07:36 -0700 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA23462 for ; Wed, 11 Jun 1997 07:09:28 -0700 Received: from big-dawgs.cisco.com (herndon-dhcp-107.cisco.com [171.68.53.107]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id HAA18090; Wed, 11 Jun 1997 07:07:24 -0700 (PDT) Message-Id: <3.0.1.32.19970611100718.006cd9b4@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Jun 1997 10:07:18 -0400 To: Koskelainen Petri From: Paul Ferguson Subject: (IPng 3973) Re: Qry on Traffic Policing (IPv6 header changes) Cc: sob@newdev.harvard.edu (Scott Bradner), deering@cisco.com, petkos@cs.tut.fi, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: <199706111315.QAA24952@harakka.cs.tut.fi> References: <199706111259.IAA01384@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1100 At 04:15 PM 06/11/97 +0300, Koskelainen Petri wrote: > >Yes, but excess traffic is only one issue. Much more important issue >is the applications ability to mark some packets with >"drop this in the case of congestion" label thus increasing >the propability of applications other packets delivery. > >Currently there is no way for applications to do so and I certainly >believe that such is needed in the (near) future A/V applications. > With IPv4, it is trivial to do this by using the IP precedence to weight the probability of drop in congestion instances. This can either be set by the origin application, or policed by the network ingress point. Draw your own comparisons to what is possible with IPv6. - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 07:30:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03958; Wed, 11 Jun 1997 07:16:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03942; Wed, 11 Jun 1997 07:15:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA11205; Wed, 11 Jun 1997 07:16:39 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA26121 for ; Wed, 11 Jun 1997 07:18:27 -0700 Received: from ietf.ietf.org by ietf.org id aa06791; 11 Jun 97 9:25 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3975) I-D ACTION:draft-ietf-ipngwg-ipv6-tcp-mib-00.txt Date: Wed, 11 Jun 1997 09:25:29 -0400 Message-ID: <9706110925.aa06791@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4392 --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 : IP Version 6 Management Information Base for the Transmission Control Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-tcp-mib-00.txt Pages : 6 Date : 06/10/1997 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, the most of managed objects defined in RFC 2012 are independent of which IP versions underly TCP, and only the TCP connection information is IP version-specific. 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-ietf-ipngwg-ipv6-tcp-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tcp-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: <19970610133530.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tcp-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970610133530.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 07:30:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03957; Wed, 11 Jun 1997 07:16:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03934; Wed, 11 Jun 1997 07:15:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA11165; Wed, 11 Jun 1997 07:16:34 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA26092 for ; Wed, 11 Jun 1997 07:18:22 -0700 Received: from ietf.ietf.org by ietf.org id aa06701; 11 Jun 97 9:24 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3974) I-D ACTION:draft-ietf-ipngwg-ipv6-mib-02.txt Date: Wed, 11 Jun 1997 09:24:50 -0400 Message-ID: <9706110924.aa06701@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4166 --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 : Management Information Base for IP Version 6: Textual Conventions and General Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-mib-02.txt Pages : 41 Date : 06/10/1997 This document is one in the series of documents that provide MIB definitions for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. 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-mib-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-mib-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970610131309.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-mib-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970610131309.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 07:31:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03959; Wed, 11 Jun 1997 07:16:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA03946; Wed, 11 Jun 1997 07:15:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA11225; Wed, 11 Jun 1997 07:16:42 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA26140 for ; Wed, 11 Jun 1997 07:18:30 -0700 Received: from ietf.ietf.org by ietf.org id aa06814; 11 Jun 97 9:25 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 3976) I-D ACTION:draft-ietf-ipngwg-ipv6-udp-mib-00.txt Date: Wed, 11 Jun 1997 09:25:37 -0400 Message-ID: <9706110925.aa06814@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4340 --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 : IP Version 6 Management Information Base for the User Datagram Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-udp-mib-00.txt Pages : 5 Date : 06/10/1997 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, the most of managed objects defined in RFC 2013 are independent of which IP versions underly UDP, and only the UDP listener information is IP version-specific. 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-ietf-ipngwg-ipv6-udp-mib-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-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: <19970610133927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-udp-mib-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970610133927.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 07:57:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA04032; Wed, 11 Jun 1997 07:48:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA04025; Wed, 11 Jun 1997 07:48:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA22345; Wed, 11 Jun 1997 07:49:05 -0700 Received: from diablo.cisco.com (diablo.cisco.com [171.68.223.106]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA06320 for ; Wed, 11 Jun 1997 07:50:55 -0700 Received: from big-dawgs.cisco.com (herndon-dhcp-107.cisco.com [171.68.53.107]) by diablo.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id HAA06154; Wed, 11 Jun 1997 07:49:15 -0700 (PDT) Message-Id: <3.0.1.32.19970611104912.006e7148@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Jun 1997 10:49:12 -0400 To: Steve Deering From: Paul Ferguson Subject: (IPng 3977) Re: Qry on Traffic Policing (IPv6 header changes) Cc: Koskelainen Petri , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: References: <3.0.1.32.19970611100718.006cd9b4@lint.cisco.com> <199706111315.QAA24952@harakka.cs.tut.fi> <199706111259.IAA01384@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 646 At 07:46 AM 06/11/97 -0700, Steve Deering wrote: > >With the revised definition of the IPv6 Priority field agreed to in Memphis, >the same is possible with IPv6. > Not that I've been following very closely (I haven't), is this modification documented yet? - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 08:00:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA04059; Wed, 11 Jun 1997 07:50:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA04052; Wed, 11 Jun 1997 07:50:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA23066; Wed, 11 Jun 1997 07:51:16 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA06957 for ; Wed, 11 Jun 1997 07:53:06 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id HAA12563; Wed, 11 Jun 1997 07:46:45 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <3.0.1.32.19970611100718.006cd9b4@lint.cisco.com> References: <199706111315.QAA24952@harakka.cs.tut.fi> <199706111259.IAA01384@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jun 1997 07:46:59 -0700 To: Paul Ferguson From: Steve Deering Subject: (IPng 3978) Re: Qry on Traffic Policing (IPv6 header changes) Cc: Koskelainen Petri , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 827 At 7:07 AM -0700 6/11/97, Paul Ferguson wrote: > With IPv4, it is trivial to do this by using the IP precedence to > weight the probability of drop in congestion instances. This can > either be set by the origin application, or policed by the network > ingress point. > > Draw your own comparisons to what is possible with IPv6. With the revised definition of the IPv6 Priority field agreed to in Memphis, the same is possible with IPv6. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 08:26:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04230; Wed, 11 Jun 1997 08:17:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04223; Wed, 11 Jun 1997 08:17:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA00471; Wed, 11 Jun 1997 08:18:34 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA15445 for ; Wed, 11 Jun 1997 08:20:23 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id IAA13665; Wed, 11 Jun 1997 08:13:46 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199706110855.LAA20810@harakka.cs.tut.fi> References: from Steve Deering at "Jun 10, 97 12:46:08 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jun 1997 08:14:01 -0700 To: Koskelainen Petri From: Steve Deering Subject: (IPng 3979) Re: Qry on Traffic Policing (IPv6 header changes) Cc: int-serv@isi.edu, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1506 At 1:55 AM -0700 6/11/97, Koskelainen Petri wrote: > As discussed in IPng mailing list (in March 97), many people > opposed applications capability to mark some packets with higher > priority. This new scenario (R=1) is an opposite strategy which can not > harm network although someone can argue that this encourages applications > to send unnecessary data to network. It can harm the carrying capacity of the network. The undeliverable packets consume bandwidth on all the hops up to the point at which they are dropped. That bandwidth would otherwise be available for more productive use by other flows. > However, I don't believe that: they send it anyway. Without router support for drop priority, the transmission of excess packets into a congestion point causes the "more important" packets to be equally vulnerable to loss as the "less important" packets. Thus, there is an incentive for the applications to be designed not to send less important packets into congested paths. If they "send them anyway", they will harm not only other flows in the Internet, but also their own "more important" traffic. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 08:33:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04252; Wed, 11 Jun 1997 08:23:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04245; Wed, 11 Jun 1997 08:23:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA01940; Wed, 11 Jun 1997 08:23:49 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA17419 for ; Wed, 11 Jun 1997 08:25:41 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id IAA14283; Wed, 11 Jun 1997 08:24:48 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <3.0.1.32.19970611104912.006e7148@lint.cisco.com> References: <3.0.1.32.19970611100718.006cd9b4@lint.cisco.com> <199706111315.QAA24952@harakka.cs.tut.fi> <199706111259.IAA01384@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jun 1997 08:25:02 -0700 To: Paul Ferguson From: Steve Deering Subject: (IPng 3980) Re: Qry on Traffic Policing (IPv6 header changes) Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1308 At 7:49 AM -0700 6/11/97, Paul Ferguson wrote: > At 07:46 AM 06/11/97 -0700, Steve Deering wrote: > > > > >With the revised definition of the IPv6 Priority field agreed to in Memphis, > >the same is possible with IPv6. > > > > Not that I've been following very closely (I haven't), is this > modification documented yet? Only in the WG minutes, so far. (I plan to have a new version of the base IPv6 spec out before Munich.) Here's what the minutes say: - Declare that 4 bits of Priority are rewritable by routers/ISPs for private purposes (and exclude from authentication header). - Priority bits have no significance to receivers - Convention: Sender sets low order bit to mean interactive traffic. o Delay more important than throughput o Suggests that routers/ISPs use other bits before touching the "interactive bit". o Affects queuing only, not routing (since re-writable). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 11:04:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04531; Wed, 11 Jun 1997 10:54:58 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA04524; Wed, 11 Jun 1997 10:54:54 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA10166; Wed, 11 Jun 1997 10:56:55 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA06315; Wed, 11 Jun 1997 10:55:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04390; Wed, 11 Jun 1997 09:57:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA27226; Wed, 11 Jun 1997 09:58:05 -0700 Received: from unir.corp ([207.32.128.74]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA18285 for ; Wed, 11 Jun 1997 09:59:45 -0700 Received: from webster.unety.net (webster.unety.net [207.32.128.58]) by unir.corp (8.7.3/8.7.3) with SMTP id LAA08436; Wed, 11 Jun 1997 11:47:33 -0500 (CDT) Received: by webster.unety.net with Microsoft Mail id <01BC765E.4C060E80@webster.unety.net>; Wed, 11 Jun 1997 11:55:03 -0500 Message-ID: <01BC765E.4C060E80@webster.unety.net> From: Jim Fleming To: "deering@cisco.com" , "petkos@cs.tut.fi" , "'Scott Bradner'" Cc: "int-serv@ISI.EDU" , "ipng@sunroof.eng.sun.com" Subject: (IPng 3982) RE: Qry on Traffic Policing (IPv6 header changes) Date: Wed, 11 Jun 1997 11:55:01 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1709 On Wednesday, June 11, 1997 3:59 AM, Scott Bradner[SMTP:sob@newdev.harvard.edu] wrote: @ > So, I recommend that one bit from IPv6 version field is taken to this @ > kind of drop bit @ @ this sort of issue is not an easy one - there has been quite a bit @ of discussion in many forums about how best to deal with excess @ traffic - a discard OK bit is one of a number of options @ @ at this time it seems to me that the community does not have enough @ understanding of the complexities in this area and more research @ is needed before we should be off reserving bits. @ I agree. It is hard to design good protocols bit by bit. It is sort of a shame that more research platforms do not exist to allow for the global testing of new ideas. There are companies willing to make investments in these efforts but in some cases they are prevented from proceeding because they do not have access to basic Internet resources. The universities control those resources and use the NSF to prevent commercial access. Despite these repressive policies of the Internet leadership, new frontiers in protocol design still continue behind the scenes. At some point the commercial interests in new and better approaches will outweigh the academic's ability to control the resources. -- Jim Fleming Unir Corporation http://www.Unir.Corp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 11:23:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04570; Wed, 11 Jun 1997 11:13:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04563; Wed, 11 Jun 1997 11:13:34 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA20386; Wed, 11 Jun 1997 11:14:17 -0700 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA14602 for ; Wed, 11 Jun 1997 11:16:04 -0700 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id VAA10594; Wed, 11 Jun 1997 21:15:16 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id VAA01926; Wed, 11 Jun 1997 21:15:15 +0300 (EET DST) Message-Id: <199706111815.VAA01926@harakka.cs.tut.fi> Subject: (IPng 3983) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: from Steve Deering at "Jun 11, 97 08:25:02 am" To: deering@cisco.com (Steve Deering) Date: Wed, 11 Jun 1997 21:15:15 +0300 (EET DST) Cc: pferguso@cisco.com, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1653 > > >With the revised definition of the IPv6 Priority field agreed to > > >in Memphis, the same is possible with IPv6. > > > > > > > Not that I've been following very closely (I haven't), is this > > modification documented yet? > > Only in the WG minutes, so far. (I plan to have a new version of the base > IPv6 spec out before Munich.) Here's what the minutes say: > > - Declare that 4 bits of Priority are rewritable by routers/ISPs for > private purposes (and exclude from authentication header). Yes, perhaps senders may set priority bits but it makes no sense since routers rewrite them usually. So, why bother setting priority by application ? About "unnecessary packets". Always (!) some packets are more important than others! Your codec can produce 20 or 200 packets/s but still, some packets are more important than others! Of course you should reduce rate for congested path but the problem is still same. Briefly, there exists no equality between A/V codec packets. No matter how small bitrate you have (even 1 kb/s), packets have still different importance. So, this (drop bit) does not encourage sending unnecessary packets. All A/V applications should reduce bitrate as much as possible but the basic problem is still same! -- Petri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 12:09:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA04690; Wed, 11 Jun 1997 12:00:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA04683; Wed, 11 Jun 1997 12:00:27 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA05100; Wed, 11 Jun 1997 12:00:40 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA29621 for ; Wed, 11 Jun 1997 12:02:20 -0700 Received: from gungnir.fnal.gov ("port 48869"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-8 #3998) id <01IJY63FWGJO000BKZ@FNAL.FNAL.GOV>; Wed, 11 Jun 1997 14:01:14 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id OAA17181; Wed, 11 Jun 1997 14:01:13 -0500 Date: Wed, 11 Jun 1997 14:01:13 -0500 From: Matt Crawford Subject: (IPng 3984) Re: Qry on Traffic Policing (IPv6 header changes) In-reply-to: "11 Jun 1997 21:15:15 +0300." <"199706111815.VAA01926"@harakka.cs.tut.fi> To: Koskelainen Petri Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Message-id: <199706111901.OAA17181@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{ No matter how small bitrate you have (even 1 kb/s), packets have still > different importance. > > So, this (drop bit) does not encourage sending unnecessary packets. I agree with your premise, but not your conclusion. I think the more generally agreed conclusion would be, the application should send as much useful data as can reach the destination. If that amount is less than "all the data," the application should choose wisely which data to send. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 12:19:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA04707; Wed, 11 Jun 1997 12:09:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA04699; Wed, 11 Jun 1997 12:09:00 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08101; Wed, 11 Jun 1997 12:08:12 -0700 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA02071 for ; Wed, 11 Jun 1997 12:09:39 -0700 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id WAA12190; Wed, 11 Jun 1997 22:08:49 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id WAA02243; Wed, 11 Jun 1997 22:08:47 +0300 (EET DST) Message-Id: <199706111908.WAA02243@harakka.cs.tut.fi> Subject: (IPng 3985) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: <199706111901.OAA17181@gungnir.fnal.gov> from Matt Crawford at "Jun 11, 97 02:01:13 pm" To: crawdad@FNAL.GOV (Matt Crawford) Date: Wed, 11 Jun 1997 22:08:47 +0300 (EET DST) Cc: petkos@cs.tut.fi, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1047 > > No matter how small bitrate you have (even 1 kb/s), packets have still > > different importance. > > > > So, this (drop bit) does not encourage sending unnecessary packets. > > I agree with your premise, but not your conclusion. I think the more > generally agreed conclusion would be, the application should send as > much useful data as can reach the destination. If that amount is > less than "all the data," the application should choose wisely which > data to send. > Yes..You are right. However, what if destination is multicast group with heteregenous receivers ? Anyway, drop bit is needed because packets have always different importance. Petri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 13:06:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA04811; Wed, 11 Jun 1997 12:57:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA04803; Wed, 11 Jun 1997 12:57:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA24290; Wed, 11 Jun 1997 12:57:43 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA17255 for ; Wed, 11 Jun 1997 12:59:32 -0700 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id MAA28433 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP id VAA09246 Posted-Date: Wed, 11 Jun 1997 21:56:36 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA19524; Wed, 11 Jun 1997 15:56:34 -0400 for Message-Id: <3.0.32.19970611155504.006b8ca8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 11 Jun 1997 15:55:05 -0400 To: Matt Crawford From: Dimitry Haskin Subject: (IPng 3986) Re: Qry on Traffic Policing (IPv6 header changes) Cc: Koskelainen Petri , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 881 At 02:01 PM 6/11/97 -0500, Matt Crawford wrote: >I agree with your premise, but not your conclusion. I think the more >generally agreed conclusion would be, the application should send as >much useful data as can reach the destination. If that amount is >less than "all the data," the application should choose wisely which >data to send. Is it that easy?! Does the application always know how much of its data can reach the destination at any particular moment if statistical multiplexing is used? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 15:42:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05198; Wed, 11 Jun 1997 15:32:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05191; Wed, 11 Jun 1997 15:32:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA10867; Wed, 11 Jun 1997 15:33:07 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA05705 for ; Wed, 11 Jun 1997 15:33:54 -0700 Received: from gungnir.fnal.gov ("port 49270"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-8 #3998) id <01IJYBBJI0O6000BKZ@FNAL.FNAL.GOV>; Wed, 11 Jun 1997 16:31:19 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA17531; Wed, 11 Jun 1997 16:31:18 -0500 Date: Wed, 11 Jun 1997 16:31:18 -0500 From: Matt Crawford Subject: (IPng 3987) Re: Qry on Traffic Policing (IPv6 header changes) In-reply-to: "11 Jun 1997 22:08:47 +0300." <"199706111908.WAA02243"@harakka.cs.tut.fi> To: Koskelainen Petri , Dimitry Haskin Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Message-id: <199706112131.QAA17531@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{ > ... the application should send as much useful data as can reach > > the destination. If that amount is less than "all the data," the > > application should choose wisely which data to send. > > Yes..You are right. > However, what if destination is multicast group with heteregenous receivers ? Then the very best thing to do is to send the different "grades" of packets to different multicast addresses, and have the receivers only join as many groups as they can actually get. > Anyway, drop bit is needed because packets have always different > importance. If you use a drop-preference bit, then you are sending packets which you believe may not make it all the way to the destination. Once more ... suppose your packets can be classified at the source into ten grades of importance, and call those grades 1 through 10 (most important to least). Suppose also that you determine at a certain time that the network is capable of delivering only enough bits per second to include all the packets of grades 1 through 4 and some of grade 5. Then that's what you should send -- all of 1 through 4 and some of grade 5. If you don't do that, then suppose you marked only grades 8 through 10 with your drop bit. You waste network bandwidth up to the bottleneck carrying all of 1 through 10, then when you get to the bottlneck you lose all of 8 through 10, and some of 1 through 7 at random. That's not the best you could have achieved. Now suppose you marked all of classes 3 through 10 with your drop bit. At the bottleneck you retain all of classes 1 and 2, and some packets randomly in classes 3 through 10. Again, not an optimal mix. Conclusion: to get the best result, put the smarts at the endpoints and send exactly the data which you choose and which the network can carry. And Dimitry says: > Is it that easy?! Does the application always know how much of its > data can reach the destination at any particular moment if > statistical multiplexing is used? TCP does a fair job of figuring this out. If you get to design your protocol today from scratch, you should be able to do it even more efficiently, yes? Or am I naive? Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 17:48:55 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA05907; Wed, 11 Jun 1997 17:40:20 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA05900; Wed, 11 Jun 1997 17:40:09 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA16947; Wed, 11 Jun 1997 17:40:51 -0700 Received: from mailhost2.BayNetworks.COM ([134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA10268 for ; Wed, 11 Jun 1997 17:42:33 -0700 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id RAA01899 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP id CAA14386 Posted-Date: Thu, 12 Jun 1997 02:39:40 +0200 (MET DST) Received: from dhaskin.baynetworks.com (eng_ppp28 [192.32.171.168]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA22301; Wed, 11 Jun 1997 20:39:36 -0400 for Message-Id: <3.0.32.19970611204112.0069b8a8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 11 Jun 1997 20:41:15 -0400 To: Matt Crawford , Koskelainen Petri , Dimitry Haskin From: Dimitry Haskin Subject: (IPng 3988) Re: Qry on Traffic Policing (IPv6 header changes) Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3735 Matt, I think it's long understood that regulating traffic flows as close to their sources as possible is a good thing. The question is if it always possible or, more importantly, economical to provide congestion feedback on the timescale and granularity that guaranty that no data discard would be necessary. And in many cases it may not be feasible for one reason or other to extend such a feedback all the way to each traffic generating application. The most likely the traffic admission control/excess discard is done at edge routers or switches. It seems that in such a case a bit saying "if you have to drop my packet I'd suffer less if this packet is dropped" could be useful. Dimitry At 04:31 PM 6/11/97 -0500, Matt Crawford wrote: >Petri says: >> > ... the application should send as much useful data as can reach >> > the destination. If that amount is less than "all the data," the >> > application should choose wisely which data to send. >> >> Yes..You are right. >> However, what if destination is multicast group with heteregenous receivers ? > >Then the very best thing to do is to send the different "grades" of >packets to different multicast addresses, and have the receivers >only join as many groups as they can actually get. > >> Anyway, drop bit is needed because packets have always different >> importance. > >If you use a drop-preference bit, then you are sending packets which >you believe may not make it all the way to the destination. Once >more ... suppose your packets can be classified at the source into >ten grades of importance, and call those grades 1 through 10 (most >important to least). Suppose also that you determine at a certain >time that the network is capable of delivering only enough bits per >second to include all the packets of grades 1 through 4 and some of >grade 5. Then that's what you should send -- all of 1 through 4 and >some of grade 5. > >If you don't do that, then suppose you marked only grades 8 through >10 with your drop bit. You waste network bandwidth up to the >bottleneck carrying all of 1 through 10, then when you get to the >bottlneck you lose all of 8 through 10, and some of 1 through 7 at >random. That's not the best you could have achieved. > >Now suppose you marked all of classes 3 through 10 with your drop >bit. At the bottleneck you retain all of classes 1 and 2, and some >packets randomly in classes 3 through 10. Again, not an optimal >mix. > >Conclusion: to get the best result, put the smarts at the endpoints >and send exactly the data which you choose and which the network can >carry. > >And Dimitry says: >> Is it that easy?! Does the application always know how much of its >> data can reach the destination at any particular moment if >> statistical multiplexing is used? > >TCP does a fair job of figuring this out. If you get to design your >protocol today from scratch, you should be able to do it even more >efficiently, yes? Or am I naive? > Matt >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 18:11:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA05956; Wed, 11 Jun 1997 18:02:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA05949; Wed, 11 Jun 1997 18:02:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA21122; Wed, 11 Jun 1997 18:02:58 -0700 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA15370 for ; Wed, 11 Jun 1997 18:04:46 -0700 Received: from big-dawgs.cisco.com (herndon-dhcp-107.cisco.com [171.68.53.107]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id SAA08986; Wed, 11 Jun 1997 18:01:33 -0700 (PDT) Message-Id: <3.0.1.32.19970611210131.006a7cfc@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 11 Jun 1997 21:01:31 -0400 To: Matt Crawford From: Paul Ferguson Subject: (IPng 3989) Re: Qry on Traffic Policing (IPv6 header changes) Cc: Koskelainen Petri , Dimitry Haskin , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: <199706112131.QAA17531@gungnir.fnal.gov> References: <"11 Jun 1997 22:08:47 +0300." <"199706111908.WAA02243"@harakka.cs.tut.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1473 At 04:31 PM 06/11/97 -0500, Matt Crawford wrote: > >Conclusion: to get the best result, put the smarts at the endpoints >and send exactly the data which you choose and which the network can >carry. > There are two issues here, each are equally valid, but it appears we are talking past one another. One might suggest that having applications support to set priority is a fundamental design goal, whether one decides to honor it or not is a matter of policy. I know some service providers who would be happy with the downstream application setting priority -- they would just require adequate measurement tools to bill them for the volume of 'premium' class traffic as opposed to the volume of 'best effort' traffic. Que sera, sera. On the other hand, there are those of us who would prefer to engineer policing mechanisms into the network to guard against downstream applications setting priority higher than I would care for them to, so I can properly do capacity engineering in my network. This is a policy issue -- we should simply develop the protocol support to handle both. - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 18:51:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA06031; Wed, 11 Jun 1997 18:43:07 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA06024; Wed, 11 Jun 1997 18:42:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA29109; Wed, 11 Jun 1997 18:43:39 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA24618 for ; Wed, 11 Jun 1997 18:45:29 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 11 Jun 1997 21:44:12 -0400 Message-ID: From: "Conta, Alex" To: "'ipng@sunroof.eng.sun.com'" Cc: "'hinden@ipsilon.com'" , "'deering@cisco.com'" Subject: (IPng 3990) Re: Node generated EUI-64s - was the "u/l bit" Date: Wed, 11 Jun 1997 21:44:11 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5165 > I and Steve had an off-line conversation that clarified the issues. > > The details follow (hope no indentation problems): > > ... In particular, a tunnel endpoint interface must not be assigned > a global IPv6 unicast address that has been assigned to any other > interface in the IPv6 Internet, since each such address by definition > identifies a single interface. Only anycast and multicast addresses can > be assigned to multiple interfaces within their scope. Only anycast and > multicast addresses can be assigned to multiple interfaces within their > scope. > I took the architecture documents rules as applying to physical > interfaces - see exception [1] in the Addressing model in the address > architecture doc - and not to tunnel pseudo-interfaces overlying a > physical interface. > > Good we clear this up. I get now Bob's remark in a previous > message(-:. > > Perhaps if the paragraph(s) that refer(s) to this specifically said > that > "interfaces" implies all interfaces regardless of physical, or virtual > or pseudo, etc.,..., etc.,... things would be clearer? It is clear for > me now, so I do not care one way or another. > No, that's not right. Local tokens are only required to be unique within > a single (real or virtual) link, regardless of the scope of IPv6 > addressesinto which they are embedded. For addresses of scope greater than > link-local, the higher-order parts of the IPv6 address (e.g., the subnet > field) ensure that an IPv6 address from one link can never be the same as > an IPv6 address from another link. > Right - no argument regarding the unicity of the IPv6 address. I was > alluding to the use of the interface ID in identifying a PCB. Local > tokens with global addresses may collide: restricting local tokens to > local or site addresses seems a simple way to eliminate the possible > collisions affecting the PCB lookup, while keeping the PCB lookup slim > - which I care a lot about - i.e. keep out the need for special case > code. Introducing such a restriction is acceptable or can be made > acceptable? > > You convinced me the answer is NO. > >> the tunnel entry point interface receives and sends out packets though > >> the underlying interface, and topologically is on the same subnet > with > >> it. > > No, no, no. The tunnel is topologically its own separate link/subnet. > At least that's the model I thought we had agreed on -- the "virtual link" > model of tunnels. > Steve > I followed a model in which a tunnel is configured at the entry point > node > as a unidirectional path, with no need of awareness or acknowledgment > from the exit point node. The need for such awareness/acknowledgment > seem to be implied by a distinct IPv6 address/subnet. This model > presents a simplification, as well as not requiring an additional > subnet/prefix and pair of IPv6 addresses, and designing/specifying and > using a control/negotiating protocol for defining the end point IPv6 > addresses - see the tunneling specs. > > Furthermore, given that a tunnel pseudo-interface (PS-IF) cannot exist > by itself, and it is always overlaid on the top of a physical > interface (PIF) on a "real link", the tunnel PS-IF and its underlying > PIF can be seen as being in "reality" on the same "real" link/subnet, > with the "virtual link" linking two distinct "real subnets", which is > allowed in IPv6. This model worked very well in my implementation, > made it very easy to stack tunnel pseudo-interfaces on the top of each > other, and in particular attaching distinct tunnels to distinct IPv6 > addresses of one physical interface; it also simplified the links > among structures and minimized the number of fields in the address > structures. > > From our off-line conversation it appears that having a distinct > tunnel IPv6 > address/subnet provides the ability to send tunneled/untunneled > packets > back to the tunnel entry point node on different paths based on the > fact > that distinct PS-IF and PIF addresses create the appearance of > different > (non-related) interfaces. Additionally it allows routing protocols > driven > dynamic route entries creation for tunnel PS-IFs. Both would be more > difficult to realize if PS-IF and PIF addresses were the same. The > distinct address still preserves the unidirectional character of the > configuration. > > Thanks, > Alex > > --------------------------------------------- > Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 > Fax: 508/287-2810 > Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 > > > --------------------------------------------- > Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 > Fax: 508/287-2810 > Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 19:33:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA06079; Wed, 11 Jun 1997 19:25:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA06072; Wed, 11 Jun 1997 19:25:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA04250; Wed, 11 Jun 1997 19:26:22 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA03232 for ; Wed, 11 Jun 1997 19:28:15 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 11 Jun 1997 22:26:59 -0400 Message-ID: From: "Conta, Alex" To: ipng@sunroof.eng.sun.com Subject: (IPng 3991) Re: Node generated EUI-64s - was the "u/l bit" Date: Wed, 11 Jun 1997 22:26:57 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1769 > ---------- > From: > owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] > Sent: Wednesday, June 11, 1997 9:36 AM > To: Conta, Alex > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 3972) Re: Node generated EUI-64s - was the "u/l > bit" > > > >including the interface ID of the real underlying interface. > > I hope it is not what the tunneling spec says. > If it did, you would have caught it (-:. > For the exception of > link-local addresses, there is no point for a tunnel interface to have > the > same address as of the underlying interface and it would violate the > addressing architecture. > Assuming that someone would care to have a tunnel between two nodes on the same link. Not that you convinced me (-:, but I do agree. ... > A tunnel interface is a separate interface which should be identified > with a separate address and may very well reside on a different subnet > > Agree. Or on the same subnet, but still different address. You say "should" which makes me say hmmm..... > or no subnet at all. > Have address but no subnet at all? you mean zero prefix? I am not sure I understand this. ... > Regards, > Dimitry > Thanks, Alex --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 20:16:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA06166; Wed, 11 Jun 1997 20:08:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA06159; Wed, 11 Jun 1997 20:08:07 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA08371; Wed, 11 Jun 1997 20:08:51 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA10645 for ; Wed, 11 Jun 1997 20:10:42 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 11 Jun 1997 23:09:26 -0400 Message-ID: From: "Conta, Alex" To: Dimitry Haskin Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 3992) Re: Qry on Traffic Policing (IPv6 header changes) Date: Wed, 11 Jun 1997 23:09:23 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1788 > ---------- > From: > owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] > Sent: Wednesday, June 11, 1997 8:41 PM > To: Matt Crawford; Koskelainen Petri; Dimitry Haskin > Cc: int-serv@ISI.EDU; ipng@sunroof.Eng.Sun.COM > Subject: (IPng 3988) Re: Qry on Traffic Policing (IPv6 header > changes) > > Matt, > ... > And in many cases it may not be feasible for one reason or > other to extend such a feedback all the way to each traffic generating > application. The most likely the traffic admission control/excess > discard > is done at edge routers or switches. > Dimitry, You seem to imply that such a feedback would exist between downstream and upstream routers or switches? Or do you assume that the edge routers/ switches would be the first to be congested? Did you have certain combinations in mind? like router to router, router to switch , switch to router, switch to switch, the same or different feedback depending on router or switch? would all switches provide this feedback? what about a case in which a non-congested switch that drops a packet is down stream from the congested switch that dropped a cell? Would you be more specific? .... > Dimitry > Thanks, Alex --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 20:55:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA06223; Wed, 11 Jun 1997 20:47:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA06216; Wed, 11 Jun 1997 20:47:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA11874; Wed, 11 Jun 1997 20:47:58 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA16871 for ; Wed, 11 Jun 1997 20:49:50 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id UAA25346; Wed, 11 Jun 1997 20:48:25 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199706111815.VAA01926@harakka.cs.tut.fi> References: from Steve Deering at "Jun 11, 97 08:25:02 am" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jun 1997 20:48:40 -0700 To: Koskelainen Petri From: Steve Deering Subject: (IPng 3993) Re: Qry on Traffic Policing (IPv6 header changes) Cc: pferguso@cisco.com, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1393 At 11:15 AM -0700 6/11/97, Koskelainen Petri wrote: > Yes, perhaps senders may set priority bits but it makes no sense > since routers rewrite them usually. That's not necessarily true. All we are saying is that the routers are free to rewrite them. We are not saying they must rewrite them, or that they must usually rewrite them. > So, this (drop bit) does not encourage sending unnecessary packets. > All A/V applications should reduce bitrate as much as possible > but the basic problem is still same! You say that all A/V applications should reduce bitrate as much as possible, but that takes design and programming effort and if there is no measurable benefit for exerting that effort, the application designers won't do it. We are long past the point where we can count on the sense of community responsibility to ensure that applications are well-behaved -- we have to design the system so that acting in ones own best interest serves, rather than harms, the overall behavior of the system. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 21:19:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA06352; Wed, 11 Jun 1997 21:11:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA06345; Wed, 11 Jun 1997 21:11:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA14594; Wed, 11 Jun 1997 21:12:00 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA21043 for ; Wed, 11 Jun 1997 21:13:51 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id VAA26155; Wed, 11 Jun 1997 21:12:31 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <3.0.32.19970611204112.0069b8a8@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 11 Jun 1997 21:12:44 -0700 To: Dimitry Haskin From: Steve Deering Subject: (IPng 3994) Re: Qry on Traffic Policing (IPv6 header changes) Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1186 At 5:41 PM -0700 6/11/97, Dimitry Haskin wrote: > The question is if it always possible or, more importantly, economical > to provide congestion feedback on the timescale and granularity that > guaranty that no data discard would be necessary. No, it's not possible to guarantee that no packets are discarded, when using the Internet's "best effort" service. Adding support for a drop- preference bit would not eliminate the possibility of loss of "unmarked" packets (i.e., packets without the drop-preference bit set), since there could still be bursts of unmarked packets that exceed the bandwidth and queueing capacity of a link. Any application designed to operate over best effort service ought to be able to gracefully survive occasional packet loss, even of its "most important" packets. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 21:29:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA06367; Wed, 11 Jun 1997 21:20:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA06358; Wed, 11 Jun 1997 21:20:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA15430; Wed, 11 Jun 1997 21:20:47 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAA22590 for ; Wed, 11 Jun 1997 21:22:38 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Thu, 12 Jun 1997 00:21:23 -0400 Message-ID: From: "Conta, Alex" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 3995) RE: Resend - indent probl: Node generated EUI-64s - was the "u/l bit" Date: Thu, 12 Jun 1997 00:21:21 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4942 Resend - apologies for the indentation problems - I was warned )-; Promise no resend: ----------------- > I and Steve had an off-line conversation that clarified the issues. > > The details follow (hope no indentation problems): > > > ... In particular, a tunnel endpoint interface must not be assigned > > a global IPv6 unicast address that has been assigned to any other > > interface in the IPv6 Internet, since each such address by > definition > > identifies a single interface. Only anycast and multicast addresses > can > > be assigned to multiple interfaces within their scope. Only anycast > and > > multicast addresses can be assigned to multiple interfaces within > their > > scope. > > I took the architecture documents rules as applying to physical > interfaces - see exception [1] in the Addressing model in the address > architecture doc - and not to tunnel pseudo-interfaces overlying a > physical interface. > > Good we clear this up. I get now Bob's remark in a previous > message(-:. > > Perhaps if the above mentioned paragraph(s) specifically said > that > "interfaces" applies to all interfaces regardless of physical, or > virtual > or pseudo, etc.,..., etc.,... things would be clearer? It is clear for > me now, so I do not care one way or another. > > > No, that's not right. Local tokens are only required to be unique > within > > a single (real or virtual) link, regardless of the scope of IPv6 > > addressesinto which they are embedded. For addresses of scope > greater > than > > link-local, the higher-order parts of the IPv6 address (e.g., the > subnet > > field) ensure that an IPv6 address from one link can never be the > same > as > > an IPv6 address from another link. > > Right - no argument regarding the unicity of the IPv6 address. I was > alluding to the use of the interface ID in identifying a PCB. Local > tokens with global addresses may collide: restricting local tokens to > local or site addresses seems a simple way to eliminate the possible > collisions affecting the PCB lookup, while keeping the PCB lookup slim > - which I care a lot about - i.e. keep out the need for special case > code. Introducing such a restriction is acceptable or can be made > acceptable? > > You convinced me the answer is NO. > > > >> the tunnel entry point interface receives and sends out packets > though > > >> the underlying interface, and topologically is on the same subnet > > with > > >> it. > > > > No, no, no. The tunnel is topologically its own separate > link/subnet. > > At least that's the model I thought we had agreed on -- the "virtual > link" > > model of tunnels. > > > Steve > > I followed a model in which a tunnel is configured at the entry point > node as a unidirectional path, with no need of awareness or > acknowledgment from the exit point node. The need for such > awareness/acknowledgment seem to be implied by a distinct IPv6 > address/subnet. This model presents a simplification, as well as not > requiring an additional subnet/prefix and pair of IPv6 addresses, and designing/specifying and using a control/negotiating protocol > for defining the end point IPv6 addresses - see the tunneling specs. > > Furthermore, given that a tunnel pseudo-interface (PS-IF) cannot exist > by itself, and it is always overlaid on the top of a physical > interface (PIF) on a "real link", the tunnel PS-IF and its underlying > PIF can be seen as being in "reality" on the same "real" link/subnet, > with the "virtual link" linking two distinct "real subnets", which is > allowed in IPv6. This model worked very well in my implementation, > made it very easy to stack tunnel pseudo-interfaces on the top of each > other, and in particular attaching distinct tunnels to distinct IPv6 > addresses of one physical interface; it also simplified the links > among structures and minimized the number of fields in the address > structures. > > From our off-line conversation it appears that having a distinct > tunnel IPv6 address/subnet provides the ability to send > tunneled/untunneled packets back to the tunnel entry point node on > different paths based on the fact that distinct PS-IF and PIF > addresses create the appearance of different > (non-related) interfaces. Additionally it allows routing protocols > driven > dynamic route entries creation for tunnel PS-IFs. Both would be more > difficult to realize if PS-IF and PIF addresses were the same. The > distinct address still preserves the unidirectional character of the > configuration. > > Thanks, > Alex > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 11 23:36:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA06473; Wed, 11 Jun 1997 23:28:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA06466; Wed, 11 Jun 1997 23:28:11 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA27634; Wed, 11 Jun 1997 23:28:56 -0700 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id XAA10588 for ; Wed, 11 Jun 1997 23:30:47 -0700 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id JAA26656; Thu, 12 Jun 1997 09:29:56 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id JAA08929; Thu, 12 Jun 1997 09:29:54 +0300 (EET DST) Message-Id: <199706120629.JAA08929@harakka.cs.tut.fi> Subject: (IPng 3996) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: from Steve Deering at "Jun 11, 97 08:48:40 pm" To: deering@cisco.com (Steve Deering) Date: Thu, 12 Jun 1997 09:29:54 +0300 (EET DST) Cc: petkos@cs.tut.fi, pferguso@cisco.com, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1823 > > Yes, perhaps senders may set priority bits but it makes no sense > > since routers rewrite them usually. > > That's not necessarily true. All we are saying is that the routers are > free to rewrite them. We are not saying they must rewrite them, or that > they must usually rewrite them. Hmm..Yes, if there is reasonable propability that setting priority bits will mean something (in the edge-router where most problems are) then yes. > > > So, this (drop bit) does not encourage sending unnecessary packets. > > All A/V applications should reduce bitrate as much as possible > > but the basic problem is still same! > > You say that all A/V applications should reduce bitrate as much as > possible, but that takes design and programming effort and if there is > no measurable benefit for exerting that effort, the application > designers won't do it. We are long past the point where we can count > on the sense of community responsibility to ensure that applications > are well-behaved I disagree. Reducing own bitrate will also increase the probability that the "more important" packets of that flow will get through. I think this will encourage application developers to do things right. And always, some receivers may be behind very low bitrate links, so it's better to use as small bitrate as possible. Moreover, billing may depend on the amount of packets etc. This also encourages not to send much traffic. Petri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 03:26:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA06549; Thu, 12 Jun 1997 03:18:20 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA06542; Thu, 12 Jun 1997 03:18:12 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA16713; Thu, 12 Jun 1997 03:18:54 -0700 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA15414 for ; Thu, 12 Jun 1997 03:20:48 -0700 Received: from rodan.UU.NET by relay2.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQctph07179; Thu, 12 Jun 1997 06:19:59 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQctph27184; Thu, 12 Jun 1997 06:19:57 -0400 (EDT) Message-Id: To: Steve Deering cc: Dimitry Haskin , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 3998) Re: Qry on Traffic Policing (IPv6 header changes) In-reply-to: Your message of "Wed, 11 Jun 1997 21:12:44 PDT." Date: Thu, 12 Jun 1997 06:19:57 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1281 I have to agree with the basic notion here. There is often a heirarchy of need in applications, particular multimedia apps, where some compression frames are a *lot* more important than others. the ability to express those relationships is potentially useful in helping decide "what loses" when push inevitably comes to shove. this is one of those situations where it might be hard to prefectly understand how the knowledge is used in all cases, but if you don't have the information, you certainly won't come to understand how to use it more effectively. so lemme suggest something to be shot at (draw the fire, Steve (grin)).... there should be TWO DE bits - one for expressing Application sensitivity and one for use downstream by site-egress traffic shaping and policing (working in conjunction with packet priority coloring). yours for controllably more-differentiated service.... -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 07:25:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06824; Thu, 12 Jun 1997 07:17:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06817; Thu, 12 Jun 1997 07:17:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA16027; Thu, 12 Jun 1997 07:17:55 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA28607 for ; Thu, 12 Jun 1997 07:19:46 -0700 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost3.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id KAA06894 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP id QAA22847 Posted-Date: Thu, 12 Jun 1997 16:18:39 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA07456; Thu, 12 Jun 1997 10:18:36 -0400 for Message-Id: <3.0.32.19970612101709.006afaa4@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 12 Jun 1997 10:17:09 -0400 To: "Conta, Alex" From: Dimitry Haskin Subject: (IPng 4000) Re: Node generated EUI-64s - was the "u/l bit" Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 621 Alex, >> or no subnet at all. >> >Have address but no subnet at all? you mean zero prefix? I am not sure I >understand this. > A tunnel interface may have no global or site-local address. I've a lot of those on my 6bone router. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 08:02:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06845; Thu, 12 Jun 1997 07:54:07 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06838; Thu, 12 Jun 1997 07:53:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA26369; Thu, 12 Jun 1997 07:54:39 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA08387 for ; Thu, 12 Jun 1997 07:56:33 -0700 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost3.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id LAA08567 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP id QAA24051 Posted-Date: Thu, 12 Jun 1997 16:55:24 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA13459; Thu, 12 Jun 1997 10:55:23 -0400 for Message-Id: <3.0.32.19970612105356.006afaa4@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 12 Jun 1997 10:53:56 -0400 To: "Conta, Alex" From: Dimitry Haskin Subject: (IPng 4001) Re: Qry on Traffic Policing (IPv6 header changes) Cc: Dimitry Haskin , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1528 At 11:09 PM 6/11/97 -0400, Conta, Alex wrote: > >Dimitry, > >You seem to imply that such a feedback would exist between downstream >and upstream routers or switches? Or do you assume that the edge >routers/ switches would be the first to be congested? Did you have >certain combinations in mind? like router to router, router to switch , >switch to router, switch to switch, the same or different feedback >depending on router >or switch? would all switches provide this feedback? what about a case >in which a non-congested switch that drops a packet is down stream from >the congested switch that dropped a cell? Would you be more specific? > There is many ways to provide congestion feedback from the interior of network to the edges. Some schemes are proprietary (the last time I was involved in one of such projects was quite a while ago), some are being worked out in different forums (e.g., ABR for atm). Some schemes try to prevent congestion and packet/cell drop, others react to it post fact. To be more specific I'd have to write a dissertation but there is already more of them than you probably have time to read. Regards, Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 08:31:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06993; Thu, 12 Jun 1997 08:23:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06986; Thu, 12 Jun 1997 08:23:30 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA03271; Thu, 12 Jun 1997 08:24:12 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA17370 for ; Thu, 12 Jun 1997 08:25:57 -0700 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost3.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id LAA09773 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP id RAA25052 Posted-Date: Thu, 12 Jun 1997 17:24:14 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id LAA16982; Thu, 12 Jun 1997 11:24:12 -0400 for Message-Id: <3.0.32.19970612112245.006c31f8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 12 Jun 1997 11:22:45 -0400 To: Steve Deering From: Dimitry Haskin Subject: (IPng 4002) Re: Qry on Traffic Policing (IPv6 header changes) Cc: Dimitry Haskin , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1443 At 09:12 PM 6/11/97 -0700, Steve Deering wrote: > >> The question is if it always possible or, more importantly, economical >> to provide congestion feedback on the timescale and granularity that >> guaranty that no data discard would be necessary. > >No, it's not possible to guarantee that no packets are discarded, when >using the Internet's "best effort" service. Adding support for a drop- >preference bit would not eliminate the possibility of loss of "unmarked" >packets (i.e., packets without the drop-preference bit set), since there >could still be bursts of unmarked packets that exceed the bandwidth and >queueing capacity of a link. Any application designed to operate over >best effort service ought to be able to gracefully survive occasional >packet loss, even of its "most important" packets. > >Steve > No argument here. But there are many degrees of survival. It can means to be barely alive with loss of a leg and an arm or to get away with minor scratches. I think we talking about potential ways of improving odds for the latter. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 09:11:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07042; Thu, 12 Jun 1997 08:59:13 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07035; Thu, 12 Jun 1997 08:59:09 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24035; Thu, 12 Jun 1997 09:01:07 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08095; Thu, 12 Jun 1997 08:59:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA06525; Thu, 12 Jun 1997 02:28:46 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA12618; Thu, 12 Jun 1997 02:29:28 -0700 Received: from ns10.nokia.com (ns10.nokia.com [131.228.6.229]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA08162 for ; Thu, 12 Jun 1997 02:31:22 -0700 Received: from pepper.research.nokia.com (pepper.research.nokia.com [131.228.12.3]) by ns10.nokia.com (8.8.5/8.6.9) with SMTP id MAA01494 for ; Thu, 12 Jun 1997 12:30:01 +0300 (EET DST) Received: (from smap@localhost) by pepper.research.nokia.com (8.6.13/8.6.13) id MAA02478; Thu, 12 Jun 1997 12:30:27 +0300 Received: from nrcph139.research.nokia.com(131.228.14.139) by pepper.research.nokia.com via smap (V1.3) id sma002447; Thu Jun 12 12:30:17 1997 Message-ID: <339FCFAD.C3E1F7B9@research.nokia.com> Date: Thu, 12 Jun 1997 12:30:05 +0200 From: Harri Hakulinen NRC/Tre Organization: Nokia Research Center X-Mailer: Mozilla 4.0b5 [en] (WinNT; I) MIME-Version: 1.0 To: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 4003) Re: Qry on Traffic Policing (IPv6 header changes) X-Priority: 3 (Normal) References: <1997Jun12.114700.1751.809784@nrchub01he.research.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3128 > Steve Deering wrote: > > > Petkos wrote: > > > However, I don't believe that: they send it anyway. > > > > Without router support for drop priority, the transmission of excess > > packets into a congestion point causes the "more important" packets > > to be equally vulnerable to loss as the "less important" packets. Yes, of course. Do you mean that you don't know any company, that would be interested to support this in routers ;) > Steve wrote: > > Thus, there is an incentive for the applications to be designed > > not to send less important packets into congested paths. If they > > "send them anyway", they will harm not only other flows in the > > Internet, but also their own "more important" traffic. I have seen some applications that currently send ALL their packets TWICE or so to increase receiving probability ! I don't know how well this works in the long run, but I know that you can't do that, if you have e.g. GSM-based low speed PPP-link to your videophone/laptop ( it may work "well" with xDSL or similar fast links, if you are only thinking yourself (and if all don't have as fast links) ). >Dimitry says: > Is it that easy?! Does the application always know how much of its > data can reach the destination at any particular moment if > statistical multiplexing is used? > Matt says: > TCP does a fair job of figuring this out. If you get to design your > protocol today from scratch, you should be able to do it even more > efficiently, yes? Or am I naive? > Steven L. Blake wrote: > Even if video applications are good at estimating the instantaneous > path bandwidth and adjusting their compression rate correspondingly, > packets will still get clobbered due to transient congestion > (or at sustained congestion onset), which occurs on timescales > shorter than the application's congestion reaction time. ... > Also, the burstiness of (shaped) VBR video is such that the rate > can vary by a factor of 3-5 within one frame period (~ 33 msec). > Allowing video applications to burst periodically with 2 levels > of loss priority is a very efficient means of statistically > multiplexing video sources while offering good delivery probability > for enhancement-layer packets and excellent delivery probability > for base-layer packets. I wonder if TCP or any congestion control algorithm is capable to handle this kind of bursts in efficient and fast enough way. I also wonder, that now when video people have developed VBR type codecs that should naturally fit to current Internet ( maybe with drop priority bit ), then IP people are trying to classify traffic and make reservations. Doesn't seem to make any sence to me. -- Harri.Hakulinen@research.nokia.com Video lab/Tampere/Finland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 09:13:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07052; Thu, 12 Jun 1997 09:00:20 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07045; Thu, 12 Jun 1997 09:00:15 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24168; Thu, 12 Jun 1997 09:02:18 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08126; Thu, 12 Jun 1997 09:00:42 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA06703; Thu, 12 Jun 1997 04:47:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA23099; Thu, 12 Jun 1997 04:48:12 -0700 Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA27652 for ; Thu, 12 Jun 1997 04:49:05 -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 HAA22372; Thu, 12 Jun 1997 07:45:34 -0400 Received: from tristan.watson.ibm.com (tristan.watson.ibm.com [9.2.19.112]) by mailhub1.watson.ibm.com (8.8.2/05-30-97) with SMTP id HAA37273; Thu, 12 Jun 1997 07:45:50 -0400 Received: by tristan.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA29508; Thu, 12 Jun 1997 07:45:48 -0400 Message-Id: <9706121145.AA29508@tristan.watson.ibm.com> To: Dimitry Haskin Cc: Matt Crawford , Koskelainen Petri , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 4004) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: Your message of Wed, 11 Jun 97 20:41:15 -0400. <3.0.32.19970611204112.0069b8a8@pobox> Date: Thu, 12 Jun 97 07:45:48 -0400 From: Roch Guerin Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4416 >I think it's long understood that regulating traffic flows as close to >their sources as possible is a good thing. The question is if it always >possible or, more importantly, economical to provide congestion feedback on >the timescale and granularity that guaranty that no data discard would be >necessary. And in many cases it may not be feasible for one reason or >other to extend such a feedback all the way to each traffic generating >application. The most likely the traffic admission control/excess discard >is done at edge routers or switches. It seems that in such a case a bit >saying "if you have to drop my packet I'd suffer less if this packet is >dropped" could be useful. There seems to be two issues here that are lumped together and it may be preferable to look at them separately. The first is that it is clearly best to send into the network ONLY those packets that will make it through. The second is whether there are mechanisms that, in the absence of exact knowledge of how many packets can make it through, can help ensure that the *more important* ones are more likely to succeed. Here, *more important* could be based on some applications ranking or determined by the network (edge router) as a function of some pre-agreed service contract with the user, e.g., traffic in excess of the contract are to be delivered only if resources are free. The question wrt to the first issue is how easy it is to obtain that kind of knowledge. This depends on the time scale at which congestion happens and disappears in the network, how fast the sender detects changes in congestion, etc. For example, a source-based closed-loop approach, such as what TCP uses, can only yield a very crude tracking of congestion. An approach, such as the one used by the ABR service (yes, that's an ATM service ;-) that attempts to provide explicit feedback information to the source by returning the maximum possible transmission rate on the bottleneck link, gets one step closer but does involve quite a bit of added complexity, both at the end-systems and within the network. Furthermore, it is not clear how well it works across scenarios. So, as far as I'm concerned, I don't think we can assume that an end-system can always *accurately* identify how much traffic they can successfully transmit through the network. As a result, you will be wasting bandwidth on some links to transmit packets that will be dropped later. This is why issue two is relevant, namely try to improve the odds of the more important packets making it through. You can try to do that either assuming some cooperation between the network and the end-system, or by doing things only at the end-system and viewing the network as a black box. There has been a number of proposals for the latter, e.g., variants on sending multiple copies of the more important packets based on different types of underlying coding schemes, and they do yield improvements for those applications that use them. However, you can typically get better results when there is some cooperation between the network and the end-systems, and this is where marking can play a role. For example, by using some weighted RED type buffer management approach, you can lower the chance of more important packets experiencing congestion (I believe Cisco is proposing something along those lines, based on the material on their web site). In general, there are many things that can be done using various combinations of scheduling and buffer management disciplines in the routers to take advantage of the availability of the information that marking provides. So, I do believe that marking, either by the application to indicate packets of different importance, or at the edge of the network as a function of some traffic contract, can be useful. The tricky part is that this requires consistent definitions in how the marking is used, as well as added support (scheduling and buffer mgt) in the routers to be able to take advantage of this. My 2c. Roch -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 09:58:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07300; Thu, 12 Jun 1997 09:46:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA07289; Thu, 12 Jun 1997 09:46:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25657; Thu, 12 Jun 1997 09:47:12 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA15354 for ; Thu, 12 Jun 1997 09:49:06 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Thu, 12 Jun 1997 12:47:51 -0400 Message-ID: From: "Conta, Alex" To: "'deering@cisco.com'" Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 4005) Re: Qry on Traffic Policing (IPv6 header chang es) Date: Thu, 12 Jun 1997 12:47:48 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1896 > ---------- > From: > owner-ipng@sunroof.Eng.Sun.COM[SMTP:owner-ipng@sunroof.Eng.Sun.COM] > Sent: Wednesday, June 11, 1997 11:48 PM > To: Koskelainen Petri > Cc: pferguso@cisco.com; int-serv@ISI.EDU; ipng@sunroof.Eng.Sun.COM > Subject: (IPng 3993) Re: Qry on Traffic Policing (IPv6 header > changes) > .... We are long past the point where we can count > on the sense of community responsibility to ensure that applications > are well-behaved -- we have to design the system so that acting in > ones > own best interest serves, rather than harms, the overall behavior of > the > system. > > Steve > Steve, One could notice for years how the more computer and networking technology becomes faster, cheaper, and easier available to a larger and larger number of people, the more the applications that enter the larger and continuously expending system are less and less "resources aware" or "system's overall behavior concerned". Of course the system's key mechanisms improved and improve as well in steps that look rather small, or not always easy to perceive, but can this general trend be really changed? I take it you had in mind something that is not there yet, so what is it, what would you design in the system to make "acting in ones own best interest serves the overall behavior of the system"? Alex --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 10:31:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07489; Thu, 12 Jun 1997 10:21:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07482; Thu, 12 Jun 1997 10:21:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA06801; Thu, 12 Jun 1997 10:21:58 -0700 Received: from burdell.cc.gatech.edu (burdell.cc.gatech.edu [130.207.3.207]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA26937 for ; Thu, 12 Jun 1997 10:23:54 -0700 Received: from appalachian.cc.gatech.edu (taddy@appalachian.cc.gatech.edu [130.207.8.17]) by burdell.cc.gatech.edu (8.8.4/8.6.9) with ESMTP id NAA08652; Thu, 12 Jun 1997 13:23:05 -0400 (EDT) Received: (from taddy@localhost) by appalachian.cc.gatech.edu (8.8.4/8.6.9) id NAA23913; Thu, 12 Jun 1997 13:22:58 -0400 (EDT) From: taddy@cc.gatech.edu (Rajesh Talpade) Message-Id: <199706121722.NAA23913@appalachian.cc.gatech.edu> Subject: (IPng 4006) Re: Qry on Traffic Policing (IPv6 header chang To: AConta@Lucent.com (Conta Alex) Date: Thu, 12 Jun 1997 13:22:57 -0400 (EDT) Cc: deering@cisco.com, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-Reply-To: from "Conta, Alex" at Jun 12, 97 12:47:48 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 993 > .... We are long past the point where we can count > > on the sense of community responsibility to ensure that applications > > are well-behaved -- we have to design the system so that acting in > > ones > > own best interest serves, rather than harms, the overall behavior of > > the > > system. [...] > what is it, what would you design in the system to make "acting in ones > own best interest serves the overall behavior of the system"? > Effective usage-based pricing ? Ciao. Rajesh. -- Rajesh R. Talpade (404)-315-1227 taddy@cc.gatech.edu http://www.cc.gatech.edu/grads/t/Rajesh.Talpade -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 14:05:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07770; Thu, 12 Jun 1997 13:57:07 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07763; Thu, 12 Jun 1997 13:56:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02481; Thu, 12 Jun 1997 13:57:40 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA01446 for ; Thu, 12 Jun 1997 13:59:29 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Thu, 12 Jun 1997 16:58:07 -0400 Message-ID: From: "Conta, Alex" To: "'taddy@cc.gatech.edu'" Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 4007) Re: Qry on Traffic Policing (IPv6 header chang e Date: Thu, 12 Jun 1997 16:58:07 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1092 > > what is it, what would you design in the system to make "acting in > ones > > own best interest serves the overall behavior of the system"? > > > > > Effective usage-based pricing ? Ciao. Rajesh Then the one who pays first is the (poor) user. It takes at least another development cycle until the ball is in the developer's court. As things are moving rapidly, I am not sure that the feedback is going to get in time to the right place. So, I am afraid this just makes some fat and happy. Alex --------------------------------------------- Alex Conta aconta@lucent.com Tel: 508/287-9000/ext 2842 Fax: 508/287-2810 Lucent Technologies, Inc. 300 Baker Ave., Concord, MA 01742 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 15:27:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA07941; Thu, 12 Jun 1997 15:17:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA07934; Thu, 12 Jun 1997 15:17:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA21534; Thu, 12 Jun 1997 15:17:54 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA24045 for ; Thu, 12 Jun 1997 15:19:50 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id PAA12412; Thu, 12 Jun 1997 15:18:26 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199706120629.JAA08929@harakka.cs.tut.fi> References: from Steve Deering at "Jun 11, 97 08:48:40 pm" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jun 1997 15:18:30 -0700 To: Koskelainen Petri From: Steve Deering Subject: (IPng 4008) Re: Qry on Traffic Policing (IPv6 header changes) Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2994 At 11:29 PM -0700 6/11/97, Koskelainen Petri wrote: > Reducing own bitrate will also increase the probability that > the "more important" packets of that flow will get through. Reducing or increasing the bitrate of the marked packets would not have any effect on the probability of delivery of the unmarked packets, if the bit were honoured by the routers in the way you wish, right? > I think this will encourage application developers to > do things right. What will encourage them not to send streams of undeliverable packets marked as less important? > And always, some receivers may be behind very low bitrate links, > so it's better to use as small bitrate as possible. But your priority bit or bits would let them send any amount of additional, lower-priority packets towards those slow links without doing any harm to the higher-priority packets. That would be just the sort of thing you would expect the designer of a real-time multicast app to do, so that receivers reachable over higher-speed links would get better quality reception. A lot easier than the more network-friendly approach of putting the different layers on different multicast groups and having the receivers dynamically adapt to the right number of groups to avoid loss. > Moreover, billing may depend on the amount of packets etc. > This also encourages not to send much traffic. Someday. Maybe. If an infrastructure for universal, Internet-wide, per- packet billing of best-efforts traffic from individual sources should come into existence, that might be an appropriate time to consider adding the feature you are requesting. [The rest of this reply is addressed to the list, not just to Petri.] Look, I really like the idea of drop priority to minimize the perceptual damage caused to real-time applications by the inevitable transient congestion events. That's why I specified the Priority field the way I did in the original IPv6 (and earlier SIP) spec. But then the negative consequences of that feature were pointed out me, and after many months of resistance, I finally and reluctantly concluded that it would do much more harm than good. I haven't heard anyone present a solution to the "wrong incentive" problem, other than usage-sensitive charging for best-efforts traffic. Making the usability of IPv6 contigent upon the successful adoption and deployment of a per-packet charging infrastructure seems like a very bad idea to me. So, there's no need to keep explaining to me the possible benefits of a loss-priority feature. Please explain how you would avoid the potential harmful consequences. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 16:23:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA08132; Thu, 12 Jun 1997 16:14:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA08125; Thu, 12 Jun 1997 16:14:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA04668; Thu, 12 Jun 1997 16:15:21 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA10543 for ; Thu, 12 Jun 1997 16:17:13 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id QAA15399; Thu, 12 Jun 1997 16:16:21 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 12 Jun 1997 16:16:24 -0700 To: "Conta, Alex" From: Steve Deering Subject: (IPng 4009) Re: Qry on Traffic Policing (IPv6 header chang es) Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 758 At 9:47 AM -0700 6/12/97, Conta, Alex wrote: > I take it you had in mind something that is not there yet, so > what is it, what would you design in the system to make "acting in ones > own best interest serves the overall behavior of the system"? Alex, I was actually trying to keep out a feature (the drop-preference bit) that would make things worse in that regard. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 12 19:09:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA08397; Thu, 12 Jun 1997 19:01:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA08390; Thu, 12 Jun 1997 19:01:10 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA04987; Thu, 12 Jun 1997 19:01:50 -0700 Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA21746 for ; Thu, 12 Jun 1997 19:03:46 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.2) with ESMTP id TAA07378 for ; Thu, 12 Jun 1997 19:02:55 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id TAA28638 for ; Thu, 12 Jun 1997 19:02:07 -0700 (PDT) Received: from lookout.nsd.3com.com (lookout.NSD.3Com.COM [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id TAA06754 for ; Thu, 12 Jun 1997 19:01:13 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id TAA03404; Thu, 12 Jun 1997 19:03:22 -0700 (PDT) Date: Thu, 12 Jun 1997 19:03:22 -0700 (PDT) Message-Id: <199706130203.TAA03404@lookout.nsd.3com.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4010) Unique EIDs for Tunnels Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 583 Forgive me if I am out of sync ? Is there a way to get unique EIDs for v6-over-v4 tunnel interfaces ? Would it be recommended that a node have atleast one unique EID ? If needed in future. Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 02:08:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA08668; Fri, 13 Jun 1997 02:00:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA08661; Fri, 13 Jun 1997 02:00:39 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA10295; Fri, 13 Jun 1997 02:01:17 -0700 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id CAA27823 for ; Fri, 13 Jun 1997 02:03:16 -0700 Received: from harakka.cs.tut.fi (petkos@harakka.cs.tut.fi [130.230.5.4]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id MAA11857; Fri, 13 Jun 1997 12:02:15 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by harakka.cs.tut.fi (8.8.5/8.8.4) id MAA16707; Fri, 13 Jun 1997 12:02:14 +0300 (EET DST) Message-Id: <199706130902.MAA16707@harakka.cs.tut.fi> Subject: (IPng 4011) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: from Steve Deering at "Jun 12, 97 03:18:30 pm" To: deering@cisco.com (Steve Deering) Date: Fri, 13 Jun 1997 12:02:14 +0300 (EET DST) Cc: petkos@cs.tut.fi, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2412 Let's first summarize what has been proposed for this IPv6 header: To use one bit for Drop Prefedence, preferable from version field since priority bits are already in use and routers may rewrite them and original information is then lost. Many people in list have emphasized that this information should not be altered in the network. Anyway, there would be two usages for that bit: 1) To mark RSVP excess traffic (by router) 2) To mark less important data (by application) More research might be needed for case 1) but we have to decide things now. Some comments about Steve's response: >putting the different layers on different multicast groups and having >the receivers dynamically adapt to the right number of groups to avoid True for multicasting, but receiver may be unicast. This approach does not work then. Or do you think it is ok to use multicast addresses for (hierarcially encoded media) one-to-one communication as well? > I haven't heard anyone present a solution to the > "wrong incentive" problem, other than usage-sensitive charging for > best-efforts traffic. Making the usability of IPv6 contigent upon the > So, there's no need to keep explaining to me the possible benefits of a > loss-priority feature. Please explain how you would avoid the potential > harmful consequences. > I have still a doubt about these harmful consequences. If application uses this presented feature (mark some of its packets with drop label) current situation continue and only change is that routers (at least some routers, for example just before slow mobile link) have the ability (if they provide that feature) to drop enhancement data. If we don't define this Drop bit, then situation is as today: Applications send same amount of data as they would with Drop bit defined. This Drop bit does not change applications beheviour. So, if we specify Drop bit which is not changed by routers (except possible RSVP excess packets), we can't loose anything but we may win something. Petri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 07:03:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA08949; Fri, 13 Jun 1997 06:54:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA08942; Fri, 13 Jun 1997 06:54:24 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01551; Fri, 13 Jun 1997 06:55:02 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA11190 for ; Fri, 13 Jun 1997 06:57:00 -0700 Received: from gungnir.fnal.gov ("port 53391"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-8 #3998) id <01IK0O0WKMKE0008TS@FNAL.FNAL.GOV>; Fri, 13 Jun 1997 08:56:10 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA21181; Fri, 13 Jun 1997 08:56:04 -0500 Date: Fri, 13 Jun 1997 08:56:03 -0500 From: Matt Crawford Subject: (IPng 4012) Re: Unique EIDs for Tunnels In-reply-to: "12 Jun 1997 19:03:22 PDT." <"199706130203.TAA03404"@lookout.nsd.3com.com> To: Quaizar Vohra Cc: ipng@sunroof.eng.sun.com Message-id: <199706131356.IAA21181@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{ Forgive me if I am out of sync ? > Is there a way to get unique EIDs for v6-over-v4 tunnel interfaces ? Yes, but none is defined now. Here's one way it could be defined. Take some company_id, either new or allocated to a cooperating organization. (The IANA comes to mind.) Define an 8-bit field to follow the company_id, then use a globally-routable IPv4 address as the lowest 32 bits. Now, there is one concern to be address before calling the resulting 64 bits an "EUI-64." The IEEE RAC claims authority over how that term gets used, and I believe their vision of EUI-64's is strictly through little bitty hardware dongles. The IETF, on the other hand, has not declared that an EID (or interface identifier) must be an EUI-64. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 07:28:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA08989; Fri, 13 Jun 1997 07:20:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA08982; Fri, 13 Jun 1997 07:19:54 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04695; Fri, 13 Jun 1997 07:20:34 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA16893 for ; Fri, 13 Jun 1997 07:22:34 -0700 Received: from gungnir.fnal.gov ("port 53484"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-8 #3998) id <01IK0OWLJW7G0008TS@FNAL.FNAL.GOV>; Fri, 13 Jun 1997 09:21:43 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA21254; Fri, 13 Jun 1997 09:21:38 -0500 Date: Fri, 13 Jun 1997 09:21:38 -0500 From: Matt Crawford Subject: (IPng 4013) Re: Qry on Traffic Policing (IPv6 header changes) In-reply-to: "13 Jun 1997 12:02:14 +0300." <"199706130902.MAA16707"@harakka.cs.tut.fi> To: Koskelainen Petri Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Message-id: <199706131421.JAA21254@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{ Let's first summarize what has been proposed for this IPv6 header: > > To use one bit for Drop Prefedence, preferable from version field > since priority bits are already in use ... I frequently hear that messing with the version field will ruin header compression. I don't know about that myself, but then, "There has been an alarming increase in the number of things I know nothing about." (Ashleigh Brilliant) Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 07:48:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA09010; Fri, 13 Jun 1997 07:40:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA09003; Fri, 13 Jun 1997 07:39:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA07203; Fri, 13 Jun 1997 07:40:35 -0700 Received: from mailhost1.BayNetworks.COM (ns3.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA21211 for ; Fri, 13 Jun 1997 07:42:35 -0700 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id HAA25162 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP id QAA19552 Posted-Date: Fri, 13 Jun 1997 16:27:31 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id KAA10848; Fri, 13 Jun 1997 10:27:29 -0400 for Message-Id: <3.0.32.19970613102604.006c72e8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 13 Jun 1997 10:26:05 -0400 To: Steve Deering From: Dimitry Haskin Subject: (IPng 4014) Re: Qry on Traffic Policing (IPv6 header changes) Cc: int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2276 At 03:18 PM 6/12/97 -0700, Steve Deering wrote: >[The rest of this reply is addressed to the list, not just to Petri.] > >Look, I really like the idea of drop priority to minimize the perceptual >damage caused to real-time applications by the inevitable transient >congestion events. That's why I specified the Priority field the way I >did in the original IPv6 (and earlier SIP) spec. But then the negative >consequences of that feature were pointed out me, and after many months >of resistance, I finally and reluctantly concluded that it would do much >more harm than good. I haven't heard anyone present a solution to the >"wrong incentive" problem, other than usage-sensitive charging for >best-efforts traffic. Making the usability of IPv6 contigent upon the >successful adoption and deployment of a per-packet charging infrastructure >seems like a very bad idea to me. > >So, there's no need to keep explaining to me the possible benefits of a >loss-priority feature. Please explain how you would avoid the potential >harmful consequences. > I thought we're now in a mood of giving away bits for the sake of a presumable but quite questionable future benefits? ;-) On a serious note.. I don't think that by not having the drop bit you're actually solving the "wrong incentive" problem or making it any better. I've heard of multimedia applications that deliberately duplicate their packets in order of improving odds of data delivery (this is reeeally wrong incentive, doesn't it?). At least with the drop bit there is a hope that some of these packet will be marked. Maybe I'm naive but I do believe that there will be applications that will make the best use of the available tool. Such applications will replace bad behaved applications not for altruistic reasons but because it just make economic sense. And "economic" does not necessary mean usage-sensitive charging. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 09:09:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09239; Fri, 13 Jun 1997 09:01:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09231; Fri, 13 Jun 1997 09:01:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA21194; Fri, 13 Jun 1997 09:01:46 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA11207 for ; Fri, 13 Jun 1997 09:03:46 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA04528; Fri, 13 Jun 1997 09:02:58 -0700 Message-Id: <3.0.2.32.19970613090233.00cbac48@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 13 Jun 1997 09:02:33 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4015) New IPng Addressing Drafts Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1015 I have submitted new versions of the addressing drafts (architecure, aggregation, multicast) to be published as Internet Drafts. In addition to many changes based on comments received, the addressing architecture includes a new appendix on creating EUI-64 based interface identifiers. Many thanks to everyone who sent me comments. Bob p.s. Prior to the new ID's being published, you can find them as: ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-addr-arch-v2-01.txt ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-unicast-aggr-01.txt ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-multicast-assgn-03.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 09:23:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09275; Fri, 13 Jun 1997 09:14:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09268; Fri, 13 Jun 1997 09:14:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA23967; Fri, 13 Jun 1997 09:15:24 -0700 Received: from socks1.raleigh.ibm.com (socks1.raleigh.ibm.com [204.146.167.124]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA15011 for ; Fri, 13 Jun 1997 09:17:23 -0700 Received: from rtpmail03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA09204; Fri, 13 Jun 1997 12:16:12 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA25382; Fri, 13 Jun 1997 12:16:14 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA18974; Fri, 13 Jun 1997 12:15:06 -0400 Message-Id: <9706131615.AA18974@cichlid.raleigh.ibm.com> To: Matt Crawford Cc: Koskelainen Petri , int-serv@ISI.EDU, ipng@sunroof.eng.sun.com Subject: (IPng 4016) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: Your message of "Fri, 13 Jun 1997 09:21:38 CDT." <199706131421.JAA21254@gungnir.fnal.gov> Date: Fri, 13 Jun 1997 12:15:06 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2451 > I frequently hear that messing with the version field will ruin > header compression. It will. The header compression folks (specifically, draft-degermark-ipv6-hc-02.txt) took a look at the version field in the IP header and concluded: hey, it will always be 4 or 6 -- no other possible value -- so let's use those bits for our own purposes. Specifically, they have several types of compressed packets: IPv6 carrying TCP, IPv4/TCP, IPv6/UDP, or something like that (I may have the details wrong, but that's the basic idea). One way to do compression is to have a shim layer between what is being compressed and what is below it, and then have a "type" field in the shim to identify what specific decompression to use, what "flow" this packet belongs to (if the compression algorithm is stateful), etc. But that adds bits to the size of the packet, since all compressed packets carry the header. To avoid the shim, one could for each link type (i.e., PPP, Ethernet, etc.), ask for a range of types that would denote "header compression", with the specific value denoting a specific type of compression analogous to "type" above. In practice, it is difficult to allocate a range of numbers from every link type you might want to run compression over. That gets us back to the version field in the IP header. If we assume that the 4 bits have only 2 values in practice (4 and 6), header compression can use the other values for its own purposes. That way it doesn't need a shim (saving a few bytes) or to get multiple type fields on each link-layer (it steals them directly from the IP header). Some would say this is a hack. Whether one wants to allow this sort of usage of the version field bits is a question worthy of debate. What is essentially happening is that the header compression folks have grabbed those bits for their own use. The larger question that should be considered is whether this particular use of the version field is better than other potential uses that are (seemingly) being ruled out-of-hand because they "break header compression". Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 11:34:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09632; Fri, 13 Jun 1997 11:24:53 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09625; Fri, 13 Jun 1997 11:24:49 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA14234; Fri, 13 Jun 1997 11:26:54 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA10125; Fri, 13 Jun 1997 11:25:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09614; Fri, 13 Jun 1997 11:23:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA26979; Fri, 13 Jun 1997 11:23:42 -0700 Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA22266 for ; Fri, 13 Jun 1997 11:25:40 -0700 Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by netscape.com (8.8.5/8.8.5) with ESMTP id LAA03074 for ; Fri, 13 Jun 1997 11:24:52 -0700 (PDT) Received: from fionavar ([207.1.142.56]) by dredd.mcom.com (Netscape Messaging Server 3.0) with SMTP id AAA2415; Fri, 13 Jun 1997 11:23:26 -0700 Message-ID: <33A18FB4.1F1A@netscape.com> Date: Fri, 13 Jun 1997 11:21:40 -0700 From: John Francis Stracke X-Mailer: Mozilla 3.0GoldC (X11; U; IRIX 5.3 IP22) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 4018) Re: Qry on Traffic Policing (IPv6 header changes) References: <199706120629.JAA08929@harakka.cs.tut.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1199 Steve Deering wrote: > the more network-friendly approach of > putting the different layers on different multicast groups and having > the receivers dynamically adapt to the right number of groups ...and then, if you've got RSVP, you can have a reservation for the group with the Important Bits and not for the others, which gives you the same behavior Petri's priority bit was looking for. /====================================================================\ |John (Francis) Stracke |My opinions are my own.|PGP key available| |Software Retrophrenologist|=========================================| |Netscape Comm. Corp. |How many roads must a man walk down | |francis@netscape.com | before he admits he is LOST? | \====================================================================/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 11:48:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09658; Fri, 13 Jun 1997 11:38:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA09651; Fri, 13 Jun 1997 11:38:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA01133; Fri, 13 Jun 1997 11:38:53 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA26874 for ; Fri, 13 Jun 1997 11:40:53 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA17108; Fri, 13 Jun 97 11:35:11 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id LAA11876; Fri, 13 Jun 1997 11:40:32 -0700 Date: Fri, 13 Jun 1997 11:40:32 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199706131840.LAA11876@feller.mentat.com> To: narten@raleigh.ibm.com Subject: (IPng 4019) Re: Qry on Traffic Policing (IPv6 header changes) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2679 Thomas, > > Some would say this is a hack. Whether one wants to allow this sort of > usage of the version field bits is a question worthy of debate. What > is essentially happening is that the header compression folks have > grabbed those bits for their own use. The larger question that should > be considered is whether this particular use of the version field is > better than other potential uses that are (seemingly) being ruled > out-of-hand because they "break header compression". > You are correct that the header compression folks have absconded with the version bits. I applaud them for it. It is a good solution. The last time this discussion occurred I pointed out that there are 28 bits in the header which can be used for any number of hop-by-hop or end-to-end purposes. We just need to get consensus on the specifics. We have no shortage of bits. We have a shortage of agreement on what to do with the already available bits. Taking the version field bits only gives us more things to wrangle over. During the last several IETF's I have heard various parties which would like to lay claim to some of these twenty eight bits in the header. >From memory: 1) RSVP wants the flow-label (end-to-end integrity required) 2) Label switching folks want the flow-label (hop-by-hop manipulation required) 3) ISP's want the priority bits (hop-by-hop manipulation required) 4) The drop priority advocates want a bit (end-to-end integrity required?) Note that 1 and 2 are completely incompatible usages in the face of AH. If the bit for 4 comes out of the priority area then 3 and 4 are also incompatible in the face of AH. The IPSec documents have reflected this confusion by changing which fields of the IPv6 header are covered by AH repeatedly over the last couple of drafts. The current draft includes the entire first 32 bits in the integrity computation. It seems as if what we need to do is divide the 28 bits of priority and flow-label into two relatively equal sized portions. One portion is for use by facilities which require end-to-end integrity. The other portion is for hop-by-hop manipulation. Once we have this division then the folks in the two camps can slug it out over how to make use of their portion of the bits. Tim (Just call me Solomon) Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 12:35:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09753; Fri, 13 Jun 1997 12:25:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09744; Fri, 13 Jun 1997 12:25:41 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA12040; Fri, 13 Jun 1997 12:26:18 -0700 Received: from cs.tut.fi (cs.tut.fi [130.230.4.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA10031 for ; Fri, 13 Jun 1997 12:28:20 -0700 Received: from korppi.cs.tut.fi (petkos@korppi.cs.tut.fi [130.230.4.3]) by cs.tut.fi (8.8.5/8.8.4) with ESMTP id WAA29058; Fri, 13 Jun 1997 22:27:30 +0300 (EET DST) From: Koskelainen Petri Received: (from petkos@localhost) by korppi.cs.tut.fi (8.8.5/8.8.4) id WAA23727; Fri, 13 Jun 1997 22:27:28 +0300 (EET DST) Message-Id: <199706131927.WAA23727@korppi.cs.tut.fi> Subject: (IPng 4020) Re: Qry on Traffic Policing (IPv6 header changes) In-Reply-To: <33A18FB4.1F1A@netscape.com> from John Francis Stracke at "Jun 13, 97 11:21:40 am" To: francis@netscape.com (John Francis Stracke) Date: Fri, 13 Jun 1997 22:27:28 +0300 (EET DST) Cc: ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 994 > > the more network-friendly approach of > > putting the different layers on different multicast groups and having > > the receivers dynamically adapt to the right number of groups > > ...and then, if you've got RSVP, you can have a reservation for the > group with the Important Bits and not for the others, which gives you > the same behavior Petri's priority bit was looking for. > RSVP is not available everywhere. Even if it is, it is definitely not used for every 1000000 Internet Telephony call. So, RSVP is not general solution for this problem (although it certainly is for some cases). Petri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 12:40:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09766; Fri, 13 Jun 1997 12:29:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09759; Fri, 13 Jun 1997 12:29:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA12747; Fri, 13 Jun 1997 12:30:14 -0700 Received: from mailhost3.BayNetworks.COM (ns4.BayNetworks.COM [192.32.253.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA10910 for ; Fri, 13 Jun 1997 12:32:16 -0700 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost3.BayNetworks.COM (8.8.5/BNET-97/03/26-E) with ESMTP id PAA07689 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP id VAA27894 Posted-Date: Fri, 13 Jun 1997 21:31:06 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA23819; Fri, 13 Jun 1997 15:30:57 -0400 for Message-Id: <3.0.32.19970613152933.006ae408@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 13 Jun 1997 15:29:41 -0400 To: thartric@mentat.com (Tim Hartrick) From: Dimitry Haskin Subject: (IPng 4021) Re: Qry on Traffic Policing (IPv6 header changes) Cc: narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 957 At 11:40 AM 6/13/97 -0700, Tim Hartrick wrote: > >1) RSVP wants the flow-label (end-to-end integrity required) >2) Label switching folks want the flow-label (hop-by-hop manipulation required) >3) ISP's want the priority bits (hop-by-hop manipulation required) >4) The drop priority advocates want a bit (end-to-end integrity required?) > I/m not sure if any of these require end-to-end integrity. After a packet reached its destination why would one care of authenticity of the flow-label or the drop-priority bit? I guess they are all for use by intermediate routers. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 12:53:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09788; Fri, 13 Jun 1997 12:40:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09780; Fri, 13 Jun 1997 12:40:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA15037; Fri, 13 Jun 1997 12:40:51 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA13457 for ; Fri, 13 Jun 1997 12:42:52 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA17499; Fri, 13 Jun 97 12:37:07 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id MAA11927; Fri, 13 Jun 1997 12:42:29 -0700 Date: Fri, 13 Jun 1997 12:42:29 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199706131942.MAA11927@feller.mentat.com> To: dhaskin@BayNetworks.COM Subject: (IPng 4022) Re: Qry on Traffic Policing (IPv6 header changes) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1639 Dimitry, > > > >1) RSVP wants the flow-label (end-to-end integrity required) > >2) Label switching folks want the flow-label (hop-by-hop manipulation > required) > >3) ISP's want the priority bits (hop-by-hop manipulation required) > >4) The drop priority advocates want a bit (end-to-end integrity required?) > > > I/m not sure if any of these require end-to-end integrity. After a packet > reached its destination why would one care of authenticity of the > flow-label or the drop-priority bit? I guess they are all for use by > intermediate routers. > In the drop-priority case you may be correct (that is the reason for the ?). If you are correct then I see no reason to take a bit from the version field for this purpose. We can simply allocate another of the priority bits. In the RSVP case it has always been my understanding that RSVP was going to be the magic bullet for providing premium services at premium prices. When money is involved you can't allow your packets to manipulated in transit causing either higher rates or loss of expected service without that manipulation being detectable and verifiable via cryptographic means. Of course I may not understand what RSVP is trying to accomplish. It would not be the first time.:-) tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 13 14:06:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10658; Fri, 13 Jun 1997 13:57:56 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA10651; Fri, 13 Jun 1997 13:57:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA01642; Fri, 13 Jun 1997 13:58:25 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA03009 for ; Fri, 13 Jun 1997 14:00:25 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id NAA17080; Fri, 13 Jun 1997 13:59:37 -0700 Message-Id: <3.0.2.32.19970613135928.00cb09d8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 13 Jun 1997 13:59:28 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4023) W.G. Last Call on "IPv6 MIBs" Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1740 This is an ipng working group last call for comments on advancing the following documents to Experimental: Title : Management Information Base for IP Version 6: Textual Conventions and General Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-mib-02.txt Pages : 41 Date : 06/10/1997 Title : Management Information Base for IP Version 6: ICMPv6 Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-icmp-mib-01.txt Pages : 18 Date : 03/24/1997 Title : IP Version 6 Management Information Base for the Transmission Control Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-tcp-mib-00.txt Pages : 6 Date : 06/10/1997 Title : IP Version 6 Management Information Base for the User Datagram Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-udp-mib-00.txt Pages : 5 Date : 06/10/1997 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on June 27, 1997. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 14 12:17:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11721; Sat, 14 Jun 1997 12:08:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11714; Sat, 14 Jun 1997 12:08:41 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA07525; Sat, 14 Jun 1997 12:10:29 -0700 Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA18352 for ; Sat, 14 Jun 1997 12:11:18 -0700 Received: (from jh@localhost) by lohi.dat.tele.fi (8.8.5/8.8.5) id WAA07646; Sat, 14 Jun 1997 22:10:06 +0300 Date: Sat, 14 Jun 1997 22:10:06 +0300 Message-Id: <199706141910.WAA07646@lohi.dat.tele.fi> From: Juha Heinanen To: petkos@cs.tut.fi CC: deering@cisco.com, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-reply-to: <199706110855.LAA20810@harakka.cs.tut.fi> (petkos@cs.tut.fi) Subject: (IPng 4024) Re: Qry on Traffic Policing (IPv6 header changes) Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 622 binary priority alone is not very useful. i would prefer a tos indication so that rsvp would not be needed (or processed) at all. this is how ieee802.1p works and there should be a mapping between 802.1p qos field and ip tos field. -- juha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 14 12:40:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11746; Sat, 14 Jun 1997 12:31:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11739; Sat, 14 Jun 1997 12:31:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08515; Sat, 14 Jun 1997 12:33:08 -0700 Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA20251 for ; Sat, 14 Jun 1997 12:33:57 -0700 Received: (from jh@localhost) by lohi.dat.tele.fi (8.8.5/8.8.5) id WAA07715; Sat, 14 Jun 1997 22:33:05 +0300 Date: Sat, 14 Jun 1997 22:33:05 +0300 Message-Id: <199706141933.WAA07715@lohi.dat.tele.fi> From: Juha Heinanen To: deering@cisco.com CC: petkos@cs.tut.fi, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-reply-to: (deering@cisco.com) Subject: (IPng 4025) Re: Qry on Traffic Policing (IPv6 header changes) Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1344 It can harm the carrying capacity of the network. The undeliverable packets consume bandwidth on all the hops up to the point at which they are dropped. That bandwidth would otherwise be available for more productive use by other flows. sure, but this is how it is with all best effort traffic. with the above logic, best effort traffic should be not allowed at all. Without router support for drop priority, the transmission of excess packets into a congestion point causes the "more important" packets to be equally vulnerable to loss as the "less important" packets. Thus, there is an incentive for the applications to be designed not to send less important packets into congested paths. If they "send them anyway", they will harm not only other flows in the Internet, but also their own "more important" traffic. huh, are you suggesting that the network cannot protect guaranteed flows from best effort traffic? -- juha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 14 12:43:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11755; Sat, 14 Jun 1997 12:34:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA11748; Sat, 14 Jun 1997 12:33:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08658; Sat, 14 Jun 1997 12:35:38 -0700 Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA20454 for ; Sat, 14 Jun 1997 12:36:27 -0700 Received: (from jh@localhost) by lohi.dat.tele.fi (8.8.5/8.8.5) id WAA07724; Sat, 14 Jun 1997 22:35:27 +0300 Date: Sat, 14 Jun 1997 22:35:27 +0300 Message-Id: <199706141935.WAA07724@lohi.dat.tele.fi> From: Juha Heinanen To: deering@cisco.com CC: pferguso@cisco.com, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-reply-to: (deering@cisco.com) Subject: (IPng 4026) Re: Qry on Traffic Policing (IPv6 header changes) Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1193 Only in the WG minutes, so far. (I plan to have a new version of the base IPv6 spec out before Munich.) Here's what the minutes say: - Declare that 4 bits of Priority are rewritable by routers/ISPs for private purposes (and exclude from authentication header). - Priority bits have no significance to receivers - Convention: Sender sets low order bit to mean interactive traffic. o Delay more important than throughput o Suggests that routers/ISPs use other bits before touching the "interactive bit". o Affects queuing only, not routing (since re-writable). the above doesn't sound like sound design, but rather a set of hacks. the real solution is to have a real qos field in the header that is setable by the application and possibly resetable by the network. -- juha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 14 13:08:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA11840; Sat, 14 Jun 1997 13:00:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA11833; Sat, 14 Jun 1997 13:00:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA10444; Sat, 14 Jun 1997 13:02:11 -0700 Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA22731 for ; Sat, 14 Jun 1997 13:03:00 -0700 Received: (from jh@localhost) by lohi.dat.tele.fi (8.8.5/8.8.5) id XAA07794; Sat, 14 Jun 1997 23:02:03 +0300 Date: Sat, 14 Jun 1997 23:02:03 +0300 Message-Id: <199706142002.XAA07794@lohi.dat.tele.fi> From: Juha Heinanen To: deering@cisco.com CC: dhaskin@baynetworks.com, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-reply-to: (deering@cisco.com) Subject: (IPng 4027) Re: Qry on Traffic Policing (IPv6 header changes) Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1165 No, it's not possible to guarantee that no packets are discarded, when using the Internet's "best effort" service. Adding support for a drop- preference bit would not eliminate the possibility of loss of "unmarked" packets (i.e., packets without the drop-preference bit set), since there could still be bursts of unmarked packets that exceed the bandwidth and queueing capacity of a link. Any application designed to operate over best effort service ought to be able to gracefully survive occasional packet loss, even of its "most important" packets. sure and a good implementation has a per flow queue with two thresholds. once the queue is above the first, it starts to drop marked packets and when above the second, it starts to drop all packets. -- juha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 14 14:20:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11935; Sat, 14 Jun 1997 14:12:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11928; Sat, 14 Jun 1997 14:12:03 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA13921; Sat, 14 Jun 1997 14:13:55 -0700 Received: from lohi.dat.tele.fi (lohi.dat.tele.fi [193.167.66.66]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA28704 for ; Sat, 14 Jun 1997 14:14:44 -0700 Received: (from jh@localhost) by lohi.dat.tele.fi (8.8.5/8.8.5) id AAA08005; Sun, 15 Jun 1997 00:13:52 +0300 Date: Sun, 15 Jun 1997 00:13:52 +0300 Message-Id: <199706142113.AAA08005@lohi.dat.tele.fi> From: Juha Heinanen To: petkos@cs.tut.fi CC: deering@cisco.com, petkos@cs.tut.fi, int-serv@ISI.EDU, ipng@sunroof.eng.sun.com In-reply-to: <199706130902.MAA16707@harakka.cs.tut.fi> (petkos@cs.tut.fi) Subject: (IPng 4028) Re: Qry on Traffic Policing (IPv6 header changes) Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1113 To use one bit for Drop Prefedence, preferable from version field since priority bits are already in use and routers may rewrite them and original information is then lost. Many people in list have emphasized that this information should not be altered in the network. Anyway, there would be two usages for that bit: 1) To mark RSVP excess traffic (by router) 2) To mark less important data (by application) craig said that if the user sends above the contract, the service that it receives will be useless. so i don't quite see the need to mark anything in such a case. i don't know how useful a priority field is. i would prefer to have a three bit qos field and a one bit loss priority field. -- juha -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 14 17:32:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12141; Sat, 14 Jun 1997 17:24:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA12134; Sat, 14 Jun 1997 17:24:35 -0700 From: HDhil@aol.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA22876; Sat, 14 Jun 1997 17:26:26 -0700 Received: from emout08.mail.aol.com (emout08.mx.aol.com [198.81.11.23]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA14656 for ; Sat, 14 Jun 1997 17:27:15 -0700 Received: (from root@localhost) by emout08.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id UAA13801 for ipng@sunroof.eng.sun.com; Sat, 14 Jun 1997 20:26:26 -0400 (EDT) Date: Sat, 14 Jun 1997 20:26:26 -0400 (EDT) Message-ID: <970614202623_1044836660@emout08.mail.aol.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4029) Forgive the aside Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 948 Not to interrupt this good discussion of traffic policing and changes to the priority field in the IPv6 header, but has the IPng made any action on the use of the flow-id field being used to carry MPLS tags, eg. as in Cisco's tag switching? I saw it mentioned in the minutes once, and i was wondering how and if IPng had discussed any ramifications of doing so, and also to what degree the field was useful in conjunction with RSVP being used to signal QoS for packet flows as well. Thanks. Harry Dhillon Lucent Technologies Phone: (908) 224-8013 Fax: (908) 224-3200 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 15 11:53:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12697; Sun, 15 Jun 1997 11:45:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA12690; Sun, 15 Jun 1997 11:45:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA02990; Sun, 15 Jun 1997 11:47:19 -0700 Received: from brickbat9.mindspring.com (brickbat9.mindspring.com [207.69.200.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA00853 for ; Sun, 15 Jun 1997 11:48:10 -0700 Received: from desktop (user-37kbm26.dialup.mindspring.com [207.69.216.70]) by brickbat9.mindspring.com (8.8.5/8.8.5) with SMTP id OAA16585; Sun, 15 Jun 1997 14:47:19 -0400 (EDT) Message-Id: <2.2.32.19970615185433.0093d1a0@mindspring.com> X-Sender: sthomas@mindspring.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 15 Jun 1997 14:54:33 -0400 To: ipng@sunroof.eng.sun.com From: Stephen Thomas Subject: (IPng 4030) New Token Ring Draft Cc: narten@raleigh.ibm.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 752 A new token ring draft is in the hands of the I-D editor. For those who can't delay, you can get a copy at http://waterscreek.com/download/draft-ietf-ipng-trans-tokenring-00.txt --Stephen ______________________________________________________ Stephen Thomas Vice President of Engineering +1.770.924.6119 TransNexus sthomas@transnexus.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 16 04:51:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA13392; Mon, 16 Jun 1997 04:43:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA13385; Mon, 16 Jun 1997 04:42:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA29267; Mon, 16 Jun 1997 04:44:45 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA26457 for ; Mon, 16 Jun 1997 04:45:35 -0700 Received: from ietf.ietf.org by ietf.org id aa04385; 16 Jun 97 7:20 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4031) I-D ACTION:draft-ietf-ipngwg-unicast-aggr-01.txt Date: Mon, 16 Jun 1997 07:19:40 -0400 Message-ID: <9706160720.aa04385@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3490 --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 : An IPv6 Aggregatable Global Unicast Address Format Author(s) : R. Hinden, M. O'Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-01.txt Pages : 10 Date : 06/13/1997 This document defines an IPv6 aggregatable global unicast address format for use in the Internet. The address format defined in this document is consistent with the IPv6 Protocol [IPV6] and the "IPv6 Addressing Architecture" [ARCH]. It is designed to facilitate scalable Internet routing. This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast Address Format". RFC 2073 will become historic. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-unicast-aggr-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-aggr-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-01.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: <19970616070248.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-aggr-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970616070248.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 16 05:01:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA13408; Mon, 16 Jun 1997 04:51:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA13401; Mon, 16 Jun 1997 04:51:18 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA29771; Mon, 16 Jun 1997 04:53:10 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA27468 for ; Mon, 16 Jun 1997 04:53:59 -0700 Received: by ietf.org id aa04938; 16 Jun 97 7:49 EDT Received: from ietf.ietf.org by ietf.org id aa04314; 16 Jun 97 7:18 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4032) I-D ACTION:draft-ietf-ipngwg-multicast-assgn-03.txt Date: Mon, 16 Jun 1997 07:17:54 -0400 Message-ID: <9706160718.aa04314@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3729 --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Multicast Address Assignments Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-multicast-assgn-03.txt Pages : 8 Date : 06/13/1997 This document defines the initial assignment of IPv6 multicast addresses. It is based on the "IP Version 6 Addressing Architecture" [ADDARCH] and current IPv4 multicast address assignment found in . It adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4 assignments that were not relevant were not converted into IPv6 assignments. Comments are solicited on this conversion. All other IPv6 multicast addresses are reserved. Sections 2 and 3 specify reserved and preassigned IPv6 multicast addresses. [ADDRARCH] defines rules for assigning new IPv6 multicast addresses. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-multicast-assgn-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-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: <19970616070239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-multicast-assgn-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970616070239.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 16 08:12:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13549; Mon, 16 Jun 1997 08:03:42 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA13542; Mon, 16 Jun 1997 08:03:34 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA25804; Mon, 16 Jun 1997 08:05:26 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09501 for ; Mon, 16 Jun 1997 08:06:14 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA28030; Mon, 16 Jun 1997 11:03:46 -0400 Date: Mon, 16 Jun 1997 11:03:46 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9706161103.ZM28028@seawind.bellcore.com> In-Reply-To: Dimitry Haskin "(IPng 4014) Re: Qry on Traffic Policing (IPv6 header changes)" (Jun 13, 10:26am) References: <3.0.32.19970613102604.006c72e8@pobox> X-Mailer: Z-Mail (3.2.1 10oct95) To: Dimitry Haskin , Steve Deering Subject: (IPng 4033) Re: Qry on Traffic Policing (IPv6 header changes) Cc: int-serv@isi.edu, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2896 > On a serious note.. I don't think that by not having the drop bit you're > actually solving the "wrong incentive" problem or making it any better. > I've heard of multimedia applications that deliberately duplicate their > packets in order of improving odds of data delivery (this is reeeally > wrong incentive, doesn't it?). Dimitry, There are indeed many problems that have to be solved if we want to guarantee a stable Internet. As Steve put it out, it is much simpler for an application designer to be selfish and messy than adaptive and clean. This is obvious when dealing with multicast applications, but the practice of open several TCP connections in parallel is just as bad. Then, if you take a close look at the new selective-ack options of TCP, you will certainly recognize a great potential for individual accelerations. There is thus zero doubt that, to obtain a stable Internet, one need active policing from inside the network. Several policing algorithm have been proposed, the most popular being the adjunction of a "bad guy detection and punishment loop" to Random Early Detection. The first effect of policing is in presence of a bottleneck, applications will only be able to transmit their "fair share" of data. In fact, a good policing response curve should guarantee that, if an application sends more than its "fair share", the number of successfully received packets will decrease, not increase. If you have policing in place, then an application assigned drop priority bit becomes a bad idea, for at least three reasons: * if priorities are user-based, rather than network wide, policy machines will have to keep tabs of the actual consumption of each users, and effectively upgrade or downgrade the priority on a per user basis. This is much more complex than the statistical policing envisaged today. * if packets are tunnelled, the user based priorities can only be used if the original users can be identified by the tunnels' relays, which defeats the purpose of tunneling. * as Steve said, if packets are bound to be lost, there is no point sending them in the first place. As many have observed, adaptation loops are not perfect. A good adaptive design should suppose assess how many packets can be sent, and should also be ready to loose some of these packets. In some cases, applications will decide to split their allowance between plain packets and redondancy. Duplicating everything is a very crude implementation of that tactic. * if -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 16 13:23:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14137; Mon, 16 Jun 1997 13:15:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14130; Mon, 16 Jun 1997 13:15:18 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA05595; Mon, 16 Jun 1997 13:17:08 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA17169 for ; Mon, 16 Jun 1997 13:17:58 -0700 Received: from ns3.BayNetworks.COM (ns1.corpemea.baynetworks.com [141.251.211.30]) by mailhost2.BayNetworks.COM (8.8.5/BNET-97/05/05-E) with ESMTP id NAA00536 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by ns3.BayNetworks.COM (8.8.5/BNET-97/01/07-I) with ESMTP id WAA01444 Posted-Date: Mon, 16 Jun 1997 22:13:00 +0200 (MET DST) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA25639; Mon, 16 Jun 1997 16:12:54 -0400 for Message-Id: <3.0.32.19970616161137.006bdfa0@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 16 Jun 1997 16:11:41 -0400 To: huitema@bellcore.com (Christian Huitema) From: Dimitry Haskin Subject: (IPng 4034) Re: Qry on Traffic Policing (IPv6 header changes) Cc: Dimitry Haskin , int-serv@isi.edu, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3914 At 11:03 AM 6/16/97 -0400, Christian Huitema wrote: >> On a serious note.. I don't think that by not having the drop bit >you're >> actually solving the "wrong incentive" problem or making it any better. >> I've heard of multimedia applications that deliberately duplicate their >> packets in order of improving odds of data delivery (this is reeeally >> wrong incentive, doesn't it?). > >Dimitry, > >There are indeed many problems that have to be solved if we want to >guarantee a stable Internet. As Steve put it out, it is much simpler for >an application designer to be selfish and messy than adaptive and clean. > This is obvious when dealing with multicast applications, but the >practice of open several TCP connections in parallel is just as bad. > Then, if you take a close look at the new selective-ack options of TCP, >you will certainly recognize a great potential for individual >accelerations. There is thus zero doubt that, to obtain a stable >Internet, one need active policing from inside the network. Several >policing algorithm have been proposed, the most popular being the >adjunction of a "bad guy detection and punishment loop" to Random Early >Detection. > >The first effect of policing is in presence of a bottleneck, applications > will only be able to transmit their "fair share" of data. In fact, a >good policing response curve should guarantee that, if an application >sends more than its "fair share", the number of successfully received >packets will decrease, not increase. > I agree with all you said so far. I don't quite agree with your conclusions below. >If you have policing in place, then an application assigned drop priority >bit becomes a bad idea, for at least three reasons: > >* if priorities are user-based, rather than network wide, policy machines >will have to keep tabs of the actual consumption of each users, and >effectively upgrade or downgrade the priority on a per user basis. This >is much more complex than the statistical policing envisaged today. > It depends. As an example, it wouldn't be too difficult for a FR DTE to intelligently map the drop-priority bit to the FR's Drop Eligibility bit to utilize the Frame Relay's congestion management. I don't believe anyone proposed a mandatory use of priority in all circumstances or as a replacement to other policy schemes. >* if packets are tunnelled, the user based priorities can only be used if >the original users can be identified by the tunnels' relays, which defeats >the purpose of tunneling. > Then what? Tunneling hides all attributes of encapsulated packets. It does not mean that they are useless. >* as Steve said, if packets are bound to be lost, there is no point >sending them in the first place. > Sure.. if application new that. We're talking about the best effort traffic, don't we? By definitions of the best effort services some of transmitted packets are bound to be lost. >As many have observed, adaptation loops are not perfect. A good adaptive >design should suppose assess how many packets can be sent, and should also >be ready to loose some of these packets. In some cases, applications will >decide to split their allowance between plain packets and redondancy. > Duplicating everything is a very crude implementation of that tactic. No disagreement. It's just that some of us believe that information provided in a priority bit (not sure if more than one is needed) may help in some cases and that the presumable harm of this bit is exaggerated. >-- >Christian Huitema Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 17 04:49:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA14755; Tue, 17 Jun 1997 04:41:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA14748; Tue, 17 Jun 1997 04:41:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA07428; Tue, 17 Jun 1997 04:43:16 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA15179 for ; Tue, 17 Jun 1997 04:44:07 -0700 Received: from ietf.ietf.org by ietf.org id aa04431; 17 Jun 97 7:20 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4035) I-D ACTION:draft-ietf-ipngwg-ipv6router-alert-02.txt Date: Tue, 17 Jun 1997 07:20:52 -0400 Message-ID: <9706170720.aa04431@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3229 --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. Note: This revision reflects comments received during the last call period. Title : IPv6 Router Alert Option Author(s) : D. Katz, R. Atkinson, C. Partridge, A. Jackson Filename : draft-ietf-ipngwg-ipv6router-alert-02.txt Pages : 5 Date : 04/21/1997 This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for protocols addressed to a destination but also require special processing in routers along the path. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6router-alert-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6router-alert-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970616094639.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6router-alert-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970616094639.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 17 05:10:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA14790; Tue, 17 Jun 1997 05:00:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA14783; Tue, 17 Jun 1997 05:00:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA08720; Tue, 17 Jun 1997 05:02:22 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA20387 for ; Tue, 17 Jun 1997 05:03:12 -0700 Received: from ietf.ietf.org by ietf.org id aa04886; 17 Jun 97 7:31 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@ietf.org cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 4036) I-D ACTION:draft-ietf-ipngwg-trans-tokenring-00.txt Date: Tue, 17 Jun 1997 07:31:31 -0400 Message-ID: <9706170731.aa04886@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3306 --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 : Transmission of IPv6 Packets over Token Ring Networks Author(s) : S. Thomas Filename : draft-ietf-ipngwg-trans-tokenring-00.txt Pages : 10 Date : 06/16/1997 This memo specifies the MTU and frame format for transmission of IPv6 packets on Token Ring networks. It also specifies the method of forming IPv6 link-local addresses on Token Ring networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router advertisement, Neighbor Solicitation and Neighbor Advertisement messages when those messages are transmitted on a Token Ring network. 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-trans-tokenring-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-tokenring-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-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: <19970616112903.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-tokenring-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-tokenring-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970616112903.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 17 07:30:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15105; Tue, 17 Jun 1997 07:22:37 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15097; Tue, 17 Jun 1997 07:22:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA26288; Tue, 17 Jun 1997 07:24:16 -0700 Received: from FNAL.FNAL.Gov (fnal.fnal.gov [131.225.110.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA22553 for ; Tue, 17 Jun 1997 07:25:02 -0700 Received: from gungnir.fnal.gov ("port 62791"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-8 #3998) id <01IK6A5ZZS7G000H3F@FNAL.FNAL.GOV>; Tue, 17 Jun 1997 09:24:10 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA28731; Tue, 17 Jun 1997 09:24:08 -0500 Date: Tue, 17 Jun 1997 09:24:08 -0500 From: Matt Crawford Subject: (IPng 4037) Re: I-D ACTION:draft-ietf-ipngwg-ipv6router-alert-02.txt In-reply-to: "17 Jun 1997 07:20:52 EDT." <"9706170720.aa04431"@ietf.org> To: dkatz@jnx.com, rja@inet.org, craig@bbn.com, awjacks@bbn.com Cc: ipng@sunroof.eng.sun.com Message-id: <199706171424.JAA28731@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{ Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15209; Tue, 17 Jun 1997 09:42:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15202; Tue, 17 Jun 1997 09:42:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA09307; Tue, 17 Jun 1997 09:43:59 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA06088 for ; Tue, 17 Jun 1997 09:44:47 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA16970; Tue, 17 Jun 1997 09:43:55 -0700 Message-Id: <3.0.2.32.19970617094351.0091dc4c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Tue, 17 Jun 1997 09:43:51 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4038) W.G. Last Call on "IPv6 Router Alert Option" Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 925 This is a second IPng working group last call for comments on advancing the following documents to Proposed Standard: Title : IPv6 Router Alert Option Author(s) : D. Katz, R. Atkinson, C. Partridge, A. Jackson Filename : draft-ietf-ipngwg-ipv6router-alert-02.txt Pages : 5 Date : 04/21/1997 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on July 1, 1997. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 20 21:57:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA19766; Fri, 20 Jun 1997 21:49:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA19759; Fri, 20 Jun 1997 21:49:46 -0700 From: HDhil@aol.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA08734; Fri, 20 Jun 1997 21:51:40 -0700 Received: from emout01.mail.aol.com (emout01.mx.aol.com [198.81.11.92]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA20648 for ; Fri, 20 Jun 1997 21:52:33 -0700 Received: (from root@localhost) by emout01.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id AAA06560 for ipng@sunroof.eng.sun.com; Sat, 21 Jun 1997 00:51:40 -0400 (EDT) Date: Sat, 21 Jun 1997 00:51:40 -0400 (EDT) Message-ID: <970621005140_356044073@emout01.mail.aol.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4039) Re: Qry on Traffic Policing (IPv6 header changes) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1308 >There is many ways to provide congestion feedback from the interior of >network to the edges. Some schemes are proprietary (the last time I was >involved in one of such projects was quite a while ago), some are being >worked out in different forums (e.g., ABR for atm). Some schemes try to >prevent congestion and packet/cell drop, others react to it post fact. To >be more specific I'd have to write a dissertation but there is already more >of them than you probably have time to read. Has anybody proposed ideas like having a high-priority ICMP or other type of IP packet indicate downstream congestion on particular router links so the rate at which packets are forwarded on those particular links can be changed in a responsive fashion? Or is this more like the Controlled Load service in RSVP? Is an ABR-like service anathema in any way to IP since people like Mpps figures instead? -Harry Dhillon Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 21 04:17:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA19918; Sat, 21 Jun 1997 04:09:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA19911; Sat, 21 Jun 1997 04:09:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA27871; Sat, 21 Jun 1997 04:11:26 -0700 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA17749 for ; Sat, 21 Jun 1997 04:12:19 -0700 Received: from big-dawgs.cisco.com (herndon-dhcp-109.cisco.com [171.68.53.109]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id EAA13897; Sat, 21 Jun 1997 04:11:24 -0700 (PDT) Message-Id: <3.0.1.32.19970621071119.006f77a4@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 21 Jun 1997 07:11:19 -0400 To: HDhil@aol.com From: Paul Ferguson Subject: (IPng 4040) Re: Qry on Traffic Policing (IPv6 header changes) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <970621005140_356044073@emout01.mail.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1513 At 12:51 AM 06/21/97 -0400, HDhil@aol.com wrote: > >Has anybody proposed ideas like having a high-priority ICMP or other type of >IP packet indicate downstream congestion on particular router links so the >rate at which packets are forwarded on those particular links can be changed >in a responsive fashion? Or is this more like the Controlled Load service in >RSVP? Is an ABR-like service anathema in any way to IP since people like Mpps >figures instead? > I get an uneasy feeling when people start discussing explicit feedback mechanisms within IP when TCP does the Right Thing (tm) in the face of loss. What I had mentioned earlier was the use of the precedence/priority field to indicate the probability of drop in a congestion situation. This would be marked (or policed) at network ingress, or could be set by the originating host. If there is no congestion, everyone is happy. If there is congestion, then an weighted congestion avoidance mechanism (similar to what is discussed in http://www.eecs.umich.edu/~wuchang/ered/) would determine which packets are dropped first based on the priority. Food for thought. - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 21 17:53:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA20381; Sat, 21 Jun 1997 17:45:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA20372; Sat, 21 Jun 1997 17:44:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA20089; Sat, 21 Jun 1997 17:46:43 -0700 Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA26707 for ; Sat, 21 Jun 1997 17:47:38 -0700 Received: from etobicoke.firstmaple.ca ([207.34.220.193]) by bureau6.utcc.utoronto.ca with SMTP id <159772(3)>; Sat, 21 Jun 1997 20:46:42 -0400 Message-ID: <33AC733B.2781E494@utoronto.ca> Date: Sat, 21 Jun 1997 20:35:07 -0400 From: Edward Ing X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.7-RELEASE i386) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 4041) Permanent IP addresses should be available as a commondity. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1092 To maintain the original spirit of the Internet -- accessibitity to cheap and free global communications -- rights to the use of a fixed IP addresses should be a cheap commodity rather than an expensive item horded by ISPs and sold at a premium to their clients. In implementing IPv6, has the IETF made considerations how the IP addresses will be distributed in such a way that the zillions of new IP address, made available by adopting IPv6, will not be horded but be easily obtainable by individauls and small groups of individuals. Edward Ing P.S. If this is not the appropiate place for discussing this issue, please direct me to an organization, mailing list or newsgroup to which I can vent my thoughts. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 21 18:35:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA20457; Sat, 21 Jun 1997 18:27:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA20450; Sat, 21 Jun 1997 18:26:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA22981; Sat, 21 Jun 1997 18:28:52 -0700 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA29241 for ; Sat, 21 Jun 1997 18:29:47 -0700 Received: from big-dawgs.cisco.com (herndon-dhcp-109.cisco.com [171.68.53.109]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id SAA24137; Sat, 21 Jun 1997 18:28:50 -0700 (PDT) Message-Id: <3.0.1.32.19970621212846.006fa8b8@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Sat, 21 Jun 1997 21:28:46 -0400 To: Edward Ing From: Paul Ferguson Subject: (IPng 4042) Re: Permanent IP addresses should be available as a commondity. Cc: ipng@sunroof.eng.sun.com In-Reply-To: <33AC733B.2781E494@utoronto.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1932 At 08:35 PM 06/21/97 -0400, Edward Ing wrote: >To maintain the original spirit of the Internet -- accessibitity to >cheap and free global communications -- rights to the use of a fixed IP >addresses should be a cheap commodity rather than an expensive item >horded by ISPs and sold at a premium to their clients. > >In implementing IPv6, has the IETF made considerations how the IP >addresses will be distributed in such a way that the zillions of new IP >address, made available by adopting IPv6, will not be horded but be >easily obtainable by individauls and small groups of individuals. > >Edward Ing > >P.S. If this is not the appropiate place for discussing this issue, >please direct me to an organization, mailing list or newsgroup to which >I can vent my thoughts. This is indeed an inappropriate forum for discussion of this issue. I would suggest that the issue is more appropriately discussed in the forums which also discuss IPv4 address allocation, however, there are certain indications that discussions regarding IPv6 address allocation are not quite ready for primetime. In fact, there is currently dissension on IPv4 address allocation. As an aside, the confounding problem with IPv6 address allocation is not that someone may try to hoard address space, it is more an issue of not increasing the size of the global routing table by additional prefixes by allocation without the capability to aggregate. And while the final IPv6 address format is in limbo, it will probably be some time before these issues are visited. - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 09:17:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24293; Wed, 25 Jun 1997 09:08:49 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24286; Wed, 25 Jun 1997 09:08:45 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06291; Wed, 25 Jun 1997 09:10:51 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA14378; Wed, 25 Jun 1997 09:09:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA24110; Wed, 25 Jun 1997 06:23:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25982; Wed, 25 Jun 1997 06:25:19 -0700 Received: from mailhub.axion.bt.co.uk (mailhub.axion.bt.co.uk [132.146.5.4]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA04562 for ; Wed, 25 Jun 1997 06:26:17 -0700 Received: from rambo.futures.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 25 Jun 1997 14:24:15 +0100 Received: from tb-platinum.info.bt.co.uk (actually mussel.futures.bt.co.uk) by rambo with SMTP (PP); Wed, 25 Jun 1997 14:26:58 +0100 Received: by tb-platinum.info.bt.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BC8173.C1A242B0@tb-platinum.info.bt.co.uk>; Wed, 25 Jun 1997 14:26:22 +0100 Message-ID: From: George Tsirtsis To: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 4044) eXchanges in new address architecture Date: Wed, 25 Jun 1997 14:19:01 +0100 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1426 Dear all, After the last IETF meeting the IPng WG produced (and recently updated) the following draft. An IPv6 Aggregatable Global Unicast Address Format The addressing issue was extensively discussed on the mailing list and the draft reflected the conversation. It is obvious, however, that the draft was influenced from discussions during the IETF meeting which were not transferred on the mailing list. Note that the last IPng WG meeting was not even transmitted over the mbone. As a result people (including me) that did not attend the IETF meeting are in the dark on key aspects of the above draft. I am specifically referring to the Exchanges as mentioned (but not defined). The IETF Meeting in Munich is approaching quickly and I for one would appreciate a preliminary summary/discussion on the subject to help us understand and appreciate this important issue. Kind regards George Internet Transport Research ART, BTLabs B29/129 Tel: 0044-1473-640756 e-mail: george.tsirtsis@bt-sys.bt.co.uk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 09:51:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24355; Wed, 25 Jun 1997 09:41:54 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24348; Wed, 25 Jun 1997 09:41:45 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA18474; Wed, 25 Jun 1997 09:42:02 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA05178 for ; Wed, 25 Jun 1997 09:41:18 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id JAA04402; Wed, 25 Jun 1997 09:41:05 -0700 Message-Id: <3.0.2.32.19970625094100.008bb780@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 25 Jun 1997 09:41:00 -0700 To: George Tsirtsis From: Bob Hinden Subject: (IPng 4045) Re: eXchanges in new address architecture Cc: "'ipng@sunroof.Eng.Sun.COM'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1495 George, >The addressing issue was extensively discussed on the mailing list and >the draft reflected the conversation. It is obvious, however, that the >draft was influenced from discussions during the IETF meeting which were >not transferred on the mailing list. Note that the last IPng WG meeting >was not even transmitted over the mbone. We were able to have the last IPng session on the MBONE. It was not on the original MBONE schedule. >As a result people (including me) that did not attend the IETF meeting >are in the dark on key aspects of the above draft. I am specifically >referring >to the Exchanges as mentioned (but not defined). Exchanged do need more work. The new addressing draft while supporting exchanges, are not dependent on having exchanges nor do they require exchanges. >The IETF Meeting in Munich is approaching quickly and I for one would >appreciate a preliminary summary/discussion on the subject to help us >understand and appreciate this important issue. I hope to issue an ID on exchanges. If there is interest we can try to have some time on the agenda for Munich. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 11:14:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24517; Wed, 25 Jun 1997 11:06:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24510; Wed, 25 Jun 1997 11:05:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA17112; Wed, 25 Jun 1997 11:07:17 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA06605 for ; Wed, 25 Jun 1997 11:08:04 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id LAA08854; Wed, 25 Jun 1997 11:07:08 -0700 Message-Id: <3.0.2.32.19970625110703.00832db0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 25 Jun 1997 11:07:03 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4046) IPng Working Group Sessions for Munich IETF Cc: hinden@Ipsilon.COM, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1361 We have reserved two sessions at the Munich IETF. Please send Steve and I requests for agenda slots. Thanks, Bob >X-Sender: mbeaulie@ietf.org >X-Mailer: Windows Eudora Pro Version 2.2 (32) >Date: Thu, 19 Jun 1997 16:52:02 -0400 >To: Bob Hinden >From: Marcia Beaulieu >Subject: 39th IETF: IPNGWG >Cc: deering@cisco.com, burgan@home.net, narten@raleigh.ibm.com > >Bob, > >This is to confirm two sessions for IPNGWG as follows: > > Wednesday, August 13 at 1530-1730 (opposite cat, snmpv3, mpls, > asid) > Thursday, August 14 at 1300-1500 (opposite ptopomib, saag, acap > rtfm, qosr) > >Please submit an agenda for these meetings as soon as possible so I can >post them on the web. > >Thanks, > >Marcia > >********************************************************************** >Marcia Beaulieu >IETF Meeting Coordinator >Voice: 703-620-8990 ext. 210 >Fax: 703-758-5913 > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 12:43:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24595; Wed, 25 Jun 1997 12:34:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24588; Wed, 25 Jun 1997 12:34:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA10114; Wed, 25 Jun 1997 12:36:03 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA03795 for ; Wed, 25 Jun 1997 12:37:01 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id MAA04633; Wed, 25 Jun 1997 12:35:54 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <970614202623_1044836660@emout08.mail.aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Jun 1997 12:35:53 -0700 To: HDhil@aol.com From: Steve Deering Subject: (IPng 4047) Re: Forgive the aside Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2591 At 5:26 PM -0700 6/14/97, HDhil@aol.com wrote: > Not to interrupt this good discussion of traffic policing and changes to the > priority field in the IPv6 header, but has the IPng made any action on the > use of the flow-id field being used to carry MPLS tags, eg. as in Cisco's tag > switching? I saw it mentioned in the minutes once, and i was wondering how > and if IPng had discussed any ramifications of doing so, and also to what > degree the field was useful in conjunction with RSVP being used to signal QoS > for packet flows as well. Harry, There was some discussion of the use of the IPv6 Flow Label field to carry tags on the ipng mailing list last October, in response to a draft proposal by Baker et al (draft-baker-flow-label-00.txt). There has been no further discussion since then, and I see that that draft has timed-out of the Internet Drafts directories. I assumed that this topic would be discussed in the MPLS Working Group, and if that group came to consensus that a change to the IPv6 Flow Label semantics was desirable (as opposed to, say, conveying tags the same way as for IPv4, e.g., by a layer 2.5 shim), that they would bring such a proposal to the IPng Working Group. We have once or twice allocated an IPng WG agenda slot for that purpose, but no one has has yet taken advantage of those opportunities. Similarly, we would expect the RSVP or Integrated Services Working Groups to let us know if the IPv6 Flow Label doesn't suit their purposes for some reason. So far, we haven't heard anything, so I am assuming that the current semantics are adequate. The IPng WG did make one decision that would facilitate changes to the Flow Label semantics of the sort suggested in draft-baker-flow-label-00.txt: we decided that the Flow Label ought to be excluded from the set of fields included in the authentication computation for the Authentication Header (though we have not yet confirmed this behavior with the IPsec working group that now owns the Authentication Header). That would enable routers to modify the Flow Label en-route (e.g., hop by hop) without causing athentication failure at the receiver. Steve Deering (wearing my IPng WG co-chair hat, not my Cisco hat) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 25 15:11:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA25051; Wed, 25 Jun 1997 15:02:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA25044; Wed, 25 Jun 1997 15:02:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA19137; Wed, 25 Jun 1997 15:04:36 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA19906 for ; Wed, 25 Jun 1997 15:05:30 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA20343 for ; Wed, 25 Jun 1997 15:04:32 -0700 Message-Id: <3.0.2.32.19970625150428.00908100@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 25 Jun 1997 15:04:28 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4048) Re: IPng Working Group Sessions for Munich IETF In-Reply-To: <3.0.2.32.19970625110703.00832db0@mailhost.ipsilon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 934 I forgot to add that both sessions will be Multicast. Bob >>Date: Thu, 19 Jun 1997 16:52:02 -0400 >>To: Bob Hinden >>From: Marcia Beaulieu >>Subject: 39th IETF: IPNGWG >>Cc: deering@cisco.com, burgan@home.net, narten@raleigh.ibm.com >> >>Bob, >> >>This is to confirm two sessions for IPNGWG as follows: >> >> Wednesday, August 13 at 1530-1730 (opposite cat, snmpv3, mpls, >> asid) >> Thursday, August 14 at 1300-1500 (opposite ptopomib, saag, acap >> rtfm, qosr) >> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 27 09:26:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29783; Fri, 27 Jun 1997 09:13:39 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA29776; Fri, 27 Jun 1997 09:13:34 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA15417; Fri, 27 Jun 1997 09:15:38 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18111; Fri, 27 Jun 1997 09:14:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA29709; Fri, 27 Jun 1997 07:59:20 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA28204; Fri, 27 Jun 1997 08:01:19 -0700 Received: from kilkenny.inria.fr (kilkenny.inria.fr [128.93.30.39]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA22994 for ; Fri, 27 Jun 1997 08:02:15 -0700 Received: from kilkenny.inria.fr (localhost [127.0.0.1]) by kilkenny.inria.fr (8.8.5/8.8.5) with ESMTP id RAA04348 for ; Fri, 27 Jun 1997 17:01:24 +0200 (CEST) Message-Id: <199706271501.RAA04348@kilkenny.inria.fr> X-Mailer: exmh version 2.0gamma 1/27/96 To: ipng@sunroof.eng.sun.com Subject: (IPng 4050) comments on Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 1997 17:01:23 +0200 From: Vincent Levigneron Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 656 Hi !!! I have a question about the DHCPv6 Extensions Draft. There's something I don't understand and I think this is an error. Page 12 and page 13, there's writen that when the F bit is not set, the "DA length" field must be 4 ???? I think it's 16. Regards. Vincent -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 27 12:14:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA00030; Fri, 27 Jun 1997 12:00:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA00023; Fri, 27 Jun 1997 12:00:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA06942; Fri, 27 Jun 1997 12:02:08 -0700 Received: from kalae.kohala.com (kalae.kohala.com [206.62.226.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA05427 for ; Fri, 27 Jun 1997 12:03:01 -0700 Received: from kohala.kohala.com (kohala.kohala.com [206.62.226.33]) by kalae.kohala.com (8.8.5/8.8.5) with ESMTP id MAA23366 for ; Fri, 27 Jun 1997 12:01:10 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id MAA29879 for ipng@sunroof.Eng.Sun.COM; Fri, 27 Jun 1997 12:01:10 -0700 (MST) Message-Id: <199706271901.MAA29879@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 27 Jun 1997 12:01:09 -0700 Reply-To: "W. Richard Stevens" X-Phone: +1 520 297 9416 X-Homepage: http://www.kohala.com/~rstevens X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: ipng@sunroof.eng.sun.com Subject: (IPng 4051) draft-stevens-advanced-api-03.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7362 A new version of the "Advanced Sockets API for IPv6" I-D was just submitted, and should be in all the normal locations within a few days. If you want a copy sooner, it's at ftp://ftp.kohala.com/pub/rstevens/draft-stevens-advanced-api-03.txt A working group last call was done in Memphis on the -02 version of this I-D, but some substantial comments were raised. This revision addresses all those comments (I think). We therefore wanted to go through another revision of the I-D, and do another last call in Munich. Attached is the change list from the new I-D. Rich Stevens ---------------------------------------------------------------------- 15. Change History Changes from the March 1997 Edition (-02 draft) - In May 1997 Draft 6.6 of Posix 1003.1g (called Posix.1g herein) passed ballot and will be forwarded to the IEEE Standards Board later in 1997 for final approval. Some changes made for this final Posix draft are incorporated into this Internet Draft, specifically the datatypes mentioned in Section 1 (and used throughout the text), and the socklen_t datatype used in Section 4.1 and 4.2. - Section 1: Added the intN_t signed datatypes, changed the datatype u_intN_t to uintN_t (no underscore after the "u"), and removed the datatype u_intNm_t, as per Draft 6.6 of Posix.1g. - Name space issues for structure and constant names in Section 2: Many of the structure member names and constant names were changed so that the prefixes are the same. The following prefixes are used for structure members: "ip6_", "icmp6_", and "nd_". All constants have the prefixes "ICMP6_" and "ND_". - New definitions: Section 2.1.2: contains definitions for the IPv6 extension headers, other than AH and ESP. Section 2.2.2: contains additional structures and constants for the neighbor discovery option header and redirected header. - Section 2.2.2: the enum for the neighbor discovery option field was changed to be a set of #define constants. - Changed the word "function" to "macro" for references to all the uppercase names in Sections 2.3 (IN6_ARE_ADDR_EQUAL), 3.2 (ICMPV6_FILTER_xxx), and 4.3 (CMSG_xxx). - Added more protocols to the /etc/protocols file (Section 2.4) and changed the name of "icmpv6" to "ipv6-icmp". - Section 3: Made it more explicit that an application cannot read or write entire IPv6 packets, that all extension headers are passed as ancillary data. Added a sentence that the kernel fragments packets written to an IPv6 raw socket when necessary. Added a note that IPPROTO_RAW raw IPv6 sockets are not special. - Section 3.1: Explicitly stated that the checksum option applies to both outgoing packets and received packets. - Section 3.2: Changed the array name within the icmp6_filter structure from "data" to "icmp6_filt". Changes the prefix for the filter macros from "ICMPV6_" to "ICMP6_", for consistency with the names in Section 2.2. Changed the example from a ping program to a program that wants to receive only router advertisements. - Section 4.1: Changed msg_namelen and msg_controllen from size_t to the Posix.1g socklen_t datatype. Updated the Note that follows. - Section 4.2: Changed cmsg_len from size_t to the Posix.1g socklen_t datatype. Updated the Note that follows. - Section 4.4: Added a Note that the second and third arguments to getsockopt() and setsockopt() are intentionally the same as the cmsg_level and cmsg_type members. - Section 4.5: Reorganized the section into a description of the option, followed by the TCP semantics, and the UDP and raw socket semantics. Added a sentence on how to clear all the sticky options. Added a note that TCP need not save the options from the most recently received segment until the application says to do so. Added the statement that ancillary data is never passed with sendmsg() or recvmsg() on a TCP socket. Simplified the interaction of the sticky options with ancillary data for UDP or raw IP: none of the sticky options are sent if ancillary data is specified. - Final paragraph of Section 5.1: ipi6_index should be ipi6_ifindex. - Section 5.4: Added a note on the term "privileged". - Section 5.5: Noted that the errors listed are examples, and the actual errors depend on the implementation. - Removed Section 6 ("Flow Labels") as the consensus is that it is premature to try and specify an API for this feature. Access to the flow label field in the IPv6 header is still provided through the sin6_flowinfo member of the IPv6 socket address structure in [RFC-2133]. Added a subsection to Section 13 that this is a future item. All remaining changes are identified by their section number in the previous draft. With the removal of Section 6, the section numbers are decremented by one. - Section 7.3.7: the calls to malloc() in all three examples should be calls to inet6_option_space() instead. The two calls to inet6_option_append() in the third example should be calls to inet6_option_alloc(). The two calls to CMSG_SPACE() in the first and third examples should be calls to CMSG_LEN(). The second call to CMSG_SPACE() in the second example should be a call to CMSG_LEN(). - Section 7.3.7: All the opt_X_ and opt_Y_ structure member names were changed to be ip6_X_opt_ and ip6_Y_opt_. The two structure names ipv6_opt_X and ipv6_opt_Y were changed to ip6_X_opt and ip6_Y_opt. The constants beginning with IPV6_OPT_X_ and IPV6_OPT_Y_ were changed to begin with IP6_X_OPT_ and IP6_Y_OPT_. - Use the term "Routing header" throughout the draft, instead of "source routing". Changed the names of the eight inet6_srcrt_XXX() functions in Section 9 to inet6_rthdr_XXX(). Changed the name of the socket option from IPV6_SRCRT to IPV6_RTHDR, and the names of the three IPV6_SRCRT_xxx constants in Section 9 to IPV6_RTHDR_xxx. - Added a paragraph to Section 9 on how to receive and send a Routing header. - Changed inet6_rthdr_add() and inet6_rthdr_reverse() so that they return -1 upon an error, instead of an Exxx errno value. - In the description of inet6_rthdr_space() in Section 9.1, added the qualifier "For an IPv6 Type 0 Routing header" to the restriction of between 1 and 23 segments. - Refer to final function argument in Sections 9.7 and 9.8 as index, not offset. - Updated Section 14 with new names from Section 2. - Changed the References from "[n]" to "[RFC-abcd]". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 27 19:13:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA00927; Fri, 27 Jun 1997 18:57:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA00920; Fri, 27 Jun 1997 18:57:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA27282; Fri, 27 Jun 1997 18:59:17 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA18781 for ; Fri, 27 Jun 1997 19:00:17 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id SAA27841; Fri, 27 Jun 1997 18:59:19 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Jun 1997 18:59:18 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 4053) IPv6 option code spaces Cc: iana@isi.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3509 While working on the update to the base IPv6 spec, I have uncovered a lack of necessary precision in the description of the Option Type values used inside the Hop-by-Hop Options and Destination Options headers. Recall that the 8-bit Option Type is internally structured as follows: +-+-+-+-+-+-+-+-+ |ACT|C| OP | +-+-+-+-+-+-+-+-+ where ACT specifies the action to be taken if this Option Type is not recognized (ignore, discard, etc.), C specifies whether or not the Data part of this option is subject to change en route, and OP identifies the specific option. The following two matters are unclear in the current spec: (1) Is the "meaning" of an option identified by the OP subfield alone, or by the OP subfield in combination with particular values of the ACT and C subfields? In other words, is it permitted to define two, unrelated options whose Option Types have the same OP value and differ only in the value of the ACT or C fields? (2) Is the numbering space for Option Types used in the Hop-by-Hop Options header the same as, or separate from, the space of Option Types used in the Destination Options header? In other words, is it permitted to assign the same Option Type to two different options, one to be used only Hop-by-Hop and one to be used only as a Destination option? My own preference would be to say that the OP subfield alone identifies a given option, regardless of the values of the ACT and C subfields, and that the Option Types for both option-bearing headers are taken from the same numbering space. According to those rules, the assignment of Option Type 11000010 to the Jumbo Payload hop-by-hop option would imply that the bit pattern xxx00010 could not, for example, be re-used for a different option that was used only in the Destination Options header. I prefer those rules because they are the most straightforward and "unsurprising". It appears also that those are the rules that IANA has assumed -- see: ftp://ftp.isi.edu/in-notes/iana/assignments/ipv6-parameters However, I could understand folks preferring different rules that permitted some reuse of OP values, mainly because the 5-bit OP space is so small that some might worry about running out of values in the future. (I'm not a big fan of options, myself, so I consider a scarcity of potential option values to be a feature rather than a bug.) I'd like to hear if anyone has a strong opinion, one way or the other. I'd also like IPv6 implementors to take a look at their code and tell me what assumptions they have already made in this regard. For example, do you "switch" on the full 8-bit value of an Option Type, or do you mask off the high-order 3 bits before switching? Is your code that parses Hop-by-Hop options separate from the code the parses Destination options, and if so, do you use the same or different symbolic names for the Option Type values in those two places? Would it be a problem for you if the process of making the spec unambiguous resulted in you having to change your code? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 27 19:36:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA00946; Fri, 27 Jun 1997 19:22:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA00939; Fri, 27 Jun 1997 19:22:03 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA29165; Fri, 27 Jun 1997 19:23:59 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA21536 for ; Fri, 27 Jun 1997 19:24:58 -0700 Received: from [171.69.199.124] (deering-mac.cisco.com [171.69.199.124]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id TAA28869; Fri, 27 Jun 1997 19:24:00 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 27 Jun 1997 19:23:58 -0700 To: iana@isi.edu From: Steve Deering Subject: (IPng 4054) IPv6 Option Code collision Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1398 Dear IANA, I just noticed a code-point collision in the space of codes that identify IPv6 options. I see on your web page: ftp://ftp.isi.edu/in-notes/iana/assignments/ipv6-parameters that you have assigned an operation code (that is, the low-order 5 bits of the IPv6 option code) value 3 to "Endpoint Identifier for Nimrod" option. However, RFC-1888 specifies the value 3 as the operation code for the "NSAP Address" option. This collision is probably my fault -- I think I told the authors of RFC-1888 to use code value 3 before the point at which you started to assign IPv6 parameters (or at least before the point at which I learned that you had commenced assignments for IPv6). Shall I leave this to you to sort out between the authors of the colliding specs, or do you want me to coordinate a resolution? I would guess that neither spec has been widely implemented, so it probably won't be too painful to change either one. (I'm sure someone will jump in at this point if my guess is wrong!) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 28 09:56:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01670; Sat, 28 Jun 1997 09:38:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01663; Sat, 28 Jun 1997 09:38:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA19128; Sat, 28 Jun 1997 09:40:20 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA02046 for ; Sat, 28 Jun 1997 09:41:19 -0700 Received: from ftp.com by ftp.com ; Sat, 28 Jun 1997 12:40:17 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Sat, 28 Jun 1997 12:40:17 -0400 Received: from trenton.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id MAA13179; Sat, 28 Jun 1997 12:36:21 -0400 Message-Id: <199706281636.MAA13179@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: deering@cisco.com, ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 4055) RE: IPv6 option code spaces Date: Sat, 28 Jun 1997 12:37:17 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: quoted-printable Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1380 (removing IANA from reply thread..) >>Reply to your message of 6/28/97 4:26 AM > I'd also like IPv6 implementors to take a look at their code and tell > me what assumptions they have already made in this regard. For example, > do you "switch" on the full 8-bit value of an Option Type, or do you > mask off the high-order 3 bits before switching? The switch is based on the full eight bit value. My natural inclination is to conserve the option number space but there's always the option (as it were) of defining other header types if that ever becomes necessary.. > Is your code that parses > Hop-by-Hop options separate from the code the parses Destination options, > and if so, do you use the same or different symbolic names for the Option > Type values in those two places? Different code, different #defines. > Would it be a problem for you if the > process of making the spec unambiguous resulted in you having to change > your code? Given GSE, I can't see this as being a big issue.. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 28 18:03:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA02066; Sat, 28 Jun 1997 17:55:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA02053; Sat, 28 Jun 1997 17:54:33 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA15335; Sat, 28 Jun 1997 17:56:25 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA15992 for ; Sat, 28 Jun 1997 17:57:23 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA26602; Sat, 28 Jun 97 17:49:46 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id RAA03391; Sat, 28 Jun 1997 17:56:10 -0700 Date: Sat, 28 Jun 1997 17:56:10 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199706290056.RAA03391@feller.mentat.com> To: ipng@sunroof.eng.sun.com, deering@cisco.com Subject: (IPng 4056) Re: IPv6 option code spaces X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1658 Steve, > (I'm not a big fan of options, myself, so I consider a scarcity of > potential option values to be a feature rather than a bug.) My sentiments exactly. > > I'd also like IPv6 implementors to take a look at their code and tell > me what assumptions they have already made in this regard. For example, > do you "switch" on the full 8-bit value of an Option Type, or do you > mask off the high-order 3 bits before switching? Is your code that parses > Hop-by-Hop options separate from the code the parses Destination options, > and if so, do you use the same or different symbolic names for the Option > Type values in those two places? Would it be a problem for you if the > process of making the spec unambiguous resulted in you having to change > your code? > We switch on the OP portion of the option type field only. We mask off the high-order 3 bits. We have seperate code for hop-by-hop and destination option headers. The same #define name space is used for both hop-by-hop and destination options. Assuming you proposal is adopted I don't believe we would need to change our code. Regardless, these things are very minor items which would not require large effort to change if your proposal is modified en route to group consensus. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 29 03:51:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA02339; Sun, 29 Jun 1997 03:43:27 -0700 Received: from sunmail1.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA02332; Sun, 29 Jun 1997 03:42:49 -0700 Received: from saturn.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id DAA24409; Sun, 29 Jun 1997 03:44:43 -0700 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.7.249]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA22771 for ; Sun, 29 Jun 1997 03:45:42 -0700 Received: from uvite33.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA26809; Sun, 29 Jun 1997 06:44:37 -0400 X-Sender: droms@mail.bucknell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 29 Jun 1997 06:44:44 -0400 To: Vincent Levigneron , ipng@sunroof From: droms@bucknell.edu (Ralph Droms) Subject: (IPng 4057) Re: comments on Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 887 At 5:01 PM 6/27/97, Vincent Levigneron wrote: >Page 12 and page 13, there's writen that when the F bit is not set, >the "DA length" field must be 4 ???? I think it's 16. > >Regards. > > Vincent I'm away from my office and don't have access to the drafts - I'll take a look as soon as I get back. You might want to post your query to the DHCPv6 mailing list, dhcp-v6@bucknell.edu, where a WG last call for comments on the DHCPv6 Internet Drafts was recently issued. - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 30 11:31:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04018; Mon, 30 Jun 1997 11:22:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA04011; Mon, 30 Jun 1997 11:22:44 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA23150; Mon, 30 Jun 1997 11:24:44 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA19581 for ; Mon, 30 Jun 1997 11:25:45 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id LAA04894; Mon, 30 Jun 1997 11:24:45 -0700 Message-Id: <3.0.2.32.19970630112427.007cdc30@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 30 Jun 1997 11:24:27 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4060) W.G. Last Call on "Advanced Sockets API for IPv6" Cc: hinden@Ipsilon.COM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 981 This is a IPng working group last call for comments on advancing the following document to Informational: Title : Advanced Sockets API for IPv6 Author(s) : W. Stevens, M. Thomas Filename : draft-stevens-advanced-api-03.txt Pages : 67 Date : 06/27/1997 This draft reflects issues found during the previous last call. Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end two weeks from today, on July 14, 1997. Bob Hinden / Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 30 13:19:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04248; Mon, 30 Jun 1997 13:09:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04241; Mon, 30 Jun 1997 13:09:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA18406; Mon, 30 Jun 1997 13:11:32 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA19769 for ; Mon, 30 Jun 1997 13:12:33 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id NAA09766; Mon, 30 Jun 1997 13:09:01 -0700 Message-Id: <3.0.2.32.19970630130849.0089be30@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 30 Jun 1997 13:08:49 -0700 To: jburgan@BayNetworks.com From: Bob Hinden Subject: (IPng 4061) Request to Advance "IPv6 MIB Documents" Cc: narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1785 Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following documents be published as RFCs with Experimental status: Title : Management Information Base for IP Version 6: Textual Conventions and General Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-mib-02.txt Pages : 41 Date : 06/10/1997 Title : Management Information Base for IP Version 6: ICMPv6 Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-icmp-mib-01.txt Pages : 18 Date : 03/24/1997 Title : IP Version 6 Management Information Base for the Transmission Control Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-tcp-mib-00.txt Pages : 6 Date : 06/10/1997 Title : IP Version 6 Management Information Base for the User Datagram Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-udp-mib-00.txt Pages : 5 Date : 06/10/1997 A working group last call for these documents was completed on June 27, 1997. No comments were received during the last call. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------