From owner-ipng@sunroof.eng.sun.com Tue Jul 1 09:16:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05503; Tue, 1 Jul 1997 09:07:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05496; Tue, 1 Jul 1997 09:07:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA02425; Tue, 1 Jul 1997 09:09:44 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA26041 for ; Tue, 1 Jul 1997 09:10:45 -0700 Received: from rtpmail01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA09986; Tue, 1 Jul 1997 12:09:43 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA22260 for ; Tue, 1 Jul 1997 12:09:42 -0400 Received: from lig32-225-17-44.us.lig-dial.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19540; Tue, 1 Jul 1997 12:08:18 -0400 Received: from hygro.raleigh.ibm.com (localhost [127.0.0.1]) by hygro.raleigh.ibm.com (8.7.6/8.7.3) with ESMTP id MAA01914 for ; Tue, 1 Jul 1997 12:08:55 -0400 Message-Id: <199707011608.MAA01914@hygro.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4062) draft-ietf-ipngwg-addr-arch-v2-01.txt Date: Tue, 01 Jul 1997 12:08:55 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 10515 Speaking as an individual, here are some comments on version -01 of the draft: > 2) Routers may have unnumbered interfaces (i.e., no IPv6 address > assigned to the interface) on point-to-point links to eliminate > the necessity to manually configure and advertise the addresses. > Addresses are not needed for point-to-point interfaces on routers > if those interfaces are not to be used as the origins or > destinations of any IPv6 datagrams. Are unnumbered interfaces truly unnumbered? That is, do they not have link-local addresses? Do they not run Neighbor Discovery (and NUD) at all? > Currently IPv6 continues the IPv4 model that a subnet is associated > with one link. Multiple subnets may be assigned to the same link. Is the first sentence really correct given aggregation? I think the problem is with the term "subnet", which doesn't mean the same thing as "prefix identifying a specific link". Not sure how best to reword (or whether to just leave alone). > (2) The format prefixes 001 and higher, except for Multicast > Addresses (1111 1111), are all required to have to have 64-bit > interface identifiers in EUI-64 format. See section 2.5.1 for > definitions. How about changing "001 and higher" to "001 through 111" Also, in reading through both this and the unicast aggregation document, it seems that the term "EUI-64 format" for an interface identifier isn't ideal. Randomly generated IDs, for example, are not related to EUI-64 at all. Also, by inverting the I/G bit, the identifer is not in EUI-64 format. Could we change the name to something like "EUI-64 derived identifier" or "EUI-64 friendly identifier" or ???? (This terminology issue comes up again later). >2.5 Unicast Addresses > > The IPv6 unicast address is contiguous bit-wise maskable, similar to > IPv4 addresses under Class-less Interdomain Routing [CIDR]. Not sure what the above means. Do you mean to say that unicast addresses are meant to be aggregatable ala CIDR, so all subnet masks must be contiguous? >2.5.1 Interface Identifiers How do these relate to interface tokens? The v6-over-ethernet spec (and others, such as stateless autoconf) don't use this terminology. I don't think (in theory) that interface tokens and interface identifiers are exactly the same thing, though in practice I think we're using them to mean pretty much the same thing. It would be good to get the common terminology right and used consistently in the various documents. > interfaces on a single node. Note that the use of the same interface > identifier on multiple interfaces of a single node does not affect > the interface identifier's global uniqueness. How about changing "does not affect the interface identifier's global uniqueness" to something like "does not violate the global uniqueness requirements for IPv6 addresses, as long as the interfaces are on different links (i.e., the prefix bits will differ)." > links, tunnel end-points, etc.). It is required that the "u" bit > (universal/local bit in IEEE EUI-64 terminology) be inverted when > forming the interface identifier. How about adding "... from the EUI-64". >2.5.3 The Loopback Address > > The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. > It may be used by a node to send an IPv6 datagram to itself. It may > never be assigned to any interface. I don't think this last sentence is quite correct. How can you send a packet to yourself if it is not addressed to one of your interfaces? How does the interface accept the packet as addressed to it? Is the sentence needed? Would it be useful to state that a loopback address is conceptually the same thing as an address having node-local scope (which IPv6 does not define), i.e., one that may never leave the machine and be sent out on an actual link? I think that is the point that the above text is trying to insure. > This mapping of NSAP address into IPv6 addresses is defined in > [NSAP]. This document recommends that network implementors who have > planned or deployed an OSI NSAP addressing plan, and who wish to > deploy or transition to IPv6, should redesign a native IPv6 > addressing plan to meet their needs. However, it also defines a set > of mechanisms for the support of OSI NSAP addressing in an IPv6 > network. These mechanisms are the ones that must be used if such > support is required. This document also defines a mapping of IPv6 > addresses within the OSI address format, should this be required. Isn't the OSI NSAP plan an informational RFC? I suspect it's not appropriate to recommend (i.e., "these mechanisms are the ones that must be used if ...") an Informational RFC as the Right Way to do something. > Routers MUST not forward any packets with link-local source or > destination addresses to other links. Hmm. Do we need to say something about Routing Headers? At first, I thought Routing Headers are implicitly covered by the above. But that turns out not to be completely true. Consider: addresses G1, LL2, G2, G3, where G denotes a global scope address, LL denotes a link-local address. If G1, LL2 and G2 were on the same link, but G3 was not, we could have a routing header that said go via LL2, G2, and G3 that would allow a packet with a LL address to be forwarded out of scope. I think we need to have specific text that clarifies whether this is allowed. > Site-Local addresses have the following format: > > | 10 | > | bits | 38 bits | 16 bits | 64 bits | > +----------+-------------+-----------+----------------------------+ > |1111111011| 0 | subnet ID | interface ID | > +----------+-------------+-----------+----------------------------+ In the above, the SLA part appears to be fixed at 16 bits, whereas in the aggregatable address section, these fields are not defined. Instead, there is a reference to another document (that define the SLA to be 16 bits). Don't we want both address formats to use the same value for subnet ID field? I think we want to say that somewhere, though I'm not sure where. This document or another one? If the latter, which one? > Routers MUST not forward any packets with site-local source or > destination addresses outside of the site. I think we need to say something about Routing Headers here as well. > A node is required to compute and support a Solicited-Node multicast > addresses for every unicast and anycast address it is assigned. How about: A node is required to compute and join the associated Solicited-Node multicast address for every unicast and anycast address it is assigned. > The current approach [RFC1972] to map IPv6 multicast addresses into > IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 > multicast address and uses it to create a MAC address. Groups ID's Token ring is 802 and does things differently, so the above reference to 802 is not correct. :-( > multicast address and uses it to create a MAC address. Groups ID's ^^^^^^ Group > less than or equal to 32 bits will generate unique MAC addresses. > A host is required to recognize the following addresses as > identifying itself: > > o Its Link-Local Address for each interface > o Assigned Unicast Addresses > o Loopback Address > o All-Nodes Multicast Address > o Solicited-Node Multicast Address for each of its assigned > unicast and anycast addresses > o Multicast Addresses of all other groups which the host belongs. ^^ add "to" Also, anycast address shouldn't be mentioned on hosts > A router is required to recognize the following addresses as > identifying itself: Rather than repeating them, how about saying that "a router recognizes all the addresses a host is required to recognize, plus ..." and then list them > o The Subnet-Router anycast addresses for the links it has > interfaces. Change to: o The Subnet-Router anycast addresses for the interface it is configured to act as a router on. > o All-Router Multicast Address Should that be all-routers (plural)? > o Multicast Addresses of all other groups which the router > belongs. "to" which the router belongs > The only address prefixes which should be predefined in an > implementation are the: > > o Unspecified Address > o Loopback Address These above are addresses, not prefixes, I think. > Depending on the characteristics of a specific link or node there are > a number of approaches to create EUI-64 based interface identifiers. ^^^^^^ creating > This appendix describes some of these approaches. > The only transformation from an EUI-64 identifier is to invert the transformation to what? "... from an EUI-64 identifier to an interface ID is to ..." > individual/group bit, and "v" are the bits of the vendor supplied > identifier. The IPv6 interface identifier would be of the form: Call it organzational identifier or company id (don't change terminology) rather than "vendor supplied". > and Arcnet. The method to create an EUI-64 based identifier is to > take the link identifier (e.g., the LocalTalk 8 bit node identifier) I don't think we should use the terminology "EUI-64 based" here. > When no built in identifier is available on a link the preferred built-in > Node Serial Number (or other node specific token) node-specific > There are many possible approaches to select an link-unique interface ^^ a Finally, I believe the web page on EUI-64 says that the term "EUI-64" is trademarked and cannot be referenced in a standards document without permission from IEEE. Is someone chasing this one down? Also, the use of MUST, must, MUST NOT and MUST not. is not quite consistent. How about going through the document with that in mind. For example: > The unspecified address must not be used as the destination address > of IPv6 datagrams or in IPv6 Routing Headers. should probably be MUST NOT. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 1 18:08:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA06284; Tue, 1 Jul 1997 17:57:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA06270; Tue, 1 Jul 1997 17:57:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA28400; Tue, 1 Jul 1997 17:59:25 -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 SAA17572 for ; Tue, 1 Jul 1997 18:00:28 -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 RAA12245; Tue, 1 Jul 1997 17:59:26 -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, 1 Jul 1997 17:59:21 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 4063) Re: IPv6 option code spaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3020 The responses (two here on the list and one private) confirm that the IPv6 spec is insufficiently specific in its description of the Option Type numbering space(s), in that each of the three implementors interpreted the spec differently. Each also said it would not be a big problem to change that bit of his code, if necessary. I've thought a little more about this, and want to change my preference, as stated in my initial note. In particular, I now propose the following clarifications: (1) Each option is identified by a full 8-bit value, with the property that its high-order 3 bits appropriately encode the action-if-unrecognized and change-en-route behavior. This means: - two option codes that are identical in their low-order 5 bits, but different in their high-order 3 bits, are considered to be two distinct options. - the code that parses options should "switch" on the full 8-bit Option Type, not on the low-order 5 bits alone. (2) The same numbering space is used for both Hop-by-Hop and Destination options. This means: - a single 8-bit Option Type value cannot be used for two different options, one Hop-by-Hop and one Destination. - an implementor may (but is not required to) share a a single piece of code and a single set of #defines for parsing both Hop-by-Hop and Destination options. My reasons for favoring rule (1) are: - it minimizes the hazard that a programmer might forget to set the high-order bits correctly and, in fact, eliminates the need for the programmer to even think about those bits. E.g., learning that the Option Type for the Jumbo Payload option is 194 decimal is simpler and less error-prone than learning it is option number 2 with the requirement that the action-if- unrecognized bits be set to 11 and the change-en-route bit be set to 0. - it forces the designer of a new option to fully consider and specify (implicitly, by assignment of Option Type value) what the appropriate action-if-unrecognized and change-en-route behaviors should be for the new option. (If more than one behavior is desirable, more than one 8-bit Option Type value can be assigned to the new option.) - [minor] it relaxes the limit on the number of new options that can be defined (assuming not all options require the same action-if-unrecognized and change-en-route behavior). My reason for favoring rule (2) is: - it's easier for IANA to deal with only one IPv6 option numbering space than two. Any objections? If not, I'll include these clarifications in the revised IPv6 spec. 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 Jul 2 04:33:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA06563; Wed, 2 Jul 1997 04:24:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA06556; Wed, 2 Jul 1997 04:24:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA29417; Wed, 2 Jul 1997 04:26:38 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA03856 for ; Wed, 2 Jul 1997 04:27:39 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id LA10943; Wed, 2 Jul 1997 21:26:29 +1000 (from kre@munnari.OZ.AU) To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4064) Re: IPv6 option code spaces In-Reply-To: Your message of "Tue, 01 Jul 1997 17:59:21 MST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 02 Jul 1997 21:26:29 +1000 Message-Id: <4824.867842789@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 972 Date: Tue, 1 Jul 1997 17:59:21 -0700 From: Steve Deering Message-ID: | In particular, I now propose the following clarifications: I much prefer this proposal to your earlier one. | My reason for favoring rule (2) is: | - it's easier for IANA to deal with only one IPv6 option numbering | space than two. It also makes it much easier to have an option which can be either/both hop-by-hop and destination, without having to define it twice, and risk having it interpreted differently. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 06:47:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06659; Wed, 2 Jul 1997 06:37:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06652; Wed, 2 Jul 1997 06:37:44 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA13816; Wed, 2 Jul 1997 06:39:38 -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 GAA27732 for ; Wed, 2 Jul 1997 06:40:22 -0700 Received: from gungnir.fnal.gov ("port 35677"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-8 #3998) id <01IKR6YLQ2Z6000BQD@FNAL.FNAL.GOV>; Wed, 02 Jul 1997 08:39:20 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA20910; Wed, 02 Jul 1997 08:39:19 -0500 Date: Wed, 02 Jul 1997 08:39:19 -0500 From: Matt Crawford Subject: (IPng 4065) Re: IPv6 option code spaces In-reply-to: "01 Jul 1997 17:59:21 PDT." <"v03102801afdf3ac601fd"@[171.69.199.124]> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Message-id: <199707021339.IAA20910@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{ Any objections? If not, I'll include these clarifications in the > revised IPv6 spec. I think these are good choices. The other way leaves a nuisance situation for the first three bits: check them on reception or no? 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 Jul 2 06:51:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06674; Wed, 2 Jul 1997 06:41:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06667; Wed, 2 Jul 1997 06:41:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA15102; Wed, 2 Jul 1997 06:43:30 -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 GAA28711 for ; Wed, 2 Jul 1997 06:44:33 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id GAA02877; Wed, 2 Jul 1997 06:43:24 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <4824.867842789@munnari.OZ.AU> References: Your message of "Tue, 01 Jul 1997 17:59:21 MST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Jul 1997 06:43:32 -0700 To: Robert Elz From: Steve Deering Subject: (IPng 4066) Re: IPv6 option code spaces Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 839 At 4:26 AM -0700 7/2/97, Robert Elz wrote: > I much prefer this proposal to your earlier one. Good. > | My reason for favoring rule (2) is: > | - it's easier for IANA to deal with only one IPv6 option numbering > | space than two. > > It also makes it much easier to have an option which can be either/both > hop-by-hop and destination, without having to define it twice, and risk > having it interpreted differently. Right. Good point. 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 Jul 2 07:02:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06696; Wed, 2 Jul 1997 06:50:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06689; Wed, 2 Jul 1997 06:49:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA17136; Wed, 2 Jul 1997 06:51:46 -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 GAA00565 for ; Wed, 2 Jul 1997 06:52:49 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id GAA03072; Wed, 2 Jul 1997 06:51:16 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199707021339.IAA20910@gungnir.fnal.gov> References: "01 Jul 1997 17:59:21 PDT." <"v03102801afdf3ac601fd"@[171.69.199.124]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Jul 1997 06:51:24 -0700 To: Matt Crawford From: Steve Deering Subject: (IPng 4067) Re: IPv6 option code spaces Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 601 At 6:39 AM -0700 7/2/97, Matt Crawford wrote: > I think these are good choices. The other way leaves a nuisance > situation for the first three bits: check them on reception or no? Another good point. Thanks! 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 Jul 2 14:05:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07392; Wed, 2 Jul 1997 13:52:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07385; Wed, 2 Jul 1997 13:52:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA00795; Wed, 2 Jul 1997 13:54:50 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA27844 for ; Wed, 2 Jul 1997 13:55:37 -0700 Received: from rock.mentat.com ([192.88.122.136]) by mentat.com (4.1/SMI-4.1) id AA22446; Wed, 2 Jul 97 13:47:32 PDT Date: Wed, 2 Jul 97 13:47:32 PDT From: tim@mentat.com (Tim Hartrick) Message-Id: <9707022047.AA22446@mentat.com> To: deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 4068) Re: IPv6 option code spaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1785 Steve, I agree with 2 and disagree with 1. As I have noted I really view options as a necessary evil. Heck they are probably unnecessary evil. That said I believe that if we must have options that we should make them as flexible as possible. My assumption is that only expert users will be interested in using them. I don't believe that we need to protect such users from the flexibility offered by being able to set the ACT bits independently of the OPT bits. I can imagine defining a hop-by-hop option for which tweaking the ACT bits may be important for debugging purposes for example. It may also be important when trying to circumnavigate a broken node in your path. I think it would be a mistake to force us to create the debug and non-debug version of an option and deal with all the IANA junk just because we are afraid that an application writer won't read the description of how options are supposed to work and mess up the encoding of the ACT bits. Leaving the ACT bits distinct from the OPT bits also provides some deployment flexibility when dealing with experimental options. At this point we don't really know what weird and wonderful things people will dream up to put in options. By some miracle some of those things might actually have practical value. We should not limit their options (yes I wrote it) before we have any serious IPv6 deployment experience. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 14:07:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07402; Wed, 2 Jul 1997 13:54:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA07395; Wed, 2 Jul 1997 13:54:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA01222; Wed, 2 Jul 1997 13:56:38 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA28299 for ; Wed, 2 Jul 1997 13:57:36 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA22460; Wed, 2 Jul 97 13:50:23 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA06682; Wed, 2 Jul 1997 13:57:04 -0700 Date: Wed, 2 Jul 1997 13:57:04 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199707022057.NAA06682@feller.mentat.com> To: deering@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 4069) Re: IPv6 option code spaces Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1785 Steve, I agree with 2 and disagree with 1. As I have noted I really view options as a necessary evil. Heck they are probably unnecessary evil. That said I believe that if we must have options that we should make them as flexible as possible. My assumption is that only expert users will be interested in using them. I don't believe that we need to protect such users from the flexibility offered by being able to set the ACT bits independently of the OPT bits. I can imagine defining a hop-by-hop option for which tweaking the ACT bits may be important for debugging purposes for example. It may also be important when trying to circumnavigate a broken node in your path. I think it would be a mistake to force us to create the debug and non-debug version of an option and deal with all the IANA junk just because we are afraid that an application writer won't read the description of how options are supposed to work and mess up the encoding of the ACT bits. Leaving the ACT bits distinct from the OPT bits also provides some deployment flexibility when dealing with experimental options. At this point we don't really know what weird and wonderful things people will dream up to put in options. By some miracle some of those things might actually have practical value. We should not limit their options (yes I wrote it) before we have any serious IPv6 deployment experience. Tim Hartrick -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 2 23:14:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA08330; Wed, 2 Jul 1997 23:01:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id XAA08323; Wed, 2 Jul 1997 23:01:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id XAA05092; Wed, 2 Jul 1997 23:03:17 -0700 Received: from belarus.it.earthlink.net (belarus-c.it.earthlink.net [204.250.46.99]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id XAA11491 for ; Wed, 2 Jul 1997 23:04:21 -0700 Received: from laptop (1Cust84.Max11.Phoenix.AZ.MS.UU.NET [153.35.230.212]) by belarus.it.earthlink.net (8.8.5/8.8.5) with SMTP id XAA18411; Wed, 2 Jul 1997 23:02:47 -0700 (PDT) Message-Id: <3.0.32.19970702210833.0069cb6c@vipmail.earthlink.net> X-Sender: martin-3@vipmail.earthlink.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 02 Jul 1997 23:06:09 -0700 To: tim@mentat.com (Tim Hartrick), deering@cisco.com, ipng@sunroof.eng.sun.com From: Martin Leufray III Subject: (IPng 4070) Re: IPv6 option code spaces Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1413 Steve, I agree with Tim. If it were me, I'd mask the high order bits and switch on the low order. This would make it easier for me to understand what is going on as this develops. I think that keeping the context of the option is more important than speed at this stage of the development. As it matures, this distinction and clarity in code may become less important due to increased understanding and speed may become more important. I would not fault anyone who opts to switch on the entire byte. I also don't look forward to the lower order bytes being reused. This, too, will create confusion at the analysis and design level. One day, as we all understand the maturation of options, we could change to using the entire byte. It will be possible to make this change, whereas a change in the reverse direction is not possible. Martin --- NetConstruct, Inc. | 818 985-2239 The Internet Construction Company (tm) | 4332 Tujunga Avenue http://netconstruct.com | Studio City, CA 91604 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 3 06:58:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA08738; Thu, 3 Jul 1997 06:48:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA08725; Thu, 3 Jul 1997 06:47:40 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA18336; Thu, 3 Jul 1997 06:49:35 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA19328 for ; Thu, 3 Jul 1997 06:50:40 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA20078; Thu, 3 Jul 1997 09:28:46 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA15104; Thu, 3 Jul 1997 09:28:42 -0400 Message-Id: <9707031328.AA15104@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4071) Re: IPv6 option code spaces In-Reply-To: Your message of "Tue, 01 Jul 97 17:59:21 PDT." Date: Thu, 03 Jul 97 09:28:42 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1441 Steve, Wearing my implementor hat. I think that (1) is better. I prefer in my code path switching once on 8bits than masking and switching on ACT bits. This also permits me to define the options without sub-levels OPT bits and ACT bits (though its really one it is virtually 2). I can then use indirection on the low order 5bits. Wearing my architect hat. I think minimizing complexity in IPv6 datagrams is a priority unless there is a very good reason. Your (1) does this IMO. The only reason for (2) I can think of is if we want to have > than 255 options, and if that is so then the OPT field is simply not big enough. I also have no problem for change-en-route if there are informative ACT bits for an OPT type if that is really needed. But I think it must be very clear quickly in the code path what is a DST OPT and what is a HOP-BY-HOP. Wearing my IETF hat. I think saving IANA time and complexity is always a good idea unless there is a clear and big gain for us in the WGs as egg-in-eers. I am not clear (1) causes that much pain? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 3 08:55:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08920; Thu, 3 Jul 1997 08:44:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08913; Thu, 3 Jul 1997 08:43:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA13342; Thu, 3 Jul 1997 08:45:55 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA15672 for ; Thu, 3 Jul 1997 08:46:56 -0700 Received: from ietf.ietf.org by ietf.org id aa08312; 3 Jul 97 10:37 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 4072) I-D ACTION:draft-ietf-ipngwg-ipv6-over-ppp-02.txt Date: Thu, 03 Jul 1997 10:37:37 -0400 Message-ID: <9707031037.aa08312@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4120 --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 : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-02.txt Pages : 14 Date : 07/02/1997 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. 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-over-ppp-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-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-over-ppp-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: <19970702145028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-over-ppp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-over-ppp-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970702145028.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 Jul 8 07:22:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15075; Tue, 8 Jul 1997 07:14:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA15068; Tue, 8 Jul 1997 07:13:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA29922; Tue, 8 Jul 1997 07:15:56 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA05871 for ; Tue, 8 Jul 1997 07:16:58 -0700 Received: from ietf.ietf.org by ietf.org id aa06737; 8 Jul 97 9:52 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 4073) I-D ACTION:draft-ietf-ipngwg-trans-ethernet-01.txt Date: Tue, 08 Jul 1997 09:52:29 -0400 Message-ID: <9707080952.aa06737@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3912 --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 : Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-ethernet-01.txt Pages : 6 Date : 07/07/1997 Transmission of IPv6 Packets over Ethernet Networks packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. 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-ethernet-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-ethernet-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-trans-ethernet-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: <19970707095209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-ethernet-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970707095209.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 Jul 9 08:11:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16949; Wed, 9 Jul 1997 08:02:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16942; Wed, 9 Jul 1997 08:02:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA06710; Wed, 9 Jul 1997 08:04:36 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA22380 for ; Wed, 9 Jul 1997 08:05:42 -0700 Received: from ietf.ietf.org by ietf.org id aa08005; 9 Jul 97 10:41 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 4074) I-D ACTION:draft-ietf-ipngwg-trans-fddi-net-01.txt Date: Wed, 09 Jul 1997 10:41:05 -0400 Message-ID: <9707091041.aa08005@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4283 --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 : Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-fddi-net-01.txt Pages : 8 Date : 07/07/1997 This memo specifies the MTU and frame format for transmission of IPv6 packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an FDDI network. This document replaces RFC 2019, "Transmission of IPv6 Packets Over FDDI", which 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 [KWORD]. 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-fddi-net-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-fddi-net-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-trans-fddi-net-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: <19970707105207.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-fddi-net-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970707105207.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 Jul 9 16:42:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA17756; Wed, 9 Jul 1997 16:33:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA17749; Wed, 9 Jul 1997 16:33:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA00269; Wed, 9 Jul 1997 16:35:53 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA25791 for ; Wed, 9 Jul 1997 16:37:00 -0700 Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <3S417WDM>; Wed, 9 Jul 1997 16:36:31 -0700 Message-ID: From: Richard Draves To: "'IPng List'" Subject: (IPng 4075) UDP pseudo-header Date: Wed, 9 Jul 1997 16:35:49 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1748 There's a small ambiguity in RFC 1883's description of the IPv6 pseudo-header, and in particular the Payload Length field. (See section 8.1.) The UDP header has its own Payload Length field. The UDP payload length may be smaller than the IPv6 payload length, presumably meaning that there is extra "junk" data in the IPv6 packet that is not part of the UDP payload. When this happens, which payload length should be used in the pseudo-header for checksumming the UDP packet? I think it would be preferable to use the UDP payload length in the pseudo-header - it seems simpler to only have one length involved in the checksum calculation. Otherwise there would be one value in the pseudo-header and another value controlling how much packet data is checksummed. Section 8.1 says "The Payload Length used in the pseudo-header is the length of the upper-layer packet, including the upper-layer header." For UDP, this would seem to indicate that UDP's payload length should be used. Then it says "It will be less than the Payload Length in the IPv6 header (or in the Jumbo Payload option) if there are extension headers between the IPv6 header and the upper-layer header." This would seem to indicate that UDP's payload length should NOT be used... Or perhaps for UDPv6, it should just clarify that the packet is dropped if the two payload lengths do not agree? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 9 17:03:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA17780; Wed, 9 Jul 1997 16:53:51 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA17773; Wed, 9 Jul 1997 16:53:42 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA03949; Wed, 9 Jul 1997 16:55:47 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA00612 for ; Wed, 9 Jul 1997 16:56:55 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49) id <3S4AY3WA>; Wed, 9 Jul 1997 16:58:30 -0700 Message-ID: From: Richard Draves To: "'IPng List'" Subject: (IPng 4076) ND question Date: Wed, 9 Jul 1997 16:55:32 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 966 I have a question about the processing of Neighbor Solicitations, and in particular, Neighbor Solicitations that do NOT include a Source Link-Layer Address option (this is allowed in some circumstances, although it's discouraged). What happens if the Neighbor Cache does not contain a valid entry for sending the Advertisement? Should the Solicitation be ignored, or should ND be used to attempt to send the Advertisement? Using ND to send an Advertisement would seem wrong. Perhaps the spec should just require that all Solicitations contain a Source Link-Layer Address option. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 10 04:24:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA18570; Thu, 10 Jul 1997 04:16:32 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA18563; Thu, 10 Jul 1997 04:16:24 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA09253; Thu, 10 Jul 1997 04:18:30 -0700 Received: from wachusett.altavista-software.com (wachusett.altavista-software.com [205.181.164.11]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA24901 for ; Thu, 10 Jul 1997 04:19:38 -0700 Received: by wachusett.altavista-software.com; (5.65v3.2/1.3/10May95) id AB29434; Thu, 10 Jul 1997 07:18:26 -0400 Message-Id: <3.0.2.32.19970710071746.0091fb5c@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 10 Jul 1997 07:17:46 -0400 To: Richard Draves Received: from 1Cust83.Max4.Boston.MA.MS.UU.NET by wachusett.altavista-software.com (smtpxd); id XA27872 From: Matt Thomas Subject: (IPng 4077) Re: UDP pseudo-header Cc: "'IPng List'" 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: 1265 At 04:35 PM 7/9/97 -0700, Richard Draves wrote: >There's a small ambiguity in RFC 1883's description of the IPv6 >pseudo-header, and in particular the Payload Length field. (See section >8.1.) > >The UDP header has its own Payload Length field. The UDP payload length >may be smaller than the IPv6 payload length, presumably meaning that >there is extra "junk" data in the IPv6 packet that is not part of the >UDP payload. Because of jumbograms, you have use the payload header from the IPv6 header or the Hop-by-Hop header. The UDP header's length is "merely" additional data to the checksum operation. -- 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 Thu Jul 10 07:22:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA18720; Thu, 10 Jul 1997 07:14:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA18713; Thu, 10 Jul 1997 07:14:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA04652; Thu, 10 Jul 1997 07:16:15 -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 HAA29819 for ; Thu, 10 Jul 1997 07:17:21 -0700 Received: from gungnir.fnal.gov ("port 37673"@gungnir.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-8 #3998) id <01IL2EL2W55I000NXX@FNAL.FNAL.GOV>; Thu, 10 Jul 1997 09:16:12 -0600 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA07103; Thu, 10 Jul 1997 09:16:12 -0500 Date: Thu, 10 Jul 1997 09:16:11 -0500 From: Matt Crawford Subject: (IPng 4078) Re: UDP pseudo-header In-reply-to: "09 Jul 1997 16:35:49 PDT." <"E13B15DD7E88CF11873A00805FD436AA02C12D12"@RED-23-MSG.dns.microsoft.com> To: Richard Draves Cc: "'IPng List'" Message-id: <199707101416.JAA07103@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{ Section 8.1 says "The Payload Length used in the pseudo-header is the > length of the upper-layer packet, including the upper-layer header." For > UDP, this would seem to indicate that UDP's payload length should be > used. Then it says "It will be less than the Payload Length in the IPv6 > header (or in the Jumbo Payload option) if there are extension headers > between the IPv6 header and the upper-layer header." This would seem to > indicate that UDP's payload length should NOT be used... I can't see a situation in which the length field from the UDP header is not the right number to use. It never includes stuff that came before the UDP header. Are you picturing a case in which the IPv6 Payload Length is greater than the total of the extension headers plus the UDP header and data, and thus indicates some mystery bytes beyond the UDP data? That would be an interesting error, and I hope a few such packets are sent to all implementations at the bake-offs. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 10 08:24:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18870; Thu, 10 Jul 1997 08:16:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18863; Thu, 10 Jul 1997 08:16:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA19137; Thu, 10 Jul 1997 08:18:26 -0700 Received: from frantic.BSDI.COM (frantic.BSDI.COM [205.230.227.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA16913 for ; Thu, 10 Jul 1997 08:19:31 -0700 Received: (from dab@localhost) by frantic.BSDI.COM (8.8.5/8.8.5) id KAA02798; Thu, 10 Jul 1997 10:18:20 -0500 (CDT) Date: Thu, 10 Jul 1997 10:18:20 -0500 (CDT) From: David Borman Message-Id: <199707101518.KAA02798@frantic.BSDI.COM> To: ipng@sunroof.eng.sun.com, richdr@microsoft.com Subject: (IPng 4079) Re: UDP pseudo-header Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1985 > From owner-ipng@sunroof.Eng.Sun.COM Wed Jul 9 22:28:09 1997 > From: Richard Draves > To: "'IPng List'" > Subject: (IPng 4075) UDP pseudo-header > Date: Wed, 9 Jul 1997 16:35:49 -0700 > X-Priority: 3 > X-Mailer: Internet Mail Service (5.0.1458.49) > Precedence: bulk > > There's a small ambiguity in RFC 1883's description of the IPv6 > pseudo-header, and in particular the Payload Length field. (See section > 8.1.) > > The UDP header has its own Payload Length field. The UDP payload length > may be smaller than the IPv6 payload length, presumably meaning that > there is extra "junk" data in the IPv6 packet that is not part of the > UDP payload. > > When this happens, which payload length should be used in the > pseudo-header for checksumming the UDP packet? The length in the pseudo-header is the length of the UDP header and data (see RFC 768). Thus, if the computed length from the IPv6 headers differs with the non-zero length in the UDP header, the length from the UDP header is copied into the pseudo-header, the trailing data is discarded, and then the checksum is verified. Of course, if the computed length is less than the UDP header length, the packet is dropped. If the UDP header length is zero, then it is ignored and the computed length is used in the pseudo-header (see RFC2147). (The UDP header length should only be zero when the UDP length is greater than 65535.) -David Borman, dab@bsdi.com P.S: BSD based UDP/IPv4 implementations do exactly this (except for the zero UDP length checks, which is IPv6 specific). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 10 10:56:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA19253; Thu, 10 Jul 1997 10:46:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA19246; Thu, 10 Jul 1997 10:46:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA24921; Thu, 10 Jul 1997 10:48:21 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA05964 for ; Thu, 10 Jul 1997 10:49:28 -0700 Received: from ftp.com by ftp.com ; Thu, 10 Jul 1997 13:48:19 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Thu, 10 Jul 1997 13:48:19 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id NAA23393; Thu, 10 Jul 1997 13:44:17 -0400 Message-Id: <199707101744.NAA23393@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: richdr@microsoft.com, ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 4080) RE: ND question Date: Thu, 10 Jul 1997 13:48:17 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 827 >>Reply to your message of 7/9/97 11:32 PM > >What happens if the Neighbor Cache does not contain a valid entry for >[the node] sending the Advertisement? The Solicitation, you mean? The neighbor cache entry goes into STALE state if there's no link address option. If the node never sends back to the neighbor that sent the solicitation, nothing more happens. Otherwise the entry progresses into DELAY, PROBE and REACHABLE states -- Frank -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 11 10:57:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA21237; Fri, 11 Jul 1997 10:48:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA21230; Fri, 11 Jul 1997 10:48:38 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA10634; Fri, 11 Jul 1997 10:50:45 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA16625 for ; Fri, 11 Jul 1997 10:50:46 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49) id <3W9VF6GY>; Fri, 11 Jul 1997 10:52:59 -0700 Message-ID: From: Richard Draves To: "'Matt Crawford'" , "'David Borman'" , "'Matt Thomas'" Cc: "'IPng List'" Subject: (IPng 4081) Re: UDP pseudo-header Date: Fri, 11 Jul 1997 10:47:07 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2258 Matt Crawford said >I can't see a situation in which the length field from the UDP header >is not the right number to use. It never includes stuff that came >before the UDP header. Are you picturing a case in which the IPv6 >Payload Length is greater than the total of the extension headers >plus the UDP header and data, and thus indicates some mystery bytes >beyond the UDP data? That would be an interesting error, and I hope >a few such packets are sent to all implementations at the bake-offs. Yes, I am picturing a case with "normal" packets, not jumbograms, in which the IPv6 payload length and the UDP payload length are inconsistent, indicating junk bytes beyond the UDP data. David Borman said >The length in the pseudo-header is the length of the UDP header and >data (see RFC 768). Thus, if the computed length from the IPv6 headers >differs with the non-zero length in the UDP header, the length from the >UDP header is copied into the pseudo-header, the trailing data is >discarded, and then the checksum is verified. Of course, if the computed >length is less than the UDP header length, the packet is dropped. If the >UDP header length is zero, then it is ignored and the computed length is >used in the pseudo-header (see RFC2147). (The UDP header length should >only be zero when the UDP length is greater than 65535.) So this was my conclusion: if there is an inconsistency, use the UDP length in the IPv6 pseudo-header. Matt Thomas said >Because of jumbograms, you have use the payload header from the IPv6 >header or the Hop-by-Hop header. The UDP header's length is "merely" >additional data to the checksum operation. Matt Thomas seems to disagree... I interpret him as saying the length from the UDP header should effectively be ignored. This would be inconsistent with IPv4 practice, but it would simplify UDP/IPv6 receive processing. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 11:17:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21255; Fri, 11 Jul 1997 11:09:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21248; Fri, 11 Jul 1997 11:08:59 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA16250; Fri, 11 Jul 1997 11:11:05 -0700 Received: from frantic.BSDI.COM (frantic.BSDI.COM [205.230.227.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA04722 for ; Fri, 11 Jul 1997 11:12:10 -0700 Received: (from dab@localhost) by frantic.BSDI.COM (8.8.5/8.8.5) id NAA04835; Fri, 11 Jul 1997 13:10:38 -0500 (CDT) Date: Fri, 11 Jul 1997 13:10:38 -0500 (CDT) From: David Borman Message-Id: <199707111810.NAA04835@frantic.BSDI.COM> To: crawdad@FNAL.GOV, dab@BSDI.COM, matt.thomas@altavista-software.com, richdr@microsoft.com Subject: (IPng 4082) Re: UDP pseudo-header Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1285 > So this was my conclusion: if there is an inconsistency, use the UDP > length in the IPv6 pseudo-header. > > Matt Thomas said > >Because of jumbograms, you have use the payload header from the IPv6 > >header or the Hop-by-Hop header. The UDP header's length is "merely" > >additional data to the checksum operation. > > Matt Thomas seems to disagree... I interpret him as saying the length > from the UDP header should effectively be ignored. This would be > inconsistent with IPv4 practice, but it would simplify UDP/IPv6 receive > processing. > > Rich RFC 2147 specifies how to use UDP with jumbograms; iff the UDP length is in excess of 65535, the UDP length is set to zero and the computed length is used in the pseudo-header and as the length of the UDP packet. For packets less 65536 bytes in length, the UDP length is the length to use in the pseudo-header. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 11:54:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21346; Fri, 11 Jul 1997 11:45:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21339; Fri, 11 Jul 1997 11:45:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA26145; Fri, 11 Jul 1997 11:47:22 -0700 Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA16878 for ; Fri, 11 Jul 1997 11:48:30 -0700 Received: from rast.cisco.com (rast.cisco.com [171.69.113.55]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id LAA24279; Fri, 11 Jul 1997 11:47:21 -0700 (PDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by rast.cisco.com (8.8.5/8.8.5) with SMTP id LAA01959; Fri, 11 Jul 1997 11:47:19 -0700 (PDT) Message-Id: <199707111847.LAA01959@rast.cisco.com> To: Richard Draves cc: "'Matt Crawford'" , "'David Borman'" , "'Matt Thomas'" , "'IPng List'" Subject: (IPng 4083) Re: UDP pseudo-header In-reply-to: Your message of "Fri, 11 Jul 1997 10:47:07 PDT." Date: Fri, 11 Jul 1997 11:47:11 -0700 From: Richard Johnson Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1321 > >I can't see a situation in which the length field from the UDP header > >is not the right number to use. It never includes stuff that came > >before the UDP header. Are you picturing a case in which the IPv6 > >Payload Length is greater than the total of the extension headers > >plus the UDP header and data, and thus indicates some mystery bytes > >beyond the UDP data? That would be an interesting error, and I hope > >a few such packets are sent to all implementations at the bake-offs. > > Yes, I am picturing a case with "normal" packets, not jumbograms, in > which the IPv6 payload length and the UDP payload length are > inconsistent, indicating junk bytes beyond the UDP data. Wasn't this done in BSD as a speedup kludge? The kernel was able to use buffers which were larger than the UDP packet, fill in only the part needed, and then send the entire buffer out. So you got trailing garbage on UDP packets sometimes. /raj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 13:31:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21534; Fri, 11 Jul 1997 13:22:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21527; Fri, 11 Jul 1997 13:21:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA19532; Fri, 11 Jul 1997 13:24:04 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA15189 for ; Fri, 11 Jul 1997 13:25:15 -0700 Received: by mail5.microsoft.com with Internet Mail Service (5.0.1458.49) id <3W9L4KX8>; Fri, 11 Jul 1997 13:25:43 -0700 Message-ID: From: Richard Draves To: "'Frank T Solensky'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4084) RE: ND question Date: Fri, 11 Jul 1997 13:24:00 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1462 Let me rephrase. Node A sends a Solicitation to node B. The Solicitation does not contain a Source Link-Layer Address Option. The Solicitation source address SSA is an address for node A and not the unspecified address. Section 7.2.4 of RFC 1970 says that node B MUST unicast an Advertisement to SSA, the source address of the Solicitation. My question is, what should node B do if its neighbor cache does not have an entry mapping address SSA to a link-layer address. Some possibilities: 1) node B should just ignore the Solicitation. (Although this would violate the RFC.) 2) node B should send the Advertisement with IPv6 destination address SSA but use a multicast link-level address. The link-level address is calculated from the solicited-node multicast address that is calculated from address SSA. (Seems cute, but the RFC says the Advertisement should be unicast.) 3) node B should initiate Neighbor Discovery to get a link-layer address corresponding to address SSA, then send the Advertisement. (Might conform to the RFC, but doesn't seem right to me.) Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 11 14:11:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21618; Fri, 11 Jul 1997 14:02:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA21611; Fri, 11 Jul 1997 14:02:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA00136; Fri, 11 Jul 1997 14:04:29 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA27632 for ; Fri, 11 Jul 1997 14:05:37 -0700 Received: from ftp.com by ftp.com ; Fri, 11 Jul 1997 17:04:24 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Fri, 11 Jul 1997 17:04:24 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id RAA01363; Fri, 11 Jul 1997 17:00:23 -0400 Message-Id: <199707112100.RAA01363@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 4085) Re: ND question Date: Fri, 11 Jul 1997 17:04:23 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 859 >>Reply to your message of 7/11/97 4:39 PM > >3) node B should initiate Neighbor Discovery to get a link-layer address >corresponding to address SSA, then send the Advertisement. (Might >conform to the RFC, but doesn't seem right to me.) That's the one. Node B is, in this case, about to send a packet to node A. The fact that the packet getting queued for node B is a unicast NA message instead of, say, a TCP SYN packet, is just a byproduct of the algorithm. -- Frank -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 13 11:21:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA23206; Sun, 13 Jul 1997 11:13:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA23199; Sun, 13 Jul 1997 11:13:30 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA25803; Sun, 13 Jul 1997 11:15:37 -0700 Received: from wrnet.it (main.wrnet.it [195.32.70.2]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA23754 for ; Sun, 13 Jul 1997 11:15:37 -0700 Received: from lizard (Bozzolo4.wrnet.it [195.32.70.69]) by wrnet.it (8.6.12/8.6.9) with SMTP id UAA25422 for ; Sun, 13 Jul 1997 20:17:21 +0100 Date: Sun, 13 Jul 1997 20:17:21 +0100 Message-Id: <199707131917.UAA25422@wrnet.it> X-Sender: grossi@mail.wrnet.it X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: "Dr. Ing. Giuseppe F. Rossi" Subject: (IPng 4086) Little Question about Anycast Addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1276 I have a little doubt about the meaning of "Anycast Address" in IPv6. In RFC1884 is stated that a packet sent to an anycast address is delivered to the nearest interface of the group, according to the router's measure of distance. But, what does it happen when there are two or more interfaces of the group having the same (minimum) "distance" from the source ? Is the packet sent to all these interfaces ? If so, It would be better to say that a packet sent to an anycast address is delivered to ALL the interfaces of the group having the SAME MINIMUM "distance" from the source. Thank you very much for your attention. Best Regards Beppe ================================= Dr. Ing. Giuseppe F. Rossi viale G. Marconi, 4 I-46010 Gazzuolo (Mantova) - Italy tel/fax: +39 - (0) 376 - 97250 E-mail: grossi@mail.wrnet.it (preferred) E-mail: grossi@mbox.mynet.it ================================= -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 13 16:18:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA23400; Sun, 13 Jul 1997 16:10:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA23393; Sun, 13 Jul 1997 16:10:51 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA10298; Sun, 13 Jul 1997 16:12:58 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA01303 for ; Sun, 13 Jul 1997 16:12:59 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id QAA04737; Sun, 13 Jul 1997 16:12:49 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199707131917.UAA25422@wrnet.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 13 Jul 1997 16:12:52 -0700 To: "Dr. Ing. Giuseppe F. Rossi" From: Steve Deering Subject: (IPng 4087) Re: Little Question about Anycast Addresses Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1110 At 12:17 PM -0700 7/13/97, Dr. Ing. Giuseppe F. Rossi wrote: > In RFC1884 is stated that a packet sent to an anycast address is delivered > to the nearest interface of the group, according to the router's measure > of distance. > But, what does it happen when there are two or more interfaces of the group > having the same (minimum) "distance" from the source ? In that case, it is still delivered to only one interface. The choice of interface is based on whatever "tie-breaking" algorithm is employed by the routing protocol(s) in use. In the case of multiple members of the same anycast group attached to the same multi-access link (e.g., Ethernet), the Neighbor Discovery protocol will pick one of the candidates. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jul 13 18:46:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA23571; Sun, 13 Jul 1997 18:38:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA23564; Sun, 13 Jul 1997 18:38:09 -0700 From: bound@zk3.dec.com Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA17492; Sun, 13 Jul 1997 18:40:17 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA22185 for ; Sun, 13 Jul 1997 18:40:19 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id VAA28546; Sun, 13 Jul 1997 21:33:20 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA19144; Sun, 13 Jul 1997 21:33:12 -0400 Message-Id: <9707140133.AA19144@wasted.zk3.dec.com> To: David Borman Cc: crawdad@fnal.gov, matt.thomas@altavista-software.com, richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: (IPng 4088) Re: UDP pseudo-header In-Reply-To: Your message of "Fri, 11 Jul 97 13:10:38 CDT." <199707111810.NAA04835@frantic.BSDI.COM> Date: Sun, 13 Jul 97 21:33:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 903 >RFC 2147 specifies how to use UDP with jumbograms; iff the UDP >length is in excess of 65535, the UDP length is set to zero and >the computed length is used in the pseudo-header and as the >length of the UDP packet. For packets less 65536 bytes in length, >the UDP length is the length to use in the pseudo-header. What counts for less-than 65K is what RFC 1883 says and its predecessor not RFC 2147. I suggest we nail this down cause it seems screwed up. I for one think Matt Thomas has the correct vision here. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 06:51:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23869; Mon, 14 Jul 1997 06:42:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23862; Mon, 14 Jul 1997 06:42:46 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA03714; Mon, 14 Jul 1997 06:44:54 -0700 Received: from mail.intercenter.net (mir.intercenter.net [207.211.128.20]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA01401 for ; Mon, 14 Jul 1997 06:44:56 -0700 Received: (qmail 3931 invoked from network); 14 Jul 1997 13:44:50 -0000 Received: from ct2-02.intercenter.net (HELO LOCALNAME) (207.211.129.67) by mir.intercenter.net with SMTP; 14 Jul 1997 13:44:50 -0000 Message-ID: <33CA56D4.1251@phase2net.com> Date: Mon, 14 Jul 1997 09:41:56 -0700 From: Charles Mumford Reply-To: cmumford@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: Frank T Solensky CC: richdr@microsoft.com, ipng@sunroof.eng.sun.com Subject: (IPng 4089) Re: ND question References: <199707112100.RAA01363@MAILSERV-2HIGH.FTP.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1315 > > 3) node B should initiate Neighbor Discovery to get a link-layer > > address corresponding to address SSA, then send the Advertisement. > > (Might conform to the RFC, but doesn't seem right to me.) > That's the one. Node B is, in this case, about to send a packet > to node A. The fact that the packet getting queued for node B > is a unicast NA message instead of, say, a TCP SYN packet, > is just a byproduct of the algorithm. > -- Frank Ok, but (refresh my memory here) is there something in the RFC that says nodes MUST NOT send solicitations without a source link layer address option when performing ND to respond to such a solicitation? If not then the potential for protocol looping exists. Or would a solictiation get ignored if a nbr cache entry was left in the incomplete state? I did IPv6 ND a while ago and am wondering if I need to update my code. Thanks Charles -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 07:37:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA23909; Mon, 14 Jul 1997 07:28:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA23902; Mon, 14 Jul 1997 07:28:44 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA10461; Mon, 14 Jul 1997 07:30:54 -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 HAA13988 for ; Mon, 14 Jul 1997 07:30:53 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 14 Jul 1997 10:31:52 -0400 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Cc: "'Frank T Solensky'" Subject: (IPng 4090) RE: ND question Date: Mon, 14 Jul 1997 10:31:49 -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: 1534 Hi Rich, > Let me rephrase. Node A sends a Solicitation to node B. The Solicitation > does not contain a Source Link-Layer Address Option. The Solicitation > source address SSA is an address for node A and not the unspecified > address. Let's consider the possibilities regarding A sending that solicitation to B. Either A has no a priori knowledge of B's address mapping, in which case it will be sending the Neighbor Solicitation (NS) to the solicited nodes multicast address -- if so, it MUST include the Source Link-Layer option, and B will be able return the Neighbor Advertisement (NA) directly. In the other situation, A does have a mapping for B's address. In this case it can send a unicast NS packet directly to B, and the Neighbor Discovery document states that it SHOULD include the Source Link-Layer option (Section 7.2.2). The definition of SHOULD means do it, unless you have a darned good reason not to. That's because you can't really make assumptions about the state of the other system's cache... Is there a more specific environment or case you had in mind, which might lead system A to omit the Source Link-Layer option? Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 09:29:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA23993; Mon, 14 Jul 1997 09:21:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA23986; Mon, 14 Jul 1997 09:20:57 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA10347; Mon, 14 Jul 1997 09:22:44 -0700 Received: from frantic.BSDI.COM (frantic.BSDI.COM [205.230.227.254]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA23605 for ; Mon, 14 Jul 1997 09:21:34 -0700 Received: (from dab@localhost) by frantic.BSDI.COM (8.8.5/8.8.5) id LAA09776; Mon, 14 Jul 1997 11:20:41 -0500 (CDT) Date: Mon, 14 Jul 1997 11:20:41 -0500 (CDT) From: David Borman Message-Id: <199707141620.LAA09776@frantic.BSDI.COM> To: bound@zk3.dec.com, dab@bsdi.com Subject: (IPng 4091) Re: UDP pseudo-header Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, matt.thomas@altavista-software.com, richdr@microsoft.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3774 > >RFC 2147 specifies how to use UDP with jumbograms; iff the UDP > >length is in excess of 65535, the UDP length is set to zero and > >the computed length is used in the pseudo-header and as the > >length of the UDP packet. For packets less 65536 bytes in length, > >the UDP length is the length to use in the pseudo-header. > > What counts for less-than 65K is what RFC 1883 says and its predecessor > not RFC 2147. Yes, that is what I said. RFC 2147 applies if and only if the UDP length equals or exceeds 64K. > I suggest we nail this down cause it seems screwed up. > I for one think Matt Thomas has the correct vision here. > > /jim No, Matt said: Because of jumbograms, you have use the payload header from the IPv6 header or the Hop-by-Hop header. The UDP header's length is "merely" additional data to the checksum operation. and this is incorrect. It implies that because of jumbograms, you have to ignore the UDP length. RFC 2147 was written to address jumbograms, so they are not at issue. Taking this statement to its logical conclusion, it says that if the computed length exceedes the explicit length in the UDP header, that you ignore the explicit UDP length, even though it is "closer" to the data and most likely the correct value. I just don't buy that, and I think you'll have a very tough time finding anyone who was around when RFC 793 was written to back up that viewpoint. The only issue is that if the computed length does not match the UDP length, do you drop the packet? If the computed length is less than the UDP length, then yes, you have to drop it because you don't have all the data. If the computed length exceeds the UDP length, do you trim the excess data, or drop the packet? Being liberal in what you accept would say you trim the IP packet to fit the UDP length. Then, what length do you put into the pseudo-header? RFC 793 says: The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. "UDP length" sounds to me a lot like "the length in the UDP header", not "the computed length from the IP header" (as opposed to the TCP specificiation, which explicitly states that the TCP length is a computed value, since it is not a transmitted value). But the real issue is that the computed length should always equal the length in the UDP header, I can't think of any valid reason for generating an IP/UDP (v4 or v6) packet in which the two lengths don't match. So, we're arguing a strictly academic issue. And for that case, the UDP length is used in the pseudo-header, not the computed length. If the computed length exceeds the UDP length, you trim the IP packet to fit the UDP length. If the computed length is less than the UDP length, you drop the packet because you don't have enough data. Now, I have no problems with saying that you drop any UDP packet in which the computed length does not equal the UDP length. But that is not currently in any spec. There is also nothing in any spec about ignoring the UDP length, except for RFC 2147 which allows it to be ignored for jumbograms. Also, any changes to how the UDP length and the computed length interact should apply to both IPv4/UDP and IPv6/UDP. If you can't apply it to UDP/IPv4, then you shouldn't apply it to IPv6/UDP. -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 09:49:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24043; Mon, 14 Jul 1997 09:39:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24036; Mon, 14 Jul 1997 09:39:37 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA19545; Mon, 14 Jul 1997 09:41:14 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA01223 for ; Mon, 14 Jul 1997 09:40:45 -0700 Received: by mail4.microsoft.com with Internet Mail Service (5.0.1458.49) id <3ZWMMQKX>; Mon, 14 Jul 1997 09:37:32 -0700 Message-ID: From: Richard Draves To: "'IPng List'" Cc: "'Frank T Solensky'" , "'Harrington, Dan'" , "'Charles Mumford'" Subject: (IPng 4092) ND question Date: Mon, 14 Jul 1997 09:36:27 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1821 >>3) node B should initiate Neighbor Discovery to get a link-layer address >>corresponding to address SSA, then send the Advertisement. (Might >>conform to the RFC, but doesn't seem right to me.) > >That's the one. Node B is, in this case, about to send a packet >to node A. The fact that the packet getting queued for node B >is a unicast NA message instead of, say, a TCP SYN packet, >is just a byproduct of the algorithm. I've figured out why my intuition rebels against this answer, and I think it's the spectre of protocol looping that Charles Mumford mentioned. The last thing you want is for some combination of strange/buggy implementations to get into a "solicit storm" where each node responds to the other with another Solicitation. I think this possibility is best ruled out up front, by forbidding implementations from responding to a Solicitation with another Solicitation. This would be similar to the prohibition against sending an ICMPv6 error message as a result of receiving an ICMPv6 error message. To answer Dan Harrington's question, I don't know why a node would omit the Source Link-Layer Address Option from a Solicitation. It saves bandwidth in some cases, but it makes the protocol more complex in a bad way. However the spec says SHOULD instead of MUST, so it's left open as a possibility and hence the spec should be clear about the requirements on an implementation that receives such a Solicitation. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 10:17:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA24085; Mon, 14 Jul 1997 10:04:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA24078; Mon, 14 Jul 1997 10:03:45 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA00143; Mon, 14 Jul 1997 10:05:27 -0700 Received: from frantic.BSDI.COM (frantic.BSDI.COM [205.230.227.254]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA11406 for ; Mon, 14 Jul 1997 10:05:18 -0700 Received: (from dab@localhost) by frantic.BSDI.COM (8.8.5/8.8.5) id MAA09839; Mon, 14 Jul 1997 12:03:27 -0500 (CDT) Date: Mon, 14 Jul 1997 12:03:27 -0500 (CDT) From: David Borman Message-Id: <199707141703.MAA09839@frantic.BSDI.COM> To: bound@zk3.dec.com, dab@BSDI.COM Subject: (IPng 4093) Re: UDP pseudo-header Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, matt.thomas@altavista-software.com, richdr@microsoft.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 587 In my previous message I meant to say "RFC 768", not "RFC 793". 793 is the TCP specification, 768 is UDP. (Thanks to Matt Thomas who pointed out my error in a private email.) -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 10:30:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA24109; Mon, 14 Jul 1997 10:18:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA24102; Mon, 14 Jul 1997 10:18:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA05436; Mon, 14 Jul 1997 10:19:35 -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 KAA22466 for ; Mon, 14 Jul 1997 10:19:54 -0700 Received: from rtpmail01.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA34722; Mon, 14 Jul 1997 13:18:34 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA31358; Mon, 14 Jul 1997 13:18:35 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA21010; Mon, 14 Jul 1997 13:18:36 -0400 Message-Id: <9707141718.AA21010@cichlid.raleigh.ibm.com> To: Richard Draves Cc: "'IPng List'" Subject: (IPng 4094) Re: ND question In-Reply-To: Your message of "Mon, 14 Jul 1997 09:36:27 PDT." Date: Mon, 14 Jul 1997 13:18:36 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1748 > To answer Dan Harrington's question, I don't know why a node would omit > the Source Link-Layer Address Option from a Solicitation. It saves > bandwidth in some cases, but it makes the protocol more complex in a bad > way. However the spec says SHOULD instead of MUST, so it's left open as > a possibility and hence the spec should be clear about the requirements > on an implementation that receives such a Solicitation. My recollection on this was that Erik & I discussed the MUST vs. SHOULD in this case and left it a SHOULD simply because MUST is absolute and would rule out some possible future scenario where this was useful (e.g., some new type of link-layer with "interesting" properties). We did not have a specific scenario in mind that would use this, but didn't see the harm in leaving the door open a crack. It also seems pretty hard to imagine an implementation that would ship with such brokeness (i.e., one that leads to looping). One of the first implementations that a new implementation would be tested against is itself (one hopes!), and the results would be pretty dramatic! Hence, I don't see a big danger that needs to be plugged. Would it help to add some additional "danger danger" text to Section 4.3 to make it clear why the SHOULD is a SHOULD? (I am also not averse to changing the SHOULD to a MUST if that is what folks want.) 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 Mon Jul 14 11:27:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24220; Mon, 14 Jul 1997 11:18:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24213; Mon, 14 Jul 1997 11:18:46 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA27122; Mon, 14 Jul 1997 11:20: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 LAA13348 for ; Mon, 14 Jul 1997 11:21:56 -0700 Received: from dogbert.alteon.com by relay2.UU.NET with SMTP (peer crosschecked as: alteon.com [208.200.21.146]) id QQcyer04048; Mon, 14 Jul 1997 14:17:40 -0400 (EDT) Received: from admin.alteon.com ([205.178.13.225]) by dogbert.alteon.com via smtpd (for relay2.UU.NET [192.48.96.7]) with SMTP; 14 Jul 1997 18:17:10 UT Received: from coastsider.acteon.com by admin.alteon.com (5.x/SMI-SVR4) id AA26942; Mon, 14 Jul 1997 10:42:40 -0700 Received: by coastsider.acteon.com (5.x/SMI-SVR4) id AA10146; Mon, 14 Jul 1997 10:42:39 -0700 Date: Mon, 14 Jul 1997 10:42:39 -0700 From: wayne@alteon.com (Wayne Hathaway) Message-Id: <9707141742.AA10146@coastsider.acteon.com> To: bound@zk3.dec.com, dab@BSDI.COM, dab@bsdi.com Subject: (IPng 4095) Re: UDP pseudo-header Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, matt.thomas@altavista-software.com, richdr@microsoft.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1238 > But the real issue is that the computed length should always > equal the length in the UDP header, I can't think of any valid > reason for generating an IP/UDP (v4 or v6) packet in which the > two lengths don't match. So, we're arguing a strictly academic > issue. In my previous existence at Auspex Systems, I saw *PLENTY* of NFS requests in which the IP length was larger than the UDP length. Whether it was for valid reasons or not I don't know, but we wouldn't have sold many file servers if we didn't handle them. So it's a little more than academic... I do agree that the current spec is correct for non-jumbograms, by the way: use the UDP length field. Wayne Hathaway Internet: wayne@alteon.com Alteon Networks Phone: 408-360-5503 6351 San Ignacio Avenue FAX: 408-360-5501 San Jose, CA 95119 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 11:39:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24267; Mon, 14 Jul 1997 11:28:32 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24260; Mon, 14 Jul 1997 11:28:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA00626; Mon, 14 Jul 1997 11:30:18 -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 LAA16745 for ; Mon, 14 Jul 1997 11:31:20 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA05913 for ; Mon, 14 Jul 1997 14:03:27 -0400 (EDT) Received: by wasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11136; Mon, 14 Jul 1997 14:03:14 -0400 Date: Mon, 14 Jul 1997 14:03:14 -0400 From: Jack McCann Message-Id: <9707141803.AA11136@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4096) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: mccann@zk3.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2215 >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 Two comments. 1. The examples on pages 38, 41, and 42 use inet6_option_space(), which returns an int, to initialize msg.msg_control, a pointer. Looks like a call to malloc() is needed? e.g. msg.msg_control = malloc(inet6_option_space(xxx)); 2. If I'm reading my bits right, with the current definitions of the nd_na_flags_reserved field and the ND_NA_FLAG_xxx masks, before &'ing the two, either: a) nd_na_flags_reserved must be converted to host byte order, e.g. ntohl(nd_na->nd_na_flags_reserved) & ND_NA_FLAG_ROUTER or b) ND_NA_FLAG_xxx must be converted to network byte order, e.g. nd_na->nd_na_flags_reserved & htonl(ND_NA_FLAG_ROUTER) Perhaps a small clarification on this (maybe just an example code fragment) would save some debug time down the road. Or, should we avoid the byte order conversion by leaving the precise values of the ND_NA_FLAG_xxx masks to the implementation, with a note such as: The implementation defines three network byte order values which may be used to access the R (router), S (solicited) and O (override) flags within the nd_na_flags_reserved field, as shown in this example: struct nd_neighbor_advert *nd_na; if (nd_na->nd_na_flags_reserved & ND_NA_FLAG_ROUTER) { /* handle R bit set */ } if (nd_na->nd_na_flags_reserved & ND_NA_FLAG_SOLICITED) { /* handle S bit set */ } if (nd_na->nd_na_flags_reserved & ND_NA_FLAG_OVERRIDE) { /* handle O bit set */ } - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 12:07:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24359; Mon, 14 Jul 1997 11:57:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA24352; Mon, 14 Jul 1997 11:56:52 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA10434; Mon, 14 Jul 1997 11:58:30 -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 LAA26428 for ; Mon, 14 Jul 1997 11:59:34 -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 LAA16148; Mon, 14 Jul 1997 11:58:08 -0700 Message-Id: <3.0.3.32.19970714115749.0320ad74@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 14 Jul 1997 11:57:49 -0700 To: Thomas Narten From: Bob Hinden Subject: (IPng 4097) Re: draft-ietf-ipngwg-addr-arch-v2-01.txt 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: 13381 Thomas, >Speaking as an individual, here are some comments on version -01 of >the draft: Thanks for the comments. >Are unnumbered interfaces truly unnumbered? That is, do they not have >link-local addresses? Do they not run Neighbor Discovery (and NUD) at >all? Good point. I think this text predates link-local addresses. We should require a link-local address on every interface. The issue becomes more of also having other addresses with greater scope. I will rewrite this section. >> Currently IPv6 continues the IPv4 model that a subnet is associated >> with one link. Multiple subnets may be assigned to the same link. > >Is the first sentence really correct given aggregation? I think the >problem is with the term "subnet", which doesn't mean the same thing >as "prefix identifying a specific link". Not sure how best to reword >(or whether to just leave alone). I will make the text clearer. I think "subnet prefix" is the correct way to describe this. >> (2) The format prefixes 001 and higher, except for Multicast >> Addresses (1111 1111), are all required to have to have 64-bit >> interface identifiers in EUI-64 format. See section 2.5.1 for >> definitions. > >How about changing "001 and higher" to "001 through 111" OK. I assume you mean "... format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are ....". >Also, in reading through both this and the unicast aggregation >document, it seems that the term "EUI-64 format" for an interface >identifier isn't ideal. Randomly generated IDs, for example, are not >related to EUI-64 at all. Also, by inverting the I/G bit, the >identifer is not in EUI-64 format. Could we change the name to >something like or "EUI-64 friendly >identifier" or ???? (This terminology issue comes up again later). I see your point but still think "EUI-64 format" is an accurate way of describing this. We are using the format, but with a slight change in the definition. >>2.5 Unicast Addresses >> >> The IPv6 unicast address is contiguous bit-wise maskable, similar to >> IPv4 addresses under Class-less Interdomain Routing [CIDR]. > >Not sure what the above means. Do you mean to say that unicast >addresses are meant to be aggregatable ala CIDR, so all subnet masks >must be contiguous? Yes. I will rewrite. >>2.5.1 Interface Identifiers > >How do these relate to interface tokens? The v6-over-ethernet spec >(and others, such as stateless autoconf) don't use this terminology. I >don't think (in theory) that interface tokens and interface >identifiers are exactly the same thing, though in practice I think >we're using them to mean pretty much the same thing. It would be good >to get the common terminology right and used consistently in the >various documents. Steve Deering answered this in a private email: "I think those two terms are naming two different concepts. "Interface ID" is the name we have long used in the unicast address architecture documents for the lowest-order field in an IPv6 unicast address. The "Address Token" is a link-type-specific quantity used to generate the value of the Interface ID field, when doing stateless address autoconfiguration. Interface IDs that were not statelessly autoconfigured don't necessarily contain Address Tokens." >> interfaces on a single node. Note that the use of the same interface >> identifier on multiple interfaces of a single node does not affect >> the interface identifier's global uniqueness. > >How about changing "does not affect the interface identifier's global >uniqueness" to something like "does not violate the global uniqueness >requirements for IPv6 addresses, as long as the interfaces are on >different links (i.e., the prefix bits will differ)." The sentence is intended to describe the "interface identifier" global uniqueness. I will add the second property (e.g., effect on the IPv6 address global uniqueness) to the note. >> links, tunnel end-points, etc.). It is required that the "u" bit >> (universal/local bit in IEEE EUI-64 terminology) be inverted when >> forming the interface identifier. > >How about adding "... from the EUI-64". OK >>2.5.3 The Loopback Address >> >> The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. >> It may be used by a node to send an IPv6 datagram to itself. It may >> never be assigned to any interface. > >I don't think this last sentence is quite correct. How can you send a >packet to yourself if it is not addressed to one of your interfaces? >How does the interface accept the packet as addressed to it? Is the >sentence needed? > >Would it be useful to state that a loopback address is conceptually >the same thing as an address having node-local scope (which IPv6 does >not define), i.e., one that may never leave the machine and be sent >out on an actual link? I think that is the point that the above text >is trying to insure. Another way to describe this is that it is associated with a virtual interface (i.e., the loopback interface) and not assigned to a physical interface. >> This mapping of NSAP address into IPv6 addresses is defined in >> [NSAP]. This document recommends that network implementors who have >> planned or deployed an OSI NSAP addressing plan, and who wish to >> deploy or transition to IPv6, should redesign a native IPv6 >> addressing plan to meet their needs. However, it also defines a set >> of mechanisms for the support of OSI NSAP addressing in an IPv6 >> network. These mechanisms are the ones that must be used if such >> support is required. This document also defines a mapping of IPv6 >> addresses within the OSI address format, should this be required. > >Isn't the OSI NSAP plan an informational RFC? I suspect it's not >appropriate to recommend (i.e., "these mechanisms are the ones that >must be used if ...") an Informational RFC as the Right Way to do >something. I thought it was experimental. In any case, this is the best advice we have for dealing with this topic so I think it is appropriate to provide the pointer. It is much better than nothing. >> Routers MUST not forward any packets with link-local source or >> destination addresses to other links. > >Hmm. Do we need to say something about Routing Headers? At first, I >thought Routing Headers are implicitly covered by the above. But that >turns out not to be completely true. Consider: addresses G1, LL2, G2, >G3, where G denotes a global scope address, LL denotes a link-local >address. If G1, LL2 and G2 were on the same link, but G3 was not, we >could have a routing header that said go via LL2, G2, and G3 that >would allow a packet with a LL address to be forwarded out of scope. > >I think we need to have specific text that clarifies whether this is >allowed. I don't think we should prohibit it and think it might be useful for diagnostic purposes. Anyone creating such a routing header would need very detailed knowledge of the path. So I think we can leave the current text intact. We should make sure that there is text that requires a receiver to authenticate any packet prior to reversing a routing header. >> Site-Local addresses have the following format: >> >> | 10 | >> | bits | 38 bits | 16 bits | 64 bits | >> +----------+-------------+-----------+----------------------------+ >> |1111111011| 0 | subnet ID | interface ID | >> +----------+-------------+-----------+----------------------------+ > >In the above, the SLA part appears to be fixed at 16 bits, whereas in >the aggregatable address section, these fields are not defined. >Instead, there is a reference to another document (that define the SLA >to be 16 bits). Don't we want both address formats to use the same >value for subnet ID field? I think we want to say that somewhere, >though I'm not sure where. This document or another one? If the >latter, which one? I will add the sizes back to the aggregatable address section. I agree it makes this relationship clearer. I also intend to update the aggregatable spec to make the terminology a bit more consistent. >> Routers MUST not forward any packets with site-local source or >> destination addresses outside of the site. > >I think we need to say something about Routing Headers here as well. I think the same answer applies as for link-local in routing headers. Useful for diagnositic pruposes. >> A node is required to compute and support a Solicited-Node multicast >> addresses for every unicast and anycast address it is assigned. > >How about: > > A node is required to compute and join the associated > Solicited-Node multicast address for every unicast and anycast > address it is assigned. OK >> The current approach [RFC1972] to map IPv6 multicast addresses into >> IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 >> multicast address and uses it to create a MAC address. Groups ID's > >Token ring is 802 and does things differently, so the above reference >to 802 is not correct. :-( I will change the text to mention that token ring is handled differently and this is described in the IPoverTokenRing spec. >> multicast address and uses it to create a MAC address. Groups ID's > ^^^^^^ >Group OK >> less than or equal to 32 bits will generate unique MAC addresses. > >> A host is required to recognize the following addresses as >> identifying itself: >> >> o Its Link-Local Address for each interface >> o Assigned Unicast Addresses >> o Loopback Address >> o All-Nodes Multicast Address >> o Solicited-Node Multicast Address for each of its assigned >> unicast and anycast addresses >> o Multicast Addresses of all other groups which the host belongs. > ^^ >add "to" OK. >Also, anycast address shouldn't be mentioned on hosts The intent here is to make the rule correct so if in the future we define anycast addresses for hosts the rule will not have to change. >> A router is required to recognize the following addresses as >> identifying itself: > >Rather than repeating them, how about saying that "a router recognizes >all the addresses a host is required to recognize, plus ..." and then >list them I will take a look at doing as you suggest. >> o The Subnet-Router anycast addresses for the links it has >> interfaces. > >Change to: > > o The Subnet-Router anycast addresses for the interface it is > configured to act as a router on. OK >> o All-Router Multicast Address > >Should that be all-routers (plural)? Yes. >> o Multicast Addresses of all other groups which the router >> belongs. > >"to" which the router belongs OK. >> The only address prefixes which should be predefined in an >> implementation are the: >> >> o Unspecified Address >> o Loopback Address > >These above are addresses, not prefixes, I think. Prefix/128 == Address >> Depending on the characteristics of a specific link or node there are >> a number of approaches to create EUI-64 based interface identifiers. > ^^^^^^ creating Still awkward. I will try to rewrite it. >> This appendix describes some of these approaches. > >> The only transformation from an EUI-64 identifier is to invert the > >transformation to what? "... from an EUI-64 identifier to an interface >ID is to ..." OK. >> individual/group bit, and "v" are the bits of the vendor supplied >> identifier. The IPv6 interface identifier would be of the form: > >Call it organizational identifier or company id (don't change >terminology) rather than "vendor supplied". I thought I had seen this terminology. I will double check. >> and Arcnet. The method to create an EUI-64 based identifier is to >> take the link identifier (e.g., the LocalTalk 8 bit node identifier) > >I don't think we should use the terminology "EUI-64 based" here. I will changed to "formated" >> When no built in identifier is available on a link the preferred > >built-in OK >> Node Serial Number (or other node specific token) > >node-specific OK >> There are many possible approaches to select an link-unique interface > ^^ >a OK >Finally, I believe the web page on EUI-64 says that the term "EUI-64" >is trademarked and cannot be referenced in a standards document >without permission from IEEE. Is someone chasing this one down? I guess the AD's could ask the IPng document editor to write a letter to the IEEE :-) Who should it be sent to? >Also, the use of MUST, must, MUST NOT and MUST not. is not quite >consistent. How about going through the document with that in >mind. For example: > >> The unspecified address must not be used as the destination address >> of IPv6 datagrams or in IPv6 Routing Headers. > >should probably be MUST NOT. I will make them consistent. Thanks again for the comments. 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 Jul 14 12:48:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24530; Mon, 14 Jul 1997 12:39:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24523; Mon, 14 Jul 1997 12:39:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA24210; Mon, 14 Jul 1997 12:41:15 -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 MAA12834 for ; Mon, 14 Jul 1997 12:42:25 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Mon, 14 Jul 1997 15:42:16 -0400 Message-ID: From: "Harrington, Dan" To: Thomas Narten , "'hinden@ipsilon.com'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4098) Re: draft-ietf-ipngwg-addr-arch-v2-01.txt Date: Mon, 14 Jul 1997 15:42:13 -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: 943 Just a quick clarification... > >Isn't the OSI NSAP plan an informational RFC? I suspect it's not > >appropriate to recommend (i.e., "these mechanisms are the ones that > >must be used if ...") an Informational RFC as the Right Way to do > >something. > > I thought it was experimental. In any case, this is the best advice we > have for dealing with this topic so I think it is appropriate to provide > the pointer. It is much better than nothing. RFC 1888 is categorized as Experimental. I'm not aware of anyone doing any experiments at this point... Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 12:54:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24543; Mon, 14 Jul 1997 12:43:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24532; Mon, 14 Jul 1997 12:43:35 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA25266; Mon, 14 Jul 1997 12:45:37 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA14369 for ; Mon, 14 Jul 1997 12:46:26 -0700 Received: from rtpmail03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA28062; Mon, 14 Jul 1997 15:45:00 -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 PAA29276; Mon, 14 Jul 1997 15:44:59 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA17934; Mon, 14 Jul 1997 15:45:00 -0400 Message-Id: <9707141945.AA17934@cichlid.raleigh.ibm.com> To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4099) Re: draft-ietf-ipngwg-addr-arch-v2-01.txt In-Reply-To: Your message of "Mon, 14 Jul 1997 11:57:49 PDT." <3.0.3.32.19970714115749.0320ad74@mailhost.ipsilon.com> Date: Mon, 14 Jul 1997 15:44:59 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2901 Bob, > >>2.5.1 Interface Identifiers > > > >How do these relate to interface tokens? The v6-over-ethernet spec > >(and others, such as stateless autoconf) don't use this terminology. I > >don't think (in theory) that interface tokens and interface > >identifiers are exactly the same thing, though in practice I think > >we're using them to mean pretty much the same thing. It would be good > >to get the common terminology right and used consistently in the > >various documents. > Steve Deering answered this in a private email: "I think those two terms > are naming two different concepts. "Interface ID" is the name we have long > used in the unicast address architecture documents for the lowest-order > field in an IPv6 unicast address. The "Address Token" is a > link-type-specific quantity used to generate the value of the Interface ID > field, when doing stateless address autoconfiguration. Interface IDs that > were not statelessly autoconfigured don't necessarily contain Address Tokens." If we use Steve's definition, it seems to me that the terminology being used elsewhere isn't quite consistent then. addrconf says: interface token - a link-dependent identifier for an interface that is (at least) unique per link. Stateless address autoconfiguration combines an interface token with a prefix to form an address. From address autoconfiguration's perspective, an interface token is a bit string of known length. The exact length of an interface token and the way it is created is defined in a separate link-type specific document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). In many cases, the token will be the same as the interface's link-layer address. Then the v6-over-ether documents says: 4. Stateless Autoconfiguration The interface token [CONF] for an Ethernet interface is based on the EUI-64 identifier [EUI64] derived from the interface's built-in 48- bit IEEE 802 address. The EUI-64 is formed as follows. (Canonical bit order is assumed throughout.) In the latter documents (and I assume others as well, though I didn't check), it seems to me that "interface token" (as used above) means the same thing as "interface identifer" as defined by Steve. Should the other documents be tweaked? 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 Mon Jul 14 13:07:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24601; Mon, 14 Jul 1997 12:55:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24594; Mon, 14 Jul 1997 12:54:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA28261; Mon, 14 Jul 1997 12:56:54 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA18486 for ; Mon, 14 Jul 1997 12:58:06 -0700 Received: from ftp.com by ftp.com ; Mon, 14 Jul 1997 15:56:55 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Mon, 14 Jul 1997 15:56:55 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id PAA26847; Mon, 14 Jul 1997 15:52:50 -0400 Message-Id: <199707141952.PAA26847@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: ipng@sunroof.eng.sun.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 4100) RE: W.G. Last Call on "Advanced Sockets API for IPv6" Date: Mon, 14 Jul 1997 15:56:53 -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: 881 >>Reply to your message of 6/30/97 2:40 PM >This is a IPng working group last call for comments on advancing the >following document to Informational: > > Title : Advanced Sockets API for IPv6 = =20 One minor point, one question: - The list of setsockopt() calls on page 24 should include IPV6_NEXTHOP - What's passed to user space when a packet is received and IPV6_NEXTHOP is requested: the destination address, nothing, and/or an error code? -- Frank -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 14 13:50:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24749; Mon, 14 Jul 1997 13:40:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24742; Mon, 14 Jul 1997 13:40:14 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA09763; Mon, 14 Jul 1997 13:42:22 -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 NAA05730 for ; Mon, 14 Jul 1997 13:43:17 -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 NAA02524; Mon, 14 Jul 1997 13:42:04 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id NAA28253; Mon, 14 Jul 1997 13:42:04 -0700 (MST) Message-Id: <199707142042.NAA28253@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 14 Jul 1997 13:42:04 -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: Frank T Solensky , ipng@sunroof.eng.sun.com Subject: (IPng 4101) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1030 [In your message of Jul 14, 3:56pm you write:] > >This is a IPng working group last call for comments on advancing the > >following document to Informational: > > > > Title : Advanced Sockets API for IPv6 > > One minor point, one question: > - The list of setsockopt() calls on page 24 should include IPV6_NEXTHOP It is intentionally not in the list on p. 24 as it is an output-only option. > - What's passed to user space when a packet is received and IPV6_NEXTHOP > is requested: the destination address, nothing, and/or an error code? Nothing gets passed back to the user for this option. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 13:56:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24777; Mon, 14 Jul 1997 13:44:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA24764; Mon, 14 Jul 1997 13:44:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA10806; Mon, 14 Jul 1997 13:46:45 -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 NAA07631 for ; Mon, 14 Jul 1997 13:47:46 -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 NAA02535 for ; Mon, 14 Jul 1997 13:46:35 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id NAA28271 for ipng@sunroof.Eng.Sun.COM; Mon, 14 Jul 1997 13:46:34 -0700 (MST) Message-Id: <199707142046.NAA28271@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Mon, 14 Jul 1997 13:46:34 -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 4102) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 625 One minor typo that I just noticed is on p. 28: the ipi6_ifindex member of the in6_pktinfo structure should be an "unsigned int", not an "int", to be consistent with the interface indexes that are used in the basic API (RFC 2133). Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 16:12:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA25067; Mon, 14 Jul 1997 16:01:41 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA25060; Mon, 14 Jul 1997 16:01:32 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA13988; Mon, 14 Jul 1997 16:03:39 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00783; Mon, 14 Jul 1997 16:03:38 -0700 Date: Mon, 14 Jul 1997 16:03:38 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707142303.QAA00783@bobo.eng.sun.com> To: narten@raleigh.ibm.com Subject: (IPng 4103) Re: ND question Cc: ipng@sunroof.eng.sun.com, nordmark@jurassic MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2944 > My recollection on this was that Erik & I discussed the MUST > vs. SHOULD in this case and left it a SHOULD simply because MUST is > absolute and would rule out some possible future scenario where this > was useful (e.g., some new type of link-layer with "interesting" > properties). We did not have a specific scenario in mind that would > use this, but didn't see the harm in leaving the door open a crack. I think we were convinced to make it a SHOULD instead of a MUST because implementors thought it was waterful. > It also seems pretty hard to imagine an implementation that would ship > with such brokeness (i.e., one that leads to looping). One of the > first implementations that a new implementation would be tested > against is itself (one hopes!), and the results would be pretty > dramatic! Hence, I don't see a big danger that needs to be plugged. I think it is worse than that in that an implementation might appear to work until it tries to interoperate with something that agressively garbage collects entries in the neighbor cache. Thus when the broken implementation sends the unicast NS (with no source link-layer address) the peer has no cache entry. But for implementations that do not grabage collect neighbor cache entries things would work just fine. > Would it help to add some additional "danger danger" text to Section > 4.3 to make it clear why the SHOULD is a SHOULD? (I am also not averse > to changing the SHOULD to a MUST if that is what folks want.) I think we need to make this a MUST for the sender (by updating the "Neighbor Solicitation Message format" and the "Sending Neighbor Solicitations" sections.) But should we also add some rules to the receiver e.g. in the message validation rules? A similar issue might show up with Router Solicitations. If a router receives an RS without a source link-layer address the specification says that the router might decide to unicast the router advertisement. But it might not have a neighbor cache entry causing it to go through the address resolution (sending an NS waiting for a NA packet) before it can send the RA. Is this a problem? Should we require that RS messages (on link layers that have link-layer address) must contain a link-layer address? Or should we say that the router should not ever unicast a RA when the RS did not contain a link-layer address? (I'd like the processing of the RS to be independed of the content of the neighbor cache since it makes it harder to implement the "router discovery" component separately from the neighbor cache.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 14 16:34:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA25170; Mon, 14 Jul 1997 16:24:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA25162; Mon, 14 Jul 1997 16:23:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA23150; Mon, 14 Jul 1997 16:25:56 -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 QAA01346 for ; Mon, 14 Jul 1997 16:27:07 -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 QAA29980; Mon, 14 Jul 1997 16:25:55 -0700 Message-Id: <3.0.3.32.19970714162538.0322ed0c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 14 Jul 1997 16:25:38 -0700 To: Thomas Narten From: Bob Hinden Subject: (IPng 4104) Re: draft-ietf-ipngwg-addr-arch-v2-01.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9707141945.AA17934@cichlid.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 677 Thomas, >In the latter documents (and I assume others as well, though I didn't >check), it seems to me that "interface token" (as used above) means >the same thing as "interface identifer" as defined by Steve. > >Should the other documents be tweaked? Yes, I think it would be a good idea. 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 Jul 15 07:11:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA25734; Tue, 15 Jul 1997 07:03:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA25727; Tue, 15 Jul 1997 07:03:41 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA02999; Tue, 15 Jul 1997 07:05:51 -0700 Received: from mail.intercenter.net (mir.intercenter.net [207.211.128.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA02838 for ; Tue, 15 Jul 1997 07:07:01 -0700 Received: (qmail 22625 invoked from network); 15 Jul 1997 14:05:43 -0000 Received: from ct2-02.intercenter.net (HELO LOCALNAME) (207.211.129.67) by mir.intercenter.net with SMTP; 15 Jul 1997 14:05:43 -0000 Message-ID: <33CBAD36.2680@phase2net.com> Date: Tue, 15 Jul 1997 10:02:46 -0700 From: Charles Mumford Reply-To: cmumford@phase2net.com Organization: phase2 networks X-Mailer: Mozilla 3.01 (Win16; I) MIME-Version: 1.0 To: IPNG WG List Subject: (IPng 4105) Re: ND question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2182 Richard Draves wrote: > The last thing you want is for some combination of strange/buggy > implementations to get into a "solicit storm" where each node responds > to the other with another Solicitation. > I think this possibility is best ruled out up front, by forbidding > implementations from responding to a Solicitation with another > Solicitation. This would be similar to the prohibition against sending > an ICMPv6 error message as a result of receiving an ICMPv6 error > message. and Erik Nordmark wrote: > > Would it help to add some additional "danger danger" text to Section > > 4.3 to make it clear why the SHOULD is a SHOULD? (I am also not > > averse to changing the SHOULD to a MUST if that is what folks want.) > I think we need to make this a MUST for the sender (by updating > the "Neighbor Solicitation Message format" and the "Sending Neighbor > Solicitations" sections.) > But should we also add some rules to the receiver e.g. in the message > validation rules? > A similar issue might show up with Router Solicitations. > If a router receives an RS without a source link-layer address > the specification says that the router might decide to unicast > the router advertisement. But it might not have a neighbor cache > entry causing it to go through the address resolution (sending > an NS waiting for a NA packet) before it can send the RA. The smallest solution would be to simply say that a node MUST NOT respond to a neighbor solicitation that does not contain a source link layer address option with another NS w/o slla. This would prohibit looping, as the (original) sender will then get either a link layer address on its original target or no response at all. This would also allow the NS/NA exchange when resolving an address for a unicast router ad. Charles -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 15 12:14:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA26004; Tue, 15 Jul 1997 12:04:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA25997; Tue, 15 Jul 1997 12:04:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA17977; Tue, 15 Jul 1997 12:06:44 -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 MAA09534; Tue, 15 Jul 1997 12:07:33 -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 MAA04616; Tue, 15 Jul 1997 12:05:39 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id MAA10336; Tue, 15 Jul 1997 12:05:19 -0700 (MST) Message-Id: <199707151905.MAA10336@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Tue, 15 Jul 1997 12:05:19 -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 4106) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: matt.thomas@altavista-software.com, Erik.Nordmark@Eng, Jack McCann Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2291 Anyone have a preference one way or the other regarding the following: Jack McCann wrote: > > 2. If I'm reading my bits right, with the current definitions of the > nd_na_flags_reserved field and the ND_NA_FLAG_xxx masks, before > &'ing the two, either: > > a) nd_na_flags_reserved must be converted to host byte order, e.g. > ntohl(nd_na->nd_na_flags_reserved) & ND_NA_FLAG_ROUTER > > or > > b) ND_NA_FLAG_xxx must be converted to network byte order, e.g. > nd_na->nd_na_flags_reserved & htonl(ND_NA_FLAG_ROUTER) > > Or, should we avoid the byte order conversion by leaving the precise > values of the ND_NA_FLAG_xxx masks to the implementation, with a note > such as: > > The implementation defines three network byte order values which > may be used to access the R (router), S (solicited) and O (override) > flags within the nd_na_flags_reserved field, as shown in > this example: The problem that Jack points out is that the flag #define ND_NA_FLAG_ROUTER 0x80000000 assumes that the value is in host byte order. There are two other ND_NA_FLAG_xxx values that share this problem, along with three IP6F_xxx values (the 16-bit offset field in the fragment header). The problem has existed in IPv4 code all along with the IP_DF and IP_MF bits. Berkeley-derived code (ip_input, for example) does an explicit htons() on the ip_off field, as does tcpdump, and then one set of constants are defined, in host byte order. We can (1) leave the constants as-is and add a note that they are defined in host byte order and you have to convert either the field or the constant, or (2) define the constant as being in network byte order. I just looked at two publicly available implementations, and the INRIA code does (1) but the NRL code does (2). Is there a consensus as to which byte ordering should be used for these constants? Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 15 13:21:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26254; Tue, 15 Jul 1997 13:12:05 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26247; Tue, 15 Jul 1997 13:11:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA01738; Tue, 15 Jul 1997 13:14:04 -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 NAA03919 for ; Tue, 15 Jul 1997 13:15:10 -0700 Received: from rtpmail03.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA27818; Tue, 15 Jul 1997 16:10:16 -0400 Received: from clemson.raleigh.ibm.com (clemson.raleigh.ibm.com [9.37.176.99]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id QAA30118; Tue, 15 Jul 1997 16:10:19 -0400 Received: by clemson.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20794; Tue, 15 Jul 1997 16:10:18 -0400 Date: Tue, 15 Jul 1997 16:10:18 -0400 (EDT) From: Brian Haberman To: "W. Richard Stevens" Cc: ipng@sunroof.eng.sun.com, matt.thomas@altavista-software.com, Erik.Nordmark@Eng, Jack McCann Subject: (IPng 4107) Re: W.G. Last Call on "Advanced Sockets API for IPv6" In-Reply-To: <199707151905.MAA10336@kohala.kohala.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1489 On Tue, 15 Jul 1997, W. Richard Stevens wrote: > > We can (1) leave the constants as-is and add a note that they are > defined in host byte order and you have to convert either the field > or the constant, or (2) define the constant as being in network byte > order. > Rich, I think that (2) is a better option. It eliminates the possibility that a user will forget to convert the field or the constant. Having to convert the field or the constant seems confusing to me and it would be nice to eliminate as much confusion as possible. :) Brian *----------------------------------- ----------------------------* | Brian K. Haberman / / | | Remote Access Products \ \ Reality is a horde of | | IBM Research Triangle Park, NC / / mice nibbling away in the | | Internal Phone : 8-444-2673 \ \ basement of your dreams. | | External Phone : (919) 254-2673 / / | | email : haberman@raleigh.ibm.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 Jul 15 13:26:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26271; Tue, 15 Jul 1997 13:16:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA26264; Tue, 15 Jul 1997 13:16:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02559; Tue, 15 Jul 1997 13:18:12 -0700 Received: from ftp.com (ftp.com [128.127.2.122]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA05125 for ; Tue, 15 Jul 1997 13:18:37 -0700 Received: from ftp.com by ftp.com ; Tue, 15 Jul 1997 16:15:40 -0400 Received: from mailserv-2high.ftp.com by ftp.com ; Tue, 15 Jul 1997 16:15:40 -0400 Received: from fenway.ftp.com by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id QAA01134; Tue, 15 Jul 1997 16:11:34 -0400 Message-Id: <199707152011.QAA01134@MAILSERV-2HIGH.FTP.COM> X-Mapi-Messageclass: IPM To: rstevens@kohala.com, ipng@sunroof.eng.sun.com Cc: matt.thomas@altavista-software.com, Erik.Nordmark@Eng, mccann@zk3.dec.com X-Mailer: FTP Software Internet Mail 2.0 Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 4108) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Date: Tue, 15 Jul 1997 16:15:38 -0400 Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 826 >>Reply to your message of 7/15/97 3:24 PM > >We can (1) leave the constants as-is and add a note that they are >defined in host byte order and you have to convert either the field >or the constant, or (2) define the constant as being in network byte >order. I'd prefer (2), with an "#if BYTE_ORDER==LOW/#elif BYTE_ORDER==HIGH" around the macros, since htonl() incurs real memory cycles on the platform I'm working on these days. -- Frank -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 16 11:44:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA27782; Wed, 16 Jul 1997 11:35:09 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA27775; Wed, 16 Jul 1997 11:34:58 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA28056; Wed, 16 Jul 1997 11:37:08 -0700 Received: from mailhost1.BayNetworks.COM ([134.177.3.16]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA21723 for ; Wed, 16 Jul 1997 11:37:03 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/07/07-E) with ESMTP id LAA14941; Wed, 16 Jul 1997 11:31:54 -0700 (PDT) for Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id LAA24335; Wed, 16 Jul 1997 11:31:51 -0700 (PDT) for Posted-Date: Wed, 16 Jul 1997 11:31:51 -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 OAA24831; Wed, 16 Jul 1997 14:31:53 -0400 for Message-Id: <3.0.32.19970716142949.006b2e40@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 16 Jul 1997 14:29:50 -0400 To: ipng@sunroof.eng.sun.com From: Dimitry Haskin Subject: (IPng 4109) RE: ND question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1678 Folks, While we are on the address resolution subject I'd like to ponder another question. >From rfc1970: 7.2.3. Receipt of Neighbor Solicitations A valid Neighbor Solicitation where the Target Address is not a unicast or anycast address assigned to the receiving interface, and the Target Address is not a "tentative" address on which Duplicate Address Detection is being performed [ADDRCONF] MUST be silently ignored. If the Target Address is tentative, the Neighbor Solicitation should be processed as described in [ADDRCONF]. Is MUST really necessary here? What is the danger of responding to a solicitation targeted to an address of other than the receiving interface of the same node, provided that a link-layer address of the receiving interface is specified in the reply? Let's consider a node address that is not assigned to a particular physical interface but rather is viewed as an address of a logical interface. As an example, it can be some pre-defined anycast address that is not specific to a particular link. Wouldn't it be desirable to be able to perform address resolution on such an address? In addition, "MUST" conflicts with solicited proxy NA described in 7.2.8. Note that it (proxy) is not exactly the same case as one described above. 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 Jul 16 14:06:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA28108; Wed, 16 Jul 1997 13:57:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA28101; Wed, 16 Jul 1997 13:57:24 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA01086; Wed, 16 Jul 1997 13:59:36 -0700 Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.31]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA06916 for ; Wed, 16 Jul 1997 14:00:41 -0700 Received: by mail5.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Wed, 16 Jul 1997 13:58:04 -0700 Message-ID: From: Richard Draves To: "'Dimitry Haskin'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4110) Re: ND question Date: Wed, 16 Jul 1997 13:56:23 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2332 >Is MUST really necessary here? What is the danger of responding to a >solicitation targeted to an address of other than the receiving interface >of the same node, provided that a link-layer address of the receiving >interface is specified in the reply? To start with, such an advertisement should not have the solicited bit set. Otherwise the receiver will think it has reachability to the target address, when that has not been confirmed. There's also a danger of multiple advertisements being sent in response to a solicitation, using excess bandwidth and possibly provoking collisions. (I assume this is why section 7.2.4 talks about a random delay when the target address is an anycast address, and section 7.2.8 has a similar provision for proxying.) >Let's consider a node address that is not assigned to a particular physical >interface but rather is viewed as an address of a logical interface. As an >example, it can be some pre-defined anycast address that is not specific to >a particular link. Wouldn't it be desirable to be able to perform address >resolution on such an address? If the anycast address is not specific to a link, wouldn't you just assign it to every interface of the node? >In addition, "MUST" conflicts with solicited proxy NA described in 7.2.8. >Note that it (proxy) is not exactly the same case as one described above. My reading of 7.2.8 is that in the proxy case, a router is pretending that some other node's IP address is assigned to itself. The router will send an Advertisement that will cause traffic directed to that address to be sent to itself, so the router can forward it in the right direction. The additional provisions in 7.2.8 are to cope with the case where the node is actually on the link, ie the router is confused and it's proxying service is not needed. So as I read it, 7.2.8 doesn't quite violate the MUST in 7.2.3, depending on the definition of "address assigned to interface". Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 14:59:20 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA28167; Wed, 16 Jul 1997 14:47:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA28160; Wed, 16 Jul 1997 14:47:27 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA13988; Wed, 16 Jul 1997 14:49:38 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA24342 for ; Wed, 16 Jul 1997 14:50:47 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49) id <3ZMR0DLB>; Wed, 16 Jul 1997 14:52:53 -0700 Message-ID: From: Richard Draves To: "'Erik.Nordmark@Eng.Sun.COM'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4111) Re: ND question Date: Wed, 16 Jul 1997 14:49:27 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1293 >Is this a problem? Should we require that RS messages (on link layers >that have link-layer address) must contain a link-layer address? I think RS messages SHOULD contain a Source Link-Layer Address option. I think MUST is not necessary here, because if the router does decide to unicast a RA and then must perform ND to get a link-layer address, there's a clear base case to the recursion. RS processing might result in the router sending a NS, but NS processing by a node will never produce an RS. I am curious why section 6.3.7 of RFC 1970 says in reference to sending RS messages: "The Source Link-Layer Address option SHOULD be set to the host's link-layer address, if the IP source address is a unicast address." Implying that the RS should not carry a Source Link-Layer Address option if the IP source address is the unspecified address. I ask because there's no equivalent caveat for NS messages. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 15:16:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28216; Wed, 16 Jul 1997 15:06:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28207; Wed, 16 Jul 1997 15:06:12 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA19752; Wed, 16 Jul 1997 15:08:22 -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 PAA00897 for ; Wed, 16 Jul 1997 15:09:34 -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 PAA10527; Wed, 16 Jul 1997 15:08:22 -0700 Message-Id: <3.0.3.32.19970716150754.0072afdc@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 16 Jul 1997 15:07:54 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4112) New IPng Addressing Drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1475 I submitted a set of new set of IPng addressing drafts to become internet-drafts. The changes include: An IPv6 Aggregatable Global Unicast Address Format - Changed termonology to be consistent with IPv6 address architecture - Moved assignment rules to new draft. TLA and NLA Assignment Rules - New document with assignment rules (from aggregation document). IP Version 6 Addressing Architecture - Clarify addressing model section - Update to new aggregation terminology IPv6 Testing Address Allocation - Update to new aggregation terminology IPv6 Multicast Address Assignments - Add assignment for service location protocol Bob p.s. Until they become Internet-Drafts they can be found at: ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-addr-arch-v2-02.txt ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-multicast-assgn-04.txt ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-testv2-addralloc-01.txt ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-tla-assignment-00.txt ftp://playground.sun.com/pub/ipng/draft-ietf-ipngwg-unicast-aggr-02.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 Wed Jul 16 15:40:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28277; Wed, 16 Jul 1997 15:31:51 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28270; Wed, 16 Jul 1997 15:31:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA26130; Wed, 16 Jul 1997 15:33:49 -0700 Received: from mailhost1.BayNetworks.COM ([134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA09758 for ; Wed, 16 Jul 1997 15:34:35 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/07/07-E) with ESMTP id PAA25706 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id PAA00242 Posted-Date: Wed, 16 Jul 1997 15:33:08 -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 SAA26217; Wed, 16 Jul 1997 18:33:09 -0400 for Message-Id: <3.0.32.19970716183106.00688bc0@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 16 Jul 1997 18:31:07 -0400 To: Richard Draves From: Dimitry Haskin Subject: (IPng 4113) RE: ND question 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: 3126 At 01:56 PM 7/16/97 -0700, Richard Draves wrote: >>Is MUST really necessary here? What is the danger of responding to a >>solicitation targeted to an address of other than the receiving >interface >>of the same node, provided that a link-layer address of the receiving >>interface is specified in the reply? > >To start with, such an advertisement should not have the solicited bit >set. Otherwise the receiver will think it has reachability to the target >address, when that has not been confirmed. But there is reachability even if through a 'proxy' interface. I don't think there is less reachability than when a proxy is done for an address of a different node (as in section 7.2.8) in which case it is not required to set the Solicited flag to zero. > >There's also a danger of multiple advertisements being sent in response >to a solicitation, using excess bandwidth and possibly provoking >collisions. (I assume this is why section 7.2.4 talks about a random >delay when the target address is an anycast address, and section 7.2.8 >has a similar provision for proxying.) > Are you concern about a node that may have multiple interfaces to the same link? >>Let's consider a node address that is not assigned to a particular >physical >>interface but rather is viewed as an address of a logical interface. As >an >>example, it can be some pre-defined anycast address that is not >specific to >>a particular link. Wouldn't it be desirable to be able to perform >address >>resolution on such an address? > >If the anycast address is not specific to a link, wouldn't you just >assign it to every interface of the node? > For one it may not be practical if a manual configuration is involved. Then one may contend that it would violate the addressing spec. In addition, it does not have to be an anycast address. >>In addition, "MUST" conflicts with solicited proxy NA described in >7.2.8. >>Note that it (proxy) is not exactly the same case as one described >above. > >My reading of 7.2.8 is that in the proxy case, a router is pretending >that some other node's IP address is assigned to itself. The router will >send an Advertisement that will cause traffic directed to that address >to be sent to itself, so the router can forward it in the right >direction. The additional provisions in 7.2.8 are to cope with the case >where the node is actually on the link, ie the router is confused and >it's proxying service is not needed. > >So as I read it, 7.2.8 doesn't quite violate the MUST in 7.2.3, >depending on the definition of "address assigned to interface". > Wow, this is quite a reading! Up to now I've thought that it has been obvious that 7.2.8 deals with addresses that are not assigned to the proxy interface ;) >Rich > 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 Jul 16 18:29:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA28728; Wed, 16 Jul 1997 18:19:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA28721; Wed, 16 Jul 1997 18:19:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA02992; Wed, 16 Jul 1997 18:21:56 -0700 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.42]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA28067 for ; Wed, 16 Jul 1997 18:23:10 -0700 Received: by INET-02-IMC with Internet Mail Service (5.0.1458.49) id <3ZMQFNA5>; Wed, 16 Jul 1997 18:22:00 -0700 Message-ID: From: Richard Draves To: "'Dimitry Haskin'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4114) RE: ND question Date: Wed, 16 Jul 1997 18:21:32 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2398 Ah, I had missed the import of the phrase "provided that a link-layer address of the receiving interface is specified in the reply" in your initial question. I thought you were asking about situations where a node would send a NA on behalf of another node (specifying the other node's link-layer address). >>If the anycast address is not specific to a link, wouldn't you just >>assign it to every interface of the node? > >For one it may not be practical if a manual configuration is involved. Then >one may contend that it would violate the addressing spec. In addition, it >does not have to be an anycast address. I don't see the problem with manual configuration. If there are files or something to be updated, a tool can do that. The world has moved beyond users updating configuration files with vi. I don't see why it would violate the addressing spec to have an anycast address assigned to multiple interfaces. That's what they are for. Can you describe a situation where you'd like to do this with a unicast address? >Wow, this is quite a reading! Up to now I've thought that it has been >obvious that 7.2.8 deals with addresses that are not assigned to the proxy >interface ;) Well if we're reading it differently perhaps it should be clarified. But the way I read it, the proxy case that 7.2.8 describes is exactly like the treatment of anycast addresses. (In fact 7.2.8 says just that.) That is, in the proxy case you take a unicast address (assigned to a mobile node's interface)and treat it like an anycast address. That means it can be assigned to a second interface (the router's interface) and the behavior described (not setting the override flag, random delay) all follows. The proxy case is different from the usual anycast case in that the address is assigned to the router's interface like an anycast address and assigned to the mobile node's interface as a unicast address. But you would get the same protocol behavior on the link with inconsistent configuration files, for example. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 16 19:37:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA28780; Wed, 16 Jul 1997 19:29:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA28773; Wed, 16 Jul 1997 19:29:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA11205; Wed, 16 Jul 1997 19:31:56 -0700 Received: from mailhost1.BayNetworks.COM ([134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA11630 for ; Wed, 16 Jul 1997 19:33:10 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107]) by mailhost1.BayNetworks.COM (8.8.5/BNET-97/07/07-E) with ESMTP id TAA02509 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.5/BNET-97/07/07-I) with ESMTP id TAA01317 Posted-Date: Wed, 16 Jul 1997 19:31:55 -0700 (PDT) Received: from dhaskin.baynetworks.com (eng_ppp2 [192.32.171.142]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id WAA07367; Wed, 16 Jul 1997 22:31:54 -0400 for Message-Id: <3.0.1.32.19970716223423.006a37c8@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 16 Jul 1997 22:34:23 -0400 To: Richard Draves , "'Dimitry Haskin'" From: Dimitry Haskin Subject: (IPng 4115) RE: ND question 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: 3321 At 06:21 PM 7/16/97 -0700, Richard Draves wrote: >Ah, I had missed the import of the phrase "provided that a link-layer >address of the receiving interface is specified in the reply" in your >initial question. I thought you were asking about situations where a >node would send a NA on behalf of another node (specifying the other >node's link-layer address). > >>>If the anycast address is not specific to a link, wouldn't you just >>>assign it to every interface of the node? >> >>For one it may not be practical if a manual configuration is involved. >Then >>one may contend that it would violate the addressing spec. In addition, >it >>does not have to be an anycast address. > >I don't see the problem with manual configuration. If there are files or >something to be updated, a tool can do that. The world has moved beyond >users updating configuration files with vi. > Really? Ask any large ISP what they are using. You'll be surprised. But even if a fancy tool is available, why should I use it if there is a simpler solution? >I don't see why it would violate the addressing spec to have an anycast >address assigned to multiple interfaces. That's what they are for. > Sorry, my fault -- it applies to unicast addresses only. >Can you describe a situation where you'd like to do this with a unicast >address? > Generally speaking I don't have to. My question was if there is any killer problem to proxy for a different interface address on the same node. If there is none, it should not be prohibited and someone may very well find use for it. Well.. logical interfaces with unicast addresses assigned to them are widely used. In some cases they only used for tcp connections between neigboring nodes (most notable to run BGP). I guess, it may be desirable to be able to resolve such addresses without involving route advertisements (not to get confused with ND Router Advertisement) to these addresses. >>Wow, this is quite a reading! Up to now I've thought that it has been >>obvious that 7.2.8 deals with addresses that are not assigned to the >proxy >>interface ;) > >Well if we're reading it differently perhaps it should be clarified. But >the way I read it, the proxy case that 7.2.8 describes is exactly like >the treatment of anycast addresses. (In fact 7.2.8 says just that.) That >is, in the proxy case you take a unicast address (assigned to a mobile >node's interface)and treat it like an anycast address. That means it can >be assigned to a second interface (the router's interface) and the >behavior described (not setting the override flag, random delay) all >follows. > >The proxy case is different from the usual anycast case in that the >address is assigned to the router's interface like an anycast address >and assigned to the mobile node's interface as a unicast address. But >you would get the same protocol behavior on the link with inconsistent >configuration files, for example. > >Rich > 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 Jul 17 02:04:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA29014; Thu, 17 Jul 1997 01:56:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA29007; Thu, 17 Jul 1997 01:56:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA17506; Thu, 17 Jul 1997 01:58:43 -0700 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA08910 for ; Thu, 17 Jul 1997 01:59:55 -0700 Received: by mailgate.rdg.opengroup.org; id AA31201; Thu, 17 Jul 1997 09:59:56 GMT Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA09511; Thu, 17 Jul 1997 09:51:17 +0100 Received: from cjh.rdg.opengroup.org(192.153.166.177) by mailhome.rdg.opengroup.org via smap (V1.3) id smaa09507; Thu Jul 17 09:51:17 1997 Message-Id: <3.0.32.19970717095127.006a1114@xopuk.rdg.opengroup.org> X-Sender: cjh@xopuk.rdg.opengroup.org X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 17 Jul 1997 09:51:43 +0100 To: ipng@sunroof.eng.sun.com From: Chris Harding Subject: (IPng 4117) Re: W.G. Last Call on "Advanced Sockets API for IPv6" Cc: XoTGnet@xopen.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3222 Dear IPng Mailgroup Member, >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. > The following comments have been made by members of XNET, the working group with responsibility for the sockets API published by The Open Group as part of the Single UNIX Specification. 1. Section 2.1.2 page 8 /* Hop-by-Hop options header */ and elsewhere. RFC2133 follows POSIX practice, now also adopted by The Open Group, in stating clearly that structures can contain fields other than those specified, and that implementations can change the order of fields unless the specification explicitly states otherwise. In these circumstances, it does not make sense to define padding fields. If alignment is important, the specification can state this as a requirement. But for this API, it is not clear that alignment should be a requirement. It may be best to leave alignment to the implementation - implementations can insert padding fields for alignment purposes and will no doubt do so if it gives them a performance advantage. The text in section 6 at the start of page 32 should be reviewed with this in mind. 2) Both POSIX and XNET have been concerned about the amount of "namespace pollution" produced by sockets, but have not felt it right to make changes to an interface that is well established. There is, however, a case for saying that all new additions to the interface should use a small number of prefixes - such as sock, SOCK, IPV6, ICMP6. For example, ND_ could be replaced by ICMP6_ND_. It would cost little to make such a change at this stage, would limit namespace pollution to what we already have, and would simplify an eventual clean-up. Regards, Chris +++++ ---------------------------------------------------------------------------- --- Chris Harding Apex Plaza, Forbury Road T H E Development Manager Reading, Berkshire O P E N E-Mail: c.harding@opengroup.org RG1 1AX G R O U P WWW: www.opengroup.org United Kingdom Tel: +44 118 950 8311 x2262 Fax: +44 118 950 0110 ---------------------------------------------------------------------------- --- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 17 12:31:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA29740; Thu, 17 Jul 1997 12:02:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA29729; Thu, 17 Jul 1997 12:02:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08547; Thu, 17 Jul 1997 12:04:46 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA09572 for ; Thu, 17 Jul 1997 12:05:59 -0700 Received: from ietf.ietf.org by ietf.org id aa12699; 17 Jul 97 13: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 4120) I-D ACTION:draft-ietf-ipngwg-tla-assignment-00.txt Date: Thu, 17 Jul 1997 13:24:20 -0400 Message-ID: <9707171324.aa12699@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3992 --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 : TLA and NLA Assignment Rules Author(s) : R. Hinden, M. O'Dell Filename : draft-ietf-ipngwg-tla-assignment-00.txt Pages : 5 Date : 07/16/1997 This document defines assignment rules for Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in [AGGR]. These rules apply to registries allocating TLA ID's and to organizations receiving TLA ID's. 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-tla-assignment-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-tla-assignment-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-tla-assignment-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: <19970716165755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-tla-assignment-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-tla-assignment-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970716165755.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 Thu Jul 17 12:31:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA29737; Thu, 17 Jul 1997 12:02:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA29715; Thu, 17 Jul 1997 12:02:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08515; Thu, 17 Jul 1997 12:04:35 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA09509 for ; Thu, 17 Jul 1997 12:05:49 -0700 Received: from ietf.ietf.org by ietf.org id aa12666; 17 Jul 97 13: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 4119) I-D ACTION:draft-ietf-ipngwg-testv2-addralloc-01.txt Date: Thu, 17 Jul 1997 13:24:17 -0400 Message-ID: <9707171324.aa12666@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4667 --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 Testing Address Allocation Author(s) : R. Hinden, R. Fink, J. Postel Filename : draft-ietf-ipngwg-testv2-addralloc-01.txt Pages : 4 Date : 07/16/1997 This document describes an allocation plan for IPv6 addresses to be used in testing IPv6 prototype software. These addresses are temporary and will be reclaimed in the future. Any IPv6 system using these addresses will have to renumber at some time in the future. These addresses will not to be routable in the Internet other than for IPv6 testing. The address format for the IPv6 test address is consistent with the "Aggregatable Global Unicast Address Allocation" [AGGR] and "TLA and NLA Assignment Rules" [TLAASN]. This document is intended to replace RFC1897 "IPv6 Testing Address Allocation", January 1996. RFC1897 will become historic. The addresses described in this document are consistent with the IPv6 Addressing Architecture [ARCH]. They may be assigned to nodes manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for IPv6 [DHCPv6]. 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-testv2-addralloc-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-testv2-addralloc-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-testv2-addralloc-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: <19970716170728.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-testv2-addralloc-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-testv2-addralloc-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970716170728.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 Thu Jul 17 12:33:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA29747; Thu, 17 Jul 1997 12:03:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA29739; Thu, 17 Jul 1997 12:02:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08601; Thu, 17 Jul 1997 12:05:04 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA09667 for ; Thu, 17 Jul 1997 12:06:15 -0700 Received: from ietf.ietf.org by ietf.org id aa12727; 17 Jul 97 13: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 4121) I-D ACTION:draft-ietf-ipngwg-unicast-aggr-02.txt Date: Thu, 17 Jul 1997 13:24:27 -0400 Message-ID: <9707171324.aa12727@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4208 --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-02.txt Pages : 9 Date : 07/16/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-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-unicast-aggr-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-unicast-aggr-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: <19970716171112.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-unicast-aggr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-unicast-aggr-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970716171112.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 Thu Jul 17 12:32:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA29733; Thu, 17 Jul 1997 12:02:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA29713; Thu, 17 Jul 1997 12:02:24 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08503; Thu, 17 Jul 1997 12:04:33 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA09489 for ; Thu, 17 Jul 1997 12:05:45 -0700 Received: from ietf.ietf.org by ietf.org id aa12643; 17 Jul 97 13: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 4118) I-D ACTION:draft-ietf-ipngwg-multicast-assgn-04.txt Date: Thu, 17 Jul 1997 13:24:10 -0400 Message-ID: <9707171324.aa12643@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4418 --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-04.txt Pages : 8 Date : 07/16/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 ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses. 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-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-multicast-assgn-04.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-04.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: <19970716170310.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-multicast-assgn-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-multicast-assgn-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970716170310.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 Thu Jul 17 16:44:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00418; Thu, 17 Jul 1997 16:30:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00411; Thu, 17 Jul 1997 16:29:33 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA12673; Thu, 17 Jul 1997 16:31:37 -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 QAA03907 for ; Thu, 17 Jul 1997 16:32:48 -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 QAA12133 for ; Thu, 17 Jul 1997 16:31:35 -0700 Message-Id: <3.0.3.32.19970717162357.006e0b60@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 17 Jul 1997 16:23:57 -0700 To: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org (by way of Bob Hinden ) Subject: (IPng 4122) I-D ACTION:draft-ietf-ipngwg-addr-arch-v2-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3323 A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-02.txt Pages : 25 Date : 07/16/1997 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 node's required addresses. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-addr-arch-v2-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-addr-arch-v2-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-addr-arch-v2-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. Content-Type: text/plain Content-ID: <19970716170034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v2-02.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 Jul 18 06:46:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA00947; Fri, 18 Jul 1997 06:37:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA00940; Fri, 18 Jul 1997 06:37:22 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA02388; Fri, 18 Jul 1997 06:39:34 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA10350 for ; Fri, 18 Jul 1997 06:40:47 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA08707; Fri, 18 Jul 1997 09:34:58 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA28553; Fri, 18 Jul 1997 09:34:54 -0400 Message-Id: <9707181334.AA28553@wasted.zk3.dec.com> To: David Borman Cc: bound@zk3.dec.com, crawdad@fnal.gov, ipng@sunroof.eng.sun.com, matt.thomas@altavista-software.com, richdr@microsoft.com Subject: (IPng 4123) Re: UDP pseudo-header In-Reply-To: Your message of "Mon, 14 Jul 1997 11:20:41 EST." <199707141620.LAA09776@frantic.BSDI.COM> Date: Fri, 18 Jul 1997 09:34:54 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5416 >> >RFC 2147 specifies how to use UDP with jumbograms; iff the UDP >> >length is in excess of 65535, the UDP length is set to zero and >> >the computed length is used in the pseudo-header and as the >> >length of the UDP packet. For packets less 65536 bytes in length, >> >the UDP length is the length to use in the pseudo-header. >> >> What counts for less-than 65K is what RFC 1883 says and its predecessor >> not RFC 2147. > >Yes, that is what I said. RFC 2147 applies if and only if the UDP >length equals or exceeds 64K. I thought so!!! >> I suggest we nail this down cause it seems screwed up. >> I for one think Matt Thomas has the correct vision here. >> >> /jim >No, Matt said: Well I am not sure I agree with your "NO". But lets see if I can parse it. Because of jumbograms, you have use the payload header from the IPv6 header or the Hop-by-Hop header. The UDP header's length is "merely" additional data to the checksum operation. >and this is incorrect. It implies that because of jumbograms, you That is what I was agreeing with in my mail. So I don't know what "NO" above means. But anyway............ >have to ignore the UDP length. RFC 2147 was written to address >jumbograms, so they are not at issue. Taking this statement to its >logical conclusion, it says that if the computed length exceedes the >explicit length in the UDP header, that you ignore the explicit UDP >length, even though it is "closer" to the data and most likely the >correct value. I just don't buy that, and I think you'll have a >very tough time finding anyone who was around when RFC 793 was >written to back up that viewpoint. So if the computed_length is greater than the UDP length in header ignore the explicit length... Thats wrong and I agree with you. I think anyway you stretch the context above for processing the chksum and extrapolate it to a new behavior for RFC 768. I did not do that in my mind. I was only wanting to make very sure we all agreed on the lengths and the implementation behavior. >The only issue is that if the computed length does not match >the UDP length, do you drop the packet? If the computed length >is less than the UDP length, then yes, you have to drop it because >you don't have all the data. If the computed length exceeds the >UDP length, do you trim the excess data, or drop the packet? >Being liberal in what you accept would say you trim the IP packet >to fit the UDP length. Then, what length do you put into the >pseudo-header? RFC 793 says: I have no use for that cliche and think it should be stricken from IETF discussions I don't buy it at all. The pseudo header conceptually prefixed to the UDP header contains the source address, the destination address, the protocol, and the UDP length. This does not support rearranging your mbufs (bsd type) and possibly carrying extra pointers and I think its a stretch again to say RFC 768 supports trimming the packets. Especially if I am in a real time or QOS application. If the lengths don't match drop the packet. >"UDP length" sounds to me a lot like "the length in the UDP header", >not "the computed length from the IP header" (as opposed to the TCP >specificiation, which explicitly states that the TCP length is a >computed value, since it is not a transmitted value). Errr... UDP length is the length of the data in UDP. Thats all I am addressing. >But the real issue is that the computed length should always equal >the length in the UDP header, I can't think of any valid reason >for generating an IP/UDP (v4 or v6) packet in which the two lengths >don't match. So, we're arguing a strictly academic issue. And >for that case, the UDP length is used in the pseudo-header, not >the computed length. If the computed length exceeds the UDP >length, you trim the IP packet to fit the UDP length. If the >computed length is less than the UDP length, you drop the packet >because you don't have enough data. I don't agree. >Now, I have no problems with saying that you drop any UDP packet >in which the computed length does not equal the UDP length. But >that is not currently in any spec. There is also nothing in >any spec about ignoring the UDP length, except for RFC 2147 which >allows it to be ignored for jumbograms. Also, any changes to >how the UDP length and the computed length interact should apply >to both IPv4/UDP and IPv6/UDP. If you can't apply it to UDP/IPv4, >then you shouldn't apply it to IPv6/UDP. I don't agree. IPv6 is the New Internet Protocol and being one who has been here since the beginning I won't give you a cliche but an axiom that I keep in my head as an engineer and as an architect when working on IPv6. Vint Cerf said it at Amsterdam meeting. We must keep "cost" in mind when engineering IPng. We can afford the cost to do what we need with IPv6. But we have to be very careful what we back-peddle to IPv4 if the cost is great. Its not just the changes to the implementations but the cost of interoperability for IPv4. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 14:14:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01295; Fri, 18 Jul 1997 14:04:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA01288; Fri, 18 Jul 1997 14:04:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA21316; Fri, 18 Jul 1997 14:06:49 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA28353 for ; Fri, 18 Jul 1997 14:08:01 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id QAA09587; Fri, 18 Jul 1997 16:06:40 -0500 Message-Id: <199707182106.QAA09587@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4124) dotting the t's and crossing the eyes. Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=mimeprimaryboundary Date: Fri, 18 Jul 1997 16:06:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1475 > THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain If any one has remaining comments on IPv6 over Ethernet and IPv6 over FDDI, please send them to me and/or the list very soon. I'm just fixing the last known typos and regularizing the language, relative to the -01 versions that came out earlier this month. The -02 should be the last. Hagvy jr punatr gur nqqerff nepuvgrpgher ntnva. :-) Matt --mimeprimaryboundary Content-Type: message/external-body; access-type="anon-ftp"; site="ds.internic.net"; directory="internet-drafts"; name="draft-ietf-ipngwg-trans-ethernet-01.txt" Content-Description: IPv6 over Ethernet Content-Type: text/plain --mimeprimaryboundary Content-Type: message/external-body; access-type="anon-ftp"; site="ds.internic.net"; directory="internet-drafts"; name="draft-ietf-ipngwg-trans-fddi-net-01.txt" Content-Description: IPv6 over FDDI Content-Type: text/plain --mimeprimaryboundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 18 15:27:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA01423; Fri, 18 Jul 1997 15:18:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA01416; Fri, 18 Jul 1997 15:17:54 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA07714; Fri, 18 Jul 1997 15:20:06 -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 PAA17926 for ; Fri, 18 Jul 1997 15:21:20 -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 PAA28809 for ; Fri, 18 Jul 1997 15:20:06 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jul 1997 15:20:02 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 4125) Re: UDP pseudo-header Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4180 At 4:35 PM -0700 7/9/97, Richard Draves wrote: > There's a small ambiguity in RFC 1883's description of the IPv6 pseudo- > header, and in particular the Payload Length field. (See section 8.1.) Yes. It's all UDP's fault. UDP is the only pseudo-header-using transport protocol that has a length field in its own header. (TCP and ICMPv6 do not.) I was mostly thinking generically when I wrote the guilty part of section 8.1 and I forgot about UDP's specialness in this respect. [I've long thought it was a "bug" that the UDP header has a length field, in that: (a) there is no need for UDP to accommodate IP-layer padding beyond the transport data, given that IP must be capable of sending payloads unpadded (TCP and ICMP, for example, rely on that capability), and (b) the (therefore) redundant UDP length field just degrades performance unnecessarily (the extra cycles required to compare it against the IP-derived length) and creates the potential for ambiguities like the one identified by Richard. ] Regarding which length to use in the UDP pseudo-header -- the value from the UDP Length field or the length derived from the IP layer -- there are reasonable arguments to support either one. Here are some arguments in favor of using the UDP Length field: (1) That's what the UDP spec (RFC 768) says to do. (2) Given that it is the sending UDP layer that computes the UDP checksum, it seems unreasonable for it to use any length other than than the length it is trying to send. If the IP layer is gratuitously adding padding, the sending UDP might not be aware of that. Here are some arguments in favor of using the IP-derived length: (1) The whole purpose of the pseudo-header is to include, in the transport-layer checksum, information from the IP layer. Therefore, the Length field in the pseudo-header must (?) be intended to hold the IP-derived length. (2) The UDP Length field is already included in the checksum, along with the rest of the UDP header, so it would be redundant to also include it in the pseudo-header. Therefore, the Length field in the pseudo-header must (?) be intended to hold the IP-derived length. (3) Using the IP-derived length in the pseudo-header would be consistent with the other transports; that consistency might have a benefit in terms of code sharing. (On the other hand, we already have an inconsistency between UDP and the others, in that the UDP case requires conversion of a zero checksum result to FFFF, while the other transports do not.) (4) We have to use the IP-derived length in the jumbogram case anyway, so for consistency we might as well use the IP-derived length in all cases. I acknowledge that this is a largely academic discussion, in that it is unncessary and extremely unusual for the UDP Length and the IP-derived length to differ. If I were still an academic, my preferred solution would be to eliminate the Length field from the UDP header (i.e., set it to zero and declare it Reserved) and always use the IP-derived length, when using UDP over IPv6. However, no longer being an academic, I propose that we adopt the rules that Dave Borman advocates: it is the UDP Length that is used in the UDP pseudo-header, except in the jumbogram case. That is, IP-layer padding of non-jumbogram UDP packets shall be tolerated, and any such padding bytes shall be ignored by the receiving UDP. This approach would appear to maximize flexibility and the probability of successful communication. And given that we already have to special-case the UDP checksum code to handle the zero->FFFF conversion, this seems unlikely to add significant new unpleasantness to implementations. Comments? 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 Jul 18 16:12:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA01470; Fri, 18 Jul 1997 15:53:51 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA01463; Fri, 18 Jul 1997 15:53:41 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA10418; Fri, 18 Jul 1997 15:55:53 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05370; Fri, 18 Jul 1997 15:55:53 -0700 Date: Fri, 18 Jul 1997 15:55:53 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707182255.PAA05370@bobo.eng.sun.com> To: ipv6imp@munnari.OZ.AU Subject: (IPng 4126) SIOC* ioctls for IPv6? Cc: ipng@sunroof.eng.sun.com, nordmark@jurassic MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2590 Please only reply to ipv6imp@munnari.OZ.AU to reduce duplicate mail. We're working on polishing our prototype code and we've run into to our IPv6 specific SIOC* ioctls. I think it would make sense to get some from of agreement among Unix vendors for these ioctls so that common code (named, sendmail, xntpd) can be more easily ported between Unix platforms. These types of daemons often issue SIOCGIFCONF, SIOCGIFADDR, SIOCGIFFLAGS, SIOCGIFMASK to determine what IP addresses and/or subnets are assigned to the machine. Also, when cleaning this up it seems to me that the end result would be a lot cleaner if the new ioctls are not IPv6 specific but instead are just capable of carrying larger addresses and can be used for both IPv4 and IPv6. Do folks agree that we should try to agree on and write down the key set of interface and address ioctls? Is anybody is interested in leading and/or contributing to such an effort? Below is a straw man for stimulating some discussion. Erik ---- Some of our stawman ideas (which we are not particularely wedded to at the moment) is to define a new "large ifreq" structure (a struct lifreq) that would carry a sockaddr larger than 16 bytes. Since there isn't a "large" sockaddr structure defined I think it would make sense to define such a beast for the sole purpose of having something to put in the lifreq. Applications would actually cast this "large" sockaddr structure to a sockaddr_in/sockaddr_in6 etc depending on the address famility. With a lifreq in hand we can then define a whole new set of ioctls that operate on the lifreq instead of an ifreq. For consistency I think it makes sense to do this for all SIOC* ioctls that currently operate on an ifreq structure so that somethime down the road we will not need the ifreq structure any more. Note that this includes SIOC* ioctls that do not need any IP addresses such as those that get and set the interface MTU etc. We propose that the new ioctls be named consistenly by taking the existing set and changing "IF" to "LIF". For example: Old ifreq ioctl New lifreq ioctl SIOCGIFADDR SIOCGLIFADDR SIOCSIFADDR SIOCSLIFADDR SIOCGIFFLAGS SIOCGLIFFLAGS SIOCSIFFLAGS SIOCSLIFFLAGS -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 18 16:29:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01635; Fri, 18 Jul 1997 16:20:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01628; Fri, 18 Jul 1997 16:19:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA19766; Fri, 18 Jul 1997 16:22:07 -0700 Received: from stb.info.com ([208.254.35.231]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA03005 for ; Fri, 18 Jul 1997 16:22:59 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0wpMKa-000ZHaC; Fri, 18 Jul 97 16:21 PDT Message-Id: Date: Fri, 18 Jul 97 16:21 PDT From: Michael Gersten Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: ipng@sunroof.eng.sun.com, naipr@arin.net Subject: (IPng 4127) An idea to bounce off people: storing routing info in the DNS instead of the routers. Reply-To: michael@stb.info.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3488 Here's an idea that I wanted to bounce off people, a way to extend IPv4, reduce the size of the routing tables used by the routers, enable /31's to be published (are /32's even legal? If so, them too), and solve the complaint that people have of only ARIN issuing IP numbers (with no clear idea of what numbers or what criteria) by allowing anyone with extra IP's to act as an assigner of IP's. The general assumptions are: 1. CIDR table reduction is blocked by non-collapsable entries (I.e, there's a lot of different published routes going through each backbone provider, which can never be collapsed without major renumbering) 2. Multihomed network entries are not a large component of the routing tables (A multihomed network: Any backbone that connects to two or more interconnection points, or any ISP that connects to two or more backbones, or any network that connects to two or more ISPs), 3. A new version of VJ-header compression can be written to deal with loose source routes in the headers (on the assumption that 99% of the loose source routes will be the same as the last one, just like the current assumption that 99% of the packets will go to the same place as the last packet), 4. Routers either (A) do not mind loose source routes in packets going through them, or (B) can have their software modified so that loose source routes, if "unchanged" (see 3 above), are essentially the same as destination addresses, 5. People will (can be forced to) update their DNS entries if the alternative is no packets will reach them (for the average dialup user this is a do-nothing -- their ISP will update the ISP's DNS entries if the ISP changes its backbone provider), 6. Someone else can solve the DNS security issues (:-) 7. All "major" routers -- those used by sprint, MCI, etc, can get software updates within about 6 months or less, 8. (The Big One): IP v4 has a router redirect message that can specify a loose source route to use, not just a single host to use, and that most vendor's ship an IP stack that accepts this message correctly, 9. Adding a new DNS RR to the v4 DNS isn't difficult (will live in the in-addr.arpa domain, just like the PTR record does now) Before I send off the idea, I wanted to get people's comments on these assumptions, especially #8. (Some of you may already see what I'm saying here). Note on #6: Right now I can find rfc's describing RIP, and how routing used to work in the internet. I know that things are not the same as they used to be, and that there's a lot of security in the routing protocols now, but I do not know which rfc's describe the current situation. I also understand that the DNS system can be easily lied to, so security is a real concern on this. Michael p.s. I apologize if these are not the appropriate lists; they are the most appropriate ones I know of. -- Michael Gersten michael@stb.info.com http://www.stb.info.com/~michael NeXT Registered Developer (NeRD) # 3860 Without Prejudice, UCC 1-207 ** HIRE ME: http://www.stb.info.com/~michael/work/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 18 16:47:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01673; Fri, 18 Jul 1997 16:33:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01666; Fri, 18 Jul 1997 16:33:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA21719; Fri, 18 Jul 1997 16:35:43 -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 QAA05593 for ; Fri, 18 Jul 1997 16:36:51 -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 QAA04568; Fri, 18 Jul 1997 16:35:17 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id QAA05876; Fri, 18 Jul 1997 16:35:17 -0700 (MST) Message-Id: <199707182335.QAA05876@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Fri, 18 Jul 1997 16:35:16 -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: Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 4128) Re: UDP pseudo-header Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1254 [In your message of Jul 18, 3:20pm you write:] > > [I've long thought it was a "bug" that the UDP header has a length field, > in that: Does anyone know *why* the length field was added to the UDP header. I've asked around, and have never gotten an authoritative answer. > I acknowledge that this is a largely academic discussion, in that it is > unncessary and extremely unusual for the UDP Length and the IP-derived > length to differ. >From "netstat -s" on a system that has been up for a while: udp: 31447198 datagrams received 0 with incomplete header 9 with bad data length field 58 with bad checksum 665319 with no checksum These 9 are when the UDP length is greater than the IP length. The cases where the UDP length is less than the IP length are not counted--the excess bytes are just discarded. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 16:51:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01686; Fri, 18 Jul 1997 16:36:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01679; Fri, 18 Jul 1997 16:36:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA22272; Fri, 18 Jul 1997 16:38:26 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA06185 for ; Fri, 18 Jul 1997 16:39:40 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49) id <3ZMSDJK8>; Fri, 18 Jul 1997 16:41:06 -0700 Message-ID: From: Richard Draves To: "'Dimitry Haskin'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4129) RE: ND question Date: Fri, 18 Jul 1997 16:38:04 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1384 >>>>If the anycast address is not specific to a link, wouldn't you just >>>>assign it to every interface of the node? >>> >>>For one it may not be practical if a manual configuration is involved. It doesn't matter how the node's implementation or configuration work internally. As long as the externally-visible effect is the same as having the anycast address assigned to every interface, the implementation can deal with it in some easier-to-configure manner. >Generally speaking I don't have to. My question was if there is any killer >problem to proxy for a different interface address on the same node. If >there is none, it should not be prohibited and someone may very well find >use for it. OK. When you put it that way, it sounds like you just want to relax the first sentence of section 7.2.8. Replace "Under limited circumstances, a router MAY proxy for one or more other nodes, ..." with something like "Under limited circumstances, an interface MAY proxy for another interface, ..." Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 17:05:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01707; Fri, 18 Jul 1997 16:52:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA01700; Fri, 18 Jul 1997 16:51:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA25279; Fri, 18 Jul 1997 16:54: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 QAA09407 for ; Fri, 18 Jul 1997 16:55:12 -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 QAA05198; Fri, 18 Jul 1997 16:53:53 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <199707182335.QAA05876@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 18 Jul 1997 16:53:49 -0700 To: "W. Richard Stevens" From: Steve Deering Subject: (IPng 4130) Re: UDP pseudo-header Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1075 > >From "netstat -s" on a system that has been up for a while: > > udp: > 31447198 datagrams received > 0 with incomplete header > 9 with bad data length field > 58 with bad checksum > 665319 with no checksum > > These 9 are when the UDP length is greater than the IP length. The cases > where the UDP length is less than the IP length are not counted--the excess > bytes are just discarded. The 58 checksum failures suggests the occurrence of occasional packet corruption; perhaps the 9 erroneous lengths are the result of corruption of the UDP length in transit -- the UDP length is usually sanity-checked before verifying the checksum. 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 Jul 18 17:52:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01955; Fri, 18 Jul 1997 17:44:09 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01948; Fri, 18 Jul 1997 17:43:59 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA26285; Fri, 18 Jul 1997 17:46:12 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA05451; Fri, 18 Jul 1997 17:46:12 -0700 Date: Fri, 18 Jul 1997 17:46:12 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707190046.RAA05451@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4131) SIOC* ioctls for IPv6? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3392 Trying once more since the last one didn't make it outside Sun. Erik ----- Begin Included Message ----- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 16:27:30 1997 Date: Fri, 18 Jul 1997 15:55:53 -0700 From: nordmark@jurassic (Erik Nordmark) To: ipv6imp@munnari.OZ.AU Subject: (IPng 4126) SIOC* ioctls for IPv6? Cc: ipng@sunroof.eng.sun.com, nordmark@jurassic MIME-Version: 1.0 Please only reply to ipv6imp@munnari.OZ.AU to reduce duplicate mail. We're working on polishing our prototype code and we've run into to our IPv6 specific SIOC* ioctls. I think it would make sense to get some from of agreement among Unix vendors for these ioctls so that common code (named, sendmail, xntpd) can be more easily ported between Unix platforms. These types of daemons often issue SIOCGIFCONF, SIOCGIFADDR, SIOCGIFFLAGS, SIOCGIFMASK to determine what IP addresses and/or subnets are assigned to the machine. Also, when cleaning this up it seems to me that the end result would be a lot cleaner if the new ioctls are not IPv6 specific but instead are just capable of carrying larger addresses and can be used for both IPv4 and IPv6. Do folks agree that we should try to agree on and write down the key set of interface and address ioctls? Is anybody is interested in leading and/or contributing to such an effort? Below is a straw man for stimulating some discussion. Erik ---- Some of our stawman ideas (which we are not particularely wedded to at the moment) is to define a new "large ifreq" structure (a struct lifreq) that would carry a sockaddr larger than 16 bytes. Since there isn't a "large" sockaddr structure defined I think it would make sense to define such a beast for the sole purpose of having something to put in the lifreq. Applications would actually cast this "large" sockaddr structure to a sockaddr_in/sockaddr_in6 etc depending on the address famility. With a lifreq in hand we can then define a whole new set of ioctls that operate on the lifreq instead of an ifreq. For consistency I think it makes sense to do this for all SIOC* ioctls that currently operate on an ifreq structure so that somethime down the road we will not need the ifreq structure any more. Note that this includes SIOC* ioctls that do not need any IP addresses such as those that get and set the interface MTU etc. We propose that the new ioctls be named consistenly by taking the existing set and changing "IF" to "LIF". For example: Old ifreq ioctl New lifreq ioctl SIOCGIFADDR SIOCGLIFADDR SIOCSIFADDR SIOCSLIFADDR SIOCGIFFLAGS SIOCGLIFFLAGS SIOCSIFFLAGS SIOCSLIFFLAGS -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ----- End Included Message ----- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 18:57:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA02095; Fri, 18 Jul 1997 18:49:48 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA02088; Fri, 18 Jul 1997 18:49:44 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA01921; Fri, 18 Jul 1997 18:51:57 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA28823; Fri, 18 Jul 1997 18:50:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA02073; Fri, 18 Jul 1997 18:46:09 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA11369; Fri, 18 Jul 1997 18:48:20 -0700 Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id SAA00918 for ; Fri, 18 Jul 1997 18:49:36 -0700 Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id UAA14333; Fri, 18 Jul 1997 20:48:17 -0500 (CDT) Received: from kcx-ks3-11.ix.netcom.com(204.30.70.107) by dfw-ix16.ix.netcom.com via smap (V1.3) id sma014323; Fri Jul 18 20:48:11 1997 Message-ID: <33CFC64B.2171@ix.netcom.com> Date: Fri, 18 Jul 1997 20:38:51 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: michael@STB.INFO.COM CC: ipng@sunroof.eng.sun.com, naipr@arin.net Subject: (IPng 4133) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4386 Michael, Michael Gersten wrote: > > Here's an idea that I wanted to bounce off people, a way to extend > IPv4, reduce the size of the routing tables used by the routers, > enable /31's to be published (are /32's even legal? If so, them too), > and solve the complaint that people have of only ARIN issuing IP > numbers (with no clear idea of what numbers or what criteria) by > allowing anyone with extra IP's to act as an assigner of IP's. > > The general assumptions are: > 1. CIDR table reduction is blocked by non-collapsable entries (I.e, > there's a lot of different published routes going through each > backbone provider, which can never be collapsed without major > renumbering) > 2. Multihomed network entries are not a large component of the > routing tables (A multihomed network: Any backbone that connects > to two or more interconnection points, or any ISP that connects to > two or more backbones, or any network that connects to two or > more ISPs), > 3. A new version of VJ-header compression can be written to deal > with loose source routes in the headers (on the assumption that 99% > of the loose source routes will be the same as the last one, just like > the current assumption that 99% of the packets will go to the same > place as the last packet), > 4. Routers either (A) do not mind loose source routes in packets > going through them, or (B) can have their software modified so that > loose source routes, if "unchanged" (see 3 above), are essentially the > same as destination addresses, > 5. People will (can be forced to) update their DNS entries if the > alternative is no packets will reach them (for the average dialup user > this is a do-nothing -- their ISP will update the ISP's DNS entries if > the ISP changes its backbone provider), > 6. Someone else can solve the DNS security issues (:-) > 7. All "major" routers -- those used by sprint, MCI, etc, can get > software updates within about 6 months or less, > 8. (The Big One): IP v4 has a router redirect message that can > specify a loose source route to use, not just a single host to use, and > that most vendor's ship an IP stack that accepts this message > correctly, > 9. Adding a new DNS RR to the v4 DNS isn't difficult (will live in the > in-addr.arpa domain, just like the PTR record does now) > > Before I send off the idea, I wanted to get people's comments on > these assumptions, especially #8. (Some of you may already see > what I'm saying here). > > Note on #6: Right now I can find rfc's describing RIP, and how > routing used to work in the internet. I know that things are not the > same as they used to be, and that there's a lot of security in the > routing protocols now, but I do not know which rfc's describe the > current situation. I also understand that the DNS system can be > easily lied to, so security is a real concern on this. This seems to be a very workable idea. I think the RFC's you are looking for are RFC 2050 and RFC 1918 and Rfc 1917. (Sorry to all the "ands") >;) As to you concern reguarding regarding #8, I don't see this as a major concern right now. Should be possibility at least. Question: Have you considered submitting this to the ARIN folks through channels or Ripe perhaps? Might be worth a shot. Over all I like this suggestion. Solves alot of problems possibly and takes the political aspect and put's it on the back burner. But it might not fly with the InterNic/IANA/ARIN folks for just that reason. > > Michael > p.s. I apologize if these are not the appropriate lists; they are the > most appropriate ones I know of. > -- > Michael Gersten michael@stb.info.com http://www.stb.info.com/~michael > NeXT Registered Developer (NeRD) # 3860 > Without Prejudice, UCC 1-207 > ** HIRE ME: http://www.stb.info.com/~michael/work/ Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 18 19:40:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02120; Fri, 18 Jul 1997 19:32:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02113; Fri, 18 Jul 1997 19:31:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA17754; Fri, 18 Jul 1997 19:34:06 -0700 Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA09622 for ; Fri, 18 Jul 1997 19:35:19 -0700 Received: from rodan.UU.NET by relay4.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQcyus01174; Fri, 18 Jul 1997 22:33:54 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQcyus11904; Fri, 18 Jul 1997 22:33:52 -0400 (EDT) Message-Id: To: Jeff Williams cc: michael@STB.INFO.COM, ipng@sunroof.eng.sun.com, naipr@arin.net, mo@UU.NET Subject: (IPng 4134) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. In-reply-to: Your message of "Fri, 18 Jul 1997 20:38:51 BST." <33CFC64B.2171@ix.netcom.com> Date: Fri, 18 Jul 1997 22:33:51 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 493 having a stack believe a redirect with loose source route is an engraved invitation to wholesale hijacking -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 Fri Jul 18 20:08:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA02165; Fri, 18 Jul 1997 20:00:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA02158; Fri, 18 Jul 1997 20:00:44 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA21440; Fri, 18 Jul 1997 20:02:56 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA14790 for ; Fri, 18 Jul 1997 20:04:09 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-26) id ; Fri, 18 Jul 1997 19:58:54 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199707190258.AA24955@zephyr.isi.edu> Subject: (IPng 4135) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. To: mo@uu.net (Mike O'Dell) Date: Fri, 18 Jul 1997 19:58:54 -0700 (PDT) Cc: jwkckid1@ix.netcom.com, michael@stb.info.com, ipng@sunroof.eng.sun.com, naipr@arin.net, mo@uu.net In-Reply-To: from "Mike O'Dell" at Jul 18, 97 10:33:51 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 883 > > having a stack believe a redirect with loose source route > is an engraved invitation to wholesale hijacking > > -mo But, given the vastly improved, civil and ethical behaviour brought on by the commercialization of the Internet, this could not possibly be a valid concern... [* for the clueless * This is not a serious reply. Humour is the intended focus of this reply. If you take the above statement out of context, you are clearly asking for trouble. Just don't do it. *] --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jul 19 09:52:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02512; Sat, 19 Jul 1997 09:45:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02505; Sat, 19 Jul 1997 09:44:50 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA16396; Sat, 19 Jul 1997 09:47:03 -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 JAA04039; Sat, 19 Jul 1997 09:48:16 -0700 Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA31004; Sat, 19 Jul 1997 12:42:05 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA21743; Sat, 19 Jul 1997 12:41:54 -0400 Message-Id: <9707191641.AA21743@wasted.zk3.dec.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipv6imp@munnari.OZ.AU, ipng@sunroof.eng.sun.com Subject: (IPng 4137) Re: [IPv6Imp] SIOC* ioctls for IPv6? In-Reply-To: Your message of "Fri, 18 Jul 1997 15:55:53 MST." <199707182255.PAA05370@bobo.eng.sun.com> Date: Sat, 19 Jul 1997 12:41:54 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1157 Erik, I would think this makes sense except for worrying about anything but IPv6. I am going to discuss this with my IPv6 colleagues at Digital. We have a lot of code for IPv6 and I don't mind rewriting IOCTLs per se but I would like to propose different names too. I mean none of us want to rewrite them. It is really very busy. But I think IPv6 apps will take more inherent knowledge of the parts you speak of and seems like a good idea but we don't need any more code deliverables before the bake off or the IETF. I don't want this as part of the API specs though is my input. I don't view this as an IETF problem but an implementor problem, unless the IETF would like to change their posture on APIs. Not sure why you cc'd ipng list but I did cause you did? /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 Sat Jul 19 11:42:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02565; Sat, 19 Jul 1997 11:34:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA02558; Sat, 19 Jul 1997 11:34:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA21800; Sat, 19 Jul 1997 11:36:41 -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 LAA14598 for ; Sat, 19 Jul 1997 11:37:57 -0700 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id LAA01901; Sat, 19 Jul 1997 11:36:38 -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 LAA00759; Sat, 19 Jul 1997 11:34:32 -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 LAA05180; Sat, 19 Jul 1997 11:34:45 -0700 (PDT) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id LAA01072; Sat, 19 Jul 1997 11:36:41 -0700 (PDT) Date: Sat, 19 Jul 1997 11:36:41 -0700 (PDT) Message-Id: <199707191836.LAA01072@lookout.nsd.3com.com> To: michael@stb.info.com Cc: ipng@sunroof.eng.sun.com, naipr@arin.net Subject: (IPng 4138) An idea to bounce off people: storing routing info in the DNS instead of the routers. In-Reply-To: References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1054 I had proposed something within 3com in a NAT discussion. I was suggesting that we can increase the address space by using source routes and DNS. DNS stores a new type of record which returns a 2 hop loose source route to the destination, where first hop is a global IP address of a boundary node of a private intranet and the final hop being the private address of the dest node within the intranet. This essentially extends the address space. Each private site introduces these DNS entries in the global internet. This may work if the DNS is secure. But then this might require small changes to tranport layers and will need changes in existing applications. 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 Sat Jul 19 13:01:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02738; Sat, 19 Jul 1997 12:52:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02731; Sat, 19 Jul 1997 12:52:41 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA25588; Sat, 19 Jul 1997 12:54:52 -0700 Received: from wachusett.altavista-software.com (wachusett.altavista-software.com [205.181.164.11]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA21338 for ; Sat, 19 Jul 1997 12:56:08 -0700 Received: by wachusett.altavista-software.com; (5.65v3.2/1.3/10May95) id AC29624; Sat, 19 Jul 1997 15:54:50 -0400 Message-Id: <3.0.3.32.19970719155315.0076ca50@ranier.altavista-software.com> X-Sender: altapop@ranier.altavista-software.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 19 Jul 1997 15:53:15 -0400 To: Erik.Nordmark@Eng (Erik Nordmark) Received: from 1Cust54.Max3.Boston.MA.MS.UU.NET by wachusett.altavista-software.com (smtpxd); id XA27935 From: Matt Thomas Subject: (IPng 4139) Re: SIOC* ioctls for IPv6? Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199707190046.RAA05451@bobo.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: 1508 The basic API has a SIOCGIFCONF equivalent (which was taken from an early version of the advanced API draft). Richard and I discussed having such things in the advanced API draft and decided against it. I think those ioctls are much too system specific. For instance, now that the prefix (netmask) is "detached" from the address, the use of SIOC?IFNETMASK doesn't make much sense to me. That may more easily done via PF_ROUTE message on some systems. SIOC?IFADDR should really be a form of adding/removing/modifying alias addresses. Then there is the issue of tokens. Does the interface automagically insert the proper token? Do need to do it yourself? Now we need a way of getting it. If an interface is defined, it should be a standard callable interface and not refer to ioctl's at all (or even file descriptors). That's my 2 cents. -- 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 Sat Jul 19 20:47:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA03170; Sat, 19 Jul 1997 20:40:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA03163; Sat, 19 Jul 1997 20:39:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA20839; Sat, 19 Jul 1997 20:42:10 -0700 Received: from neteracy.instructors.net (neteracy.instructors.net [204.57.120.144]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA05344 for ; Sat, 19 Jul 1997 20:43:25 -0700 Received: from ts002d09.col-co.concentric.net [206.83.80.45] (HELO tedr.instructors.net) by neteracy.instructors.net (AltaVista Mail V1.0/1.0 BL18 listener) id 0000_004c_33d1_8a1f_1f36; Sat, 19 Jul 1997 22:46:39 -0500 Received: by localhost with Microsoft MAPI; Sat, 19 Jul 1997 22:41:44 -0500 Message-ID: <01BC9494.EF2FF720.trohling@instructors.net> From: Ted Rohling To: "'Quaizar Vohra'" Cc: "ipng@sunroof.Eng.Sun.COM" Subject: (IPng 4140) RE: An idea to bounce off people: storing routing info in the DNS instead of the routers. Date: Sat, 19 Jul 1997 22:41:43 -0500 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4128 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: 2149 I would hope that nothing like this occurs in my lifetime. Source routing can be used to conveniently "skip around" known firewalls and hit an internal site hard. With NAT, the possibility is limited due to the unknown nature of the internal addresses (so far!!), but a random walk through a site might be fruitful. I also recently received email from site using NAT and obtained various workstations 10. address via the email headers. This was from an company that markets IP security products. Look at this a bit closer before this moves any further. On Saturday, July 19, 1997 1:37 PM, Quaizar Vohra [SMTP:qv@3com.com] wrote: > I had proposed something within 3com in a NAT discussion. > I was > suggesting that we can increase the address space by using > source > routes and DNS. DNS stores a new type of record which > returns a > 2 hop loose source route to the destination, where first > hop is > a global IP address of a boundary node of a private > intranet and > the final hop being the private address of the dest node > within > the intranet. This essentially extends the address space. > Each > private site introduces these DNS entries in the global > internet. > This may work if the DNS is secure. > > But then this might require small changes to tranport > layers and > will need changes in existing applications. > > 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 > ---------------------------------------------------------- > ---------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 20 11:41:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03532; Sun, 20 Jul 1997 11:33:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA03525; Sun, 20 Jul 1997 11:33:12 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA04931; Sun, 20 Jul 1997 11:35:26 -0700 Received: from stb.info.com ([208.254.35.229]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA05321 for ; Sun, 20 Jul 1997 11:36:40 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0wq0ow-000ZHaC; Sun, 20 Jul 97 11:35 PDT Message-Id: Date: Sun, 20 Jul 97 11:35 PDT From: Michael Gersten To: jwkckid1@ix.netcom.com, mo@UU.NET Subject: (IPng 4141) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. Cc: ipng@sunroof.eng.sun.com, michael@STB.INFO.COM, naipr@arin.net Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1544 >having a stack believe a redirect with loose source route >is an engraved invitation to wholesale hijacking > > -mo Lovely. This whole idea is based on a trade-off: routers will spend less time dealing with a routing table, a little more time with the DNS, and most of that will then get sent back to the originating sites. What little does not get sent back will be in the DNS cache. If there's no solution to the redirect security, then that can't go in, and the DNS cache use by the routers becomes a huge problem, and this trade off no longer works. V6 solves the router security problem by requiring a router message to have a TTL of 254. The question is, can v4 handle that as well, or is this now a case of creating IP v5, as an incremental improvement over v4 (really just this one issue). (What's wrong with v6? The whole question of TCP vs TCPv6, only one chance to do v6 right, the compatibility issues, how will v6 routing really happen, etc. With only one chance to implement v6, we want to do it right, and not be pressed for time. This idea of mine should add another 3-5 years, giving v6 a better opportunity to be done right the first time.) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 08:48:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04497; Mon, 21 Jul 1997 08:40:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA04490; Mon, 21 Jul 1997 08:39:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA14430; Mon, 21 Jul 1997 08:42:07 -0700 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA12599 for ; Mon, 21 Jul 1997 08:43:21 -0700 Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Mon Jul 21 11:40:12 EDT 1997 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research; Mon Jul 21 11:40:14 EDT 1997 Received: from zubin (localhost [127.0.0.1]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id LAA29606; Mon, 21 Jul 1997 11:40:09 -0400 (EDT) Message-Id: <199707211540.LAA29606@zubin.dnrc.bell-labs.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Michael Gersten cc: ipng@sunroof.eng.sun.com Subject: (IPng 4144) Re: An idea to bounce off people Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 11:40:09 -0400 From: Zheng Wang Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 16797 Michael, If the purpose of your proposal is to extend the life of IPv4 so that IPv6 can be done properly, I'd like to draw your attention to RFC 1335 (see enclosed) - a proposal I put forward a few years ago. RFC1335 proposed to have a gloabl Internet with overlapping private internets, similar to the telephone networks (with global networks and private exchanges). With the increasing use of firewalls and dynamic address allocation over last a few years, it seems that RFC 1335 fits very well to the current Internet structure. And the deployment can be completely incremental. It seems to me that a two-tier addressing scheme also makes a lot of sense if we assume that IP will be everywhere (in your VCR, TV, light switch, cooker ...) Cheers Zheng --------------------------------------------------------------------------- Zheng Wang Bell Labs Lucent Technologies http://www.bell-labs.com/user/zhwang/ --------------------------------------------------------------------------- Network Working Group Z. Wang Request for Comments: 1335 J. Crowcroft University College London May 1992 A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited. Abstract This RFC presents a solution to problem of address space exhaustion in the Internet. It proposes a two-tier address structure for the Internet. This is an "idea" paper and discussion is strongly encouraged. Introduction Address space exhaustion is one of the most serious and immediate problems that the Internet faces today [1,2]. The current Internet address space is 32-bit. Each Internet address is divided into two parts: a network portion and a host portion. This division corresponds the three primary Internet address classes: Class A, Class B and Class C. Table 1 lists the network number statistics as of April 1992. Total Allocated Allocated (%) Class A 126 48 54% Class B 16383 7006 43% Class C 2097151 40724 2% Table 1: Network Number Statistics (April 1992) If recent trends of exponential growth continue, the network numbers in Class B will soon run out [1,2]. There are over 2 million Class C network numbers and only 2% have been allocated. However, a Class C network number can only accommodate 254 host numbers which is too small for most networks. With the rapid expansion of the Internet and drastic increase in personal computers, the time when the 32-bit address space is exhausted altogether is also not too distant [1-3]. Recently several proposals have been put forward to deal with the Wang & Crowcroft [Page 1] RFC 1335 Two-Tier Address Structure for the Internet May 1992 immediate problem [1-4]. The Supernetting and C-sharp schemes attempt to make the Class C numbers more usable by re-defining the way in which Class C network numbers are classified and assigned [3,4]. Both schemes require modifications to the exterior routing algorithms and global coordination across the Internet may be required for the deployment. The two schemes do not expand the total number of addresses available to the Internet and therefore can only be used as a short-term fix for next two or three years. Schemes have also been put forwarded in which the 32-bit address field is replaced with a field of the same size but with different meaning and the gateways on the boundary re-write the address when the packet crossed the boundary [1,2,5]. Such schemes, however, requires substantial changes to the gateways and the exterior routing algorithm. In this paper, we present an alternative solution to the problem of address space exhaustion. The "Dual Network Addressing (DNA)" scheme proposed here is based on a two-tier address structure and sharing of addresses. It requires no modifications to the exterior routing algorithms and any networks can adopt the scheme individually at any time without affecting other networks. The Scheme The DNA scheme attempts to reduce the waste in using the Internet addresses. A useful analogy to our scheme is the extension system used in the telephone system. Many large organizations usually have extensive private telephone networks for internal use and at the mean time hire a limited number of external lines for communications with the outside world. In such a telephone system, important offices may have direct external lines and telephones in the public areas may be restricted to internal calls only. The majority of the telephones can usually make both internal calls and external calls. But they must share a limited number of external lines. When an external call is being made, a pre-defined digit has to be pressed so that an external line can be allocated from the poll of external lines. In the DNA scheme, there are two types of Internet addresses: Internal addresses and External addresses. An internal address is an Internet address only used within one network and is unique only within that network. An interface with an internal address can only communicate with another interface with an internal address in the same network. An external address is unique in the entire Internet and an interface with an external address can communicate directly to another interface with an external address over the Internet. All current Internet addresses are external addresses. In effect, the external addresses form one global Internet and the Wang & Crowcroft [Page 2] RFC 1335 Two-Tier Address Structure for the Internet May 1992 internal addresses form many private Internets. Within one network, the external addresses are only used for inter-network communications and internal addresses for intra-network communications. An External Address Sharing Service (EASS) is needed to manage the sharing of external addresses. An EASS server reserves a number of external addresses. When a machine that only has an internal address wants to communicate a machine with an external address in other networks, it can send a request to an EASS server to obtain a temporary external address. After the use, the machine can return the external address to the EASS server. We believe that, with the DNA scheme, a network can operate with a limited number of external addresses. The reasons are as follows: * In most networks, the majority of the traffic is confined to its local area networks. This is due the nature of networking applications and the bandwidth constraints on inter-network links. * The number of machines which act as Internet servers, i.e., running programs waiting to be called by machines in other networks, is often limited and certainly much smaller than the total number of machines. These machines include mail servers, domain name servers, ftp archive servers, directory servers, etc. * There are an increasingly large number of personal machines entering the Internet. The use of these machines is primarily limited to their local environment. They may also be used as "clients" such as ftp and telnet to access other machines. * For security reasons, many large organizations, such as banks, government departments, military institution and some companies, may only allow a very limited number of their machines to have access to the global Internet. The majority of their machines are purely for internal use. In the DNA scheme, all machines in a network are assigned a permanent internal address and can communicate with any machines within the same network. The allocation of external addresses depends on the functions of the machines and as a result it creates three-level privileges: * machines which act as servers or used as central computing infrastructure are likely to have frequent communications with other networks therefore they may require external addresses all the time. These machines are allocated Wang & Crowcroft [Page 3] RFC 1335 Two-Tier Address Structure for the Internet May 1992 permanent external addresses. * machines which are not allowed to communicate with other networks have no external addresses and can only communicate with machines within their own network. * the rest of the machines share a number of external addresses. The external addresses are allocated by the EASS server on request. These machines can only used as clients to call machines in other networks, i.e., they can not be called by machines in other networks. A network can choose any network number other than its external network number as its internal network number. Different networks can use the same network number as their internal number. We propose to reserve one Class A network number as the well-known network number for internal use. The Advantages The DNA scheme attempts to tackle the problem from the bottom of the Internet, i.e., each individual network, while other schemes described in the first section deal with the problem from the top of the Internet, i.e., gateways and exterior routing algorithms. These schemes, however, do not need to be consider as mutually exclusive. The DNA scheme has several advantages: * The DNA scheme takes an evolutionary approach towards the changes. Different networks can individually choose to adopt the scheme at any time only when necessary. There is no need for global coordination between different networks for their deployment. The effects of the deployment are confined to the network in which the scheme is being implemented, and are invisible to exterior routing algorithms and external networks. * With the DNA scheme, it is possible for a medium size organization to use a Class C network number with 254 external addresses. The scheme allows the current Internet to expand to over 2 million networks and each network to have more than 16 million hosts. This will allow considerable time for a long-term solution to be developed and fully tested. * The DNA scheme requires modifications to the host software. However, the modifications are needed only in those networks which adopt the DNA scheme. Since all existing Class A and B networks usually have sufficient external addresses for all their machines, they do not need to adopt the DNA scheme, and therefore Wang & Crowcroft [Page 4] RFC 1335 Two-Tier Address Structure for the Internet May 1992 need no modifications at all to their software. The networks which need to use the DNA scheme are those new networks which are set up after the Class A and B numbers run out and have to use a Class C number. * The DNA scheme makes it possible to develop to a new addressing scheme without expanding the 32-bit address length to 64-bit. With the two-tier address structure, the current 32-bit space can accommodate over 4 billion hosts in the global Internet and 100 million hosts in each individual network. When we move to a classless multi-hierarchic addressing scheme, the use of external addresses can be more efficient and less wasteful and the 32-bit space can be adequate for the external addresses. * When a new addressing scheme has been developed, all current Internet addresses have to be changed. The DNA scheme will make such a undertaking much easier and smoother, since only the EASS servers and those have permanent external addresses will be affected, and communications within the network will not be interrupted. The Modifications The major modifications to the host software is in the network interface code. The DNA scheme requires each machine to have at least two addresses. But most of the host software currently does not allow us to bind two addresses to one physical interface. This problem can be solved by using two network interfaces on each machine. But this option is too expensive. Note the two interfaces are actually connected to the same physical network. Therefore, if we modify the interface code to allow two logical interfaces to be mapped onto one single physical interface, the machine can then use both the external address and the internal address with one physical interface as if it has two physical interfaces. In effect, two logical IP networks operate over the same physical network. The DNA scheme also has implications to the DNS service. Many machines will have two entries in the local name server. The DNS server must examine the source address of the request and decide which entry to use. If the source address matches the well-known internal network number, it passes the internal address of the domain name. Otherwise, the name server passes the external address. An EASS server is required to manage the sharing of the external addresses, i.e., to allocate and de-allocate external addresses to the machines which do not have permanent external addresses. This service can be provided by using the "Dynamic Host Configuration Protocol (DHCP)" [6]. Wang & Crowcroft [Page 5] RFC 1335 Two-Tier Address Structure for the Internet May 1992 Many hosts do an inverse lookup of incoming connections. Therefore, it is desirable the entry in the DNS server be updated whenever a new external address is allocated. This will also allow an machine which currently has a temporary external address to be called by other machines. The updating of the entry in the DNS server can be done more easily if the EASS server and DNS server are co-located. Acknowledgements We would like to thank J. K. Reynolds for the network statistics, and V. Cerf, C. Topolcic, K. McCloghrie, R. Ullmann and K. Carlberg for their useful comments and discussion. References [1] Chiappa, N., "The IP Addressing Issue", work in progress, October 1990. [2] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UC Davis, December 1991. [3] Solensky, F., and F. Kastenholz, "A Revision to IP Address Classifications", work in progress, March 1992. [4] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", work in progress, March 1992. [5] Tsuchiya, P., "The IP Network Address Translator", work in progress, March 1991. [6] Droms, R., "Dynamic Host Configuration Protocol", work in progress, March 1992. Wang & Crowcroft [Page 6] RFC 1335 Two-Tier Address Structure for the Internet May 1992 Security Considerations Security issues are not discussed in this memo. Authors' Addresses Zheng Wang Dept. of Computer Science University College London London WC1E 6BT, UK EMail: z.wang@cs.ucl.ac.uk Jon Crowcroft Dept. of Computer Science University College London London WC1E 6BT, UK EMail: j.crowcroft@cs.ucl.ac.uk Wang & Crowcroft [Page 7] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 21 09:13:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04529; Mon, 21 Jul 1997 09:04:58 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04522; Mon, 21 Jul 1997 09:04:54 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA21982; Mon, 21 Jul 1997 09:07:09 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02422; Mon, 21 Jul 1997 09:05:22 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA02196; Fri, 18 Jul 1997 20:15:33 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA22894; Fri, 18 Jul 1997 20:17:45 -0700 Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA17094 for ; Fri, 18 Jul 1997 20:18:58 -0700 Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id WAA21214; Fri, 18 Jul 1997 22:17:03 -0500 (CDT) Received: from kcx-ks13-09.ix.netcom.com(206.214.130.137) by dfw-ix16.ix.netcom.com via smap (V1.3) id sma021190; Fri Jul 18 22:16:32 1997 Message-ID: <33CFDAFF.3DF9@ix.netcom.com> Date: Fri, 18 Jul 1997 22:07:11 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Bill Manning CC: "Mike O'Dell" , michael@stb.info.com, ipng@sunroof.eng.sun.com, naipr@arin.net Subject: (IPng 4145) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. References: <199707190258.AA24955@zephyr.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1159 Bill, Did you read my original reply yet? Bill Manning wrote: > > > > > having a stack believe a redirect with loose source route > > is an engraved invitation to wholesale hijacking > > > > -mo > > But, given the vastly improved, civil and ethical behaviour brought on > by the commercialization of the Internet, this could not possibly be > a valid concern... > > [* for the clueless * This is not a serious reply. Humour is the intended > focus of this reply. If you take the above statement out of context, > you are clearly asking for trouble. Just don't do it. *] > > --bill -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.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 Jul 21 09:35:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04583; Mon, 21 Jul 1997 09:25:25 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04576; Mon, 21 Jul 1997 09:25:20 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24000; Mon, 21 Jul 1997 09:27:35 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02510; Mon, 21 Jul 1997 09:25:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA03578; Sun, 20 Jul 1997 12:19:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA06981; Sun, 20 Jul 1997 12:22:04 -0700 Received: from unir.corp ([207.32.128.74]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA08906 for ; Sun, 20 Jul 1997 12:23:21 -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 OAA18602; Sun, 20 Jul 1997 14:08:41 -0500 (CDT) Received: by webster.unety.net with Microsoft Mail id <01BC9517.C823B120@webster.unety.net>; Sun, 20 Jul 1997 14:18:23 -0500 Message-ID: <01BC9517.C823B120@webster.unety.net> From: Jim Fleming To: "jwkckid1@ix.netcom.com" , "'Michael Gersten'" , "mo@UU.NET" Cc: "ipng@sunroof.Eng.Sun.COM" , "naipr@arin.net" Subject: (IPng 4146) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. Date: Sun, 20 Jul 1997 14:18:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1455 On Sunday, July 20, 1997 1:35 PM, Michael Gersten[SMTP:michael@STB.INFO.COM] wrote: @ >having a stack believe a redirect with loose source route @ >is an engraved invitation to wholesale hijacking @ > @ > -mo @ @ @ (What's wrong with v6? The whole question of TCP vs TCPv6, @ only one chance to do v6 right, the compatibility issues, @ how will v6 routing really happen, etc. With only one chance @ to implement v6, we want to do it right, and not be pressed @ for time. This idea of mine should add another 3-5 years, @ giving v6 a better opportunity to be done right the first time.) @ @ It is my impression that IPv6 is complete, is here, is available and is the protocol of choice for future NSF funding....as well as past funding... It is also my impression that artificial shortages in the IPv4 address space will force companies and ISPs to start using IPv6. This coupled with the NSF funding will make the transition happen very quickly. Is that not the NSF plan ? -- Jim Fleming Unir Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 21 09:41:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04595; Mon, 21 Jul 1997 09:29:42 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04588; Mon, 21 Jul 1997 09:29:36 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24577; Mon, 21 Jul 1997 09:31:51 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02542; Mon, 21 Jul 1997 09:30:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA03608; Sun, 20 Jul 1997 12:49:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08337; Sun, 20 Jul 1997 12:51:35 -0700 Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA11139 for ; Sun, 20 Jul 1997 12:52:52 -0700 Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id OAA20502; Sun, 20 Jul 1997 14:51:27 -0500 (CDT) Received: from kcx-ks12-01.ix.netcom.com(206.214.130.129) by dfw-ix3.ix.netcom.com via smap (V1.3) id sma020491; Sun Jul 20 14:50:58 1997 Message-ID: <33D21585.46D8@ix.netcom.com> Date: Sun, 20 Jul 1997 14:41:25 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Michael Gersten CC: mo@UU.NET, ipng@sunroof.eng.sun.com, naipr@arin.net Subject: (IPng 4147) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2299 Michael, This is the second one of these responses I have gotten. BTW Michael Gersten wrote: > > >having a stack believe a redirect with loose source route > >is an engraved invitation to wholesale hijacking > > > > -mo > > Lovely. > > This whole idea is based on a trade-off: routers will spend > less time dealing with a routing table, a little more time > with the DNS, and most of that will then get sent back to > the originating sites. What little does not get sent back will > be in the DNS cache. > > If there's no solution to the redirect security, then that > can't go in, and the DNS cache use by the routers becomes > a huge problem, and this trade off no longer works. I agree. > > V6 solves the router security problem by requiring a > router message to have a TTL of 254. The question is, > can v4 handle that as well, or is this now a case of > creating IP v5, as an incremental improvement over v4 > (really just this one issue). IMHO if v6 is done properly there should be no problems security wise. I also believe that v4 can handle the TTL of 254 without too much problem either. SO the v6 concern is moot really at this point anyway. Time is also a factor here. > > (What's wrong with v6? The whole question of TCP vs TCPv6, > only one chance to do v6 right, the compatibility issues, > how will v6 routing really happen, etc. With only one chance > to implement v6, we want to do it right, and not be pressed > for time. This idea of mine should add another 3-5 years, > giving v6 a better opportunity to be done right the first time.) I don't think we have 5 or 6 years for v6. In fact 2 years is the outside time factor at the current growing demand for routeable IP demand. Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.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 Jul 21 18:21:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA05945; Mon, 21 Jul 1997 18:12:44 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA05938; Mon, 21 Jul 1997 18:12:34 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA28683; Mon, 21 Jul 1997 18:14:51 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA07780; Mon, 21 Jul 1997 18:14:51 -0700 Date: Mon, 21 Jul 1997 18:14:51 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707220114.SAA07780@bobo.eng.sun.com> To: richdr@microsoft.com Subject: (IPng 4148) Re: ND question 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: 1076 > I am curious why section 6.3.7 of RFC 1970 says in reference to sending > RS messages: "The Source Link-Layer Address option SHOULD be set to the > host's link-layer address, if the IP source address is a unicast > address." Implying that the RS should not carry a Source Link-Layer > Address option if the IP source address is the unspecified address. I > ask because there's no equivalent caveat for NS messages. We're claifying this text and the related text for the use of unspecified address in RS and NS messages to make it clear that the source link-layer address option MUST NOT be sent when the source IP is unspecified and also require this in the message validation rules. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 21 18:38:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA05967; Mon, 21 Jul 1997 18:29:20 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA05960; Mon, 21 Jul 1997 18:29:07 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA00410; Mon, 21 Jul 1997 18:31:24 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA07792; Mon, 21 Jul 1997 18:31:23 -0700 Date: Mon, 21 Jul 1997 18:31:23 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707220131.SAA07792@bobo.eng.sun.com> To: richdr@microsoft.com Subject: (IPng 4149) Re: ND question 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: 686 > So as I read it, 7.2.8 doesn't quite violate the MUST in 7.2.3, > depending on the definition of "address assigned to interface". We're making this more clear by explicitly listing "or a unicast address for which the node is offering proxy services" in the first paragraph on section 7.2.3. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 22 09:03:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06645; Tue, 22 Jul 1997 08:55:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06638; Tue, 22 Jul 1997 08:55:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA14347; Tue, 22 Jul 1997 08:57:16 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA26537 for ; Tue, 22 Jul 1997 08:58:31 -0700 Received: from rtpmail01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA56824; Tue, 22 Jul 1997 11:57:14 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id LAA25334 for ; Tue, 22 Jul 1997 11:57:13 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA24068; Tue, 22 Jul 1997 11:57:12 -0400 Message-Id: <9707221557.AA24068@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4150) Re: security problem: RAs with 0 lifetime prefixes In-Reply-To: Your message of "Fri, 28 Mar 1997 10:16:31 CST." <199703281616.KAA09789@gungnir.fnal.gov> Date: Tue, 22 Jul 1997 11:57:12 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2867 Per the Memphis meeting, I've had on my plate the task of proposing some specfic text that addresses the "0 lifetime" denial-of-service problem in the addrconf document. One message that seemed to have been clear is "keep it simple". Erik Nordmark and I have been exchanging ideas/text for a bit, and here is some specific wording I'm proposing as a strawman. In Section 5.5.3 (Router Advertisement Processing) of the addrconf document, add the following two checks: e) If the prefix advertised matches the prefix of an autoconfigured address (i.e., one obtained previously via stateless or stateful autoconfiguration) in the list of addresses associated with the interface, and the valid lifetime in the received RA is both less than 2 hours and less than the remaining valid Lifetime in the cached entry, ignore the Prefix Information option for the purpose of stateless address autoconfiguration. f) If the prefix advertised matches the prefix of an autoconfigured address (i.e., one obtained previously via stateless or stateful autoconfiguration) in the list of addresses associated with the interface, and the preferred lifetime in the received RA is both less than 2 hours and less than the remaining preferred Lifetime in the cached entry, ignore the Prefix Information option for the purpose of stateless address autoconfiguration. The above rules apply only to addrconf. These rules have no affect on the way the on-link flag is being interpreted. (We will add explicit text to the ND stating this.) The above rules have the following properties: 1) Minor code impact. 2) Bakeoffs & interoperability tests can still use very small Lifetimes (e.g., 10 minutes) to test the timing out of prefixes. One can't *lower* an existing Lieftime, but one can use a small initial value and have things work as expected. 3) Intuitively does the right thing. By that, I mean that if a host boots, and routers are advertising Lifetimes of less than 2 hours, the host will configure such addresses. Other rules that had been under consideration (e.g., ignore all lifetimes less than 2 hours, increase a received value to 2 hours under some circumstances, etc.) might result in recently booted hosts not configuring the same prefixes/Lifetimes as other hosts that had booted longer ago than the 2 hour window. That might lead to sys admin confusion. Unless I hear otherwise, the proposed text will go into the addrconf draft. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 09:16:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08207; Wed, 23 Jul 1997 09:03:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08200; Wed, 23 Jul 1997 09:03:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA17002; Wed, 23 Jul 1997 09:05: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 JAA21391 for ; Wed, 23 Jul 1997 09:06:49 -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 JAA06512 for ; Wed, 23 Jul 1997 09:05:31 -0700 Message-Id: <3.0.3.32.19970723085534.006ab8b4@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 23 Jul 1997 08:55:34 -0700 To: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org (by way of Bob Hinden ) Subject: (IPng 4151) I-D ACTION:draft-stevens-advanced-api-04.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4263 A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Advanced Sockets API for IPv6 Author(s) : W. Stevens, M. Thomas Filename : draft-stevens-advanced-api-04.txt Pages : 69 Date : 07/22/1997 Specifications are in progress for changes to the sockets API to support IP version 6 [RFC-2133]. These changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. But another class of applications exists that will also be run under IPv6. We call these "advanced" applications and today this includes programs such as Ping, Traceroute, routing daemons, multicast routing daemons, router discovery daemons, and the like. The API feature typically used by these programs that make them "advanced" is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge of the packet header formats used by these protocols. To provide portability for applications that use raw sockets under IPv6, some standardization is needed for the advanced API features. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface) and IPv6 extension headers that are not addressed in [RFC-2133]: Hop-by-Hop options, Destination options, and the Routing header (source routing). This document provides API access to these features too. 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-stevens-advanced-api-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-stevens-advanced-api-04.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-stevens-advanced-api-04.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. Content-Type: text/plain Content-ID: <19970722113133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-stevens-advanced-api-04.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 Wed Jul 23 09:17:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08216; Wed, 23 Jul 1997 09:05:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08209; Wed, 23 Jul 1997 09:05:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA17409; Wed, 23 Jul 1997 09:07:21 -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 JAA21979 for ; Wed, 23 Jul 1997 09:08:38 -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 JAA06517; Wed, 23 Jul 1997 09:05:32 -0700 Message-Id: <3.0.3.32.19970723090508.006a9524@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 23 Jul 1997 09:05:08 -0700 To: jburgan@BayNetworks.com From: Bob Hinden Subject: (IPng 4152) Request to Advance "Advanced Sockets API for IPv6" 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: 1001 Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Informational status: Title : Advanced Sockets API for IPv6 Author(s) : W. Stevens, M. Thomas Filename : draft-stevens-advanced-api-04.txt Pages : 69 Date : 07/22/1997 A working group last call for these documents was completed on July 14, 1997. This draft incorporates changes based on comments received during the w.g. 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 09:38:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08274; Wed, 23 Jul 1997 09:28:34 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08267; Wed, 23 Jul 1997 09:28:24 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04168; Wed, 23 Jul 1997 09:30:33 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09502; Wed, 23 Jul 1997 09:30:33 -0700 Date: Wed, 23 Jul 1997 09:30:33 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707231630.JAA09502@bobo.eng.sun.com> To: ipng@sunroof Subject: (IPng 4153) Problem with _res.options in RFC 2133 Cc: nordmark@jurassic, paul@vix.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2588 RFC 2133 (in section 6.1) says that an application can modify the beahvior of gethostbyname and gethostbyname2 when it comes to returning IPv4 and IPv6 addresses by uttering: res_init(); _res.options |= RES_USE_INET6; This is bad for the following three reasons: 1. Programming interfaces that use shared global data between the application and the library are bad; they are hard to evolve as the implementation of the library changes. For instance, should the resolver library's implementation of the _res structure change there has to be great care in not changing the offset of the "options" field in the _res structure to prevent breaking binary compatibility. 2. The interface is specifically tried to the DNS resolver and vendors support more than one name service accessible through gethostbyaname. I understand this is often done through some form of nameservice "switch" that direct gethostbyname() calls to the various name services - the resolver being one such name service. Thus I think it would make sense to have the interface use non-resolver specific names so that it can go through the same level of indirection as gethostbyname and friends. 3. The interface does not allow for multithreaded applications where one one thread wants the RES_USE_INET6 behavior and other thread wants the default behavior of gethostbyname and gethostbyname2. I don't know how important a problem this is. What do other vendors with some re-entrant gethostbyname function think? (Often the re-entrant functions are called e.g. gethostbyname_r.) I have a simple proposal for fixing #1 and #2 but we need to determine if #3 needs to be fixed as well. The proposal is to create a functional interface for toggling the RES_USE_INET6 behavior. (Suggestions for a better name are welcome.) int sethostent_inet6(int on); This could be implemented in the DNS resolver as int sethostent_inet6(int on) { res_init(); if (on) _res.options |= RES_USE_INET6; else _res.options &= ~RES_USE_INET6; } The above routine can then be implemented by the various name services such as the local /etc/hosts file, NIS, NIS+, whatever. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 10:05:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08335; Wed, 23 Jul 1997 09:54:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08328; Wed, 23 Jul 1997 09:54:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA29781; Wed, 23 Jul 1997 09:57:01 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA09119 for ; Wed, 23 Jul 1997 09:58:18 -0700 Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id ; Wed, 23 Jul 1997 09:57:04 -0700 Message-ID: From: Richard Draves To: "'Erik.Nordmark@Eng.Sun.COM'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4154) Re: ND question Date: Wed, 23 Jul 1997 09:56:16 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1657 >We're claifying this text and the related text for the use of >unspecified address in RS and NS messages to make it >clear that the source link-layer address option MUST NOT be >sent when the source IP is unspecified and also require this >in the message validation rules. Why this prohibition? In private email to Thomas I suggested that the recipient of a NS with unspecified source address could potentially take advantage of the source link-layer address option. The recipient is required to send a NA to the all-nodes multicast address. The NA will let the NS-sender know that it is trying to configure a duplicate address. However because the NA is sent to the all-nodes multicast address, it interrupts every other node on the link. If there is a source link-layer address option in the NS, why not send the NA (with IPv6 destination being the all-nodes multicast address) to that link-layer address? This would be strange, because the NA's IP destination address is multicast and the link-layer address is unicast, but the behavior seems well-defined and it would be more efficient for the network. Of course duplicate addresses shouldn't happen often in practice, but one possible scenario is someone who persists in trying to bring up a misconfigured device. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 10:11:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08365; Wed, 23 Jul 1997 09:58:19 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08358; Wed, 23 Jul 1997 09:58:14 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08328; Wed, 23 Jul 1997 10:00:32 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06822; Wed, 23 Jul 1997 09:58:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08337; Wed, 23 Jul 1997 09:56:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA00390; Wed, 23 Jul 1997 09:59:10 -0700 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA09866; Wed, 23 Jul 1997 10:00:28 -0700 Received: from wisdom.rc.vix.com (wisdom.rc.vix.com [204.152.187.1]) by gw.home.vix.com (8.8.6/) via ESMTP id JAA25272; Wed, 23 Jul 1997 09:59:11 -0700 (PDT) env-from (vixie@wisdom.rc.vix.com) Received: by wisdom.rc.vix.com; id JAA15024; Wed, 23 Jul 1997 09:59:11 -0700 Message-Id: <199707231659.JAA15024@wisdom.rc.vix.com> X-Authentication-Warning: wisdom.rc.vix.com: localhost [127.0.0.1] didn't use HELO protocol To: Erik.Nordmark@Eng (Erik Nordmark) cc: ipng@sunroof.eng.sun.com Subject: (IPng 4156) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Wed, 23 Jul 1997 09:30:33 PDT." <199707231630.JAA09502@bobo.eng.sun.com> Date: Wed, 23 Jul 1997 09:59:10 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 459 Agreed. I'd proposed something like this but we clearly didn't do it in time. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 10:36:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08565; Wed, 23 Jul 1997 10:27:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08558; Wed, 23 Jul 1997 10:27:39 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA08515; Wed, 23 Jul 1997 10:29:53 -0700 Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.235]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA20414 for ; Wed, 23 Jul 1997 10:29:41 -0700 Received: from hprt48.ptp.hp.com (daemon@hprt48.ptp.hp.com [15.60.248.9]) by palrel1.hp.com (8.8.5/8.8.5) with ESMTP id KAA19818 for ; Wed, 23 Jul 1997 10:29:41 -0700 (PDT) Received: from localhost by hprt48.ptp.hp.com with SMTP (1.37.109.18/15.5+IOS 3.22) id AA168309001; Wed, 23 Jul 1997 10:30:01 -0700 Message-Id: <199707231730.AA168309001@hprt48.ptp.hp.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4157) Re: Problem with _res.options in RFC 2133 Date: Wed, 23 Jul 1997 10:30:00 -0700 From: Frank Rowand Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1352 Erik.Nordmark@Eng.Sun.COM wrote: > RFC 2133 (in section 6.1) says that an application > can modify the beahvior of gethostbyname and gethostbyname2 > when it comes to returning IPv4 and IPv6 addresses by uttering: > > res_init(); > _res.options |= RES_USE_INET6; > > This is bad for the following three reasons: > 3. The interface does not allow for multithreaded applications where one > one thread wants the RES_USE_INET6 behavior and other thread wants > the default behavior of gethostbyname and gethostbyname2. > I don't know how important a problem this is. What do other vendors > with some re-entrant gethostbyname function think? (Often the > re-entrant functions are called e.g. gethostbyname_r.) > > I have a simple proposal for fixing #1 and #2 but we need to determine > if #3 needs to be fixed as well. Yes, #3 is very important to my customers. Thread safe interfaces are needed. Frank Rowand HP-RT Real Time OS frowand@ptp.hp.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 Jul 23 11:01:29 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08635; Wed, 23 Jul 1997 10:50:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08628; Wed, 23 Jul 1997 10:50:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA15654; Wed, 23 Jul 1997 10:53:03 -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 KAA28865; Wed, 23 Jul 1997 10:53:04 -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 KAA16083; Wed, 23 Jul 1997 10:53:03 -0700 (MST) Received: (from rstevens@localhost) by kohala.kohala.com (8.8.5/8.8.3) id KAA16391; Wed, 23 Jul 1997 10:53:03 -0700 (MST) Message-Id: <199707231753.KAA16391@kohala.kohala.com> From: rstevens@kohala.com (W. Richard Stevens) Date: Wed, 23 Jul 1997 10:53:03 -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: Paul A Vixie , Erik.Nordmark@Eng (Erik Nordmark) Subject: (IPng 4158) Re: Problem with _res.options in RFC 2133 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1091 General question: there are some items in RFC 2133 that should be clarified (e.g., we four authors of the RFC got email last week from The Open Group summarizing some points and questions brought up by their XNET group), and some items to be added (this new function proposed by Erik). Plus some cleanup of datatypes, now that Posix.1g appears final, and the Unix 98 changes that are taken from the final Posix.1g draft. Should we start a new I-D with these clarifications and corrections, so everyone developing or using the RFC can see what needs tweaking? If we ignore it then The Open Group will do something (eventually) but their process seems much more closed to outsiders than the IETF. Rich Stevens -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 11:17:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08680; Wed, 23 Jul 1997 11:04:42 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08673; Wed, 23 Jul 1997 11:04:36 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18250; Wed, 23 Jul 1997 11:06:54 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06944; Wed, 23 Jul 1997 11:05:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA08640; Wed, 23 Jul 1997 10:54:18 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA16672; Wed, 23 Jul 1997 10:56:32 -0700 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA00179; Wed, 23 Jul 1997 10:56:34 -0700 Received: from wisdom.rc.vix.com (wisdom.rc.vix.com [204.152.187.1]) by gw.home.vix.com (8.8.6/) via ESMTP id KAA28452; Wed, 23 Jul 1997 10:56:33 -0700 (PDT) env-from (vixie@wisdom.rc.vix.com) Received: by wisdom.rc.vix.com; id KAA15233; Wed, 23 Jul 1997 10:56:33 -0700 Message-Id: <199707231756.KAA15233@wisdom.rc.vix.com> X-Authentication-Warning: wisdom.rc.vix.com: localhost [127.0.0.1] didn't use HELO protocol To: "W. Richard Stevens" cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4160) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Wed, 23 Jul 1997 10:53:03 PDT." <199707231753.KAA16391@kohala.kohala.com> Date: Wed, 23 Jul 1997 10:56:24 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 429 I vote in favour of a clarified version of 2133. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 23 11:37:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08724; Wed, 23 Jul 1997 11:25:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08717; Wed, 23 Jul 1997 11:25:20 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA25968; Wed, 23 Jul 1997 11:27:30 -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 LAA11392; Wed, 23 Jul 1997 11:27: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 LAA14719; Wed, 23 Jul 1997 11:27:05 -0700 Message-Id: <3.0.3.32.19970723112643.006fa490@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 23 Jul 1997 11:26:43 -0700 To: "W. Richard Stevens" From: Bob Hinden Subject: (IPng 4161) Re: Problem with _res.options in RFC 2133 Cc: Paul A Vixie , Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com In-Reply-To: <199707231753.KAA16391@kohala.kohala.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 807 Rich, >Should we start a new I-D with these clarifications and corrections, >so everyone developing or using the RFC can see what needs tweaking? >If we ignore it then The Open Group will do something (eventually) >but their process seems much more closed to outsiders than the IETF. I think it would be a good idea to start a new I-D with the changes. This is all part of the process of learning from implementations. 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 Jul 23 13:15:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09077; Wed, 23 Jul 1997 13:06:19 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09070; Wed, 23 Jul 1997 13:06:09 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09499; Wed, 23 Jul 1997 13:08:28 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09742; Wed, 23 Jul 1997 13:08:27 -0700 Date: Wed, 23 Jul 1997 13:08:27 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707232008.NAA09742@bobo.eng.sun.com> To: richdr@microsoft.com Subject: (IPng 4162) Re: ND question 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: 2555 > In private email to Thomas I suggested that the recipient of a NS with > unspecified source address could potentially take advantage of the > source link-layer address option. The recipient is required to send a NA > to the all-nodes multicast address. The NA will let the NS-sender know > that it is trying to configure a duplicate address. However because the > NA is sent to the all-nodes multicast address, it interrupts every other > node on the link. If there is a source link-layer address option in the > NS, why not send the NA (with IPv6 destination being the all-nodes > multicast address) to that link-layer address? This would be strange, > because the NA's IP destination address is multicast and the link-layer > address is unicast, but the behavior seems well-defined and it would be > more efficient for the network. Of course duplicate addresses shouldn't > happen often in practice, but one possible scenario is someone who > persists in trying to bring up a misconfigured device. I don't think we can require such behavior of implementations since it would make it harder to build a modular implementation. As defined ND is just ICMP that passes packets down to IP for IP to send. In this case ND would in addition pass along a unicast link-layer address for the packet with a multicast IP address. Furthermore, I don't see much point in optimizing this case. Even if somebody is persistently trying to bring up a node with a duplicate address that wouldn't happen more than once every few seconds (I assuming it is a human being that is making the happen - an implementation should just shut off the use of an address when it detects a duplicate). Finally, I find it an architectural anomaly to send IP multicast packets to a unicast link-layer address. So why is it critical to allow this behavior? I was planning on updating the specification to disallow source link-layer adress options when the source IP address is the unspecified address to simply the receiver (it would just drop such packets). I think this will make the protocol ever so slightly easier to implement and remove one potential source of interoperability problems. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 13:37:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09122; Wed, 23 Jul 1997 13:28:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09115; Wed, 23 Jul 1997 13:28:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA27066; Wed, 23 Jul 1997 13:30:44 -0700 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.41]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA19920 for ; Wed, 23 Jul 1997 13:30:45 -0700 Received: by INET-01-IMC with Internet Mail Service (5.0.1458.49) id ; Wed, 23 Jul 1997 13:30:46 -0700 Message-ID: From: Richard Draves To: "'Erik.Nordmark@Eng.Sun.COM'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4163) Re: ND question Date: Wed, 23 Jul 1997 13:30:38 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1474 >I don't think we can require such behavior of implementations... Certainly. The question is can we allow such behavior. I don't think it's critical; I think it's an interesting possibility. >Finally, I find it an architectural anomaly to send IP multicast >packets to a unicast link-layer address. So you think it should be forbidden to implement IP multicast via link-layer unicast? For some combinations of link characteristics & multicast group sizes, you could be ruling out an efficient implementation. >I was planning on updating the specification to disallow >source link-layer adress options when the source IP address is >the unspecified address to simply the receiver (it would just drop >such packets). I think this will make the protocol ever so slightly >easier to implement and remove one potential source of interoperability >problems. It seems to me this change would complicate the receiver because an extra check is needed, and it would complicate the sender similarly - it's easier for the sender to just include the option in every NS message that it generates. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 16:46:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00411; Wed, 23 Jul 1997 16:37:39 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA00404; Wed, 23 Jul 1997 16:37:28 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA10888; Wed, 23 Jul 1997 16:39:47 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09890; Wed, 23 Jul 1997 16:39:47 -0700 Date: Wed, 23 Jul 1997 16:39:47 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707232339.QAA09890@bobo.eng.sun.com> To: richdr@microsoft.com Subject: (IPng 4164) Re: ND question Cc: ipng@sunroof.eng.sun.com, nordmark@jurassic MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2167 > So you think it should be forbidden to implement IP multicast via > link-layer unicast? For some combinations of link characteristics & > multicast group sizes, you could be ruling out an efficient > implementation. Not at all. However, I don't see why such an optimization would only apply to Neighbor Advertisement packets which is what I thought we were discussing. If some IP-over-foo has an efficient way for multicasting on the foo link layer wouldn't this apply to all multicast packets instead of just this particular form of Neighbor Advertisement packets that are used as part of DAD (duplicate address detection)? > It seems to me this change would complicate the receiver because an > extra check is needed, and it would complicate the sender similarly - > it's easier for the sender to just include the option in every NS > message that it generates. I don't think so. Currently checks are required to avoid creating or updating a neighbor cache entry when the source is the unspecified address. I think doing the check up front when the packet is received avoids doing the check in the main processing of the NS or RS packets. And in the sender I suspect that there will be special case code for sending the DAD NS packet since it does this as part of the DAD algorithm and not part of the normal address resolution. As for sending RS before it has verified (using DAD) the link-local address i.e. the source of the RS will be the unspecified address is also likely to be special code since I expect it to be part of the same boot code that sends the DAD NS packet for the link-local packet. (The only reason for allowing the RS with the unspecified source is to reduce boot time by allowing the RS to go out while the node is waiting for the DAD timeout.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 20:02:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA00672; Wed, 23 Jul 1997 19:54:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA00665; Wed, 23 Jul 1997 19:54:16 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA17488; Wed, 23 Jul 1997 19:56:31 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA05940; Wed, 23 Jul 1997 19:56:29 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA02305; Wed, 23 Jul 1997 22:50:03 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA23769; Wed, 23 Jul 1997 22:50:01 -0400 Message-Id: <9707240250.AA23769@wasted.zk3.dec.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com, paul@vix.com Subject: (IPng 4165) Re: Problem with _res.options in RFC 2133 In-Reply-To: Your message of "Wed, 23 Jul 1997 09:30:33 MST." <199707231630.JAA09502@bobo.eng.sun.com> Date: Wed, 23 Jul 1997 22:50:00 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1380 Erik, Fix you propose for #1 and #2 are better than now I agree after working with RFC 2133. But #3 is important. If we move a little back to the following strategy: gethostbyname(host) -- just does what it dose today and no more. gethostbyname2(host, AF_FAMILY) If AF_FAMILY = AF_INET If found return IPv4 Mapped Address IF AF_FAMILY = AF_INET6 If found return IPv6 address If your still an IPv4 app not ported to IPv6 gethostbyname() just continues to work. If your an IPv4 app that has been ported to IPv6 and to be cognizant of both IPv4 and IPv6, but all addresses are treated as IPv6 addresses in the application when you use gethostbyname2(). I think this solves your #1 and #2. I think it also solves your #3 if implementors make the libraries threadsafe so gethostbyname() and gethostbyname() are built to be thread safe. Its work to diff BIND sources each time to make the resolver APIs thread saft but works. Then one does not need a gethostbyname_r(). /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 20:22:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA00692; Wed, 23 Jul 1997 20:13:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA00685; Wed, 23 Jul 1997 20:13:34 -0700 From: bound@zk3.dec.com Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA19457; Wed, 23 Jul 1997 20:15:49 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA22106; Wed, 23 Jul 1997 20:15:39 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA07072; Wed, 23 Jul 1997 23:06:36 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA24245; Wed, 23 Jul 1997 23:06:32 -0400 Message-Id: <9707240306.AA24245@wasted.zk3.dec.com> To: "W. Richard Stevens" Cc: Paul A Vixie , Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4166) Re: Problem with _res.options in RFC 2133 In-Reply-To: Your message of "Wed, 23 Jul 1997 10:53:03 MST." <199707231753.KAA16391@kohala.kohala.com> Date: Wed, 23 Jul 1997 23:06:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2188 Richard, >General question: there are some items in RFC 2133 that should be >clarified (e.g., we four authors of the RFC got email last week from >The Open Group summarizing some points and questions brought up by >their XNET group), and some items to be added (this new function >proposed by Erik). Plus some cleanup of datatypes, now that Posix.1g >appears final, and the Unix 98 changes that are taken from the final >Posix.1g draft. Well I have as one author proposed an extension to what Erik has suggested and I think it takes the issue even further. So lets have some discussion on this and possibly at the IETF before we run off and change anything. I want to see Erik's response (seeing how he caught an error we let slip through the cracks in our eagerness to just get the thing to Info RFC). And the WG. >Should we start a new I-D with these clarifications and corrections, >so everyone developing or using the RFC can see what needs tweaking? >If we ignore it then The Open Group will do something (eventually) >but their process seems much more closed to outsiders than the IETF. This is not entirely true anymore as far as X/Open direction. I was at the last meeting of XNET and X/Open is very interested in working with the IETF. They are in discussions to make their processes open to the public as far as drafts etc. But X/Open view I hope will be the following: 1. IETF does network APIs as Info RFCs. 2. Networkers Implement and Prototype. 3. IETF comments from this experience. 4. XNET provides their comments to the review process. 5. IETF updates INfo RFC # 6. XNET adopts the IETF Info RFC API I think we are at #3 and #4 with RFC 2133. I think this is a good way to play the game and RFC 2133 is the perfect test case to see if it works. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 20:34:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA00715; Wed, 23 Jul 1997 20:24:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA00708; Wed, 23 Jul 1997 20:24:32 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA20682; Wed, 23 Jul 1997 20:26:47 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA11827; Wed, 23 Jul 1997 20:26:49 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA04283; Wed, 23 Jul 1997 23:21:54 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA24740; Wed, 23 Jul 1997 23:21:47 -0400 Message-Id: <9707240321.AA24740@wasted.zk3.dec.com> To: Richard Draves Cc: "'Erik.Nordmark@Eng.Sun.COM'" , ipng@sunroof.eng.sun.com Subject: (IPng 4167) Re: ND question In-Reply-To: Your message of "Wed, 23 Jul 1997 13:30:38 MST." Date: Wed, 23 Jul 1997 23:21:47 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1434 Richard, >>Finally, I find it an architectural anomaly to send IP multicast >>packets to a unicast link-layer address. >So you think it should be forbidden to implement IP multicast via >link-layer unicast? For some combinations of link characteristics & >multicast group sizes, you could be ruling out an efficient >implementation. I am just listening for now and hope all this ND stuff is on the Munich Agenda !!! I pretty much agree with your sentiment above from a laissez-faire view of specifications, but I am beginning to learn more about my own technical ideals. I would ask of what benefit is it to multicast to a unicast link-layer address? Also I fear vendors could then abuse the link-layer address rules for unicast and use multicast in some perverted manner, hence, creating more chaos than we already have today with IPv4. Which I think we have made better with IPv6 ND. So I think permitting what you suggest might be setting us backwards in time relative to IPv6. I hope your coming to Munich we could use your view point. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 23 21:04:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA00768; Wed, 23 Jul 1997 20:56:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA00761; Wed, 23 Jul 1997 20:56:46 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA23639; Wed, 23 Jul 1997 20:59:01 -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 UAA17914; Wed, 23 Jul 1997 20:59:02 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA03417; Wed, 23 Jul 1997 23:53:18 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA25519; Wed, 23 Jul 1997 23:53:16 -0400 Message-Id: <9707240353.AA25519@wasted.zk3.dec.com> To: Erik.Nordmark@Eng Cc: ipng@sunroof.eng.sun.com, paul@vix.com Subject: (IPng 4168) Re: Problem with _res.options in RFC 2133 In-Reply-To: Your message of "Wed, 23 Jul 1997 22:50:00 -0400." <9707240250.AA23769@wasted.zk3.dec.com> Date: Wed, 23 Jul 1997 23:53:16 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 817 >I think it also solves your #3 if implementors make the libraries >threadsafe so gethostbyname() and gethostbyname() are built to be thread ^^^^^^^^^^^^^^^ [should have been] gethostbyname2() >safe. Its work to diff BIND sources each time to make the resolver APIs >thread saft but works. Then one does not need a gethostbyname_r(). Note this is transparent to users too. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 08:35:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA01298; Thu, 24 Jul 1997 08:26:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA01291; Thu, 24 Jul 1997 08:26:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA07706; Thu, 24 Jul 1997 08:29:00 -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 IAA22787 for ; Thu, 24 Jul 1997 08:29:00 -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 IAA26630 for ; Thu, 24 Jul 1997 08:28:43 -0700 Message-Id: <3.0.3.32.19970724082812.030c23c0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 24 Jul 1997 08:28:12 -0700 To: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org (by way of Bob Hinden ) Subject: (IPng 4169) I-D ACTION:draft-souvatzis-ipv6-arcnet-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3403 A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Method for the Transmission of IPv6 Packets over ARCnet Networks. Author(s) : I. Souvatzis Filename : draft-souvatzis-ipv6-arcnet-02.txt Pages : 4 Date : 07/23/1997 This memo specifies a frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an ARCnet. 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-souvatzis-ipv6-arcnet-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-souvatzis-ipv6-arcnet-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-souvatzis-ipv6-arcnet-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. Content-Type: text/plain Content-ID: <19970723172442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-souvatzis-ipv6-arcnet-02.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 Thu Jul 24 11:31:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01554; Thu, 24 Jul 1997 11:21:56 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01547; Thu, 24 Jul 1997 11:21:48 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA23202; Thu, 24 Jul 1997 11:24:04 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA24354; Thu, 24 Jul 1997 11:24:03 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA20952; Thu, 24 Jul 1997 14:16:23 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA05550; Thu, 24 Jul 1997 14:16:14 -0400 Message-Id: <9707241816.AA05550@wasted.zk3.dec.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com, paul@vix.com Subject: (IPng 4170) Re: Problem with _res.options in RFC 2133 In-Reply-To: Your message of "Wed, 23 Jul 1997 09:30:33 MST." <199707231630.JAA09502@bobo.eng.sun.com> Date: Thu, 24 Jul 1997 14:16:13 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2578 Erik and WG, Check the attached out from Richard Johnson fixing my extension. I agree with it. I like the name too. /jim ---------------- Return-Path: raj@cisco.com Received: from flume.zk3.dec.com by mailhub1.zk3.dec.com (5.65v3.2/1.1.10.5/24Sep96-0323PM) id AA07090; Thu, 24 Jul 1997 02:11:37 -0400 Received: from mail12.digital.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA25491; Thu, 24 Jul 1997 02:11:30 -0400 Received: from hubbub.cisco.com (mailgate-sj-1.cisco.com [198.92.30.31]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with ESMTP id CAA24810 for ; Thu, 24 Jul 1997 02:07:06 -0400 (EDT) Received: from rast.cisco.com (rast.cisco.com [171.69.113.55]) by hubbub.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with ESMTP id XAA20839 for ; Wed, 23 Jul 1997 23:04:35 -0700 (PDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by rast.cisco.com (8.8.5/8.8.5) with SMTP id XAA18506 for ; Wed, 23 Jul 1997 23:04:32 -0700 (PDT) Message-Id: <199707240604.XAA18506@rast.cisco.com> To: bound@zk3.dec.com Subject: Re: (IPng 4168) Re: Problem with _res.options in RFC 2133 In-Reply-To: Your message of "Wed, 23 Jul 1997 23:53:16 EDT." <9707240353.AA25519@wasted.zk3.dec.com> Date: Wed, 23 Jul 1997 23:04:31 -0700 From: Richard Johnson > >I think it also solves your #3 if implementors make the libraries > >threadsafe so gethostbyname() and gethostbyname() are built to be thread > ^^^^^^^^^^^^^^^ > [should have been] gethostbyname2() Please use some other, more descriptive, name such as "gethostbyfamilyname()" instead of "gethostbyname2()". Maybe the actual name has yet to be clarified though and you just mentioned "gethostbyname2()" in order to fill in your example? Of course, "gethostbyfamilyname() should have arguments in the order: gethostbyfamilyname(AF_FAMILY, host); which sorta makes more sense since it orders arguments from less specific to more specific. In this case, "gethostbyname" would simply be a #define: #define gethostbyname(host) (gethostbyfamilyname(AF_INET, (host))) /raj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 12:03:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01582; Thu, 24 Jul 1997 11:53:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01575; Thu, 24 Jul 1997 11:53:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA02368; Thu, 24 Jul 1997 11:56:04 -0700 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA05418 for ; Thu, 24 Jul 1997 11:56:04 -0700 Received: from wisdom.rc.vix.com (wisdom.rc.vix.com [204.152.187.1]) by gw.home.vix.com (8.8.6/) via ESMTP id LAA11534 for ; Thu, 24 Jul 1997 11:56:02 -0700 (PDT) env-from (vixie@wisdom.rc.vix.com) Received: by wisdom.rc.vix.com; id LAA16142; Thu, 24 Jul 1997 11:56:01 -0700 Message-Id: <199707241856.LAA16142@wisdom.rc.vix.com> X-Authentication-Warning: wisdom.rc.vix.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 4171) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Thu, 24 Jul 1997 14:16:13 EDT." <9707241816.AA05550@wasted.zk3.dec.com> Date: Thu, 24 Jul 1997 11:56:01 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 890 gethostbyname2() is part of bind. i chose the name, however badly, based on my prior observation of: pid_t wait(int *status); pid_t waitpid(pid_t wpid, int *status, int options); pid_t wait3(int *status, int options, struct rusage *rusage); pid_t wait4(pid_t wpid, int *status, int options, struct rusage *rusage); i'm not asking you folks to like the name, but now that it's in the field you have to have a better reason than "i don't like the name" to change it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 12:46:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01733; Thu, 24 Jul 1997 12:38:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA01726; Thu, 24 Jul 1997 12:37:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA12701; Thu, 24 Jul 1997 12:40:07 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA19626 for ; Thu, 24 Jul 1997 12:40:06 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA31720; Fri, 25 Jul 1997 05:39:53 +1000 (from kre@munnari.OZ.AU) To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4172) Re: Problem with _res.options in RFC 2133 In-Reply-To: Your message of "Thu, 24 Jul 1997 11:56:01 MST." <199707241856.LAA16142@wisdom.rc.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 1997 05:39:52 +1000 Message-Id: <19843.869773192@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1765 Date: Thu, 24 Jul 1997 11:56:01 -0700 From: Paul A Vixie Message-ID: <199707241856.LAA16142@wisdom.rc.vix.com> | pid_t | wait3(int *status, int options, struct rusage *rusage); The wait3 name was sheer laziness, by someone who couldn't be bothered thinking up something rational. | pid_t | wait4(pid_t wpid, int *status, int options, struct rusage *rusage); But wait4 was a pun - it was meant to be read as "wait for", where you give the pid that you expect to finish - that it had 4 args and that wait3 with 3 args already existed merely made it a better joke. | i'm not asking you folks to like the name, but now that it's in the field | you have to have a better reason than "i don't like the name" to change it. I somehow doubt that usage of gethostbyname2() is so endemic that changing it would be any kind of real problem. And in any case, nothing would prevent that name continuing to be available for those who do happen to have the few applications that use it (nothing greatly different here than the index()/strchr() changes etc that have, and still are, happening over time, and there index() really was much more ingrained, and for a much longer time, than is the case with gethostbyname2()). I'd certainly support choosing a more rational name (and the one suggested is just fine). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 14:09:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA01917; Thu, 24 Jul 1997 13:59:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA01910; Thu, 24 Jul 1997 13:59:33 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA02961; Thu, 24 Jul 1997 14:01:51 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA15296 for ; Thu, 24 Jul 1997 14:01:51 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id QAA00566; Thu, 24 Jul 1997 16:45:51 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA16990; Thu, 24 Jul 1997 16:45:50 -0400 Message-Id: <9707242045.AA16990@wasted.zk3.dec.com> To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4173) Re: Problem with _res.options in RFC 2133 In-Reply-To: Your message of "Thu, 24 Jul 1997 11:56:01 MST." <199707241856.LAA16142@wisdom.rc.vix.com> Date: Thu, 24 Jul 1997 16:45:18 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 655 >i'm not asking you folks to like the name, but now that it's in the field >you have to have a better reason than "i don't like the name" to change it. That is a good point so I will go either way. I just would like to not change my apps/utilities again if possible. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 16:24:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02202; Thu, 24 Jul 1997 16:14:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02195; Thu, 24 Jul 1997 16:14:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA09384; Thu, 24 Jul 1997 16:17:00 -0700 Received: from stb.info.com ([208.254.35.51]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA26177 for ; Thu, 24 Jul 1997 16:16:59 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0wrX6k-000ZHaC; Thu, 24 Jul 97 16:15 PDT Message-Id: Date: Thu, 24 Jul 97 16:15 PDT From: Michael Gersten To: qv@3com.com, trohling@instructors.net Subject: (IPng 4174) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 941 Good point; if the loose source routing is to allow going past a firewall, it's a big problem. I'm not thinking of that at all. I'm just thinking of the existing loose source routing system. As for packet hijacking (which someone else mentioned), it can be solved with the V6 system of a 254 TTL field. It takes a few packets before it stabilizes (goes one hop closer to the source on each packet). The benefit: Even if the source site does not know how to take a loose source route redirection, the ISP's site will (in all likelyhood). More comments, please -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 24 16:37:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02213; Thu, 24 Jul 1997 16:25:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02206; Thu, 24 Jul 1997 16:25:27 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA12173; Thu, 24 Jul 1997 16:27:44 -0700 Received: from stb.info.com (1Cust51.tnt1.lancaster.ca.da.uu.net [208.254.35.51]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA29512 for ; Thu, 24 Jul 1997 16:27:42 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0wrXHO-000ZHaC; Thu, 24 Jul 97 16:26 PDT Message-Id: Date: Thu, 24 Jul 97 16:26 PDT From: Michael Gersten To: jwkckid1@ix.netcom.com, michael@STB.INFO.COM Subject: (IPng 4175) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. Cc: ipng@sunroof.eng.sun.com, mo@UU.NET, naipr@arin.net Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1209 Yes, 2 years is the outside limit, given the demand for routable IP's. This idea of mine is intended to allow V4 systems, with 100% compatibility, to have routables /31's or /32's (assuming that a /32 won't crash the kernel). As people have pointed out to me, strict compatibility won't happen, but if the ISP's and backbones upgrade, it will work; if and when people upgrade their own systems (windows 98, etc), then the load is moved even more to the source sites and away from the center. The point is: If the whole reason for rushing v6 is "Get routable IP's", then it's a false argument. There are other ways to get routable IP's that do not require all existing v4 applications to be incompatible. [Did a solution to a v4 program talking to a v6 host ever get developed? I was off the list for about 4 months this year] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 24 17:15:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA02367; Thu, 24 Jul 1997 17:07:32 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA02360; Thu, 24 Jul 1997 17:07:28 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA09238; Thu, 24 Jul 1997 17:09:48 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA09130; Thu, 24 Jul 1997 17:07:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA02245; Thu, 24 Jul 1997 16:49:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA18034; Thu, 24 Jul 1997 16:52:04 -0700 Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA06455 for ; Thu, 24 Jul 1997 16:52:02 -0700 Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id SAA10431; Thu, 24 Jul 1997 18:51:56 -0500 (CDT) Received: from kcx-ks6-23.ix.netcom.com(204.30.70.215) by dfw-ix13.ix.netcom.com via smap (V1.3) id sma010424; Thu Jul 24 18:51:38 1997 Message-ID: <33D793D2.B4@ix.netcom.com> Date: Thu, 24 Jul 1997 18:41:38 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: Michael Gersten CC: ipng@sunroof.eng.sun.com, mo@UU.NET, naipr@arin.net Subject: (IPng 4177) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1692 Michael and all, Michael Gersten wrote: > > Yes, 2 years is the outside limit, given the demand for routable > IP's. Glad you clarified that. Two years just isn't exceptable I don't believe dure to demand alone. > > This idea of mine is intended to allow V4 systems, with 100% compatibility, > to have routables /31's or /32's (assuming that a /32 won't crash the > kernel). > > As people have pointed out to me, strict compatibility won't happen, but > if the ISP's and backbones upgrade, it will work; if and when people upgrade > their own systems (windows 98, etc), then the load is moved even more to > the source sites and away from the center. > > The point is: If the whole reason for rushing v6 is "Get routable IP's", > then it's a false argument. There are other ways to get routable IP's that > do not require all existing v4 applications to be incompatible. I agree. > > [Did a solution to a v4 program talking to a v6 host ever get developed? > I was off the list for about 4 months this year] I believe so. But don't quote me on this. Maybe some others on this list can answer this one. Anyone? Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 18:30:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA02441; Thu, 24 Jul 1997 18:21:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA02434; Thu, 24 Jul 1997 18:21:24 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA04114; Thu, 24 Jul 1997 18:23:40 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA27490 for ; Thu, 24 Jul 1997 18:23:42 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id VAA31297; Thu, 24 Jul 1997 21:19:42 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30978; Thu, 24 Jul 1997 21:19:35 -0400 Message-Id: <9707250119.AA30978@wasted.zk3.dec.com> To: Jeff Williams Cc: Michael Gersten , ipng@sunroof.eng.sun.com, mo@uu.net, naipr@arin.net, bound@zk3.dec.com Subject: (IPng 4178) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. In-Reply-To: Your message of "Thu, 24 Jul 1997 18:41:38 +0100." <33D793D2.B4@ix.netcom.com> Date: Thu, 24 Jul 1997 21:19:34 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1125 I have not commented on this thread as I am just scanning it and will read it in entirety before the IETF and if I have comments I will make them later or at the IETF if this is a subject for the Working Group. But this caught my scanner: >> [Did a solution to a v4 program talking to a v6 host ever get developed? >> I was off the list for about 4 months this year] > I believe so. But don't quote me on this. Maybe some others >on this list can answer this one. Anyone? A v4 host can always talk to a v6 host that has a hybrid stack meaning it can accept v4 or v6 addresses. A v4 host talking to a v6 ONLY host is another matter (I am assuming translators or non-translators exist between the two nodes). Which is the question? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 24 19:55:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02622; Thu, 24 Jul 1997 19:47:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02615; Thu, 24 Jul 1997 19:47:32 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA14123; Thu, 24 Jul 1997 19:49:50 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA13279 for ; Thu, 24 Jul 1997 19:49:50 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA04543; Thu, 24 Jul 1997 22:44:15 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03136; Thu, 24 Jul 1997 22:44:11 -0400 Message-Id: <9707250244.AA03136@wasted.zk3.dec.com> To: Jeff Williams Cc: bound@zk3.dec.com, Michael Gersten , ipng@sunroof.eng.sun.com, mo@uu.net, naipr@arin.net Subject: (IPng 4181) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. In-Reply-To: Your message of "Thu, 24 Jul 1997 20:47:25 +0100." <33D7B14C.9FC@ix.netcom.com> Date: Thu, 24 Jul 1997 22:44:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1045 Well it can't be down without translators on the host. But no we have no IETF solutiion at this time. Some of us are working on it but I am not sure this can be brought into the IETF. How I do it on my implementation may not be good for another implementation. Also they have a lot of evil aspects like killing performance and a nightmare to manage. Lots of different ways to do them. This just may be the place where added value exists and the vendor who does this well will sell more IPv6. At the ngtrans group I will present deployment scenarios and this is clearly one of them. It also can be avoided in most cases too with private IPv4 addresses. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 25 09:04:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03165; Fri, 25 Jul 1997 08:53:04 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03158; Fri, 25 Jul 1997 08:53:00 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA20321; Fri, 25 Jul 1997 08:55:19 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10058; Fri, 25 Jul 1997 08:53:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02549; Thu, 24 Jul 1997 19:02:14 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA09590; Thu, 24 Jul 1997 19:04:30 -0700 Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id TAA04838 for ; Thu, 24 Jul 1997 19:04:32 -0700 Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id UAA22984; Thu, 24 Jul 1997 20:57:49 -0500 (CDT) Received: from kcx-ks3-26.ix.netcom.com(204.30.70.122) by dfw-ix15.ix.netcom.com via smap (V1.3) id sma022968; Thu Jul 24 20:57:26 1997 Message-ID: <33D7B14C.9FC@ix.netcom.com> Date: Thu, 24 Jul 1997 20:47:25 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: bound@zk3.dec.com CC: Michael Gersten , ipng@sunroof.eng.sun.com, mo@uu.net, naipr@arin.net Subject: (IPng 4183) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. References: <9707250119.AA30978@wasted.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1603 Jim, bound@zk3.dec.com wrote: > > I have not commented on this thread as I am just scanning it and will > read it in entirety before the IETF and if I have comments I will make > them later or at the IETF if this is a subject for the Working Group. > > But this caught my scanner: > > >> [Did a solution to a v4 program talking to a v6 host ever get developed? > >> I was off the list for about 4 months this year] > > > I believe so. But don't quote me on this. Maybe some others > >on this list can answer this one. Anyone? > > A v4 host can always talk to a v6 host that has a hybrid stack meaning > it can accept v4 or v6 addresses. > > A v4 host talking to a v6 ONLY host is another matter (I am assuming > translators or non-translators exist between the two nodes). > > Which is the question? I believe the latter is the question. I believe that if translators are present on the v6 only host, that there is no problem. However, if not than of course transmission will fail. But don't quote me on tis one. > > /jim Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jul 25 09:05:36 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03174; Fri, 25 Jul 1997 08:54:36 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03167; Fri, 25 Jul 1997 08:54:29 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA20466; Fri, 25 Jul 1997 08:56:49 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10085; Fri, 25 Jul 1997 08:54:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA02577; Thu, 24 Jul 1997 19:21:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA11479; Thu, 24 Jul 1997 19:23:20 -0700 Received: from severian.chi.il.us (severian.chi.il.us [131.225.104.254]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA08509 for ; Thu, 24 Jul 1997 19:23:21 -0700 Received: from LOCALHOST.chi.il.us by severian.chi.il.us (8.7.3/severian-1) id VAA09263; Thu, 24 Jul 1997 21:22:42 -0500 (CDT) Message-Id: <199707250222.VAA09263@severian.chi.il.us> To: ipng@sunroof.eng.sun.com Subject: (IPng 4184) final(?) IPv6-over-{ethernet,fddi} Mime-Version: 1.0 Content-Description: A MIME message created by mime-compose.el. Content-Type: multipart/mixed; boundary=mimeprimaryboundary Date: Thu, 24 Jul 1997 21:22:41 -0500 From: Matt Crawford Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1673 > THIS IS A MESSAGE IN 'MIME' FORMAT. > If you are reading this, your mail reader may not support MIME. > Some parts of this message will be readable as plain text. --mimeprimaryboundary Content-Type: text/plain I have just sent what I hope are the final drafts of IPv6 over Ethernet and over FDDI to the i-d editor. The changes from the -01 draft consist of wording details to make the two uniform (where they should be) uniformly using the term "Interface Identifier" instead of any of the alternatives mentioning, in a generic way, the applicability to fast ethernet, full duplex, etc., and CDDI In order to save interested parties the wait, yet not clutter up mailboxes, I include pointers to the drafts below. Matt --mimeprimaryboundary Content-Type: message/external-body; access-type="anon-ftp"; site="berserk.fnal.gov"; directory="pub"; name="draft-ietf-ipngwg-trans-ethernet-02.txt" Content-Description: draft-ietf-ipngwg-trans-ethernet-02.txt Content-Type: text/plain --mimeprimaryboundary Content-Type: message/external-body; access-type="anon-ftp"; site="berserk.fnal.gov"; directory="pub"; name="draft-ietf-ipngwg-trans-fddi-net-02.txt" Content-Description: draft-ietf-ipngwg-trans-fddi-net-02.txt Content-Type: text/plain --mimeprimaryboundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 25 09:12:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA03189; Fri, 25 Jul 1997 09:00:47 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA03182; Fri, 25 Jul 1997 09:00:39 -0700 Received: from stinker.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA21212; Fri, 25 Jul 1997 09:02:58 -0700 Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10117; Fri, 25 Jul 1997 09:01:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA03013; Fri, 25 Jul 1997 06:46:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA11138; Fri, 25 Jul 1997 06:49:05 -0700 Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA08856 for ; Fri, 25 Jul 1997 06:49:03 -0700 Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id IAA03534; Fri, 25 Jul 1997 08:42:18 -0500 (CDT) Received: from kcx-ks12-24.ix.netcom.com(206.214.130.152) by dfw-ix1.ix.netcom.com via smap (V1.3) id sma003475; Fri Jul 25 08:42:08 1997 Message-ID: <33D85671.90A@ix.netcom.com> Date: Fri, 25 Jul 1997 08:32:01 +0100 From: Jeff Williams Organization: IEG. INC. X-Mailer: Mozilla 3.01Gold (Win16; I) MIME-Version: 1.0 To: bound@zk3.dec.com CC: Michael Gersten , ipng@sunroof.eng.sun.com, mo@uu.net, naipr@arin.net Subject: (IPng 4185) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. References: <9707250244.AA03136@wasted.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1942 Jim, bound@zk3.dec.com wrote: > > Well it can't be down without translators on the host. But no we have > no IETF solutiion at this time. That is my understanding as well. The IETF is still working on a standard here form wht I understand. > > Some of us are working on it but I am not sure this can be brought into > the IETF. How I do it on my implementation may not be good for another > implementation. True. But some standardation can be achieved. > > Also they have a lot of evil aspects like killing performance and a > nightmare to manage. Yes, the performance hit is significant I must admit. I am not in agreement with the managment part however. I have done this already on several occasions and the managment aspect is really a matter of setting up good procedures and some tool development, which I have done myself. > > Lots of different ways to do them. This just may be the place where > added value exists and the vendor who does this well will sell more > IPv6. I agree. > > At the ngtrans group I will present deployment scenarios and this is > clearly one of them. Great! I think it would be very helpfull. > > It also can be avoided in most cases too with private IPv4 addresses. Not sure what you are refering to here. FOr intrAnet I do, but for Internet addressable IPv4 I don't. Can you clearify a bit? >;) > > /jim Regards, -- Jeffrey A. Williams DIR. Internet Network Eng/SR. Java Development Eng. Information Eng. Group. IEG. INC. Phone :913-294-2375 (v-office) E-Mail jwkckid1@ix.netcom.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 Jul 28 07:19:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05444; Mon, 28 Jul 1997 07:10:43 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05437; Mon, 28 Jul 1997 07:10:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA09298; Mon, 28 Jul 1997 07:12:53 -0700 Received: from ietf.org (ietf.org [132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA24274 for ; Mon, 28 Jul 1997 07:12:50 -0700 Received: from ietf.ietf.org by ietf.org id aa07173; 28 Jul 97 9:44 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 4186) I-D ACTION:draft-ietf-ipngwg-icmp-namelookups-01.txt Date: Mon, 28 Jul 1997 09:44:18 -0400 Message-ID: <9707280944.aa07173@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4154 --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 Name Lookups Through ICMP Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-namelookups-01.txt Pages : 5 Date : 07/25/1997 IPv4 addresses are translated to fully-qualified domain names (FQDNs) using the DNS. Experience shows that the IN-ADDR.ARPA zones used for this translation tend to be poorly maintained in many cases. In a larger internet with more frequent site renumbering, the maintenance of such zones will be even more difficult. This document describes a protocol for simply asking an IPv6 node to supply its FQDN when needed. The DNS style of authority delegation is thus eliminated for IPv6 address-to-name translations and the routing infrastructure plays that role. 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-icmp-namelookups-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-icmp-namelookups-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-icmp-namelookups-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: <19970725110415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-namelookups-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-namelookups-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970725110415.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 Jul 28 11:44:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA05746; Mon, 28 Jul 1997 11:34:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA05739; Mon, 28 Jul 1997 11:33:52 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA22027; Mon, 28 Jul 1997 11:36:12 -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 LAA23452 for ; Mon, 28 Jul 1997 11:36:12 -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 LAA06707 for ; Mon, 28 Jul 1997 11:36:11 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 28 Jul 1997 11:36:02 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 4187) Routing header's Strict/Loose Bit Map Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2798 The IPv6 spec defines the Strict/Loose Bit Map in the Routing header to allow a sender to restrict particular segments of the route to occur only between neighboring addresses. However, it does not specify how a node shall decide if given next address is its neighbor. There are at least two solutions to this specification inadequacy: (1) specify a neighborness test, or (2) eliminate the Strict/Loose Bit Map from the Routing header altogether. I would prefer to do (2), because (1) appears to be somewhat complicated and because I am dubious of the value of strict routing anyway. Presumably, two addresses are considered neighbors if they have been assigned to interfaces connected to the same link. But how does a node determine that a given address is a neighbor of one of its own addresses? A simple test for equality under a subnet mask is inadequate because: (a) the node doing the testing may not know any or all of the subnet masks assigned to the attached link. (ND can be configured to withhold that information from hosts.) (b) even an address that tests equal under a subnet mask known to the node may not be a neighbor because, for example, it belongs to a mobile node that is away from home. (I'm assuming that a mobile host away from home should *not* be considered a neighbor of nodes on its home link, for the purposes of strict routing -- is that the right assumption?) A possible test would be based on results of ND exchanges: - all routers discovered through ND are neighbors, and - all hosts discovered through ND are neighbors, excluding those for whom only a proxy is known. That's messy because at the point at which the test must be performed while processing a Routing header, if the node doing the processing had never previously tried to communicate with the supposed neighbor address, it would have initiate some sort of communication (e.g., a ping) and then wait for the ND result to come back before continuing to process the Route header. According to my definition of neighborness, addresses assigned to each end of an IPv6-in-IPv6 tunnel would be considered neighbors, since a tunnel is a (virtual) link. Is that OK, for the purpose of strict routing, or would we have to special-case that? What have implementors done about this, if anything? Would anyone object if we just tossed the strict routing feature altogether? 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 Mon Jul 28 12:30:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA05829; Mon, 28 Jul 1997 12:20:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA05822; Mon, 28 Jul 1997 12:20:18 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA04570; Mon, 28 Jul 1997 12:22:38 -0700 Received: from gin.math.human.nagoya-u.ac.jp (gin.math.human.nagoya-u.ac.jp [133.6.144.61]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA09874 for ; Mon, 28 Jul 1997 12:22:38 -0700 Received: from bimota.imada.math.human.nagoya-u.ac.jp (gshi2.info.human.nagoya-u.ac.jp) by gin.math.human.nagoya-u.ac.jp (4.2/3.3W9) id AA26127; Tue, 29 Jul 97 04:21:45 JST Received: from bimota.imada.math.human.nagoya-u.ac.jp (koji@bimota.imada.math.human.nagoya-u.ac.jp [133.6.251.3]) by bimota.imada.math.human.nagoya-u.ac.jp (8.8.5/3.5Wpl4) with ESMTP id EAA12464; Tue, 29 Jul 1997 04:21:48 +0900 (JST) Message-Id: <199707281921.EAA12464@bimota.imada.math.human.nagoya-u.ac.jp> To: ipng@sunroof.eng.sun.com Cc: rstevens@kohala.com (W. Richard Stevens) Subject: (IPng 4188) Re: I-D ACTION:draft-stevens-advanced-api-04.txt From: Koji Imada - je4owb/2 In-Reply-To: Your message of "Wed, 23 Jul 1997 08:55:34 -0700" References: <3.0.3.32.19970723085534.006ab8b4@mailhost.ipsilon.com> X-Mailer: Mew version 1.54 on Emacs 19.28.3, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 1997 04:21:29 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2071 I found some inconsistency in draft-stevens-advanced-api-04.txt. This is handling of CMSG_LEN() or CMSG_SPACE(). In examples of 6.3.7 and 8.9, msg.msg_controllen is set by CMSG_LEN(cmsgptr->cmsg_len). But definition of CMSG_LEN() in 4.3.5, > This macro is new with this API. Given the length of an ancillary > data object, CMSG_LEN() returns the value to store in the cmsg_len > member of the cmsghdr structure, taking into account any padding > needed to satisfy alignment requirements. What does "the length of an ancillary data object" mean? Is this includes length of cmsghdr structure? Although returned value includes length of an ancillary data object and it's cmsghdr structure, how about length argument to CMSG_LEN()? In the case of CMSG_SPACE(), it is noted and sample implementation has same meaning(length argument does not include length of cmsghdr). On the other hand, this is not noted explicitly in 4.3.5. From sample implementation this seems to be same as CMSG_SPACE() which does not includes length of cmsghdr structure. But in examples of 6.3.7 and 8.9, msg.msg_controllen is set as follows. > msg.msg_controllen = CMSG_LEN(cmsgptr->cmsg_len); or > msg.msg_controllen = CMSG_SPACE(cmsgptr->cmsg_len); > msg.msg_controllen += CMSG_LEN(cmsgptr->cmsg_len); This make msg.msg_controllen ALIGN(sizeof(struct cmsghdr)) bytes longer than it should be. If my understanding is correct, assignment should be > msg.msg_controllen = CMSG_LEN(cmsg->cmsg_len - CMSG_LEN(0)); or just align it > msg.msg_controllen = ALIGN(cmsg->cmsg_len); Which is the right meaning of CMSG_LEN()? -- Koji Imada - je4owb/2 kojI@math.human.nagoya-u.ac.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 13:39:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA05900; Mon, 28 Jul 1997 13:30:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA05893; Mon, 28 Jul 1997 13:30:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA21368; Mon, 28 Jul 1997 13:32:43 -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 NAA02957 for ; Mon, 28 Jul 1997 13:32:43 -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 NAA10909; Mon, 28 Jul 1997 13:32:42 -0700 (PDT) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA25496; Mon, 28 Jul 1997 13:32:41 -0700 (PDT) Date: Mon, 28 Jul 1997 13:32:41 -0700 (PDT) Message-Id: <199707282032.NAA25496@pedrom-ultra.cisco.com> From: Pedro Marques To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4189) Routing header's Strict/Loose Bit Map 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: 2136 >>>>> "Steve" == Steve Deering writes: Steve> The IPv6 spec defines the Strict/Loose Bit Map in the Steve> Routing header to allow a sender to restrict particular Steve> segments of the route to occur only between neighboring Steve> addresses. However, it does not specify how a node shall Steve> decide if given next address is its neighbor. There are at Steve> least two solutions to this specification inadequacy: Steve> (1) specify a neighborness test, or Steve> (2) eliminate the Strict/Loose Bit Map from the Routing Steve> header altogether. Steve> I would prefer to do (2), because (1) appears to be Steve> somewhat complicated and because I am dubious of the value Steve> of strict routing anyway. Steve> Presumably, two addresses are considered neighbors if they Steve> have been assigned to interfaces connected to the same Steve> link. But how does a node determine that a given address Steve> is a neighbor of one of its own addresses? A simple test Steve> for equality under a subnet mask is inadequate because: Steve> (a) the node doing the testing may not know any or all Steve> of the subnet masks assigned to the attached link. (ND can Steve> be configured to withhold that information from hosts.) Steve, I believe that the definition of "neighbor" can be: "to be connected to the same link, to the best of the knowledge of the router that performs the test". I.e. perform the subnet mask test and beaware that the information might not reflect the topology with 100% accuracy. If proxy ARP is used on IPv4 with can get the same kind of non 100% acurate results... however this doesn't seam to be a problem. 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 Jul 28 14:17:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05983; Mon, 28 Jul 1997 14:08:11 -0700 Received: from hsmpka.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05976; Mon, 28 Jul 1997 14:08:03 -0700 Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA22160; Mon, 28 Jul 1997 14:10:24 -0700 Date: Mon, 28 Jul 1997 14:08:28 -0700 (PDT) From: Charles Perkins Reply-To: Charles Perkins Subject: (IPng 4190) Re: Routing header's Strict/Loose Bit Map To: ipng@sunroof.eng.sun.com Cc: deering@cisco.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DxbNVA/ReT+K6LNkdPHTJA== X-Mailer: dtmail 1.1.0 CDE Version 1.1_50 SunOS 5.5.1 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1417 > (I'm assuming that a mobile host away from home should *not* be considered > a neighbor of nodes on its home link, for the purposes of strict routing -- > is that the right assumption?) Here, I think that one has to say that the mobile node away from home is still considered a neighbor of other nodes on the home network, since the home agent has to proxy for the mobile node anyway. > According to my definition of neighborness, addresses assigned to each > end of an IPv6-in-IPv6 tunnel would be considered neighbors, since a > tunnel is a (virtual) link. Is that OK, for the purpose of strict > routing, or would we have to special-case that? Isn't this analysis also relevant to the case of a mobile node? > What have implementors done about this, if anything? Would anyone object > if we just tossed the strict routing feature altogether? I wouldn't. I also hope that there is still agreement that reception of a routing header does not require that the receiver perform any sort of route reversal. > Steve Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 15:46:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA06125; Mon, 28 Jul 1997 15:36:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA06118; Mon, 28 Jul 1997 15:36:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA01479; Mon, 28 Jul 1997 15:38:26 -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 OAA25714 for ; Mon, 28 Jul 1997 14:43:22 -0700 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id OAA27433 Posted-Date: Mon, 28 Jul 1997 14:43:01 -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 RAA04017; Mon, 28 Jul 1997 17:43:19 -0400 for Message-Id: <3.0.32.19970728174145.006aad94@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 28 Jul 1997 17:41:45 -0400 To: Steve Deering From: Dimitry Haskin Subject: (IPng 4191) Re: Routing header's Strict/Loose Bit Map 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: 4191 Steve, At 11:36 AM 7/28/97 -0700, Steve Deering wrote: >The IPv6 spec defines the Strict/Loose Bit Map in the Routing header to >allow a sender to restrict particular segments of the route to occur only >between neighboring addresses. However, it does not specify how a node >shall decide if given next address is its neighbor. There are at least two >solutions to this specification inadequacy: > > (1) specify a neighborness test, or > > (2) eliminate the Strict/Loose Bit Map from the Routing header altogether. > >I would prefer to do (2), because (1) appears to be somewhat complicated >and because I am dubious of the value of strict routing anyway. > >Presumably, two addresses are considered neighbors if they have been >assigned to interfaces connected to the same link. But how does a node >determine that a given address is a neighbor of one of its own addresses? >A simple test for equality under a subnet mask is inadequate because: > > (a) the node doing the testing may not know any or all of the > subnet masks assigned to the attached link. (ND can be > configured to withhold that information from hosts.) > > (b) even an address that tests equal under a subnet mask known > to the node may not be a neighbor because, for example, it > belongs to a mobile node that is away from home. > I never perceived it as a problem since I assumed that the same test that is used to determine neighborness when forwarding packets without a Routing header should be used with source routed packets. That is, a address is a neighbor if one of the following is true: - its address prefix has been advertised in RA with the on-link flag on; - it has been manually configured to be a neighbor; - a router redirect has been received for the address; - it is a link-local address; - and possibly, if unsolicited NA has been received for the address. >(I'm assuming that a mobile host away from home should *not* be considered >a neighbor of nodes on its home link, for the purposes of strict routing -- >is that the right assumption?) > I never considered a mobile host to be a special case as forwarding is concerned. But I don't have much expertise here so I could be very well mistaken. >A possible test would be based on results of ND exchanges: > > - all routers discovered through ND are neighbors, and > > - all hosts discovered through ND are neighbors, excluding those > for whom only a proxy is known. > >That's messy because at the point at which the test must be performed >while processing a Routing header, if the node doing the processing had >never previously tried to communicate with the supposed neighbor address, >it would have initiate some sort of communication (e.g., a ping) and then >wait for the ND result to come back before continuing to process the >Route header. > I don't think more than a normal test for the forwarding address should be done for packet with a Routing header. I.e., neighborness is determined before communication is initiated. >According to my definition of neighborness, addresses assigned to each >end of an IPv6-in-IPv6 tunnel would be considered neighbors, since a >tunnel is a (virtual) link. Is that OK, for the purpose of strict >routing, or would we have to special-case that? And how would you know at one end of a tunnel that a non link-local address is assigned to the another end of the tunnel? I think if you try to answer this question you may see that there is no special case to consider here. > >What have implementors done about this, if anything? We use the same neighborness test for all types of forwarding. >Would anyone object >if we just tossed the strict routing feature altogether? > I don't have any vested interest in this feature but I feel that the problem is overstated. >Steve 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 Mon Jul 28 15:57:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA06139; Mon, 28 Jul 1997 15:43:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA06132; Mon, 28 Jul 1997 15:43:17 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA03175; Mon, 28 Jul 1997 15:43:55 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA13764 for ; Mon, 28 Jul 1997 15:43:43 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA16291; Mon, 28 Jul 97 15:42:37 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA08259; Mon, 28 Jul 1997 15:44:12 -0700 Date: Mon, 28 Jul 1997 15:44:12 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199707282244.PAA08259@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4192) Re: Routing header's Strict/Loose Bit Map X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2762 Steve, > > Presumably, two addresses are considered neighbors if they have been > assigned to interfaces connected to the same link. But how does a node > determine that a given address is a neighbor of one of its own addresses? > A simple test for equality under a subnet mask is inadequate because: > > (a) the node doing the testing may not know any or all of the > subnet masks assigned to the attached link. (ND can be > configured to withhold that information from hosts.) > > (b) even an address that tests equal under a subnet mask known > to the node may not be a neighbor because, for example, it > belongs to a mobile node that is away from home. > > (I'm assuming that a mobile host away from home should *not* be considered > a neighbor of nodes on its home link, for the purposes of strict routing -- > is that the right assumption?) > We have been checking that we have an address/mask assigned to one of our interfaces which matches the next hop address and that we know the prefix to be on-link based on a either manual configuration or receipt of a prefix option indicating the "on-link" attribute. Admittedly this is an imperfect test for the reasons you note above. Given the current definition of ND and ADDRCONF it is the best test we can make which does not require explicit probing for neighborlyness. You note this below. Real messy I think. > > A possible test would be based on results of ND exchanges: > > - all routers discovered through ND are neighbors, and > > - all hosts discovered through ND are neighbors, excluding those > for whom only a proxy is known. > > That's messy because at the point at which the test must be performed > while processing a Routing header, if the node doing the processing had > never previously tried to communicate with the supposed neighbor address, > it would have initiate some sort of communication (e.g., a ping) and then > wait for the ND result to come back before continuing to process the > Route header. > .... > > What have implementors done about this, if anything? Would anyone object > if we just tossed the strict routing feature altogether? > I have no objection to the removal of the strict/loose bitmask. I have doubts about the value of strict source routes given the current subnet model employed by ND. I will not mourn their passing. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jul 28 22:34:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA06487; Mon, 28 Jul 1997 22:26:37 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA06480; Mon, 28 Jul 1997 22:26:24 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA07921; Mon, 28 Jul 1997 22:28:44 -0700 Received: from onoe2.sm.sony.co.jp (onoe2.sm.sony.co.jp [133.138.10.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA16995 for ; Mon, 28 Jul 1997 22:28:44 -0700 Received: from duplo.sm.sony.co.jp (root@duplo.sm.sony.co.jp [133.138.10.3]) by onoe2.sm.sony.co.jp (8.8.5/Sony6.1MX) with ESMTP id OAA09721; Tue, 29 Jul 1997 14:28:39 +0900 (JST) Received: from sm.sony.co.jp (onoe@localhost [127.0.0.1]) by duplo.sm.sony.co.jp (8.8.5/8.8.5) with ESMTP id OAA03239; Tue, 29 Jul 1997 14:26:26 +0900 (JST) Message-Id: <199707290526.OAA03239@duplo.sm.sony.co.jp> To: deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4193) Re: Routing header's Strict/Loose Bit Map In-Reply-To: Your message of "Mon, 28 Jul 1997 11:36:02 -0700" References: X-Mailer: Mew version 1.52 on Emacs 19.28.2, Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 1997 14:26:15 +0900 From: Atsushi Onoe Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1066 Steve, > Would anyone object > if we just tossed the strict routing feature altogether? I would. The strict routing feature can be used to implement a policy, for example, the marked packet should not be forwarded to backup link. For some tunneling mechanisms, such as IPv4 over IPv6, or Mbone over IPv6, the carried protocols have their own routing and they might want to detect the link status. If there is no strict routing feature, the lower IPv6 packet would be implicitly rerouted to backup link and no information will be notified to upper layer protocol. However, I don't think ND tests are required. Performing address mask tests would be enough in most cases. Atsushi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 29 07:09:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06683; Tue, 29 Jul 1997 06:59:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06664; Tue, 29 Jul 1997 06:58:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA26415; Tue, 29 Jul 1997 07:01:13 -0700 Received: from ietf.org ([132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA15518 for ; Tue, 29 Jul 1997 07:01:14 -0700 Received: from ietf.ietf.org by ietf.org id aa06832; 29 Jul 97 9:37 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 4194) I-D ACTION:draft-ietf-ipngwg-trans-ethernet-02.txt Date: Tue, 29 Jul 1997 09:37:36 -0400 Message-ID: <9707290937.aa06832@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3975 --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 : Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-ethernet-02.txt Pages : 6 Date : 07/25/1997 This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. 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-ethernet-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-ethernet-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-trans-ethernet-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: <19970725110847.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-ethernet-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-ethernet-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970725110847.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 Jul 29 07:09:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06684; Tue, 29 Jul 1997 06:59:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA06667; Tue, 29 Jul 1997 06:58:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA26422; Tue, 29 Jul 1997 07:01:15 -0700 Received: from ietf.org ([132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA15531 for ; Tue, 29 Jul 1997 07:01:16 -0700 Received: from ietf.ietf.org by ietf.org id aa06857; 29 Jul 97 9:37 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 4195) I-D ACTION:draft-ietf-ipngwg-trans-fddi-net-02.txt Date: Tue, 29 Jul 1997 09:37:40 -0400 Message-ID: <9707290937.aa06857@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4356 --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 : Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-fddi-net-02.txt Pages : 8 Date : 07/25/1997 This memo specifies the MTU and frame format for transmission of IPv6 packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an FDDI network. This document replaces RFC 2019, "Transmission of IPv6 Packets Over FDDI", which 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 [KWORD]. 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-fddi-net-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-trans-fddi-net-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-trans-fddi-net-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: <19970725111720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-trans-fddi-net-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-trans-fddi-net-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970725111720.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 Jul 29 08:01:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06777; Tue, 29 Jul 1997 07:53:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA06770; Tue, 29 Jul 1997 07:53:10 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA11967; Tue, 29 Jul 1997 07:55:30 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA00391 for ; Tue, 29 Jul 1997 07:55:30 -0700 Received: from rtpmail02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA66720; Tue, 29 Jul 1997 10:55:28 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA17468 for ; Tue, 29 Jul 1997 10:55:27 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA26330; Tue, 29 Jul 1997 10:55:26 -0400 Message-Id: <9707291455.AA26330@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4196) ND: Change default prefix Lifetime from infinity? Date: Tue, 29 Jul 1997 10:55:26 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2994 Folks, In updating the ND document, Erik & I have come up against an issue we need feedback on. The ND spec currently specifies that routers should advertise prefixes with a default valid Lifetime of infinity. We propose reducing it to something much shorter (e.g., 60 days). Our motivation is the following: - The spec today says that once a host has formed an address from an address via addrconf, it can use it until the prefix/address expires, either through the normal Lifetime expiration, or if a subsequent RA bumps down the Lifetime. - Because nodes may be powered off when RAs get sent out that reduce the Lifetime of a prefix to something shorter (i.e., in anticipation of a renumbering), a router must continue advertising such prefixes with a 0 lifetime even (long) after the prefix should no no longer in use. This advertising must continue essentially forever, to ensure that machines that are "away" for long periods of time learn of the changed Lifetime and stop using the address. - Although having an address with a long Lifetime might seem to improve robustness, this does not appear to be true. An address does one little good unless you have a neighboring router *and* that router (and the routing infrastructure as a whole) properly routes packet for the prefix the address was formed from. But if you have routers nearby, you'll get RAs that (presumably) contain the most correct prefix information. That information should always be better (i.e., more usable, more correct) than something that has been cached by a host for a long period of time and that the router isn't even advertising anymore. In other words, using an address/prefix that routers aren't advertising in RAs may well mean that the address won't work. - Hardcoding infinity in the spec today is going to be something that is hard to reverse in the future once widescale deployment takes place. Once hosts have started caching those infinite Lifetimes, we'll never stamp them all out. So it seems prudent to rethink the use of a infinite Lifetimes for a default. Of course a system administrator can still override the default and use infinite Lifetimes; we're only suggesting that the default behavior change. Erik added a nice section on renumbering issues to the ND spec that discuss the infinite lifetime issue in more detail. This should help system administrator make informed decisions. As a strawman, we propose setting the default to 60 days. That's still *really* long. Does it make sense for host be using addresses/prefixes that neighboring routers haven't advertised for two months? Comments? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 08:32:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06835; Tue, 29 Jul 1997 08:22:21 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06828; Tue, 29 Jul 1997 08:22:11 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA18351; Tue, 29 Jul 1997 08:24:31 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA09179 for ; Tue, 29 Jul 1997 08:23:57 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA24007; Tue, 29 Jul 1997 11:05:14 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA15946; Tue, 29 Jul 1997 11:05:08 -0400 Message-Id: <9707291505.AA15946@wasted.zk3.dec.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4197) Re: Routing header's Strict/Loose Bit Map In-Reply-To: Your message of "Mon, 28 Jul 1997 11:36:02 MST." Date: Tue, 29 Jul 1997 11:05:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 5626 Steve, >The IPv6 spec defines the Strict/Loose Bit Map in the Routing header to >allow a sender to restrict particular segments of the route to occur only >between neighboring addresses. However, it does not specify how a node >shall decide if given next address is its neighbor. There are at least two >solutions to this specification inadequacy: > > (1) specify a neighborness test, or > > (2) eliminate the Strict/Loose Bit Map from the Routing header altogether. >I would prefer to do (2), because (1) appears to be somewhat complicated >and because I am dubious of the value of strict routing anyway. I think the value of strict is very obvious. It forces each node to be specified and no other node should be in the forwarding path that is not specified. One application for this is a military operation in the field, another is a financial transaction, where both are needed for an Intranet backbone not connected to the "Internet". This is a feature of IPv6 that is useful to those building networks that want control over the forwarding path and this can be done if "strict" is specified in the IPv6 standard. I agree that the test for neighbors is unspecified and I just looked at our code implementation. This does need to be nailed down. Also at some point we need to state how the "flowlabel" affects the forwarding of packets too as other input to you too !!!!! >Presumably, two addresses are considered neighbors if they have been >assigned to interfaces connected to the same link. But how does a node >determine that a given address is a neighbor of one of its own addresses? >A simple test for equality under a subnet mask is inadequate because: >I would add for the purposes of source routing > (a) the node doing the testing may not know any or all of the > subnet masks assigned to the attached link. (ND can be > configured to withhold that information from hosts.) As other input sent to you the onlink-prefix flag is a hint. ALso the NUD state and cache in the implementation can be consulted to set flags for addresses that are onlink. >(b) even an address that tests equal under a subnet mask known > to the node may not be a neighbor because, for example, it > belongs to a mobile node that is away from home. >(I'm assuming that a mobile host away from home should *not* be considered >a neighbor of nodes on its home link, for the purposes of strict routing -- >is that the right assumption?) What is the mechanism to determine if the node is mobile? If the node is a neighbor per my above test assumptions it is a node on my link I know about. So I think whether it is a mobile node or not to the implementation is not relative. The mobile node is at a minimum a virtual neighbor. The question is if I xmit to the mobile node and use some mobile binding update is that like a proxy? I address that below. >A possible test would be based on results of ND exchanges: >- all routers discovered through ND are neighbors, and Yes. >- all hosts discovered through ND are neighbors, excluding those >for whom only a proxy is known. I agree. So the question is a mobile node who has had a binding update to another address a neighbor. I think NO if there is a care-of-address (and I am not sure where mobile IP group is with care-of-addresses for IPv6 as last I heard it was still up for debate and I have not seen a new IPv6 mobile draft come out) is not one of the onlink prefixes and/or part of ND cache. >That's messy because at the point at which the test must be performed >while processing a Routing header, if the node doing the processing had >never previously tried to communicate with the supposed neighbor address, >it would have initiate some sort of communication (e.g., a ping) and then >wait for the ND result to come back before continuing to process the >Route header. This is something that can be specified. I think it should be done in an instaneaous manner. What I mean by this is that if the node does not know of the strict neighbor at the point of the test it should not forward the packet. I would assume that this would be the rare state and most packets would get forwarded if in fact the neighbor test was executed. I think this is a performance optimization we should permit. >According to my definition of neighborness, addresses assigned to each >end of an IPv6-in-IPv6 tunnel would be considered neighbors, since a >tunnel is a (virtual) link. Is that OK, for the purpose of strict >routing, or would we have to special-case that? I agree that a tunnel is a neighbor. But I think it might be good to have another bit that says forward or don't forward if its a tunnel interface. We have reserved bits. >What have implementors done about this, if anything? Would anyone object >if we just tossed the strict routing feature altogether? I would object to tossing it. We see if route to the address exists based on ND paramters, which is an incomplete test, so specifying it better would be good. I also don't think this is messy. We can add a mask to addrs structures to be set from the hueristics we want to specify. This can be checked when the strict/loose code path of the rt header type 0 is excecuted. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 08:40:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06854; Tue, 29 Jul 1997 08:29:51 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06847; Tue, 29 Jul 1997 08:29:37 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA20032; Tue, 29 Jul 1997 08:31:57 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA11785 for ; Tue, 29 Jul 1997 08:31:10 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA21891; Tue, 29 Jul 1997 11:17:48 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA04564; Tue, 29 Jul 1997 11:17:40 -0400 Message-Id: <9707291517.AA04564@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: (IPng 4198) Re: security problem: RAs with 0 lifetime prefixes In-Reply-To: Your message of "Tue, 22 Jul 1997 11:57:12 -0400." <9707221557.AA24068@cichlid.raleigh.ibm.com> Date: Tue, 29 Jul 1997 11:17:39 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3663 Thomas, >Received: from rtpmail01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) > id AA56824; Tue, 22 Jul 1997 11:57:14 -0400 >Per the Memphis meeting, I've had on my plate the task of proposing >some specfic text that addresses the "0 lifetime" denial-of-service >problem in the addrconf document. One message that seemed to have been >clear is "keep it simple". >Erik Nordmark and I have been exchanging ideas/text for a bit, and >here is some specific wording I'm proposing as a strawman. > >In Section 5.5.3 (Router Advertisement Processing) of the addrconf >document, add the following two checks: > e) If the prefix advertised matches the prefix of an autoconfigured > address (i.e., one obtained previously via stateless or stateful > autoconfiguration) in the list of addresses associated with the > interface, and the valid lifetime in the received RA is both less > than 2 hours and less than the remaining valid Lifetime in the > cached entry, ignore the Prefix Information option for the purpose > of stateless address autoconfiguration. I object. After thinking about this I think its a bad idea. Scenario: On the Host. valid time = 10 days pref time = 2 days RA = valid time = 0 pref time = 0 I would drop the RA from your above tests. That is bogus. The admin may want me to just kill the address and the implementation should do so. > f) If the prefix advertised matches the prefix of an autoconfigured > address (i.e., one obtained previously via stateless or stateful > autoconfiguration) in the list of addresses associated with the > interface, and the preferred lifetime in the received RA is both > less than 2 hours and less than the remaining preferred Lifetime in > the cached entry, ignore the Prefix Information option for the > purpose of stateless address autoconfiguration. Again I object. Admin may want to reduce the threshhold of pref time in an emergency as a waring. This must be permitteed. Right now I would object completely at last call and to the IESG. >3) Intuitively does the right thing. By that, I mean that if a host >boots, and routers are advertising Lifetimes of less than 2 hours, the >host will configure such addresses. Other rules that had been under >consideration (e.g., ignore all lifetimes less than 2 hours, increase >a received value to 2 hours under some circumstances, etc.) might >>result in recently booted hosts not configuring the same >prefixes/Lifetimes as other hosts that had booted longer ago than the 2 >hour window. That might lead to sys admin confusion. >Unless I hear otherwise, the proposed text will go into the addrconf >draft. I think what you need to do is state if implementations want to not bee attacked by bogus lifetimes implement IPsec, but don't change this feature of IPv6 addr conf. /jim 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 29 09:14:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06936; Tue, 29 Jul 1997 09:05:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06929; Tue, 29 Jul 1997 09:05:21 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA28821; Tue, 29 Jul 1997 09:07:40 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA23755 for ; Tue, 29 Jul 1997 09:07:37 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA28836 for ; Tue, 29 Jul 1997 11:44:42 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA06514; Tue, 29 Jul 1997 11:44:39 -0400 Message-Id: <9707291544.AA06514@wasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4199) IPv6 API Update to RFC 2133 Date: Tue, 29 Jul 1997 11:44:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 9538 Folks, I suggest we nail down an update to RFC 2133 by Oct 1st 97. ISVs are beginning to port to IPv6 and we want to Nail this down. We don't want to be doing major revisions to the Base API after 1997. Here is some input I received anonymously and I think it gets to the heart of the matter. I also attached Eriks' recent input on this thread for continuity. I think getaddrinfo can solve the one api issue, but I now believe we need to specify the interfaces used by getaddrinfo to be "thread safe". These interfaces can also be used by developers who do not want to change their application to use getaddrinfo. We also now neeed to look at if we need new parts to getaddrinfo. Having implemented parts of this spec three times now I concur with the attached mail and also that the functionality is needed. During August I would like to get all to send in functionality not listed or you now find you need from your prototype experiences or input from your customers or ISVs. I do ask we move this discussion from the abstract to the concrete. I will ask my co-authors of RFC 2133 if we can during Sept complete a revision and get it out for review and input from XNET. Based on this discussion thread. No response means your a happy camper. thanks /jim --------------------------------------- 1) We need to allow the user to toggle the behavior of the interface(s) that perform hostname to address lookups. 2) The syntax and semantics of the API must be name service independent 3) Minimize the number of new interfaces that perform the task of hostname lookups. The ideal number is one. 4) The syntax and semantics of the API should be consistent with the existing family of interfaces. 5) The API needs to be able to work in a multi-threaded environment. I think that the first two goals have not been adhered to in the current id of the base spec. I would like to see the hostname-to-address translation routines specified in a name service independent manner. Currently, most implementations have hosts that support multi name services (dns, nis, nis+, others). Usually they are implemented using some "switch" mechanism. We need to define an interface that is not specific to one of the name services to "toggle" the behavior of the hostname-to-address translation interface (e.g., gethostbyname2()). Note that a name service can define its own options or toggles that are specific to it, but we need to define a standard generic mechanism to perform hostname lookups. The way this can be dealt with in rfc is that the generic stuff is listed in the main section and a seperate section that standardizes dns options is dealt with. Now that leads me into the issue of what type of "toggles" are needed. We need to allow the application to "toggle" the behavior of the gethostbyname2() (or whatever the interface name is). We need to standardize these toggles. The current toggles outlined using the resolver option (RES_USE_INET6) don't meet all of the needs that the application my have. It is my feeling (from my own prototype work) that we need to extend the toggles to include: 1) return all addresses : both pure IPv6 addresses and IPv4-mapped IPv6 addresses (the pure Ipv6 addresses are returned at the top of the list). 2) return all pure IPv6 addresses; if none exist return NULL. 3) return only IPv4 addresses; if none exist return NULL. 4) return only IPv4-mapped addresses; if none exist return NULL. (*) 5) Do not filter out pure IPv6 addresses if I am a IPv6 capable host that has no v6 configured interfaces. (*) footnote: - By default the name service switch would filter out pure IPv6 addresses on an IPv6 capable host that has no v6 configured interfaces. We need a toggle to the gethostbyname2() interface so that certains applications have the option to "turnoff" this filter (e.g., getent command). One possible way to implement the filtering of pure IPv6 addresses on an IPv6 capable but not v6 configured host is to provide a check in the switch code to determine if the host has a v6 configured interface. If it does have a v6 configured interface, some global flag in the switch is set indicating "filter out pure v6 addresses". Each time a gethostbyname2() call is made the flag is checked to see if filtering is needed. The ifconfig utility will need to communicate (somehow) that it has configured (or unconfigured the last) v6 interface. The flag in the switch will always need to be kept current as to "whether we are on a v6 capable host that has no v6 configured interfaces". -------------------------------------------------------------------- ------- Forwarded Message Return-Path: owner-ipng@sunroof.eng.sun.com Received: from quarry.zk3.dec.com by mailhub1.zk3.dec.com (5.65v3.2/1.1.10.5/24Sep96-0323PM) id AA22544; Wed, 23 Jul 1997 13:17:57 -0400 Received: from mail11.digital.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA06112; Wed, 23 Jul 1997 13:17:49 -0400 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id NAA05682 for ; Wed, 23 Jul 1997 13:10:41 -0400 (EDT) Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA29580; Wed, 23 Jul 1997 10:22:03 -0700 Received: from sunroof.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA00545; Wed, 23 Jul 1997 09:52:06 -0700 Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08274; Wed, 23 Jul 1997 09:28:34 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08267; Wed, 23 Jul 1997 09:28:24 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA04168; Wed, 23 Jul 1997 09:30:33 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA09502; Wed, 23 Jul 1997 09:30:33 -0700 Date: Wed, 23 Jul 1997 09:30:33 -0700 From: Erik.Nordmark@eng.sun.com (Erik Nordmark) Message-Id: <199707231630.JAA09502@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4153) Problem with _res.options in RFC 2133 Cc: Erik.Nordmark@eng.sun.com, paul@vix.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 2133 (in section 6.1) says that an application can modify the beahvior of gethostbyname and gethostbyname2 when it comes to returning IPv4 and IPv6 addresses by uttering: res_init(); _res.options |= RES_USE_INET6; This is bad for the following three reasons: 1. Programming interfaces that use shared global data between the application and the library are bad; they are hard to evolve as the implementation of the library changes. For instance, should the resolver library's implementation of the _res structure change there has to be great care in not changing the offset of the "options" field in the _res structure to prevent breaking binary compatibility. 2. The interface is specifically tried to the DNS resolver and vendors support more than one name service accessible through gethostbyaname. I understand this is often done through some form of nameservice "switch" that direct gethostbyname() calls to the various name services - the resolver being one such name service. Thus I think it would make sense to have the interface use non-resolver specific names so that it can go through the same level of indirection as gethostbyname and friends. 3. The interface does not allow for multithreaded applications where one one thread wants the RES_USE_INET6 behavior and other thread wants the default behavior of gethostbyname and gethostbyname2. I don't know how important a problem this is. What do other vendors with some re-entrant gethostbyname function think? (Often the re-entrant functions are called e.g. gethostbyname_r.) I have a simple proposal for fixing #1 and #2 but we need to determine if #3 needs to be fixed as well. The proposal is to create a functional interface for toggling the RES_USE_INET6 behavior. (Suggestions for a better name are welcome.) int sethostent_inet6(int on); This could be implemented in the DNS resolver as int sethostent_inet6(int on) { res_init(); if (on) _res.options |= RES_USE_INET6; else _res.options &= ~RES_USE_INET6; } The above routine can then be implemented by the various name services such as the local /etc/hosts file, NIS, NIS+, whatever. Erik - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com - -------------------------------------------------------------------- ------- End of Forwarded Message -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 09:25:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06950; Tue, 29 Jul 1997 09:13:58 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA06943; Tue, 29 Jul 1997 09:13:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA00917; Tue, 29 Jul 1997 09:16:04 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA26649 for ; Tue, 29 Jul 1997 09:16:02 -0700 Received: from rtpmail02.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA69882; Tue, 29 Jul 1997 12:13:20 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA27340; Tue, 29 Jul 1997 12:13:19 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20534; Tue, 29 Jul 1997 12:13:18 -0400 Message-Id: <9707291613.AA20534@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4200) Re: security problem: RAs with 0 lifetime prefixes In-Reply-To: Your message of "Tue, 29 Jul 1997 11:17:39 EDT." <9707291517.AA04564@wasted.zk3.dec.com> Date: Tue, 29 Jul 1997 12:13:18 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2685 Jim, > Scenario: > On the Host. > valid time = 10 days > pref time = 2 days > > RA = > valid time = 0 > pref time = 0 > I would drop the RA from your above tests. According to the proposed rules, yes. > That is bogus. The admin may want me to just kill the address and the > implementation should do so. What the proposed rules had *intended* to permit was for the system administrator to send out something like: RA = valid time = 3 hours pref time = 2 hours Which would still allow the sys admin to bump down the time to something reasonable in a fairly timely manner. I'll agree this isn't as flexible as allowing a sys admin to set the lifetime to 0 and have it go into effect immediately. The thought is that allowing them to have something time out in 2 hours was reasonable enough. > That is bogus. The admin may want me to just kill the address and the > implementation should do so. You have a choice. Leave your implementation vulnerable to a denial-of-service attack, or disallow the sys admin from reducing Lifetimes to 0 and have the change take effect *immediately*. Without encryption-based authentication, there is no way for a host to know whether a request to change a Lifetime to 0 is legit or not. Having said that, your message does point out another problem (one for which I don't have an easy fix). In a message sent to the list earlier today, I argued against the use of infinite Lifetimes. The problem is that if a prefix with an infinite Lifetime is ever lowered, the router needs to advertise a 0 Lifetime essentially foreover, to make sure that all hosts (including those that are powered down) receive an RA with the updated Lifetime. With the proposed rules added to addrconf, the 0 Lifetime prefix would always be ignored because it is less thatn 2 hours. Advertising prefixes at 2 hours doesn't work either, because nodes would install the prefix, and then on each subsequent reception, bump the Lifetime in the cache back to 2 hours; the prefix would never time out. There are several ways do address this, but they seem to need a special value that means "start the 2 hour timer now" if you have a cached entry, but ignore completely otherwise. Not hard, but yet another special case. Any better suggestions? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 10:44:21 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07218; Tue, 29 Jul 1997 10:31:43 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07211; Tue, 29 Jul 1997 10:31:21 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA07704; Tue, 29 Jul 1997 10:33:42 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA15749; Tue, 29 Jul 1997 10:33:40 -0700 Date: Tue, 29 Jul 1997 10:33:40 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707291733.KAA15749@bobo.eng.sun.com> To: bound@zk3.dec.com Subject: (IPng 4201) Re: security problem: RAs with 0 lifetime prefixes 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: 1828 > RA = > > valid time = 0 > pref time = 0 > > I would drop the RA from your above tests. > > That is bogus. The admin may want me to just kill the address and the > implementation should do so. It is a tradeoff between allowing the admin to immediately kill the prefix and the rogue node on the link that can multicast a single RA packet (containing zero lifetime for all the links prefixes) to have all the addresses on all the nodes immediately time out. I think the addrconf specification says that the implementation should kill the TCP connections when the address becomes invalid. Thus the rogue node can kill all TCP connections for all nodes on a link by sending a single packet. While I agree that it would be nice if the admin could say "kill this prefix now" I think the risk of the above denial of service attack is to great to provide that feature to the admin. We need to ensure that IPv6 as a whole does not introduce new security weaknesses - we have enough existing denial of service attacks in the TCP/IP stack and I don't see why IPv6/ND/addrconf needs to add new ones. I don't think we can say that the only solution is to use IPsec for all router advertisements since there isn't even a specification how you could bootstrap IPsec, addrconf, and ND using only authenticated router advertisements. (The issue is how do you distribute the keys before you have an address with sufficient scope.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 11:59:07 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA07359; Tue, 29 Jul 1997 11:45:59 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA07351; Tue, 29 Jul 1997 11:45:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA15026; Tue, 29 Jul 1997 11:47:40 -0700 Received: from epilogue.com (rurha-pente.epilogue.com [128.224.2.24]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA20321 for ; Tue, 29 Jul 1997 11:47:38 -0700 Received: from rurha-pente.epilogue.com by rurha-pente.epilogue.com id aa00525; 29 Jul 97 14:47 -0400 To: michael@stb.info.com cc: ipng@sunroof.eng.sun.com, naipr@arin.net Subject: (IPng 4202) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. In-Reply-To: Message from Michael Gersten dated "Fri, 18 Jul 97 16:21:00 PDT" References: Date: Tue, 29 Jul 1997 14:47:27 -0400 From: Rob Austein Message-ID: <9707291447.aa00525@rurha-pente.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1192 Sorry for the delayed response, I'm reading the IPng list in batch mode again. The idea of stuffing routing information into the DNS is something that comes up every few years. It turns out to have some technical problems, even assuming that DNSSEC would solve all the security issues (a point that would need careful examination). Chief among these is that it creates a circular dependency between DNS and IP routing (you need the routing information to send the IP packets to the DNS servers to get the routing information to send the IP packets to the DNS servers...). I'm not saying that it's impossible, but you should think very carefully about every phase of the bootstrap behavior, and about whether or not it's worth adding yet another protocol to the critical path for basic IP connectivity. --Rob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 29 12:44:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07434; Tue, 29 Jul 1997 12:30:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07427; Tue, 29 Jul 1997 12:30:14 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA26486; Tue, 29 Jul 1997 12:32:33 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA04426 for ; Tue, 29 Jul 1997 12:32:35 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA10368; Tue, 29 Jul 1997 15:27:00 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA20893; Tue, 29 Jul 1997 15:26:54 -0400 Message-Id: <9707291926.AA20893@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4203) Re: security problem: RAs with 0 lifetime prefixes In-Reply-To: Your message of "Tue, 29 Jul 1997 12:13:18 -0400." <9707291613.AA20534@cichlid.raleigh.ibm.com> Date: Tue, 29 Jul 1997 15:26:53 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3537 Thomas, >What the proposed rules had *intended* to permit was for the system >administrator to send out something like: > RA = > valid time = 3 hours > pref time = 2 hours >Which would still allow the sys admin to bump down the time to >something reasonable in a fairly timely manner. I'll agree this isn't >as flexible as allowing a sys admin to set the lifetime to 0 and have >it go into effect immediately. The thought is that allowing them to >have something time out in 2 hours was reasonable enough. OK lets suppose the admin sent out the wrong time and worse yet wrong prefix. They want to get it to zero so I cannot stop being used "immediately". I think all admins in the world will want to be able to perform the "immediate kill" solution by valid gets zero. >> That is bogus. The admin may want me to just kill the address and the >> implementation should do so. >You have a choice. Leave your implementation vulnerable to a >denial-of-service attack, or disallow the sys admin from reducing >Lifetimes to 0 and have the change take effect *immediately*. Without >encryption-based authentication, there is no way for a host to know >whether a request to change a Lifetime to 0 is legit or not. I don't agree. We are building and spending a lot of resources, time, and money to support IPsec. This will include encryption and authentication. IN fact for IPv6 it is MANDATORY. So I think those who are worried about this should use IPsec. That way the IP layer MUST be secure via encrption or authentication. We are opening an entire can of paranoid worms here when we have a perfectly good security answer. Do what you did for ND specifiy IPsec MAY be used. Why else have required IPsec as MANDATORY for IPv6 than for this very reason we are discussing. I don't think there will be any vendor who does not support IPsec because they don't want to be non-compliant for IPv6. The solution you propose is simply not needed. >Having said that, your message does point out another problem (one for >which I don't have an easy fix). In a message sent to the list earlier >today, I argued against the use of infinite Lifetimes. The problem is >that if a prefix with an infinite Lifetime is ever lowered, the router >needs to advertise a 0 Lifetime essentially foreover, to make sure >that all hosts (including those that are powered down) receive an RA >with the updated Lifetime. Exactly. I will respond to that mail later though OK. >With the proposed rules added to addrconf, the 0 Lifetime prefix would >always be ignored because it is less thatn 2 hours. Advertising >prefixes at 2 hours doesn't work either, because nodes would install >the prefix, and then on each subsequent reception, bump the Lifetime >in the cache back to 2 hours; the prefix would never time out. Exactly and I maintain we are weaving a web that will screw us all up. >There are several ways do address this, but they seem to need a >special value that means "start the 2 hour timer now" if you have a >cached entry, but ignore completely otherwise. Not hard, but yet >another special case. This is just not needed use IPsec. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 13:12:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07471; Tue, 29 Jul 1997 12:59:35 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA07464; Tue, 29 Jul 1997 12:59:08 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA02935; Tue, 29 Jul 1997 13:01:25 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA12901; Tue, 29 Jul 1997 13:01:26 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA27068; Tue, 29 Jul 1997 15:42:09 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA21884; Tue, 29 Jul 1997 15:42:06 -0400 Message-Id: <9707291942.AA21884@wasted.zk3.dec.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4204) Re: security problem: RAs with 0 lifetime prefixes In-Reply-To: Your message of "Tue, 29 Jul 1997 10:33:40 MST." <199707291733.KAA15749@bobo.eng.sun.com> Date: Tue, 29 Jul 1997 15:42:05 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3368 Erik, >It is a tradeoff between allowing the admin to immediately kill the >prefix and the rogue node on the link that can multicast a single >RA packet (containing zero lifetime for all the links prefixes) >to have all the addresses on all the nodes immediately time out. Sure. But I think the trade-off is not fully discussed. If we were doing this in our own company as engineers building a product and we knew the customer would want to kill the valid timer we would have to discuss what tools we have to develop a win-win scenario for our company and the customer. I would suggest to you that we have just built this IPsec thing and it does secure the IP layer so a rogue node would have to break into my 128bit Triple-DES encryption scheme or the packet would not get parsed to the icmpv6 ND msg because it failed at the point I parsed the IPv6 header sec option in ip_xxxx.c module. Also what are the percentages of nodes that will get broken into this inmanner and via a rogue node on the network of an "Intranet" (which most of our customers are as opposed to the Internet for ND in IPv6). Then of those percentages how many of them would be reduced via IPsec. >I think the addrconf specification says that the implementation should >kill the TCP connections when the address becomes invalid. I think so and I wrote the code reading the spec and that is what I do as soon as I see a valid time of ZERO. ..the address party is over folks....----)... >Thus the rogue node can kill all TCP connections for all nodes >on a link by sending a single packet. Yes. It can without security. But imagine what a rogue node could do to all nodes with ND link-layer addressees too. Where do we stop and get on with IPv6 Draft Standard and then Full Standard. We can do this forever. That is why we built IPsec. >While I agree that it would be nice if the admin could say "kill this >prefix now" I think the risk of the above denial of service attack >is to great to provide that feature to the admin. >We need to ensure that IPv6 as a whole does not introduce >new security weaknesses - we have enough existing denial of service >attacks in the TCP/IP stack and I don't see why IPv6/ND/addrconf >needs to add new ones. I don't agree. I don't think we are creating a denial of service attack. We are creating an efficient mechanism and have more freedom to do that because of IPsec. So I take a different posture and I guess philosophy on the spec. Also I think this fix will introduce new bugs and before we do that why do you or Thomas not believe IPsec is the fix? As a MAY not as a MUST. Or as you have it specified in ND. /jim I don't think we can say that the only solution is to use IPsec for all router advertisements since there isn't even a specification how you could bootstrap IPsec, addrconf, and ND using only authenticated router advertisements. (The issue is how do you distribute the keys before you have an address with sufficient scope.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 20:16:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08144; Tue, 29 Jul 1997 20:07:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08137; Tue, 29 Jul 1997 20:06:54 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA16372; Tue, 29 Jul 1997 20:09:14 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA24515; Tue, 29 Jul 1997 20:09:15 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA16429; Tue, 29 Jul 1997 23:01:38 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA06655; Tue, 29 Jul 1997 23:01:37 -0400 Message-Id: <9707300301.AA06655@wasted.zk3.dec.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4205) Re: security problem: RAs with 0 lifetime prefixes In-Reply-To: Your message of "Tue, 29 Jul 1997 10:33:40 MST." <199707291733.KAA15749@bobo.eng.sun.com> Date: Tue, 29 Jul 1997 23:01:37 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1699 Erik, Apology. I did not respond to your last paragraph. So I will now. >I don't think we can say that the only solution is to use IPsec >for all router advertisements since there isn't even a specification >how you could bootstrap IPsec, addrconf, and ND using only authenticated >router advertisements. (The issue is how do you distribute the keys before >you have an address with sufficient scope.) You can do it with a link-local address. In fact we can build an entire link network with IPv6 and not have addr conf or DHCPv6 as long as everything is only on the link. FE80::....... I believe you could even use SSL with Netscape with link-local addresses or any application. I can ftp to my nodes in Digital on the same link as me using link-local addresses. So the address issue on the link is a null issue. As far as bootstraping it. That is not an IETF specification. But, the node comes up with a link-local address. The association is kicked off as a daemon using ISAKMP-OAKLEY with some Domain of Interpretation (DOI) and then PF_KEY2 API is used to set the associations in the kernel to IPsec implementation. IPsec is then turned on. How the keys are distributed is an IPsec implementation issue but I defer to the IPsec group and the folks doing the ANX IPsec bake-offs as we speak. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 20:39:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08181; Tue, 29 Jul 1997 20:30:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08174; Tue, 29 Jul 1997 20:29:54 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA21272; Tue, 29 Jul 1997 20:32:15 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA01209 for ; Tue, 29 Jul 1997 20:32:15 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA04954; Tue, 29 Jul 1997 23:25:49 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA07409; Tue, 29 Jul 1997 23:25:43 -0400 Message-Id: <9707300325.AA07409@wasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4206) Re: ND: Change default prefix Lifetime from infinity? In-Reply-To: Your message of "Tue, 29 Jul 1997 10:55:26 -0400." <9707291455.AA26330@cichlid.raleigh.ibm.com> Date: Tue, 29 Jul 1997 23:25:42 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3584 Thomas and (Erik), I have no problem with the default being 60 days. OK. But I think I have a problem with the logic presented for renumbering: >- Because nodes may be powered off when RAs get sent out that reduce >the Lifetime of a prefix to something shorter (i.e., in anticipation >of a renumbering), a router must continue advertising such prefixes >with a 0 lifetime even (long) after the prefix should no no longer in >use. This advertising must continue essentially forever, to ensure >that machines that are "away" for long periods of time learn of the >changed Lifetime and stop using the address. AND >- Hardcoding infinity in the spec today is going to be something that >is hard to reverse in the future once widescale deployment takes >place. Once hosts have started caching those infinite Lifetimes, we'll >never stamp them all out. So it seems prudent to rethink the use of a >infinite Lifetimes for a default. Of course a system administrator can >still override the default and use infinite Lifetimes; we're only >suggesting that the default behavior change. Erik added a nice section >on renumbering issues to the ND spec that discuss the infinite >lifetime issue in more detail. This should help system administrator >make informed decisions. It is the preferred timer that is the essence of renumbering. Admins use the preferred timer to have nodes become aware its time to look for a new address. Or better yet to begin to stop new connections in OR out. In additon this should list in net utilities as DEPRECATED ADDRESS as status in my opinion in implementations. So an admin can set up a policy with IPv6 as follows: 1. Turn on vendor option for IPv6 that when an address is deprecated that all new connections are not permitted. All Host nodes at this site would turn this option on. 2. If admin wants to renumber their subnets (I will assume we have Bob Hindens RR for ROuters) Hosts, the routers are directed to send out changes to valid and preferred times. 3. So for this discussion lets say it will happen in 8 hours. 4. Routers send out: valid = 7.5 hours (lets give grace of 1/2 hour) pref = 7.0 hours Per the site policy at 7 hours all new connections will be stopped for 1 hour. Existing connections will be permitted for 1/2 hour longer. At 7.5 hours all connections are stopped. At that time new RAs are provided to begin renumbering of the nodes. So in 30 minutes all nodes are renumbered and no human intervention was required at the hosts. Th down side is that the existing connections were killed and nodes were not able to communicate off the subnet for 1 hour.. I am working on a dyn IP addr update thingee but want to get it implemented a bit before moving it into the IETF. But I don't think its worth not killing these apps in most cases, but if we really want to do that I can say more about my work in D.C. at Dec 97 IETF. So whatever you all are doing I suggest not messing up what we can do today without discussion before a major draft. Adding to the above to make it better would be great of course. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jul 29 22:17:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA08351; Tue, 29 Jul 1997 22:09:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA08344; Tue, 29 Jul 1997 22:09:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA02418; Tue, 29 Jul 1997 22:11:26 -0700 Received: from stb.info.com (1Cust50.tnt1.lancaster.ca.da.uu.net [208.254.35.50]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA20723 for ; Tue, 29 Jul 1997 22:11:26 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0wtR2Q-000ZHaC; Tue, 29 Jul 97 22:11 PDT Message-Id: Date: Tue, 29 Jul 97 22:11 PDT From: Michael Gersten To: michael@stb.info.com, sra@epilogue.com Subject: (IPng 4207) Re: An idea to bounce off people: storing routing info in the DNS instead of the routers. Cc: ipng@sunroof.eng.sun.com, naipr@arin.net Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3085 I'm not looking at storing all the routing info in the DNS. Just a carefully selected subset. (A large subset) I'm also assuming that a DNS server has a secondary not on the same net. Specifically, I'm assuming that the in-addr.arpa zone file for a host (which would be the authority of last resort for which provider it connects through) would be duplicated at the ISP, or that the ISP's would be secondaried by the backbone. Hmm, I just realized that I'm also assuming that the root info is available. If all I know is the IP address of a root, and there is nothing in anyone's cache, then the request can go out to the backbone, but from there, are any of the 9 roots a backbone site? (ISI, USC, a .gov or two, where are the others?) Actually, even if they are backbone sites, the routing info wouldn't be there (only the summary of how to reach the backbone). Once you get that solved, the NS's for the in-addr.arpa can be identified (the ISP) and their A's, and then you ask for ... Ok, so bootstrapping this is not as straight forward as I thought. Give me a moment... Assume we can reach the root. (add 9 more routes to the routing table) Ok, it can work if we require that one of the secondaries for the in-addr.arpa zone be the same site listed as your IP forwarder. Then, to look up a site, you query the root for the A, the root returns an NS for the top level domain, and some A's; you look up the IP forwarders for those A's (an in-addr.arpa query), and then, since we are [now] requring that those be secondaried upstream, that query will work. Ok, so to make this faster (:-), just as you return additional A records, you'd also have the DNS server return additional IP forwarder records [IPF? IPX is already taken :-) ] Note that there is one unexpected side affect of this: If the "true roots" are blessed and in the global routing tables for this to work, then no one else can start another root. Unless they put their IP forwarder info in the cache. Thats it. You don't need to put the root routing info in the routing tables. You put it in the cache. You require that anyone who has a forwarder entry have that forwarder act as a secondary for the in-addr.arpa zone file. You speed the system up by returning both A and forwarder entries when you return an NS entry. And, you return the forwarder as an additional when you return an A. Essentially, you return the forwarder info any time you'd return the A. That solves the routing/DNS circular loop, and allows for clean bootstrapping. [Remember: This does NOT put the backbone routing info, which changes every second, in the DNS; it puts the networks off the backbones, which might change once a month, in the DNS] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 29 22:37:23 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA08368; Tue, 29 Jul 1997 22:28:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA08361; Tue, 29 Jul 1997 22:28:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA04170; Tue, 29 Jul 1997 22:30:43 -0700 Received: from stb.info.com (1Cust50.tnt1.lancaster.ca.da.uu.net [208.254.35.50]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA24063 for ; Tue, 29 Jul 1997 22:30:44 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0wtRLL-000ZHaC; Tue, 29 Jul 97 22:30 PDT Message-Id: Date: Tue, 29 Jul 97 22:30 PDT From: Michael Gersten To: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4208) Re: IPv6 API Update to RFC 2133 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1386 I think that REQUIRING (I.e, MUST) the name lookups to be multithreaded would be a huge win. Consider a system where you have name information that can come from a bunch of possible places -- local database, network wide database, or the internet's DNS system. Consider the possibility that a system decides to put all of this in one place; one program that gets RPC calls from all other programs via the gethostbyname() library routine; this one program gets updated to add new features/lookup locations. Consider that if all the database lookups fail, that it relies on gethostbyname() -- the real, query the DNS one. Consider that if that routine is non-multithreaded, that _EVERY_ request on the entire system becomes serialized. Now, would any actual vendor ship a product like that? Naawww, they're way to smart for that, right? Right. Some browsers, possibly some proxy servers, will cache name->IP mappings, to avoid the serialization of these lookups when operating multithreaded. Michael -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 30 12:10:19 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09246; Wed, 30 Jul 1997 12:01:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09239; Wed, 30 Jul 1997 12:01:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA04849; Wed, 30 Jul 1997 11:24:47 -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 LAA25629 for ; Wed, 30 Jul 1997 11:24:22 -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 LAA00324 for ; Wed, 30 Jul 1997 11:24:19 -0700 Message-Id: <3.0.3.32.19970730112257.03167b7c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 30 Jul 1997 11:22:57 -0700 To: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org (by way of Bob Hinden ) Subject: (IPng 4209) I-D ACTION:draft-souvatzis-ipv6-arcnet-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3424 A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Method for the Transmission of IPv6 Packets over ARCnet Networks. Author(s) : I. Souvatzis Filename : draft-souvatzis-ipv6-arcnet-03.txt Pages : 5 Date : 07/29/1997 This memo specifies a frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses on ARCnet networks. It also specifies the content of the Source/Target Link-layer Address option used by the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an ARCnet. 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-souvatzis-ipv6-arcnet-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-souvatzis-ipv6-arcnet-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-souvatzis-ipv6-arcnet-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. Content-Type: text/plain Content-ID: <19970729155401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-souvatzis-ipv6-arcnet-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 Wed Jul 30 12:43:08 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09297; Wed, 30 Jul 1997 12:32:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09290; Wed, 30 Jul 1997 12:32:38 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA25703; Wed, 30 Jul 1997 12:34:43 -0700 Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA18796 for ; Wed, 30 Jul 1997 12:34:41 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id MAA29162 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id MAA19851 Posted-Date: Wed, 30 Jul 1997 12:34:35 -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 PAA09649; Wed, 30 Jul 1997 15:34:35 -0400 for Message-Id: <3.0.32.19970730153304.006bbd88@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 30 Jul 1997 15:33:05 -0400 To: Thomas Narten From: Dimitry Haskin Subject: (IPng 4210) Re: ND: Change default prefix Lifetime from infinity? 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: 1528 At 10:55 AM 7/29/97 -0400, Thomas Narten wrote: >- Because nodes may be powered off when RAs get sent out that reduce >the Lifetime of a prefix to something shorter (i.e., in anticipation >of a renumbering), a router must continue advertising such prefixes >with a 0 lifetime even (long) after the prefix should no no longer in >use. This advertising must continue essentially forever, to ensure >that machines that are "away" for long periods of time learn of the >changed Lifetime and stop using the address. > I'm not sure that I understand it. My assumption was that if a host was powered off and then came up on a link, it would not have any prefix information or non-link-local addresses prior to receiving a RA (which could be solicited to expedite the autoconfiguration process). You seem to be implying that it is not necessary true and hosts may have pre-configured non-volatile addresses. In this case I'd argue that a host that was statefully configured in the first place should be statefully re-configured when its statefully configured address is to be changed. Dimitry P.S. BTW, I don't mind if the lifetime default is 60 days. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 30 13:03:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09317; Wed, 30 Jul 1997 12:53:25 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA09310; Wed, 30 Jul 1997 12:53:13 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA00656; Wed, 30 Jul 1997 12:55:32 -0700 Received: from socks2.raleigh.ibm.com (socks2.raleigh.ibm.com [204.146.167.123]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA24555 for ; Wed, 30 Jul 1997 12:55:32 -0700 Received: from rtpmail03.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA94672; Wed, 30 Jul 1997 15:55:25 -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 PAA31680; Wed, 30 Jul 1997 15:55:26 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA20618; Wed, 30 Jul 1997 15:55:24 -0400 Message-Id: <9707301955.AA20618@cichlid.raleigh.ibm.com> To: Dimitry Haskin Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4211) Re: ND: Change default prefix Lifetime from infinity? In-Reply-To: Your message of "Wed, 30 Jul 1997 15:33:05 EDT." <3.0.32.19970730153304.006bbd88@pobox> Date: Wed, 30 Jul 1997 15:55:24 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1724 > I'm not sure that I understand it. My assumption was that if a host was > powered off and then came up on a link, it would not have any prefix > information or non-link-local addresses prior to receiving a RA (which > could be solicited to expedite the autoconfiguration process). I think this is a reasonable assumption, and I suspect that many (most?) implementations will do just that. > You seem to be implying that it is not necessary true and hosts may > have pre-configured non-volatile addresses. I may be wrong, but I wouldn't be surprised if some implementations form addresses via stateless addrconf, and then store those addresses on disk. I don't believe that this is prohibited by the spec. Have any implementations chosen to do something like this? Also, getting new RAs may lead to getting new prefixes. An implementation that has stored "old" prefixes that are no longer being advertised may choose to continue using them in addition to using the new ones. > In this case I'd argue that a host that was statefully configured in > the first place should be statefully re-configured when its > statefully configured address is to be changed. In the case I mentioned above, stateful (i.e, DHCP) configuration hasn't taken place. The node has simply chosen to store information received in RAs in stable storage. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 13:19:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09426; Wed, 30 Jul 1997 13:05:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09419; Wed, 30 Jul 1997 13:05:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA03655; Wed, 30 Jul 1997 13:07:38 -0700 Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA28404 for ; Wed, 30 Jul 1997 13:07:40 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id NAA00482 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id NAA04373 Posted-Date: Wed, 30 Jul 1997 13:07:30 -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 QAA12377; Wed, 30 Jul 1997 16:07:30 -0400 for Message-Id: <3.0.32.19970730160601.006ab400@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 30 Jul 1997 16:06:01 -0400 To: Thomas Narten From: Dimitry Haskin Subject: (IPng 4212) Re: ND: Change default prefix Lifetime from infinity? Cc: Dimitry Haskin , 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: 1344 At 03:55 PM 7/30/97 -0400, Thomas Narten wrote: >> I'm not sure that I understand it. My assumption was that if a host was >> powered off and then came up on a link, it would not have any prefix >> information or non-link-local addresses prior to receiving a RA (which >> could be solicited to expedite the autoconfiguration process). > >I think this is a reasonable assumption, and I suspect that many >(most?) implementations will do just that. > >> You seem to be implying that it is not necessary true and hosts may >> have pre-configured non-volatile addresses. > >I may be wrong, but I wouldn't be surprised if some implementations >form addresses via stateless addrconf, and then store those addresses >on disk. I don't believe that this is prohibited by the spec. > Then perhaps it should be prohibited. I don't think changing the default lifetime to 60 days solves the problem -- it is awfully long time to mess with obsolete addresses any way. 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 Jul 30 13:19:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09435; Wed, 30 Jul 1997 13:06:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09428; Wed, 30 Jul 1997 13:05:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA03749; Wed, 30 Jul 1997 13:08:04 -0700 Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA28514 for ; Wed, 30 Jul 1997 13:08:06 -0700 Received: from research.research.bell-labs.com ([135.104.1.3]) by dirty; Wed Jul 30 16:07:27 EDT 1997 Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by research; Wed Jul 30 16:07:29 EDT 1997 Received: from gjapc (gjapc [135.180.130.101]) by zubin.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id QAA03071; Wed, 30 Jul 1997 16:07:42 -0400 (EDT) Message-ID: <33DF9EEC.FDC9709C@dnrc.bell-labs.com> Date: Wed, 30 Jul 1997 16:07:08 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 4213) FYI, IPv6 over ATM update in the ION group X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1879 FYI, ---- A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internetworking Over NBMA Working Group of the IETF. Title : Transient Neighbors for IPv6 over ATM Author(s) : G. Armitage, P. Schulter, M. Jork, G. Harter Filename : draft-ietf-ion-tn-01.txt Pages : 32 Date : 07/29/1997 This document describes an architecture and protocols for IPv6 over ATM. It allows conventional host-side operation of the Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths. This is achieved through the use of Redirects to create Transient Neighbors, standard IPv6 protocol operation within the IPv6 Logical Link, and inter-router NHRP for location of off-Link destinations. Shortcuts are discovered by egress routers when triggered either by detection of suitable packet flows, or source host initiation. NHRP is used to locate a better link level first hop, and the result is announced to the source host using a Neighbor Discovery Redirect message. [..] A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ion-tn-01.txt ---- cheers, gja ________________________________________________________________________ Grenville Armitage Bell Labs, Lucent Technologies http://nj5.injersey.com/~gja -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 30 13:44:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09488; Wed, 30 Jul 1997 13:35:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA09481; Wed, 30 Jul 1997 13:35:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA11535; Wed, 30 Jul 1997 13:37:40 -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 NAA07617 for ; Wed, 30 Jul 1997 13:37:40 -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 NAA21188 for ; Wed, 30 Jul 1997 13:37:38 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Jul 1997 13:37:30 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: (IPng 4214) new draft of base IPv6 spec Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3516 A new draft of the IPv6 spec has been submitted for publication as an Internet Draft. The impatient can fetch it from: ftp://ftp-eng.cisco.com/deering/draft-ietf-ipngwg-ipv6-spec-v2-00.txt A list of changes is included at the end of the draft, and also at the end of this message. The biggest change is the revised description of the Priority field (now named the Class field). I did not delete the Strict/Loose Bit Map from the Routing header, nor did I define a neighborness test -- I hope to do one of those two things after we have finished thrashing out the issues on the list and in Munich. Bob and I did make one last-minute change to the draft that we forgot to include in the list of changes: we deleted the Priority (now Class) field from the set of fields that must be constant for all packets originated with the same flow id. However, it's not clear that that was the right change to make, and Bob and I are still debating about that, so consider that change tentative and we can talk about it in Munich. Steve ------ CHANGES SINCE RFC-1883 This draft has the following changes from RFC-1883. Number indicates which version of internet draft the change was made. 00) In section 4, corrected the Code value to indicate "unrecognized Next Header type encountered" in an ICMP Parameter Problem message (changed from 2 to 1). 00) In the description of the Payload Length field in section 3, and of the Jumbo Payload Length field in section 4.3, made it clearer that extensions headers are included in the payload length count. 00) In section 4.2, made it clearer that options are identified by the full 8-bit Option Type, not by the low-order 5 bits of an Option Type. Also specified that the same Option Type numbering space is used for both Hop-by-Hop Options and Destination Options headers. 00) In section 4.4, added a sentence requiring that nodes processing a Routing header must send an ICMP Packet Too Big message in response to a packet that is too big to fit in the next hop link (rather than, say, performing fragmentation). 00) Changed the name of the IPv6 Priority field to "Class", and replaced the previous description of Priority in section 7 with a description of the Class field. 00) In the pseudo-header in section 8.1, changed the name of the "Payload Length" field to "Upper-Layer Packet Length". Also clarified that, in the case of protocols that carry their own length info (like non-jumbogram UDP), it is the upper-layer- derived length, not the IP-layer-derived length, that is used in the pseudo-header. 00) Added section 8.4, specifying that upper-layer protocols, when responding to a received packet that carried a Routing header, must not include the reverse of the Routing header in the response packet(s) unless the received Routing header was authenticated. 00) Fixed some typos and grammatical errors. 00) Authors' contact info updated. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 30 14:50:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09637; Wed, 30 Jul 1997 14:41:14 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA09630; Wed, 30 Jul 1997 14:41:04 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA19429; Wed, 30 Jul 1997 14:43:27 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA18108; Wed, 30 Jul 1997 14:43:26 -0700 Date: Wed, 30 Jul 1997 14:43:26 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707302143.OAA18108@bobo.eng.sun.com> To: dhaskin@BayNetworks.COM Subject: (IPng 4215) Re: ND: Change default prefix Lifetime from infinity? 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: 1496 > I'm not sure that I understand it. My assumption was that if a host was > powered off and then came up on a link, it would not have any prefix > information or non-link-local addresses prior to receiving a RA (which > could be solicited to expedite the autoconfiguration process). Firstly it is not only the powered off scenario that is interesting. I might just unplug my laptop from the net and walk away with it. It might be weeks until it is plugged into the Ethernet again (it might be plugged in using e.g. PPP in the meantime). Secondly I think there will be implementations that will cache the assigned addresses and their expiry time on disk just like they today cache IPv4 addressed assigned using DHCP. The disk caching makes the system more robust. For instance, if I power on my laptop before I plug in the Ethernet cable it is likely to send the Router Solicitations and not get an answer. If I plug it in after it has stopped sending RS packets, unless I've cached the addresses/lifetimes, the poor host will sit there for many minutes waiting for the next periodic Router Advertisement. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 16:53:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09878; Wed, 30 Jul 1997 16:44:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09871; Wed, 30 Jul 1997 16:44:25 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA06431; Wed, 30 Jul 1997 16:46:45 -0700 Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id QAA05066 for ; Wed, 30 Jul 1997 16:46:46 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id QAA08960 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id QAA23270 Posted-Date: Wed, 30 Jul 1997 16:39:51 -0700 (PDT) Received: from dhaskin.baynetworks.com (eng_ppp24 [192.32.171.164]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id TAA25768; Wed, 30 Jul 1997 19:39:50 -0400 for Message-Id: <3.0.1.32.19970730194243.006a156c@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 30 Jul 1997 19:42:43 -0400 To: Thomas Narten , bound@zk3.dec.com From: Dimitry Haskin Subject: (IPng 4216) Re: security problem: RAs with 0 lifetime prefixes Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9707291613.AA20534@cichlid.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1402 At 12:13 PM 7/29/97 -0400, Thomas Narten wrote: >You have a choice. Leave your implementation vulnerable to a >denial-of-service attack, or disallow the sys admin from reducing >Lifetimes to 0 and have the change take effect *immediately*. Without >encryption-based authentication, there is no way for a host to know >whether a request to change a Lifetime to 0 is legit or not. > Maybe we can do better. What about the following rules? 1) a host should not lower lifetimes of a priorly known prefix as the result of receiving of a directed (unicast) RA. 2) if a host receives a multicast RA with a prefix lifetime of less than 10 seconds (or pick another reasonable period), it should delay deprecation of the prefix for 10 seconds. 3) if a router receives a multicast RA with a prefix that has a lifetime lower than the receiving router advertises for this prefix, it should immediately send own multicast RA. 4) a host receiving RAs from multiple routers should use a higher lifetime for the same prefix. 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 Jul 30 17:44:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10028; Wed, 30 Jul 1997 17:31:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10021; Wed, 30 Jul 1997 17:31:35 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA16752; Wed, 30 Jul 1997 17:33:53 -0700 Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id RAA17055; Wed, 30 Jul 1997 17:33:54 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id RAA11153 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id RAA08971 Posted-Date: Wed, 30 Jul 1997 17:33:50 -0700 (PDT) Received: from dhaskin.baynetworks.com (eng_ppp24 [192.32.171.164]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA27603; Wed, 30 Jul 1997 20:33:48 -0400 for Message-Id: <3.0.1.32.19970730203641.006ae788@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 30 Jul 1997 20:36:41 -0400 To: Erik.Nordmark@Eng (Erik Nordmark), dhaskin@BayNetworks.COM From: Dimitry Haskin Subject: (IPng 4217) Re: ND: Change default prefix Lifetime from infinity? Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199707302143.OAA18108@bobo.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: 2506 At 02:43 PM 7/30/97 -0700, Erik Nordmark wrote: > >> I'm not sure that I understand it. My assumption was that if a host was >> powered off and then came up on a link, it would not have any prefix >> information or non-link-local addresses prior to receiving a RA (which >> could be solicited to expedite the autoconfiguration process). > >Firstly it is not only the powered off scenario that is interesting. >I might just unplug my laptop from the net and walk away with it. >It might be weeks until it is plugged into the Ethernet again >(it might be plugged in using e.g. PPP in the meantime). > I see. And poorly connected cable can get loose while dusted by an inept janitor and get reconnected after the host got kicked the next morning :) In any case I don't see how you solve the problem by reducing the default prefix lifetime to 60 days (not that I mind). 60 days is infinity for all practical purposes. I guess, hosts that can't detect a loss of connectivity to a router within a reasonable period of time are troublesome. Perhaps hosts should be required to periodically probe routers if no other indication of connectivity is available and flush their prefix caches if a loss of connectivity is detected. >Secondly I think there will be implementations that will cache >the assigned addresses and their expiry time on disk just like >they today cache IPv4 addressed assigned using DHCP. The disk caching >makes the system more robust. For instance, if I power on my laptop before >I plug in the Ethernet cable it is likely to send the Router Solicitations >and not get an answer. If I plug it in after it has stopped sending >RS packets, unless I've cached the addresses/lifetimes, the poor >host will sit there for many minutes waiting for the next periodic >Router Advertisement. > Perhaps prefix caching in non-volatile memory should be disallowed for purpose of stateless autoconfiguration. I.e., if a host gets a prefix and subsequently its address from a disk, such an address should be considered as statefully configured regardless of how this prefix was learned in a previous life. > Erik 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 Jul 30 17:51:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10037; Wed, 30 Jul 1997 17:36:19 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10030; Wed, 30 Jul 1997 17:36:06 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01627; Wed, 30 Jul 1997 17:38:28 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA18296; Wed, 30 Jul 1997 17:38:26 -0700 Date: Wed, 30 Jul 1997 17:38:26 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707310038.RAA18296@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4218) New draft of Neighbor Discovery specification Cc: nordmark@jurassic, narten@raleigh.ibm.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 899 We've submitted an update to RFC 1970 for publication as an Internet Draft. If you want a preview you can get it from: ftp://playground.sun.com/pub/nordmark/draft-ietf-ipngwg-discovery-v2-00.txt The document has a list of changes since RFC 1970 at the end and thanks to Jim Bound's suggestion it also has change bars. Apart from the change to the solicited node multicast address most of the changes are clarifications and minor fixes e.g. to the NUD state and how the IsRouter flag is maintained. Erik & Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 17:52:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10046; Wed, 30 Jul 1997 17:37:00 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10039; Wed, 30 Jul 1997 17:36:41 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA01722; Wed, 30 Jul 1997 17:39:04 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA18300; Wed, 30 Jul 1997 17:39:03 -0700 Date: Wed, 30 Jul 1997 17:39:03 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707310039.RAA18300@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4219) Site prefixes draft available MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 913 I've submitted an Internet Draft based on the presentation I did in Memphis on Site Prefixes. If you want a preview before it shows up in the Internet Drafts directories you can get it from: ftp://playground.sun.com/pub/nordmark/draft-ietf-ipngwg-site-prefixes-00.txt Abstract This document specifies extensions to IPv6 Neighbor Discovery to carry site-prefixes. The site prefixes are used to reduce the effect of site renumbering by ensuring that the communication inside a site uses site-local addresses. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 18:08:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10086; Wed, 30 Jul 1997 17:53:04 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA10079; Wed, 30 Jul 1997 17:52:41 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA04690; Wed, 30 Jul 1997 17:55:03 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA18315; Wed, 30 Jul 1997 17:55:01 -0700 Date: Wed, 30 Jul 1997 17:55:01 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707310055.RAA18315@bobo.eng.sun.com> To: dhaskin@BayNetworks.COM Subject: (IPng 4220) Re: ND: Change default prefix Lifetime from infinity? 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: 2342 > I see. And poorly connected cable can get loose while dusted by an inept > janitor and get reconnected after the host got kicked the next morning :) > In any case I don't see how you solve the problem by reducing the default > prefix lifetime to 60 days (not that I mind). 60 days is infinity for all > practical purposes. There is an example in the updated ND specification that explains that infinity is a lot longer time than 60 days. See the new Renumbering Considerations section. > I guess, hosts that can't detect a loss of connectivity to a router within > a reasonable period of time are troublesome. Perhaps hosts should be > required to periodically probe routers if no other indication of > connectivity is available and flush their prefix caches if a loss of > connectivity is detected. The host would detect that the router isn't present but why should that make the host discard the autoconfigured addresses that are still valid (and might be valid for months depending on the lifetimes in the annoucements). Keeping the address causes no harm as long as the host will not try to use the address for the unplugged network interface as a source address when sending packets out other network interfaces. > Perhaps prefix caching in non-volatile memory should be disallowed for > purpose of stateless autoconfiguration. I.e., if a host gets a prefix and > subsequently its address from a disk, such an address should be considered > as statefully configured regardless of how this prefix was learned in a > previous life. Are you saying we should disallow hosts to have robust implementations? Having your host be unusable for 10 minutes longer than necessary just because your host and your router booted faster than than your switch/hub after a power failure doesn't seem very robust to me. DHCP allows caching of addresses with lifetimes. Why does stateless address autoconfig have to behave worse than DHCP in this respect? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jul 30 18:16:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA10127; Wed, 30 Jul 1997 18:04:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA10118; Wed, 30 Jul 1997 18:04:30 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA22626; Wed, 30 Jul 1997 18:06:49 -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 SAA24903 for ; Wed, 30 Jul 1997 18:06:51 -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 SAA19959; Wed, 30 Jul 1997 18:06:50 -0700 Message-Id: <3.0.3.32.19970730180612.0077cdac@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 30 Jul 1997 18:06:12 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4221) Re: security problem: RAs with 0 lifetime prefixes In-Reply-To: <3.0.1.32.19970730194243.006a156c@pobox> References: <9707291613.AA20534@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1875 I wonder if the question we need to answer before we can come to consensus on this topic is how hard do we want to protect from denial of service attacks from on-link sources. I think there are two scenarios: 1) private LAN's where the responsible organization has reasonable control over what is plugged and has some ability to isolate problems, and 2) public LAN's where almost anyone can plug in and there is no control over host software. The first is like most corporate LAN's, the latter is situations like the IETF terminal room LAN's. In the second scenario real authentication of RAs seems like the obvious answer. However this is probably the situation where it is the hardest to set up key servers, hand out keys, etc. All the things necessary to use real authentication. The paradox is that the first scenario where real authentication is needed less, it is the easiest to install it. Note that the situation is very different for router-to-router traffic which is easy to authenticate because the organization providing the service has control of the routers. Where this becomes difficult is in the router-to-host traffic, because of the difficulty in configuring key information on the transient hosts. My conclusion is that it is reasonable to protect against this kind of attack in the absence of real authentication. Perhaps a reasonable compromise for the need to advertise shorter lifetimes, it to only allow them if the RA were authenticated. My two cents... 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 Jul 31 06:18:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA10921; Thu, 31 Jul 1997 06:10:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA10914; Thu, 31 Jul 1997 06:10:48 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA28167; Thu, 31 Jul 1997 06:13:09 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA00861 for ; Thu, 31 Jul 1997 06:13:05 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA07912; Thu, 31 Jul 1997 23:11:57 +1000 (from kre@munnari.OZ.AU) To: Thomas Narten Cc: Dimitry Haskin , ipng@sunroof.eng.sun.com Subject: (IPng 4223) Re: ND: Change default prefix Lifetime from infinity? In-Reply-To: Your message of "Wed, 30 Jul 1997 15:55:24 -0400." <9707301955.AA20618@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 31 Jul 1997 23:11:56 +1000 Message-Id: <4560.870354716@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2894 Date: Wed, 30 Jul 1997 15:55:24 -0400 From: Thomas Narten Message-ID: <9707301955.AA20618@cichlid.raleigh.ibm.com> | I may be wrong, but I wouldn't be surprised if some implementations | form addresses via stateless addrconf, and then store those addresses | on disk. I don't believe that this is prohibited by the spec. I would hope that any implementation which has chosen to do this (if there are any) would at least find some way to verify the addresses before using them after a power off (or similar) restart. Quite apart from the possibility that the address has been deprecated in the meantime, and that the host missed the RA's announcing that it had gone, there's also the possibility that the host is now connected to some quite different link where the address never was valid - is anyone suggesting that RA's need to invalidate every address that isn't valid on the link just in case some node that used to be configured with such an address appears? Nodes should never use any address without finding some way to verify that the address is sane for use on the link where it is proposed to be used (and that probably even includes human configured addresses). Getting an RA advertising the prefix is one way to do that, getting a DHCP response is another. Do we need some other way to validate other addresses? Erik's problem of a disconnected laptop, remaining powered on, also needs attention - such a node has no idea where it will be reconnected. I'd suggest that a node that failes to receive RA packetc (say 3 consecutive expected RA packets) should treat all addresses it has acquired as being of suspicious validity, and validate them again (it can start doing that even while disconnected - obviously the responses, indicating good or bad, won't appear until after a connection is re-established). kre ps: I certainly don't object to changing from infinite to 60 days, though personally I can't see why the default would ever want to be more than a few days - anyone who has an environment where long address lifetimes makes sense can easily configure that - but having an address accidentally allocated for 2 months because of a simple startup with bad config seems like a very heavy penalty to me - make the default 24 hours - that's not so short that it would provide a horrid penalty on sites that don't change it, and also not so long as to be too much of a burden on sites that make mistakes in their initial config. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 31 07:04:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA10955; Thu, 31 Jul 1997 06:55:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA10948; Thu, 31 Jul 1997 06:55:35 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA08799; Thu, 31 Jul 1997 06:57:57 -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 GAA12887 for ; Thu, 31 Jul 1997 06:57:54 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Thu, 31 Jul 1997 09:59:39 -0400 Message-ID: From: "Harrington, Dan" To: ipng@sunroof.eng.sun.com Subject: (IPng 4224) Re: security problem: RAs with 0 lifetime prefixe s Date: Thu, 31 Jul 1997 09:59: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: 910 > 4) a host receiving RAs from multiple routers should use a higher lifetime > for the same prefix. I like Dimitry's proposed rules, as a means of reducing the risk of a single rogue router. But be aware that there is an implied assumption that all hosts will keep track of multiple routers on a given link. I'm not sure that this is a stated requirement of host implementations (although it is certainly an obvious thing to do if you want to be robust). Does ND require all routers to be tracked by a host? Should it? Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jul 31 09:32:06 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11255; Thu, 31 Jul 1997 09:20:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11248; Thu, 31 Jul 1997 09:20:10 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA18522; Thu, 31 Jul 1997 09:22: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 JAA29579 for ; Thu, 31 Jul 1997 09:22:22 -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 JAA17239; Thu, 31 Jul 1997 09:22:21 -0700 Message-Id: <3.0.3.32.19970731092130.031d4240@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 31 Jul 1997 09:21:30 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4225) W.G. Last Call on Addressing and IPv6_over_ Documents 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: 3320 This is a IPng working group last call for comments on advancing the new set of addressing and IPv6_over_ documents. The w.g. last call is being done for this group of documents because they reflect changes to the IPv6 Addressing Architecture agreed to at the Memphis IETF meeting. These changes include interface identifier size and formats, unicast formats, and solicited node multicast definition. The following documents are to be advanced to Proposed Standard: Title : IP Version 6 Addressing Architecture Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-02.txt Pages : 25 Date : 07/16/1997 Title : An IPv6 Aggregatable Global Unicast Address Format Author(s) : R. Hinden, M. O'Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-02.txt Pages : 9 Date : 07/16/1997 Title : Transmission of IPv6 Packets over Ethernet Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-ethernet-02.txt Pages : 6 Date : 07/25/1997 Title : Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-trans-fddi-net-02.txt Pages : 8 Date : 07/25/1997 Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-ipv6-over-ppp-02.txt Pages : 14 Date : 07/02/1997 Title : A Method for the Transmission of IPv6 Packets over ARCnet Networks. Author(s) : I. Souvatzis Filename : draft-souvatzis-ipv6-arcnet-03.txt Pages : 5 Date : 07/29/1997 The following document is to be advanced to BCP: Title : TLA and NLA Assignment Rules Author(s) : R. Hinden, M. O'Dell Filename : draft-ietf-ipngwg-tla-assignment-00.txt Pages : 5 Date : 07/16/1997 The following document is to be advanced to Experimental: Title : IPv6 Testing Address Allocation Author(s) : R. Hinden, R. Fink, J. Postel Filename : draft-ietf-ipngwg-testv2-addralloc-01.txt Pages : 4 Date : 07/16/1997 The following document is to be advanced to Informational: Title : IPv6 Multicast Address Assignments Author(s) : R. Hinden, S. Deering Filename : draft-ietf-ipngwg-multicast-assgn-04.txt Pages : 8 Date : 07/16/1997 Please send substantive comments to the ipng mailing list, and minor editorial comments to the authors. This last call period will end on August 13, 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 Thu Jul 31 10:04:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11306; Thu, 31 Jul 1997 09:55:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA11299; Thu, 31 Jul 1997 09:54:54 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA29320; Thu, 31 Jul 1997 09:57:16 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA12948 for ; Thu, 31 Jul 1997 09:56:59 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1458.49) id ; Thu, 31 Jul 1997 09:59:23 -0700 Message-ID: From: Richard Draves To: "'Dimitry Haskin'" , Thomas Narten , bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4226) Re: security problem: RAs with 0 lifetime prefixe s Date: Thu, 31 Jul 1997 09:56:22 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1458.49) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1867 > 1) a host should not lower lifetimes of a priorly known prefix as the > result of receiving of a directed (unicast) RA. > > 2) if a host receives a multicast RA with a prefix lifetime of less > than 10 > seconds (or pick another reasonable period), it should delay > deprecation of > the prefix for 10 seconds. > > 3) if a router receives a multicast RA with a prefix that has a > lifetime > lower than the receiving router advertises for this prefix, it should > immediately send own multicast RA. > > 4) a host receiving RAs from multiple routers should use a higher > lifetime > for the same prefix. > The approach seems promising but here's a nit to consider: how is a receiving node going to tell if the RA was sent to an appropriate multicast address? Inspecting the IPv6 destination address doesn't do the job properly, because the link-layer destination address may not be consistent. We could mandate some checking in the link layer, to ensure that the link-layer destination address and the IPv6 destination address are consistent. For example discard packets with a multicast IPv6 destination and unicast link-layer destination (and vice-versa). At this point, I believe in a fairly strong isolation between the link layer and the IPv6 layer. For example when a packet is handed up to IPv6 from the link layer, there is no information passed about the link layer source & destination addresses. This kind of consistency-checking would weaken this isolation. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 31 10:38:04 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11454; Thu, 31 Jul 1997 10:26:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11443; Thu, 31 Jul 1997 10:26:28 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA09063; Thu, 31 Jul 1997 10:28:43 -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 KAA25007 for ; Thu, 31 Jul 1997 10:27:48 -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 KAA20658 for ; Thu, 31 Jul 1997 10:27:46 -0700 Message-Id: <3.0.3.32.19970731102705.0075f198@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 31 Jul 1997 10:27:05 -0700 To: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org (by way of Bob Hinden ) Subject: (IPng 4227) I-D ACTION: draft-ietf-ipngwg-router-renum-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3559 --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 : Router Renumbering for IPv6 Author(s) : Bob Hinden and M. Crawford Filename : draft-ietf-ipngwg-router-renum-01.txt Pages : 16 Date : 1997-07-30 IPv6 Neighbor Discovery [ND] and Address Autoconfiguration [AA] conveniently make initial assignments of address prefixes to hosts. Aside from the problem of connection survival across a renumbering event, these two mechanisms also simplify the reconfiguration of hosts when the set of valid prefixes changes. This document defines a mechanism called Router Renumbering (RR) which allows address prefixes on routers to be configured and reconfigured almost as easily as the combination of Neighbor Discovery and Address Autoconfiguration works for hosts. It provides a means for a network manager to make updates to the prefixes used by and advertised by IPv6 routers throughout a site. Internet-Drafts are available by anonymous FTP. Login wih the username 'anonymous' and a password of your e-mail address. After logging in, type 'cd internet-drafts' and then 'get draft-ietf-ipngwg-router-renum-01.txt'. A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-router-renum-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net 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-router-renum-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: <19970730135802.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-router-renum-01.txt --OtherAccess Content-Type: Message/External-body; name='draft-ietf-ipngwg-router-renum-01.txt'; site='ds.internic.net'; access-type='anon-ftp'; directory='internet-drafts' Content-Type: text/plain Content-ID: <19970730135802.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 Thu Jul 31 10:55:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11484; Thu, 31 Jul 1997 10:43:57 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA11477; Thu, 31 Jul 1997 10:43:45 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA28957; Thu, 31 Jul 1997 10:46:09 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18937; Thu, 31 Jul 1997 10:46:08 -0700 Date: Thu, 31 Jul 1997 10:46:08 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707311746.KAA18937@bobo.eng.sun.com> To: dth@lucent.com, dhaskin@BayNetworks.COM Subject: (IPng 4228) Re: security problem: RAs with 0 lifetime prefixe s Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3007 Dimitry Haskin wrote: > 4) a host receiving RAs from multiple routers should use a higher > lifetime > for the same prefix. Can you provide some more details on how this would be implemented? How much state does the host need to keep? (Does the host have to track every prefix based on what router is was received from, when it was received, and the lifetime(s) it contained?) Without requiring some more state about the prefixes that today (i.e. just prefix and lifetimes) I don't see how you can implement the above rule and still be able to lower the lifetime. Today the state is: Prefix P1, lifetime 10 days If you keep From R1: Prefix P1, lifetime 10 days From R2: Prefix P1, lifetime 10 days and 3 minutes From R3: Prefix P1, lifetime 10 days From R4: Prefix P1, lifetime 10 days and 10 minutes From R5: Prefix P1, lifetime 10 days From Rogue R: Prefix P1, lifetime 3 seconds you can clearly implement your rule by computing the max lifetime over all routers. But there are another problem (apart from the additional state): If R1 is turned off and later the network manager wants to lower the lifetime to 1 day it can't be done until the lifetime sent by R1 has expire. (The R1 entry will remain in the hosts state until it times out.) You can work around this by having e.g. R2 send you a RA packet with R1's source address but that is rather gross. Dan Harrington wrote: > I like Dimitry's proposed rules, as a means of reducing the > risk of a single rogue router. But be aware that there is an > implied assumption that all hosts will keep track of multiple > routers on a given link. I'm not sure that this is a stated > requirement of host implementations (although it is certainly > an obvious thing to do if you want to be robust). Does ND > require all routers to be tracked by a host? Should it? There is currently no requirement in the ND spec that a host track all the default routers on a link. A host with limited memory is free to pick some number of routers. I think the spec points out that for robustness they should track more than one default router. Also, there is currently no requirement that the hosts, for each advertised prefix, track which router(s) have advertised that prefix. I think we want the requirements on the hosts to be as small as possible so that relatively memory starved devices can implement IPv6. One possible future development is the creation of very large switches Ethernets which might have lots (say 100) routers attached to a single large switched Ethernet. In such a case I don't think we want to require that every router Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 31 11:21:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA11520; Thu, 31 Jul 1997 11:11:57 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA11513; Thu, 31 Jul 1997 11:11:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA24596; Thu, 31 Jul 1997 11:13:48 -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 LAA11927 for ; Thu, 31 Jul 1997 11:13: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 LAA13930; Thu, 31 Jul 1997 11:13:11 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Jul 1997 11:13:01 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 4229) Re: security problem: RAs with 0 lifetime prefixes Cc: IPng Working Group Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1348 [retransmission -- sunroof bounced the first transmission] At 9:56 AM -0700 7/31/97, Richard Draves wrote: > At this point, I believe in a fairly strong isolation between > the link layer and the IPv6 layer. For example when a packet is handed > up to IPv6 from the link layer, there is no information passed about the > link layer source & destination addresses. This kind of > consistency-checking would weaken this isolation. Rich, Unfortunately, the isolation is already slightly violated, in that ICMP needs to know whether or not the link-layer destination address of incoming packets was unicast or non-unicast, in order to suppress ICMP error messages in response to link-layer multicasts or broadcasts [RFC-1885, page 6]. Granted that's just a one-bit flag, not a link-layer address or pair of addresses. (I'm personally not fond of even that bit of layer leakage, but I lost that argument in the Host Requirements working group, many eons ago.) 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 Jul 31 11:52:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA11573; Thu, 31 Jul 1997 11:42:58 -0700 Received: from sunmail1.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA11566; Thu, 31 Jul 1997 11:42:48 -0700 Received: from saturn.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id LAA15632; Thu, 31 Jul 1997 11:45:10 -0700 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA22370 for ; Thu, 31 Jul 1997 11:45:02 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA30868; Fri, 1 Aug 1997 04:43:22 +1000 (from kre@munnari.OZ.AU) To: Erik.Nordmark@Eng (Erik Nordmark) Cc: dth@lucent.com, dhaskin@BayNetworks.COM, ipng@sunroof Subject: (IPng 4230) Re: security problem: RAs with 0 lifetime prefixe s In-Reply-To: Your message of "Thu, 31 Jul 1997 10:46:08 MST." <199707311746.KAA18937@bobo.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Aug 1997 04:43:20 +1000 Message-Id: <8562.870374600@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4099 Date: Thu, 31 Jul 1997 10:46:08 -0700 From: Erik.Nordmark@Eng.Sun.COM (Erik Nordmark) Message-ID: <199707311746.KAA18937@bobo.eng.sun.com> | Without requiring some more state about the prefixes that today | (i.e. just prefix and lifetimes) I don't see how you can implement | the above rule and still be able to lower the lifetime. That's certainly true, though I would suggest that keeping the needed extra state is a good idea anyway - it allows debugging network problems (it becomes trivial to determine which router is sending a bogus prefix, or similar, simply by examination of your prefix table). | Today the state is: | Prefix P1, lifetime 10 days Yes. | If you keep | From R1: Prefix P1, lifetime 10 days | From R2: Prefix P1, lifetime 10 days and 3 minutes | From R3: Prefix P1, lifetime 10 days | From R4: Prefix P1, lifetime 10 days and 10 minutes | From R5: Prefix P1, lifetime 10 days | From Rogue R: Prefix P1, lifetime 3 seconds | you can clearly implement your rule by computing the max lifetime | over all routers. You only need to keep From R4: Prefix P1, lifetime 10 days and 10 minutes That adds just the "R4" - then when an incoming RA appears, either it is from R4, in which case it is processed, or it isn't, in which case the lifetime is compared, and if greater, it replaces R4 (I might also suggest putting a limit on how much greater it can be - maybe a factor of 2). Keeping R4 in the table (if your implementation can possibly afford the extra 16 bytes per advertised prefix - which is not that much overhead unless you're imagining hundreds of prefixes) is a good idea anyway, as mentioned above. | But there are another problem (apart from the additional state): | If R1 is turned off and later the network manager wants to lower | the lifetime to 1 day it can't be done until the lifetime sent | by R1 has expire. (The R1 entry will remain in the hosts state | until it times out.) You can work around this by having e.g. R2 | send you a RA packet with R1's source address but that is rather | gross. Perhaps better, have R2 send a packet first with a slightly longer lifetime, and follow that with the short one. A bigger problem with Dimitry's algorithm might be ... 3) if a router receives a multicast RA with a prefix that has a lifetime lower than the receiving router advertises for this prefix, it should immediately send own multicast RA. That opens a packet storm problem - is a misconfig'd router with a shorter than should be lifetime starts sending RA's on a link, every other router will immediately (quite quickly anyway, that is required) respond with its RA. That might be a considerable amount of traffic on large nets. Further, unless that extra RA is considered to be a special case, it could also result in synchronising the RA's from everyone else. if there are a few misconfigured routers (with different lifetimes), the response to the one with the shortest lifetime sending its RA will be for all to respond. Several of those will be shorter than others - each of those will cause all those with longer lifetimes to send another RA. Some of those will be shorter than others, ... This repeats until only those with the longest lifetime respond. One way out of that might be to have routers listen to other routers RAs and adjust their lifetimes upwards (if necessary) for each prefix, so all fairly quickly settle on the maximum configured value. Of course doing that makes it very difficult to ever reduce a lifetime, as as soon as you configure a router with a lowe value it sees an RA from someone else, and bumps its one again. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 31 14:01:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA11795; Thu, 31 Jul 1997 13:49:54 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA11788; Thu, 31 Jul 1997 13:49:44 -0700 Received: from bobo.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA00914; Thu, 31 Jul 1997 13:52:07 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA19058; Thu, 31 Jul 1997 13:52:06 -0700 Date: Thu, 31 Jul 1997 13:52:06 -0700 From: nordmark@jurassic (Erik Nordmark) Message-Id: <199707312052.NAA19058@bobo.eng.sun.com> To: kre@munnari.OZ.AU Subject: (IPng 4231) Re: security problem: RAs with 0 lifetime prefixe s Cc: ipng@sunroof MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1358 > | But there are another problem (apart from the additional state): > | If R1 is turned off and later the network manager wants to lower > | the lifetime to 1 day it can't be done until the lifetime sent > | by R1 has expire. (The R1 entry will remain in the hosts state > | until it times out.) You can work around this by having e.g. R2 > | send you a RA packet with R1's source address but that is rather > | gross. > > Perhaps better, have R2 send a packet first with a slightly longer > lifetime, and follow that with the short one. And how many retransmissions does R2 need to do with the higher lifetime to ensure that everybody receives it? What if two routers are doing this at the same time? Your RA storm point is a good one. My gut feel is that this is either not very robust or, if it is made robust will be rather complex. I suspect it will be more complex than the simple 2 hour rules that started this discussion. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jul 31 23:00:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA12691; Thu, 31 Jul 1997 22:51:32 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA12684; Thu, 31 Jul 1997 22:51:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA23837; Thu, 31 Jul 1997 22:53:42 -0700 Received: from CHIMAY.MACH.CS.CMU.EDU (CHIMAY.MACH.CS.CMU.EDU [128.2.222.167]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA08038 for ; Thu, 31 Jul 1997 22:53:43 -0700 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa16486; 1 Aug 97 1:53:31 EDT To: mobile-ip@SMALLWORKS.COM, ipng@sunroof.eng.sun.com From: Dave Johnson Subject: (IPng 4233) New Internet-Draft for Mobile IPv6 Date: Fri, 01 Aug 97 01:53:25 -0400 Message-ID: <16484.870414805@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3320 On Wednesday, I submitted a new version of the Mobile IPv6 draft, which is now working its way through the official annoucement and publication process. This draft is a product of the Mobile IP working group. For those interested in getting a copy now, I have made it available on my ftp server at: ftp://ftp.monarch.cs.cmu.edu/pub/internet-drafts/ draft-ietf-mobileip-ipv6-03.txt Below is a copy of the abstract from the draft: This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send packets destined for the mobile node directly to it at this care-of address. And here is a list of some of the major changes in this draft relative to the previous version of this same draft: - Introduced the Home Address destination option, to allow packets sent by a mobile node while away from home to pass normally through routers implementing ingress filtering. - Added the requirement that all IPv6 nodes MUST be able to correctly process a Home Address destination option in a received packet. - Changed the interpretation of the Binding Update option such that the home address in the binding is the address in the Home Address option, not the Source Address in the IPv6 header. - Made the Care-of Address field in the Binding Update optional, controlled by whether or not the new Care-of Address Present (C) bit is set in the option. With the new use of the Home Address option, the care-of address for a binding will usually be specified by the Source Address field in the packet's IPv6 header, but by retaining this field (and making it optional), it is possible to send a binding update using a Source Address different from the care-of address for the binding. - Changed the 32-bit Identification field in the Binding Update and Binding Acknowledgement to a 16-bit Sequence Number field, and clarified the use of this field. Replay protection for Binding Updates and Binding Acknowledgements is provided by the IPsec authentication in the packet, but this replay protection does not provide sequencing due to the use of the replay protection window. This field satisfies that the additional sequencing requirement. - Added a description of the dynamic home agent address discovery procedure and the use of the new Home-Agents anycast address. Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------